By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,650 Members | 812 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,650 IT Pros & Developers. It's quick & easy.

about sort and dictionary

P: n/a
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 #1
Share this Question
Share on Google+
99 Replies


P: n/a

Shi Mu wrote:
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]

most built-in function/method don't return the "object" but None. This
I believe is the language creator's preference for everything being
explicit. You better do it like this :

b.sort()
c[2].append(b)

Of course, this make things like this not possible :

obj.method_a().method_b().method_c()

But the language(and the community) in general discourage you to write
code like this ;-)

Nov 22 '05 #2

P: n/a

Shi Mu wrote:
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]

most built-in function/method don't return the "object" but None. This
I believe is the language creator's preference for everything being
explicit. You better do it like this :

b.sort()
c[2].append(b)

Of course, this make things like this not possible :

obj.method_a().method_b().method_c()

But the language(and the community) in general discourage you to write
code like this ;-)

Nov 22 '05 #3

P: n/a
Shi Mu <sa************@gmail.com> writes:
#why c can not append the sorted b??


Because sort() doesn't return anything?

According to the library reference:

7) The sort() and reverse() methods modify the list in place for
economy of space when sorting or reversing a large list. To remind you
that they operate by side effect, they don't return the sorted or
reversed list.
--
Eric Jacoboni, ne il y a 1435934131 secondes
Nov 22 '05 #4

P: n/a
Shi Mu <sa************@gmail.com> writes:
#why c can not append the sorted b??


Because sort() doesn't return anything?

According to the library reference:

7) The sort() and reverse() methods modify the list in place for
economy of space when sorting or reversing a large list. To remind you
that they operate by side effect, they don't return the sorted or
reversed list.
--
Eric Jacoboni, ne il y a 1435934131 secondes
Nov 22 '05 #5

P: n/a
Magnus Lycka wrote:
Actually, I guess it's possible that sorted() is done so
that it works like below, but I don't think pre-sorted()
versions of Python support keyword arguments to list.sort()
anyway...

def sorted(l, *p, **kw): s=l[:];s.sort(*p, **kw);return s


One part you missed, sorted is actually closer to:

def sorted(iterable, cmp=None, key=None, reverse=False):
"sorted(iterable, cmp=None, key=None, reverse=False) --> new sorted list"
s=list(iterable)
s.sort(cmp, key, reverse)
return s

The point being that while in general only a list will have a sort
method, the sorted builtin may be called on any iterable and will
return a sorted list.

Also note that it only accepts specific named arguments, and has a
docstring.
Nov 22 '05 #6

P: n/a

Magnus Lycka wrote:
sorted_l = l.sort()

and while sorted_l would contain what one might expect, it
would in fact just be another name referencing exactly the
same sorted list as l, and it would probably be surprising
that l was also sorted, and that subsequent changes would
show up in both sorted_l and l, and that sorted_l might not
be sorted and longer even though you only modified l. It's
this particular gotcha that the language creator wanted to
avoid.

Since python's '=' is just name binding and that most objects(other
than those like int/float/string?) are mutable, I don't quite
understand why this is a gotcha that is so worrying.

a = [1,2,3]
a.sorted()
b = a

even an entry level python programmer can't expect 'b' to be
unchanged(after getting the first bite may be) if there is any
operation on a later. This not only applies to list but almost all
mutable object.

As you said, if one wants a copy of an object, use copy/deepcopy or
even pickle to get a snapshot of it.

Nov 22 '05 #7

P: n/a
bo****@gmail.com wrote:
Since python's '=' is just name binding and that most objects(other
than those like int/float/string?) are mutable, I don't quite
understand why this is a gotcha that is so worrying.

a = [1,2,3]
a.sorted()
b = a

even an entry level python programmer can't expect 'b' to be
unchanged(after getting the first bite may be) if there is any
operation on a later. This not only applies to list but almost all
mutable object.


so what would an entry-level Python programmer expect from this
piece of code?

for item in a.reverse():
print item
for item in a.reverse():
print item

