Re: [Python-Dev] "make touch" replaced with "make regen-all"

2017-05-05 Thread Victor Stinner 
2017-05-05 6:31 GMT+02:00 Nick Coghlan :
> For the benefit of Linux distros attempting to ensure they're doing
> full "from source" builds, it would be good to note this in a "Notable
> changes in maintenance releases", akin to the existing ones for 3.4
> and 2.7 (perhaps retitling the latter accordingly).

Sorry, I'm not aware of these notes. Where can I found them? Where
should we document the build system change?

You may comment the issue directly: http://bugs.python.org/issue23404

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale

2017-05-05 Thread Erik Bray 
On Thu, May 4, 2017 at 6:25 PM, Antoine Pitrou  wrote:
> On Thu, 4 May 2017 11:24:27 +0900
> INADA Naoki  wrote:
>> Hi, Nick and all core devs who are interested in this PEP.
>>
>> I'm reviewing PEP 538 and I want to accept it in this month.
>> It will reduces much UnicodeError pains which server-side OPs facing.
>> Thank you Nick for working on this PEP.
>>
>> If you have something worrying about this PEP, please post a comment
>> soon.  If you don't have enough time to read entire this PEP, feel free to
>> ask a question about you're worrying.
>
> From my POV, it is problematic that the behaviour outlined in PEP 538
> (see Abstract section) varies depending on the adoption of another PEP
> (PEP 540).
>
> If we want to adopt PEP 538 before pronouncing on PEP 540, then PEP 538
> should remove all points conditional on PEP 540 adoption, and PEP 540
> should later be changed to adopt those removed points as PEP
> 540-specific changes.

This is kind of an aside, but regardless of the dependency
relationship between PEP 538 and 540, given that they kind of go
hand-in-hand would it make sense to rename them--e.g. have PEP 539 and
PEP 540 trade places, since PEP 539 has nothing to do with this and is
awkwardly nestled between them.  Or would that only confuse matters at
this point?

Thanks,
Erik
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale

2017-05-05 Thread Nick Coghlan 
On 5 May 2017 at 19:45, Erik Bray  wrote:
> On Thu, May 4, 2017 at 6:25 PM, Antoine Pitrou  wrote:
>> If we want to adopt PEP 538 before pronouncing on PEP 540, then PEP 538
>> should remove all points conditional on PEP 540 adoption, and PEP 540
>> should later be changed to adopt those removed points as PEP
>> 540-specific changes.
>
> This is kind of an aside, but regardless of the dependency
> relationship between PEP 538 and 540, given that they kind of go
> hand-in-hand would it make sense to rename them--e.g. have PEP 539 and
> PEP 540 trade places, since PEP 539 has nothing to do with this and is
> awkwardly nestled between them.  Or would that only confuse matters at
> this point?

While we have renumbered PEPs in the past, it was only in cases where
the PEPs were relatively new, so there weren't many discussions
referencing them under their existing numbers.

In this case, both PEP 539 and 540 have already been discussed
extensively, so renumbering them would cause problems without
providing any corresponding benefit (Python's development is
sufficiently high volume that it isn't unusual for related PEPs to
have non-sequential PEP numbers)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale

2017-05-05 Thread INADA Naoki 
On Fri, May 5, 2017 at 1:25 AM, Antoine Pitrou  wrote:
> On Thu, 4 May 2017 11:24:27 +0900
> INADA Naoki  wrote:
>> Hi, Nick and all core devs who are interested in this PEP.
>>
>> I'm reviewing PEP 538 and I want to accept it in this month.
>> It will reduces much UnicodeError pains which server-side OPs facing.
>> Thank you Nick for working on this PEP.
>>
>> If you have something worrying about this PEP, please post a comment
>> soon.  If you don't have enough time to read entire this PEP, feel free to
>> ask a question about you're worrying.
>
> From my POV, it is problematic that the behaviour outlined in PEP 538
> (see Abstract section) varies depending on the adoption of another PEP
> (PEP 540).
>
> If we want to adopt PEP 538 before pronouncing on PEP 540, then PEP 538
> should remove all points conditional on PEP 540 adoption, and PEP 540
> should later be changed to adopt those removed points as PEP
> 540-specific changes.
>
> Regards
>
> Antoine.
>

Fair enough.  I stop hurrying about PEP 538 and start reviewing PEP 540.

Thanks,
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale

