Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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 >

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] thoughts on backporting __wrapped__ to 2.7?

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

[Python-Dev] bugs.python.org email blockage at gmail

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] bugs.python.org email blockage at gmail

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] bugs.python.org email blockage at gmail

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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

Re: [Python-Dev] When should pathlib stop being provisional?

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.

[Python-Dev] When should pathlib stop being provisional?

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

[Python-Dev] bugs.python.org email blockage at gmail

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

[Python-Dev] Anyone want to lead the sprints at PyCon US 2016?

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

Re: [Python-Dev] Help/advice needed with JyNI issue #4 (Tkinter on OSX)

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: >

Re: [Python-Dev] thoughts on backporting __wrapped__ to 2.7?

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. > >

Re: [Python-Dev] thoughts on backporting __wrapped__ to 2.7?

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: