about sort and dictionary

[Magnus Lycka]

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

"This hammer is stupid. It's very uncomfortable, and
it's not hard and heavy enough to get the nails into
the wall."

"It will work better if you hold it in the other end."

"Don't tell me how to hold my hammer. It's just built
wrong. This cold and hard thing should be in the other
end!"

;^)

Seriously, it's not a matter of right or wrong. It's
a matter of trying to understand how a tool is intended
to be used, and to adjust to that. I'm not saying that
all Python programmers should be some kind of Guido
clones, there's plenty of room for variation, but it
usually pays to be adaptable. Python fits my brain.
I felt that from the start. YMMV.

 

[Antoon Pardon]

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


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.

Why do you use the word "mangle" here? I'll come to this again later.

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.


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.

No it wasn't. From what I have picked up, the ternary operator
was finaly introduced after one of the developers tripped over
the commonly used idiom to simulate a ternary operator, which
can fail in certain cases.

Anyway, when I was arguing for a ternary operator in python,
those who opposed me, certainly gave me the impression that
they thought I wanted to mangle the language, the mere idea
of a ternary operator was against the spirit of python.

When I argued for a more general loop construct similar
objections were made and the proposal was fiercely fought.
Someone even started a PEP, with the intention to bury
the idea. (That can be from before I argued for it)

Now I have read about both that they will be introduced in
Python 2.5 without a whisper of protest.

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.

"That is not the Python way", is just saying "Python doesn't have it"
in other words. So it can't be the answer to why python can't have
something.

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.

The python way is something that changes continuously. What is the
python way now certainly wasn't the python way with version 1.5
(when I started).

So "That is not the python way" doesn't answer the question why
it couldn't be the python way.

 

[Antoon Pardon]

No one is suggesting that Guido is perfect.

I disagree. They may not do so directly, but if each time a language
change is suggested, someone answer that this is not Guido thinks
about it or something similar, then Guido is certainly presented
as the standard with which to compare. Putting al those responses
toghether suggests 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.

So, that makes that about a lot of things we think alike. Remains
the question about whose ideas are better about the things we
disagree.

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.

When I first came to python, I almost immediatly thought a number
of things would improve the language. A number of them are
already implemented or seem to be scheduled for 2.5. I'm not
going to argue that that makes me a better language designer
than Guido, but it does seem to be an indication I'm not that
bad.

 

[Simon Brunning]

So, that makes that about a lot of things we think alike. Remains
the question about whose ideas are better about the things we
disagree.

It might remain for *you* to see the answer to that question. I susp
ect that most of us have answered it to our own satisfaction long since.

 

[Antoon Pardon]

It might remain for *you* to see the answer to that question. I susp
ect that most of us have answered it to our own satisfaction long since.

<Shrug> There was a time that Guido and I disagreed about the ternary
operator. I'm sure people then also answered the question who of us was
wrong to their satisfaction. In the mean time Guido seems to have
changed his mind.

The way it looks to me right now, is that python is evolving the way
I like it to evolve, even if newsgroup members in general oppose those
ideas when I defend them in the newsgroup.

 

[Bengt Richter]

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.

You have a reservation about that other 10% ? ;-)

Regards,
Bengt Richter

 

[Simon Brunning]

You have a reservation about that other 10% ? ;-)

The other 10%, I've just not worked it out yet.

 

[Mike Meyer]

"That is not the Python way", is just saying "Python doesn't have it"
in other words. So it can't be the answer to why python can't have
something.

No, it isn't. At least, it isn't when I use it. A language is more
than just an accumulation of features. Well, a good language is more
than just an accumulation of features - there's a philosophy
underlying the language, that guides what features are added and what
features aren't. Other languages have other philosophies, and wind up
being good for other things.

When I say "That's not the Python way", I mean that such a feature
runs counter to my vision of Python's underlying philosophy. My vision
isn't perfect - I've changed my mind about things: I used to want real
macros, and I initially disliked list comprehensions. My vision
doesn't agree with the developers - notably including Guido's - a lot
of the time. On the other hand, they haven't done anything that
strikes me as so wrong that I want to spend the time required working
on Python rather than in Python to allow me to get it fixed.

<mike

 

[Alex Martelli]

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

