Why return None?

[Alex Martelli]

Antoon Pardon <apardon at forel.vub.ac.be> wrote:
   ...
> > You think one way, GvR thinks another, and in Python GvR wins.  Go
> > design your own language where what you think matters.
> 
> Why the fuss over the chosen decorator syntax if  GvR
> wins anyhow.  Why don't you go tell all those people
> arguing decorator syntax that they should design their own
> language where what they think matters.

Because in this case, specifically, the decision is explicitly
considered "not definitive yet".  Alpha versions get released
_specifically_ to get community feedback, so a controversial innovation
gets a chance to be changed if the community can so persuade Guido.

I do not know if you're really unable to perceive this obvious
difference, or are just trying to falsely convince others that you're as
thick as that; in this like in many other cases in this thread, if
you're pretending, then you're doing a good job of it, because you're
quite close to convincing me that your perception _is_ truly as impeded
as it would appear to be.

> 
> If you think I shouldn't voice an opinion here because GvR
> wins anyhow and my opinion won't matter fine. Just say so
> from the beginning. Don't start with pretending that you
> have good arguments that support the status quo because
> all that matters is that GvR prefers it this way.
> All good arguments in support are just a coincidence in
> that case.

I do think, and I have indeed "stated so from the beginning" (many years
ago), that it's generally a waste of time and energy for people to come
charging here criticizing Python's general design and demanding changes
that won't happen anyway.  There are forums essentialy devoted to
debates and flamewars independenlty of their uselessness, and this
newsgroup is not one of them.

People with normal levels of perceptiveness can see the difference
between such useless rants, on one side, and, on the other, several
potentially useful kinds of discourse, that I, speaking personally, do
indeed welcome.  Trying to understand the design rationale for some
aspect of the language is just fine, for example -- and that's because
trying to understand any complicated artefact X is often well served by
efforts to build a mental model of how X came to be as it is, quite
apart from any interest in _changing_ X.  You may not like the arguments
I present, but I'm not just "pretending" that they're good, as you
accuse me of doing: many people like them, as you can confirm for
yourself by studying the google groups archives of my posts and of the
responses to them over the years, checking out the reviews of my books,
and so on.  If you just don't like reading my prose, hey, fine, many
others don't particularly care for it either (including Guido,
mostly;-); I'll be content with being helpful to, and appreciated by,
that substantial contingent of people who do like my writing.

And so, inevitably, each and every time I return to c.l.py, I find some
people who might be engaging in either kind of post -- the useful
"trying to understand" kind, or the useless "criticizing what you cannot
change" one -- and others who are clearly just flaming.  And inevitably
I end up repeating once again all the (IMHO) good arguments which (IMHO)
show most criticisms to be badly conceived and most design decisions in
Python to be consistent, useful, helpful and well-founded.  Why?
Because this is a _public_ forum, with many more readers than writers
for most any thread.  If these were private exchanges, I'd happily set
my mail server to bounce any mail from people I know won't say anything
useful or insightful, and good riddance.  But since it's a public forum,
there are likely to be readers out there who ARE honestly striving to
understand, and if they see unanswered criticisms they may not have
enough Python knowledge to see by themselves the obvious answers to
those criticisms -- so, far too often, I provide those answers, as a
service to those readers out there.  I would much rather spend this time
and energy doing something that's more fun and more useful, but it's
psychologically difficult for me to see some situation that can
obviously use some help on my part, and do nothing at all about it.

Maybe one day I'll be psychologically able to use killfiles more
consistently, whenever I notice some poster that I can reliably classify
as a useless flamer, and let readers of that poster's tripe watch out
for themselves.  But still I find it less painful to just drop out of
c.l.py altogether when I once again realize I just can't afford the time
to show why every flawed analysis in the world IS flawed, why every
false assertion in the world IS false, and so on -- and further realize
that there will never be any shortage of people eager to post flawed
analysis, false assertions, and so on, to any public forum.


> >> I don't see that much difference in the frustration of having
> >> to write: 
> >> 
> >>   t = f(x)
> >>   v[t] = v[t] + 1
> >
> > You're repeating (necessarily) the indexing operation, which may be
> > unboundedly costly for a user-coded type.
> 
> That repetion is just pythons inabilty to optimise.

There being, in general, no necessary correlation whatsoever between the
computations performed by __getitem__ and those performed by
__setitem__, the repetition of the indexing operation is (in general)
indeed inevitable here.  Python does choose not to hoist constant
subexpressions even in other cases, but here, unless one changed
semantics very deeply and backwards-incompatibly, there's nothing to
hoist.  ((note carefully that I'm not claiming v[t] += 1 is inherently
different...))

> 
> >> and the frustration of having to write
> >> 
> >>   lst = f(x)
> >>   lst.sort()
> >>   lst.reverse()
> >
> > Here, no operation is needlessly getting repeated.
> 
> Yes there is, the operation to find lst from the local dictionary.
> Although it wont be unboundedly costly.

If you're thinking of a virtual machine based on a stack (which happens
to be the case in the current Python), you can indeed imagine two
repeated elementary operations, in current bytecode LOAD_FAST for name
'lst' and POP_TOP to ignore the result of each call -- they're extremely
fast but do indeed get repeated.  But that's an implementation detail
based on using a stack-based virtual machine, and therefore irrelevant
in terms of judging the _language_ (as opposed to its implementations).
Using a register-based virtual machine, name 'lst' could obviously be
left in a register after the first look-up -- no repetition at all is
_inherently_ made necessary by this aspect of language design.


> > Still, I'm much happier thinking of you busy designing your own
> > wonderful language, than wasting your time and yours here, busy
> > criticizing what you cannot change.
> 
> If you don't want to waste time, just state from the beginning
> that this is how GvR wanted it and people won't be able to
> change it.
> 
> You shouldn't start by arguing why the language as it is is as
> it should because that will just prolong the discussion as
> people will give counter arguments for what they think would
> be better. If you know that, should people not be persuaded
> by your arguments, you will resort to GvR autority and declare
> the arguments a waste of time, you are better of puttings
> GvR autority that can't be questioned on the table as soon
> as possible.

On the other hand, _reasonable_ readers (and there are some, as shown by
the various feedback on my work that I have referred to in previous
parts of this post) can benefit by a presentation of the _excellent_
reasons underlying Python's design, and such readers would be badly
served if the flawed arguments and false assertions presented to justify
some criticisms of Python were left unanswered.


Alex