[Numpy-discussion] Release of 1.0b5 this weekend

[Charles R Harris]

Hi,

On 8/29/06, kortmann at ideaworks.com <kortmann at ideaworks.com> wrote:
>
> >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.


Maybe they should start with assembly (or mix ;) instead of C? In any case,
references are  pointer wrappers and pointers seem to be the biggest bugaboo
in C. Maybe everyone should start with Fortran where most everything was a
reference. I say "was" because the last Fortran I used was F77 and I have no
idea what the current situation is. I suppose the in/out specs make a
difference.

But then again who on this list has problems remembering things like that
> anyways right?...
> ~Kenny


Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20060829/d5545b1d/attachment-0001.html>