Got confused by the following code: a
[6, 3, 1] b
[4, 3, 1] c
{1: [[6, 3, 1], [4, 3, 1]], 2: [[6, 3, 1]]} c[2].append(b.sort())
c
{1: [[6, 3, 1], [1, 3, 4]], 2: [[6, 3, 1], None]}
#why c can not append the sorted b?? b.sort()
b
[1, 3, 4]
Nov 22 '05
99  4560 
Mike Meyer wrote: "bo****@gmail.com" <bo****@gmail.com> writes: 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.
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. bo****@gmail.com wrote: 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 +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/ bo****@gmail.com wrote: Mike Meyer wrote:
"bo****@gmail.com" <bo****@gmail.com> writes:
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.
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.
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
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
Steve Holden wrote: bo****@gmail.com wrote: 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.
Steve Holden wrote: bo****@gmail.com wrote: Mike Meyer wrote:
"bo****@gmail.com" <bo****@gmail.com> writes:
>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.
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.
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. bo****@gmail.com wrote: Steve Holden wrote:
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.
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.
--
Ben Sizer
Op 2005-11-23, rh********@gmail.com schreef <rh********@gmail.com>: 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.
--
Antoon Pardon
Antoon Pardon wrote: 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" :-)
On 24 Nov 2005 10:21:51 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote: 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.
--
Cheers,
Simon B, si***@brunningonline.net, http://www.brunningonline.net/simon/blog/ ru***@yahoo.com wrote: "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.
Alex Martelli wrote: 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). Perhaps we need a.reverse? for just-mutating-a-little reverse as well?
;^)
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.
Op 2005-11-24, Mike Meyer schreef <mw*@mired.org>: "bo****@gmail.com" <bo****@gmail.com> writes: Mike Meyer wrote: > 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. 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.
> 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.
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.
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.
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.
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.
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.
"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
Op 2005-11-24, Simon Brunning schreef <si************@gmail.com>: On 24 Nov 2005 10:21:51 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote: 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.
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.
--
Antoon Pardon
On 24 Nov 2005 11:30:04 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote: 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.
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.
--
Cheers,
Simon B, si***@brunningonline.net, http://www.brunningonline.net/simon/blog/
Op 2005-11-24, Simon Brunning schreef <si************@gmail.com>: On 24 Nov 2005 11:30:04 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote: > 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.
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.
--
Antoon Pardon
On Thu, 24 Nov 2005 10:49:59 +0000, Simon Brunning <si************@gmail.com> wrote: On 24 Nov 2005 10:21:51 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote: 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.
You have a reservation about that other 10% ? ;-)
Regards,
Bengt Richter
On 24/11/05, Bengt Richter <bo**@oz.net> wrote: 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% ? ;-)
The other 10%, I've just not worked it out yet.
--
Cheers,
Simon B, si***@brunningonline.net, http://www.brunningonline.net/simon/blog/
Antoon Pardon <ap*****@forel.vub.ac.be> writes: 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.
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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Magnus Lycka <ly***@carmen.se> wrote:
... I think you mean volatile or mutable rather than transient? "transient"
... 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
Alex Martelli wrote: 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...
Magnus Lycka <ly***@carmen.se> writes: 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.)
--
Björn Lindström <bk**@stp.lingfil.uu.se>
Student of computational linguistics, Uppsala University, Sweden
Magnus Lycka <ly***@carmen.se> wrote: Alex Martelli wrote: 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.
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
"Mike Meyer" <mw*@mired.org> writes: ru***@yahoo.com writes: 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.
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. This has the benefit of attracting more people to Python.
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. :-) ru***@yahoo.com writes: "Mike Meyer" <mw*@mired.org> writes: ru***@yahoo.com writes: > 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.
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. > This has the benefit of attracting more people to Python.
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. :-)
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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Op 2005-11-24, Mike Meyer schreef <mw*@mired.org>: Antoon Pardon <ap*****@forel.vub.ac.be> writes: 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.
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
Op 2005-11-24, Mike Meyer schreef <mw*@mired.org>: ru***@yahoo.com writes: "Mike Meyer" <mw*@mired.org> writes: ru***@yahoo.com writes:
> 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.
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:
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. 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.
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.
--
Antoon Pardon
Antoon Pardon wrote: Op 2005-11-24, Mike Meyer schreef <mw*@mired.org>: ru***@yahoo.com writes: "Mike Meyer" <mw*@mired.org> writes:
ru***@yahoo.com writes:
> 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.
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:
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.
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.
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. bo****@gmail.com wrote: 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 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 argueit 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: import this
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!" 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
Antoon Pardon <ap*****@forel.vub.ac.be> writes: Op 2005-11-24, Mike Meyer schreef <mw*@mired.org>: Antoon Pardon <ap*****@forel.vub.ac.be> writes: 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.
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,
By who?
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.
Sometimes, such things are easy to explain, and they'll generally get
that explanation. Sometimes they aren't, so you're reduced to
pointing out similar - but more obvious - things that aren't in the
language, and "import this", and suggesting that they try it for a
while and see how it works
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"
That's essentially true. In some cases, the reasons can be explained
without understanding about python. In some cases, they can't.
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".
You're carrying things a step to far, going from explaining an overly
brief statement to imagining a motive for said statement.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Antoon Pardon <ap*****@forel.vub.ac.be> writes: 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.
And what's wrong with that? 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.
Those two statements say the same thing. Part of the Python philosphy,
from "import this", is that there should only be one obvious way to do
it. By enabling that part of Python's philosphy, you're automatically
limiting python to not allow other - specifically non-pythonic - ways
to do the same thing.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Mike Meyer <mw*@mired.org> writes: Those two statements say the same thing. Part of the Python philosphy,
from "import this", is that there should only be one obvious way to do
it. By enabling that part of Python's philosphy, you're automatically
limiting python to not allow other - specifically non-pythonic - ways
to do the same thing.
Sometimes there are zero obvious ways to do it, or an obvious way that
doesn't work, so if you want to do it at all, you have to find a
contorted way. At that point it's normal to ask why there isn't an
obvious way that works. All too often, the answer is "that would be
un-Pythonic".
Paul Rubin <http://ph****@NOSPAM.invalid> writes: Mike Meyer <mw*@mired.org> writes: Those two statements say the same thing. Part of the Python philosphy,
from "import this", is that there should only be one obvious way to do
it. By enabling that part of Python's philosphy, you're automatically
limiting python to not allow other - specifically non-pythonic - ways
to do the same thing.
Sometimes there are zero obvious ways to do it, or an obvious way that
doesn't work, so if you want to do it at all, you have to find a
contorted way. At that point it's normal to ask why there isn't an
obvious way that works. All too often, the answer is "that would be
un-Pythonic".
Examples?
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Antoon Pardon wrote: 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.
Protesting BDFL is absolutely useless by definition even if you
disagree. Tim Peters wanted generators for 10 years
<http://mail.python.org/pipermail/python-list/2001-June/050146.html>
and he has much more power of convincing Guido than you. Why do you
think your proposal should be immediately accepted?
By the way, I don't see the features you mentioned neither in
<http://svn.python.org/view/python/trunk/Doc/whatsnew/whatsnew25.tex?rev=39802&view=auto>
nor among PEPs. Perhaps they are not final?
Op 2005-11-25, Mike Meyer schreef <mw*@mired.org>: Antoon Pardon <ap*****@forel.vub.ac.be> writes: Op 2005-11-24, Mike Meyer schreef <mw*@mired.org>: Antoon Pardon <ap*****@forel.vub.ac.be> writes:
> 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.
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,
By who?
I would guess in the first place by Guido. Just look at the history
of how it finaly came to be present and IMO the only conclusion
is that Guido doesn't like a ternary operator.
Then there were those who always argued against the ternary
operator. I'm sure you can dig up some names if you go
through google groups.
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.
Sometimes, such things are easy to explain, and they'll generally get
that explanation. Sometimes they aren't,
Well maybe that are not that easy to explain because they aren't.
so you're reduced to
pointing out similar - but more obvious - things that aren't in the
language, and "import this", and suggesting that they try it for a
while and see how it works
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"
That's essentially true. In some cases, the reasons can be explained
without understanding about python. In some cases, they can't.
Which IMO makes python like a cult. The characteristic of certain
things only explainable to those who have seen the light, makes
for a view that never needs to fear being contradicted. Well
I'm sorry that I can't explain it to you, but you just don't
understand Python.
--
Antoon Pardon
Op 2005-11-25, Mike Meyer schreef <mw*@mired.org>: Antoon Pardon <ap*****@forel.vub.ac.be> writes: 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.
And what's wrong with that?
It seems a bit intollerant and contraproductive to me.
If thet would just concentrated on what they want, they could
have progressed further on that road, then where they are now,
because progress sometimes simple stops because other could
use something for what it was not intended.
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.
Those two statements say the same thing.
They are not.
Part of the Python philosphy,
from "import this", is that there should only be one obvious way to do
it.
It doesn't say that. It says:
There should be one-- and preferably only one --obvious way to do it.
Here you see the difference on emphasis. You are focussing on the
only one, while the original Python Koan seems to focus on the
there should be one.
So supose someone proposes a change that will introduce one
obvious way, to solve a particular problem. However it
introduces a second obvious way to solve an other problem
too.
I think we should accept such a proposal. It seems you and
a lot of others seem to think such proposals should be
rejected.
By enabling that part of Python's philosphy, you're automatically
limiting python to not allow other - specifically non-pythonic - ways
to do the same thing.
No it doesn't.
Supose someone proposes a change that will introduce one
obvious way, to solve a particular problem. However it introduces a
second non pythonic way to solve an other problem.
I don't think there is something wrong with accepting this
change. However it seems you do.
--
Antoon Pardon
Op 2005-11-28, Serge Orlov schreef <Se*********@gmail.com>: Antoon Pardon wrote: 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.
Protesting BDFL is absolutely useless by definition even if you
disagree. Tim Peters wanted generators for 10 years
<http://mail.python.org/pipermail/python-list/2001-June/050146.html>
and he has much more power of convincing Guido than you. Why do you
think your proposal should be immediately accepted?
I don't think that. I was just illustrating that using:
"That is unpythonic" isn't really an argument, because
things that were thought unpythonic before are now
accepted as the pythonic way.
By the way, I don't see the features you mentioned neither in
<http://svn.python.org/view/python/trunk/Doc/whatsnew/whatsnew25.tex?rev=39802&view=auto>
nor among PEPs. Perhaps they are not final?
There were people who annouced these features in this newsgroup
for version 2.5 with a rather clear titles and those from the
dev-list that frequent this newsgroup didn't protest.
Among the PEP's I see that at least PEP 308 is accepted.
So although it may not be implemented for version 2.5
a ternary operator is now an accepted as being pythonic.
--
Antoon Pardon
Op 2005-11-25, EP schreef <EP@zomething.com>:
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:
import this 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!
No, it doesn't answer anything. My impression is that the Zen of
Python gets used a lot by the python people like the bible is
used by the christions: You can always find a verse/Koan that
supports your view.
If someone comes with a pratical proposal that breaks a rule,
the proponents will cite: "practical beats purity" and
the opponents will cite: "Special cases aren't special enough
to break the rules:
And each will be convince that his view is the pythonic one.
I'm even of the impression that what is considered pythonic
or not is more related to who proposes it that to what the
proposal is and that after one has so decided the right
rules are selected to defend that decision.
--
Antoon Pardon
Antoon Pardon <ap*****@forel.vub.ac.be> writes: Op 2005-11-25, Mike Meyer schreef <mw*@mired.org>: Antoon Pardon <ap*****@forel.vub.ac.be> writes: 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. And what's wrong with that?
It seems a bit intollerant and contraproductive to me.
I suspect it seems that way because you belief two falsehoods:
Falsehood #1) There's little or no value in protecting something good.
Anyone who's seen a good thing vanish will tell you this isn't
so.
Falsehood #2) Adding things makes a language better.
This simply isn't so. Anyone who's been around computers for any
length of time has heard of featuritis. It afflicts programming
languages as well. A language with 2n features is not inherently
better than a language with n features - it's just got more
features. The 2n language may actually be less powerful.
You see, you can make languages more powerful by *removing* things
from it. Removing static typing leaves you with dynamic typing or duck
typing, both of which are more powerful than static typing. Removing
the need to explicitly free things - even though explicit is better
than implicit - means programmers don't have to worry about such, and
pretty much eliminates several classes of bugs. Removing restriction
on what you can do to an object - making them "first class" - results
in some very powerful facilities that simply don't exist in languages
where that hasn't happened. Since I've been writing Python, it's
gotten more powerful because of such removals.
If thet would just concentrated on what they want, they could
have progressed further on that road, then where they are now,
because progress sometimes simple stops because other could
use something for what it was not intended.
They know what they want. They want python to remain unbroken. Having
seen languages that have been broken to appeal to a new user
population, to appease a software vendor, and - in an extreme case -
because a drunk developer thought it was amusing, I'm *glad* that new
features are only added to Python after they've been beaten on and
thought about and in general had the implications of adding them
explored in depth by the community.
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.
Those two statements say the same thing.
They are not.
Yes, they are.
Part of the Python philosphy,
from "import this", is that there should only be one obvious way to do
it.
It doesn't say that. It says:
There should be one-- and preferably only one --obvious way to do it.
Here you see the difference on emphasis. You are focussing on the
only one, while the original Python Koan seems to focus on the
there should be one.
Wrong. There are some thing which there should *not* be a way to do.
For instance, there should not be a way to produce a segmentation
fault - which means certain features common to other languages will
never be added. We don't talk much about how you produce buffer
overfows in Python, but people have asked for that as well. Adding
ways to write hard-to-read code is frowned upon. And so on.
So supose someone proposes a change that will introduce one
obvious way, to solve a particular problem. However it
introduces a second obvious way to solve an other problem
too.
In other words, they propose a change and come up with a use case,
which is SOP.
I think we should accept such a proposal. It seems you and
a lot of others seem to think such proposals should be
rejected.
I won't speak for others, but I wouldn't reject it out of hand. You
haven't provided enough information. Accepting it just because it adds
a way to do something is wrong. First, you have to ask whether or not
that something is something we want in Python at all. Then you
consider whether how the way proposed fits with the language: is it
ugly? Is it prone to abuse? Etc. These could cause a specific proposal
to be rejected, even if the proposed facility acceptable. Then you
have to consider how it affects the rest of the language. Adding
another way to do something isn't reason to reject it out of hand, but
it's a minus. Consider whether the same end can be achieved in another
way - preferably without changing the language (Python is *very*
powerful, a you can do quite a bit with it that isn't obvious), but
see if there's some way to do this without negative side
effects. Finally, you have to consider the implementation: can it be
implemented efficiently and in such a way that it won't be confusing?
Features have been rejected at this stage - meaning if the answer
changes, they'll show up.
In summary, the design philosophy is that it's better to do without
some facility than to add it in a way that doesn't fit with the
language, and the process reflects that. This process has worked well
so far, and there's no obvious reason to think that things would
improve if it changed. Python isn't the only language that has that
kind of philosophy underlying it, and I find languages built with this
philosophy to in general be languages I enjoy writing in, even if they
have nothing else in common.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
On 2005-11-28, Mike Meyer <mw*@mired.org> wrote: Antoon Pardon <ap*****@forel.vub.ac.be> writes: Op 2005-11-25, Mike Meyer schreef <mw*@mired.org>: Antoon Pardon <ap*****@forel.vub.ac.be> writes:
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.
And what's wrong with that? It seems a bit intollerant and contraproductive to me.
I suspect it seems that way because you belief two falsehoods:
Falsehood #1) There's little or no value in protecting something good.
Anyone who's seen a good thing vanish will tell you this isn't
so.
I don't beleif this. What I do believe is, that it is better
to produce more good with those who think likewise than to
prevent those who think differently, from doing what you
think is bad.
Falsehood #2) Adding things makes a language better.
I don't believe this either.
This simply isn't so. Anyone who's been around computers for any
length of time has heard of featuritis. It afflicts programming
languages as well. A language with 2n features is not inherently
better than a language with n features - it's just got more
features. The 2n language may actually be less powerful.
You see, you can make languages more powerful by *removing* things
from it.
You cast this in way to general terms. The logic conclusion
from this statements is that the most powerfull language
is the empty language.
Removing static typing leaves you with dynamic typing or duck
typing, both of which are more powerful than static typing.
Static typing allows for some things that dynamic typing can't do.
At least not as python uses it.
Removing
the need to explicitly free things - even though explicit is better
than implicit - means programmers don't have to worry about such, and
pretty much eliminates several classes of bugs. Removing restriction
on what you can do to an object - making them "first class" - results
in some very powerful facilities that simply don't exist in languages
where that hasn't happened. Since I've been writing Python, it's
gotten more powerful because of such removals.
Well if you call eliminating restrictions, removing something from
the language I guess you can say that removing things can make
a language more powerfull. But eliminating restrictions IMO is
adding things to the language, those things that were formerly
unallowed because of the restrictions, not removing things from
the language.
If thet would just concentrated on what they want, they could
have progressed further on that road, then where they are now,
because progress sometimes simple stops because other could
use something for what it was not intended.
They know what they want. They want python to remain unbroken. Having
seen languages that have been broken to appeal to a new user
population, to appease a software vendor, and - in an extreme case -
because a drunk developer thought it was amusing, I'm *glad* that new
features are only added to Python after they've been beaten on and
thought about and in general had the implications of adding them
explored in depth by the community.
> 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.
Those two statements say the same thing.
They are not.
Yes, they are.
Part of the Python philosphy,
from "import this", is that there should only be one obvious way to do
it.
It doesn't say that. It says:
There should be one-- and preferably only one --obvious way to do it.
Here you see the difference on emphasis. You are focussing on the
only one, while the original Python Koan seems to focus on the
there should be one.
Wrong. There are some thing which there should *not* be a way to do.
For instance, there should not be a way to produce a segmentation
fault - which means certain features common to other languages will
never be added.
Then C-extentions shouldn't be allowed.
We don't talk much about how you produce buffer
overfows in Python, but people have asked for that as well. Adding
ways to write hard-to-read code is frowned upon. And so on.
Do you mean people have asked for the possibility that a buffer
overflow would overwrite other variables?
So supose someone proposes a change that will introduce one
obvious way, to solve a particular problem. However it
introduces a second obvious way to solve an other problem
too.
In other words, they propose a change and come up with a use case,
which is SOP.
I think we should accept such a proposal. It seems you and
a lot of others seem to think such proposals should be
rejected.
I won't speak for others, but I wouldn't reject it out of hand. You
haven't provided enough information. Accepting it just because it adds
a way to do something is wrong. First, you have to ask whether or not
that something is something we want in Python at all. Then you
consider whether how the way proposed fits with the language: is it
ugly?
That is a highly subjective question, answering it says more about
the person then about the proposal.
Is it prone to abuse?
I don't see why this is always brought up, given the number of
features that can be abused in python.
Etc. These could cause a specific proposal
to be rejected, even if the proposed facility acceptable. Then you
have to consider how it affects the rest of the language. Adding
another way to do something isn't reason to reject it out of hand, but
it's a minus. Consider whether the same end can be achieved in another
way - preferably without changing the language (Python is *very*
powerful, a you can do quite a bit with it that isn't obvious),
But there should be one obvious way to do things. That there are
lots of unobvious way to do the same thing thus shouldn't count
against a proposal that introduces an obvious way to do it.
but
see if there's some way to do this without negative side
effects. Finally, you have to consider the implementation: can it be
implemented efficiently and in such a way that it won't be confusing?
Features have been rejected at this stage - meaning if the answer
changes, they'll show up.
This is not the kind of rejection I'm talking about. This is a
problem of implementation, not a rejection of an idea.
In summary, the design philosophy is that it's better to do without
some facility than to add it in a way that doesn't fit with the
language, and the process reflects that.
I don't mind that a proposal is worked on and that counter-proposals
can be made. But some people just seem to counter any new proposal,
while other are more interrested in searching for ways to make
the new proposal fit the language. Now sometimes a proposal can't
be fitted and gets rejected, so be it. But maybe more could be
fitted in the langauge if more people were willing to look for
ways to fit something, instead of rejecting it simply because
the current proposal doesn't fit properly yet.
--
Antoon Pardon
Antoon Pardon <ap*****@forel.vub.ac.be> writes: You see, you can make languages more powerful by *removing* things
from it.
You cast this in way to general terms. The logic conclusion
from this statements is that the most powerfull language
is the empty language.
The only way you reach that conclusion is if you read the statement as
saying that removing things *always* makes a langauge more
powerful. That's not what I said, and that's as false as the belief
that adding things always makes a language more powerful. Wrong. There are some thing which there should *not* be a way to do.
For instance, there should not be a way to produce a segmentation
fault - which means certain features common to other languages will
never be added.
Then C-extentions shouldn't be allowed.
C-extensions aren't part of Python. We don't talk much about how you produce buffer
overfows in Python, but people have asked for that as well. Adding
ways to write hard-to-read code is frowned upon. And so on.
Do you mean people have asked for the possibility that a buffer
overflow would overwrite other variables?
Buffer overflows don't have to overwrite variables. They just asked
how you create buffer overflows in Python. I won't speak for others, but I wouldn't reject it out of hand. You
haven't provided enough information. Accepting it just because it adds
a way to do something is wrong. First, you have to ask whether or not
that something is something we want in Python at all. Then you
consider whether how the way proposed fits with the language: is it
ugly?
That is a highly subjective question, answering it says more about
the person then about the proposal.
True. But whether or not a language is good is a highly subjective
question. Since the goal - keeping python good to the people who
already consider it good - is subjective, it's only natural that part
of the evaluation process be sujectie. Is it prone to abuse?
I don't see why this is always brought up, given the number of
features that can be abused in python.
Just because Python isn't perfect is no reason to make it worse. Etc. These could cause a specific proposal
to be rejected, even if the proposed facility acceptable. Then you
have to consider how it affects the rest of the language. Adding
another way to do something isn't reason to reject it out of hand, but
it's a minus. Consider whether the same end can be achieved in another
way - preferably without changing the language (Python is *very*
powerful, a you can do quite a bit with it that isn't obvious),
But there should be one obvious way to do things. That there are
lots of unobvious way to do the same thing thus shouldn't count
against a proposal that introduces an obvious way to do it.
"Obvious" is also a subjective statement, so adding *any* other way to
do things is a minus. In summary, the design philosophy is that it's better to do without
some facility than to add it in a way that doesn't fit with the
language, and the process reflects that.
I don't mind that a proposal is worked on and that counter-proposals
can be made. But some people just seem to counter any new proposal,
while other are more interrested in searching for ways to make
the new proposal fit the language. Now sometimes a proposal can't
be fitted and gets rejected, so be it. But maybe more could be
fitted in the langauge if more people were willing to look for
ways to fit something, instead of rejecting it simply because
the current proposal doesn't fit properly yet.
The only way this would be good is if "more features" were inherently
better. That's simply not true. So the change in behavior you're
looking for isn't clearly good.
Further, if someone doesn't have a need, trying to make someone elses
need fit is largely a waste of their time, though some people -
language wonks - will do it anyway. On the other hand, pointing out
that something is bad is *not* a waste of their time, as it protects
something good. So basically, you're asking that people waste their
time on something of dubious value. Not a request that's likely to be
get very far.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
On 2005-11-29, Mike Meyer <mw*@mired.org> wrote: Antoon Pardon <ap*****@forel.vub.ac.be> writes: You see, you can make languages more powerful by *removing* things
from it. You cast this in way to general terms. The logic conclusion
from this statements is that the most powerfull language
is the empty language.
The only way you reach that conclusion is if you read the statement as
saying that removing things *always* makes a langauge more
powerful. That's not what I said,
I would say it is the common interpretation for such a sentence.
and that's as false as the belief
that adding things always makes a language more powerful.
Wrong. There are some thing which there should *not* be a way to do.
For instance, there should not be a way to produce a segmentation
fault - which means certain features common to other languages will
never be added.
Then C-extentions shouldn't be allowed.
C-extensions aren't part of Python.
As far as I understand, if you implement a class with a C-extension,
then that class is understood to be part of Python. So if you
think there should be no way to produce a segmentation fault in
python you shouldn't allow such classes. We don't talk much about how you produce buffer
overfows in Python, but people have asked for that as well. Adding
ways to write hard-to-read code is frowned upon. And so on.
Do you mean people have asked for the possibility that a buffer
overflow would overwrite other variables?
Buffer overflows don't have to overwrite variables. They just asked
how you create buffer overflows in Python.
I do wonder what they mean with a buffer overflow. Would the following
classify:
buf = range(10)
buf[10] = 10 I won't speak for others, but I wouldn't reject it out of hand. You
haven't provided enough information. Accepting it just because it adds
a way to do something is wrong. First, you have to ask whether or not
that something is something we want in Python at all. Then you
consider whether how the way proposed fits with the language: is it
ugly?
That is a highly subjective question, answering it says more about
the person then about the proposal.
True. But whether or not a language is good is a highly subjective
question. Since the goal - keeping python good to the people who
already consider it good - is subjective, it's only natural that part
of the evaluation process be sujectie.
Is it prone to abuse?
I don't see why this is always brought up, given the number of
features that can be abused in python.
Just because Python isn't perfect is no reason to make it worse.
Why is it worse. You seem to think that if one has a toolbox, which
lacks a hammer, that the fact that the hammer can be abused makes
your toolbox less usefull if you add a hammer to it.
We have a toolbox, full of equipment that can be abused, yet
that something else can be abused too, seems to be a mayor
stumbling block for adding it. In summary, the design philosophy is that it's better to do without
some facility than to add it in a way that doesn't fit with the
language, and the process reflects that.
I don't mind that a proposal is worked on and that counter-proposals
can be made. But some people just seem to counter any new proposal,
while other are more interrested in searching for ways to make
the new proposal fit the language. Now sometimes a proposal can't
be fitted and gets rejected, so be it. But maybe more could be
fitted in the langauge if more people were willing to look for
ways to fit something, instead of rejecting it simply because
the current proposal doesn't fit properly yet.
The only way this would be good is if "more features" were inherently
better. That's simply not true. So the change in behavior you're
looking for isn't clearly good.
No, this is good while there are still possible features that could make
python a better language
--
Antoon Pardon
On 30 Nov 2005 10:57:04 GMT in comp.lang.python, Antoon Pardon
<ap*****@forel.vub.ac.be> wrote: On 2005-11-29, Mike Meyer <mw*@mired.org> wrote: Antoon Pardon <ap*****@forel.vub.ac.be> writes: You see, you can make languages more powerful by *removing* things
from it.
You cast this in way to general terms. The logic conclusion
from this statements is that the most powerfull language
is the empty language.
The only way you reach that conclusion is if you read the statement as
saying that removing things *always* makes a langauge more
powerful. That's not what I said,
I would say it is the common interpretation for such a sentence.
I hope no one ever tells you that you'd be healthier if you ate less
and exercised more. (Perhaps it's not true in your case, but it
certainly is in mine.)
Regards,
-=Dave
--
Change is inevitable, progress is not.
Antoon Pardon <ap*****@forel.vub.ac.be> wrote: On 2005-11-29, Mike Meyer <mw*@mired.org> wrote: Antoon Pardon <ap*****@forel.vub.ac.be> writes: Mike Meyer wrote:
You see, you can make languages more powerful by *removing*
things from it.
You cast this in way to general terms. The logic conclusion from
this statements is that the most powerfull language is the empty
language.
The only way you reach that conclusion is if you read the
statement as saying that removing things *always* makes a langauge
more powerful. That's not what I said,
I would say it is the common interpretation for such a sentence.
You'd be wrong. "you can do X by doing foo" does not exclude "you can
do the opposite of X by doing foo".
Stating "you can make a lot of money by investing in the stock market"
does not imply that is the only possible outcome, nor even the most
likely. Just because Python isn't perfect is no reason to make it worse.
Why is it worse. You seem to think that if one has a toolbox, which
lacks a hammer, that the fact that the hammer can be abused makes
your toolbox less usefull if you add a hammer to it.
I see Mike arguing that the debate before adding the hammer is a good
thing. It ensures that only the *really* good tools -- the ones that
are so beneficial that they outweigh complicating the toolset --
actually get added; and only when they are in a form that they
overcome many objections. The only way this would be good is if "more features" were
inherently better. That's simply not true. So the change in
behavior you're looking for isn't clearly good.
No, this is good while there are still possible features that could
make python a better language
Then let's subject those possible features -- with their real use
cases and implementations -- to harsh scrutiny, over an extended time,
before deciding they'll be a net benefit.
--
\ "Unix is an operating system, OS/2 is half an operating system, |
`\ Windows is a shell, and DOS is a boot partition virus." -- |
_o__) Peter H. Coffin |
Ben Finney
Antoon Pardon <ap*****@forel.vub.ac.be> writes: On 2005-11-29, Mike Meyer <mw*@mired.org> wrote: Antoon Pardon <ap*****@forel.vub.ac.be> writes: You see, you can make languages more powerful by *removing* things
from it.
You cast this in way to general terms. The logic conclusion
from this statements is that the most powerfull language
is the empty language. The only way you reach that conclusion is if you read the statement as
saying that removing things *always* makes a langauge more
powerful. That's not what I said,
I would say it is the common interpretation for such a sentence.
You'd be wrong. "Can" denotes a possibility, not a certainty. If I'd
say "You *will* make languages more powerful by removing features",
then you'd be right. But that isn't what I said.
Wrong. There are some thing which there should *not* be a way to do.
For instance, there should not be a way to produce a segmentation
fault - which means certain features common to other languages will
never be added.
Then C-extentions shouldn't be allowed.
C-extensions aren't part of Python.
As far as I understand, if you implement a class with a C-extension,
then that class is understood to be part of Python. So if you
think there should be no way to produce a segmentation fault in
python you shouldn't allow such classes.
You understand wrong.
We don't talk much about how you produce buffer
overfows in Python, but people have asked for that as well. Adding
ways to write hard-to-read code is frowned upon. And so on.
Do you mean people have asked for the possibility that a buffer
overflow would overwrite other variables?
Buffer overflows don't have to overwrite variables. They just asked
how you create buffer overflows in Python.
I do wonder what they mean with a buffer overflow. Would the following
classify:
buf = range(10)
buf[10] = 10
Well, you'd have to ask them. Personsally, I wouldn't count that,
because no data outside the scope of buf got written to.
I won't speak for others, but I wouldn't reject it out of hand. You
haven't provided enough information. Accepting it just because it adds
a way to do something is wrong. First, you have to ask whether or not
that something is something we want in Python at all. Then you
consider whether how the way proposed fits with the language: is it
ugly?
That is a highly subjective question, answering it says more about
the person then about the proposal.
True. But whether or not a language is good is a highly subjective
question. Since the goal - keeping python good to the people who
already consider it good - is subjective, it's only natural that part
of the evaluation process be sujectie. Is it prone to abuse?
I don't see why this is always brought up, given the number of
features that can be abused in python.
Just because Python isn't perfect is no reason to make it worse.
Why is it worse. You seem to think that if one has a toolbox, which
lacks a hammer, that the fact that the hammer can be abused makes
your toolbox less usefull if you add a hammer to it.
Look again. I never said it would make Python less useful, I said it
would make it worse. Those aren't the same thing. It's possible to
make a language both more useful and worse at the same time. For
instance, Python would clearly be more useful if it could interpret
perl 6 scripts. Personally, I think adding the features required to do
that would make the language (much, much) worse. Oddly enough, I think
adding the features to Perl so it could interpret Python scripts would
make it better as well as more useful :-).
We have a toolbox, full of equipment that can be abused, yet
that something else can be abused too, seems to be a mayor
stumbling block for adding it.
"Major" is your word, not mine. I just listed it as something to
consider. It may be there's an obscure corner case that's really
abusive, but chances are no one would ever stumble over it. That's not
a major problem. On the other hand, if there's an obvious and
attractive use that's abusive, that's a reason for looking for another
way to add that functionality. In summary, the design philosophy is that it's better to do without
some facility than to add it in a way that doesn't fit with the
language, and the process reflects that.
I don't mind that a proposal is worked on and that counter-proposals
can be made. But some people just seem to counter any new proposal,
while other are more interrested in searching for ways to make
the new proposal fit the language. Now sometimes a proposal can't
be fitted and gets rejected, so be it. But maybe more could be
fitted in the langauge if more people were willing to look for
ways to fit something, instead of rejecting it simply because
the current proposal doesn't fit properly yet.
The only way this would be good is if "more features" were inherently
better. That's simply not true. So the change in behavior you're
looking for isn't clearly good.
No, this is good while there are still possible features that could make
python a better language
In that case, they're doing exactly what you want: they're making sure
that possible features make python a better language. You seem to
think they should stop doing this. I disagree.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
On 2005-11-30, Dave Hansen <id**@hotmail.com> wrote: On 30 Nov 2005 10:57:04 GMT in comp.lang.python, Antoon Pardon
<ap*****@forel.vub.ac.be> wrote:
On 2005-11-29, Mike Meyer <mw*@mired.org> wrote: Antoon Pardon <ap*****@forel.vub.ac.be> writes:
> You see, you can make languages more powerful by *removing* things
> from it.
You cast this in way to general terms. The logic conclusion
from this statements is that the most powerfull language
is the empty language.
The only way you reach that conclusion is if you read the statement as
saying that removing things *always* makes a langauge more
powerful. That's not what I said,
I would say it is the common interpretation for such a sentence.
I hope no one ever tells you that you'd be healthier if you ate less
and exercised more. (Perhaps it's not true in your case, but it
certainly is in mine.)
But that is IMO not a good analogy. A better analogy would be:
You can make persons healthier by making them eat less
and execise more.
--
Antoon Pardon
On 2005-11-30, Mike Meyer <mw*@mired.org> wrote: Antoon Pardon <ap*****@forel.vub.ac.be> writes: On 2005-11-29, Mike Meyer <mw*@mired.org> wrote: Antoon Pardon <ap*****@forel.vub.ac.be> writes:
> You see, you can make languages more powerful by *removing* things
> from it.
You cast this in way to general terms. The logic conclusion
from this statements is that the most powerfull language
is the empty language.
The only way you reach that conclusion is if you read the statement as
saying that removing things *always* makes a langauge more
powerful. That's not what I said, I would say it is the common interpretation for such a sentence.
You'd be wrong. "Can" denotes a possibility, not a certainty.
You didn't write:
Removing things can make a language more powerfull.
You wrote:
You can make a language more powerfull by removing things.
In the first case "can" describes a possible outcome of
removing things.
In the second case "can" describes that this is a decision
you are allowed and able to make. Not the possibility
of the outcomes should you make the decision.
What your sentence states is that you can make this decision and
that if you do so, removing things will accomplish this goal
If I'd
say "You *will* make languages more powerful by removing features",
then you'd be right. But that isn't what I said.
No this states that I don't have a choice in removing features or not.
Anyway that is how I read those sentences.
I just want to add that I'm not interrested in whether your
interpretation is the right one or mine. I understand now
what you meant and that is enough for meu. The above should
be considered as an explanation of how understood, not as
a correction of how yuo should have wrote it.
> We don't talk much about how you produce buffer
> overfows in Python, but people have asked for that as well. Adding
> ways to write hard-to-read code is frowned upon. And so on.
Do you mean people have asked for the possibility that a buffer
overflow would overwrite other variables?
Buffer overflows don't have to overwrite variables. They just asked
how you create buffer overflows in Python.
I do wonder what they mean with a buffer overflow. Would the following
classify:
buf = range(10)
buf[10] = 10
Well, you'd have to ask them. Personsally, I wouldn't count that,
because no data outside the scope of buf got written to.
I find this odd. You seem to argue that you don't want bufferoverflows
allowed in python, but then you don't seem to know what is meant by it.
If you don't know what they mean, how can you decide you don't want it.
And I seem to remember people asking about the possibility of overflow
in Python, but I never understood those inquiries in the sense they
would want it, but more in a sense of how python protects against it.
So I have a bit of a problem understanding the relevance here.
> I won't speak for others, but I wouldn't reject it out of hand. You
> haven't provided enough information. Accepting it just because it adds
> a way to do something is wrong. First, you have to ask whether or not
> that something is something we want in Python at all. Then you
> consider whether how the way proposed fits with the language: is it
> ugly?
That is a highly subjective question, answering it says more about
the person then about the proposal.
True. But whether or not a language is good is a highly subjective
question. Since the goal - keeping python good to the people who
already consider it good - is subjective, it's only natural that part
of the evaluation process be sujectie.
> Is it prone to abuse?
I don't see why this is always brought up, given the number of
features that can be abused in python.
Just because Python isn't perfect is no reason to make it worse.
Why is it worse. You seem to think that if one has a toolbox, which
lacks a hammer, that the fact that the hammer can be abused makes
your toolbox less usefull if you add a hammer to it.
Look again. I never said it would make Python less useful, I said it
would make it worse. Those aren't the same thing. It's possible to
make a language both more useful and worse at the same time. For
instance, Python would clearly be more useful if it could interpret
perl 6 scripts.
I disagree. Having more possibilities doesn't imply more usefull.
One of my nefews has this kind of army swiss knife with tons of
possibilities. But I find the few tools I have that total less
possibilities more usefull.
Now adding a extra possibilty to the army swiss knife may make
it worse, less usefull. Putting an extra tool in my toolbox
doesn't make it worse or less usefull, since I can just ignore
the tools I don't use.
Personally, I think adding the features required to do
that would make the language (much, much) worse. Oddly enough, I think
adding the features to Perl so it could interpret Python scripts would
make it better as well as more useful :-).
We have a toolbox, full of equipment that can be abused, yet
that something else can be abused too, seems to be a mayor
stumbling block for adding it.
"Major" is your word, not mine.
That is the impression I get from the emphasis that is always
put on abuse possibilities of a proposed addition in this
group.
I just listed it as something to
consider. It may be there's an obscure corner case that's really
abusive, but chances are no one would ever stumble over it. That's not
a major problem. On the other hand, if there's an obvious and
attractive use that's abusive, that's a reason for looking for another
way to add that functionality.
Well you said it, that's a reason for looking for another way to add
that functionality. My impression is that few people look at it
that way, but instead seem to think it a reason to simply reject the
functionality.
--
Antoon Pardon
Antoon Pardon <ap*****@forel.vub.ac.be> wrote: On 2005-11-30, Mike Meyer <mw*@mired.org> wrote: You'd be wrong. "Can" denotes a possibility, not a certainty.
You didn't write:
Removing things can make a language more powerfull.
You wrote:
You can make a language more powerfull by removing things.
In the first case "can" describes a possible outcome of removing
things.
In the second case "can" describes that this is a decision you are
allowed and able to make. Not the possibility of the outcomes should
you make the decision.
That's a distinction that exists. I don't see how it's significant
here.
Do you believe that these two statements are contradictory?
"You can make X more powerful by removing things."
"You can make X less powerful by removing things."
How about these two, do you think they're contradictory?
"You can make X more powerful by removing things."
"You can make X more powerful by adding things."
In fact, neither of those pairs are contradictory. All of them can be
truthful about the same X simultaneously.
What your sentence states is that you can make this decision and
that if you do so, removing things will accomplish this goal
No. The statement says nothing about *which* things need to be removed
to meet the goal. It doesn't say that removing *any* thing from the
language will make it more powerful.
I think this is an understandably subtle linguistic point for someone
who doesn't have English as a first language; it's ambiguous enough
that even native speakers could twist it to read more that it actually
says.
Now that you understand what Mike was trying to say, and Mike has
clarified what his statement meant, can we move on to another
argument?
I just want to add that I'm not interrested in whether your
interpretation is the right one or mine. I understand now what you
meant and that is enough for meu. The above should be considered as
an explanation of how understood, not as a correction of how yuo
should have wrote it.
An object lesson in taking programmers at their word :-)
--
\ "I went to San Francisco. I found someone's heart." -- Steven |
`\ Wright |
_o__) |
Ben Finney
Antoon Pardon <ap*****@forel.vub.ac.be> writes: >> We don't talk much about how you produce buffer
>> overfows in Python, but people have asked for that as well. Adding
>> ways to write hard-to-read code is frowned upon. And so on.
> Do you mean people have asked for the possibility that a buffer
> overflow would overwrite other variables?
Buffer overflows don't have to overwrite variables. They just asked
how you create buffer overflows in Python.
I do wonder what they mean with a buffer overflow. Would the following
classify:
buf = range(10)
buf[10] = 10 Well, you'd have to ask them. Personsally, I wouldn't count that,
because no data outside the scope of buf got written to.
I find this odd. You seem to argue that you don't want bufferoverflows
allowed in python, but then you don't seem to know what is meant by it.
If you don't know what they mean, how can you decide you don't want it.
I know what *I* mean by it, and I don't want to allow that. You asked
what someone else meant by it - I don't know that. The best I can do
is give you my take on it.
So I have a bit of a problem understanding the relevance here.
It's one of the list of things people ask about an extensions.
FWIW, that list is meant to be examples, not a definition. There are
*lots* of other things to check.
>> I won't speak for others, but I wouldn't reject it out of hand. You
>> haven't provided enough information. Accepting it just because it adds
>> a way to do something is wrong. First, you have to ask whether or not
>> that something is something we want in Python at all. Then you
>> consider whether how the way proposed fits with the language: is it
>> ugly?
> That is a highly subjective question, answering it says more about
> the person then about the proposal.
True. But whether or not a language is good is a highly subjective
question. Since the goal - keeping python good to the people who
already consider it good - is subjective, it's only natural that part
of the evaluation process be sujectie.
>> Is it prone to abuse?
> I don't see why this is always brought up, given the number of
> features that can be abused in python.
Just because Python isn't perfect is no reason to make it worse.
Why is it worse. You seem to think that if one has a toolbox, which
lacks a hammer, that the fact that the hammer can be abused makes
your toolbox less usefull if you add a hammer to it.
Look again. I never said it would make Python less useful, I said it
would make it worse. Those aren't the same thing. It's possible to
make a language both more useful and worse at the same time. For
instance, Python would clearly be more useful if it could interpret
perl 6 scripts.
I disagree. Having more possibilities doesn't imply more usefull.
You're right. But I didn't say that.
Now adding a extra possibilty to the army swiss knife may make
it worse, less usefull. Putting an extra tool in my toolbox
doesn't make it worse or less usefull, since I can just ignore
the tools I don't use.
Not true. If I put enough extra tools in your toolbox, it will
eventually get to heavy to lift. A single tool, poorly chosen - like a
band saw - could have the same effect. Personally, I think adding the features required to do
that would make the language (much, much) worse. Oddly enough, I think
adding the features to Perl so it could interpret Python scripts would
make it better as well as more useful :-). We have a toolbox, full of equipment that can be abused, yet
that something else can be abused too, seems to be a mayor
stumbling block for adding it.
"Major" is your word, not mine.
That is the impression I get from the emphasis that is always
put on abuse possibilities of a proposed addition in this
group.
Well, if they're bad enough to bring up, they probalby are major. I just listed it as something to
consider. It may be there's an obscure corner case that's really
abusive, but chances are no one would ever stumble over it. That's not
a major problem. On the other hand, if there's an obvious and
attractive use that's abusive, that's a reason for looking for another
way to add that functionality.
Well you said it, that's a reason for looking for another way to add
that functionality. My impression is that few people look at it
that way, but instead seem to think it a reason to simply reject the
functionality.
So? If they don't need the functionality, why should they look for
another way to add it? In fact, there's a fair chance they aren't
really qualified to evaluate a proposed solution in terms of adding
the proper functionality. Like I said before (or elsewhere), most
people won't bother with that, but a few language wonks will. If you
want another feature, it's up to you to propose an acceptable
mechanism to add it - or convince someone else to do it for you. If
you expect people to do work for you gratis on a regular basis, I'm
afraid you're in for a lot of dissapointment.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Raymond Arthur St. Marie II of III |
last post by:
very Very VERY dumb ? about the new Set( ) 's
Please be kind and read this like you know I've been up 33-34 hours reading
PEP's but...
Doc\ref 2.6 Delimiters show's three unused characters "@...
|
by: Marco Aschwanden |
last post by:
Hi
I don't have to talk about the beauty of Python and its clear and
readable syntax... but there are a few things that striked me while
learning Python.
I have collected those thoughts. I am...
|
by: lechequier |
last post by:
Let's say I define a list of pairs as follows:
>>l =
Can anyone explain why this does not work?
>>h = {}.update(l)
and instead I have to go:
>>h = {}
>>h.update(l)
to initialize a...
|
by: John Salerno |
last post by:
I'm a little confused. Why doesn't s evaluate to True in the first part,
but it does in the second? Is the first statement something different?
False
print 'hi'
hi
Thanks.
|
by: erik gartz |
last post by:
Hello,
I'm new to python and I'm having difficulty understanding the following
code. Why doesn't the variable a contain , ] instead. Doesn't {} allocate new memory for the
dictionary each time?...
|
by: hn.ft.pris |
last post by:
"Forward maximum match" mean that there is a dictionary contains
thousands of items which are single words. For example, "kid", "nice",
"best"...
And here get a string "kidnicebs", the forward...
|
by: Neil Chambers |
last post by:
Hi All,
I'm looking to see if it's feasible to use the SortObjectCommand
included in the Microsoft.Powershell.Commands assembly.
I have a Dictionary
Dictionary<string, intd = new...
|
by: kdt |
last post by:
Hi,
I need to perform some horrible functions in python I need to do, using sort in a similar way that Excel can.
With a dictionary like:
>>> d
{8: (99, 99), 9: , 4: , 5: (67, 77)}
I...
|
by: Hilton |
last post by:
Hi,
for (int i = 0; i < list.Count; i++)
has a hidden performance hit; i.e. list.Count gets evaluated each time, so
we write something like:
int listCount = list.Count;
for (int i = 0; i <...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |
