about sort and dictionary

[Mike Meyer]

Different programming styles are appropriate for different
tasks, different times and different places, different people.
And like morality, government, or economics, I do not believe
that one style of programming fits all situations.

If I read you right, what you're saying is that hammmers aren't good
at driving screws. I don't think anyone would argue about that.

But I do not think (and reading c.l.p convinces me) that GvR and
Python's developers know a coding style that works best in all
situations.

I don't think that GvR believes he knows such a coding style,
either. I certainly don't believe it.

I do think that the Python development community believes they do,
or more accurately, that if someone wants to use a different style,
they can go use something else.

In other words, they believe that you should use a screwdriver to
drive screws, and not a hammer. You apparently disagree with them.

I think that it is possible to include in Python, things that are
non-Pythonic (such as a return value from sort()) that allow users
more stylistic freedom, without degrading the ability of those who
don't want to use such features, to write in a pure Pythonic manner.

So you think we can turn a hammer into a screwdriver without degrading
the ability to use the hammer to drive nails. The problem is, doing
this means you have a bigger, heavier hammer - which almost certainly
degrades the ability to use it as a hammer.

Adding features makes the language processor bigger. With Pythons
strong commitment to backwards compatibility, these are hard to get
rid of. Further, while those of us who like the Pythonic style may not
have to use them, that won't prevent us from having to maintain code
that uses them.

Now, I'm not against changing the language per se. But most language
changes have deeper implications than are obvious at first
glance. Even when they don't, I'd prefer that you get cases that make
for significantly cleaner code without having major negative
connotations. The first is why people ask for "use cases": they want
to see a real-world example where the proposed change would make
things cleaner or more readable, or otherwise better in some way. At
the same time, the new feature should provide an abuse that's hard to
read, or lead to code that is easily misinterpreted.

This has the benefit of attracting more people to Python.

And why is this a benefit?

<mike

 

[bonono]

In other words, they believe that you should use a screwdriver to
drive screws, and not a hammer. You apparently disagree with them.

That is the kind of argument I see all the time on this thread. It is
more appropriate to say that "I don't believe it is a screw, but
something else and don't want to use a screw driver with it".

So you think we can turn a hammer into a screwdriver without degrading
the ability to use the hammer to drive nails. The problem is, doing
this means you have a bigger, heavier hammer - which almost certainly
degrades the ability to use it as a hammer.

And it follows through, first said it is a screw and since you
disagree, you are trying to do screwing with a hammer.

Adding features makes the language processor bigger. With Pythons
strong commitment to backwards compatibility, these are hard to get
rid of. Further, while those of us who like the Pythonic style may not
have to use them, that won't prevent us from having to maintain code
that uses them.

Now, I'm not against changing the language per se. But most language
changes have deeper implications than are obvious at first
glance. Even when they don't, I'd prefer that you get cases that make
for significantly cleaner code without having major negative
connotations. The first is why people ask for "use cases": they want
to see a real-world example where the proposed change would make
things cleaner or more readable, or otherwise better in some way. At
the same time, the new feature should provide an abuse that's hard to
read, or lead to code that is easily misinterpreted.

I am just curious that if the "should we have ternary" back then
creates similar arguments.

Based on what I have read for this few period of time on this group, it
is actually not people coming in complain loudly that "why can't Python
have this" kind of post, it usually was a neutral question because
either they come from another background, or they for whatever reason
expect things to work certain way, or they enjoy certain style. But
many times, the responses are toned in a way of "you dumb, you didn't
know that is the wrong way of doing it?", without explain why or with
convincing reasons.

 

[Mike Meyer]

That is the kind of argument I see all the time on this thread. It is
more appropriate to say that "I don't believe it is a screw, but
something else and don't want to use a screw driver with it".

Whatever it is, trying to turn Python into a tool for dealing with it
isn't the right thing to do.

And it follows through, first said it is a screw and since you
disagree, you are trying to do screwing with a hammer.

You're the one that wants to use the hammer to do whatever it is, not
me. I don't believe in silver bullets. Python is good at what it
does. If I need a different tool, I use a different tool, rather than
try and mangle a good tool into something it's not. Such attempts are
pretty much doomed. They nearly inevitably producej a tool that's not
as good at what the original did as the original, and not as good at
whatever new task it's being mangledd to do as a tool that was
designed for that in the first place.

I am just curious that if the "should we have ternary" back then
creates similar arguments.

