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

[Steve Barnes]

On 21/11/2017 00:32, Chris Barker wrote:
> On Mon, Nov 20, 2017 at 3:24 PM, Paul Moore  > wrote:
> 
> On 20 November 2017 at 21:59, Chris Barker  > wrote:
>  > I don't understand any of this enough to have an opinion, so
> while I'd like
>  > to see py.exe be renamed python.exe, let's not let "the perfect
> be the enemy
>  > of good enough". So, if someone can make the case that they can
> restructure
>  > the whole py.exe / python.exe thing nicely in a way that will
> work, AND
>  > write the code to do it fairly quickly, then great!
> 
> I'm happy enough to modify the py.exe code to base its behaviour on
> the name it's called with, as Steve suggested. I'm not sure if that
> would require a PEP, but I'm willing to do one if it's felt that there
> is a need. It should be possible to get that change in for 3.7.
> 
> 
> very cool -- thanks!

I agree that it would be.

> 
> I
> don't know what would be the best approach for adding copies/links of
> the launcher under other names, though.
> 
> 
> this is the thing -- I wonder if py.exe has been a success at all :-)

A lot of people, on windows, are using py.exe and pyw.exe without 
realising it - the default behaviour of the recent installer is to 
associate py.exe with *.py and pyw.exe with *.pyw so any user that is 
running python code by just typing the name of the file, or double 
clicking it, will be using it.

This is the equivalent of the Unix chmod + shebang - I don't think that 
Windows users are ready for chown/chmod.
> 
> I honestly don't know - it's a cool idea, and I liked the idea of 
> replacing the #! line and all that, but the truth is that people simple 
> don't write scripts on Windows and expect them to "just work" the same 
> way they do on *nix systems. And if you do distutils/setuptools 
> "scripts" or "entry points" or whatever we are calling them, right, then 
> you can write utility scripts and install them, and use them
> 
> So ti comes down to: does anyone USE py.exe???
> 
As above.

> The fact that it's unique to Windows  makes it simply less discoverable, 
> and the fact that Windows users aren't used to the whole #! line thing, 
> means that as useful as it might be, it's not getting actual use.
> 
> In fact, I happened to be paying a lot of attention to this conversion 
> because at the very same moment, a group of us are developing a python 
> curriculum, and working on the "how to run a python file" part. We are 
> producing platform specific instructions, but decided NOT to include the 
> py.exe option for Windows users .. just more confusing things among a 
> lot of confusing things!
> 
> So who does teach people about it???

I quite regularly give people python courses and I always, regardless of 
target platform, tell them about the shebang and encoding lines, explain 
why they need them, including many editors basing syntax highlighting 
and character handling on them. I also point out that some nasty person, 
(me), has embedded the requirement to use them in the company coding 
standard for python and the review criteria for all code. (So carrot and 
stick).

> 
> Anyway, this whole thread has been about making the experience more 
> platform-independent -- ideally users should see docs without 
> Windows-specifc advice, and have it "just work" -- having a python3.exe  
> would make that more likely, so let's do that.
> 
> If we could py.exe enhanced and then use it instead of python.ex,m that 
> would be great. Though I at least still have no idea of that's possible.
> 
> But I don't see why we couldn't make a pyton3.exe NOW (in py3.7) that is 
> a copy (Or link, still don't get linking on Windows...) of python.exe, 
> that would help the situation, and if at some point the in the future, 
> python.exe, python3.exe and py.exe all become the same thing, great!
> 
> I think the launcher change is worthwhile in its own right. Even if we
> don't install any aliases by default, users will be able to manually
> add them.
> 
> 
> sure -- but no one would -- or not really no one, but it would become 
> maybe even a worse hassle of the same thing not working everywhere.
> 
> we need th=e basic advice given out to *nix users to work:
> 
> if you type "python" at the command line, and get python2, then you can 
> type "python3" to get python 3.

> 
> simple, straightforward, and it CAN help.
> 
>  > Otherwise, let's at least get a python3.exe into 3.7 -- and
> ideally into
>  > updates to 3.5, 3.6, and (python2.exe in this case, 2.7)
> 
> It's not going to be acceptable for 3.5, as that is now in security
> fix only mode. I'm not certain it's even acceptable for bugfix-only
> releases. It's a backward incompatible change (3.6.3 has no
> python3.exe but python 3.6.4 does) but maybe an acceptable one - we'd
> need feedback from the 3.6 and 2.7 release man

Re: [Python-ideas] Should Python have user-defined constants?

[Serhiy Storchaka]

21.11.17 08:33, Saeed Baig пише:
Hey guys I am thinking of perhaps writing a PEP to introduce 
user-defined constants to Python. Something along the lines of Swift’s 
“let” syntax (e.g. “let pi = 3.14”).


Do you guys think it would be a good idea? Why or why not? Do you think 
there’s a better way to do it?


To do what? What problem do you need to solve?

___
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] Should Python have user-defined constants?

[Joseph Jevnik]

How is that different from "pi = 3.14"?

On Tue, Nov 21, 2017 at 1:33 AM, Saeed Baig  wrote:
> Hey guys I am thinking of perhaps writing a PEP to introduce user-defined
> constants to Python. Something along the lines of Swift’s “let” syntax (e.g.
> “let pi = 3.14”).
>
> Do you guys think it would be a good idea? Why or why not? Do you think
> there’s a better way to do it? I’d like to know what others think about this
> idea before making any formal submission (I’ve already posted this same
> question on python-list, but I just wanted to gauge opinion here too).
>
> ___
> 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] Should Python have user-defined constants?

[INADA Naoki]

I'm -1.

I feel Python is complex language already.
And I don't want make it more complicate.
INADA Naoki  


On Tue, Nov 21, 2017 at 3:33 PM, Saeed Baig  wrote:
> Hey guys I am thinking of perhaps writing a PEP to introduce user-defined
> constants to Python. Something along the lines of Swift’s “let” syntax (e.g.
> “let pi = 3.14”).
>
> Do you guys think it would be a good idea? Why or why not? Do you think
> there’s a better way to do it? I’d like to know what others think about this
> idea before making any formal submission (I’ve already posted this same
> question on python-list, but I just wanted to gauge opinion here too).
>
> ___
> 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] Should Python have user-defined constants?

[Saeed Baig]

Hey guys I am thinking of perhaps writing a PEP to introduce user-defined 
constants to Python. Something along the lines of Swift’s “let” syntax (e.g. 
“let pi = 3.14”).

Do you guys think it would be a good idea? Why or why not? Do you think there’s 
a better way to do it? I’d like to know what others think about this idea 
before making any formal submission (I’ve already posted this same question on 
python-list, but I just wanted to gauge opinion here too).___
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] Allow additional separator character in variables

[Serhiy Storchaka]

21.11.17 05:16, Mikhail V пише:

my·variable
myᝍvariable
myㅡvariable
myⵧvariable
myㄧvariable
myㆍvariable

^ Is this good idea *for Python*? I mean this is not Python that
I knew. I don't know how it is possible. Looks like a result of
some unlucky nuclear experment. Might be it will not cause any possible
confusion, or less than a hyphen and a minus.


Yes, it causes less confusion that changing meaning of a minus.

And yes, it can cause confusion if misused. As well as using the 
following variables:


мyvariable
mуvariable
myvаriable
myvarіable
myvariаble
myvariaЬle
myvariab1e
myvariablе

But the name моязмінна doesn't cause any confusion if used in an 
appropriate context (for example in a lesson for young Ukrainian 
children). I believe the above dot- and hyphen-like characters don't 
cause confusion if used as letters in an appropriate language context.


___
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] Adding a new function "zip_flat" to itertools (Re: Rewriting the "roundrobin" recipe in the itertools documentation)

[Serhiy Storchaka]

21.11.17 01:00, Terry Reedy пише:

