Re: [Python-ideas] venv *is* provided in the standard Python install on Debian/Ubuntu

[Brett Cannon]

On Tue, Nov 14, 2017, 04:06 Stephan Houben,  wrote:

> Hi Brett,
>
> The current documentation *cannot* be fixed, since
> fixing it would entail adding an initial two-page essay
> on "how to start Python on various platforms/systems"
> (it is really NOT as simple as Windows=python, Linux=python3)
> and such a PR will certainly by rejected.
>

It doesn't have to be in the venv' docs. Such a page could be a HOWTO or in
the tutorial (if it isn't already there).


> In my opinion, the only alternatives are
>
> 1. either harmonize the invocation of python across platforms
>   (and *then* adapt the docs to follow).
>   Which was pretty much the whole topic of this thread so far.
>

The idea has been discussed of developing a 'py' command fo all OSs like on
Windows, but has never gone beyond just a discussion.


> 2. or just use "python" consistently across all docs
>   (since that is the *only* command which is at least consistent among
>python.org installers), and add weasel-wording to "consult
> documentation
>   of third-party installers"
>

While 'python' is 'python2' on operating systems that won't really work out
well. Best you could do is 'python3'.


> 3. or leave the docs broken for at least some people some of the time.
>

I'm eyeing the removal of pyvenv come February when we fork for 3.8
development so I'm personally not planning to try and clarify anything
(obviously others can make an attempt).

-brett



> Stephan
>
>
> 2017-11-14 2:31 GMT+01:00 Brett Cannon :
>
>>
>>
>> On Mon, Nov 13, 2017, 00:01 Stephan Houben,  wrote:
>>
>>> Hi all,
>>>
>>> Related to this text on https://docs.python.org/3/library/venv.html :
>>>
>>> 
>>>
>>>  Note
>>>   The pyvenv script has been deprecated as of Python 3.6 in favor of
>>>   using python3 -m venv to help prevent any potential confusion as to
>>>   which Python interpreter a virtual environment will be based on.
>>> 
>>>
>>> It's clearer than the text below to which I originally referred.
>>>
>>> However,  this text has also problems in that it is too unix-specific.
>>> In particular:
>>> * Most seriously, it refers to "python3" which doesn't work with the
>>> python.org Windows installer.
>>>
>>
>> It can, but it's opt-in. It's just one of those things that's easy to
>> forget.
>>
>> * Less seriously, it refers to "pyenv" as a "script" which is unix jargon
>>> and moreover technically
>>>incorrect on Windows. (Also, needlessly specific, it should just be
>>> "the pyenv command",
>>>   how it is implemented is irrelevant for this section).
>>>
>>
>> I disagree with this as Python refers to .Py files that you execute
>> directly as "scripts", so I don't think this requires clarification.
>>
>>
>> Anyway, a pull request with suggested wording to address your concerns
>> would be the best way to try and rectify the issue.
>>
>> -brett
>>
>>
>>
>>> Stephan
>>>
>>> 2017-11-13 0:32 GMT+01:00 Chris Angelico :
>>>
 On Mon, Nov 13, 2017 at 10:29 AM, Nick Coghlan 
 wrote:
 > On 13 November 2017 at 07:11, Chris Angelico 
 wrote:
 >> On Mon, Nov 13, 2017 at 6:24 AM, Stephan Houben <
 stephan...@gmail.com> wrote:
 >>> Hi Antoine,
 >>>
 >>> The venv module is included,
 >>> however the pyvenv script is in a separate package
 >>> python3.5-venv .
 >>>
 >>> By the way, I was totally confused by the following text form the
 doc.
 >>>
 >>> https://docs.python.org/3/library/venv.html
 >>>
 >>> 
 >>> Deprecated since version 3.6: pyvenv was the recommended tool for
 creating
 >>> virtual environments for Python 3.3 and 3.4, and is deprecated in
 Python
 >>> 3.6.
 >>>
 >>> Changed in version 3.5: The use of venv is now recommended for
 creating
 >>> virtual environments.
 >>>
 >>> 
 >>
 >> Not sure where you're reading that. I'm seeing:
 >>
 >> """
 >> Note
 >> The pyvenv script has been deprecated as of Python 3.6 in favor of
 >> using python3 -m venv to help prevent any potential confusion as to
 >> which Python interpreter a virtual environment will be based on.
 >> """
 >>
 >> I think that's pretty clear. "python3 -m venv env" is the standard
 and
 >> recommended way to spin up a virtual environment.
 >
 > It's further down in the page, under
 >
 https://docs.python.org/3/library/venv.html#creating-virtual-environments
 >
 > I think the deprecation notice for pyvenv should just be deleted,
 > since it renders like the *module* is deprecated.

 Ah, I see it now, thanks.

 Agreed; or maybe downgrade it to a parenthetical comment. Focus on
 "this is how to do the obvious thing", and only as an afterthought
 mention "it used to be done differently" in case someone greps for
 pyvenv.

 

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

[Neil Girdhar]

On Fri, Nov 17, 2017 at 3:15 AM Nick Coghlan  wrote:

> On 17 November 2017 at 15:52, Steven D'Aprano  wrote:
> > There's a lot of benefit to having a relatively simple, understandable
> > algorithm for determining the MRO, as opposed to some sort of adaptive
> > rule that will try to reorder classes according to potentially clashing
> > constraints. If that means that some classes cannot go together in
> > multiple inheritence because their MRO would be inconsistent, I think
> > that's a price worth paying for not having to debug inheritence bugs
> > caused by weirdly reordered MROs.
>
> I'll note that an interesting side effect of
> https://www.python.org/dev/peps/pep-0560/#mro-entries will be to allow
> folks to write:
>
> class MyCustomMRO:
> def __init__(self, *bases):
> self._resolved_bases = my_mro_resolver(bases)
> def __mro_entries(self, orig_bases):
> if len(orig_bases) > 1 or orig_bases[0] is not self:
> raise TypeError("CustomMRO instance must be sole base
> class")
> return self._resolved_bases
>
>
> class Z(MyCustomMRO(B, R)):
> ...
>
> The custom MRO algorithm may then allow for use case specific hints to
> handle situations that the default C3 resolver will reject as
> inconsistent or ambiguous. (I'll also note that such a custom resolver
> would be able to manufacture and inject synthetic metaclasses if
> that's what someone decided they really wanted to do, by also
> synthesising a custom base class to stick at the head of the list of
> bases).
>

This is really cool!  Like you said, this goes above and beyond what I was
proposing.   I guess my problem could be added as a motivation for
PEP-560's __mro_entries__.

(cc Ivan)


> 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/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/T7YNKZmwW1c/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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 Thu, Nov 16, 2017 at 1:11 AM 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 a way to say "B inherits from
> S and E, but it doesn't care what order they go in". Then
> the MRO generating algorithm could in principle swap them
> if it would result in a consistent MRO.
>

Interesting idea, but unfortunately, reordering base classes doesn't solve
all of the problems that a precedence specification does.  For example, the
original example was:

R < E, C
B < S, E
S < C
Z < B, R

If we make it slightly more complicated:

class Y: pass
class X(Y): pass
class E(X): pass
class C: pass
class R(E, C): pass
class S(C, Y): pass
class B(S, E): pass
class Z(B, R): pass

Then, S and E can't be swapped.


>
> Or maybe the MRO generator could decide for itself if the
> order of two base classes can be swapped by inspecting
> their attributes to see if any of them clash?
>

In general, I think that this would be a cool project, but is much hard
than the user declaring a consistent order.


>
> --
> Greg
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/T7YNKZmwW1c/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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

[pylang]

I find this refactored code intriguing.  While I would not suggest changes
to the itertools recipes,
it is a pleasant exercise to think of alternative recipes with an itertools
way.

There are a few third-party libraries dedicated to itertools recipes.  For
example, more-itertools
 has an iter-like recipe called `more_itertools.interleave_longest`.  It
turns out it behaves like
`round_robin` and the implementation happens to be similar to your
suggestion:



_marker = object() def interleave_longest(*iterables): """Return a new
iterable yielding from each iterable in turn, skipping any that are
exhausted. >>> list(interleave_longest([1, 2, 3], [4, 5], [6, 7, 8])) [1,
4, 6, 2, 5, 7, 3, 8] """ i = chain.from_iterable(zip_longest(*iterables,
fillvalue=_marker)) return filter(lambda x: x is not _marker, i)


For comparison, your suggestion:

def roundrobin(*iters):
> "roundrobin('ABC', 'D', 'EF') --> A D E B F C"
> # Perhaps "flat_zip_nofill" is a better name, or something similar
> sentinel = object()
> for tup in it.zip_longest(*iters, fillvalue=sentinel):
> yield from (x for x in tup if x is not sentinel)
>

In summary, both versions zip iterables and filter sentinels.  I believe
`yield from` in your suggestion
restricts your recipe to Python 3 (which can be resolved with a for loop).
Aside,  given some
performance gain, such third-party libraries may be better suited for your
particular contribution.





On Thu, Nov 16, 2017 at 8:56 AM, bunslow  wrote:

> 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 blanks rather than just ignoring a finished
> iterator and moving on with the rest.
>
> This latter most use case is at least somewhat common, according to
> this[1] StackOverflow question (and other duplicates), in addition to the
> existence of the `roundrobin` recipe[2] in the itertools docs. The recipe
> satisfies this use case, and its code is repeated in the StackOverflow
> answer.
>
> However, it is remarkably unpythonic, in my opinion, which is one thing
> when such is necessary to achieve a goal, but for this functionality, such
> is most definitely *not* necessary.  I'll paste the code here for quick
> reference:
>
>
> 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))
>
>
> Things that strike me as unpythonic: 1) requiring the total number of
> input iterables 2) making gratuitous use of `next`, 3) using a while loop
> in code dealing with iterables, 4) combining loops, exceptions, and
> composed itertools functions in non-obvious ways that make control flow
> difficult to determine
>
> Now, I get it, looking at the "roughly equivalent to" code for zip_longest
> in the docs, there doesn't seem to be much way around it for generally
> similar goals, and as I said above, unpythonic is fine when necessary
> (practicality beats purity), but in this case, for being a "recipe" in the
> itertools docs, it should *make use* of the zip_longest which already does
> all the unpythonic stuff for you (though honestly I'm not convinced either
> that the zip_longest code in the docs is the most possible pythonic-ness).
> Instead, the following recipe (which I also submitted to the StackOverflow
> question, and which is generally similar to several other later answers,
> all remarking that they believe it's more pythonic) is much cleaner and
> more suited to demonstrating the power of itertools to new developers than
> the mess of a "recipe" pasted above.
>
>
> def roundrobin(*iters):
> "roundrobin('ABC', 'D', 'EF') --> A D E B F C"
> # Perhaps "flat_zip_nofill" is a better name, or something similar
> sentinel = object()
> for tup in it.zip_longest(*iters, fillvalue=sentinel):
> yield from (x for x in tup if x is not sentinel)
>
>
> In particular, this is just an extremely thin wrapper around zip_longest,
> whose primary purpose is to eliminate the otherwise-mandatory "fillvalues"
> that zip_longest requires to produce uniform-length tuples. It's also an
> excellent example of how to make best pythonic use of iterables in general,
> and itertools in particular, and as such a much better implementation to be
> demonstrated in documentation.
>
> I would thus advocate that the former recipe is replaced with the latter
> recipe, being much more pythonic, understandable, and useful for helping
> new developers acquire the style of python. (Using the common 

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

[Stephan Houben]

I put the actual space characters here so you can see them
in a non-proportional font (which I assume most Python programmer use).

https://gist.github.com/stephanh42/7c1c122154fd3f26d864233a40d8

The control characters aren't rendered at all (Vim renders them as ^\ ^] ^^
^_,
respectively). Most of the other spaces are rendered exactly like the
normal space.

The only ones which render differently are
U+1680 | | OGHAM SPACE MARK
U+3000 | | IDEOGRAPHIC SPACE

I understand Ogham has recently (since 6th century CE) seen a decline in
popularity.

However, I think Python should totally adopt U+3000 as a new whitespace
character
and start promoting it as the One True Way to indent code,
so as to finally end the age-old spaces vs tabs conflict.

[That was supposed to be a joke.]

Stephan



2017-11-17 16:38 GMT+01:00 Victor Stinner :

> I don't think that we need more than space (U+0020) and Unix newline
> (U+000A) ;-)
>
> Victor
>
> 2017-11-16 11:23 GMT+01:00 Serhiy Storchaka :
> > 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" in the
> /x
> > mode. It ignores additional 5 non-ASCII characters.
> >
> >  U+0085 NEXT LINE
> >  U+200E LEFT-TO-RIGHT MARK
> >  U+200F RIGHT-TO-LEFT MARK
> >  U+2028 LINE SEPARATOR
> >  U+2029 PARAGRAPH SEPARATOR
> >
> > The regex module just ignores characters for which str.isspace() returns
> > True. It ignores additional 20 non-ASCII whitespace characters, including
> > characters U+001C..001F whose classification as whitespaces is
> questionable,
> > but doesn't ignore LEFT-TO-RIGHT MARK and RIGHT-TO-LEFT MARK.
> >
> >  U+001C [FILE SEPARATOR]
> >  U+001D [GROUP SEPARATOR]
> >  U+001E [RECORD SEPARATOR]
> >  U+001F [UNIT SEPARATOR]
> >  U+00A0 NO-BREAK SPACE
> >  U+1680 OGHAM SPACE MARK
> >  U+2000 EN QUAD
> >  U+2001 EM QUAD
> >  U+2002 EN SPACE
> >  U+2003 EM SPACE
> >  U+2004 THREE-PER-EM SPACE
> >  U+2005 FOUR-PER-EM SPACE
> >  U+2006 SIX-PER-EM SPACE
> >  U+2007 FIGURE SPACE
> >  U+2008 PUNCTUATION SPACE
> >  U+2009 THIN SPACE
> >  U+200A HAIR SPACE
> >  U+202F NARROW NO-BREAK SPACE
> >  U+205F MEDIUM MATHEMATICAL SPACE
> >  U+3000 IDEOGRAPHIC SPACE
> >
> > Is it worth to extend the set of ignored whitespaces to "Pattern
> > Whitespaces"? Would it add any benefit? Or add confusion? Should this
> depend
> > on the re.ASCII mode? Should the byte b'\x85' be ignorable in verbose
> bytes
> > patterns?
> >
> > And there is a similar question about the Python parser. If Python uses
> > Unicode definition for identifier, shouldn't it accept non-ASCII "Pattern
> > Whitespaces" as whitespaces? There will be technical problems with
> > supporting this, but are there any benefits?
> >
> >
> > https://perldoc.perl.org/perlre.html
> > https://www.unicode.org/reports/tr31/tr31-4.html#Pattern_Syntax
> > https://unicode.org/L2/L2005/05012r-pattern.html
> >
> > ___
> > Python-ideas mailing list
> > Python-ideas@python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Victor Stinner]