(as the X people used to say, the only thing worse than generalizing
from one example (sort) is generalizing from no examples at all ("let's
assume I have a use case")).

</F>

Nov 22 '05 #8

P: n/a

Fredrik Lundh wrote:
so what would an entry-level Python programmer expect from this
piece of code?

for item in a.reverse():
print item
for item in a.reverse():
print item

I would expect it to first print a in reverse then a as it was.

a=[1,2,3]

I expect it to print

3
2
1
1
2
3

As for your other comment, I don't even understand them.

Nov 22 '05 #9

P: n/a
bo****@gmail.com wrote:
so what would an entry-level Python programmer expect from this
piece of code?

for item in a.reverse():
print item
for item in a.reverse():
print item

I would expect it to first print a in reverse then a as it was.

a=[1,2,3]

I expect it to print

3
2
1
1
2
3


really? wouldn't

3
2
1
3
2
1

make a lot more sense ?

</F>

Nov 22 '05 #10

P: n/a

Fredrik Lundh wrote:
bo****@gmail.com wrote:
so what would an entry-level Python programmer expect from this
piece of code?

for item in a.reverse():
print item
for item in a.reverse():
print item

I would expect it to first print a in reverse then a as it was.

a=[1,2,3]

I expect it to print

3
2
1
1
2
3


really? wouldn't

3
2
1
3
2
1

make a lot more sense ?

I have no idea. That is my expectation. I don't know yours.

My interpretation of it is :

a got reversed then I consume it one by one
a got reversed again then I consume it one by one

Because I expect a being a mutable object, anything works on it(not
just object method, but even other functions) is by default has side
effect, unless otherwise stated, like copy/deepcopy.

Nov 22 '05 #11

P: n/a
bo****@gmail.com wrote:
so what would an entry-level Python programmer expect from this
piece of code?

for item in a.reverse():
print item
for item in a.reverse():
print item

I would expect it to first print a in reverse then a as it was.

a=[1,2,3]

I expect it to print

3
2
1
1
2
3

really? wouldn't

3
2
1
3
2
1

make a lot more sense ?

</F>

Nov 22 '05 #12

P: n/a

Fredrik Lundh wrote:
bo****@gmail.com wrote:
so what would an entry-level Python programmer expect from this
piece of code?

for item in a.reverse():
print item
for item in a.reverse():
print item

I would expect it to first print a in reverse then a as it was.

a=[1,2,3]

I expect it to print

3
2
1
1
2
3

really? wouldn't

3
2
1
3
2
1

make a lot more sense ?

Still don't see why even you ask it again. May be you can enlight me a
bit. If this is Haskell, I would expect the result you posted.

Nov 22 '05 #13

P: n/a
> Still don't see why even you ask it again.

fyi, I'm not " fr*****@pythonware-dot-com.no-spam.invalid ", and I've
never, as far I know, posted from "readfreenews.net"

</F>

Nov 22 '05 #14

P: n/a

Fredrik Lundh wrote:
Still don't see why even you ask it again.


fyi, I'm not " fr*****@pythonware-dot-com.no-spam.invalid ", and I've
never, as far I know, posted from "readfreenews.net"

I have no idea what you are talking about. I read this list through
Google's group and I saw two of the same post. Google unfortunately
just should your name "Fredrik Lundh", may be something went wrong with
the service.

Nov 22 '05 #15

P: n/a
Fredrik Lundh wrote:
bo****@gmail.com wrote:
so what would an entry-level Python programmer expect from this
piece of code?

for item in a.reverse():
print item
for item in a.reverse():
print item

I would expect it to first print a in reverse then a as it was.

a=[1,2,3]

I expect it to print

3
2
1
1
2
3

really? wouldn't

3
2
1
3
2
1

make a lot more sense ?


I am not a complete newb at python, but I am still pretty new.
I too thought immediately that the output should be 3,2,1, 1,2,3.
I used reverse() and sort() a couple time and of course read
the docs before I did. I noted they do the change inplace, and
don't find rememering that to be a terrible burden. Actually, I
get rather annoyed by the comment that they return None "as
a reminder" that the change is inplace. How arrogant! While
I'm sure the designers had kindly intentions. my memory, though
bad, is not that bad, and I object to being forced to write code
that is more clunky than need be, because the designers thought
they needed to help me with my memory.

Nov 22 '05 #16

P: n/a
Fredrik Lundh wrote:
bo****@gmail.com wrote:
> so what would an entry-level Python programmer expect from this
> piece of code?
>
> for item in a.reverse():
> print item
> for item in a.reverse():
> print item
>

I would expect it to first print a in reverse then a as it was.

a=[1,2,3]

I expect it to print

3
2
1
1
2
3


really? wouldn't

3
2
1
3
2
1

make a lot more sense ?


Yes. The unintuitive thing is that the list is sorted in place at
all.

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown
Nov 22 '05 #17

P: n/a
On Tue, 22 Nov 2005 08:53:07 -0800, rurpy wrote:
I am not a complete newb at python, but I am still pretty new.
I too thought immediately that the output should be 3,2,1, 1,2,3.
What you are saying is that a.reverse() should *both* change a in place
*and* return a reference to the same list.

I used reverse() and sort() a couple time and of course read
the docs before I did. I noted they do the change inplace, and
don't find rememering that to be a terrible burden. Actually, I
get rather annoyed by the comment that they return None "as
a reminder" that the change is inplace. How arrogant! While
I'm sure the designers had kindly intentions. my memory, though
bad, is not that bad, and I object to being forced to write code
that is more clunky than need be, because the designers thought
they needed to help me with my memory.


Built-in methods with side-effects (sort, reverse, update, clear, etc.)
return None because every function must return something, not because it
is a reminder. Python is not Pascal, and there are no procedures.

There are four possibilities for a construction like list.sort():

(1) sort the list in place and return a reference to the same list;
(2) sort the list in place and return a copy of the same list;
(3) sort the list in place and return None;
(4) don't sort in place and return a sorted list.

No solution is always right, no solution is always wrong, but the most
flexible is a combination of (3) and (4). Python now has that with sort()
and sorted(). Prior to the addition of sorted() to the language, (3) was
considered the best solution because of a simple Python principle: never
duplicate objects unless explicitly told to.
--
Steven.

Nov 22 '05 #18

P: n/a

Steven D'Aprano wrote:
There are four possibilities for a construction like list.sort():

(1) sort the list in place and return a reference to the same list;
(2) sort the list in place and return a copy of the same list;
(3) sort the list in place and return None;
(4) don't sort in place and return a sorted list.

No solution is always right, no solution is always wrong, but the most
flexible is a combination of (3) and (4). Python now has that with sort()
and sorted(). Prior to the addition of sorted() to the language, (3) was
considered the best solution because of a simple Python principle: never
duplicate objects unless explicitly told to.

I don't see the reason that (3) and (4) are the most flexible.

Again, "never duplicate objects unless explicitly told to" combined
with "=" is name binding gives me a very strong message that
list.sort() it will change things in place and which is why it is quite
natural(for me at least)

3
2
1
1
2
3

for this language. Wether it is "best" or make more sense doesn't
really matter to me, though I am curious to know why.

But basically, I just use the language as it is, and the way I want to.
So long it solves my problem and gives me the result I want.

Nov 22 '05 #19

P: n/a

OKB (not okblacke) wrote:
Fredrik Lundh wrote:
bo****@gmail.com wrote:
> so what would an entry-level Python programmer expect from this
> piece of code?
>
> for item in a.reverse():
> print item
> for item in a.reverse():
> print item
>
I would expect it to first print a in reverse then a as it was.

a=[1,2,3]

I expect it to print

3
2
1
1
2
3


really? wouldn't

3
2
1
3
2
1

make a lot more sense ?


Yes. The unintuitive thing is that the list is sorted in place at
all.

intuitive seems to be a very subjective matter, depends on once
background etc :-)

Nov 22 '05 #20

P: n/a
"Steven D'Aprano" <st***@REMOVETHIScyber.com.au> wrote in message
news:pa****************************@REMOVETHIScybe r.com.au...
On Tue, 22 Nov 2005 08:53:07 -0800, rurpy wrote:
I am not a complete newb at python, but I am still pretty new.
I too thought immediately that the output should be 3,2,1, 1,2,3.
What you are saying is that a.reverse() should *both* change a in place
*and* return a reference to the same list.


Yes. I don't see a problem with this.
I used reverse() and sort() a couple time and of course read
the docs before I did. I noted they do the change inplace, and
don't find rememering that to be a terrible burden. Actually, I
get rather annoyed by the comment that they return None "as
a reminder" that the change is inplace. How arrogant! While
I'm sure the designers had kindly intentions. my memory, though
bad, is not that bad, and I object to being forced to write code
that is more clunky than need be, because the designers thought
they needed to help me with my memory.


Built-in methods with side-effects (sort, reverse, update, clear, etc.)
return None because every function must return something, not because it
is a reminder. Python is not Pascal, and there are no procedures.


Quoting directly from the Library Reference:
"To remind you that they operate by side effect, they don't return
the sorted or reversed list."
There are four possibilities for a construction like list.sort():

(1) sort the list in place and return a reference to the same list;
(2) sort the list in place and return a copy of the same list;
(3) sort the list in place and return None;
(4) don't sort in place and return a sorted list.

No solution is always right, no solution is always wrong, but the most
flexible is a combination of (3) and (4). Python now has that with sort()
and sorted(). Prior to the addition of sorted() to the language, (3) was
considered the best solution because of a simple Python principle: never
duplicate objects unless explicitly told to.


#2 makes no sense. I see the primary difference as inplace or
copy sort, and the return value as a secondary issue:
(1) Leave orignal list alone and sort a copy. Obviously this has
to return a reference to that copy.
(2) Sort list in place and...
(2a) Don't return anything (i.e. return None)
(2b) Return a reference to the list.

(2b) is clearly the most flexible (of the inplace options) because it
subsumes option (2a) -- if is you don't want to use the returned
refernce for stylistic reasons, then don't.

I think this is just another (admittedly minor) case of Python's
designers using Python to enforce some idea of programming
style purity.

Nov 22 '05 #21

P: n/a
ru***@yahoo.com writes:
I think this is just another (admittedly minor) case of Python's
designers using Python to enforce some idea of programming
style purity.


You say that as if it were a bad thing.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Nov 23 '05 #22

P: n/a

Mike Meyer wrote:
ru***@yahoo.com writes:
I think this is just another (admittedly minor) case of Python's
designers using Python to enforce some idea of programming
style purity.


You say that as if it were a bad thing.

I would say "interesting" thing. As it seems that quite some people
don't see the language as the creator or wants them to see it.

Nov 23 '05 #23

P: n/a
Mike Meyer wrote:
ru***@yahoo.com writes:
I think this is just another (admittedly minor) case of Python's
designers using Python to enforce some idea of programming
style purity.


You say that as if it were a bad thing.


Well, there are many languages that promote a specific
style of programming and many of the ideas developed
have been incorporated in later, more general languages
to good effect.

But for a language that wants to be a general purpose
language, yea, I guess I think it's bad. A general
purpose language should strive to support as wide a
varity of styles as possible.

But this is getting rather off-topic.

Nov 23 '05 #24

P: n/a
bo****@gmail.com <bo****@gmail.com> wrote:
...
intuitive seems to be a very subjective matter, depends on once
background etc :-)