On 11/20/2017 4:57 PM, Steven D'Aprano wrote:

Is there a reason for calling reversed() instead of reversing the order
of range in the first place?

range(len(iterables)-1, -1, -1)


Readability.  Accurately and automatically reversing ranges was one of 
the use cases motivating the addition of 'reversed'.  Ranges have a 
__reversed__ method which returns a iterator for a reversed range.


Agree. You also can write this as range(1, len(iterables))[::-1]. This 
is shorter and (I suppose) slightly faster. But reverse() can be better 
choice for a recipe, if it looks less confusing for beginners.


___
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] Allow additional separator character in variables

[Mikhail V]

On Tue, Nov 21, 2017 at 2:51 AM, Stephen J. Turnbull
 wrote:
> Mikhail V writes:
>
>  > On Mon, Nov 20, 2017 at 5:46 AM, Guido van Rossum  wrote:
>  > > Please kill this thread.
>  >
>  > So the idea is too bad?
>
> No, the idea is *not* bad, it's just not for Python.  As has been true
> for every one of your ideas for language tweaks that I can recall.

Not every, but many, yes. And there is plethora of proposals less
plausible and not for Python. Anyway, I'll stick to python-list better
for such topics.
BTW, as per Serhiy Storchaka's note:

my·variable
myᝍvariable
myㅡvariable
myⵧvariable
myㄧvariable
myㆍvariable

^ Is this good idea *for Python*? I mean this is not Python that
I knew. I don't know how it is possible. Looks like a result of
some unlucky nuclear experment. Might be it will not cause any possible
confusion, or less than a hyphen and a minus.

> The solution is as proposed earlier: create your own language. [...]
> language, because other people may feel the same level of attraction
> to it.

Not much interested in *my own language*. Simple translator for
hyphens and minuses I have already made, and I enjoy it.

If the new language thing would happen and gained popularity -
it would be the worst scenario - competing syntaxes, CO2 emissions,
community splittage, etc.
I don't endorse such ideas.



Mikhail
___
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] Consider (one day) adding an inheritance order class precedence mechanism

[Neil Girdhar]

On Mon, Nov 20, 2017 at 9:41 PM Nick Coghlan  wrote:

> On 21 November 2017 at 12:34, Nick Coghlan  wrote:
> > Right, but once you do that, then the existing resolver is already
> > able to handle things:
> >
> > >>> class C: pass
> > ...
> > >>> class S(C): pass
> > ...
> > >>> class E: pass
> > ...
> > >>> class B(S, E, C): pass
> > ...
> > >>> class R(E, C): pass
> > ...
> > >>> class Z(B, R): pass
> > ...
> > >>>
> >
> > If you wanted to pick up cases where two classes generate inconsistent
> > MROs that will prevent mutual subclasses (like "class B(S, E)" vs
> > "class R(E, C)"), that feels like a job for a type checker, since it
> > isn't obvious whether it's the definition of B or the definition of R
> > that should be changed to reorder their MRO.
>
> I do wonder if we might be able to make the error message here less
> cryptic by mentioning which *listed* base classes brought in the
> conflicting MRO entries.
>
> Consider the current:
>
> >>> class Z(B, R): pass
> ...
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: Cannot create a consistent method resolution order
> (MRO) for bases C, E
>
> vs something like:
>
> TypeError: Cannot create a consistent method resolution order
> (MRO) for bases C, E (inherited through B, R)
>
> (Note: I haven't actually checked how practical it would be to
> implement something like that)
>

I totally agree.  I actually proposed this on ideas a few months ago and
then wrote something here: https://github.com/NeilGirdhar/inheritance_graph

If you have any suggestions or improvements, please feel free to improve
the code.

Best,

Neil

> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
___
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] Adding a thin wrapper class around the functions in stdlib.heapq

[bunslow]

Perhaps such repetition is a sign that *something* needs to be done...

Thanks for the link though. I'm new enough to the community that it didn't
even occur to me to search for prior discussions.

On Mon, Nov 20, 2017 at 8:38 PM, Sebastian Kreft  wrote:

> This has been brought up multiple times. Last time was on this thread
> https://mail.python.org/pipermail/python-ideas/2016-October/043024.html.
>
> On Tue, Nov 21, 2017 at 3:13 AM, bunslow  wrote:
>
>> Nothing so bombastic this time. The heapq functions are basically all
>> named "heapsomething", and basically all take a "heap" for their first
>> argument, with supplementary args coming after. It's a textbook example of
>> the (hypothetical) Object Oriented Manifesto™ where defining a class
>> increases type safety and programmers' conceptual clarity. There're
>> practically no drawbacks, and the code to be added would be very simple.
>> Updating the tests and docs would probably be harder.
>>
>> In pure Python, such a class would look like this:
>>
>> class Heap(list):
>>
>> def __init__(self, iterable=None):
>> if iterable:
>> super().__init__(iterable)
>> else:
>> super().__init__()
>>
>> self.heapify()
>>
>> push = heapq.heappush
>> pop = heapq.heappop
>> pushpop = heapq.heappushpop
>> replace = heapq.heapreplace
>> heapify = heapq.heapify
>>
>> # This could be a simple wrapper as well, but I had the following
>> thoughts anyways, so here they are
>> def nsmallest(self, n, key=None):
>> # heapq.nsmallest makes a *max* heap of the first n elements,
>> # while we know that self is already a min heap, so we can
>> # make the max heap construction faster
>> self[:n] = reversed(self[:n])
>> return heapq.nsmallest(n, self, key)
>>
>> # do we define nlargest on a minheap??
>>
>>
>> Wrapping around the C builtin functions (which aren't descriptors) would
>> be a bit harder, but not much so:
>>
>> from functools import partial
>>
>> class Heap(list):
>> def __init__(self, iterable=None):
>> if iterable:
>> super().__init__(iterable)
>> else:
>> super().__init__()
>>
>> self.heapify = partial(heapq.heapify, self)
>> self.push = partial(heapq.heappush, self)
>> ...
>>
>> self.heapify()
>>
>>
>> Thoughts?
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>
>
> --
> Sebastian Kreft
>
___
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] Consider (one day) adding an inheritance order class precedence mechanism

[Neil Girdhar]

On Mon, Nov 20, 2017 at 9:34 PM Nick Coghlan  wrote:

> On 21 November 2017 at 11:09, Neil Girdhar  wrote:
> >
> > On Sat, Nov 18, 2017 at 9:29 PM Nick Coghlan  wrote:
> >>
> >> >>> class C: pass
> >> ...
> >> >>> class S(C): pass
> >> ...
> >> >>> class E: pass
> >> ...
> >> >>> class B(S, E): pass
> >> ...
> >> >>> class R(E, C): pass
> >> ...
> >> >>> class Z(B, S, R, E, C): pass
> >> ...
> >> Traceback (most recent call last):
> >>  File "", line 1, in 
> >> TypeError: Cannot create a consistent method resolution order
> >> (MRO) for bases C, E
>
> > Sorry, I wrote back too quickly.  I meant also to change B's requested
> MRO
> > to be:
> >
> > (B, S, E, C)
> >
> > It works with that change.
>
> Right, but once you do that, then the existing resolver is already
> able to handle things:
>
> >>> class C: pass
> ...
> >>> class S(C): pass
> ...
> >>> class E: pass
> ...
> >>> class B(S, E, C): pass
> ...
> >>> class R(E, C): pass
> ...
> >>> class Z(B, R): pass
> ...
> >>>
>

Sure, but like I mentioned, that's really ugly because B doesn't care about
C and shouldn't have to mention it as a base class.  This solution can
quickly spiral out of control so that changes in the inheritance graph
require you to hunt down extraneous base classes.


>
> If you wanted to pick up cases where two classes generate inconsistent
> MROs that will prevent mutual subclasses (like "class B(S, E)" vs
> "class R(E, C)"),


