Re: [Python-Dev] 2.7.5 baking
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 but ran > into some conflicts. Since we don't have buildbot testing of release > branches, I decided it would be best to just cut from the maintenance > branch. 3.2.5 and 3.3.2 are coming along as well. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tightening up the specification for locals()
On Fri, 03 May 2013 12:43:41 +1000 Steven D'Aprano 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 I'd like to make the current > > CPython behaviour part of the language/library specification. (We > > recently found a bug in the interaction between the __prepare__ method > > and lexical closures that was indirectly related to this > > underspecification) > > Fixing the underspecification is good. Enshrining a limitation as the > one correct way, not so good. I have to say, I agree with Steven here. Mutating locals() is currently an implementation detail, and it should IMHO stay that way. Only reading a non-mutated locals() should be well-defined. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tightening up the specification for locals()
On Sun, May 12, 2013 at 10:01 PM, Antoine Pitrou wrote: > On Fri, 03 May 2013 12:43:41 +1000 > Steven D'Aprano 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 I'd like to make the current >> > CPython behaviour part of the language/library specification. (We >> > recently found a bug in the interaction between the __prepare__ method >> > and lexical closures that was indirectly related to this >> > underspecification) >> >> Fixing the underspecification is good. Enshrining a limitation as the >> one correct way, not so good. > > I have to say, I agree with Steven here. Mutating locals() is currently > an implementation detail, and it should IMHO stay that way. Only > reading a non-mutated locals() should be well-defined. At global and class scope (and, equivalently, in exec), I strongly disagree. There, locals() is (or should be) well defined, either as identical to globals(), as the value returned from __prepare__() (and will be passed to the metaclass as the namespace). The exec case corresponds to those two instances, depending on whether the single namespace or dual namespace version is performed. What Steven was objecting to was my suggestion that CPython's current behaviour where mutating locals() may not change the local namespace be elevated to an actual requirement where mutating locals *must not* change the local namespace. He felt that was overspecifying a CPython-specific limitation, and I think he's right - at function scope, the best we can say is that modifying the result of locals() may or may not make those changes visible to other code in that function (or closures that reference the local variables in that function). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tightening up the specification for locals()
On Sun, 12 May 2013 23:22:39 +1000 Nick Coghlan 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 isn't expected to use locals() as a way to access (let alone mutate) that dictionary. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.7.5 baking
On Sun, 12 May 2013 13:24:45 +0200 Georg Brandl 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 regression fixes onto the > > 2.7.4 release and release those as 2.7.5. I started to this but ran > > into some conflicts. Since we don't have buildbot testing of release > > branches, I decided it would be best to just cut from the maintenance > > branch. > > 3.2.5 and 3.3.2 are coming along as well. 3.3.2 can't be released before http://bugs.python.org/issue17962 is fixed. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tightening up the specification for locals()
On Sun, May 12, 2013 at 11:28 PM, Antoine Pitrou wrote: > On Sun, 12 May 2013 23:22:39 +1000 > Nick Coghlan 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 isn't expected to use locals() as a way to access > (let alone mutate) that dictionary. Right, the main reason for the proposal is to lock down "locals() is globals()" for module namespaces and "locals() is the namespace that was returned from __prepare__ and will be passed to the metaclass constructor" for class bodies. The change to exec merely follows because the single argument form corresponds to module execution and the two argument form to class body execution. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info
> 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) > is_file() > is_dir() > is_link() > stat() > cached_stat (None or a stat object) Nice! I really like your basic idea of returning a custom object instead of a 2-tuple. And I agree with Christian that .stat() would be clearer called .lstat(). I also like your later idea of simply exposing .dirent (would be None on Windows). One tweak I'd suggest is that is_file() etc be called isfile() etc without the underscore, to match the naming of the os.path.is* functions. > That would actually make sense at an implementation > level anyway - is_file() etc would check self.cached_lstat first, and > if that was None they would check self.dirent, and if that was also > None they would raise an error. Hmm, I'm not sure about this at all. Are you suggesting that the DirEntry object's is* functions would raise an error if both cached_lstat and dirent were None? Wouldn't it make for a much simpler API to just call os.lstat() and populate cached_lstat instead? As far as I'm concerned, that'd be the point of making DirEntry.lstat() a function. 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 would call entry.lstat() if dirent was or d_type was DT_UNKNOWN. This would change relatively nasty code like this: files = [] dirs = [] for entry in os.scandir(path): try: isdir = entry.isdir() except NotPresentError: st = os.lstat(os.path.join(path, entry.name)) isdir = stat.S_ISDIR(st) if isdir: dirs.append(entry.name) else: files.append(entry.name) Into nice clean code like this: files = [] dirs = [] for entry in os.scandir(path): if entry.isfile(): dirs.append(entry.name) else: files.append(entry.name) This change would make scandir() usable by ordinary mortals, rather than just hardcore library implementors. In other words, I'm proposing that the DirEntry objects yielded by scandir() would have .name and .dirent attributes, and .isdir(), .isfile(), .islink(), .lstat() methods, and look basically like this (though presumably implemented in C): 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 attributes self._path = path def lstat(self): if self._lstat is None: self._lstat = os.lstat(os.path.join(self._path, self.name)) return self._lstat def isdir(self): if self.dirent is not None and self.dirent.d_type != DT_UNKNOWN: return self.dirent.d_type == DT_DIR else: return stat.S_ISDIR(self.lstat().st_mode) def isfile(self): if self.dirent is not None and self.dirent.d_type != DT_UNKNOWN: return self.dirent.d_type == DT_REG else: return stat.S_ISREG(self.lstat().st_mode) def islink(self): if self.dirent is not None and self.dirent.d_type != DT_UNKNOWN: return self.dirent.d_type == DT_LNK else: return stat.S_ISLNK(self.lstat().st_mode) Oh, and the .dirent would either be None (Windows) or would have .d_type and .d_ino attributes (Linux, OS X). This would make the scandir() API nice and simple to use for callers, but still expose all the information the OS provides (both the meaningful fields in dirent, and a full stat on Windows, nicely cached in the DirEntry object). Thoughts? -Ben ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info
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 would call > entry.lstat() if dirent was or d_type was DT_UNKNOWN. This would > change relatively nasty code like this: 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. Your code example doesn't handle the case of a failing lstat() call. It can happen when the file is removed or permission of a parent directory changes. > This change would make scandir() usable by ordinary mortals, rather > than just hardcore library implementors. Why not have both? The os module exposes and leaks the platform details on more than on occasion. A low level function can expose name + dirent struct on POSIX and name + stat_result on Windows. Then you can build a high level API like os.scandir() in pure Python code. > 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 attributes > self._path = path You should include the fd of the DIR pointer here for the new *at() function family. > def lstat(self): > if self._lstat is None: > self._lstat = os.lstat(os.path.join(self._path, self.name)) > return self._lstat The function should use fstatat(2) function (os.lstat with dir_fd) when it is available on the current platform. It's better and more secure than lstat() with a joined path. > def isdir(self): > if self.dirent is not None and self.dirent.d_type != DT_UNKNOWN: > return self.dirent.d_type == DT_DIR > else: > return stat.S_ISDIR(self.lstat().st_mode) > > def isfile(self): > if self.dirent is not None and self.dirent.d_type != DT_UNKNOWN: > return self.dirent.d_type == DT_REG > else: > return stat.S_ISREG(self.lstat().st_mode) > > def islink(self): > if self.dirent is not None and self.dirent.d_type != DT_UNKNOWN: > return self.dirent.d_type == DT_LNK > else: > return stat.S_ISLNK(self.lstat().st_mode) A bit faster: d_type = getattr(self.dirent, "d_type", DT_UNKNOWN) if d_type != DT_UNKNOWN: return d_type == DT_LNK The code doesn't handle a failing lstat() call. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Best practices for Enum
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 integer-enums have a better repr than plain integers. For internal constants such as those in idlelib and regex, the user won't see any benefit at all. But there will be a cost in terms of code churn, risk of introducing errors in stable code, modestly slowing-down the code, making it more difficult to apply bug fixes across multiple versions of Python, and increased code verbosity (i.e. changing "if direction=LEFT: ..." to "if direction is Direction.LEFT: ...") For external constants, some thought needs to be given to: * is the current API working just fine (i.e. decimal's ROUND_DOWN) * will enums break doctests or any existing user code * will it complicate users converting from Python 2 * do users now have to learn an additional concept * does it complicate the module in any way I'm hoping that enums get used only in cases where they clearly improve the public API (i.e. cases such as sockets that have a large number of integer constants) rather than having a frenzy of every constant, everywhere getting turned into an enum. I would like to see enums used as tool for managing complexity, rather than becoming a cause of added complexity by being used for every problem, the tall and small, even where it is not needed at all. my-two-cents-ly yours, Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info
2013/5/13 Ben Hoyt : > 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 attributes > self._path = path > > def lstat(self): > if self._lstat is None: > self._lstat = os.lstat(os.path.join(self._path, self.name)) > return self._lstat > ... You need to provide a way to invalidate the stat cache, DirEntry.clearcache() for example. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info
> 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 .cached_lstat could call os.lstat()? That seems very bad to me. It's a property access -- it looks cheap, therefore people will expect it to be. From PEP 8 "Avoid using properties for computationally expensive operations; the attribute notation makes the caller believe that access is (relatively) cheap." Even worse is error handling -- I'd expect the expression "entry.cached_lstat" to only ever raise AttributeError, not OSError in the case it calls stat under the covers. Calling code would have to have a try/except around what looked like a simple attribute access. For these two reasons I think lstat() should definitely be a function. > Your code example doesn't handle the case of a failing lstat() call. It > can happen when the file is removed or permission of a parent directory > changes. True. My isdir/isfile/islink implementations should catch any OSError from the lstat() and return False (like os.path.isdir etc do). But then calling code still doesn't need try/excepts around the isdir() calls. This is how os.walk() is implemented -- there's no extra error handling around the isdir() call. > Why not have both? The os module exposes and leaks the platform details > on more than on occasion. A low level function can expose name + dirent > struct on POSIX and name + stat_result on Windows. Then you can build a > high level API like os.scandir() in pure Python code. I wouldn't be opposed to that, but it's a scandir() implementation detail. If there's a scandir_helper_win() and scandir_helper_posix() written in C, and the rest is written in Python, that'd be fine by me. As long as the Python part didn't slow it down much. > The function should use fstatat(2) function (os.lstat with dir_fd) when > it is available on the current platform. It's better and more secure > than lstat() with a joined path. Sure. I'm primarily a Windows dev, so not too familiar with all the fancy stat* functions. But what you're saying makes sense. -Ben ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info
On Mon, May 13, 2013 at 12:11 PM, Victor Stinner wrote: > 2013/5/13 Ben Hoyt : >> class DirEntry: >> ... >> def lstat(self): >> if self._lstat is None: >> self._lstat = os.lstat(os.path.join(self._path, self.name)) >> return self._lstat >> ... > > You need to provide a way to invalidate the stat cache, > DirEntry.clearcache() for example. Hmm, I'm not sure why, as the stat result is cached on the DirEntry instance (not the class). If you don't want the cached version, just call os.stat() yourself, or throw away the DirEntry instance. DirEntry instances would just be used for dealing with scandir() results. -Ben ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Best practices for Enum
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 that's in the stdlib while doing something modestly useful. For internal constants such as those in idlelib and regex, the user won't see any benefit at all. Devs are users, too! If it makes our lives easier, then, ultimately, it will make our users lives easier as well. But there will be a cost in terms of code churn, risk of introducing errors in stable code, modestly slowing-down the code, making it more difficult to apply bug fixes across multiple versions of Python, and increased code verbosity (i.e. changing "if direction=LEFT: ..." to "if direction is Direction.LEFT: ...") There is no need for increased verbosity, as Enums support __eq__ as well: class Direction(Enum): LEFT = 1 RIGHT = 2 UP = 3 DOWN = 4 globals.update(Direction.__members__) direction = ... if direction == LEFT: ... For external constants, some thought needs to be given to: * is the current API working just fine (i.e. decimal's ROUND_DOWN) just fine? or working great? * will enums break doctests or any existing user code doctests rely on repr's, don't they? Then yes. User code? I would think only if the user was relying on a repr or str of the value. At any rate, that's why this isn't going in until 3.4. * will it complicate users converting from Python 2 I would hope it would simplify; I'll backport a 2.x version, though, so anyone interested can play with it. * do users now have to learn an additional concept I don't think enumerations would be a new concept to a computer programmer. * does it complicate the module in any way A little bit of setup at the top, but then it should be easier everywhere else. I'm hoping that enums get used only in cases where they clearly improve the public API (i.e. cases such as sockets that have a large number of integer constants) rather than having a frenzy of every constant, everywhere getting turned into an enum. I would like to see enums used as tool for managing complexity, rather than becoming a cause of added complexity by being used for every problem, the tall and small, even where it is not needed at all. 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. I don't know about you, but I sure spend a lot of time in those two places. -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Best practices for Enum
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 limitation on that theory that I envision with retrofitting the stdlib is that cooperative modules (those that call into and are called from the module being converted to use enums) are going to be expecting values, not enums. So you need to convert return values and arguments, and not only do you *not* get the benefit of enum reprs in the cooperating modules, but you introduce additional complexity in the converted module. Nor can you say "OK, it's more than I expected but I'll do the whole stdlib," because you don't know who is calling into or supplying callbacks to the stdlib modules. I expect you would recognize these cases quickly, but I imagine Raymond is feeling a more generic unease, and I can't say I blame him. In many cases you could convert code to use IntEnum instead of Enum, preserving the old semantics, and probably not needing to convert return values, but again I expect the benefits of Enum-ness would attenuate quickly as cooperating code converts them to int internally. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Best practices for Enum
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 know of. It's my hope that such changes will happen very gradually and only when deemed important and useful by core developers. So it's not different from any other changes made in the Python repository, really. Issues will be opened, discussed, code will be reviewed by whomever is willing to participate. IIRC Guido wanted to have a printable representation for the socket module constants like socket.AF_* and socket.SOCK_* because that would be useful in developing Tulip. Implementing those with IntEnum may be a relatively non-controversial first foray into actually putting enums to use. But again, at least as far as I'm concerned there's no concrete todo list at this point. Eli On Sun, May 12, 2013 at 4:49 PM, Raymond Hettinger < [email protected]> 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 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 integer-enums have a better > repr than plain integers. > > For internal constants such as those in idlelib and regex, > the user won't see any benefit at all. But there will be > a cost in terms of code churn, risk of introducing errors > in stable code, modestly slowing-down the code, making > it more difficult to apply bug fixes across multiple versions > of Python, and increased code verbosity (i.e. changing > "if direction=LEFT: ..." to "if direction is Direction.LEFT: ...") > > For external constants, some thought needs to be given to: > * is the current API working just fine (i.e. decimal's ROUND_DOWN) > * will enums break doctests or any existing user code > * will it complicate users converting from Python 2 > * do users now have to learn an additional concept > * does it complicate the module in any way > > I'm hoping that enums get used only in cases where they > clearly improve the public API (i.e. cases such as sockets > that have a large number of integer constants) rather > than having a frenzy of every constant, everywhere getting > turned into an enum. > > I would like to see enums used as tool for managing complexity, > rather than becoming a cause of added complexity by being used > for every problem, the tall and small, even where it is not needed at all. > > my-two-cents-ly yours, > > > Raymond > > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/eliben%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Best practices for Enum
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. Not so in the existing stdlib, I expect. Perhaps not to somebody who is already well versed in it. It would be very helpful to me. ;) The concrete limitation on that theory that I envision with retrofitting the stdlib is that cooperative modules (those that call into and are called from the module being converted to use enums) are going to be expecting values, not enums. So you need to convert return values and arguments, and not only do you *not* get the benefit of enum reprs in the cooperating modules, but you introduce additional complexity in the converted module. Nor can you say "OK, it's more than I expected but I'll do the whole stdlib," because you don't know who is calling into or supplying callbacks to the stdlib modules. Well, somebody else might, but I know how much (little?) time I have. It'll be great to have new modules use Enums; retrofitted modules should use Psuedonums (okay, I made that word up -- it's supposed to be an Enum but with some other type mixed in so it's no longer a pure Enum, more like a psuedo enum). As I was saying, if tkinter was up for conversion it would just be to StrEnum, and that would mostly consist of adding the enumeration at the top, exporting it to global, then browsing for locations where the string value was used and removing the quotes. Of course, having said that I'm sure somebody will chime in with "yes, but..." In many cases you could convert code to use IntEnum instead of Enum, preserving the old semantics, and probably not needing to convert return values, but again I expect the benefits of Enum-ness would attenuate quickly as cooperating code converts them to int internally. Hmmm... yeah, that would suck. Well, I'm sure I can help in others ways if this doesn't pan out. Maybe some other new module that Raymond objects to. ;) -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
