Why return None?

[Antoon Pardon]

Op 2004-08-27, Alex Martelli schreef <aleaxit at yahoo.com>:
> Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>    ...
>> 
>> 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.

I don't demand changes. I have my critisms of the language and
think that some arguments used to defend the language are not
well founded and when I see one of those I sometimes respond
to it.  That is all. I realise no language is perfect
and I don't have the time to design the one true perfect language
my self. In general I'm happy to program in python with the
warts I think it has. I'll just see how it evolves and based
on that evolution and the appearance of other languages will
decide what language I will use in the future.

I hope that someday a ternary operator will arive, but my choice
of language will hardly depend on that and I won't ask for it
except if ever that particulat PEP becomes activated again.
But if someone argues there is no need for a ternary operator
I'll probably respond.

> 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.

The number of people that like your arguments is irrelevant to me.
If I don't think it is a good argument chances are I will respond
to it.

> 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.

The problem IMO is that often enough, when a usefull trying to
understand article arrives, the answers are not limited to
explaining what is going on, but often include some advocacy
of why the choice made in python was the correct one.

This invites people who are less happy with that particular choice
to argue why that choice isn't so good as the first responder may
have let to believe. Even if they don't particularly want the
language to change.


> 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.

Well the same work the other way around. There are those people who
think that some of the choices that python made are not that consistent,
usefull, helpfull and well-founded as some would like us to believe
and that those things may be known too.

>> >> 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__,

Maybe that is the problem here. I think one could argue that a c++
approach here would have been better, where v[t] would result in
an lvalue, from which a value could be extracted or that could
be set to a value depending on which side of an assignment it
was found. And no I'm not asking that python should be changed
this way.

-- 
Antoon Pardon