python input and output In [2]: z=[ x for x in range(10)] In [3]: z Out[3]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] In [4]: z=[x for x in range(10),100] # should be [ 0 , 1, 2, 3, 4, 5, 6, 7, 8, 9, 100] # but output is not as expected # following is the output # other wise it should show error In [5]: z Out[5]: [[0, 1, 2, 3, 4, 5, 6, 7, 8, 9], 100]
On Wed, Feb 3, 2016 at 8:01 PM, Alexander Walters <tritium-list@sdamon.com> wrote:
That is working exactly as expected. You iterate over a tuple of a list (the range), and an int (100).
I have to say, though, I was a little confused at first, because I'm used to range objects not being lists. And trying it showed that the syntax has been tightened up somewhere:
But in Python 2.7, it behaves as the OP describes. I wonder, does python-ideas need a bit more clarification somewhere that this is (almost) exclusively for the discussion of Python 3, as that's where new ideas can actually be implemented? ChrisA
Chris Angelico writes:
It's not that simple because sometimes ideas for Python 3 are intended to making porting or transition from Python 2 simpler. True, we hope that phase of Python 3 development is over by now, but you never know. %-Formatting for bytes was approved in March 2014 according to the PEP (and released in Python 3.5 last September).
On Wed, Feb 3, 2016 at 9:10 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Yes, that's true - but it's still a new feature for Python 3.5, not a change to Python 2. Same with reinstating the u"..." prefix for Unicode strings - clearly and solely for Py2 compat, but not a change to Py2. Anyone who's proposing changes to the language needs to at least be aware of Python 3, and have tried the code in question under it. (Yes, there are very rare exceptions, where changes DO happen in Py2 - hash randomization comes to mind - but if I were explaining the list's purpose to someone, I'd ignore those rarities in the interests of simplicity.) ChrisA
On Wed, Feb 3, 2016 at 9:22 PM, Alexander Walters <tritium-list@sdamon.com> wrote:
Those usually also apply to Python 3, and the cases where they don't are *incredibly* rare. A lot rarer than the query that ought to have gone to python-list in which someone assumes Python 2 (usually without even saying anything about version) and asks for some new feature that already exists in Py3, or uses example code that doesn't work under Py3. But I'm just spouting nonsense here. People won't read descriptions anyway, so what difference does it make? :) ChrisA
On Wed, Feb 03, 2016 at 02:04:53PM +0530, shiva prasanth wrote:
Your suggestion is not how iteration works in Python: py> for x in range(10), 100: ... print x ... [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 100 To get the result you want, you need to do this: # Python 2 py> [x for x in range(10) + [100]] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 100] # Python 3 py> from itertools import chain py> [x for x in chain(range(10), [100])] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 100] I've sometimes thought that Python should have a iterator concatenation operator (perhaps &) which we could use: [x for x in range(5) & [100] & "spam"] => returns [0, 1, 2, 3, 4, 100, 's', 'p', 'a', 'm'] -- Steve
On Wed, Feb 3, 2016 at 10:04 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Might be problematic for generic iterables, as your three examples are; but if you explicitly request an iterator, it's not hard to make it support + or & for chaining: from itertools import chain _iter = iter class iter: def __init__(self, *args): self.iter = _iter(*args) def __add__(self, other): return type(self)(chain(self.iter, _iter(other))) __and__ = __add__ def __iter__(self): return self def __next__(self): return next(self.iter) print(list(iter(range(5)) & [100] & "spam")) Is that good enough? ChrisA
On Wed, Feb 3, 2016 at 6:14 AM Chris Angelico <rosuav@gmail.com> wrote:
For some reason, the use of an operator there makes me feel like the right-hand argument could be a non-iterable that is appended. ChainableRange(10) & [100] # versus ChainableRange(10) & 100 As opposed to the more explicit use of ``itertools.chain`` which makes it more clear (in my head) that the second argument must be an iterable chain(range(10), [100]) chain(range(10), 100) # will cause TypeError: 'int' object is not iterable I could imagine a module of fancy iterables overloading __and__ for that purpose, but it ought to be a large enough chunk of functionality to warrant a mini-language. Like NumPy. As much as I dislike the term "domain-specific language", I think this example of overloading operators falls into that category. One could take the itertools module and map all sorts of operators to its features: a & b ==> chain(a, b) it[j:k] ==> islice(it, j, k) +it ==> tee(it) a * b ==> product(a, b) 2-it ==> pairwise(it) etc. Not saying it's a good idea for the standard library, but I could see a module that makes extensive use of itertools doing so. It's worth repeating that I prefer using the word instead of the operator for most if not all of these cases.
On Tue, Feb 9, 2016 at 10:54 AM, Michael Selik <mike@selik.org> wrote:
And the cool part of it is that anyone can do this simply by creating a class called "iter", and using that everywhere. A simple "from magic import iter" will enable this for the people who want it AND make it possible for everyone else to figure out what's going on. Personally, I don't use the itertools functions anywhere near enough to justify magic syntax, but there are people who do. ChrisA
Michael Selik writes:
One could take the itertools module and map all sorts of operators to its features:
One could, but I find it hard to think of use cases where you need a concise operator language for dealing with general iterables. The only case I can think of is array algebra, which could deal with general iterables but in practice limits itself to fixed-dimension arrays. Even that has been perennially controversial despite the wealth of applications (and the passion of its advocates :-).
In Python 3.5:
[*(x for x in range(10)), 100]
Should give [0, 1 ... 10, 100]. You can now expand sequence and dict items with * and **, similar to how function calls work. Top-posted from my Windows Phone -----Original Message----- From: "shiva prasanth" <kesavarapu.siva@gmail.com> Sent: 2/3/2016 1:00 To: "python-ideas@python.org" <python-ideas@python.org> Subject: [Python-ideas] List Comprehensions python input and output In [2]: z=[ x for x in range(10)] In [3]: z Out[3]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] In [4]: z=[x for x in range(10),100] # should be [ 0 , 1, 2, 3, 4, 5, 6, 7, 8, 9, 100] # but output is not as expected # following is the output # other wise it should show error In [5]: z Out[5]: [[0, 1, 2, 3, 4, 5, 6, 7, 8, 9], 100]
On Wed, Feb 3, 2016 at 8:01 PM, Alexander Walters <tritium-list@sdamon.com> wrote:
That is working exactly as expected. You iterate over a tuple of a list (the range), and an int (100).
I have to say, though, I was a little confused at first, because I'm used to range objects not being lists. And trying it showed that the syntax has been tightened up somewhere:
But in Python 2.7, it behaves as the OP describes. I wonder, does python-ideas need a bit more clarification somewhere that this is (almost) exclusively for the discussion of Python 3, as that's where new ideas can actually be implemented? ChrisA
Chris Angelico writes:
It's not that simple because sometimes ideas for Python 3 are intended to making porting or transition from Python 2 simpler. True, we hope that phase of Python 3 development is over by now, but you never know. %-Formatting for bytes was approved in March 2014 according to the PEP (and released in Python 3.5 last September).
On Wed, Feb 3, 2016 at 9:10 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Yes, that's true - but it's still a new feature for Python 3.5, not a change to Python 2. Same with reinstating the u"..." prefix for Unicode strings - clearly and solely for Py2 compat, but not a change to Py2. Anyone who's proposing changes to the language needs to at least be aware of Python 3, and have tried the code in question under it. (Yes, there are very rare exceptions, where changes DO happen in Py2 - hash randomization comes to mind - but if I were explaining the list's purpose to someone, I'd ignore those rarities in the interests of simplicity.) ChrisA
On Wed, Feb 3, 2016 at 9:22 PM, Alexander Walters <tritium-list@sdamon.com> wrote:
Those usually also apply to Python 3, and the cases where they don't are *incredibly* rare. A lot rarer than the query that ought to have gone to python-list in which someone assumes Python 2 (usually without even saying anything about version) and asks for some new feature that already exists in Py3, or uses example code that doesn't work under Py3. But I'm just spouting nonsense here. People won't read descriptions anyway, so what difference does it make? :) ChrisA
On Wed, Feb 03, 2016 at 02:04:53PM +0530, shiva prasanth wrote:
Your suggestion is not how iteration works in Python: py> for x in range(10), 100: ... print x ... [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 100 To get the result you want, you need to do this: # Python 2 py> [x for x in range(10) + [100]] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 100] # Python 3 py> from itertools import chain py> [x for x in chain(range(10), [100])] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 100] I've sometimes thought that Python should have a iterator concatenation operator (perhaps &) which we could use: [x for x in range(5) & [100] & "spam"] => returns [0, 1, 2, 3, 4, 100, 's', 'p', 'a', 'm'] -- Steve
On Wed, Feb 3, 2016 at 10:04 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Might be problematic for generic iterables, as your three examples are; but if you explicitly request an iterator, it's not hard to make it support + or & for chaining: from itertools import chain _iter = iter class iter: def __init__(self, *args): self.iter = _iter(*args) def __add__(self, other): return type(self)(chain(self.iter, _iter(other))) __and__ = __add__ def __iter__(self): return self def __next__(self): return next(self.iter) print(list(iter(range(5)) & [100] & "spam")) Is that good enough? ChrisA
On Wed, Feb 3, 2016 at 6:14 AM Chris Angelico <rosuav@gmail.com> wrote:
For some reason, the use of an operator there makes me feel like the right-hand argument could be a non-iterable that is appended. ChainableRange(10) & [100] # versus ChainableRange(10) & 100 As opposed to the more explicit use of ``itertools.chain`` which makes it more clear (in my head) that the second argument must be an iterable chain(range(10), [100]) chain(range(10), 100) # will cause TypeError: 'int' object is not iterable I could imagine a module of fancy iterables overloading __and__ for that purpose, but it ought to be a large enough chunk of functionality to warrant a mini-language. Like NumPy. As much as I dislike the term "domain-specific language", I think this example of overloading operators falls into that category. One could take the itertools module and map all sorts of operators to its features: a & b ==> chain(a, b) it[j:k] ==> islice(it, j, k) +it ==> tee(it) a * b ==> product(a, b) 2-it ==> pairwise(it) etc. Not saying it's a good idea for the standard library, but I could see a module that makes extensive use of itertools doing so. It's worth repeating that I prefer using the word instead of the operator for most if not all of these cases.
On Tue, Feb 9, 2016 at 10:54 AM, Michael Selik <mike@selik.org> wrote:
And the cool part of it is that anyone can do this simply by creating a class called "iter", and using that everywhere. A simple "from magic import iter" will enable this for the people who want it AND make it possible for everyone else to figure out what's going on. Personally, I don't use the itertools functions anywhere near enough to justify magic syntax, but there are people who do. ChrisA
Michael Selik writes:
One could take the itertools module and map all sorts of operators to its features:
One could, but I find it hard to think of use cases where you need a concise operator language for dealing with general iterables. The only case I can think of is array algebra, which could deal with general iterables but in practice limits itself to fixed-dimension arrays. Even that has been perennially controversial despite the wealth of applications (and the passion of its advocates :-).
In Python 3.5:
[*(x for x in range(10)), 100]
Should give [0, 1 ... 10, 100]. You can now expand sequence and dict items with * and **, similar to how function calls work. Top-posted from my Windows Phone -----Original Message----- From: "shiva prasanth" <kesavarapu.siva@gmail.com> Sent: 2/3/2016 1:00 To: "python-ideas@python.org" <python-ideas@python.org> Subject: [Python-ideas] List Comprehensions python input and output In [2]: z=[ x for x in range(10)] In [3]: z Out[3]: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] In [4]: z=[x for x in range(10),100] # should be [ 0 , 1, 2, 3, 4, 5, 6, 7, 8, 9, 100] # but output is not as expected # following is the output # other wise it should show error In [5]: z Out[5]: [[0, 1, 2, 3, 4, 5, 6, 7, 8, 9], 100]
participants (7)
-
Alexander Walters -
Chris Angelico -
Michael Selik -
shiva prasanth -
Stephen J. Turnbull -
Steve Dower -
Steven D'Aprano