Re: [Python-ideas] List indexing multiple elements

[David Mertz]

On Mon, Feb 20, 2017 at 12:54 PM, Ryan Gonzalez  wrote:

> elements = [mylist[a], mylist[b]]
> - Right now, a[b,c] is already valid syntax, since it's just indexing a
> with the tuple (b, c). The proposal is to make this a specialization in the
> grammar, and also allow stuff like a[b:c, d:e] (like
> `a.__getitem__(slice(b, c), slice(d, e))`).
>

This part is DOA.  As someone else notes, use of tuples as indexers is
commonplace in NumPy (and Pandas, XArray, Dask, etc).  In those collection
types, the comma refers to dimensions of the data.

However, as someone else notes, you can create whatever meaning you want
for indexing with a tuple.  I think it would be confusing to give a meaning
very different from that in NumPy; but it's perfectly syntactical.

class MultisliceList(list):
def __getitem__(self, arg):
if isinstance(arg, int) or isinstance(arg, slice):
return list.__getitem__(self, arg)
elif isinstance(arg, tuple):
indices = set()
for x in arg:
if isinstance(x, int):
indices.add(x)
elif isinstance(x, slice):
for i in range(x.start or 0, x.stop, x.step or 1):
indices.add(i)
else:
raise NotImplementedError("Can only index with ints and
slices")
else:
raise NotImplementedError("Can only index with ints and slices")

return MultisliceList([list.__getitem__(self, i) for i in
sorted(indices)]))

>>> l = MultisliceList(range(1000,0,-5))
>>> l[10:15], type(l[10:15])

([950, 945, 940, 935, 930], list)

>>> l[9], type(l[9])

(955, int)

>>> msl = l[9,110:115,10:15,100]
>>> msl, type(msl)

([955, 950, 945, 940, 935, 930, 500, 450, 445, 440, 435, 430],
 __main__.MultisliceList)



I decided that the various index positions indicated should be in sorted
order (there might be overlap in tuple items).  Also I didn't make a single
slice stay as the special class. You can write your version however you
like.

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Delayed Execution via Keyword

[Joshua Morton]

This comes from a bit of a misunderstanding of how an interpreter figures
out what needs to be compiled. Most (all?) JIT compilers run code in an
interpreted manner, and then compile subsections down to efficient machine
code when they notice that the same code path is taken repeatedly, so in
pypy something like

x = 0
for i in range(10):
x += 1

would, get, after 10-20 runs through the loop, turned into assembly that
looked like what you'd write in pure C, instead of the very indirection and
pointer heavy code that such a loop would be if you could take it and
convert it to cpython actually executes, for example. So the "hot" code is
still run.

All that said, this is a bit of an off topic discussion and probably
shouldn't be on list.

What you really do want is functional purity, which is a different concept
and one that python as a language can't easily provide no matter what.

--Josh

On Mon, Feb 20, 2017 at 7:53 PM Abe Dillon  wrote:

> On Fri, Feb 17, 2017, Steven D'Aprano wrote:
>
> JIT compilation delays *compiling* the code to run-time. This is a
> proposal for delaying *running* the code until such time as some other
> piece of code actually needs the result.
>
>
> My thought was that if a compiler is capable of determining what needs to
> be compiled just in time, then an interpreter might be able to determine
> what expressions need to be evaluated just when their results are actually
> used.
>
> So if you had code that looked like:
>
> >>> log.debug("data: %s", expensive())
>
> The interpreter could skip evaluating the expensive function if the result
> is never used. It would only evaluate it "just in time". This would almost
> certainly require just in time compilation as well, otherwise the byte code
> that calls the "log.debug" function would be unaware of the byte code that
> implements the function.
>
> This is probably a pipe-dream, though; because the interpreter would have
> to be aware of side effects.
>
>
>
> On Mon, Feb 20, 2017 at 5:18 AM,  wrote:
>
>
>
> > -Original Message-
> > From: Python-ideas [mailto:python-ideas-bounces+tritium-
> > list=sdamon@python.org] On Behalf Of Michel Desmoulin
> > Sent: Monday, February 20, 2017 3:30 AM
> > To: python-ideas@python.org
> > Subject: Re: [Python-ideas] Delayed Execution via Keyword
> >
> > I wrote a blog post about this, and someone asked me if it meant
> > allowing lazy imports to make optional imports easier.
> >
> > Someting like:
> >
> > lazy import foo
> > lazy from foo import bar
> >
> > So now if I don't use the imports, the module is not loaded, which could
> > also significantly speed up applications starting time with a lot of
> > imports.
>
> Would that not also make a failure to import an error at the time of
> executing the imported piece of code rather than at the place of import?
> And how would optional imports work if they are not loaded until use?
> Right
> now, optional imports are done by wrapping the import statement in a
> try/except, would you not need to do that handling everywhere the imported
> object is used instead?
>
> (I haven't been following the entire thread, and I don't know if this is a
> forest/tress argument)
>
> > ___
> > Python-ideas mailing list
> > Python-ideas@python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Delayed Execution via Keyword

