2001 Enchancement Wishlist

[Alex Martelli]

"Raymond Hettinger" <othello at javanet.com> wrote in message
news:3A4ECDA9.E2796F78 at javanet.com...
    [snip]
> I was hoping to avoid a factory method or global variable or using
> modules to create single instances.  Compared to enriching __init__,
> these approaches seem kludgy,

Why would a factory function be "kludgy"?  It's one of the most
classic and useful design-patterns, and I've as yet seen NO reason
at all, from either you or Pearu, showing this pattern as in any
way undesirable.

> break the encapsulation of the class,

How so?  In what sense, exactly, does a client-code call of:

    x = theModule.makeFoo(1,2)

show any 'encapsulation breaking' when compared to

    x = theModule.Foo(1,2)

...?

> and are hard to implement after clients are already making calls to
> the constructor.

Really?  How does client-code use the classname _except_ as a
constructor?  So, if you're so keen to avoid having it call makeFoo,
just change your theModule.py as follows:

-- start of theModule.py
class Foo:
    def __init__(self):
        # whatever
    # further mysteries

# we currently singletonize it

_singleFoo = Foo()

def makeFoo():
    return _singleFoo

# and now, the magic trick...:

Foo = makeFoo
-- end of theModule.py

Now, the client code doing

    myFoo = theModule.Foo()

will in fact be calling function theModule.makeFoo, which can
return whatever you desire.  It doesn't make the singleton design
pattern any better, mind you -- but neither does it make any
worse; if you ARE keen to have a callable, named "just like" a
class, which isn't the class itself, it's pretty elementary.


> The decision to make a object a Singleton or to
> revoke that decision should be invisible to clients of the class.

I strongly disagree that such "invisibility" is at all a desirable
design target -- and, in any case, "having __init__ return
something" would surely not accomplish it (or would you also
abolish 'is', 'id', etc...?).


> Only one of the posts so far reacted positively to the idea, but none
> indicated that it would be hard to implement.  It would seem to add
> flexibility without breaking anything currently written.

Adding one more way to accomplish what can perfectly well
be accomplished now by other means (and is in many cases
a dubious idea anyway -- e.g., alleged "invisibility" of singleton
or non-singleton state for a class) is definitely unPythonic.


> Here is a revised wish (borrowed from AWK):
>
> Override the IN keyword for dictionaries and access the keys directly:
>
> knights = { 'lancalot':'good', 'gallahad':'brave', 'robin':'coward' }
> for k in knights:
>         print k, knights[k]
> if 'arthur' in knights:
>         print 'Not a king'

The more I do Python, the more I like "explicit is better than implicit".

Your request seems to boil down to having x implicitly mean x.keys(),
when x is a dictionary, in certain contexts; taking 'black magic' (even
in small doses:-) as a _negative_, rather than as good in itself, what
IS the supposed benefit that offsets the cost of implicitness here?

Having two perfectly good and equivalent ways to accomplish the same
task is another unPythonic aspect of this, as above indicated.  Python's
ideal is that there be ONE way to perform a task -- as an ideal, it cannot
be fully reached, only approached; but, where is the plus in such a
deliberate departure from the usual design-guideline of the language?


Alex