Re: [Python-ideas] Consider (one day) adding an inheritance order class precedence mechanism

On Thu, Nov 16, 2017 at 07:10:15PM +1300, Greg Ewing wrote: > Steven D'Aprano wrote: > >These are not equivalent: > > > >B < S, E > >B < E, S > > Not in general, but in many cases they will be, e.g. if > E and S have no method names in common. I think the OP is > implying that his case is one of t

Re: [Python-ideas] A proliferation of (un-)Pythonically programmatic pragmas

On Mon, Nov 13, 2017 at 07:17:26PM -0500, Terry Reedy wrote: > Docstring directives might be considered for points to copy or not copy. > An example is # doctest: +ELLIPSIS, +NORMALIZE_WHITESPACE [...] > For binary options, '+' and '-' prefixes are much more compact than > '=True' and '=False' s

Re: [Python-ideas] Looking for input to help with the pip situation

On 17 November 2017 at 05:15, Chris Barker wrote: > On Wed, Nov 15, 2017 at 11:07 AM, Steve Dower > wrote: > >> If you write such a PEP, please also research and write up the issues >> with modifying PATH on Windows (they're largely scattered throughout >> bugs.p.o and earlier discussions on pyt

Re: [Python-ideas] Consider (one day) adding an inheritance order class precedence mechanism

It doesn't -- that's the point. Currently it's assumed that the order base classes appear in a class statement is the order that they must appear in the MRO. It’s not assumed — it’s how order is specified by the coder... But that's not always true. Isn’t it true by definition? I'm suggesting

Re: [Python-ideas] A proliferation of (un-)Pythonically programmatic pragmas

On 16/11/2017 19:03, Chris Barker wrote: > On Tue, Nov 14, 2017 at 6:14 PM, Steven D'Aprano > wrote: > > > and then, even if you wanted to put it on the previous line, you would't > > have the line-length issue: > > > > # flake8: disable=unused-import

Re: [Python-ideas] Consider (one day) adding an inheritance order class precedence mechanism

Ethan Furman wrote: If they don't have any clashing attributes, why does order matter? It doesn't -- that's the point. Currently it's assumed that the order base classes appear in a class statement is the order that they must appear in the MRO. But that's not always true. I'm suggesting that t

Re: [Python-ideas] Rewriting the "roundrobin" recipe in the itertools documentation

On Thu, Nov 16, 2017 at 02:56:29PM -0500, Terry Reedy wrote: > >3) using a while loop in code dealing with iterables, > > I agree that this is not necessary, and give a replacement below. The OP isn't just saying that its unnecessary in this case, but that its unPythonic to ever use a while loo

Re: [Python-ideas] Rewriting the "roundrobin" recipe in the itertools documentation

On 11/16/2017 2:42 PM, brent bejot wrote: I think the idea behind the original recipe is that when one of the inner lists has been iterated through, it is removed and never looked at again.  Imagine the following scenario: L is a list which contains one million empty lists and also a list con

Re: [Python-ideas] Rewriting the "roundrobin" recipe in the itertools documentation

On 11/16/2017 2:56 PM, Terry Reedy wrote: Correct off-by-one error. I should have tested with an edge case such as print(list(roundrobin('ABC', ''))) The following combines 3 statements into one for statement. def roundrobin(*iterables):     "roundrobin('ABC', 'D', 'EF') --> A D E B F C"   

Re: [Python-ideas] Rewriting the "roundrobin" recipe in the itertools documentation

On Thu, Nov 16, 2017 at 07:56:21AM -0600, bunslow wrote about the roundrobin recipe in the itertools docs: > However, it is remarkably unpythonic, in my opinion [...] > Things that strike me as unpythonic: 1) requiring the total number of input > iterables 2) making gratuitous use of `next`, 3) u

Re: [Python-ideas] Ignorable whitespaces in the re.VERBOSE mode

On 2017-11-16 21:44, Serhiy Storchaka wrote: 16.11.17 19:38, Guido van Rossum пише: Who would benefit from changing this? Let's not change things just because we can, or because Perl 6 does it. I don't know. I know the disadvantages of making this change, and I ask what is the benefit. If ther

Re: [Python-ideas] Ignorable whitespaces in the re.VERBOSE mode

16.11.17 19:38, Guido van Rossum пише: Who would benefit from changing this? Let's not change things just because we can, or because Perl 6 does it. I don't know. I know the disadvantages of making this change, and I ask what is the benefit. If there is a benefit, and it is important for Pyth

Re: [Python-ideas] Rewriting the "roundrobin" recipe in the itertools documentation

I like yours better. Plenty of recipes sit on top of other recipes, e.g., pairwise sits on top of tee. On Thursday, November 16, 2017 at 8:57:29 AM UTC-5, bunslow wrote: > > For taking values alternately from a series of iterables, there's two > primary functions: > > builtin.zip > itertools.zi

Re: [Python-ideas] Rewriting the "roundrobin" recipe in the itertools documentation

On 11/16/2017 05:56 AM, bunslow wrote: I realize at the end of the day this is a pretty trivial and ultimately meaningless nit to pick, Not at all -- documentation is extremely important. but I've never contributed before and have a variety of similar minor pain points in the docs/stdlib,

Re: [Python-ideas] Rewriting the "roundrobin" recipe in the itertools documentation