I don't think that we need more than space (U+0020) and Unix newline
(U+000A) ;-)

Victor

2017-11-16 11:23 GMT+01:00 Serhiy Storchaka :
> 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" in the /x
> mode. It ignores additional 5 non-ASCII characters.
>
>  U+0085 NEXT LINE
>  U+200E LEFT-TO-RIGHT MARK
>  U+200F RIGHT-TO-LEFT MARK
>  U+2028 LINE SEPARATOR
>  U+2029 PARAGRAPH SEPARATOR
>
> The regex module just ignores characters for which str.isspace() returns
> True. It ignores additional 20 non-ASCII whitespace characters, including
> characters U+001C..001F whose classification as whitespaces is questionable,
> but doesn't ignore LEFT-TO-RIGHT MARK and RIGHT-TO-LEFT MARK.
>
>  U+001C [FILE SEPARATOR]
>  U+001D [GROUP SEPARATOR]
>  U+001E [RECORD SEPARATOR]
>  U+001F [UNIT SEPARATOR]
>  U+00A0 NO-BREAK SPACE
>  U+1680 OGHAM SPACE MARK
>  U+2000 EN QUAD
>  U+2001 EM QUAD
>  U+2002 EN SPACE
>  U+2003 EM SPACE
>  U+2004 THREE-PER-EM SPACE
>  U+2005 FOUR-PER-EM SPACE
>  U+2006 SIX-PER-EM SPACE
>  U+2007 FIGURE SPACE
>  U+2008 PUNCTUATION SPACE
>  U+2009 THIN SPACE
>  U+200A HAIR SPACE
>  U+202F NARROW NO-BREAK SPACE
>  U+205F MEDIUM MATHEMATICAL SPACE
>  U+3000 IDEOGRAPHIC SPACE
>
> Is it worth to extend the set of ignored whitespaces to "Pattern
> Whitespaces"? Would it add any benefit? Or add confusion? Should this depend
> on the re.ASCII mode? Should the byte b'\x85' be ignorable in verbose bytes
> patterns?
>
> And there is a similar question about the Python parser. If Python uses
> Unicode definition for identifier, shouldn't it accept non-ASCII "Pattern
> Whitespaces" as whitespaces? There will be technical problems with
> supporting this, but are there any benefits?
>
>
> https://perldoc.perl.org/perlre.html
> https://www.unicode.org/reports/tr31/tr31-4.html#Pattern_Syntax
> https://unicode.org/L2/L2005/05012r-pattern.html
>
> ___
> 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] Looking for input to help with the pip situation