That's a strong point of Ruby, actually -- allowing an exclamation mark
at the end of a method name, which conventionally is always used to
indicate that the method is a mutator. So, you can have a.reverse [NOT
mutating a since no !] _and_ a.reverse! [mutating a]. Probably too much
of a change even for Python 3000, alas... but, it DOES make it obvious
when an object's getting mutated, and when not...
Alex
Nov 23 '05 #25

P: n/a
<ru***@yahoo.com> wrote:
...
language, yea, I guess I think it's bad. A general
purpose language should strive to support as wide a
varity of styles as possible.
Definitely NOT Python's core design principle, indeed the reverse of it.
But this is getting rather off-topic.


Yep. If you disagree so deeply with Python's foundations, other
language such as Perl, embodying just the "striving" you cherish, should
probably make you much happier.
Alex
Nov 23 '05 #26

P: n/a

Alex Martelli wrote:
<ru***@yahoo.com> wrote:
...
language, yea, I guess I think it's bad. A general
purpose language should strive to support as wide a
varity of styles as possible.


Definitely NOT Python's core design principle, indeed the reverse of it.


Priciples are fine if not carried to an extreme, as any examination
of religous or political groups will show.
But this is getting rather off-topic.


Yep. If you disagree so deeply with Python's foundations, other
language such as Perl, embodying just the "striving" you cherish, should
probably make you much happier.