2017-05-05 Thread Nick Coghlan 
On 5 May 2017 at 23:21, INADA Naoki  wrote:
> On Fri, May 5, 2017 at 1:25 AM, Antoine Pitrou  wrote:
>> If we want to adopt PEP 538 before pronouncing on PEP 540, then PEP 538
>> should remove all points conditional on PEP 540 adoption, and PEP 540
>> should later be changed to adopt those removed points as PEP
>> 540-specific changes.
>
> Fair enough.  I stop hurrying about PEP 538 and start reviewing PEP 540.

Don't forget that Victor's still working on the design of PEP 540, so
it isn't ready for pronouncement yet.

Antoine's request was for me to update PEP *538* to eliminate the
"this will need to change if PEP 540 is accepted" aspects, and I think
your suggestion to make the "C.UTF-8 -> surrogateescape on standard
streams by default" behaviour independent of the locale coercion will
achieve that.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2017-05-05 Thread Python tracker 

ACTIVITY SUMMARY (2017-04-28 - 2017-05-05)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open5929 (+21)
  closed 36109 (+61)
  total  42038 (+82)

Open issues with patches: 2384 


Issues opened (58)
==

#29094: Regression in zipfile writing in 2.7.13
http://bugs.python.org/issue29094  reopened by gregory.p.smith

#30166: Import command-line parsing modules only when needed
http://bugs.python.org/issue30166  reopened by terry.reedy

#30202: Update test.test_importlib.test_abc to test find_spec()
http://bugs.python.org/issue30202  opened by brett.cannon

#30203: AttributeError in Popen.communicate()
http://bugs.python.org/issue30203  opened by Luke Campagnola

#30210: No Documentation on tkinter dnd module
http://bugs.python.org/issue30210  opened by anthony-flury

#30211: Bdb: add docstrings
http://bugs.python.org/issue30211  opened by csabella

#30212: test_ssl.py is broken in Centos7
http://bugs.python.org/issue30212  opened by david-cpi

#30213: ZipFile from 'a'ppend-mode file generates invalid zip
http://bugs.python.org/issue30213  opened by BoppreH

#30214: make_zip.py lacks command a few line options.
http://bugs.python.org/issue30214  opened by Decorater

#30216: xdrlib.Unpacker.unpack_string returns bytes (docs say should b
http://bugs.python.org/issue30216  opened by rnash

#30217: Missing entry for the tilde (~) operator in the Index
http://bugs.python.org/issue30217  opened by lebigot

#30218: shutil.unpack_archive doesn't support PathLike
http://bugs.python.org/issue30218  opened by Jelle Zijlstra

#30219: webbrowser.open outputs xdg-open deprecation warning
http://bugs.python.org/issue30219  opened by desbma

#30220: Why are the custom messages for ValueError and TypeError suppr
http://bugs.python.org/issue30220  opened by pgacv2

#30222: make_zip.py had a bug when setting up full 64 bit distribution
http://bugs.python.org/issue30222  opened by Decorater

#30223: Add Lib/test/__main__.py in 2.7
http://bugs.python.org/issue30223  opened by serhiy.storchaka

#30224: remove outdated checks in struct
http://bugs.python.org/issue30224  opened by xiang.zhang

#30226: Modernize make_ssl_certs
http://bugs.python.org/issue30226  opened by christian.heimes

#30227: test_site must not write outside the build directory: must not
http://bugs.python.org/issue30227  opened by haypo

#30228: Open a file in text mode requires too many syscalls
http://bugs.python.org/issue30228  opened by haypo

#30229: Closing a BufferedRandom calls lseek() mutliple times
http://bugs.python.org/issue30229  opened by haypo

#30230: Move quick test in PyObject_IsSubClass outside of PyType_Check
http://bugs.python.org/issue30230  opened by Jim Fasarakis-Hilliard

#30231: test_imaplib needs a TLS server accepting self-signed certific
http://bugs.python.org/issue30231  opened by haypo

#30235: Validate shutil supports path-like objects, update docs accord
http://bugs.python.org/issue30235  opened by brett.cannon

#30237: Access violation due to CancelSynchronousIo of console read
http://bugs.python.org/issue30237  opened by eryksun

#30238: 2to3 doesn't detect or fix Exception indexing
http://bugs.python.org/issue30238  opened by dlenski

#30241: Add contextlib.AbstractAsyncContextManager
http://bugs.python.org/issue30241  opened by Jelle Zijlstra

#30242: resolve undefined behaviour in struct
http://bugs.python.org/issue30242  opened by xiang.zhang

