2001 Enchancement Wishlist

[Alex Martelli]

"Thomas Wouters" <thomas at xs4all.net> writes:

> > > > > already has a framework for creating exactly one instance of
> > > > > something: the module namespace).
> > > >
> > > > Pity that isn't as flexible as an object-instance -- can't define
> > > > special methods to determine how it will print, how it will
> > > > let usercode loop on its items, etc.
> > >
> > > Of course it can.
> >
> > The module can define a class-instance object (which can in turn
> > do these nice things), but it can't do them itself -- as you know
> > perfectly well, so it's peculiar that you would say otherwise.
>
> I'm afraid I don't understand the difference. Are you saying a class can't
> pretend to be a list by encapsulating it, because it wouldn't do the work

A class-instance _is_ 'as flexible' as itself -- it can present whatever
'face' it needs to client-code (however it chooses to implement or
delegate it) [well, _almost_ 'whatever' -- but close enough].  (It's
the _instance_ object that can 'pretend to be a list', NOT the _class_
object, of course; I'm nitpicking just because you later seem to be,
regarding my former use of 'object-instance' where 'class-instance'
was meant:-).

> itself ? Or that it can't do string operations because it doesn't do the
> operations itself, but rather asks the string object to do them (in 2.0)
or
> asks the strop module to do it (before 2.0) ?

Ditto, and no difference from the previous case.

A module object, in contrast, has no such flexibility.  It can of
course have *attributes*, which, as they can be anything (in particular,
they can be class-instances), are as flexible as can be -- but it
cannot present any 'face' to client-code, except its own.


> > > <spammodule.py>
> > > class _singleton:
> > > <whatever you want>
> > >
> > > SingleTon = _singleton()
> > >
> > > All that is required is for everyone to use spammodule.SingleTon.

This is like saying that, e.g., a dictionary object can be callable --
    dict = {}
    dict['callit'] = somefunction
"all that is required" is for everyone to use dict['callit']... i.e.,
the dict itself *ISN'T* callable, just because it can have one or more
items that are.  Or, similarly, a tuple -- tup=(somefunction,), and
then, "all that is required" is for everyone to use tup[0]...!  Again,
the *tuple* isn't callable, even though one or more of its items may be.

Similarly, as I said, the *module* "can't define" how it will
print, how it will let clientcode loop-on-its-items, and so on;
one or more of its attributes can of course do so, just like
one or more of the items in a tuple or dict, but that doesn't
transfer such defining-power to tuples, dicts, or modules
themselves.


> > So, if somebody complains that a Python lambda cannot contain
> > a for loop, will you answer "of course it can" in that it can (e.g.)
> > call a function which, in turn, IS able to contain such loops?
>
> Again, I don't see the difference. I'm sorry that I apparently pissed you
> off by explaining what I thought /F meant, but I can honestly say this is
> the first time I've been flamed without undestanding why :) Lambda's
cannot
> contain 'for' loops, but you can do a 'for' loop from a lambda, by

So, lambdas can USE (indirectly) for-loops, but they can't CONTAIN
one.  What do you mean "you don't see the difference"?  You've just
named it!

If Python didn't have lambdas at all, you could define functions
and pass them where you now use lambdas.  If Python didn't exist,
you could write machine-code performing exactly the same things.
Can you *really* not see the difference between an object having
and lacking a certain ability?!

> 'encapsulating' it in a function. Python lacks closures, but they can be
> faked using default-arguments.

I'm not convinced that this is 'faking', by the way.  But that's
another argument.

> Python doesn't have Perl's 'm//' or
> 'while(<>)', but you can achieve the same effect through the re and
> fileinput modules. Python lacks C's ability to do '*(0) = 42', but you can
> achieve a similar effect by using the signal module ;P

Right.  And when somebody writes "Python cannot issue a generic
syscall", you don't say "Of course it can." because C code can
be written that does so and which Python can call -- well, maybe
YOU do, judging from current form.  Moreover, you would then
also say that a Python _dictionary_ can issue the call, right?
Since it can have an item that's a C-written function that does...

That reduces the usefulness of the verb 'can' to zero --
everything can do anything, great.  Pah.

More sensible usage: if I say "I can't play the piano", one
doesn't respond "of course you can -- all it requires is
that you pay some pianist to play on your behalf"... that
would still be him, or her, playing, and it would not make
my statement false.  A preferable response might rather be
"if you can't, and still you need a piano played, you may
easily find good pianists that will perform the playing in
return for monetary compensation" -- still not very good,
as it assumes I don't know (or haven't thought of) such an
obvious solution, but still much better than the "of course
you can" falsehood.

Suppose that Python was changed, so that a class whose
name has an even number of characters cannot any more
define __str__, and so on.  If then somebody regretted
that his 'class Foop' "cannot define how" its instances
will be printed, etc, would you answer "of course it can"
since it can have an attribute X that instances a suitable
odd-number-of-chars named class -- that "all it takes"
is for everybody to use blak.X when referring to instances
of class Foop...?!


> What, exactly, are you objecting to ? That everything in Python is an
> object instance, whether you want it or not ?

Oh really?  Are you claiming, e.g., that the keyword 'for' is not
"in Python", or are you claiming that it's an object instance?  If
nit-picking is what you want, nit-picking we have to supply, no
worry.

What I object is not in Python, but rather in your answer: the
(false) assertion that 'of course' a module object 'can' define
how it will print, etc.  It can't, any more than, say, a dict
object, a tuple, etc -- some of their attributes/items may, but
that does not mean the objects themselves have this ability.

I wouldn't mind it if a module-object could define special
methods for such purposes, mind you, but I hardly think it
a make-or-break issue -- the pretty mild regret suitably
expressed, I think, by my original "pity that" sentence.


Alex