There is much about Perl's rich functionality that is very worthy.
Unfortunately, as you know, it's syntax leaves a lot to be desired.

Nov 23 '05 #27

P: n/a

Alex Martelli wrote:
<ru***@yahoo.com> wrote:
...
language, yea, I guess I think it's bad. A general
purpose language should strive to support as wide a
varity of styles as possible.


Definitely NOT Python's core design principle, indeed the reverse of it.


Priciples are fine if not carried to an extreme, as any examination
of religous or political groups will show.
But this is getting rather off-topic.


Yep. If you disagree so deeply with Python's foundations, other
language such as Perl, embodying just the "striving" you cherish, should
probably make you much happier.


There is much about Perl's rich functionality that is very worthy.
Unfortunately, as you know, it's syntax leaves a lot to be desired.

Nov 23 '05 #28

P: n/a

Alex Martelli wrote:
bo****@gmail.com <bo****@gmail.com> wrote:
...
intuitive seems to be a very subjective matter, depends on once
background etc :-)


That's a strong point of Ruby, actually -- allowing an exclamation mark
at the end of a method name, which conventionally is always used to
indicate that the method is a mutator. So, you can have a.reverse [NOT
mutating a since no !] _and_ a.reverse! [mutating a]. Probably too much
of a change even for Python 3000, alas... but, it DOES make it obvious
when an object's getting mutated, and when not...

And I doubt if it should be added because of the history of python. As
that would effectively mean changing the meaning of a function because
of version, where old codes means differently for people who learn the
new syntax.

Nov 23 '05 #29

P: n/a
bo****@gmail.com wrote:
Steven D'Aprano wrote:
There are four possibilities for a construction like list.sort():

(1) sort the list in place and return a reference to the same list;
(2) sort the list in place and return a copy of the same list;
(3) sort the list in place and return None;
(4) don't sort in place and return a sorted list.

No solution is always right, no solution is always wrong, but the most
flexible is a combination of (3) and (4). Python now has that with sort()
and sorted(). Prior to the addition of sorted() to the language, (3) was
considered the best solution because of a simple Python principle: never
duplicate objects unless explicitly told to.

I don't see the reason that (3) and (4) are the most flexible.


If you only want one copy of the data, sorted, you sort
in place with (3).

If you want two copies of the data, one sorted and one
not sorted, you use solution (4).

(2) fails the "don't wastefully make a copy of data if
it isn't needed" test.

(1) is sub-optimal because it introduces a dependency
that isn't obvious. It not only modifies the list in
place, but it creates a new reference to the same list.
Expect to see lots of wasteful L = L.sort() lines by
people who forget it sorts in place. Expect to see code
like M = L.sort(); print L; print M by people who
forget that M and L are both the same sorted list.

Again, "never duplicate objects unless explicitly told to" combined
with "=" is name binding gives me a very strong message that
list.sort() it will change things in place and which is why it is quite
natural(for me at least)


Which is the behaviour of L.sort(). Did you think I was
arguing against that? Heavens no -- I think sort() as
it exists is the optimal solution. It isn't that
difficult to say M = L[:]; M.sort() when you want a
sorted copy.

Having said that, since sorted() now exists, I'll
happily use it. I just don't think it is necessary.

--
Steven.

Nov 23 '05 #30