[Abe Dillon]

On Fri, Feb 17, 2017, Steven D'Aprano wrote:

> JIT compilation delays *compiling* the code to run-time. This is a
> proposal for delaying *running* the code until such time as some other
> piece of code actually needs the result.


My thought was that if a compiler is capable of determining what needs to
be compiled just in time, then an interpreter might be able to determine
what expressions need to be evaluated just when their results are actually
used.

So if you had code that looked like:

>>> log.debug("data: %s", expensive())

The interpreter could skip evaluating the expensive function if the result
is never used. It would only evaluate it "just in time". This would almost
certainly require just in time compilation as well, otherwise the byte code
that calls the "log.debug" function would be unaware of the byte code that
implements the function.

This is probably a pipe-dream, though; because the interpreter would have
to be aware of side effects.



On Mon, Feb 20, 2017 at 5:18 AM,  wrote:

>
>
> > -Original Message-
> > From: Python-ideas [mailto:python-ideas-bounces+tritium-
> > list=sdamon@python.org] On Behalf Of Michel Desmoulin
> > Sent: Monday, February 20, 2017 3:30 AM
> > To: python-ideas@python.org
> > Subject: Re: [Python-ideas] Delayed Execution via Keyword
> >
> > I wrote a blog post about this, and someone asked me if it meant
> > allowing lazy imports to make optional imports easier.
> >
> > Someting like:
> >
> > lazy import foo
> > lazy from foo import bar
> >
> > So now if I don't use the imports, the module is not loaded, which could
> > also significantly speed up applications starting time with a lot of
> > imports.
>
> Would that not also make a failure to import an error at the time of
> executing the imported piece of code rather than at the place of import?
> And how would optional imports work if they are not loaded until use?
> Right
> now, optional imports are done by wrapping the import statement in a
> try/except, would you not need to do that handling everywhere the imported
> object is used instead?
>
> (I haven't been following the entire thread, and I don't know if this is a
> forest/tress argument)
>
> > ___
> > Python-ideas mailing list
> > Python-ideas@python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] List indexing multiple elements

[Paul Moore]

On 20 February 2017 at 20:54, Ryan Gonzalez  wrote:
> Apologies if this has already been covered!
>
> Right now, if you want to get multiple elements in a list, you have to do:
>
> elements = [mylist[a], mylist[b]]
>
> My proposal is two-folded:
>
> - Right now, a[b,c] is already valid syntax, since it's just indexing a with
> the tuple (b, c). The proposal is to make this a specialization in the
> grammar, and also allow stuff like a[b:c, d:e] (like `a.__getitem__(slice(b,
> c), slice(d, e))`).

I'm not sure what you mean by a "specialisation in the grammar". This
is currently valid syntax. It's only list.__getitem__ that rejects it:

>>> lst[4:5,6]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: list indices must be integers or slices, not tuple

That error comes from lst.__getitem__, not from the grammar.

> - Add support for indexing via tuples in list.__getitem__.
> list.__getitem__(tuple) would roughly be equivalent to map(list.__getitem__,
> tuple).
>
> The first part is solely so that slices would be allowed in the syntax, but
> if you guys don't like the idea, the second part still stands.

But they already are...

> Thoughts? *ducks from flying tomatoes*

Thoughts on the second path, then.

I presume you're aware this can be done right now using a helper
function. And indeed you point out yourself that it's basically
map(lst.__getitem__, seq). So I guess the key question is what
*additional* benefit do you see to this proposal that justifies adding
it to the builtin list type *now*, when people have managed fine this
far without it.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] List indexing multiple elements

[Ivan Levkivskyi]

On 20 February 2017 at 22:05, Jonathan Goble  wrote:

> On Mon, Feb 20, 2017 at 3:55 PM Ryan Gonzalez  wrote:
>
>> - Right now, a[b,c] is already valid syntax, since it's just indexing a
>> with the tuple (b, c). The proposal is to make this a specialization in the
>> grammar, and also allow stuff like a[b:c, d:e] (like
>> `a.__getitem__(slice(b, c), slice(d, e))`).
>>
>
> The syntax/grammar already permits slices to be used in this fashion:
>