yes, exactly.


> that feels like a job for a type checker, since it
> isn't obvious whether it's the definition of B or the definition of R
> that should be changed to reorder their MRO.
>

I don't know what the "type checker" means here.  I figured that the
easiest user specification would be precedence relationships between
classes that could be applied (in the way I described).  And I figured that
that could be processed for given classes when their MRO is generated.

The proposal of having a custom MRO generator would also be able to solve
this problem.


> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
___
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] Consider (one day) adding an inheritance order class precedence mechanism

[Nick Coghlan]

On 21 November 2017 at 12:34, Nick Coghlan  wrote:
> Right, but once you do that, then the existing resolver is already
> able to handle things:
>
> >>> class C: pass
> ...
> >>> class S(C): pass
> ...
> >>> class E: pass
> ...
> >>> class B(S, E, C): pass
> ...
> >>> class R(E, C): pass
> ...
> >>> class Z(B, R): pass
> ...
> >>>
>
> If you wanted to pick up cases where two classes generate inconsistent
> MROs that will prevent mutual subclasses (like "class B(S, E)" vs
> "class R(E, C)"), that feels like a job for a type checker, since it
> isn't obvious whether it's the definition of B or the definition of R
> that should be changed to reorder their MRO.

I do wonder if we might be able to make the error message here less
cryptic by mentioning which *listed* base classes brought in the
conflicting MRO entries.

Consider the current:

>>> class Z(B, R): pass
...
Traceback (most recent call last):
  File "", line 1, in 
TypeError: Cannot create a consistent method resolution order
(MRO) for bases C, E

vs something like:

TypeError: Cannot create a consistent method resolution order
(MRO) for bases C, E (inherited through B, R)

(Note: I haven't actually checked how practical it would be to
implement something like that)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Adding a thin wrapper class around the functions in stdlib.heapq

[Sebastian Kreft]

This has been brought up multiple times. Last time was on this thread
https://mail.python.org/pipermail/python-ideas/2016-October/043024.html.

On Tue, Nov 21, 2017 at 3:13 AM, bunslow  wrote:

> Nothing so bombastic this time. The heapq functions are basically all
> named "heapsomething", and basically all take a "heap" for their first
> argument, with supplementary args coming after. It's a textbook example of
> the (hypothetical) Object Oriented Manifesto™ where defining a class
> increases type safety and programmers' conceptual clarity. There're
> practically no drawbacks, and the code to be added would be very simple.
> Updating the tests and docs would probably be harder.
>
> In pure Python, such a class would look like this:
>
> class Heap(list):
>
> def __init__(self, iterable=None):
> if iterable:
> super().__init__(iterable)
> else:
> super().__init__()
>
> self.heapify()
>
> push = heapq.heappush
> pop = heapq.heappop
> pushpop = heapq.heappushpop
> replace = heapq.heapreplace
> heapify = heapq.heapify
>
> # This could be a simple wrapper as well, but I had the following
> thoughts anyways, so here they are
> def nsmallest(self, n, key=None):
> # heapq.nsmallest makes a *max* heap of the first n elements,
> # while we know that self is already a min heap, so we can
> # make the max heap construction faster
> self[:n] = reversed(self[:n])
> return heapq.nsmallest(n, self, key)
>
> # do we define nlargest on a minheap??
>
>
> Wrapping around the C builtin functions (which aren't descriptors) would
> be a bit harder, but not much so:
>
> from functools import partial
>
> class Heap(list):
> def __init__(self, iterable=None):
> if iterable:
> super().__init__(iterable)
> else:
> super().__init__()
>
> self.heapify = partial(heapq.heapify, self)
> self.push = partial(heapq.heappush, self)
> ...
>
> self.heapify()
>
>
> Thoughts?
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
Sebastian Kreft
___
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] Consider (one day) adding an inheritance order class precedence mechanism

[Nick Coghlan]

On 21 November 2017 at 11:09, Neil Girdhar  wrote:
>
> On Sat, Nov 18, 2017 at 9:29 PM Nick Coghlan  wrote:
>>
>> >>> class C: pass
>> ...
>> >>> class S(C): pass
>> ...
>> >>> class E: pass
>> ...
>> >>> class B(S, E): pass
>> ...
>> >>> class R(E, C): pass
>> ...
>> >>> class Z(B, S, R, E, C): pass
>> ...
>> Traceback (most recent call last):
>>  File "", line 1, in 
>> TypeError: Cannot create a consistent method resolution order
>> (MRO) for bases C, E

> Sorry, I wrote back too quickly.  I meant also to change B's requested MRO
> to be:
>
> (B, S, E, C)
>
> It works with that change.

Right, but once you do that, then the existing resolver is already
able to handle things:

>>> class C: pass
...
>>> class S(C): pass
...
>>> class E: pass
...
>>> class B(S, E, C): pass
...
>>> class R(E, C): pass
...
>>> class Z(B, R): pass
...
>>>

If you wanted to pick up cases where two classes generate inconsistent
MROs that will prevent mutual subclasses (like "class B(S, E)" vs
"class R(E, C)"), that feels like a job for a type checker, since it
isn't obvious whether it's the definition of B or the definition of R
that should be changed to reorder their MRO.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Ignorable whitespaces in the re.VERBOSE mode

[Stephen J. Turnbull]

Serhiy Storchaka writes:

 > I agree. But if there is a special part of the Unicode standard for 
 > Pattern White Spaces which includes non-ASCII characters, perhaps there 
 > is a need in them. I asked for the case if Python developers with very 
 > different cultures have need in additional whitespaces in regular 
 > expressions, but I don't know. Seems nobody has claimed their need.

I doubt that Japanese would want it.  I do use \N{IDEOGRAPHIC SPACE} a
bit as a *target* of regular expressions, but I would never want it as
non-syntactic in re.VERBOSE.  (Of course, I'm not a native Japanese, but
I have never heard a Japanese developer wish for use of that character
in any programming language, outside of literal strings.)

 > In particularly I don't know how helpful would be supporting 
 > right-to-left and left-to-right marks in verbose regular expressions

That's a good question.  Interpretation and display of R2L in
programming constructs came up briefly in the discussions about BIDI
on the emacs-devel list.  I'll ask Eli Zaretskii, who implemented it
for Emacs.

Steve


-- 
Associate Professor  Division of Policy and Planning Science
http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information
Email: turnb...@sk.tsukuba.ac.jp   University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
___
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] Adding a thin wrapper class around the functions in stdlib.heapq

[bunslow]

Nothing so bombastic this time. The heapq functions are basically all named
"heapsomething", and basically all take a "heap" for their first argument,
with supplementary args coming after. It's a textbook example of the
(hypothetical) Object Oriented Manifesto™ where defining a class increases
type safety and programmers' conceptual clarity. There're practically no
drawbacks, and the code to be added would be very simple. Updating the
tests and docs would probably be harder.

In pure Python, such a class would look like this:

class Heap(list):

def __init__(self, iterable=None):
if iterable:
super().__init__(iterable)
else:
super().__init__()

self.heapify()

push = heapq.heappush
pop = heapq.heappop
pushpop = heapq.heappushpop
replace = heapq.heapreplace
heapify = heapq.heapify

# This could be a simple wrapper as well, but I had the following
thoughts anyways, so here they are
def nsmallest(self, n, key=None):
# heapq.nsmallest makes a *max* heap of the first n elements,
# while we know that self is already a min heap, so we can
# make the max heap construction faster
self[:n] = reversed(self[:n])
return heapq.nsmallest(n, self, key)

# do we define nlargest on a minheap??


Wrapping around the C builtin functions (which aren't descriptors) would be
a bit harder, but not much so:

from functools import partial

class Heap(list):
def __init__(self, iterable=None):
if iterable:
super().__init__(iterable)
else:
super().__init__()

self.heapify = partial(heapq.heapify, self)
self.push = partial(heapq.heappush, self)
...

self.heapify()


Thoughts?
___
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] Allow additional separator character in variables

