Magnus Lycka <[EMAIL PROTECTED]> 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
> > l
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
Magnus Lycka <[EMAIL PROTECTED]> 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
Magnus Lycka <[EMAIL PROTECTED]> 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
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 be
[EMAIL PROTECTED] 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."
[EMAIL PROTECTED] (Alex Martelli) writes:
> Neil Hodgson <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] 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 pytho
Neil Hodgson <[EMAIL PROTECTED]> 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
Magnus Lycka wrote:
> [EMAIL PROTECTED] 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 th
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...
Ru
Magnus Lycka <[EMAIL PROTECTED]> 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 get
[EMAIL PROTECTED] wrote:
> Alex Martelli wrote:
>
>>[EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 metho
[EMAIL PROTECTED] 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 need
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 tr
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>OKB (not okblacke) wrote:
>> Fredrik Lundh wrote:
>> > [EMAIL PROTECTED] wrote:
[ ... ]
>> >> > so what would an entry-level Python programmer expect from this
>> >> > piece of code?
>> >> >
>> >> > for item in a.reverse():
>> >> > print ite
[EMAIL PROTECTED] 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
Alex Martelli wrote:
> <[EMAIL PROTECTED]> 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 f
Alex Martelli wrote:
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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
Alex Martelli wrote:
> <[EMAIL PROTECTED]> 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 f
<[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 m
Mike Meyer wrote:
> [EMAIL PROTECTED] 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
sty
Mike Meyer wrote:
> [EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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.
http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/U
"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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
OKB (not okblacke) wrote:
> Fredrik Lundh wrote:
>
> > [EMAIL PROTECTED] 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():
> >> > p
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 plac
Fredrik Lundh wrote:
> [EMAIL PROTECTED] 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 pr
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.
Fredrik Lundh wrote:
> [EMAIL PROTECTED] 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
Fredrik Lundh wrote:
> > Still don't see why even you ask it again.
>
> fyi, I'm not " [EMAIL PROTECTED] ", 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 un
> Still don't see why even you ask it again.
fyi, I'm not " [EMAIL PROTECTED] ", and I've
never, as far I know, posted from "readfreenews.net"
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik Lundh wrote:
> [EMAIL PROTECTED] 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 wa
[EMAIL PROTECTED] 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 pri
[EMAIL PROTECTED] 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'
[EMAIL PROTECTED] 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.
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 i
Fredrik Lundh wrote:
> [EMAIL PROTECTED] 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
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 i
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, s
"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??
In python 2.4, you can
"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??
In python 2.4, you can
[EMAIL PROTECTED] wrote:
> 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.
The list methods .sort() and .reverse() don't create copies,
but rather change the existing object. The reson for thi
Shi Mu <[EMAIL PROTECTED]> 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 the
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
>
46 matches
Mail list logo