By the results of the vote, most people wanted ternary. The use
cases for it are well know. From what I recall, the debate was over
which of the many proposals should be adopted.

Based on what I have read for this few period of time on this group, it
is actually not people coming in complain loudly that "why can't Python
have this" kind of post, it usually was a neutral question because
either they come from another background, or they for whatever reason
expect things to work certain way, or they enjoy certain style. But
many times, the responses are toned in a way of "you dumb, you didn't
know that is the wrong way of doing it?", without explain why or with
convincing reasons.

The usual response is "That's not the Python way." That's not calling
someone dumb, just pointing out that they don't yet fully understand
the Python way. The Python way is not something you're going to grok
by reading postings on usenet. You can have bits and pieces explained
to you, and your understanding will increase. And that's the way it is
for everyone but GvR.

<mike

 

[bonono]

Whatever it is, trying to turn Python into a tool for dealing with it
isn't the right thing to do.

Still this tone, and logic. This statement alone is right except that
it may not be what was about.

You're the one that wants to use the hammer to do whatever it is, not
me. I don't believe in silver bullets. Python is good at what it
does. If I need a different tool, I use a different tool, rather than
try and mangle a good tool into something it's not. Such attempts are
pretty much doomed. They nearly inevitably producej a tool that's not
as good at what the original did as the original, and not as good at
whatever new task it's being mangledd to do as a tool that was
designed for that in the first place.

And again.

By the results of the vote, most people wanted ternary. The use
cases for it are well know. From what I recall, the debate was over
which of the many proposals should be adopted.

That is not the impression I get on here. The impression I get lately
is "ternary" is bad, is hard to read, can always be done "better" with
if then else statement.

 

[Alex Martelli]

Magnus Lycka:


Ruby uses '!' not for mutation but to indicate surprising or
destructive mutation. If it was placed on all mutators, code would be
full of '!'s. '!' is less common on methods that modify the receiver
than on methods that mutate other arguments.

Thanks for the clarification! Unfortunately, this variation on the
convention does make it substantially less clear/sharp/well-defined, and
therefore less useful; whenever I call a mutator I must memorize or work
out (or guess) whether the author considered its mutation "surprising or
destructive" to know whether I need to append a bang or not, which is
peeving; so, I'm now happily reconciled to Python never adopting this.


Alex

 

[bonono]

"do things right" is my fundamental beef with Python.
Dispite claims, I don't believe Python's designers have
a monopoly on the definition of "right".

I think raymond's post more correctly described it. Rather than do
things right, it is more the "world view of python", just that it has
been pushed too far in certain situation(mostly unconciously) and
turning it into a holy war. We seem to see it every where, not just
about a programming language though.

I would have but fortunately the introduction of iterators
spared you from having to read about that

Exactly, it is the functionality, not syntax that matters.
"if-then-else" vs "then-if-else", does it really matter other than
proving one is "righter" ?

I serious doubt sort's return value of lack thereof made any
measurable difference in the time spent helping people.

I kind of understand the rationale behind it now, thanks to another
post. I think the argument is that Python is intended for people
without prior programming experience and that the current behaviour is
more "intuitive"(people expect 321321 in the example case), how that
conclusion is drawn I have no idea but could be valid.

The real life situation though is, Python is usually not the first
language one learns and the net result is that one has to unlearn/wash
away what is learnt to appreciate the pythonic way. But that since we
never has a chance of this "from pure to python", we would never
appreciate that as we already know things about mutable/immutable
object. Thereful, we would not make the mistake of expecting "321321"
and thus no chance to appreciate the "oops, what is this not a iterable
error, let me lookup the manual" saga.

 

[Mike Meyer]

And again.

This isn't a Python thing, it's a believe about tools in general -
that you should choose the right tool for the job. It isn't applied
very often to hardware tools because they aren't as mallable as
software tools, and have in general been around and improving for a
long time. But it applies to programming languages, data formats, and
similar more mallable things. Changes that make them better at what
they do are welcome; changes that make the into what they aren't are
viewed with great suspicion.

Maybe Python attracts people who share that belief. After all, TRTFTJ
is implies TSBOOWTDI, and vice versa.

<mike

 

[bonono]

This isn't a Python thing, it's a believe about tools in general -
that you should choose the right tool for the job. It isn't applied
very often to hardware tools because they aren't as mallable as
software tools, and have in general been around and improving for a
long time. But it applies to programming languages, data formats, and
similar more mallable things. Changes that make them better at what
they do are welcome; changes that make the into what they aren't are
viewed with great suspicion.