Heh, you're welcome. Hadn't done anything much with C++ for almost five
years, but found out (to my surprise, wouldn't have predicted it!) that
it all comes back to me effortlessly (I might put it down to working
with Matt Austern, but what we did together at Google wasn't C++...;-).
My _perl_, OTOH, *has* gone all fuzzy... go figure! (Guess I have a
C++-shaped mind rather than a perl-shaped one, FWIW.

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

Sure, caching and "just in time" computation are common. That is
basically the difference between interface and implementation, and the
distinction in C++ between "logically const" and "physically const" (but
that doesn't really work right, either, for different reasons).

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.

"Problems", yes; method names, not necessarily. Being able to assert
that X==X' (using the X' notation to mean "X before the call") does have
expressive power; this leaves all the needed leeway to change
implementation as long as it touches "hidden" state only. Thread safety
and atomicity are really quite different issues, just like for any class
invariant. If there's a class invariant P(), that means that P(X')
[before the call] and P(X) [after it] both hold, but the word
"invariant" does *NOT* mean that P holds "invariably" DURING the
execution of X's methods, so class invariants cannot be used to infer
threadsafety, much less atomicity -- that would constrain the
implementation of the method WAY too much in the general case.
(_Callbacks_ from a method to generic callables passed from the outside
can be a headache -- there's no general theory as to what should hold
while an external callback executes... though I'm in the camp claiming
that invariants SHOULD hold at that time, I understand the debate).

I don't think these headaches and difficulties justify dumping the whole
field of reasoning about programs, nor the subfield of PbC. The concept
of "immutable" is really just a tiny corner of these fields, and it's a
long way from being the hardest or most problematic one in them;-).


Alex

 

[Magnus Lycka]

I don't think these headaches and difficulties justify dumping the whole
field of reasoning about programs, nor the subfield of PbC. The concept
of "immutable" is really just a tiny corner of these fields, and it's a
long way from being the hardest or most problematic one in them;-).

Agreed. I also think that it's good practice to make methods do *one*
thing, so when methods grow into both changing state and returning
some substantial value, I usually split them. While the distinction
between "functions" and "procedures" to speak Pascalese is a useful
guidline at times, it's still a generalization though, and I doubt
that it's very useful to have a syntactic marker for this distinction
such as e.g. Pascal has.

As I understand it, Ruby's "!" isn't quite like "procedure" in Pascal,
or "not const" in C/C++, but rather a marker for surprising behaviour,
and while it might be wise to acknowledge that not all APIs are
perfect, it seems difficult to know where mutating behaviour will
surprise users. It seems to me that different programmers have
different expectations on such things, and stumble over completely
different things...

 

[Guest]

As I understand it, Ruby's "!" isn't quite like "procedure" in Pascal,
or "not const" in C/C++, but rather a marker for surprising behaviour,

In my experience, ! is used in Ruby much the same way as it is in
Scheme, signifying that a method/function is called only for side
effects. (Similar to a void function in C.)

 

[Alex Martelli]

Agreed. I also think that it's good practice to make methods do *one*
thing, so when methods grow into both changing state and returning
some substantial value, I usually split them. While the distinction
between "functions" and "procedures" to speak Pascalese is a useful
guidline at times, it's still a generalization though, and I doubt
that it's very useful to have a syntactic marker for this distinction
such as e.g. Pascal has.

The distinction is theoretically nice, but pragmatically it can get in
your way when a result is a "natural side effect" of the state change.

As a (perhaps overly) simple example, heapq.heapreplace is very natural
for some use cases of heaps as priority queues, and frequent enough that
having to replace it throughout with
result = heapq.heappop...
heapq.heappush...
return result
would be mildly annoying. At the other extreme, if Queue.Queue.get
couldn't BOTH alter queue state (remove one item) AND return the removed
item, within one threadsafe ("atomic") operation, that would be way more
than just annoying... it would just about destroy the usefulness of
Queue.Queue!


Alex

 

[rurpy]

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.

No, the analogy is more like this. Python is hammer that comes
in green or blue. The hammer's developers say (perhaps with
some reason) that cool colors like green and blue are the best
colors because they promote calm when used. Calm hammerers
are more productive and less violent. My work is
repairing the inside of dark water tanks. It is hard to see blue
and green hammers, and to find them if I put them down.
I suggest that Python have the option of red hammers. The
Python people respond with horror, pointing out the problems
with red hammers. I say that I am a calm person already,
that I know how to use red hammers safely, but of course
the Python people don't want anything to do with the idea.
"What will happen if your red hammer falls into the hands of
a beginner?" they ask. (I note that although the hammer does
have a lot of safety features, it is still easy to poke an eye out
with the nail remover if one is not careful.) They also point
out that adding a third color will cost time and effort. And
the problems of deciding if the hammer should really be
red, or maybe orange would be better. So they tell me to go
use a red screwdriver.