Moreover, this syntax is already extensively used by numpy and means
something different - multidimensional slicing.
Having a different semantics for lists would be therefore confusing.

--
Ivan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] List indexing multiple elements

[Jonathan Goble]

On Mon, Feb 20, 2017 at 3:55 PM Ryan Gonzalez  wrote:

> - Right now, a[b,c] is already valid syntax, since it's just indexing a
> with the tuple (b, c). The proposal is to make this a specialization in the
> grammar, and also allow stuff like a[b:c, d:e] (like
> `a.__getitem__(slice(b, c), slice(d, e))`).
>

The syntax/grammar already permits slices to be used in this fashion:

Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class Tester:
...   def __getitem__(self, *args):
... print('object was indexed with these args:', args)
...
>>> obj = Tester()
>>> obj[3:5, 2:6, 7, -15:6:3]
object was indexed with these args: ((slice(3, 5, None), slice(2, 6, None),
7, slice(-15, 6, 3)),)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] List indexing multiple elements

[Ryan Birmingham]

So, to make sure I have this right: your proposal says array should be
indexable by a list of indexes as they're currently done, in a tuple,
right? Would this also mean that something like (1:4, 8:10, 13) should be
an acceptable constructor for a tuple?

-Ryan Birmingham

On 20 February 2017 at 15:54, Ryan Gonzalez  wrote:

> Apologies if this has already been covered!
>
> Right now, if you want to get multiple elements in a list, you have to do:
>
> elements = [mylist[a], mylist[b]]
>
> My proposal is two-folded:
>
> - Right now, a[b,c] is already valid syntax, since it's just indexing a
> with the tuple (b, c). The proposal is to make this a specialization in the
> grammar, and also allow stuff like a[b:c, d:e] (like
> `a.__getitem__(slice(b, c), slice(d, e))`).
>
> - Add support for indexing via tuples in list.__getitem__.
> list.__getitem__(tuple) would roughly be equivalent to
> map(list.__getitem__, tuple).
>
> The first part is solely so that slices would be allowed in the syntax,
> but if you guys don't like the idea, the second part still stands.
>
> Thoughts? *ducks from flying tomatoes*
>
> --
> Ryan (ライアン)
> Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else
> http://refi64.com
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] List indexing multiple elements

[Ryan Gonzalez]

Apologies if this has already been covered!

Right now, if you want to get multiple elements in a list, you have to do:

elements = [mylist[a], mylist[b]]

My proposal is two-folded:

- Right now, a[b,c] is already valid syntax, since it's just indexing a
with the tuple (b, c). The proposal is to make this a specialization in the
grammar, and also allow stuff like a[b:c, d:e] (like
`a.__getitem__(slice(b, c), slice(d, e))`).

- Add support for indexing via tuples in list.__getitem__.
list.__getitem__(tuple) would roughly be equivalent to
map(list.__getitem__, tuple).

The first part is solely so that slices would be allowed in the syntax, but
if you guys don't like the idea, the second part still stands.

Thoughts? *ducks from flying tomatoes*

--
Ryan (ライアン)
Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else
http://refi64.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Delayed Execution via Keyword

[tritium-list]

> -Original Message-
> From: Python-ideas [mailto:python-ideas-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Michel Desmoulin
> Sent: Monday, February 20, 2017 3:30 AM
> To: python-ideas@python.org
> Subject: Re: [Python-ideas] Delayed Execution via Keyword
> 
> I wrote a blog post about this, and someone asked me if it meant
> allowing lazy imports to make optional imports easier.
> 
> Someting like:
> 
> lazy import foo
> lazy from foo import bar
> 
> So now if I don't use the imports, the module is not loaded, which could
> also significantly speed up applications starting time with a lot of
> imports.

Would that not also make a failure to import an error at the time of
executing the imported piece of code rather than at the place of import?
And how would optional imports work if they are not loaded until use?  Right
now, optional imports are done by wrapping the import statement in a
try/except, would you not need to do that handling everywhere the imported
object is used instead?

(I haven't been following the entire thread, and I don't know if this is a
forest/tress argument)

> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Delayed Execution via Keyword

[Michel Desmoulin]

I wrote a blog post about this, and someone asked me if it meant
allowing lazy imports to make optional imports easier.

Someting like:

lazy import foo
lazy from foo import bar

So now if I don't use the imports, the module is not loaded, which could
also significantly speed up applications starting time with a lot of
imports.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/