P: n/a
bo****@gmail.com <bo****@gmail.com> wrote:
OKB (not okblacke) wrote:
Fredrik Lundh wrote:
> bo****@gmail.com wrote: [ ... ] >> > so what would an entry-level Python programmer expect from this
>> > piece of code?
>> >
>> > for item in a.reverse():
>> > print item
>> > for item in a.reverse():
>> > print item
>> >
>> I would expect it to first print a in reverse then a as it was.
>>
>> a=[1,2,3]
>>
>> I expect it to print
>>
>> 3
>> 2
>> 1
>> 1
>> 2
>> 3
> really? wouldn't
>
> 3
> 2
> 1
> 3
> 2
> 1
>
> make a lot more sense ?

Yes. The unintuitive thing is that the list is sorted in place at
all.

intuitive seems to be a very subjective matter, depends on once
background etc :-)


A quick straw-poll of some non-Pythonistas (two sysadmins, two
programmers) suggests that reversing in place is unintuitive --
all four expected:

3
2
1
3
2
1

as suggested by Fredrik. It was less clear-cut, talking through
it, whether they found sorting inplace was intuitive or not, but
it was agreed that it would be "odd" if sort() and reverse()
behaved differently. All of which is to say I'm convinced by the
current behaviour:

1. sort() in place makes sense in terms of space, and is not
completely unintuitive.
2. reverse() should do what sort() does.
3. The inexperienced user is most likely to expect the above
code to print 3 2 1 3 2 1, and is more likely to have
difficulty tracking down the problem if reverse() returns
self and they get unexpected results than if it returns
None and they get a TypeError: iteration over non-sequence.

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomež se bera eadward ofdun hlęddre heafdes bęce bump bump bump
Nov 23 '05 #31

P: n/a

Sion Arrowsmith wrote:
1. sort() in place makes sense in terms of space, and is not
completely unintuitive.
2. reverse() should do what sort() does.
3. The inexperienced user is most likely to expect the above
code to print 3 2 1 3 2 1, and is more likely to have
difficulty tracking down the problem if reverse() returns
self and they get unexpected results than if it returns
None and they get a TypeError: iteration over non-sequence.

In other words, the None is used as a "you are guranteed to get error
when you loop it, assuming you don't read the documentation and don't
do the simple trial and error in the interactive shell before doing
real thing" and would read the manual afterwards then found out
sort()/reverse() is in place.

That as a way to "teach", never thought about that kind of intend.

But isn't "develop by test" the general preference ? If that is the
case, a unit test would definitely catch the error and I doubt tracking
down the error is that hard.

Nov 23 '05 #32

P: n/a
bo****@gmail.com wrote:
Alex Martelli wrote:
bo****@gmail.com <bo****@gmail.com> wrote:
...
intuitive seems to be a very subjective matter, depends on once
background etc :-)


That's a strong point of Ruby, actually -- allowing an exclamation mark
at the end of a method name, which conventionally is always used to
indicate that the method is a mutator. So, you can have a.reverse [NOT
mutating a since no !] _and_ a.reverse! [mutating a]. Probably too much
of a change even for Python 3000, alas... but, it DOES make it obvious
when an object's getting mutated, and when not...


Except when it isn't obvious. What constitutes mutation of an object?
C++ handles this with 'const', and lets the programmer cheat by using
transient member variables, since there are cases when you actually
want to mutate objects a little, but claim that you don't...

Perhaps we need a.reverse? for just-mutating-a-little reverse as well?
;^)
Nov 23 '05 #33

P: n/a
ru***@yahoo.com wrote:
a reminder" that the change is inplace. How arrogant! While
I'm sure the designers had kindly intentions. my memory, though
bad, is not that bad, and I object to being forced to write code
that is more clunky than need be, because the designers thought
they needed to help me with my memory.
Such as being arm-twisted into writing horrible things
like x = sorted(l) instead of x = l.sort()? It sounds a
bit as if someone locked you into a cellar and forced
you to program Python, just to torture you. I guess the
next step will be the comfy armchair! ;)

Python has its roots in ABC, a language intended for
teaching programming to beginners, and it goes to great
lengths to make it easy to do things right. In my opinion,
it also avoids the mistake of introducing hurdles in a
vain attempts to prevent programmer mistakes. Such hurdles
typically lead to ugly workarounds. There are a few cases
when things don't work as some people would expect them
to work, but I think there are good resons for that.

I'm surprised that you don't complain about not being able
to do "while x = f(): ..." while you're at it. That's also
a restriction of the kind you seem to rebel against.

I'm pretty sure Guido didn't think a bit about *your*
memory capacity when he designed Python, but rather wanted
to avoid spending his and other programmers' time on helping
people with yet another set of silly bugs.
There is much about Perl's rich functionality that is very worthy.
Unfortunately, as you know, it's syntax leaves a lot to be desired.


Which is mainly a consequence of TMTOWTDI...

If you want something more perlish, but with somewhat more
sane syntax, you might want to try Ruby.
Nov 23 '05 #34