[Stephen J. Turnbull]

Mikhail V writes:

 > On Mon, Nov 20, 2017 at 5:46 AM, Guido van Rossum  wrote:
 > > Please kill this thread.
 > 
 > So the idea is too bad?

No, the idea is *not* bad, it's just not for Python.  As has been true
for every one of your ideas for language tweaks that I can recall.

There are *millions* of Python programmers by now.  There are more
lines of Python being written and read in a day than you could write
or read in your lifetime.  It's just not practical to *change* the
meaning of valid lexical constructs this way, and the rules you want
could easily have edge cases that confuse a lot of people.  We have a
lot of experience with such edge cases, both in Python ("else" clauses
on loops, and Python 3 itself, come to mind) and out.  We don't like
them, as a rule, and introduce them only only when they allow a better
expression of something that is quite awkward without them, and
preferably only when they express new semantics (ie, something
previously impossible).

If it were just one idea, I'd say "suck it up, Mikhail, and get with
the programming language".  But your ideas are consistently
superficially plausible, taking a few seconds of reflection to see
that, yes, they could be done, but they are not going to be accepted
in mainline Python.  The problem with them is that you propose them
for Python, not the specific ideas themselves.

The solution is as proposed earlier: create your own language.  It
shouldn't be excessively hard to write a preprocessor for "mvlang"
targeting Python.  It has historical precedent: that's how Stroustrup
originally implemented C++.  It allows smooth interchange of programs
with people who know Python, no matter how much you add or change.
If, having elaborated all your ideas into this new language, you find
yourself unwilling to write in Python, then it's time to publish your
language, because other people may feel the same level of attraction
to it.

But ... it *will* be a different language, not Python.

Regards,
Steve (not speaking for any other Steves, Stevens, or Stephens)


-- 
Associate Professor  Division of Policy and Planning Science
http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information
Email: turnb...@sk.tsukuba.ac.jp   University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
___
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] Adding a new function "zip_flat" to itertools (Re: Rewriting the "roundrobin" recipe in the itertools documentation)

[bunslow]

(Regarding the stackoverflow link, he does have a version that includes the
trivial fix to apply iter() to args, at the bottom of the post.)

I think that the variety of solutions with a variety of merits is
indicative that it would be useful to have a "zip_flat" in the itertools
module, but I guess support for that isn't very strong here. I see that
Terry opened a bug to clean up the current recipe in the docs, which is
better than nothing, but I think it's the absolute bare minimum improvement.

I'm prepared to drop the subject unless there's further discussion in favor
of it.

Thanks again to all for the replies.

Bill

On Mon, Nov 20, 2017 at 10:08 AM, Steven D'Aprano 
wrote:

> Hi Bill,
>
> I don't have time to go through your email in detail and respond to
> every point you raise, but I'd like to respond to one point you made.
>
> On Mon, Nov 20, 2017 at 02:03:13AM -0600, bunslow wrote:
>
> > I also found this answer:
> >
> > https://stackoverflow.com/questions/243865/how-do-i-
> merge-two-python-iterators/40498526#40498526
> >
> > which proposes a solution that is both more correct and efficient than
> the
> > zip_longest-with-sentinels, and also noticeably more readable than either
> > the original doc recipe or even Terry's cleaned up replacement of it.
>
> Please don't make claims about correctness and efficiency without
> testing the code first. The second suggestion given there, using deque,
> is *not* correct as provided, as it fails to work with iterables. It
> requires the caller to pass only iterators, unlike the existing
> roundrobin recipe which accepts any iterable.
>
>

> Nor is it more efficient, at least on my machine -- in fact the
> opposite, it is the worst performing of the four recipes I've tried:
>
> - the current recipe from the itertools docs;
> - your re-write, using zip_longest;
> - Terry's version;
> - and the one from stackoverflow.
>
> I've attached my test code, in case you want to play around with it.
> Apologies in advance for any bugs in the test code (its 2 in the
> morning here and I've had a long day).
>
> According to my testing, on my computer using Python 3.5, Terry's code
> is by far the fastest in all three separate test cases, but that
> probably shouldn't count since it's buggy (it truncates the results and
> bails out early under some circumstances). Out of the implementations
> that don't truncate, the existing recipe is by far the fastest.
>
> Terry, if you're reading this, try:
>
> list(roundrobin('A', 'B', 'CDE'))
>
> Your version truncates the results to A B C instead of A B C D E as the
> itertools recipe gives.
>
> But I digress... the point is, if you're going to make claims about the
> correctness and efficiency of code, you really ought to actually check
> the correctness and efficiency first.
>
> I may or may not get around to responding to some of your other points
> over the next few days.
>
>
> --
> Steve
>
> ___
> 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] Consider (one day) adding an inheritance order class precedence mechanism

[Neil Girdhar]

On Sat, Nov 18, 2017 at 9:29 PM Nick Coghlan  wrote:

> On 19 November 2017 at 06:56, Neil Girdhar  wrote:
> > Would you mind explaining why it's necessary for C3 to complain?
> >
> > In:
> >
> > S < C
> > B < S, E
> > R < E, C
> > Z < B, R
> >
> > If Z is told to have MRO:
> >
> > (Z, B, S, R, E, C)
> >
> > then there are no conflicts with any base classes.
>
> I don't actually know what C3 allows in principle, I only know that
> CPython's resolver still complains in practice:
>
> >>> class C: pass
> ...
> >>> class S(C): pass
> ...
> >>> class E: pass
> ...
> >>> class B(S, E): pass
> ...
> >>> class R(E, C): pass
> ...
> >>> class Z(B, S, R, E, C): pass
> ...
> Traceback (most recent call last):
>  File "", line 1, in 
> TypeError: Cannot create a consistent method resolution order
> (MRO) for bases C, E
>
> I think the problem is that the resolver isn't looking at the declared
> bases of "B", and "R", it's looking at their full MRO:
>
> >>> B.__mro__
> (, , ,
> , )
> >>> R.__mro__
> (, , ,
> )
>
> Changing the heuristics used to generate B's MRO such that "C" and "E"
> appeared in the opposite order wouldn't really help, since that would
> just flip the problematic case to be the "R(C, E)" declaration.
>

Sorry, I wrote back too quickly.  I meant also to change B's requested MRO
to be:

(B, S, E, C)

It works with that change.


>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
___
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] Rewriting the "roundrobin" recipe in the itertools documentation

[Terry Reedy]

On 11/16/2017 5:57 PM, Terry Reedy wrote:

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"
 nexts = cycle(iter(it).__next__ for it in iterables)
 for reduced_len in reversed(range(1, len(iterables))):


Make that 0 rather than 1 for start value.


 try:
 for next in nexts:
 yield next()
 except StopIteration:
 nexts = cycle(islice(nexts, reduced_len))


A slightly clearer, slightly less efficient alternative would be

def roundrobin(*iterables):
     "roundrobin('ABC', 'D', 'EF') --> A D E B F C"
     nexts = cycle(iter(it).__next__ for it in iterables)
     for current_len in reversed(range(1, len(iterables)+1)):
     try:
     for next in nexts:
     yield next()
     except StopIteration:
     nexts = cycle(islice(nexts, current_len - 1))


I submitted the 'current_len' version as
https://bugs.python.org/issue32099
"Use range in itertools roundrobin recipe"

--
Terry Jan Reedy


___
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] Looking for input to help with the pip situation

[Chris Barker]

On Mon, Nov 20, 2017 at 3:24 PM, Paul Moore  wrote:

