2013/11/25 Greg Ewing :
> Ben Hoyt wrote:
>>
>> However, it seems there was no further discussion about why not
>> "extension" and "extensions"? I have never heard a filename extension
>> being called a "suffix".
>
>
> You can't have read many unix man pages, then! I just
> searched for "suffix" in
25.11.13 01:35, Nick Coghlan написав(ла):
Using "**" for directory spanning globs is also another case of us
borrowing a reasonably common idiom from *nix systems that may not be
familiar to Windows users.
Rather from Java world.
___
Python-Dev mail
On 25 Nov 2013 09:42, "Ben Hoyt" wrote:
>
> > Using "**" for directory spanning globs is also another case of us
borrowing
> > a reasonably common idiom from *nix systems that may not be familiar to
> > Windows users.
>
> Okay, *nix wins then. :-) Python's stdlib is already fairly
> *nix-oriented
> Using "**" for directory spanning globs is also another case of us borrowing
> a reasonably common idiom from *nix systems that may not be familiar to
> Windows users.
Okay, *nix wins then. :-) Python's stdlib is already fairly
*nix-oriented (even when it's being cross-platform), so I guess it's
On 25 Nov 2013 09:14, "Ben Hoyt" wrote:
>
> >> 4) Is path_obj.glob() recursive? In the PEP it looks like it is if the
> >> pattern starts with '**',
> >
> >
> > I don't think it has to *start* with **. Rather, the ** is
> > a pattern that can span directory separators. It's not a
> > flag that app
>> However, it seems there was no further discussion about why not
>> "extension" and "extensions"? I have never heard a filename extension
>> being called a "suffix".
>
>
> You can't have read many unix man pages, then!
Huh, no I haven't! Certainly not regularly, as I'm almost exclusively
a Windo
Ben Hoyt wrote:
However, it seems there was no further discussion about why not
"extension" and "extensions"? I have never heard a filename extension
being called a "suffix".
You can't have read many unix man pages, then! I just
searched for "suffix" in the gcc man page, and found
this:
Fo
> Well, "path" is much too common already, and it's an obvious variable
> name for a filesystem path, so "pathlib" is better to avoid name
> clashes.
Yep, that makes total sense, thanks.
>> However, it seems there was no further discussion about why not
>> "extension" and "extensions"? I have nev
Hello,
On Mon, 25 Nov 2013 11:00:09 +1300
Ben Hoyt wrote:
>
> 1) Someone on reddit.com/r/Python asked "Is the import going to be
> 'pathlib'? I thought the renaming going on of std lib things with the
> transition to Python 3 sought to remove the spurious usage of
> appending 'lib' to libs?" I
PEP 428 looks nice. Thanks, Antoine!
I have a couple of questions about the module name and API. I think
I've read through most of the previous discussion, but may have missed
some, so please point me to the right place if there have already been
discussions about these things.
1) Someone on redd
On 24 Nov 2013 01:21, "Antoine Pitrou" wrote:
>
> On Sat, 23 Nov 2013 15:32:58 +0200
> Serhiy Storchaka wrote:
> > 22.11.13 18:44, Antoine Pitrou написав(ла):
> > > I've pushed pathlib to the repository. I'm hopeful there won't be
> > > new buildbot failures because of it, but still, there may be
On Sat, 23 Nov 2013 15:32:58 +0200
Serhiy Storchaka wrote:
> 22.11.13 18:44, Antoine Pitrou написав(ла):
> > I've pushed pathlib to the repository. I'm hopeful there won't be
> > new buildbot failures because of it, but still, there may be some
> > platform-specific issues I'm unaware of.
>
> Con
I'd vote for a different perspective on path handling. For me the
pathlib is not the
good way to go. Especially with copying ill behaviour of old os.path functions.
We definitely need a "task force page" dedicated to "working with paths in
Python" to collaborate. ML + PEP with privileged write acc
22.11.13 18:44, Antoine Pitrou написав(ла):
I've pushed pathlib to the repository. I'm hopeful there won't be
new buildbot failures because of it, but still, there may be some
platform-specific issues I'm unaware of.
Congratuate Antoine!
Does it means that issues #11344 (Add os.path.splitpath(
On Fri, 22 Nov 2013 17:44:55 +0100
Antoine Pitrou wrote:
>
> I've pushed pathlib to the repository. I'm hopeful there won't be
> new buildbot failures because of it, but still, there may be some
> platform-specific issues I'm unaware of.
Actually, there turn out to be two platform-specific issue
It was too fast. I didn't had a chance to send the comments.
--
anatoly t.
On Fri, Nov 22, 2013 at 7:44 PM, Antoine Pitrou wrote:
>
> Hello,
>
> I've pushed pathlib to the repository. I'm hopeful there won't be
> new buildbot failures because of it, but still, there may be some
> platform-specif
2013/11/22 Antoine Pitrou :
> I've pushed pathlib to the repository. I'm hopeful there won't be
> new buildbot failures because of it, but still, there may be some
> platform-specific issues I'm unaware of.
A PEP wouldn't be successful if it doesn't break any buildbot. PEP 451
was successful, as y
Hello,
I've pushed pathlib to the repository. I'm hopeful there won't be
new buildbot failures because of it, but still, there may be some
platform-specific issues I'm unaware of.
I hope our Release Manager is doing ok :-)
Regards
Antoine.
___
Pyth
On Wed, Nov 20, 2013 at 5:41 PM, Mark Lawrence wrote:
> On 20/11/2013 22:01, Antoine Pitrou wrote:
>
>>
>> pathlib imports many modules at startup, so for scripts for which
>> startup time is critical using os.path may still be the best option.
>>
>>
> Will there be or is there a note to this effe
On Nov 20, 2013, at 4:53 PM, Antoine Pitrou wrote:
>
> When pathlib-in-the-stdlib stabilizes, I plan to release a pathlib 1.0
> on PyPI that will integrate the PEP's API.
Great, thanks!
Chris
> In the meantime, if you don't mind installing from VCS, you clone the
> Mercurial repo (https://bi
On Thu, 21 Nov 2013 01:51:59 +0100
Antoine Pitrou wrote:
> On Wed, 20 Nov 2013 14:43:26 -0800
> Chris Barker wrote:
> >
> > By the way, for us dinosaurs is this going to exactly match the
> > pathlib implementation that can be used with py2?
>
> pathlib up to 0.8 (on PyPI) has a different API
On Wed, 20 Nov 2013 14:43:26 -0800
Chris Barker wrote:
>
> By the way, for us dinosaurs is this going to exactly match the
> pathlib implementation that can be used with py2?
pathlib up to 0.8 (on PyPI) has a different API - since there were so
many changes done as part of the release process.
On Wed, Nov 20, 2013 at 1:39 PM, Giampaolo Rodola' wrote:
> Isn't this redundant?
>
> >>> Path.cwd()
> PosixPath('/home/antoine/pathlib')
>
> Probably this is just personal taste but I'd prefer the more explicit:
>
> >>> Path(os.getcwd())
> PosixPath('/home/antoine/pathlib')
>
> I understand all t
On 20/11/2013 22:01, Antoine Pitrou wrote:
pathlib imports many modules at startup, so for scripts for which
startup time is critical using os.path may still be the best option.
Will there be or is there a note to this effect in the docs?
--
Python is the second best programming language in
On Wed, 20 Nov 2013 13:42:42 -0800
Guido van Rossum wrote:
> On Tue, Nov 19, 2013 at 1:04 PM, Antoine Pitrou wrote:
>
> > Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> > latest amended form. Here is the last call for any comments or
> > arguments against approval, be
On Wed, 20 Nov 2013 13:42:42 -0800
Guido van Rossum wrote:
> On Tue, Nov 19, 2013 at 1:04 PM, Antoine Pitrou wrote:
>
> > Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> > latest amended form. Here is the last call for any comments or
> > arguments against approval, be
On Tue, Nov 19, 2013 at 1:04 PM, Antoine Pitrou wrote:
> Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> latest amended form. Here is the last call for any comments or
> arguments against approval, before Guido marks the PEP accepted (or
> changes his mind :-)).
>
Cong
On Tue, Nov 19, 2013 at 10:04 PM, Antoine Pitrou wrote:
>
> Hello,
>
> Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> latest amended form. Here is the last call for any comments or
> arguments against approval, before Guido marks the PEP accepted (or
> changes his mind
Am 20.11.13 17:04, schrieb Eric V. Smith:
> I think the confusion comes from the difference between what NTFS can do
> and what the Win32 (or whatever it's now called) layer allows you to do.
> Rumor has it that the old Posix subsystem allowed NTFS to create 2 files
> in the same directory that dif
On 2013-11-20, at 17:09 , Guido van Rossum wrote:
> On Wed, Nov 20, 2013 at 6:01 AM, Ethan Furman wrote:
> On 11/20/2013 04:25 AM, Garth Bushell wrote:
>
> I'm also quite uneasy on the case insensitive comparison on Windows as the
> File system NTFS is case sensitive.
>
> No, it's case-preser
On Wed, Nov 20, 2013 at 6:01 AM, Ethan Furman wrote:
> On 11/20/2013 04:25 AM, Garth Bushell wrote:
>
>>
>> I'm also quite uneasy on the case insensitive comparison on Windows as
>> the File system NTFS is case sensitive.
>>
>
> No, it's case-preserving.
>
It's quite possible that you are both r
On 11/20/2013 09:01 AM, Ethan Furman wrote:
> On 11/20/2013 04:25 AM, Garth Bushell wrote:
>>
>> I'm also quite uneasy on the case insensitive comparison on Windows as
>> the File system NTFS is case sensitive.
>
> No, it's case-preserving.
>
>> """Current Windows file systems, like NTFS, are cas
On Wed, Nov 20, 2013 at 4:49 AM, Antoine Pitrou wrote:
> On Wed, 20 Nov 2013 12:25:20 +
> Garth Bushell wrote:
> >
> > I'm also quite uneasy on the case insensitive comparison on Windows as
> the
> > File system NTFS is case sensitive.
> >
> > """Current Windows file systems, like NTFS, are
On 11/20/2013 04:25 AM, Garth Bushell wrote:
I'm also quite uneasy on the case insensitive comparison on Windows as the File
system NTFS is case sensitive.
No, it's case-preserving.
"""Current Windows file systems, like NTFS, are case-sensitive; that is a
readme.txt and a Readme.txt can ex
On Wed, 20 Nov 2013 12:25:20 +
Garth Bushell wrote:
>
> I'm also quite uneasy on the case insensitive comparison on Windows as the
> File system NTFS is case sensitive.
>
> """Current Windows file systems, like NTFS, are case-sensitive; that is a
> readme.txt and a Readme.txt can exist in th
I've noticed in pathlib.py the following error on line 39
if sys.getwindowsversion()[:2] >= (6, 0) and sys.version_info >= (3, 2):
it should be:-
if sys.getwindowsversion()[2:] >= (6, 0) and sys.version_info >= (3, 2):
I'm also quite uneasy on the case insensitive comparison on Windows as the
F
On Tue, 19 Nov 2013 17:02:15 -0500
Brett Cannon wrote:
> On Tue, Nov 19, 2013 at 4:04 PM, Antoine Pitrou wrote:
>
> >
> > Hello,
> >
> > Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> > latest amended form. Here is the last call for any comments or
> > arguments again
On Tue, Nov 19, 2013 at 4:04 PM, Antoine Pitrou wrote:
>
> Hello,
>
> Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> latest amended form. Here is the last call for any comments or
> arguments against approval, before Guido marks the PEP accepted (or
> changes his mind
Hello,
Guido has told me that he was ready to approve PEP 428 (pathlib) in its
latest amended form. Here is the last call for any comments or
arguments against approval, before Guido marks the PEP accepted (or
changes his mind :-)).
Regards
Antoine.
__
Le Tue, 17 Sep 2013 18:10:53 -0700,
Philip Jenvey a écrit :
>
> On Sep 16, 2013, at 1:05 PM, Antoine Pitrou wrote:
>
> > On Mon, 16 Sep 2013 15:48:54 -0400
> > Brett Cannon wrote:
> >>>
> >>> So I would like to propose the following API change:
> >>>
> >>> - Path.stat() (and stat-accessing me
On 18 September 2013 11:10, Philip Jenvey wrote:
>
> On Sep 16, 2013, at 1:05 PM, Antoine Pitrou wrote:
>
>> On Mon, 16 Sep 2013 15:48:54 -0400
>> Brett Cannon wrote:
So I would like to propose the following API change:
- Path.stat() (and stat-accessing methods such as get_mti
On Sep 16, 2013, at 1:05 PM, Antoine Pitrou wrote:
> On Mon, 16 Sep 2013 15:48:54 -0400
> Brett Cannon wrote:
>>>
>>> So I would like to propose the following API change:
>>>
>>> - Path.stat() (and stat-accessing methods such as get_mtime()...)
>>> returns an uncached stat object by default
>
Terry Reedy writes:
> On 9/16/2013 4:14 PM, R. David Murray wrote:
>
> > Well, we tend to avoid single boolean arguments in favor of differently
> > named functions.
>
> The stdlib has lots of boolean arguments. My impression is that they are
> to be avoided when they would change the ret
On 17 Sep 2013 06:45, "Antoine Pitrou" wrote:
>
> On Mon, 16 Sep 2013 16:14:43 -0400
> "R. David Murray" wrote:
> > On Mon, 16 Sep 2013 15:48:54 -0400, Brett Cannon
wrote:
> > > On Mon, Sep 16, 2013 at 3:45 PM, Antoine Pitrou
wrote:
> > > > So I would like to propose the following API change:
>
On Mon, 16 Sep 2013 16:14:43 -0400
"R. David Murray" wrote:
> On Mon, 16 Sep 2013 15:48:54 -0400, Brett Cannon wrote:
> > On Mon, Sep 16, 2013 at 3:45 PM, Antoine Pitrou wrote:
> > > So I would like to propose the following API change:
> > >
> > > - Path.stat() (and stat-accessing methods such a
On 9/16/2013 4:14 PM, R. David Murray wrote:
Well, we tend to avoid single boolean arguments in favor of differently
named functions.
The stdlib has lots of boolean arguments. My impression is that they are
to be avoided when they would change the return type or otherwise do
something disjoi
On Mon, 16 Sep 2013 15:48:54 -0400, Brett Cannon wrote:
> On Mon, Sep 16, 2013 at 3:45 PM, Antoine Pitrou wrote:
> > So I would like to propose the following API change:
> >
> > - Path.stat() (and stat-accessing methods such as get_mtime()...)
> > returns an uncached stat object by default
> >
On Mon, Sep 16, 2013 at 3:45 PM, Antoine Pitrou wrote:
> On Mon, 16 Sep 2013 19:06:37 +0200
> Charles-François Natali wrote:
> > 2013/9/16 Antoine Pitrou :
> > > Le Sun, 15 Sep 2013 06:46:08 -0700,
> > > Ethan Furman a écrit :
> > >> I see PEP 428 is both targeted at 3.4 and still in draft stat
2013/9/16 Brett Cannon :
> Any reason why stat() can't get a keyword-only cached=True argument instead?
> Or have stat() never cache() but stat_cache() always so that people can
> choose if they want fresh or cached based on API and not whether some
> library happened to make a decision for them?
On Mon, 16 Sep 2013 15:48:54 -0400
Brett Cannon wrote:
> >
> > So I would like to propose the following API change:
> >
> > - Path.stat() (and stat-accessing methods such as get_mtime()...)
> > returns an uncached stat object by default
> >
> > - Path.cache_stat() can be called to return the sta
On Mon, 16 Sep 2013 19:06:37 +0200
Charles-François Natali wrote:
> 2013/9/16 Antoine Pitrou :
> > Le Sun, 15 Sep 2013 06:46:08 -0700,
> > Ethan Furman a écrit :
> >> I see PEP 428 is both targeted at 3.4 and still in draft status.
> >>
> >> What remains to be done to ask for pronouncement?
> >
>
2013/9/16 Antoine Pitrou :
> Le Sun, 15 Sep 2013 06:46:08 -0700,
> Ethan Furman a écrit :
>> I see PEP 428 is both targeted at 3.4 and still in draft status.
>>
>> What remains to be done to ask for pronouncement?
>
> I think I have a couple of items left to integrate in the PEP.
> Mostly it needs
I hope there is a volunteer for delegate.
--Guido van Rossum (sent from Android phone)
On Sep 16, 2013 1:17 AM, "Antoine Pitrou" wrote:
> Le Sun, 15 Sep 2013 06:46:08 -0700,
> Ethan Furman a écrit :
> > I see PEP 428 is both targeted at 3.4 and still in draft status.
> >
> > What remains to be
Le Sun, 15 Sep 2013 06:46:08 -0700,
Ethan Furman a écrit :
> I see PEP 428 is both targeted at 3.4 and still in draft status.
>
> What remains to be done to ask for pronouncement?
I think I have a couple of items left to integrate in the PEP.
Mostly it needs me to take a bit of time and finalize
I see PEP 428 is both targeted at 3.4 and still in draft status.
What remains to be done to ask for pronouncement?
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://ma
55 matches
Mail list logo