P: n/a
Magnus Lycka <ly***@carmen.se> wrote:
...
indicate that the method is a mutator. So, you can have a.reverse [NOT
mutating a since no !] _and_ a.reverse! [mutating a]. Probably too much
of a change even for Python 3000, alas... but, it DOES make it obvious
when an object's getting mutated, and when not...

Except when it isn't obvious. What constitutes mutation of an object?


"Potential alteration of the object's state". [2,2,2] -- a list with
three identical items -- may be subject to any permutation in-place,
including sorting and reversing, without _actual_ alteration of state,
just as, say, L[2]=2 MAY happen not to alter state if L[2] was already 2
before the assignment. However, such corner cases do not constitute any
deep conceptual blockage to the notion of mutation, any more than, say,
the possibility of state being empty (e.g in an empty tuple) constitues
any to the notion of state.

I classify list and dict methods as mutating and non-mutating in the
Nutshell, for example, and nobody's quibbled about their usefulness. If
you want to get more formal, you can focus on the post-condition (either
in programming-by-contract terms, or the more formal Hoare and Djikstra
ideas that preceded Pbc) using X' to mean "X as it was on entry":

for any type T,
a method M of T is said to be non-mutating iff,
for any instance t of T,
the strongest postcondition of calling M on t includes
t == t'
a method M is said to be mutating if it is not non-mutating

Note how cleanly this deals (by delegating to ==, if you will;-) with
the issue of whether 'non-observable state' (e.g. a cache) "counts" as
state (answer: if it cannot influence the result of == it does not
matter regarding this definition).

Objects which cannot be compared for equality with their peers, or for
which it is conceptually absurd to talk of "as it was", are always going
to be problematic for any system of formal reasoning about programming,
but the problem is with the formalization under such conditions (it's
hard to do most any formal reasoning without equality, for example) and
not with the pragmatics of the situation.
C++ handles this with 'const', and lets the programmer cheat by using
transient member variables, since there are cases when you actually
want to mutate objects a little, but claim that you don't...
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).

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. Anyway, a
trailing question mark is used in Ruby to indicate a predicate (a non
mutator which returns a boolean result); a convention similar to that of
exclamation for mutators, though not quite as important IMHO. I do see
some nice symmetry, supposing for example that S is a mutable string, in
being able to name some of S's methods as:

upper return an uppercased copy of S, not mutating S
upper! mutate S in-place to be uppercased
upper? return True iff S is already uppercased, not mutating S

but (maybe because I have no extensive Ruby real-life experience) the
predicate case, while nice, doesn't seem compelling to me (having to
name it, say, isupper, doesn't appear to cause practical problems).
Alex
Nov 23 '05 #35

P: n/a
bo****@gmail.com wrote:
it seems that quite some people
don't see the language as the creator or wants them to see it.


Here's my two cents on this recurring theme.

While nothing forces a particular programming style, there is some
merit to swimming with the current rather than against it. Observing
five years of newsgroup posts, I've observed that many who struggle
with language or get angry about some part of it are fighting the
language rather than using it as intended/designed.

IMO, following designer intent leads to happiness because Guido's
philosophies so thoroughly pervade the language. So, when you accept
his viewpoints, you'll find that all the parts of the language tend to
fit together neatly and easily. Conversely, fighting the language
tends to result in one struggle after the next.

For example, there is a person currently working on a new proposal for
a container freezing protocol. In order to overcome all the
fundamental difficulties (like what to do with mutable values when
freezing a dictionary), the proponent is finding that he has to suggest
pervasive changes to the language (including mutable strings, recursive
freezing protocols, mutation notifications, etc). I suspect that he is
fighting the language. It is not so much that his idea is wrong, it is
just that he is effectively creating another language that is not
Python.

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.

Keep this in mind when finding yourself madder than heck about
mylist.sort() returning None or zip(it,it) intentionally not
documenting its implementation quirks. IMO, using the tools as given
leads to easily-written, clean, maintainable, beautiful code. Learn to
love what makes Python great. Pounding a square object into a round
hole should be a cue that you're doing things the hard way ;-)

respectfully submitted,
Raymond

Nov 23 '05 #36

P: n/a
Magnus Lycka:
Except when it isn't obvious. What constitutes mutation of an object?
C++ handles this with 'const', and lets the programmer cheat by using
transient member variables, since there are cases when you actually
want to mutate objects a little, but claim that you don't...


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

There was a recent thread on this in c.l.ruby "Array#insert",
starting 8 posts down.

Neil
Nov 23 '05 #37

P: n/a
<rh********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
bo****@gmail.com wrote:
it seems that quite some people
don't see the language as the creator or wants them to see it.


Here's my two cents on this recurring theme.

While nothing forces a particular programming style, there is some
merit to swimming with the current rather than against it. Observing
five years of newsgroup posts, I've observed that many who struggle
with language or get angry about some part of it are fighting the
language rather than using it as intended/designed.

IMO, following designer intent leads to happiness because Guido's
philosophies so thoroughly pervade the language. So, when you accept
his viewpoints, you'll find that all the parts of the language tend to
fit together neatly and easily. Conversely, fighting the language
tends to result in one struggle after the next.

