Le mardi 23 novembre 2010 à 11:34 -0800, Guido van Rossum a écrit : > >> From a backward-compatibility perspective, what makes sense depends on > >> whether they're used to implement existing constants (socket.AF_INET, > >> etc.) or if they reserved for new features only. > > > > It's not only backwards compatibility. New features relying on C APIs > > have to be able to map constants to the integers used in the C library. > > It would be much better if this were done naturally rather than through > > explicit conversion maps. > > I'm not sure what you mean here. Can you give an example of what you > mean? I agree that it should be possible to make pretty much any > constant in the OS modules enums -- even if the values vary across > platforms. I mean that PyArg_ParseTuple should continue to be pratical even if e.g. os.SEEK_SET and friends become named constants. It implies that the various format codes such as "i", "l", etc. are still usable with those constants. Hence: > > (this really means subclassing int, if we don't want to complicate > > C-level code) > > Right. :-) Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4