[Numpy-discussion] Release of 1.0b5 this weekend

[kortmann at ideaworks.com]

>I find it much cleaner to write

>x = foo.bar().baz(param).frob()

>than

>foo.bar()
>foo.baz(param)
>x = foo.frob()

>but perhaps others disagree.

Both of these look "clean" but i do not think that moving 3 lines to one
line makes code "cleaner"  They both do the same thing and if someone that
does not know what .bar() .baz(param) and .frob() are IMO the second
version that takes place on three lines would be easier to understand.



>I'm generally +0 on this idea (it seems like the clarity in writing
>comes largely for interactive users), and don't see much difficulty in
>separating the constructs.   On the other hand, I don't see much problem
>in returning a reference to self either.

>I guess you are worried about the situation where you write

>b = a.sort()

>and think you have a new array, but in fact have a new reference to the
>already-altered 'a'?

>Hmm..  So, how is this different from the fact that

>b = a[1:10:3] already returns a reference to 'a'

>(I suppose in the fact that it actually returns a new object just one
>that happens to share the same data with a).

>However, I suppose that other methods don't return a reference to an
>already-altered object, do they.

>Tim's argument has moved me from +0 to -0

>-Travis


I couldn't agree more with you and Tim on this.  I would rather have code
that works all the time and will not possibly confuse people later, like
the example of

>b = a.sort()
>and think you have a new array, but in fact have a new reference to the
>already-altered 'a'?

alot of people have problems grasping this "memory management" type of
programming...or at least in my C class half of the kids dropped out
because the couldnt keep track of

b = a.sort() meaning that b was actually just referencing a and if you
changed b then a was changed also.
But then again who on this list has problems remembering things like that
anyways right?...
~Kenny