[Steve Barnes]

On 17/11/2017 09:13, Paul Moore wrote:
> On 17 November 2017 at 01:57, Nick Coghlan  wrote:
>> 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 python-dev).
>>>
>>>
>>> Is anyone proposing doing anything new with that? (other than changing the
>>> default)
>>>
 My preferred solution for this is to rename "py.exe" to "python.exe"
>>>
>>>
>>> I was going to propose that in this thread, but then thought: "there has
>>> GOT to be a reason why that reall obvious solution wan't done in the first
>>> place", and didn't have time to go back and research it.
>>
>>
>> As far as I recall, the arguments against it are:
>>
>> - wanting the regular executable and the launcher to be able to coexist in
>> the same build target directory
>> - not wanting the regular python executable to prevent access to the
>> launcher at a shell prompt
>> - not wanting the launcher at a shell prompt to prevent access to the
>> regular executable at a shell prompt
>>
>> However, 
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.python.org%2Fdev%2Fpeps%2Fpep-0397%2F=02%7C01%7Cgadgetsteve%40live.co.uk%7C18fce28e3baa4e4e70c708d52d9b80c5%7C84df9e7fe9f640afb435%7C1%7C0%7C636465068254194278=4%2BAusacb7TwM5NY9xEUXx%2B%2Ff7s%2BTvV05xIhUWtn9xjg%3D=0
>>  doesn't spell those out,
>> it just states what the launcher's name will be, and emphasises that the
>> main purpose is to provide a sensible target for file associations after the
>> "always use the most recently installed version" assumption broke down:
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.python.org%2Fdev%2Fpeps%2Fpep-0397%2F%23rationale=02%7C01%7Cgadgetsteve%40live.co.uk%7C18fce28e3baa4e4e70c708d52d9b80c5%7C84df9e7fe9f640afb435%7C1%7C0%7C636465068254194278=OVs0HEVnlob8Rj5LQewOE0YoyIvIA9ydar7i0b1%2BZfY%3D=0
>>
>> Addressing them now:
>>
>> * as long as the extra hard links are only generated at install time, there
>> also won't be any problems with build directory name conflicts.
>> * the launcher will always be available a `py`, regardless of the current
>> PATH
>> * PATH in a venv will still put the regular python executable ahead of the
>> launcher
> 
> Note that if I *do* get round to working on this, my primary intention
> will be to propose altering the launcher to allow it to be used under
> different names, as described by Steve. However, I won't initially be
> proposing that we add any additional links to the launcher by default,
> leaving that for users to do manually, and/or for later revisions of
> the PEP (or further PEPs) to propose this.
> 
> Reasons:
> 
> 1. The launcher is typically in C:\Windows, which has a very high
> priority on PATH, so getting the environment right will be tricky.
> 2. I don't have any real experience with the installer.
> 3. Backporting this change, or dealing with older versions of Python
> that don't include the new launcher, is a complicated question.
> 
> I'd rather keep the initial PEP restricted to the simple behaviour
> change. It's possible that the behaviour change may not even need a
> PEP, but I think it'd be better to have one. The "how do we use the
> new behaviour in the installers" question is likely to be much more
> controversial...
> 
> Paul
> 
> PS This (particularly the replacement of python.exe) is almost
> certainly too late for 3.7, so it's not as if there's a rush to answer
> all the questions at once :-)
> ___

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

