On 9 May 2017 at 05:08, Chris Barker wrote:
> On Fri, May 5, 2017 at 9:30 PM, Nick Coghlan wrote:
>>
>> By contrast, 3.6 users can just unconditionally call os.fspath(), and
>> know the result will work with all stdlib APIs, without allowing
>> nonsense
On Fri, May 5, 2017 at 9:30 PM, Nick Coghlan wrote:
> 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
On Fri, May 5, 2017 at 2:34 PM, Terry Reedy wrote:
> 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.
we're not talking about language changes here -- we
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
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
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
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
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
On 4 May 2017 at 08:25, Victor Stinner wrote:
> If you start to backport support for the fspath protocol, be prepared
> to have to backport it *many* places. I expect that slowly in the near
> future, many functions will be patched to support the fspath protocol.
>
> I
On Thu, May 4, 2017 at 8:30 PM, Terry Reedy wrote:
> On 5/4/2017 10:43 AM, Koos Zevenhoven wrote:
>> On Thu, May 4, 2017 at 4:19 AM, Terry Reedy wrote:
>>> Enhancing public APIs in normal (non-provisional) modules in bugfix
>>> releases
>>> has turned out to
On 04.05.17 21:01, Berker Peksağ wrote:
We've already backported a few patches that improves the PEP 519
support in the stdlib with the permission from the release manager of
3.6. I'd ask Ned whether bpo-30218 qualifies for backporting to 3.6.
AFAIK it was before releasing 3.6.1. Some users
On Wed, May 3, 2017 at 9:15 PM, Brett Cannon wrote:
> My allergies have hit me hard so I'm not thinking at full capacity, but did
> we ever decide if supporting os.PathLike in the stdlib was viewed as an
> enhancement or bugfix? Specifically I'm thinking of
>
On 5/4/2017 10:43 AM, Koos Zevenhoven wrote:
On Thu, May 4, 2017 at 4:19 AM, Terry Reedy wrote:
What did not get done for 3.6 should be proposed for 3.7.
Anyone, feel free. The nightmare part is done, so this could be a case
where a PR actually pays off in terms of being
Thanks for the feedback, everyone. I'll just consider it an enhancement
then.
On Wed, 3 May 2017 at 15:07 Terry Reedy wrote:
> On 5/3/2017 2:15 PM, Brett Cannon wrote:
> > My allergies have hit me hard so I'm not thinking at full capacity, but
> > did we ever decide if
On 03.05.17 21:15, Brett Cannon wrote:
My allergies have hit me hard so I'm not thinking at full capacity, but
did we ever decide if supporting os.PathLike in the stdlib was viewed as
an enhancement or bugfix? Specifically I'm thinking
of https://bugs.python.org/issue30218 for adding support to
On 4 May 2017 at 04:15, Brett Cannon wrote:
> My allergies have hit me hard so I'm not thinking at full capacity, but did
> we ever decide if supporting os.PathLike in the stdlib was viewed as an
> enhancement or bugfix? Specifically I'm thinking of
>
On Thu, May 4, 2017 at 4:19 AM, Terry Reedy wrote:
> On 5/3/2017 7:13 PM, Koos Zevenhoven wrote:
>>
[...]
>> Shutil was among the most important to be updated, IMO.
>>
>> I had made some sort of list of affected modules elsewhere [1]:
>> ntpath, posixpath, os.scandir, os.[other
On 5/3/2017 7:13 PM, Koos Zevenhoven wrote:
On Thu, May 4, 2017 at 1:07 AM, Terry Reedy wrote:
On 5/3/2017 2:15 PM, Brett Cannon wrote:
My allergies have hit me hard so I'm not thinking at full capacity, but
did we ever decide if supporting os.PathLike in the stdlib was
On Thu, May 4, 2017 at 1:07 AM, Terry Reedy wrote:
> On 5/3/2017 2:15 PM, Brett Cannon wrote:
>>
>> My allergies have hit me hard so I'm not thinking at full capacity, but
>> did we ever decide if supporting os.PathLike in the stdlib was viewed as an
>> enhancement or bugfix?
If you start to backport support for the fspath protocol, be prepared
to have to backport it *many* places. I expect that slowly in the near
future, many functions will be patched to support the fspath protocol.
I suggest to only do that in master. It's not that hard to cast
manually to a string:
On 5/3/2017 2:15 PM, Brett Cannon wrote:
My allergies have hit me hard so I'm not thinking at full capacity, but
did we ever decide if supporting os.PathLike in the stdlib was viewed as
an enhancement or bugfix? Specifically I'm thinking of
https://bugs.python.org/issue30218 for adding support
My allergies have hit me hard so I'm not thinking at full capacity, but did
we ever decide if supporting os.PathLike in the stdlib was viewed as an
enhancement or bugfix? Specifically I'm thinking of
https://bugs.python.org/issue30218 for adding support to
shutil.unpack_archive() and whether it
22 matches
Mail list logo