> On 20 November 2017 at 21:59, Chris Barker  wrote:
> > I don't understand any of this enough to have an opinion, so while I'd
> like
> > to see py.exe be renamed python.exe, let's not let "the perfect be the
> enemy
> > of good enough". So, if someone can make the case that they can
> restructure
> > the whole py.exe / python.exe thing nicely in a way that will work, AND
> > write the code to do it fairly quickly, then great!
>
> I'm happy enough to modify the py.exe code to base its behaviour on
> the name it's called with, as Steve suggested. I'm not sure if that
> would require a PEP, but I'm willing to do one if it's felt that there
> is a need. It should be possible to get that change in for 3.7.


very cool -- thanks!


> I
> don't know what would be the best approach for adding copies/links of
> the launcher under other names, though.


this is the thing -- I wonder if py.exe has been a success at all :-)

I honestly don't know - it's a cool idea, and I liked the idea of replacing
the #! line and all that, but the truth is that people simple don't write
scripts on Windows and expect them to "just work" the same way they do on
*nix systems. And if you do distutils/setuptools "scripts" or "entry
points" or whatever we are calling them, right, then you can write utility
scripts and install them, and use them

So ti comes down to: does anyone USE py.exe???

The fact that it's unique to Windows  makes it simply less discoverable,
and the fact that Windows users aren't used to the whole #! line thing,
means that as useful as it might be, it's not getting actual use.

In fact, I happened to be paying a lot of attention to this conversion
because at the very same moment, a group of us are developing a python
curriculum, and working on the "how to run a python file" part. We are
producing platform specific instructions, but decided NOT to include the
py.exe option for Windows users .. just more confusing things among a lot
of confusing things!

So who does teach people about it???

Anyway, this whole thread has been about making the experience more
platform-independent -- ideally users should see docs without
Windows-specifc advice, and have it "just work" -- having a python3.exe
would make that more likely, so let's do that.

If we could py.exe enhanced and then use it instead of python.ex,m that
would be great. Though I at least still have no idea of that's possible.

But I don't see why we couldn't make a pyton3.exe NOW (in py3.7) that is a
copy (Or link, still don't get linking on Windows...) of python.exe, that
would help the situation, and if at some point the in the future,
python.exe, python3.exe and py.exe all become the same thing, great!


> I think the launcher change is worthwhile in its own right. Even if we
> don't install any aliases by default, users will be able to manually
> add them.


sure -- but no one would -- or not really no one, but it would become maybe
even a worse hassle of the same thing not working everywhere.

we need th=e basic advice given out to *nix users to work:

if you type "python" at the command line, and get python2, then you can
type "python3" to get python 3.

simple, straightforward, and it CAN help.


> > Otherwise, let's at least get a python3.exe into 3.7 -- and ideally into
> > updates to 3.5, 3.6, and (python2.exe in this case, 2.7)
>
> It's not going to be acceptable for 3.5, as that is now in security
> fix only mode. I'm not certain it's even acceptable for bugfix-only
> releases. It's a backward incompatible change (3.6.3 has no
> python3.exe but python 3.6.4 does) but maybe an acceptable one - we'd
> need feedback from the 3.6 and 2.7 release managers on that.
>

Fine -- we can leave that for future discussion


> Also, I'm assuming here you mean "create a copy of python.exe called
> python3.exe". If we do that, we risk making it harder to later switch
> to making "python3.exe" a link to the launcher - for the same reason
> that making "python.exe" be an alternative name for the launcher is
> problematic right now.
>

I'm lost -- how does it make it any harder, rather than exactly the same ???
(except two changes, rather than one...but they are the same change)

> And maybe make "add to PATH" be the default in the installer.
>
> I'm not willing to contradict Steve on this one.


I didn't know he'd made a clear statement about it.

But if people that understand these things say it's a bad idea, then it's a
bad idea. But we SHOULD make sure we are considering not just what could go
wrong, or how often it could go wrong, but who it is going to go wrong
for...

i.e. making it "do the right thing" for newbies is much more important that
making sure it doesn't "do the wrong thing" for more experienced folks that
can uncheck a box, or clean up their PATH after the fact

There are too many
> not-uncommon cases that we could mess up badly here. It's the right
> choice for "make new users' experien

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

[Paul Moore]

>> BTW -- does pip install a "pip3" on Windows?
>
> No. Just "pip.exe".

Looks like I should have checked. As others pointed out, it does
(pip3.exe and pip3.6.exe). Apologies.
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] Looking for input to help with the pip situation

[Paul Moore]

On 20 November 2017 at 21:59, Chris Barker  wrote:
> I don't understand any of this enough to have an opinion, so while I'd like
> to see py.exe be renamed python.exe, let's not let "the perfect be the enemy
> of good enough". So, if someone can make the case that they can restructure
> the whole py.exe / python.exe thing nicely in a way that will work, AND
> write the code to do it fairly quickly, then great!

I'm happy enough to modify the py.exe code to base its behaviour on
the name it's called with, as Steve suggested. I'm not sure if that
would require a PEP, but I'm willing to do one if it's felt that there
is a need. It should be possible to get that change in for 3.7. I
don't know what would be the best approach for adding copies/links of
the launcher under other names, though. And I don't have any
experience with the tools we use to build the installer, so that would
be for someone else. That part probably *would* need a PEP, and it may
well be controversial enough that getting agreement in time for 3.7
(i.e. in the next 2 months or so) will be challenging.

I think the launcher change is worthwhile in its own right. Even if we
don't install any aliases by default, users will be able to manually
add them. (And someone could write a 3rd party tool to manage creation
of such aliases, making that capability available to users who don't
have the necessary skills themselves).

> Otherwise, let's at least get a python3.exe into 3.7 -- and ideally into
> updates to 3.5, 3.6, and (python2.exe in this case, 2.7)

It's not going to be acceptable for 3.5, as that is now in security
fix only mode. I'm not certain it's even acceptable for bugfix-only
releases. It's a backward incompatible change (3.6.3 has no
python3.exe but python 3.6.4 does) but maybe an acceptable one - we'd
need feedback from the 3.6 and 2.7 release managers on that.

Also, I'm assuming here you mean "create a copy of python.exe called
python3.exe". If we do that, we risk making it harder to later switch
to making "python3.exe" a link to the launcher - for the same reason
that making "python.exe" be an alternative name for the launcher is
problematic right now.

> And maybe make "add to PATH" be the default in the installer.

I'm not willing to contradict Steve on this one. There are too many
not-uncommon cases that we could mess up badly here. It's the right
choice for "make new users' experience as easy as possible", but if we
do this at the cost of making the experience of people upgrading to
3.7 (possibly by installing 3.7 to gradually switch over, or starting
their migration from 2.7 with 3.7) unpleasant, then we risk getting
bad publicity for the 3.7 release.

The history of how we added Python to PATH across various versions is
messy and inconsistent. Add to that other distributions (Anaconda,
ActiveState) making different choices and adding yet more
inconsistency, means that anyone who *isn't* a brand new user probably
already has a tweaked, and likely fragile, setup. We're not doing them
any favours by adding another new behaviour. (And enabling "Add to
PATH" in 3.7 *would* be a new behaviour - I don't think we've enabled
add to path by default in any version since we switched to per-user
installs as the default).

We need *another* solution here. Not just variations on the existing
mess. That's why I like Steve's suggestion of making the launcher into
the canonical entry point. It's not easy, but at least it stands a
chance of breaking out of the cycle we're currently in, of switching
back and forth between "add to PATH" and "don't add to PATH".

> Those are quick and simple to do, result in little disruption, and make the
> whole cross-platform thing more manageable.

They aren't that simple. I've already discussed "add to PATH". And if
we add python3.exe, we have to consider questions like will venv be
modified to include it in virtual environments? Will virtualenv? If
not, will "python3" run the system Python rather than the current
virtualenv? That's just as much a problem for the option of having
python3 be an alias for the launcher, of course - but my point here is
you have to think about questions like this even for your "simple"
approach.

