In article 53ab53a7.6050...@jcea.es, Jesus Cea j...@jcea.es 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/devguide/devcycle.html#summary
Ned, I am aware. It is a
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
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
On Thu, Jun 26, 2014 at 9:04 PM, Antoine Pitrou anto...@python.org 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
On Wed, Jun 25, 2014, at 23:38, Ned Deily wrote:
In article 53ab53a7.6050...@jcea.es, Jesus Cea j...@jcea.es 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.
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
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 for the
Looks like it's already in the works! Nevermind
On Thu, Jun 26, 2014 at 10:33 AM, Benjamin Peterson benja...@python.org
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
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
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
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 with
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 (easy
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,
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
On 27 June 2014 09:28, MRAB pyt...@mrabarnett.plus.com 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
Hello,
On Thu, 26 Jun 2014 18:59:45 -0400
Ben Hoyt benh...@gmail.com 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
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
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 transparently.
+1 for scandir.
-1 for iterdir(scandir sounds fancier).
- for windows_wildcard.
Tim Delaney timothy.c.dela...@gmail.com wrote:
On 27 June 2014 09:28, MRAB pyt...@mrabarnett.plus.com wrote:
Personally, I'd prefer the name 'iterdir' because it emphasises that
it's an iterator.
Exactly
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
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.walk()
+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
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 iterkeys()
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,
26 matches
Mail list logo
