Am 12.05.2013 06:03, schrieb Benjamin Peterson:
The long anticipated emergency 2.7.5 release has now been tagged. It
will be publicly announced as binaries arrive.
Originally, I was just going to cherrypick regression fixes onto the
2.7.4 release and release those as 2.7.5. I started to this
On Fri, 03 May 2013 12:43:41 +1000
Steven D'Aprano st...@pearwood.info wrote:
On 03/05/13 11:29, Nick Coghlan wrote:
An exchange in one of the enum threads prompted me to write down
something I've occasionally thought about regarding locals(): it is
currently severely underspecified, and
On Sun, May 12, 2013 at 10:01 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 03 May 2013 12:43:41 +1000
Steven D'Aprano st...@pearwood.info wrote:
On 03/05/13 11:29, Nick Coghlan wrote:
An exchange in one of the enum threads prompted me to write down
something I've occasionally
On Sun, 12 May 2013 23:22:39 +1000
Nick Coghlan ncogh...@gmail.com wrote:
The exec case
corresponds to those two instances, depending on whether the single
namespace or dual namespace version is performed.
I don't get the point. exec() *passes* a locals dictionary, but the
compiled code itself
On Sun, 12 May 2013 13:24:45 +0200
Georg Brandl g.bra...@gmx.net wrote:
Am 12.05.2013 06:03, schrieb Benjamin Peterson:
The long anticipated emergency 2.7.5 release has now been tagged. It
will be publicly announced as binaries arrive.
Originally, I was just going to cherrypick
On Sun, May 12, 2013 at 11:28 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 12 May 2013 23:22:39 +1000
Nick Coghlan ncogh...@gmail.com wrote:
The exec case
corresponds to those two instances, depending on whether the single
namespace or dual namespace version is performed.
I don't
And if we're creating a custom object instead, why return a 2-tuple
rather than making the entry's name an attribute of the custom object?
To me, that suggests a more reasonable API for os.scandir() might be
for it to be an iterator over dir_entry objects:
name (as a string)
Am 13.05.2013 00:04, schrieb Ben Hoyt:
In fact, I don't think .cached_lstat should be exposed to the user.
They just call entry.lstat(), and it returns a cached stat or calls
os.lstat() to get the real stat if required (and populates the
internal cached stat value). And the entry.is* functions
After the long design effort for the enum module,
I'm sure there will be a forthcoming effort to apply
them pervasively throughout the standard library.
I would like to ask for a little restraint and for there to
be individual cost/benefit evaluations for each case.
On the plus-side, the new
2013/5/13 Ben Hoyt benh...@gmail.com:
class DirEntry:
def __init__(self, name, dirent, lstat, path='.'):
# User shouldn't need to call this, but called internally by scandir()
self.name = name
self.dirent = dirent
self._lstat = lstat # non-public
I would prefer to go the other route and don't expose lstat(). It's
cleaner and less confusing to have a property cached_lstat on the object
because it actually says what it contains. The property's internal code
can do a lstat() call if necessary.
Are you suggesting just accessing
On Mon, May 13, 2013 at 12:11 PM, Victor Stinner
victor.stin...@gmail.com wrote:
2013/5/13 Ben Hoyt benh...@gmail.com:
class DirEntry:
...
def lstat(self):
if self._lstat is None:
self._lstat = os.lstat(os.path.join(self._path, self.name))
return self._lstat
On 05/12/2013 04:49 PM, Raymond Hettinger wrote:
After the long design effort for the enum module,
I'm sure there will be a forthcoming effort to apply
them pervasively throughout the standard library.
I'd like to apply them where it makes sense. It would be a good way for me to learn all
Ethan Furman writes:
I will certainly ask for advice on which modules to spend my time
on. I know enums are not a cure-all, but they are great for
debugging and interactive work.
Especially in new code where they are used throughout. Not so in the
existing stdlib, I expect.
The concrete
Thanks for the insights, Raymond. I don't think anyone is planning on
rushing anything. We still have to get the enum module itself committed and
a serious review process has just started for that, so it will take time.
There's no general let's replace all constants with enums TODO item that
I
On 05/12/2013 08:15 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
I will certainly ask for advice on which modules to spend my time
on. I know enums are not a cure-all, but they are great for
debugging and interactive work.
Especially in new code where they are used throughout.
16 matches
Mail list logo
