Hello people. I have some questions

[Alex Martelli]

"jeroen paul goudsmit" <diedanootdie at danoot.com> wrote in message
news:XO2j7.19$Cz3.314 at pollux.casema.net...
>
> I can read, write, speak , hear, understand english. I'm dutch, so dutch
> still is easier for me. That's why I asked for dutch books.

Funny enough, while Python's inventor and architect is Dutch,
and so are some of the major figures in the Python community,
e.g. Boudewijn Rempt (see http://stage.linuxports.com/pyqt/book1.htm),
I don't know of any Python resource in Dutch -- Bulgarian,
Chinese, Czechoslovakian, Esperanto, French, German, Hungarian,
Italian, Japanese, Korean, Norwegian, Portuguese, Russian,
Spanish and Swedish, yes, but not Dutch.  Maybe that's the
downside of you guys being so good at English -- none of you
has bothered setting up Dutch-language mailing lists, sites,
book translations and so on...?


> so if i got it right, python is easier then vb. Only one  thing is not
easy.

Nope, I would say a tiny bit more than one.  Most have good and bad
aspects, but they can be seen as "not easy".  It IS a handful of
things out of the thousands details of each language, though.

> You can't just put  a control on a form. But there are special thingies in
> python who can.

Yes, depending on the GUI toolkit you choose.  "not easy" thing
number one is that there are so *MANY* Python extensions for such
tools as GUI's and web work that choosing between them is hard!
Of course, this also has good sides -- nice to have choice.

Other "not easy" thing are:

    -- in Python, case is significant: words such as "english"
        (adjective) and "English" (noun) are distinct even though
        they only differ in case (upper/lower).  Visual Basic is
        more forgiving in this.  Good side, well, this is hotly
        debated in the Python community, and some of us are
        convinced that case-sensitivity was a design error (it's
        not gonna change -- backwards compatibility is generally
        maintained in Python!), but most Pythonistas love it (I
        guess they have Unix backgrounds -- so do I but I still
        prefer case-insensitivity!-), so I guess it must have some.

    -- in Python, division TRUNCATES when it's between integers:
        print 1/2
       emits 0, NOT 0.5 as most people expect.  In Visual Basic,
       the result of 1/2 is indeed 0.5.  In Python you have to
       use a . somewhere to indicate a non-integer number, e.g.
       1./2 or 1/2. or 1./2. (or just write 0.5), or explicitly
       ask to float one or both numbers one way or another.
       Another hotly-contentious item in the Python community.

     -- in Visual Basic (non-strict mode) you can just use a
       variable you've never mentioned before and it will just
       spring into life with a default value (it's never very
       clear if that default value is an empty string or the
       number 0, or something different yet, and this often does
       confuse things, of course).  In Python a variable appears
       when it's *assigned* to -- you can't use a variable that
       has never been assigned, Python will detect an error if
       you try to do that.  This DOES in the mid-long term make
       things easier (no wondering about what kind of default
       value has sprung up from nowhere!) but beginners sometimes
       have a slightly hard time coming to terms with the idea
       that any name must have been created before you use it.


> And i've got one more question. What's the limit of python. What can you
not
> make in it. Vb stops somewere, c++ stops later. Weere stops python?

VB (and Python) stop where there's no runtime environment to
support them (C++, like C, is designed to be able to do without
a support environment -- it does need a *compiler* to prepare
the program for execution, but once compiled and prepared the
program can run on the environments it was prepared for, which
may be "such and such machine without any other software AT
ALL", e.g. "embedded" applications).

Say you'd like a little program of yours to run in the browser
of anybody who looks at your site.  VB will stop at any browser
that lacks VB runtime support (Internet Explorer, recent versions,
has it, albeit, reasonably, limited to the VBScript subset;
Netscape and Opera do not; etc, etc).  Python will stop at any
browser that lacks Python runtime support (and, apart from the
old Grail browser that was written entirely in Python, I know
of no browser that *COMES WITH* Python runtime support -- you
could easily ADD such support to Internet Explorer, or Mozilla 6,
since they're highly-modular browsers, but you probably cannot
count on the visitors to your webpage having done so!).

I see other posters have mentioned and are debating "OS modules".
It's again just a question of runtime support -- no more, no
less: if an OS had runtime support for VB, or for Python, you
could use VB, or Python, to write modules for that OS, period.
There's no "conceptual" block -- just that, in practice, I know
of no such OS (for either language).

Apart from the "deployment" issue of "is there runtime support",
both languages are capable of any task whatsoever -- so called
"Turing-complete" (within the hardware limits of the systems
they're using).  One will be much more PRODUCTIVE than the other
for certain tasks, but that's a different issue from "stopping".


Alex