I just don't think there *is* a quick and simple solution here. So
better not to rush into a solution that isn't fully thought through,
IMO. "Although never is often better than *right* now" is the relevant
Zen here, not "Now is better than never" (nobody's suggesting we
*never* fix this).

> BTW -- does pip install a "pip3" on Windows?

No. Just "pip.exe".

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] Adding a new function "zip_flat" to itertools (Re: Rewriting the "roundrobin" recipe in the itertools documentation)

[Terry Reedy]

On 11/20/2017 4:57 PM, Steven D'Aprano wrote:

On Mon, Nov 20, 2017 at 12:15:50PM -0500, Terry Reedy wrote:


Your version truncates the results to A B C instead of A B C D E as the
itertools recipe gives.


This is due to an off-by-1 error which I corrected 3 hours later in a
follow-up post, repeated below.


Ah, I missed that, thanks.


def roundrobin(*iterables):
  "roundrobin('ABC', 'D', 'EF') --> A D E B F C"
  nexts = cycle(iter(it).__next__ for it in iterables)
  for reduced_len in reversed(range(1, len(iterables))):


Make that 0 rather than 1 for start value.


Is there a reason for calling reversed() instead of reversing the order
of range in the first place?

range(len(iterables)-1, -1, -1)


Readability.  Accurately and automatically reversing ranges was one of 
the use cases motivating the addition of 'reversed'.  Ranges have a 
__reversed__ method which returns a iterator for a reversed range.


>>> reversed(range(0, n))

>>> list(reversed(range(0, n))) == list(iter(range(n-1, -1, -1)))
True

--
Terry Jan Reedy

___
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] Looking for input to help with the pip situation

[Mark Lawrence]

On 20/11/17 21:59, Chris Barker wrote:


BTW -- does pip install a "pip3" on Windows?

-CHB

--

Christopher Barker, Ph.D.
Oceanographer



pip.exe, pip3.exe and pip3.6.exe are all in C:\Program 
Files\Python36\Scripts on my Windows 10 setup installed for all users.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
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] Looking for input to help with the pip situation

[Eric Fahlgren]

​
On Mon, Nov 20, 2017 at 1:59 PM, Chris Barker  wrote:

> BTW -- does pip install a "pip3" on Windows?
>
​
In 3.6 it does:

> find t:/Python36/ -iname 'pip*exe'
t:/Python36/Scripts/pip.exe
t:/Python36/Scripts/pip3.6.exe
t:/Python36/Scripts/pip3.exe


​
___
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] Looking for input to help with the pip situation

[Chris Barker]

On Fri, Nov 17, 2017 at 2:14 AM, Steve Barnes 
wrote:

>
> >>> On Wed, Nov 15, 2017 at 11:07 AM, Steve Dower 
>  My preferred solution for this is to rename "py.exe" to "python.exe"
>

...


>
> Note that renaming py.exe to python.exe would have several problems:
>
> ...

I don't understand any of this enough to have an opinion, so while I'd like
to see py.exe be renamed python.exe, let's not let "the perfect be the
enemy of good enough". So, if someone can make the case that they can
restructure the whole py.exe / python.exe thing nicely in a way that will
work, AND write the code to do it fairly quickly, then great!

Otherwise, let's at least get a python3.exe into 3.7 -- and ideally into
updates to 3.5, 3.6, and (python2.exe in this case, 2.7)

And maybe make "add to PATH" be the default in the installer.

Those are quick and simple to do, result in little disruption, and make the
whole cross-platform thing more manageable.

BTW -- does pip install a "pip3" on Windows?

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Adding a new function "zip_flat" to itertools (Re: Rewriting the "roundrobin" recipe in the itertools documentation)

[Steven D'Aprano]

On Mon, Nov 20, 2017 at 12:15:50PM -0500, Terry Reedy wrote:

> >Your version truncates the results to A B C instead of A B C D E as the
> >itertools recipe gives.
> 
> This is due to an off-by-1 error which I corrected 3 hours later in a 
> follow-up post, repeated below.

Ah, I missed that, thanks.

> > def roundrobin(*iterables):
> >  "roundrobin('ABC', 'D', 'EF') --> A D E B F C"
> >  nexts = cycle(iter(it).__next__ for it in iterables)
> >  for reduced_len in reversed(range(1, len(iterables))):
> 
> Make that 0 rather than 1 for start value.

Is there a reason for calling reversed() instead of reversing the order 
of range in the first place?

range(len(iterables)-1, -1, -1)



-- 
Steve
___
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] Allow additional separator character in variables

[Nikolaus Rath]

On Nov 18 2017, Bruce Leban  wrote:
> And because spaces between words is mostly not valid syntax currently, this
> change would be easier to introduce than breaking every single program out
> there by re-purposing hyphen-minus. But I'm not seriously proposing this
> because I think the modest benefits are outweighed by the many problems it
> would introduce.

Luckily, there is a compromise: use backticks to quote identifiers:

`test mode` = True
if `test mode`:
   `display message`("just a test")


I'm not seriously suggesting that, but I still wonder what people think
about it.