1. It would only address things on Windows or if py were created for 
other platforms as python there would be issues with trying to ensure 
that it was the one that was called first in every case.
1. We would have to also rename python.exe to avoid py.exe executing itself.
1. The current behaviour of py.exe doesn't quite match what I was 
suggesting in that it always executes a python, (the default or 
specified), or in 3.7 with the -0 lists the ones that it can find, so 
would not really address the users installing to the wrong context. I 
was suggesting that pip, and possibly other tools, would simply execute 
the command if there was only one python in the current context or 
prompt the user if there were more than one. (It occurs to me that it 
might also be valuable to have an all option, e.g. for admins installing 
security updates).

I do like the idea to making this sort of behaviour available, possibly 
as soft-links or alternate entry points, to tools other than pip as that 
would be very handy in some cases, so having this behaviour in a python 
library that pip and other tools could 

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

[Paul Moore]

On 17 November 2017 at 01:57, Nick Coghlan  wrote:
> 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 python-dev).
>>
>>
>> Is anyone proposing doing anything new with that? (other than changing the
>> default)
>>
>>> My preferred solution for this is to rename "py.exe" to "python.exe"
>>
>>
>> I was going to propose that in this thread, but then thought: "there has
>> GOT to be a reason why that reall obvious solution wan't done in the first
>> place", and didn't have time to go back and research it.
>
>
> As far as I recall, the arguments against it are:
>
> - wanting the regular executable and the launcher to be able to coexist in
> the same build target directory
> - not wanting the regular python executable to prevent access to the
> launcher at a shell prompt
> - not wanting the launcher at a shell prompt to prevent access to the
> regular executable at a shell prompt
>
> However, https://www.python.org/dev/peps/pep-0397/ doesn't spell those out,
> it just states what the launcher's name will be, and emphasises that the
> main purpose is to provide a sensible target for file associations after the
> "always use the most recently installed version" assumption broke down:
> https://www.python.org/dev/peps/pep-0397/#rationale
>
> Addressing them now:
>
> * as long as the extra hard links are only generated at install time, there
> also won't be any problems with build directory name conflicts.
> * the launcher will always be available a `py`, regardless of the current
> PATH
> * PATH in a venv will still put the regular python executable ahead of the
> launcher

