On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan wrote:
> On 6 April 2016 at 15:57, Serhiy Storchaka wrote:
>> On 06.04.16 05:44, Nick Coghlan wrote:
>>>
>>> The most promising option for that is probably "getattr(path, 'path',
>>> path)", since the "path" attribute is being added to pathlib, and th
On 6 April 2016 at 16:25, Ethan Furman wrote:
> On 04/05/2016 10:50 PM, Serhiy Storchaka wrote:
>> On 06.04.16 05:44, Nick Coghlan wrote:
>>> The next challenge would then be to make a list of APIs to be updated
>>> for 3.6 to implicitly accept "rich path" objects via the agreed
>>> convention, wi
On 04/05/2016 10:00 PM, Guido van Rossum wrote:
On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman wrote:
[...] we can't do:
app_root = Path(...)
config = app_root/'settings.cfg'
with open(config) as blah:
# whatever
It feels like instead of addressing this basic disconnect,
On 6 April 2016 at 15:57, Serhiy Storchaka wrote:
> On 06.04.16 05:44, Nick Coghlan wrote:
>>
>> The most promising option for that is probably "getattr(path, 'path',
>> path)", since the "path" attribute is being added to pathlib, and the
>> given idiom can be readily adopted in Python 2/3 compat
On 04/05/2016 10:50 PM, Serhiy Storchaka wrote:
On 06.04.16 05:44, Nick Coghlan wrote:
The next challenge would then be to make a list of APIs to be updated
for 3.6 to implicitly accept "rich path" objects via the agreed
convention, with pathlib.PurePath used as a test class:
* open()
* codecs.
On Wed, Apr 6, 2016 at 3:37 PM, Stephen J. Turnbull wrote:
> Chris Angelico writes:
>
> > Outside of deliberate tests, we don't create files on our disks
> > whose names are strings of random bytes;
>
> Wishful thinking. First, names made of control characters have often
> been deliberately use
On 6 April 2016 at 15:59, Serhiy Storchaka wrote:
> On 06.04.16 08:52, Greg Ewing wrote:
>>
>> Nick Coghlan wrote:
>>>
>>> The most promising option for that is probably "getattr(path, 'path',
>>> path)",
>>
>>
>> Is there something seriously wrong with str(path)?
>
> What if path is None or bytes
On 04/05/2016 10:40 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
> No, Stephen, that is not what this is about.
Wrong Steven. Spelling matters in email too.
Yes, it absolutely does. My apologies.
-1 Not good enough. I wouldn't do it that often that "ugly" overrides
the reasoning
On 06.04.16 08:52, Greg Ewing wrote:
Nick Coghlan wrote:
The most promising option for that is probably "getattr(path, 'path',
path)",
Is there something seriously wrong with str(path)?
What if path is None or bytes?
___
Python-Dev mailing list
Py
On 06.04.16 05:44, Nick Coghlan wrote:
The most promising option for that is probably "getattr(path, 'path',
path)", since the "path" attribute is being added to pathlib, and the
given idiom can be readily adopted in Python 2/3 compatible code
(since normal strings and any other object without a
Nick Coghlan wrote:
The most promising option for that is probably "getattr(path, 'path',
path)",
Is there something seriously wrong with str(path)?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/py
On 06.04.16 05:44, Nick Coghlan wrote:
The next challenge would then be to make a list of APIs to be updated
for 3.6 to implicitly accept "rich path" objects via the agreed
convention, with pathlib.PurePath used as a test class:
* open()
* codecs.open() (et al)
* io.*
* os.path.*
* other os func
On 6 April 2016 at 15:03, Guido van Rossum wrote:
> On Tue, Apr 5, 2016 at 7:44 PM, Nick Coghlan wrote:
>> Option 4: define a rich-object-to-text path serialisation convention,
>
> Unfortunately that sounds like a classic "serious programming"
> solution (objects, abstractions, serialization, all
Ethan Furman writes:
> No, Stephen, that is not what this is about.
Wrong Steven. Spelling matters in email too. And he's more worth
paying attention to than I am. But I'll have my say anyway. ;-)
> This is about the ugliness of code with str(path) this and
> str(path) that
-1 Not good en
Chris Angelico writes:
> Outside of deliberate tests, we don't create files on our disks
> whose names are strings of random bytes;
Wishful thinking. First, names made of control characters have often
been deliberately used by miscreants to conceal their warez. Second,
in some systems it's al
On 06.04.16 01:41, Brett Cannon wrote:
After a rather extensive discussion on python-ideas about
pathlib.PurePath not inheriting from str, another point that came up was
that the use of pathlib has been rather light. Unfortunately even the
stdlib doesn't really use pathlib because it's currently
On Tue, Apr 5, 2016 at 7:44 PM, Nick Coghlan wrote:
> Option 4: define a rich-object-to-text path serialisation convention,
Unfortunately that sounds like a classic "serious programming"
solution (objects, abstractions, serialization, all big important
words :-).
--
--Guido van Rossum (python.o
On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman wrote:
> [...] we can't do:
>
> app_root = Path(...)
> config = app_root/'settings.cfg'
> with open(config) as blah:
> # whatever
>
> It feels like instead of addressing this basic disconnect, the answer has
> instead been: add that
On 6 April 2016 at 13:06, Alexander Walters wrote:
> I think the naysayers would be satisfied with an object that... while not
> str or bytes or a derived class of either... acted like str when it had to.
> Is that possible without deriving from str or bytes?
Only if the consuming code explicitly
On 04/05/2016 07:40 PM, Steven D'Aprano wrote:
On Tue, Apr 05, 2016 at 11:47:32PM +, Brett Cannon wrote:
To me it seems to basically be a question of whether people can be patient
during a transition and embrace pathlib over time or if they will simply
refuse to add support in libraries an
On 04/05/2016 03:55 PM, Guido van Rossum wrote:
It's been provisional since 3.4. I think if it is still there in 3.6.0
it should be considered no longer provisional. But this may indeed be
a test case for the ultimate fate of provisional modules -- should we
remove it?
We should either remove
On Wed, Apr 6, 2016 at 12:51 PM, Steven D'Aprano wrote:
> On Wed, Apr 06, 2016 at 10:02:30AM +1000, Chris Angelico wrote:
>
>> My personal view on the text/bytes debate is that a path is
>> fundamentally a human concept, and consists therefore of text. The
>> fact that some file systems store (at
On 4/5/2016 22:44, Nick Coghlan wrote:
Option 4: define a rich-object-to-text path serialisation convention,
as paths are not conceptually the same as arbitrary strings
Just as a nit to pick, it is perfectly acceptable for hypothetical path
objects to raise when someone tries to shoehorn them in
Robert Collins writes:
> Sadly that has the ordering bug of assigning __wrapped__ first and appears
> a little unmaintained based on the bug tracker :(
You can fix two problems with one patch, then!
___
Python-Dev mailing list
Python-Dev@python.org
h
R. David Murray writes:
> again. However, the IPV4 address has a poor reputation, and Verizon
> at least appears to be blocking it. So more work is still needed.
Don't take Verizon's policy as meaningful. Tell Verizon customers to
get another address. That is the only solution that works fo
On Wed, Apr 06, 2016 at 10:02:30AM +1000, Chris Angelico wrote:
> My personal view on the text/bytes debate is that a path is
> fundamentally a human concept, and consists therefore of text. The
> fact that some file systems store (at the low level) bytes and some
> store (I think) UTF-16 code uni
On 6 April 2016 at 09:45, Guido van Rossum wrote:
> On Tue, Apr 5, 2016 at 4:13 PM, Chris Angelico wrote:
>> On Wed, Apr 6, 2016 at 9:08 AM, Alexander Walters
>> wrote:
>>> * pathlib should be improved (specifically by making it inherit from str)
>>
>> I'd like to see this specific change settle
I haven't really been following this discussion, but a couple of
comments...
On Tue, Apr 05, 2016 at 11:47:32PM +, Brett Cannon wrote:
> http://www.snarky.ca/why-pathlib-path-doesn-t-inherit-from-str
Nice write-up, thanks.
[...]
> To me it seems to basically be a question of whether peopl
On 6 April 2016 at 11:27, Terry Reedy wrote:
> On 4/5/2016 3:56 PM, R. David Murray wrote:
>>
>> We think we have a partial (and hopefully temporary) solution to the
>> bugs email blockage: ipv6 has been turned off on bugs, so it is sending
>> only from the ipv4 address. Google appears to be acce
On 4/5/2016 7:45 PM, Guido van Rossum wrote:
This does sound like it's the crucial issue, and it is worth writing
up clearly the pros and cons. Let's draft those lists in a thread
(this one's fine) and then add them to the PEP. We can then decide to:
- keep the status quo
- change PurePath to i
On 4/5/2016 3:56 PM, R. David Murray wrote:
We think we have a partial (and hopefully temporary) solution to the
bugs email blockage: ipv6 has been turned off on bugs, so it is sending
only from the ipv4 address. Google appears to be accepting the emails
again. However, the IPV4 address has a p
On Wed, Apr 6, 2016 at 9:45 AM, Guido van Rossum wrote:
> On Tue, Apr 5, 2016 at 4:13 PM, Chris Angelico wrote:
>> On Wed, Apr 6, 2016 at 9:08 AM, Alexander Walters
>> wrote:
>>> * pathlib should be improved (specifically by making it inherit from str)
>>
>> I'd like to see this specific change
On Tue, 5 Apr 2016 at 15:55 Guido van Rossum wrote:
> It's been provisional since 3.4. I think if it is still there in 3.6.0
> it should be considered no longer provisional. But this may indeed be
> a test case for the ultimate fate of provisional modules -- should we
> remove it?
>
> I have to a
On Tue, Apr 5, 2016 at 4:13 PM, Chris Angelico wrote:
> On Wed, Apr 6, 2016 at 9:08 AM, Alexander Walters
> wrote:
>> * pathlib should be improved (specifically by making it inherit from str)
>
> I'd like to see this specific change settled on in the PEP, actually.
> There are some arguments on b
On Wed, Apr 6, 2016 at 9:08 AM, Alexander Walters
wrote:
> * pathlib should be improved (specifically by making it inherit from str)
I'd like to see this specific change settled on in the PEP, actually.
There are some arguments on both sides, and some hybrid solutions
being proposed, and it looks
On 4/5/2016 18:55, Guido van Rossum wrote:
My last/only comment in the discussion
was about there possibly being a dichotomy between people who use
Python for scripting and those who use it to write more substantial
programs (I'm trying not to judge one group more important than
another -- I'm
I think the provisional status can be safely lifted now. Even though
pathlib hasn't seen that much use, there have been enough reports and
discussion since its acception that I think the API has proven it's sane
for general use.
(as for importlib, pathlib might have too many dependencies for san
It's been provisional since 3.4. I think if it is still there in 3.6.0
it should be considered no longer provisional. But this may indeed be
a test case for the ultimate fate of provisional modules -- should we
remove it?
I have to admit I got tired of the discussions and muted them all.
Personall
After a rather extensive discussion on python-ideas about pathlib.PurePath
not inheriting from str, another point that came up was that the use of
pathlib has been rather light. Unfortunately even the stdlib doesn't really
use pathlib because it's currently marked as provisional (or at least
that's
We think we have a partial (and hopefully temporary) solution to the
bugs email blockage: ipv6 has been turned off on bugs, so it is sending
only from the ipv4 address. Google appears to be accepting the emails
again. However, the IPV4 address has a poor reputation, and Verizon
at least appears t
The call has started to go out for sprint groups to list themselves online.
Anyone want to specifically lead the core sprint this year? If no one
specifically does then I will sign us up and do my usual thing of pointing
people at the devguide and encourage people to ask questions but not do a
lot
Since this seems tcl/tk related your best bet is the tkinter mailing
list: https://mail.python.org/mailman/listinfo/tkinter-discuss
On Mon, Apr 4, 2016 at 8:38 PM, Stefan Richthofer
wrote:
> Hey everybody,
>
> I need help/advice for this JyNI-related issue:
> https://github.com/Stewori/JyNI/issu
Sadly that has the ordering bug of assigning __wrapped__ first and appears
a little unmaintained based on the bug tracker :(
On 5 Apr 2016 8:10 PM, "Victor Stinner" wrote:
> See https://pypi.python.org/pypi/functools32 for the functools backport
> for Python 2.7.
>
> Victor
>
See https://pypi.python.org/pypi/functools32 for the functools backport for
Python 2.7.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pyt
44 matches
Mail list logo
