On 25 November 2013 03:18, Ben Hoyt wrote:
> d_ino -- can a non-Windows dev tell me how or when d_ino would be
> useful? If it's useful, is it useful in a higher-level, cross-platform
> API such as scandir()?
OK, so I'm a Windows dev, but my understanding is that d_ino is useful
to tell if two fi
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
> The idea of the rich stat result object is that has all that info
> prepopulated, based on an initial stat call. "Caching" it amounts to "keep a
> reference to it".
>
> It is suggested that it would be a subset of the pathlib.Path API:
> http://bugs.python.org/issue19725
>
> If it's also a supers
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
On 25 Nov 2013 09:31, "Ben Hoyt" wrote:
>
> > It's also quite likely the "rich stat object" API will be pursued for
3.5,
> > which is a much safer approach to stat result caching than trying to
embed
> > it directly in pathlib.Path objects.
>
> As a Windows dev, I'm not sure I love the "rich stat
> 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
> I think we should think hard and deep about all the consequences. I was
> initially in favor of stat caching, but during offline review of PEP 428
> Nick pointed out that there are too many different ways to do stat caching,
> and convinced me that it would be wrong to rush it. Now that beta 1 is
Antoine's class-global flag seems like a bad idea.
> A global string (or Path) keyed cache (rather than a per-object cache) would
> actually be a safer option, since it would ensure distinct path objects
> always gave the same answer. That's the approach I will likely pursue at
> some point in wal
On Sun, Nov 24, 2013 at 3:04 PM, Ben Hoyt wrote:
> > Right now, pathlib doesn't cache. Guido decided it was safer to start
> > off like that, and perhaps later we can add some optional caching.
> >
> > One reason caching didn't go in is that it's not clear which API is
> > best. Working on pluggi
On 25 Nov 2013 09:07, "Ben Hoyt" wrote:
>
> > Right now, pathlib doesn't cache. Guido decided it was safer to start
> > off like that, and perhaps later we can add some optional caching.
> >
> > One reason caching didn't go in is that it's not clear which API is
> > best. Working on pluggin scandi
In article <529276f0.3040...@hastings.org>,
Larry Hastings wrote:
> On behalf of the Python development team, it's my privilege to announce
> the first beta release of Python 3.4.
>
> This is a preview release, and its use is not recommended for
> production settings.
Note to users of the pytho
On Mon, 25 Nov 2013 12:04:28 +1300
Ben Hoyt wrote:
> > Right now, pathlib doesn't cache. Guido decided it was safer to start
> > off like that, and perhaps later we can add some optional caching.
> >
> > One reason caching didn't go in is that it's not clear which API is
> > best. Working on plugg
>> 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
> Right now, pathlib doesn't cache. Guido decided it was safer to start
> off like that, and perhaps later we can add some optional caching.
>
> One reason caching didn't go in is that it's not clear which API is
> best. Working on pluggin scandir() into pathlib would actually help
> choosing a sta
> 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
On Mon, 25 Nov 2013 11:20:08 +1300
Ben Hoyt wrote:
>
> This mainly depends on how Path is going to cache stat information. If
> it caches it, then this will just work. Sounds like Guido's opinion
> was that both cached and uncached use cases are important, but that it
> should be very clear which
On 11/24/2013 02:00 PM, Larry Hastings wrote:
Python 3.4 includes a range of improvements of the 3.x series, including
hundreds of small improvements and bug fixes. Major new features and
changes in the 3.4 release series include:
Whoops, sorry, I missed a couple of PEPs there:
* PEP 428, a "
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
Hi folks,
I decided to start another thread for my thoughts on the interaction
between pathlib (Antoine's new PEP 428), issue 11406 (proposal for a
directory iterator returning stat-like info), and my own scandir
library, which implements something along the lines of issue 11406.
My scandir libra
On behalf of the Python development team, it's my privilege to announce
the first beta release of Python 3.4.
This is a preview release, and its use is not recommended for
production settings.
Python 3.4 includes a range of improvements of the 3.x series, including
hundreds of small improvement
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 Nov 24, 2013, at 06:02 PM, Antoine Pitrou wrote:
>If the hardware is not supported anymore, and since the machine was
>rather slow, I agree it's ok to let it go.
Done!
(The machine's name was 'hope', so now we're hope-less :).
-Barry
___
Python-Dev
On Sun, 24 Nov 2013 11:47:42 -0500
Barry Warsaw wrote:
> On Nov 23, 2013, at 11:01 PM, Gregory P. Smith wrote:
>
> >http://buildbot.python.org/all/buildslaves/gps-ubuntu-exynos5-armv7l
>
> Cool thanks. Antoine, do you still want or need my buildbot, or can I take it
> off-line? (FWIW, because
On Nov 23, 2013, at 11:01 PM, Gregory P. Smith wrote:
>http://buildbot.python.org/all/buildslaves/gps-ubuntu-exynos5-armv7l
Cool thanks. Antoine, do you still want or need my buildbot, or can I take it
off-line? (FWIW, because the hardware is no longer supported, it's pretty
much stuck at Ubunt
On Nov 23, 2013, at 11:13 PM, Gregory P. Smith wrote:
>our buildbots are setup to configure --with-pydebug which also
>unfortunately causes them to compile with -O0... this results in a python
>binary that is excruciatingly slow and makes the entire test suite run take
>a long time.
It would be f
Please refrain from checking in any new features to Python trunk until
after the 3.4 release branch is created (which will be a few months).
Instead, let's concentrate our efforts on polishing Python 3.4 until
it's the best and most-defect-free release yet!
Thanks,
//arry/
__
On Sun, Nov 24, 2013 at 6:12 AM, anatoly techtonik wrote:
> On Sun, Nov 24, 2013 at 12:43 PM, Nick Coghlan wrote:
> >
> > On 24 Nov 2013 17:15, "Gregory P. Smith" wrote:
> >>
> >> our buildbots are setup to configure --with-pydebug which also
> >> unfortunately causes them to compile with -O0...
On Sun, Nov 24, 2013 at 12:43 PM, Nick Coghlan wrote:
>
> On 24 Nov 2013 17:15, "Gregory P. Smith" wrote:
>>
>> our buildbots are setup to configure --with-pydebug which also
>> unfortunately causes them to compile with -O0... this results in a python
>> binary that is excruciatingly slow and mak
On Sun, 24 Nov 2013 05:58:24 +0100 (CET)
alexandre.vassalotti wrote:
> http://hg.python.org/cpython/rev/a68c303eb8dc
> changeset: 87486:a68c303eb8dc
> user:Alexandre Vassalotti
> date:Sat Nov 23 20:58:24 2013 -0800
> summary:
> Disable annoying tests which doesn't work optimiz
On 24 Nov 2013 17:15, "Gregory P. Smith" wrote:
>
> our buildbots are setup to configure --with-pydebug which also
unfortunately causes them to compile with -O0... this results in a python
binary that is excruciatingly slow and makes the entire test suite run take
a long time.
>
> given that nobod
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
33 matches
Mail list logo