Note that if I *do* get round to working on this, my primary intention
will be to propose altering the launcher to allow it to be used under
different names, as described by Steve. However, I won't initially be
proposing that we add any additional links to the launcher by default,
leaving that for users to do manually, and/or for later revisions of
the PEP (or further PEPs) to propose this.

Reasons:

1. The launcher is typically in C:\Windows, which has a very high
priority on PATH, so getting the environment right will be tricky.
2. I don't have any real experience with the installer.
3. Backporting this change, or dealing with older versions of Python
that don't include the new launcher, is a complicated question.

I'd rather keep the initial PEP restricted to the simple behaviour
change. It's possible that the behaviour change may not even need a
PEP, but I think it'd be better to have one. The "how do we use the
new behaviour in the installers" question is likely to be much more
controversial...

Paul

PS This (particularly the replacement of python.exe) is almost
certainly too late for 3.7, so it's not as if there's a rush to answer
all the questions at once :-)
___
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

[Koos Zevenhoven]

On Fri, Nov 17, 2017 at 10:14 AM, Nick Coghlan  wrote:

> On 17 November 2017 at 15:52, Steven D'Aprano  wrote:
> > There's a lot of benefit to having a relatively simple, understandable
> > algorithm for determining the MRO, as opposed to some sort of adaptive
> > rule that will try to reorder classes according to potentially clashing
> > constraints. If that means that some classes cannot go together in
> > multiple inheritence because their MRO would be inconsistent, I think
> > that's a price worth paying for not having to debug inheritence bugs
> > caused by weirdly reordered MROs.
>
> I'll note that an interesting side effect of
> https://www.python.org/dev/peps/pep-0560/#mro-entries will be to allow
> folks to write:
>
> class MyCustomMRO:
> def __init__(self, *bases):
> self._resolved_bases = my_mro_resolver(bases)
> def __mro_entries(self, orig_bases):
> if len(orig_bases) > 1 or orig_bases[0] is not self:
> raise TypeError("CustomMRO instance must be sole base
> class")
> return self._resolved_bases
>
>
> class Z(MyCustomMRO(B, R)):
> ...
>
> The custom MRO algorithm may then allow for use case specific hints to
> handle situations that the default C3 resolver will reject as
> inconsistent or ambiguous. (I'll also note that such a custom resolver
> would be able to manufacture and inject synthetic metaclasses if
> that's what someone decided they really wanted to do, by also
> synthesising a custom base class to stick at the head of the list of
> bases).
>
>
​I can imagine someone wanting that, but it still doesn't allow customizing
the *whole* MRO, AFAICT. Regarding the inheritance trees of B and R that
is. Or at least trying to somehow achieve that without introducing a
metaclass would probably become a terrible hack (if not just impossible).

––Koos
​


-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
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]