#30244: Emit a ResourceWarning in concurrent.futures executor destruct
http://bugs.python.org/issue30244  opened by haypo

#30245: possible overflow when organize struct.pack_into error message
http://bugs.python.org/issue30245  opened by xiang.zhang

#30246: fix several error messages in struct
http://bugs.python.org/issue30246  opened by xiang.zhang

#30247: Make importlib.machinery class handle os.PathLike path
http://bugs.python.org/issue30247  opened by louielu

#30248: Using boolean arguments in the _json module
http://bugs.python.org/issue30248  opened by serhiy.storchaka

#30249: improve struct.unpack_from's error message like struct.pack_in
http://bugs.python.org/issue30249  opened by xiang.zhang

#30250: StreamIO truncate behavior of current position
http://bugs.python.org/issue30250  opened by Albert.Zeyer

#30251: Windows Visual Studio solution does not have an install target
http://bugs.python.org/issue30251  opened by steveire

#30252: Configuration system does not work for Windows/Visual Studio
http://bugs.python.org/issue30252  opened by steveire

#30253: Python does not build without WITH_THREADS defined on Windows/
http://bugs.python.org/issue30253  opened by steveire

#30256: Adding a SyncManager Queue proxy to a SyncManager dict or Name
http://bugs.python.org/issue30256  opened by jjdmon

#30258: [2.7] regrtest: handle child process crash
http://bugs.python.org/issue30258  opened by haypo

#30259: Test somehow that

[Python-Dev] Outdated GitHub clone of the old svn repository

2017-05-05 Thread Victor Stinner 
Hi,

Does someone know who owns the following Git clone of the old
Subversion CPython repository?
https://github.com/python-git/python/

I would suggest to remove it to avoid confusion. A friend pointed to
me this repository and was surprised to see outdated code...

Is https://github.com/python-git a real user or an organization?

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Outdated GitHub clone of the old svn repository

2017-05-05 Thread Jonathan Goble 
On Fri, May 5, 2017 at 12:33 PM Victor Stinner 
wrote:

> Is https://github.com/python-git a real user or an organization?
>

It appears to me to be an individual user rather than an organization.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Outdated GitHub clone of the old svn repository

2017-05-05 Thread Guido van Rossum 
I submitted another issue requesting to shut down that repo, but there are
already several other such issues and no response. I think the next step is
to contact GitHub user support and request that the repo be shut down. They
sometimes do such things if it's clear that a username/repo is abandoned.

On Fri, May 5, 2017 at 9:31 AM, Victor Stinner 
wrote:

> Hi,
>
> Does someone know who owns the following Git clone of the old
> Subversion CPython repository?
> https://github.com/python-git/python/
>
> I would suggest to remove it to avoid confusion. A friend pointed to
> me this repository and was surprised to see outdated code...
>
> Is https://github.com/python-git a real user or an organization?
>
> Victor
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Outdated GitHub clone of the old svn repository

2017-05-05 Thread Berker Peksağ 
On Fri, May 5, 2017 at 7:31 PM, Victor Stinner  wrote:
> Hi,
>
> Does someone know who owns the following Git clone of the old
> Subversion CPython repository?
> https://github.com/python-git/python/
>
> I would suggest to remove it to avoid confusion. A friend pointed to
> me this repository and was surprised to see outdated code...
>
> Is https://github.com/python-git a real user or an organization?

See https://mail.python.org/pipermail/python-dev/2016-February/143224.html
for the previous discussion.

--Berker
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Outdated GitHub clone of the old svn repository

2017-05-05 Thread Victor Stinner 
2017-05-05 18:36 GMT+02:00 Jonathan Goble :
> It appears to me to be an individual user rather than an organization.

Oh nice, glad to meet you :-) So what do you think? Are you ok to
remove this old clone? Or do you have reasons to keep it?

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Outdated GitHub clone of the old svn repository

2017-05-05 Thread Brett Cannon 
On Fri, 5 May 2017 at 09:50 Victor Stinner  wrote:

> 2017-05-05 18:36 GMT+02:00 Jonathan Goble :
> > It appears to me to be an individual user rather than an organization.
>
> Oh nice, glad to meet you :-) So what do you think? Are you ok to
> remove this old clone? Or do you have reasons to keep it?
>

I don't think Jonathan was claiming ownership of the python-git account,
just pointed out the account is a personal account of somebody's and not an
organization account.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Outdated GitHub clone of the old svn repository

2017-05-05 Thread Jonathan Goble 
On Fri, May 5, 2017 at 12:52 PM Brett Cannon  wrote:

