On 5/24/2016 10:49 AM, Paul Moore wrote:
On 24 May 2016 at 15:11, Koos Zevenhoven wrote:
Please, no. We learned that lesson in Python 2.2.1 with True/False.
What happened? True was included in 2.2.1 but not False?-). Anyway, I
guess you are probably right, and "3.6->" is the way to go. Besid
On 24 May 2016 at 15:11, Koos Zevenhoven wrote:
>> Please, no. We learned that lesson in Python 2.2.1 with True/False.
>
> What happened? True was included in 2.2.1 but not False?-). Anyway, I
> guess you are probably right, and "3.6->" is the way to go. Besides,
> Guido already wrote that in the
On Tue, May 24, 2016 at 4:56 PM, Barry Warsaw wrote:
> On May 24, 2016, at 02:03 PM, Koos Zevenhoven wrote:
>
>>I guess we might consider adding __fspath__ in maintenance releases,
>>and make open() support it? That would cover a significant share of
>>use cases, although it might be weird if code
On May 24, 2016, at 02:03 PM, Koos Zevenhoven wrote:
>I guess we might consider adding __fspath__ in maintenance releases,
>and make open() support it? That would cover a significant share of
>use cases, although it might be weird if code written for 3.5.2
>doesn't run on 3.5.1...
Please, no. We
On Mon, May 23, 2016 at 10:38 PM, Chris Barker wrote:
> On Mon, May 23, 2016 at 10:13 AM, Brett Cannon wrote:
>>
>> 3.5 is still getting bugfixes:
>> https://docs.python.org/devguide/#status-of-python-branches
>>
>> As for backporting __fspath__() for pathlib, you can easily write your own
>> sub
On Mon, May 23, 2016 at 10:13 AM, Brett Cannon wrote:
> 3.5 is still getting bugfixes:
> https://docs.python.org/devguide/#status-of-python-branches
>
> As for backporting __fspath__() for pathlib, you can easily write your own
> subclass that adds it. And since the stdlib won't be updated in 3.5
On Mon, May 23, 2016, 09:55 Chris Barker wrote:
> On Fri, May 20, 2016 at 11:42 AM, Brett Cannon wrote:
>
>>
>> WFM. I'll let 3.4 and 3.5 just stay as they are and make all PEP 519
>> changes a 3.6 thing.
>>
>
> I'd like to see it in 3.5 if we could do that -- that'll be available for
> operatio
On Fri, May 20, 2016 at 11:42 AM, Brett Cannon wrote:
>
> WFM. I'll let 3.4 and 3.5 just stay as they are and make all PEP 519
> changes a 3.6 thing.
>
I'd like to see it in 3.5 if we could do that -- that'll be available for
operational code a lot sooner than 3.6, and it's still in active
maint
On 05/20/2016 09:15 PM, Victor Stinner wrote:
> 2016-05-20 18:56 GMT+02:00 Guido van Rossum :
>> Let's start in 3.6 with all this. I added path to 3.4 because I didn't
>> realize it was in security-mode only.
>
> I also had to ask the question to myself about branches, that's why I
> wrote this ta
2016-05-20 18:56 GMT+02:00 Guido van Rossum :
> Let's start in 3.6 with all this. I added path to 3.4 because I didn't
> realize it was in security-mode only.
I also had to ask the question to myself about branches, that's why I
wrote this table ;-)
https://docs.python.org/devguide/#status-of-pyth
On Fri, 20 May 2016 at 09:56 Guido van Rossum wrote:
> Let's start in 3.6 with all this. I added path to 3.4 because I didn't
> realize it was in security-mode only. I've now undone all my work
> there. Let's not disturb it again, not even its docs.
>
> I don't think there's an "upstream" repo fo
Let's start in 3.6 with all this. I added path to 3.4 because I didn't
realize it was in security-mode only. I've now undone all my work
there. Let's not disturb it again, not even its docs.
I don't think there's an "upstream" repo for pathlib (like there still
is for asyncio) and I don't think th
Three questions:
1. Should pathlib gain __fspath__() all the way back to 3.4?
2. Should pathlib's constructor support __fspath__() all the way back to
3.4? (separate question as os.fspath() will only be in 3.6; and if we
backport I'm not looking forward to making Typeshed happy w/o os.
13 matches
Mail list logo
