Perl is worse! (was: Python is Wierd!)

[Alex Martelli]

"Steve Lamb" <grey at despair.rpglink.com> wrote in message
news:slrn8o1vc0.vnr.grey at teleute.rpglink.com...
    [snip]
>     Like I said, every language has its quirks.  Every language.  Just
because
> this is your favorite doesn't mean it doesn't have quirks, just means you
are
> used to them.  Just as a perl programmer I am used to perl's quirks and
take
> advantage of them and, yes, sometimes get caught by them as well.  Just as
I

I have 8 years' experience with Perl, and less than a year with Python.
After
a *MONTH* of Python, I was far happier and more productive with it than I've
ever been throughout those long, drab years of Perl (actually, I was
deliriously
happy already well before the month was over, but, realistically, it did
take a few
weeks before I started feeling _mastery_ of the language's mechanics -- I
was,
after all, studying it "very part-time"!).

So, it most emphatically DOESN'T "just mean I am used" to the quirks of one
language and not to those of another; there IS a huge difference in the
quirk-sets
involved.  Which doesn't have to mean one of them is empty, of course.
"Every
sea has some water" doesn't have to mean Aral is remotely comparable to the
Pacific Ocean, even as long as the former still has some drops in it; "every
man
has some money" doesn't mean my finances are comparable with Bill Gates'.

> am in the process of learning Python (rapidly, I might add) and have, and
> will, be caught by its quirks and will also learn to take advantage of
them.
>
>     But please, if you're going to toss rocks out your glass house, at
least
> be realistic about it, ok?  At least then your neighbors are more apt to
help
> you sweep up the resulting mess.

Realism and pragmatism are fine qualities.  But they STILL don't make Aral
and the Pacific directly comparable.


>     And just for fun, here's a good quirk for you.
>
> None = 1
> a = None
> >>> if a:
> ...   print "foo\n"
> ...
> foo
>
> >>> a
> 1
>
>     I think that is kinda neat, don't you?

I don't understand why it would be a 'quirk', or 'neat', that identifiers
bound
in the current (global) namespace hide homonyms bound in the builtin
namespace.  (Similarly, those in the local namespace hide those in the
global one).  I've been using lexically scoped languages for over a quarter
century, and it seems quite sensible and reasonable to me; having just
three active namespaces rather than an unbounded amount, which is
Python's peculiarity wrt other languages in this regard, plays no role in
this which you claim to be a 'quirk'.

Would you expect identifiers bound in a wider namespace to somehow
'lock-out' or 'pre-empt' narrower-namespace rebinding, a la Java?  I did
not find this Java feature at all helpful when I used Java (nor particularly
damaging, either).


> {grey at teleute:~} perl
> null = "foo";
> Can't modify constant item in scalar assignment at - line 1, near ""foo";"
>
>     I just don't understand how people can advocate for types and the
> restrictions they impose while, on the other hand, embracing a language
that
> is free enough to shoot yourself in the foot by reassigning None.

Naming and typing are orthogonal issues and Python keeps them
carefully separated (a very strong point in its favour).  The Perl idea
of keeping unlimited 'barewords' available for infinite future addition
of keywords is part of what forces all of those yecchy '$'.  Python has
chosen to define its set of keywords (reserved words) very carefully
and narrowly, once and for all, limiting keywords to those which bear
a needed syntactic load (following in this the tradition of Pascal, C,
etc): exactly 28 of them, in a carefully designed balance between
restriction of the set, and program readability.

None of the 28 keywords, of course, names an object of any kind.
All names of objects (functions, constants, etc) which Python defines
are perfectly ordinary identifiers, just bound in advance in the
__builtins__ namespace (86 of them in my current 1.5.2 setup).

You can perfectly well choose to re-bind them differently in a more
localized namespace, of course; in that namespace, you will then
(just as "of course") have to use the long explicit form
    __builtins__.Identifier
rather than just mentioning Identifier, if you want to access the
original binding in __builtins__.

Further, namespace dictionaries are not locked -- try rebinding
or unbinding (deleting) __builtins__.None, for *REAL* fun (and
don't be surprised if an IDE crashes when you do that:-).  I think
some explicit way to lock a dictionary against modification would
be neat to avoid _accidental_ rebinding of entries, actually, but
I doubt that this rebinding (or deleting, etc) *could* be at all likely
to happen *accidentally*!-)... anybody really determined to rebind
__builtins__.None would have no qualms calling the 'unlock'
method on its dictionary, either!-)


Alex