> On Fri, 5 May 2017 at 09:50 Victor Stinner 
> wrote:
>
>> 2017-05-05 18:36 GMT+02:00 Jonathan Goble :
>> > It appears to me to be an individual user rather than an organization.
>>
>> Oh nice, glad to meet you :-) So what do you think? Are you ok to
>> remove this old clone? Or do you have reasons to keep it?
>>
>
> I don't think Jonathan was claiming ownership of the python-git account,
> just pointed out the account is a personal account of somebody's and not an
> organization account.
>

Right. I was just answering the "user or organization?" question. I have
only one GItHub account, and that is not it.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Outdated GitHub clone of the old svn repository

2017-05-05 Thread Guido van Rossum 
Let's coordinate who contacts GitHub. Victor, Brett or myself?

On Fri, May 5, 2017 at 9:52 AM, Brett Cannon  wrote:

>
>
> On Fri, 5 May 2017 at 09:50 Victor Stinner 
> wrote:
>
>> 2017-05-05 18:36 GMT+02:00 Jonathan Goble :
>> > It appears to me to be an individual user rather than an organization.
>>
>> Oh nice, glad to meet you :-) So what do you think? Are you ok to
>> remove this old clone? Or do you have reasons to keep it?
>>
>
> I don't think Jonathan was claiming ownership of the python-git account,
> just pointed out the account is a personal account of somebody's and not an
> organization account.
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?

2017-05-05 Thread Chris Barker 
Sorry to come late to the game, It wasn't immediately clear to me what the
implications were of the "enhancement or bugfix" distinction...

On Thu, May 4, 2017 at 9:46 PM, Nick Coghlan  wrote:

> That improved casting mechanism and the implicit support in the low
> level APIs is the main benefit I see in PEP 519, and if we were
> talking about an os module API that was missing os.path support, I'd
> be more likely to be on the "it's a bug" side of things.
>

absolutely.


> It's only higher level APIs like shutil that I put into the same
> category as third party libraries for now: Python 3.6 users shouldn't
> expect implicit use of the fspath protocol to be universal yet,


I think stdlib packages, like shutil are very much distinct from third
party  libs, and users certainly expect the entire stdlib to be updated to
support new language features.

We very often make the distinction between third party libs and stdlibs --
in fact, that is one reason we are reluctant to add new packages to the
stdlib...

Indeed, IIRC, that was the entire motivation for PEP 519 -- it started as a
"let's make Path objects work with the stdlib", but when we looked at how
to do that, it became clear that new protocol was teh best way to do that
and also provide flexibility to do that.

And the PEP states:

"""
Changes to Python's standard library are also proposed to utilize this
protocol where appropriate to facilitate the use of path objects where
historically only str and/or bytes file system paths are accepted. The goal
is to facilitate the migration of users towards rich path objects while
providing an easy way to work with code expecting str or bytes .
"""

It doesn't actually say "everywhere possible in the stdlib", but if the
goal is to facilitate migration, as stated, then the any but truly obscure
functions should be covered -- and shutil is certainly not obscure.

So it would be really great if any updates to shutils (and other stdlib
packages) to support the new protocol be back-ported.

Yes, it's "just" adding an extra call, but in my experience, low barrier to
entry are enough to discourage adoption -- and handful of shutil function
failing will certainly be enough to keep some folks from adopting the new
approach.

Is there any chance of it breaking already working code? That would be the
one compelling reason to not back-port.

-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

[email protected]
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?

2017-05-05 Thread Eric V. Smith 

On 5/5/2017 3:36 PM, Chris Barker wrote:
Sorry to come late to the game, It wasn't immediately clear to me what 
the implications were of the "enhancement or bugfix" distinction...


On Thu, May 4, 2017 at 9:46 PM, Nick Coghlan > wrote:


That improved casting mechanism and the implicit support in the low
level APIs is the main benefit I see in PEP 519, and if we were
talking about an os module API that was missing os.path support, I'd
be more likely to be on the "it's a bug" side of things.


absolutely.

It's only higher level APIs like shutil that I put into the same
category as third party libraries for now: Python 3.6 users shouldn't
expect implicit use of the fspath protocol to be universal yet,


I think stdlib packages, like shutil are very much distinct from third 
party  libs, and users certainly expect the entire stdlib to be updated 
to support new language features.


We very often make the distinction between third party libs and stdlibs 
-- in fact, that is one reason we are reluctant to add new packages to 
the stdlib...