Maybe Python attracts people who share that belief. After all, TRTFTJ
is implies TSBOOWTDI, and vice versa.

I was not talking about the believe, I was talking about the way you
presented it. You are setting up an "imaginary" me, which is not me.
And that is the kind of arguments I saw, I believe this many times are
done unconciously.

 

[Mike Meyer]

Thanks for the clarification! Unfortunately, this variation on the
convention does make it substantially less clear/sharp/well-defined, and
therefore less useful;

For the record, the ! convention (and the ? convention) are used by
scheme, where it is used to indiciation mutation (and a predicate). Of
course, scheme isn't OO, and is functional, so that mutation is the
exception rather than the rule.

<mke

 

[Mike Meyer]

I was not talking about the believe, I was talking about the way you
presented it. You are setting up an "imaginary" me, which is not me.
And that is the kind of arguments I saw, I believe this many times are
done unconciously.

You're doing that yourself. But we don't have a real other person to
work with - the best we can do is work with our model of that other
person. That's life.

<mike

 

[bonono]

You're doing that yourself. But we don't have a real other person to
work with - the best we can do is work with our model of that other
person. That's life.

In what way am I doing it myself ? It could be unconciously too but I
always welcome if it could be pointed out.

 

[Steve Holden]

Mike Meyer wrote: [...]

By the results of the vote, most people wanted ternary. The use
cases for it are well know. From what I recall, the debate was over
which of the many proposals should be adopted.

That is not the impression I get on here. The impression I get lately
is "ternary" is bad, is hard to read, can always be done "better" with
if then else statement.