For example, there is a person currently working on a new proposal for
a container freezing protocol. In order to overcome all the
fundamental difficulties (like what to do with mutable values when
freezing a dictionary), the proponent is finding that he has to suggest
pervasive changes to the language (including mutable strings, recursive
freezing protocols, mutation notifications, etc). I suspect that he is
fighting the language. It is not so much that his idea is wrong, it is
just that he is effectively creating another language that is not
Python.

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.

Keep this in mind when finding yourself madder than heck about
mylist.sort() returning None or zip(it,it) intentionally not
documenting its implementation quirks. IMO, using the tools as given
leads to easily-written, clean, maintainable, beautiful code. Learn to
love what makes Python great. Pounding a square object into a round
hole should be a cue that you're doing things the hard way ;-)


I don't disagree with your points and in reality mostly follow
them. I have found out that it is easier to work with Python
than against it. And the overall results are on the plus side
of the scale (because I still use it.) You are describing the
way Python is, and saying a small change in my attitude
will make using Python easier. I am saying that a small
change in the view of Python's developer's will make Python
a better and more versatile language.

I want two things from a language -
1. Effectiveness - I want to be able to solve my programming
tasks quickly. This means good language design, rich and
powerful datatypes and language features, wide coverage
library, good documentation, etc.
2. Generality - to be able to use it in a wide range of environments
and satisfy a wide range of needs: interactive calculator,
one-off quickie programs, small task programs, large systems,
gui and command line programs, OS code,... this is a very
long list.

Python is pretty good at number 1. It is good, but less
good at #2. (The biggest limitation in #2 is it's slow runtime
performance but that is a different subject.)

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. But I do not
think (and reading c.l.p convinces me) that GvR and Python's
developers know a coding style that works best in all
situations. I 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.The sense I have with Python is a little like
I have seen in certain religious or very ideological political
groups -- "our way is the one true way". I just can't buy
that.

My reaction also results from my belief that supersetting
is good. A language that allows for writing Pythonic code
and additionally allows for writing in other styles, is better
that one the enforces a Pythonic only style because it
serves the needs of a wider audience. (Obviously it
is possible to write non-Pythonic code in Python but I see
the Python development community as trying their best to
suppress this ability.) 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. This
has the benefit of attracting more people to Python.

In practice, as I said, more often than not, I do "swallow the
pill, smile, and be happy", and write my code Pythonically
(or my best approximization of that, given my inexperience
with Python). Nevertheless, there are times when I have to
sacrifice clarity maintainability, or otherwise write in a way
that has negative costs (in my judgment) in order to do
this. There are other times when I use another language.
And I continue looking for a better language.

You say, "Pounding a square object into a round hole should
be a cue that you're doing things the hard way". But I think
that the fact that some things are "recurring theme"s should
also be a cue. :-)

I am under no illusions that I am going to convince you,
GvR, or anyone else to change your views. But at least I
tried :-)

And thanks for your thoughtful and informative response.

Nov 24 '05 #38

P: n/a

Magnus Lycka wrote:
ru***@yahoo.com wrote:
a reminder" that the change is inplace. How arrogant! While
I'm sure the designers had kindly intentions. my memory, though
bad, is not that bad, and I object to being forced to write code
that is more clunky than need be, because the designers thought
they needed to help me with my memory.
Such as being arm-twisted into writing horrible things
like x = sorted(l) instead of x = l.sort()?


The first statement is not the same as the second.
It sounds a
bit as if someone locked you into a cellar and forced
you to program Python, just to torture you. I guess the
next step will be the comfy armchair! ;)

Python has its roots in ABC, a language intended for
teaching programming to beginners, and it goes to great
lengths to make it easy to do things right. In my opinion,
"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".
it also avoids the mistake of introducing hurdles in a
vain attempts to prevent programmer mistakes. Such hurdles
typically lead to ugly workarounds. There are a few cases
when things don't work as some people would expect them
to work, but I think there are good resons for that.

I'm surprised that you don't complain about not being able
to do "while x = f(): ..." while you're at it. That's also
a restriction of the kind you seem to rebel against.
I would have but fortunately the introduction of iterators
spared you from having to read about that :-)
I'm pretty sure Guido didn't think a bit about *your*
memory capacity when he designed Python, but rather wanted
to avoid spending his and other programmers' time on helping
people with yet another set of silly bugs.
I serious doubt sort's return value of lack thereof made any
measurable difference in the time spent helping people.
There is much about Perl's rich functionality that is very worthy.
Unfortunately, as you know, it's syntax leaves a lot to be desired.


Which is mainly a consequence of TMTOWTDI...

If you want something more perlish, but with somewhat more
sane syntax, you might want to try Ruby.


Nov 24 '05 #39

P: n/a
In article <11********************@g49g2000cwa.googlegroups.c om>,
<ru***@yahoo.com> wrote:

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. But I do not think (and reading c.l.p
convinces me) that GvR and Python's developers know a coding style that
works best in all situations. I 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.The sense I
have with Python is a little like I have seen in certain religious or
very ideological political groups -- "our way is the one true way". I
just can't buy that.