I sort of like it, actually. The `(" part is pretty ugly (which is why I
included it in the example), but there's no syntax that can completely
avoid ugly corner cases. I think in most cases the context would also
make it easy to distinguish single quotes and backticks even when
they're typographically similar.


Cheers,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
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] A proliferation of (un-)Pythonically programmatic pragmas

[Barry Warsaw]

Chris Barker wrote:

> but whatever -- multiple line pragmas are fine, too -- I'm hoping putting
> this much crap in your code will be rare :-)

For sure.  It's not uncommon for you to need two pragmas, e.g. flake8
and coverage, but it's pretty rare to need those *plus* mypy.  It does
happen though.

And while I agree it's better to fix the problem, there are lots of
reasons why you can't.  Multiple-version support in libraries is one
common reason (e.g. this code path will never be taken in Python 2 and
the alternative will never be taken in Python 3), bugs in the tools
(false positives), etc.

Cheers,
-Barry


___
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] Adding a new function "zip_flat" to itertools (Re: Rewriting the "roundrobin" recipe in the itertools documentation)

[David Mertz]

After correcting Terry's off-by-one error, I get this on Python 3.6 (and
bumping NUMBER to 1000).  In speed, Terry's is either very slightly faster
or very slightly slower than the recipe, depending on the data.  I think
Terry's is more readable that roundrobin(), but still requires a little
thought compared to Bunslow's.  However, using the builtin name 'next' as a
variable name seems like a bad choice to me (it doesn't break in this code,
but seems like bad practice, i'd choose some other variable name).

507-code % python rr_tester.py
testing with equal_data
  roundrobin  0.187816
  bunslow 0.393162
  terry   0.183851
  stackoverflow   0.675543
**
testing with unequal_data
  roundrobin  0.209959
  bunslow 0.555731
  terry   0.233015
  stackoverflow   0.746880
**
testing with extreme_data
  roundrobin  0.053149
  bunslow 0.273607
  terry   0.051963
  stackoverflow   0.158515

508-code % python --version
Python 3.6.2 :: Anaconda custom (x86_64)


On Mon, Nov 20, 2017 at 9:15 AM, Terry Reedy  wrote:

> On 11/20/2017 11:08 AM, Steven D'Aprano wrote:
>
> Please don't make claims about correctness and efficiency without
>> testing the code first. The second suggestion given there, using deque,
>> is *not* correct as provided, as it fails to work with iterables. It
>> requires the caller to pass only iterators, unlike the existing
>> roundrobin recipe which accepts any iterable.
>>
>> Nor is it more efficient, at least on my machine -- in fact the
>> opposite, it is the worst performing of the four recipes I've tried:
>>
>> - the current recipe from the itertools docs;
>> - your re-write, using zip_longest;
>> - Terry's version;
>> - and the one from stackoverflow.
>>
>> I've attached my test code, in case you want to play around with it.
>> Apologies in advance for any bugs in the test code (its 2 in the
>> morning here and I've had a long day).
>>
>> According to my testing, on my computer using Python 3.5, Terry's code
>> is by far the fastest in all three separate test cases, but that
>> probably shouldn't count since it's buggy (it truncates the results and
>> bails out early under some circumstances). Out of the implementations
>> that don't truncate, the existing recipe is by far the fastest.
>>
>> Terry, if you're reading this, try:
>>
>> list(roundrobin('A', 'B', 'CDE'))
>>
>
> Your version truncates the results to A B C instead of A B C D E as the
>> itertools recipe gives.
>>
>
> This is due to an off-by-1 error which I corrected 3 hours later in a
> follow-up post, repeated below.
> ---
>
> 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"
> >  nexts = cycle(iter(it).__next__ for it in iterables)
> >  for reduced_len in reversed(range(1, len(iterables))):
>
> Make that 0 rather than 1 for start value.
>
> >  try:
> >  for next in nexts:
> >  yield next()
> >  except StopIteration:
> >  nexts = cycle(islice(nexts, reduced_len))
>
> A slightly clearer, slightly less efficient alternative would be
>
> def roundrobin(*iterables):
> "roundrobin('ABC', 'D', 'EF') --> A D E B F C"
> nexts = cycle(iter(it).__next__ for it in iterables)
> for current_len in reversed(range(1, len(iterables)+1)):
> try:
> for next in nexts:
> yield next()
> except StopIteration:
> nexts = cycle(islice(nexts, current_len - 1))
>
> --
> Terry Jan Reedy
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
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] Adding a new function "zip_flat" to itertools (Re: Rewriting the "roundrobin" recipe in the itertools documentation)

[Terry Reedy]

On 11/20/2017 11:08 AM, Steven D'Aprano wrote:


Please don't make claims about correctness and efficiency without
testing the code first. The second suggestion given there, using deque,
is *not* correct as provided, as it fails to work with iterables. It
requires the caller to pass only iterators, unlike the existing
roundrobin recipe which accepts any iterable.

Nor is it more efficient, at least on my machine -- in fact the
opposite, it is the worst performing of the four recipes I've tried:

- the current recipe from the itertools docs;
- your re-write, using zip_longest;
- Terry's version;
- and the one from stackoverflow.

I've attached my test code, in case you want to play around with it.
Apologies in advance for any bugs in the test code (its 2 in the
morning here and I've had a long day).

According to my testing, on my computer using Python 3.5, Terry's code
is by far the fastest in all three separate test cases, but that
probably shouldn't count since it's buggy (it truncates the results and
bails out early under some circumstances). Out of the implementations
that don't truncate, the existing recipe is by far the fastest.

Terry, if you're reading this, try:

list(roundrobin('A', 'B', 'CDE'))



Your version truncates the results to A B C instead of A B C D E as the
itertools recipe gives.


This is due to an off-by-1 error which I corrected 3 hours later in a 
follow-up post, repeated below.

---

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"
>  nexts = cycle(iter(it).__next__ for it in iterables)
>  for reduced_len in reversed(range(1, len(iterables))):

Make that 0 rather than 1 for start value.

>  try:
>  for next in nexts:
>  yield next()
>  except StopIteration:
>  nexts = cycle(islice(nexts, reduced_len))

A slightly clearer, slightly less efficient alternative would be

def roundrobin(*iterables):
"roundrobin('ABC', 'D', 'EF') --> A D E B F C"
nexts = cycle(iter(it).__next__ for it in iterables)
for current_len in reversed(range(1, len(iterables)+1)):
try:
for next in nexts:
yield next()
except StopIteration:
nexts = cycle(islice(nexts, current_len - 1))

--
Terry Jan Reedy

___
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] Adding a new function "zip_flat" to itertools (Re: Rewriting the "roundrobin" recipe in the itertools documentation)

[Steven D'Aprano]

Oops, a slight buglet in my test code:

[Attachment: rr_tester.py]

Change the constant 

NUMBER = 30

to the largest value you can bear for more reliable timing tests. I 
lowered the value for a quick test and forgot to increase it again.


-- 
Steve
___
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] Adding a new function "zip_flat" to itertools (Re: Rewriting the "roundrobin" recipe in the itertools documentation)

[Steven D'Aprano]

Hi Bill, 

I don't have time to go through your email in detail and respond to 
every point you raise, but I'd like to respond to one point you made.

On Mon, Nov 20, 2017 at 02:03:13AM -0600, bunslow wrote:

> I also found this answer:
> 
> https://stackoverflow.com/questions/243865/how-do-i-merge-two-python-iterators/40498526#40498526
> 
> which proposes a solution that is both more correct and efficient than the
> zip_longest-with-sentinels, and also noticeably more readable than either
> the original doc recipe or even Terry's cleaned up replacement of it.

Please don't make claims about correctness and efficiency without 
testing the code first. The second suggestion given there, using deque, 
is *not* correct as provided, as it fails to work with iterables. It 
requires the caller to pass only iterators, unlike the existing 
roundrobin recipe which accepts any iterable.

Nor is it more efficient, at least on my machine -- in fact the 
opposite, it is the worst performing of the four recipes I've tried:

- the current recipe from the itertools docs;
- your re-write, using zip_longest;
- Terry's version;
- and the one from stackoverflow.

I've attached my test code, in case you want to play around with it. 
Apologies in advance for any bugs in the test code (its 2 in the 
morning here and I've had a long day).

According to my testing, on my computer using Python 3.5, Terry's code 
is by far the fastest in all three separate test cases, but that 
probably shouldn't count since it's buggy (it truncates the results and 
bails out early under some circumstances). Out of the implementations 
that don't truncate, the existing recipe is by far the fastest.

Terry, if you're reading this, try:

list(roundrobin('A', 'B', 'CDE'))

Your version truncates the results to A B C instead of A B C D E as the 
itertools recipe gives.

But I digress... the point is, if you're going to make claims about the 
correctness and efficiency of code, you really ought to actually check 
the correctness and efficiency first.

I may or may not get around to responding to some of your other points 
over the next few days.


-- 
Steve
import itertools

from itertools import *
from timeit import Timer


# From the itertools recipe
def roundrobin(*iterables):
"roundrobin('ABC', 'D', 'EF') --> A D E B F C"
pending = len(iterables)
nexts = cycle(iter(it).__next__ for it in iterables)
while pending:
try:
for next in nexts:
yield next()
except StopIteration:
pending -= 1
nexts = cycle(islice(nexts, pending))

def bunslow(*iters):
"roundrobin('ABC', 'D', 'EF') --> A D E B F C"
sentinel = object()
for tup in itertools.zip_longest(*iters, fillvalue=sentinel):
yield from (x for x in tup if x is not sentinel)


def terry(*iterables):
"roundrobin('ABC', 'D', 'EF') --> A D E B F C"
nexts = cycle(iter(it).__next__ for it in iterables)
for reduced_len in reversed(range(1, len(iterables))):
try:
for next in nexts:
yield next()
except StopIteration:
nexts = cycle(islice(nexts, reduced_len))


from collections import deque

def stackoverflow(*iterators):
queue = deque(iter(it) for it in iterators)
while len(queue) > 0:
iterator = queue.popleft()
try:
yield next(iterator)
queue.append(iterator)
except StopIteration:
pass



FUNCTIONS = (roundrobin, bunslow, terry, stackoverflow)

equal_data = [range(500)]*4
unequal_data = [range(500), range(600), range(700), range(400)]
extreme_data = [range(1), range(1), range(1), range(500)]

def trial(data_name, number, repeat):
print("testing with %s" % data_name)
template = 'from __main__ import %s as rr, %s as data'
data = globals()[data_name]
assert len(data) == 4 and all(type(x) is range for x in data)
expected = list(roundrobin(*data))
failed = []
for func in FUNCTIONS:
actual = list(func(*data))
if actual != expected:
failed.append(func)
setup = template % (func.__name__, data_name)
T = Timer('list(rr(*data))', setup=setup)
t = min(T.repeat(number=number, repeat=repeat))
print('  %-15s %f' % (func.__name__, t))
for f in failed:
print('  *** %s returned incorrect results ***' % f.__name__)


NUMBER = 30
REPEAT = 5

trial('equal_data', NUMBER, REPEAT)
print("*"*50)
trial('unequal_data', NUMBER, REPEAT)
print("*"*50)
trial('extreme_data', NUMBER, REPEAT)


___
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] Adding a new function "zip_flat" to itertools (Re: Rewriting the "roundrobin" recipe in the itertools documentation)

[bunslow]

Dear all: thank you for your replies and thoughts, most especially Steve
and Terry. I am more-or-less new to contributing to Python, so I wasn't
sure that the bug tracker was the best way to start -- I was looking for a
sanity check and received exactly what I wanted :) Thanks to the feedback
here, the bug tracker issue will be much cleaner from the start.

Regarding the meta discussion about my OP: yes it was long winded,
detailed, pedantic and (to a certain extent) bombastic, but I was imaging
the many possible responses to the suggestion (and suggested replacement)
the I felt I should explain where I was coming from. Even though there was
a lot of disagreement about how I described the current recipe as not very
Pythonic, I'm very glad for all the perspectives and lessons I got from
reading the ensuing discussions.

Now, having had some time to think, I've come up with further thoughts on
the topic. In particular, I was going to create a new bug, and wrote
several paragraphs on the topic summarizing this thread, and my thoughts.
I'll paste those paragraphs here:

"""
To summarize, I found the current implementation of the "roundrobin"
function difficult to understand, and proposed a much simpler solution
that, while producing correct results, isn't quite "correct" in the sense
that it glosses over a detail before "manually" correcting the detail at
the end, and as such is prone to severe inefficiency in extreme cases.
There were a smattering of comments from several people indicating that
they liked the simpler recipe better, despite its performance drawbacks.

Terry Reedy proposed a slightly rewritten version of the current recipe,
which implements the correct algorithm (without glossing over and manually
correcting the details). Although I have since changed my perceptions of
the original, now understanding how it works, the rewritten version from
Terry was clearer enough that I was able to understand *it* where I could
not previously understand the original. (My newfound understanding of the
original is largely derived from making sense of the rewritten version,
which properly clued me in to what cycle and islice actually do.

Either way, the current recipe can certainly be improved. Although I now
find the original and its rewrite to be algorithmically clean and correct
(even if the code and inline comments can be improved), the StackOverflow
question (
https://stackoverflow.com/questions/3678869/pythonic-way-to-combine-two-lists-in-an-alternating-fashion/)
that originally got me thinking about the problem  demonstrates that the
algorithmically clean way is *not* obvious at all to people who aren't very
familiar with the itertools module -- which is the large majority of people
who use Python (even if that's a very small fraction of the people reading
this bug).  The second from top answer is the answer which references the
recipe in the docs, but as my own first post to python-ideas demonstrates,
the (large?) majority of python users aren't familiar enough with the
itertools module to be able to understand that recipe, and I also believe
many people were looking for one or two liners to use in their own code
without a function call. Further confusion on the overall topic is the lack
of a clear name -- "roundrobin", "alternate", "interleave", "merge", and
variations and others.
"""

Having completed those, I found a roughly duplicate StackOverflow question
to the one from my OP:
https://stackoverflow.com/questions/243865/how-do-i-merge-two-python-iterators

Besides emphasizing my points about not having even a clear name for the
topic, a desire for one liners, mass confusion around the issue (especially
regarding flattening zip [which terminates on the shortest input, a hidden
gotcha], zip_longest [someone else found the same solution as me and others
in this op), and all around failure to generate anything even resembling a
consensus on the topic, I also found this answer:

https://stackoverflow.com/questions/243865/how-do-i-merge-two-python-iterators/40498526#40498526

which proposes a solution that is both more correct and efficient than the
zip_longest-with-sentinels, and also noticeably more readable than either
the original doc recipe or even Terry's cleaned up replacement of it.

Given this variety of problems with the issue, I now think that -- while
updating the itertools recipe is certainly better than nothing -- the
better thing to do might be to just add a new function to itertools called
"zip_flat" which solves this problem. In addition to answering the stack
overflow questions with ongoing debate about efficiency, correctness, and
pythonicity (pythonicness?), it would also help to greatly clarify the
naming issue as well. (Sidenote: whoever came up with "zip" as the name for
the builtin was quite creative. It's a remarkably short and descriptive.)

What are the sentiments of readers here? If positive, I'll create an issue
on BPO about zip_flat (rather than just improving the docs recip

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

[M.-A. Lemburg]

For consistency, we should probably have "whitespace" for re
equal to whatever "\s" matches, since this is what the engine
itself considers as whitespace (and then also covers the special
case where you use the re.ASCII flag).

Still, the only practical case I could imagine, where extending the
list would indeed make sense, is to have the   character qualify
as whitespace for re.VERBOSE, since this can sometimes be introduced
via copy&paste from other sources (e.g. web pages showing a
regular expression).

Due to whitespace being what it is, it's hard to tell whether you've
just copied a \u0020 or a \u00a0. The latter can easily render the
regular expression non-working with the current interpretation of
re.VERBOSE.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Nov 20 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.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] Ignorable whitespaces in the re.VERBOSE mode

[Serhiy Storchaka]

20.11.17 10:13, Stephen J. Turnbull пише:

Otherwise I'm with Paul, who writes:

  > My instinct is not to worry about it unless someone has actually hit
  > the issue in practice and raised a bug.

After the tabs vs. spaces fiasco, I lean steeply to the right for code
-- including embedded languages like regexes.  *We* say what is
allowed there, and *you* can find an editor that does it our way.


I agree. But if there is a special part of the Unicode standard for 
Pattern White Spaces which includes non-ASCII characters, perhaps there 
is a need in them. I asked for the case if Python developers with very 
different cultures have need in additional whitespaces in regular 
expressions, but I don't know. Seems nobody has claimed their need.


In particularly I don't know how helpful would be supporting 
right-to-left and left-to-right marks in verbose regular expressions (or 
even in Python code), or this will just add confusion? Unicode 
identifiers already can be misused for confusion due to homoglyphs. The 
problem is not that correctly looking program can be rejected by the 
compiler, but that the program can work differently from expected 
because it uses different names that look the same.


___
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] Ignorable whitespaces in the re.VERBOSE mode

[Stephen J. Turnbull]

All,

If we *do* seriously consider adding those characters as ignorable in
re.VERBOSE, that's because somebody is using them in text a lot, and
it slips into their coding.  Given frequent use, we should consider
how a lot more whitespace characters can be conveniently searched
individually and readably, because whitespace characters are the
ultimate confusables.  This may be a no-op, given the \N and \u
notations, but \u is pretty opaque and \N leads to character-per-line
regexes. ;-)

Otherwise I'm with Paul, who writes:

 > My instinct is not to worry about it unless someone has actually hit
 > the issue in practice and raised a bug.

After the tabs vs. spaces fiasco, I lean steeply to the right for code
-- including embedded languages like regexes.  *We* say what is
allowed there, and *you* can find an editor that does it our way.

The point of re.VERBOSE is to allow writing regexes the way we write
Python code, formatting to emphasize structure and improve
readability.  I don't see why we would want to allow more than we
already do, given that any fancy whitespace formatting for "literate
programming" will be done by the code formatting engine of the
document preparation system anyway.

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