Regarding the differences between hammers and screwdrivers...
When a screwdriver is appropriate I use a screwdriver. If I
need to write code that does a large amount of CPU intensive
number crunching, I use C, not Python.

But suppose someone came up with a Python compiler. It
would compile any Python program but there would be no
speed benefit unless you carefully wrote the code to not use
many of Python's dynamic features, so that either by type
inferencing or programmer supplied static declarations, the
compiler could generate efficient native machine code
that executes at near C speeds.
Obviously this would require changes (mostly additions?)
to the Python language, though these changes would still
allow today's style dynamic code to be written and run
(though just as slow as today's runs).
The payout would be that things written as C-extensions
today, would be writable in (a restricted form of) Python.
Would the Python orthodoxy favor such a development?
Or would that be turning Python into a screwdriver?

To me, it would be better because I can now do with a
hammer, many of the things I used to do with a screw-
driver. I can spend more time becoming a better hammerer,
and less time learning the intricacies of screwdrivers.
My life is better.

And why is this a benefit?

More eyeballs to find bugs. More hands to make improvements.
More minds to make suggestions. More hearts to share the joy.

 

[Mike Meyer]

No, the analogy is more like this. Python is hammer that comes
in green or blue. The hammer's developers say (perhaps with
some reason) that cool colors like green and blue are the best
colors because they promote calm when used. Calm hammerers
are more productive and less violent. My work is
repairing the inside of dark water tanks. It is hard to see blue
and green hammers, and to find them if I put them down.
I suggest that Python have the option of red hammers.

So you're suggesting a fundamental change to the nature of
Python. It's inherently a blue/green language. Making it available in
Red violates the spirit and philosphy of the language, which is why:

The Python people respond with horror, pointing out the problems
with red hammers.

In other words, there are reasons that python doesn't come in red, and
they will gladly tell you what they are.

Regarding the differences between hammers and screwdrivers...
When a screwdriver is appropriate I use a screwdriver. If I
need to write code that does a large amount of CPU intensive
number crunching, I use C, not Python.

Yes. And if you need a red hammmer, you should get a red hammer, not
use red spray paint on one that wasn't designed to be red. Just
because *you* don't see how providing a red option violates the
philosophy of python doesn't mean that it doesn't do so.

More eyeballs to find bugs. More hands to make improvements.
More minds to make suggestions. More hearts to share the joy.

More people to try and turn the hammer into a screwdriver, more people
to insist that the bike shed be red, etc. If popularity were inherently
a good thing, I'd be writing VB on Windows.

<mike

 

[Antoon Pardon]

No, it isn't. At least, it isn't when I use it. A language is more
than just an accumulation of features. Well, a good language is more
than just an accumulation of features - there's a philosophy
underlying the language, that guides what features are added and what
features aren't. Other languages have other philosophies, and wind up
being good for other things.

But how this philosophy influences design is not straight forward.

The ternary operator was thought of to go against the philosopy,
and now seems to be at least compatible with the philosophy.

So when someone asks why it is not in python, saying "It is not
the python way" still doesn't answer the question, because the
person would probably still like to know what in his proposal
is against the python philosophy and why.

When I say "That's not the Python way", I mean that such a feature
runs counter to my vision of Python's underlying philosophy.

Fine, but it would help if you could support this with arguments
or at least give an explanation of why you think this is so.

My vision
isn't perfect - I've changed my mind about things: I used to want real
macros, and I initially disliked list comprehensions. My vision
doesn't agree with the developers - notably including Guido's - a lot
of the time. On the other hand, they haven't done anything that
strikes me as so wrong that I want to spend the time required working
on Python rather than in Python to allow me to get it fixed.

I see nothing wrong with that. But I would apreciate it, should
you be more open about something being your personal vision.
To me something like: "That is not the python way" comes accross
as: "You just don't understand about python, if you ask/propose
something like that" It gives me the feeling the person is
saying something like: "Python is like this, I like it this
way, so nobody better suggests this changes".

 

[Antoon Pardon]

So you're suggesting a fundamental change to the nature of
Python. It's inherently a blue/green language. Making it available in
Red violates the spirit and philosphy of the language, which is why:

Well this is, is one thing I have a problem with.

The python people seem to be more concerned with fighting things
that could be used counter the python philosophy, than search for
things that enable working in the python philosophy.

Why did it take so long before a ternary operator was introduced?
Because it was thought it could be too easily abused. The fact
that there was also good use for a ternary operator within the
spirit of Python was regarded as less important.

In other words, there are reasons that python doesn't come in red, and
they will gladly tell you what they are.