Your third-to-last sentence is correct, but your second-to-last sentence
is not. The reason Python people say to use something else is precisely
because we don't believe that one-size-fits-all. Some people use other
languages in addition to Python, and some people don't use Python at all.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur." --Red Adair
Nov 24 '05 #40

P: n/a
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.
But I do not think (and reading c.l.p convinces me) that GvR and
Python's developers know a coding style that works best in all
situations.
I don't think that GvR believes he knows such a coding style,
either. I certainly don't believe it.
I do think that the Python development community believes they do,
or more accurately, that if someone wants to use a different style,
they can go use something else.
In other words, they believe that you should use a screwdriver to
drive screws, and not a hammer. You apparently disagree with them.
I think that it is possible to include in Python, things that are
non-Pythonic (such as a return value from sort()) that allow users
more stylistic freedom, without degrading the ability of those who
don't want to use such features, to write in a pure Pythonic manner.
So you think we can turn a hammer into a screwdriver without degrading
the ability to use the hammer to drive nails. The problem is, doing
this means you have a bigger, heavier hammer - which almost certainly
degrades the ability to use it as a hammer.

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

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


And why is this a benefit?

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Nov 24 '05 #41

P: n/a

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

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

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

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

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

Nov 24 '05 #42

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


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

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Nov 24 '05 #43

P: n/a

Mike Meyer wrote:
Whatever it is, trying to turn Python into a tool for dealing with it
isn't the right thing to do. Still this tone, and logic. This statement alone is right except that
it may not be what was about.
> 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. Such attempts are
pretty much doomed. They nearly inevitably producej a tool that's not
as good at what the original did as the original, and not as good at
whatever new task it's being mangledd to do as a tool that was
designed for that in the first place.

And again.
By the results of the vote, most people wanted ternary. The use
cases for it are well know. From what I recall, the debate was over
which of the many proposals should be adopted. That is not the impression I get on here. The impression I get lately
is "ternary" is bad, is hard to read, can always be done "better" with
if then else statement.
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.


Nov 24 '05 #44

P: n/a
Neil Hodgson <ny*****************@gmail.com> wrote:
Magnus Lycka:
Except when it isn't obvious. What constitutes mutation of an object?
C++ handles this with 'const', and lets the programmer cheat by using
transient member variables, since there are cases when you actually
want to mutate objects a little, but claim that you don't...


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


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

P: n/a

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". I think raymond's post more correctly described it. Rather than do
things right, it is more the "world view of python", just that it has
been pushed too far in certain situation(mostly unconciously) and
turning it into a holy war. We seem to see it every where, not just
about a programming language though.
it also avoids the mistake of introducing hurdles in a
vain attempts to prevent programmer mistakes. Such hurdles
typically lead to ugly workarounds. There are a few cases
when things don't work as some people would expect them
to work, but I think there are good resons for that.

I'm surprised that you don't complain about not being able
to do "while x = f(): ..." while you're at it. That's also
a restriction of the kind you seem to rebel against.
I would have but fortunately the introduction of iterators
spared you from having to read about that :-)

Exactly, it is the functionality, not syntax that matters.
"if-then-else" vs "then-if-else", does it really matter other than
proving one is "righter" ?
I'm pretty sure Guido didn't think a bit about *your*
memory capacity when he designed Python, but rather wanted
to avoid spending his and other programmers' time on helping
people with yet another set of silly bugs.


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

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

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

Nov 24 '05 #46

P: n/a
"bo****@gmail.com" <bo****@gmail.com> writes:
You're the one that wants to use the hammer to do whatever it is, not
me. I don't believe in silver bullets. Python is good at what it
does. If I need a different tool, I use a different tool, rather than
try and mangle a good tool into something it's not. Such attempts are
pretty much doomed. They nearly inevitably produce 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 mangled to do as a tool that was
designed for that in the first place.

And again.


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

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

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Nov 24 '05 #47

P: n/a

Mike Meyer wrote:
"bo****@gmail.com" <bo****@gmail.com> writes:
You're the one that wants to use the hammer to do whatever it is, not
me. I don't believe in silver bullets. Python is good at what it
does. If I need a different tool, I use a different tool, rather than
try and mangle a good tool into something it's not. Such attempts are
pretty much doomed. They nearly inevitably produce 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 mangled to do as a tool that was
designed for that in the first place.

And again.


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

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

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.

Nov 24 '05 #48

P: n/a
al***@mail.comcast.net (Alex Martelli) writes:
Neil Hodgson <ny*****************@gmail.com> wrote:
Ruby uses '!' not for mutation but to indicate surprising or
destructive mutation. If it was placed on all mutators, code would be
full of '!'s. '!' is less common on methods that modify the receiver
than on methods that mutate other arguments.

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


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

<mke
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Nov 24 '05 #49

P: n/a
"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.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Nov 24 '05 #50

99 Replies

This discussion thread is closed

Replies have been disabled for this discussion.