26.06.14 02:28, Nick Coghlan написав(ла):
OK, *that* sounds like an excellent reason to keep the Unicode disabled
builds functional, and make sure they stay that way with a buildbot: to
help make sure we're not accidentally running afoul of the implicit
interoperability between str and unicode wh
Le 25/06/2014 19:28, Nick Coghlan a écrit :
OK, *that* sounds like an excellent reason to keep the Unicode disabled
builds functional, and make sure they stay that way with a buildbot: to
help make sure we're not accidentally running afoul of the implicit
interoperability between str and unicode
On Thu, Jun 26, 2014 at 9:04 PM, Antoine Pitrou wrote:
> For the same reason, I agree with Victor that we should ditch the
> threading-disabled builds. It's too much of a hassle for no actual,
> practical benefit. People who want a threadless unicodeless Python can
> install Python 1.5.2 for all I
On Wed, Jun 25, 2014, at 23:38, Ned Deily wrote:
> In article <53ab53a7.6050...@jcea.es>, Jesus Cea wrote:
>
> > On 25/06/14 20:35, Ned Deily wrote:
> > > The 3.3 branch is open only to security fixes. Please don't backport
> > > other patches to there.
> > >
> > > https://docs.python.org/devgu
Hello python devs,
I was recently in need of some faster caching and thought this would be a
good opportunity to familiarize myself with the Python/C api so I wrote a C
extension for the lru_cache in functools. The source is at
https://github.com/pbrady/fastcache.git and I've posted it as a packa
You might look at https://bugs.python.org/issue14373
On Thu, Jun 26, 2014, at 08:38, Peter Brady wrote:
> Hello python devs,
>
> I was recently in need of some faster caching and thought this would be a
> good opportunity to familiarize myself with the Python/C api so I wrote a
> C
> extension fo
Looks like it's already in the works! Nevermind
On Thu, Jun 26, 2014 at 10:33 AM, Benjamin Peterson
wrote:
> You might look at https://bugs.python.org/issue14373
>
> On Thu, Jun 26, 2014, at 08:38, Peter Brady wrote:
> > Hello python devs,
> >
> > I was recently in need of some faster caching
I'm an advocate of getting users and projects to move to modern Python
versions. I believe dropping support for end-of-lifed Python versions is
important for the health of the Python community. If you've done any
amount of Python 3 porting work, you know things get much harder the
more 2.x lega
Le 26/06/2014 20:34, Gregory Szorc a écrit :
I'm an advocate of getting users and projects to move to modern Python
versions. I believe dropping support for end-of-lifed Python versions is
important for the health of the Python community. If you've done any
amount of Python 3 porting work, you kn
I have a little pet project for building rpm of python 2.7 (it should be
trivial to port to 3.x):
https://build.opensuse.org/project/show/home:cavallo71:opt-python-modules
If there's enough interest I can help to integrate with python.org.
>> I understand there may be technical challenges wit
Le 26/06/2014 22:00, Antonio Cavallo a écrit :
> Of course Anaconda is oriented towards scientific applications but it is
> a proof that a pre-build binary installer works and can be simple to
use.
Rpm are the "blessed" way to instal software on linux: it supports what
most sysadmin expect (ea
Hi Python dev folks,
I've written a PEP proposing a specific os.scandir() API for a
directory iterator that returns the stat-like info from the OS, the
main advantage of which is to speed up os.walk() and similar
operations between 4-20x, depending on your OS and file system. Full
details, backgro
On 2014-06-26 23:59, Ben Hoyt wrote:
Hi Python dev folks,
I've written a PEP proposing a specific os.scandir() API for a
directory iterator that returns the stat-like info from the OS, the
main advantage of which is to speed up os.walk() and similar
operations between 4-20x, depending on your OS
On 27 June 2014 09:28, MRAB wrote:
> Personally, I'd prefer the name 'iterdir' because it emphasises that
> it's an iterator.
Exactly what I was going to post (with the added note that thee's an
obvious symmetry with listdir).
+1 for iterdir rather than scandir
Other than that:
+1 for adding
Hello,
On Thu, 26 Jun 2014 18:59:45 -0400
Ben Hoyt wrote:
> Hi Python dev folks,
>
> I've written a PEP proposing a specific os.scandir() API for a
> directory iterator that returns the stat-like info from the OS, the
> main advantage of which is to speed up os.walk() and similar
> operations b
On 06/26/2014 04:36 PM, Tim Delaney wrote:
On 27 June 2014 09:28, MRAB wrote:
Personally, I'd prefer the name 'iterdir' because it emphasises that
it's an iterator.
Exactly what I was going to post (with the added note that thee's an obvious
symmetry with listdir).
+1 for iterdir rather tha
On Thu, Jun 26, 2014, at 17:07, Paul Sokolovsky wrote:
>
> With my MicroPython hat on, os.scandir() would make things only worse.
> With current interface, one can either have inefficient implementation
> (like CPython chose) or efficient implementation (like MicroPython
> chose) - all transparent
Hello,
On Thu, 26 Jun 2014 17:35:21 -0700
Benjamin Peterson wrote:
> On Thu, Jun 26, 2014, at 17:07, Paul Sokolovsky wrote:
> >
> > With my MicroPython hat on, os.scandir() would make things only
> > worse. With current interface, one can either have inefficient
> > implementation (like CPython
+1 for scandir.
-1 for iterdir(scandir sounds fancier).
- for windows_wildcard.
Tim Delaney wrote:
>On 27 June 2014 09:28, MRAB wrote:
>
>> Personally, I'd prefer the name 'iterdir' because it emphasises that
>> it's an iterator.
>
>
>Exactly what I was going to post (with the added note
I don't mind iterdir() and would take it :-), but I'll just say why I
chose the name scandir() -- though it wasn't my suggestion originally:
iterdir() sounds like just an iterator version of listdir(), kinda
like keys() and iterkeys() in Python 2. Whereas in actual fact the
return values are quite
On 2014-06-27 02:37, Ben Hoyt wrote:
I don't mind iterdir() and would take it :-), but I'll just say why I
chose the name scandir() -- though it wasn't my suggestion originally:
iterdir() sounds like just an iterator version of listdir(), kinda
like keys() and iterkeys() in Python 2. Whereas in
> os.listdir() when I worked on "os" module for MicroPython. I essentially
> did what your PEP suggests - introduced internal generator function
> (ilistdir_ex() in
> https://github.com/micropython/micropython-lib/blob/master/os/os/__init__.py#L85
> ), in terms of which both os.listdir() and os.wal
+1 on getting this in for 3.5.
If the only objection people are having is the stupid paint color of the
name I don't care what it's called! scandir matches the libc API of the
same name. iterdir also makes sense to anyone reading it. Whoever checks
this in can pick one and be done with it. We
On Fri, Jun 27, 2014 at 03:07:46AM +0300, Paul Sokolovsky wrote:
> With my MicroPython hat on, os.scandir() would make things only worse.
> With current interface, one can either have inefficient implementation
> (like CPython chose) or efficient implementation (like MicroPython
> chose) - all tra
On Thu, Jun 26, 2014 at 09:37:50PM -0400, Ben Hoyt wrote:
> I don't mind iterdir() and would take it :-), but I'll just say why I
> chose the name scandir() -- though it wasn't my suggestion originally:
>
> iterdir() sounds like just an iterator version of listdir(), kinda
> like keys() and iterke
I'm generally +1, with opinions noted below on these two topics.
On 6/26/2014 3:59 PM, Ben Hoyt wrote:
Should there be a way to access the full path?
--
Should ``DirEntry``'s have a way to get the full path without using
``os.path.join(path, entry.nam
On 26 June 2014 23:59, Ben Hoyt wrote:
> Would love feedback on the PEP, but also of course on the proposal itself.
A solid +1 from me.
Some specific points:
- I'm in favour of it being in the os module. It's more discoverable
there, as well as the other reasons mentioned.
- I prefer scandir as
27 matches
Mail list logo
