On 28 June 2017 at 14:30, Terry Reedy wrote:
> On 6/27/2017 10:47 PM, Nick Coghlan wrote:
>> Such an approach has a lot to recommend it:
>>
>> 1. It has precedent, in that Python 3's map(), filter(), and zip(),
>> are essentially Python 2's itertools.imap(), ifilter(), and izip()
>> 2. There's no
On 28 June 2017 at 13:16, Chris Angelico wrote:
> On Wed, Jun 28, 2017 at 12:25 PM, Nick Coghlan wrote:
>> While generator functions now do that implicitly for StopIteration,
>> and "raise X from Y" lets people write suitable exception handlers
>> themselves, we don't offer an easy way to do it w
On 6/27/2017 10:47 PM, Nick Coghlan wrote:
While I haven't been following this thread closely, I'd like to note
that arguing for a "chain()" builtin has the virtue that would just be
arguing for the promotion of the existing itertools.chain function
into the builtin namespace.
Such an approach
On Wed, Jun 28, 2017 at 12:25 PM, Nick Coghlan wrote:
> While generator functions now do that implicitly for StopIteration,
> and "raise X from Y" lets people write suitable exception handlers
> themselves, we don't offer an easy way to do it with a context manager
> (with statement as stack bound
On 28 June 2017 at 07:13, Mike Miller wrote:
>
> On 2017-06-27 14:05, Brendan Barnwell wrote:
>>
>> Even if this "chain" only took one argument, you could do
>> it1.chain(it2).chain(it3). But I don't see why it couldn't take multiple
>> arguments as you suggest.
>
> Right, and as I forgot to
On 28 June 2017 at 06:03, Chris Angelico wrote:
> On Wed, Jun 28, 2017 at 5:49 AM, Sven R. Kunze wrote:
>> I would agree with you here but this "refactoring principle in Python"
>> doesn't work for control flow.
>>
>> Just look at "return", "break", "continue" etc. Exceptions are another way
>> o
By the way, this is already in the CPython source code if I remember from
when I worked on 448. The code for dict unpacking is merely blocked. I
like this syntax from a purity standpoint, but I don't think I would use it
that much.
On Thursday, June 8, 2017 at 3:18:21 PM UTC-4, Nick Badger w
On Monday, June 26, 2017, Wes Turner wrote:
>
>
> On Sunday, June 25, 2017, Wes Turner > wrote:
>
>>
>>
>> On Sunday, June 25, 2017, Danilo J. S. Bellini
>> wrote:
>>
>>> On Sun, Jun 25, 2017 at 3:06 PM, lucas via Python-ideas <
>>> python-ideas@python.org> wrote:
>>>
I often use generator
On 2017-06-27 14:05, Brendan Barnwell wrote:
Even if this "chain" only took one argument, you could do
it1.chain(it2).chain(it3). But I don't see why it couldn't take multiple
arguments as you suggest.
Right, and as I forgot to mention, making it a built-in is an uphill battle with
h
On 2017-06-27 14:02, David Mertz wrote:
iterable3 = iterable1.chain(iterable2)
How do you chain it1, it2, it3, etc?
Why not:
iterable5 = iterable1.chain(iterable2, iterable3, iterable4)
? i.e. Couldn't a class method do this with itertools.chain() under the hood?
On 2017-06-27 14:02, David Mertz wrote:
On Tue, Jun 27, 2017 at 1:57 PM, Mike Miller mailto:python-id...@mgmiller.net>> wrote:
I like this suggestion. Here's another color that might be less
controversial:
iterable3 = iterable1.chain(iterable2)
How do you chain it1, it2, it3
On Tue, Jun 27, 2017 at 1:57 PM, Mike Miller
wrote:
> I like this suggestion. Here's another color that might be less
> controversial:
>
> iterable3 = iterable1.chain(iterable2)
>
How do you chain it1, it2, it3, etc?
I guess `it1.chain(it2.chain(it3)))` ... but that starts to become
distin
On 2017-06-25 20:23, Steven D'Aprano wrote:
> I have a counter-proposal: introduce the iterator chaining operator "&":
>
> iterable & iterable --> itertools.chain(iterable, iterable)
>
I like this suggestion. Here's another color that might be less controversial:
iterable3 = iterable1
On 27.06.2017 21:27, David Mertz wrote:
And I would like a language change that made a number of common
iterable objects "chainable" without the wrapper. This wrapper could
of course be used as a decorator too.
E.g. generator comprehensions, things returned by itertools functions,
range(),
On Wed, Jun 28, 2017 at 5:49 AM, Sven R. Kunze wrote:
> On 27.06.2017 13:41, Nick Coghlan wrote:
>>
>> The shallow exception notion breaks a fairly fundamental refactoring
>> principle in Python: you should be able to replace an arbitrary
>> expression with a subfunction or subgenerator that produ
On 27.06.2017 13:41, Nick Coghlan wrote:
The shallow exception notion breaks a fairly fundamental refactoring
principle in Python: you should be able to replace an arbitrary
expression with a subfunction or subgenerator that produces the same
result without any of the surrounding code being able
On Tue, Jun 27, 2017 at 4:44 AM, Steven D'Aprano
wrote:
> But that strikes me as overkill. You don't normally check for dunders
> before using an operator, and we already have operators that can return
> different types depending on the operands:
>
> % can mean modulo division or string interpola
On 2017-06-27 00:47, David Mertz wrote:
Maybe if you are confident a and b are exactly NumPy arrays it is
obvious, but what about:
from some_array_library import a
from other_array_library import b
What do you think `a & b` will do under your proposal? Yes, I understand
it's determini
Argh, you're correct. Thanks for the catch.
On Tue, Jun 27, 2017 at 10:06 AM Stephan Houben
wrote:
> Unfortunately this is existing syntax:
>
> a++b
> is parsed as
> a+(+b)
>
> Stephan
>
>
> Op 27 jun. 2017 6:03 p.m. schreef "Joshua Morton" <
> joshua.morto...@gmail.com>:
>
> Just another syntac
Unfortunately this is existing syntax:
a++b
is parsed as
a+(+b)
Stephan
Op 27 jun. 2017 6:03 p.m. schreef "Joshua Morton" :
Just another syntactical suggestion: the binary ++ operator is used as
concat in various contexts in various languages, and is probably less
likely to confuse people as b
Just another syntactical suggestion: the binary ++ operator is used as
concat in various contexts in various languages, and is probably less
likely to confuse people as being either a logical or binary &.
On Tue, Jun 27, 2017 at 6:53 AM Stephan Houben wrote:
> > Its the applications where it *is
> Its the applications where it *is* important that
> we should be looking at.
Um, yes, but given our relative positions in this debate,
the onus is not really on *me* to demonstrate such an application, right?
That would just confuse everbody ;-)
(FWIW, Sagemath is not mostly "numerical processi
On Tue, Jun 27, 2017 at 01:32:05PM +0200, Stephan Houben wrote:
> Hi Steven,
>
> To put this into perspective, I did some greps on Sagemath,
> being the largest Python project I have installed on this machine
> (1955 .py files).
And one which is especially focused on numerical processing, not
re
TL;DR
If people really object to & doing double-duty as bitwise-AND and
chaining, there's always && as a possibility.
On Tue, Jun 27, 2017 at 12:47:40AM -0700, David Mertz wrote:
> > - keep the existing __and__ and __rand__ behaviour;
> > - if they are not defined, and both operands x, y are i
On 27 June 2017 at 02:29, Sven R. Kunze wrote:
> On 24.06.2017 01:37, MRAB wrote:
>>
>> I think a "shallow exception" would be one that's part of a defined API,
>> as distinct from one that is an artifact of the implementation, a leak in
>> the abstraction.
>
> I like the "shallow exception" idea
Hi Steven,
To put this into perspective, I did some greps on Sagemath,
being the largest Python project I have installed on this machine
(1955 .py files).
Occurrences:
enumerate: 922
zip: 585
itertools.product: 67
itertools.combinations: 18
itertools.islice: 17
chain: 14 (with or without itertool
On Mon, Jun 26, 2017 at 01:23:36PM +1000, Steven D'Aprano wrote:
> The downside to this proposal is that it adds some conceptual complexity
> to Python operators. Apart from `is` and `is not`, all Python operators
> call one or more dunder methods. This is (as far as I know) the first
> operato
On Tue, Jun 27, 2017 at 11:01:32AM +0200, Stephan Houben wrote:
> Hi all,
>
> Is "itertools.chain" actually that common?
> Sufficiently common to warrant its own syntax?
I think it's much more common than (say) sequence repetition:
a = [None]*5
which has had an operator for a long, long time.
On Tue, Jun 27, 2017 at 08:40:23PM +1200, Greg Ewing wrote:
> David Mertz wrote:
> >I just wish I could think of a good
> >character that doesn't have some very different meaning in other
> >well-known contexts (even among iterables).
>
>(a;b)
>
> Should be unambiguous as long as the parens
Hi all,
Is "itertools.chain" actually that common?
Sufficiently common to warrant its own syntax?
In my experience, "enumerate" is far more common
among the iterable operations.
And that doesn't have special syntax either.
A minimal proposal would be to promote "chain" to builtins.
Stephan
20
David Mertz wrote:
I just wish I could think of a good
character that doesn't have some very different meaning in other
well-known contexts (even among iterables).
(a;b)
Should be unambiguous as long as the parens are required.
--
Greg
___
Pytho
On Tue, Jun 27, 2017 at 12:12 AM, Steven D'Aprano
wrote:
> > > I have a counter-proposal: introduce the iterator chaining operator
> "&":
> > > iterable & iterable --> itertools.chain(iterable, iterable)
> >
> > In [1]: import numpy as np
> > In [2]: import itertools
> > In [3]: a, b = np.arr
On Mon, Jun 26, 2017 at 09:55:19AM -0700, David Mertz wrote:
> On Sun, Jun 25, 2017 at 8:23 PM, Steven D'Aprano
> wrote:
>
> > On Sun, Jun 25, 2017 at 02:06:54PM +0200, lucas via Python-ideas wrote:
> >
> > I have a counter-proposal: introduce the iterator chaining operator "&":
> >
> > itera
33 matches
Mail list logo
