[Python-ideas] Respectively and its unpacking sentence
Sjoerd Job Postmus
sjoerdjob at sjec.nl
Wed Jan 27 13:58:22 EST 2016
On Wed, Jan 27, 2016 at 12:55:33PM -0500, Mirmojtaba Gharibi wrote:
> On Wed, Jan 27, 2016 at 2:29 AM, Andrew Barnert <abarnert at yahoo.com> wrote:
>
> For example lets say you have
> x=[1,2,3,4,5,...]
> y=['A','BB','CCC',...]
> p=[2,3,4,6,6,...]
> r=[]*n
>
> $r = str(len($y*$p)+$x)
Several (current-Python) solutions are there I can already see:
r = [str(len(yv * pv) + xv) for xv, yv, pv in zip(x, y, p)]
r = map(lambda xv, yv, pv: str(len(yv * pv) + xv), x, y, p)
# Assuming x, y, p are numpy arrays
r = np.vectorize(lambda xv, yv, pv: str(len(yv * pv) + xv))(x, y, p)
Furthermore, the `str(len(y * p) + x)` is supposed to actually do
something, I presume. Why does that not have a name? Foobarize?
r = [foobarize(xv, yv, pv) for xv, yv, pv in zip(x, y, p)]
r = map(foobarize, x, y, p)
r = np.vectorize(foobarize)(x, y, p)
or in your syntax
$r = foobarize($x, $y, $p)
I assume?
Also, supposing `f` is a function of two arguments:
$r = f(x, $y)
means
r = [f(x, y_val) for y_val in y]
And
$r = f($x, y)
means
r = [f(x_val, y) for x_val in x]
Then what does
$r = f($x, $y)
mean? I suppose you want it to mean
r = [f(x_val, y_val) for x_val, y_val in zip(x, y)]
= map(f, x, y)
which can be confusing if `x` and `y` have different lengths.
Maybe
r = [f(x_val, y_val) for x_val in x for y_val in y]
or
r = [f(x_val, y_val) for y_val in y for x_val in x]
?
Besides the questionable benefit of shorter syntax, I think this would
actually not be a good case. Numpy, list/generator comprehensions and
the map/zip builtins already provide more than enough ways to do it. Why
add even another syntax.
No, you don't have to use numpy. If you don't need it, please don't use
it. But, do not forget that the standard set of builtins is already
powerful enough to give you what you want.
Python is a general-purpose programming language (though often used in
sciency-stuff). Matlab is a 'matrix lab' language. If the language its
only purpose is working with matrices: please, go ahead and build
matrix-specific syntax.
In my experience, Python has a lot more purposes than just matrix
manipulation. Codebases I've worked on only had use for the `$` operator
you're suggesting for too little lines of code to bother learning the
extra syntax.
I'm definitively -1 on yet another syntax when there are already
multiple obvious ways to solve the same problem:(numpy, comprehensions,
map.
(not sure if I even have the right to vote here, given that I'm not a
core developer, but just giving my opinion)
>
> It would be really complex to calculate such a thing with vectorize.
> All I am saving on is basically a for-loop and the indexing. We don't
> really have to use numpy,etc. I think it's much easier to just use for-loop
> and indexing, if you don't like the syntax. So I think the question is,
> does my syntax bring enough convenience to avoid for-loop and indexing.
> For example the above could be equivalently written as
> for i in range(0,len(r)):
> ...r[i] = str(len(y[i]*p[i])+x[i])
> So that's the whole saving. Just a for-loop and indexing operator.
And I listed some of the ways you can save the loop + indexing. That
doesn't need new syntax.
>
>
>
>
> > That's everything you're asking for, with even more flexibility, with no
> > need for any new ugly perlesque syntax: just use at least one np.array type
> > in an operator expression, call a method on an array type, or wrap a
> > function in vectorize, and everything is elementwise.
> >
> > And of course when you actually _are_ using numbers, as in every single
> > one of your examples, using numpy also gives you around a 6:1 space and
> > 20:1 time savings, which is a nice bonus.
> >
> > For example:
> >
> > $StudentFullName = $FirstName + " " + $LastName
> >
> > So, in effect, I think one big part of is component wise operations.
> >
> > Another thing that can't be achieved with sequence unpacking is:
> > f($x)
> > i.e. applying f for each component of x.
> >
> >
> > That's a very different operation, which I think is more readably spelled
> > map(f, x).
> >
> > About your question above, it's not ambiguous here either:
> > a; b = x1;a + x2;5
> > is exactly "Equivalent" to
> > a = x1+x2
> > b = a + 5
> >
> > Also, there is a difference in style in sequence unpacking, and here.
> > In sequence unpacking, you have to pair up the right variables and repeat
> > the operator, for example:
> > x,y,z = x1+x2 , y1+y2, z1+z2
> > Here you don't have to repeat it and pair up the right variables, i.e.
> > x;y;z = x1;y1;z1 + x2;y2;z2
> >
> >
> > If you only have two or three of these, that isn't a problem. Although in
> > this case, it sure looks like you're trying to add two 3D vectors, so
> > maybe you should just be storing 3D vectors as instances of a class (with
> > an __add__ method, of course), or as arrays, or as columns in a larger
> > array, rather than as 3 separate variables. What could be more readable
> > than this:
> >
> > v = v1 + v2
> >
> > And if you have more than about three separate variables, you _definitely_
> > want some kind of array or iterable, not a bunch of separate variables.
> > You're worried about accidentally typing "y1-y2" when you meant "+", but
> > you're far more likely to screw up one of the letters or numbers than the
> > operator. You also can't loop over separate variables, which means you
> > can't factor out some logic and apply it to all three axes, or to both
> > vectors. Also consider how you'd do something like transposing or pivoting
> > or anything even fancier. If you've got a 2D array or iterable of
> > iterables, that's trivial: transpose or zip, etc. If you've got N*M
> > separate variables, you have to write them all individually. Your syntax at
> > best cuts the source length and opportunity for errors in half; using
> > collections cuts it down to 1.
> >
> >
More information about the Python-ideas
mailing list