Indeed, IIRC, that was the entire motivation for PEP 519 -- it started 
as a "let's make Path objects work with the stdlib", but when we looked 
at how to do that, it became clear that new protocol was teh best way to 
do that and also provide flexibility to do that.


And the PEP states:

"""
Changes to Python's standard library are also proposed to utilize this 
protocol where appropriate to facilitate the use of path objects where 
historically only str and/or bytes file system paths are accepted. The 
goal is to facilitate the migration of users towards rich path objects 
while providing an easy way to work with code expecting str or bytes .

"""

It doesn't actually say "everywhere possible in the stdlib", but if the 
goal is to facilitate migration, as stated, then the any but truly 
obscure functions should be covered -- and shutil is certainly not obscure.


So it would be really great if any updates to shutils (and other stdlib 
packages) to support the new protocol be back-ported.


Yes, it's "just" adding an extra call, but in my experience, low barrier 
to entry are enough to discourage adoption -- and handful of shutil 
function failing will certainly be enough to keep some folks from 
adopting the new approach.


Is there any chance of it breaking already working code? That would be 
the one compelling reason to not back-port.


The problem is not breaking existing code. The problem is that when 
someone writes code a year from now and tests it under Python 3.6.2, 
then a customer of theirs finds it doesn't work in 3.6.1. This will 
happen if 3.6.2 supports Path parameters to functions that 3.6.1 does not.


We've burned ourselves before with this, most famously with True and 
False in 2.2.1: 
http://python-history.blogspot.com/2013/11/the-history-of-bool-true-and-false.html


--
Eric.

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?

2017-05-05 Thread Terry Reedy 

On 5/5/2017 3:36 PM, Chris Barker wrote:
Sorry to come late to the game, It wasn't immediately clear to me what 
the implications were of the "enhancement or bugfix" distinction...


An enhancement changes the definition of the Python language, a bugfix 
does not.  Enhancements can only be part of a new version of Python.  A 
bugfix can potentially go in any 'active' implementation that has the bug.


'Python 3.6' is a version of Python.  The Python 3.6 docs more-or-less 
define the Python 3.6.  Subsequent doc patches refine and clarify the 
definition, but should not change it.  New doc patches are released 
daily on docs.python.org.


CPython 3.6.0 was the first full implementation of Python 3.6, whose 
definition was mostly fixed at the first beta.  CPython 3.6.1 was the 
next officially released implementation *of the same Python 3.6 
language*, but with some implementation bugs fixed. The same will be 
true of 3.6.2, etcetera.


If someone privately compiles cpython as it is at some time today, it 
will be an implementation of 3.6 that is hopefully better than 3.6.1 and 
worse than the future 3.6.2, but will not be either.  Call it 
3.6.(datetime).  3rd party distributions based on CPython can muddy 
things even further by selectively incorporating upstream patches, so 
that XYZ Python 3.6(.whatever) does not correspond to any date-stamped 
or released version of repository CPython.


So it would be really great if any updates to shutils (and other stdlib 
packages) to support the new protocol be back-ported.


Not if they change the language.

--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?

2017-05-05 Thread Koos Zevenhoven 
On May 5, 2017 10:39 PM, "Chris Barker"  wrote:

Sorry to come late to the game, It wasn't immediately clear to me what the
implications were of the "enhancement or bugfix" distinction...

On Thu, May 4, 2017 at 9:46 PM, Nick Coghlan  wrote:

> That improved casting mechanism and the implicit support in the low
> level APIs is the main benefit I see in PEP 519, and if we were
> talking about an os module API that was missing os.path support, I'd
> be more likely to be on the "it's a bug" side of things.
>

absolutely.


> It's only higher level APIs like shutil that I put into the same
> category as third party libraries for now: Python 3.6 users shouldn't
> expect implicit use of the fspath protocol to be universal yet,


I think stdlib packages, like shutil are very much distinct from third
party  libs, and users certainly expect the entire stdlib to be updated to
support new language features.

We very often make the distinction between third party libs and stdlibs --
in fact, that is one reason we are reluctant to add new packages to the
stdlib...

Indeed, IIRC, that was the entire motivation for PEP 519 -- it started as a
"let's make Path objects work with the stdlib", but when we looked at how
to do that, it became clear that new protocol was teh best way to do that
and also provide flexibility to do that.

And the PEP states:

"""
Changes to Python's standard library are also proposed to utilize this
protocol where appropriate to facilitate the use of path objects where
historically only str and/or bytes file system paths are accepted. The goal
is to facilitate the migration of users towards rich path objects while
providing an easy way to work with code expecting str or bytes .
"""