Well I personally believe the main reason Guido resisted the
introduction of the ternary operator for so long is precisely because he
knows it will be "abused" (by which I mean "used when its use will make
a program's meaning less clear") to the detriment of program readability.

Python's unusual virtue is its ability to make a programmer's intent
clear from a reading of the code, and Guido tends to be fiercely
protective of that characteristic.

You should also bear in mind that many (though admittedly not all)
suggestions for change are ill-thought-out at best and lamebrained at
worst. One recent example (though I won't accord it a specific position
on the scale) was the suggestion that user-defined operators could be
introduced using a "]+[" syntax. The fact that this made

y = [1,2,3]+[4,5,6]

syntactically ambiguous had not been considered by the proposer.

I agree that sometimes those who shoot such proposals down in flames
might be more considerate of the feelings of the proposers, but life is
short and we are all imperfect.

The fact that naive expressions of opinion about such matters are
traditionally accorded respect and answered politely is one of the
reasons why so many people find this list a helpful place to discuss Python.

regards
Steve

 

[Steve Holden]

In what way am I doing it myself ? It could be unconciously too but I
always welcome if it could be pointed out.

I think Mike (the Mike I imagine, anyway) merely intended to point out
that since we can't live in each others' heads all communication is with
an imaginary person, whose actual thoughts and feelings are unavailable
to us.

regards
Steve

 

[bonono]

Mike Meyer wrote: [...]

By the results of the vote, most people wanted ternary. The use
cases for it are well know. From what I recall, the debate was over
which of the many proposals should be adopted.

That is not the impression I get on here. The impression I get lately
is "ternary" is bad, is hard to read, can always be done "better" with
if then else statement.

Well I personally believe the main reason Guido resisted the
introduction of the ternary operator for so long is precisely because he
knows it will be "abused" (by which I mean "used when its use will make
a program's meaning less clear") to the detriment of program readability.

Python's unusual virtue is its ability to make a programmer's intent
clear from a reading of the code, and Guido tends to be fiercely
protective of that characteristic.

If it is expressed as this, there won't be long winding recurring
threads about the same topic which usually go off-topic.

I agree that sometimes those who shoot such proposals down in flames
might be more considerate of the feelings of the proposers, but life is
short and we are all imperfect.

Well, no one is obliged to be considerate about other's feeling, that
is a personal choice. But doing it the high handed way is usually
counter-productive and never get the message across, which to me is a
failure.

 

[bonono]

I think Mike (the Mike I imagine, anyway) merely intended to point out
that since we can't live in each others' heads all communication is with
an imaginary person, whose actual thoughts and feelings are unavailable
to us.

If that is the case, it is quite different from saying "you are the one
who wants to use a hammer on a screw", but without further
clarification, I would leave it.

 

[Ben Sizer]

Well, no one is obliged to be considerate about other's feeling, that
is a personal choice. But doing it the high handed way is usually
counter-productive and never get the message across, which to me is a
failure.

I agree with you that sometimes, the responses here can come across as
a bit condescending. I don't think this is intentional, as everybody
seems friendly enough, but I do see a pattern of people replying to a
query and implying that the original poster should know better than to
ask for whatever they asked, despite the Pythonic solutions suggested
often differing algorithmically from the best solution in other
languages.

 

[Antoon Pardon]

My own experience with adapting to Guido's design-view relates to
tuples and lists. To Guido, tuples are for records and lists are for
iteration. My own inclination is to view tuples as immutable lists.
Accordingly, it seems obvious to me that tuples should have count() and
index() methods for better substitutability. However, I've learned
that adapting to Guido's world-view leads to happiness because Python's
function signatures tend to reflect his design view. So, when I'm
thinking the Guido way, my code comes together seamlessly. When I
persist with a conflicting viewpoint, I find myself having to make
conversions, write work-arounds, or create more helper functions than
otherwise needed.

But only Guido, thinks like Guido and then even Guido may now think
differently than he thought before. And what if Guido had a bad day
when he came up with something, should we just adopt to what he
had in mind without questioning them.

Sure, when you have a particular job to finish, you better adapt
to how the language actually works. But when the argument is
about how the language could be better, in whatever way you
want to fill that in, just arguing that one should adapt to
Guido style, is not an argument. Maybe an other approach
could work better.

Since I have been working with python I have seen the following
changes not in a particular order:

augmented arithmetic operators.
generators.
iterators.
nested scopes.
descriptors (and properties)
list comprehension
generator comprehension
f(*sequence) calls
new style classes
unifictation of longs and ints
sets
decorators

I wonder how much of these would have come about if everybody would
just have adapted to the langauge as it was, instead of wondering
how things could be improved. For all changes one could argue
that those who wanted something from this list before it came
about, that they were fighting the language.

When we notice that people are fighting the language, sometimes
the best approach is to change the language so that there is
less reason to fight the language.

 

[Magnus Lycka]

I think you mean volatile or mutable rather than transient? "transient"
is not a keyword in C++, while both volatile and mutable are, with
different semantics. Anyway, C++'s 'const' is a mess both theoretical
AND practical. I'm told Ruby's "object-freezing" works better (but I
have no practical experience).

Right, volatile it is. It's really great that I can program so much
Python now that I forget my C++! Thanks Alex (both for reminding me
of forgotten C++ syntax and for making Python better).

I don't see the alleged humor in this ill-defined concept.

I've run into a lot of cases where things are conceptually non-mutating,
but in implementation, there are lots of internal state changes. For
instance, we can imagine lazy get methods (or why not attributes) for
database access. From the users perspective, it might not matter when
things are actually fetched from the database if the Python code looks
like this:

p = myDB.getPerson(person_id) # Perhaps fetch here.
....
print p.name # Or fetch here.

It's pretty common that we avoid fetching stuff from a database until
we really need it, so accessing p.name, might well be the event that
triggers fetching all the relevant columns in the person-table for
key value person_id. That technically mutates p, but does the user
of p need to be aware of that? Maybe, maybe not. I guess it depends.
How are transactions and multi user issues handled? Will p.name lock
a database row?

While simple "warning signs" might be useful at times, I find that
the devil is in the details, and most programming problems are too
subtle to be described with an exclamation mark.

 

[bonono]

When we notice that people are fighting the language, sometimes
the best approach is to change the language so that there is
less reason to fight the language.

I think just don't "disregard the other side" without considering their
rationale is enough, and I mean the other side both way.

Which you are right, the keyword is "sometimes"

 

[Simon Brunning]

But only Guido, thinks like Guido and then even Guido may now think
differently than he thought before. And what if Guido had a bad day
when he came up with something, should we just adopt to what he
had in mind without questioning them.

No one is suggesting that Guido is perfect. But he's consistently a
better judge of language design than I am, and in all likelihood
better than you, too. If you like Python, it's 'cos you like the
decisions he's made over many years.

Where my first impulse is to think that one of decisions is wrong,
nine times out of ten in time I'll come to find that I was wrong and
he was right.