Yes. And if you need a red hammmer, you should get a red hammer, not
use red spray paint on one that wasn't designed to be red. Just
because *you* don't see how providing a red option violates the
philosophy of python doesn't mean that it doesn't do so.

Well this seems to be the main conflict between those who would
like Python to go a bit further and those that oppose it.

Should the priority be to enable python's philosophy or should
it be the priority to limit python to only allow it's philosophy.

One groups seems to think that python's spirit is not broken
by allowing things that seem counter to it, as long as people
can without much trouble, work within that spirit.

An other group seems to think that any allowance to disgress
from python's spirit is an assault on it.

 

[bonono]

Well this is, is one thing I have a problem with.

The python people seem to be more concerned with fighting things
that could be used counter the python philosophy, than search for
things that enable working in the python philosophy.

Why did it take so long before a ternary operator was introduced?
Because it was thought it could be too easily abused. The fact
that there was also good use for a ternary operator within the
spirit of Python was regarded as less important.


Well this seems to be the main conflict between those who would
like Python to go a bit further and those that oppose it.

Should the priority be to enable python's philosophy or should
it be the priority to limit python to only allow it's philosophy.

One groups seems to think that python's spirit is not broken
by allowing things that seem counter to it, as long as people
can without much trouble, work within that spirit.

An other group seems to think that any allowance to disgress
from python's spirit is an assault on it.

And exactly what is "python's spirit/philosophy" ? It seems to me that
they are often used in a liberal way, just to support one's argument
that whatever is not in the CURRENT python should not be there.

 

[Paul Boddie]

And exactly what is "python's spirit/philosophy" ? It seems to me that
they are often used in a liberal way, just to support one's argument
that whatever is not in the CURRENT python should not be there.

Yes, those contentious terms "pythonic" and "unpythonic" which, as
someone recently pointed out, appear to be convenient tools to
respectively label one's own work as acceptable and someone else's work
as deficient.

I certainly don't have much time for people who, after the most cursory
inspection of Python, proclaim that it is substandard for not having
static typing or for employing indentation to organise source code, but
I do believe that people shouldn't be given the brush-off on more
subtle topics by some "Zen of Python" remark (probably not even
supported by the classic Tim Peters text). It should be noted that Zope
eventually experienced something of a backlash by encouraging such a
culture of obscure wisdom, and sometimes Python risks experiencing some
of the same. More documentation, explanation and objective discussion
help to bring the newcomer to understanding, rather than alienating
them with some kind of opaque, elitist retort which gives them no clue
as to how they may reach such understanding.

Paul

 

[EP]

Should the priority be to enable python's philosophy or should
it be the priority to limit python to only allow it's philosophy.

One groups seems to think that python's spirit is not broken
by allowing things that seem counter to it, as long as people
can without much trouble, work within that spirit.

An other group seems to think that any allowance to disgress
from python's spirit is an assault on it.

This seems to assume a background philosophy of TMTOWTDI

versus

YWKTMTOWTDIBIPFCEMS = "".join(["Yes we know","TMTOWTDI","But in Python fewer choices equals more simplicity")


"There should be one-- and preferably only one --obvious way to do it."

"Although that way may not be obvious at first unless you're Dutch."


Maybe what makes Python most different is its philosophy; I would not argue it is the ultimate philosophy --- I could not embrace a government which held such views --- it is nothing like Democratic --- but the people in Pythonia tend to be fairly nice, and the tax rate is outstandingly low. Of course that's silly, Python is a tool, not a country. Python's philosophy, however, seems to run counter to adding a phillips head, flat head, and hex head screwdriver blade to its hammer.

In life and society I hope we embrace a great multiplicity of perspectives and lifestyles. This, however, is not that.

What is the philosophy? I'm not the one to answer that, but I do use "import this" for reference, and it seems to answer some of the points in this thread:
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

EP

"Criminy, I didn't realize that drat ternary operator was going to creep in.. Ugh. Drat, drat, drat!"

 

[Bryan]

But suppose someone came up with a Python compiler. It
would compile any Python program but there would be no
speed benefit unless you carefully wrote the code to not use
many of Python's dynamic features, so that either by type
inferencing or programmer supplied static declarations, the
compiler could generate efficient native machine code
that executes at near C speeds.
Obviously this would require changes (mostly additions?)
to the Python language, though these changes would still
allow today's style dynamic code to be written and run
(though just as slow as today's runs).
The payout would be that things written as C-extensions
today, would be writable in (a restricted form of) Python.
Would the Python orthodoxy favor such a development?
Or would that be turning Python into a screwdriver?

i agree with you... pyrex should be part of the python distribution

bryan