It doesn't actually say "everywhere possible in the stdlib", but if the
goal is to facilitate migration, as stated, then the any but truly obscure
functions should be covered -- and shutil is certainly not obscure.


Indeed.

So it would be really great if any updates to shutils (and other stdlib
packages) to support the new protocol be back-ported.

Yes, it's "just" adding an extra call, but in my experience, low barrier to
entry are enough to discourage adoption -- and handful of shutil function
failing will certainly be enough to keep some folks from adopting the new
approach.


I suppose the worst thing to happen is what Eric describes. But technically
speaking, passing os.PathLike to shutil functions might currently be
undefined behavior, so the change is 'legal' if it's not documented ;).

-- Koos (mobile)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Outdated GitHub clone of the old svn repository

2017-05-05 Thread Guido van Rossum 
OK I'll contact GitHub.

On Fri, May 5, 2017 at 10:01 AM, Guido van Rossum  wrote:

> Let's coordinate who contacts GitHub. Victor, Brett or myself?
>
> On Fri, May 5, 2017 at 9:52 AM, Brett Cannon  wrote:
>
>>
>>
>> On Fri, 5 May 2017 at 09:50 Victor Stinner 
>> wrote:
>>
>>> 2017-05-05 18:36 GMT+02:00 Jonathan Goble :
>>> > It appears to me to be an individual user rather than an organization.
>>>
>>> Oh nice, glad to meet you :-) So what do you think? Are you ok to
>>> remove this old clone? Or do you have reasons to keep it?
>>>
>>
>> I don't think Jonathan was claiming ownership of the python-git account,
>> just pointed out the account is a personal account of somebody's and not an
>> organization account.
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
>> 40python.org
>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?

2017-05-05 Thread Nick Coghlan 
On 6 May 2017 at 05:36, Chris Barker  wrote:
> It doesn't actually say "everywhere possible in the stdlib", but if the goal
> is to facilitate migration, as stated, then the any but truly obscure
> functions should be covered -- and shutil is certainly not obscure.
>
> So it would be really great if any updates to shutils (and other stdlib
> packages) to support the new protocol be back-ported.

This argument would apply to all the other protocols we've added over
time, and would lead to significant language churn in maintenance
releases if we regularly relied on it.

As another example from 3.6, we found that the non-type metaclasses in
the standard library (most notably abc.ABCMeta) don't play nice with
the arbitrary keyword support in __init_subclass__, since they don't
pass the additional keywords from the class definition up to
type.__new__ (which in turn would pass them along to
__init_subclass__).

That's an oversight we're definitely going to fix, but we'll fix it in
3.7, not in 3.6.x.

> Yes, it's "just" adding an extra call, but in my experience, low barrier to
> entry are enough to discourage adoption -- and handful of shutil function
> failing will certainly be enough to keep some folks from adopting the new
> approach.

The critical problem prior to 3.6 wasn't the extra call, it was that
the recommended extra call had the undesirable side effect of allowing
*any* object to be used as a "file system path". As a result, you
couldn't easily separate the check out into a helper function without
putting a lot of annoying "isinstance" checks into it (or else relying
on functools.singledispatch).

By contrast, 3.6 users can just unconditionally call os.fspath(), and
know the result will work with all stdlib APIs, without allowing
nonsense like attempting to use "str(str)" as a filesystem path.

Doing that implicitly in various APIs is certainly a nice UX
enhancement, but it's the replacement of str with os.fspath as the
recommended coercion function that removes the major barrier to
pathlib adoption.

> Is there any chance of it breaking already working code? That would be the
> one compelling reason to not back-port.

"Don't make the third party compatibility testing matrix impossibly
complicated" is our other major reason not to backport new features.

We already have platform providers supporting 3.6.0 in the wild
(Heroku and AWS Lambda), and we know 3.6.1 is going to be in at least
Fedora 26, and probably Ubuntu 17.10.

We want CI providers like Travis/GitLab/Circle CI/etc to be able to
provide a *single* 3.6.x release (typically the most recent one), and
have the guarantee be "code that passes on this maintenance release
will only fail on earlier maintenance releases if you hit a genuine
bug in those releases".

Changing a function signature from accepting "Union[str, bytes]" (or
potentially even just "str") to instead accepting "os.PathLike"
doesn't count as fixing a genuine bug in the earlier releases - it
just means we made the API more permissive in a maintenance release.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com