On 11/16/2017 8:56 AM, bunslow wrote: For taking values alternately from a series of iterables, there's two primary functions: builtin.zip itertools.zip_longest These bunch together the nth items of each iterable, while itertools.cycle does not. ... def roundrobin(*iterables):     "round

Re: [Python-ideas] Rewriting the "roundrobin" recipe in the itertools documentation

I think the idea behind the original recipe is that when one of the inner lists has been iterated through, it is removed and never looked at again. Imagine the following scenario: L is a list which contains one million empty lists and also a list containing one million numbers Then the original r

Re: [Python-ideas] Looking for input to help with the pip situation

On Wed, Nov 15, 2017 at 11:07 AM, Steve Dower wrote: > If you write such a PEP, please also research and write up the issues with > modifying PATH on Windows (they're largely scattered throughout bugs.p.o > and earlier discussions on python-dev). > Is anyone proposing doing anything new with tha

Re: [Python-ideas] A proliferation of (un-)Pythonically programmatic pragmas

On Tue, Nov 14, 2017 at 6:14 PM, Steven D'Aprano wrote: > > and then, even if you wanted to put it on the previous line, you would't > > have the line-length issue: > > > > # flake8: disable=unused-import mypy: alias=pathlib2.Path coverage: > > ignore=when>py2.7 > > And the irony is that this sho

Re: [Python-ideas] Ignorable whitespaces in the re.VERBOSE mode

Who would benefit from changing this? Let's not change things just because we can, or because Perl 6 does it. On Thu, Nov 16, 2017 at 9:21 AM, MRAB wrote: > On 2017-11-16 10:23, Serhiy Storchaka wrote: > >> Currently the re module ignores only 6 ASCII whitespaces in the >> re.VERBOSE mode: >> >>

Re: [Python-ideas] Ignorable whitespaces in the re.VERBOSE mode

On 2017-11-16 10:23, Serhiy Storchaka wrote: Currently the re module ignores only 6 ASCII whitespaces in the re.VERBOSE mode: U+0009 CHARACTER TABULATION U+000A LINE FEED U+000B LINE TABULATION U+000C FORM FEED U+000D CARRIAGE RETURN U+0020 SPACE Perl i

Re: [Python-ideas] Rewriting the "roundrobin" recipe in the itertools documentation

I agree this is a much better recipe presented. Have you benchmarked the two on more realistically long iterators. E.g. a hundred iterators of millions of items where many terminate much earlier than others. I doubt the repeated 'is not' comparison makes much difference, but it would be good to se

Re: [Python-ideas] Consider (one day) adding an inheritance order class precedence mechanism

On 11/15/2017 10:10 PM, Greg Ewing wrote: Steven D'Aprano wrote: These are not equivalent: B < S, E B < E, S Not in general, but in many cases they will be, e.g. if E and S have no method names in common. I think the OP is implying that his case is one of those. Maybe what's really wanted is

[Python-ideas] Rewriting the "roundrobin" recipe in the itertools documentation

For taking values alternately from a series of iterables, there's two primary functions: builtin.zip itertools.zip_longest zip of course stops when the shortest iterable ends. zip_longest is generally a useful substitute for when you don't want the zip behavior, but it fills extra values in the b

Re: [Python-ideas] Consider (one day) adding an inheritance order class precedence mechanism

On Thu, Nov 16, 2017 at 5:28 AM, Neil Girdhar wrote: > On Wednesday, November 15, 2017 at 5:32:00 PM UTC-5, Koos Zevenhoven wrote: >> >> On Wed, Nov 15, 2017 at 11:49 PM, Neil Girdhar >> wrote: >> >>> Sometimes I get MRO failures when defining classes. For example, if >>> >>> R < E, C >>> B < S

Re: [Python-ideas] Looking for input to help with the pip situation

Would something like this be helpful? (`python -m pip` seems to work fine after `conda install pip` after a miniconda install) https://gist.github.com/westurner/80e81cd4bf9b79acb5989622f2621655 ```python #!/usr/bin/env python """ Something like this as e.g site.discover (for use as ``python -m si

Re: [Python-ideas] Ignorable whitespaces in the re.VERBOSE mode

My instinct is not to worry about it unless someone has actually hit the issue in practice and raised a bug. Paul On 16 November 2017 at 10:23, Serhiy Storchaka wrote: > Currently the re module ignores only 6 ASCII whitespaces in the re.VERBOSE > mode: > > U+0009 CHARACTER TABULATION >

[Python-ideas] Ignorable whitespaces in the re.VERBOSE mode

Currently the re module ignores only 6 ASCII whitespaces in the re.VERBOSE mode: U+0009 CHARACTER TABULATION U+000A LINE FEED U+000B LINE TABULATION U+000C FORM FEED U+000D CARRIAGE RETURN U+0020 SPACE Perl ignores characters that Unicode calls "Pattern White Space

Re: [Python-ideas] Looking for input to help with the pip situation

On 16 November 2017 at 06:49, Nick Coghlan wrote: > On 16 November 2017 at 05:29, Zachary Ware > wrote: >> >> On Wed, Nov 15, 2017 at 1:07 PM, Steve Dower >> wrote: >> > My preferred solution for this is to rename "py.exe" to "python.exe" (or >> > rather, make a copy of it with the new name), an