17.11.17 00:09, MRAB пише:

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 there is a benefit, and it is important for
Python, I could implement this feature in re and regex.

You could see what some more languages, e.g. C#, do. If there isn't a 
consensus of some kind, it's best to leave it.


I haven't found this in the documentation, but according to the sources 
it uses only 5 ASCII whitespaces (exluding \v).


Java uses 6 ASCII whitespaces.

___
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 17 November 2017 at 15:52, Steven D'Aprano  wrote:
> There's a lot of benefit to having a relatively simple, understandable
> algorithm for determining the MRO, as opposed to some sort of adaptive
> rule that will try to reorder classes according to potentially clashing
> constraints. If that means that some classes cannot go together in
> multiple inheritence because their MRO would be inconsistent, I think
> that's a price worth paying for not having to debug inheritence bugs
> caused by weirdly reordered MROs.

I'll note that an interesting side effect of
https://www.python.org/dev/peps/pep-0560/#mro-entries will be to allow
folks to write:

class MyCustomMRO:
def __init__(self, *bases):
self._resolved_bases = my_mro_resolver(bases)
def __mro_entries(self, orig_bases):
if len(orig_bases) > 1 or orig_bases[0] is not self:
raise TypeError("CustomMRO instance must be sole base class")
return self._resolved_bases


class Z(MyCustomMRO(B, R)):
...

The custom MRO algorithm may then allow for use case specific hints to
handle situations that the default C3 resolver will reject as
inconsistent or ambiguous. (I'll also note that such a custom resolver
would be able to manufacture and inject synthetic metaclasses if
that's what someone decided they really wanted to do, by also
synthesising a custom base class to stick at the head of the list of
bases).

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/