[Python-3000] Interest in PEP for callbacks on module import
guido.van.rossum wrote:
> Modified: python/branches/py3k/Lib/numbers.py
> ==
> --- python/branches/py3k/Lib/numbers.py (original)
> +++ python/branches/py3k/Lib/numbers.py Thu Dec 6 18:45:33 2007
> @@ -43,6 +43,7 @@
>
> Inexact.register(complex)
> Inexact.register(float)
> +# Inexact.register(decimal.Decimal)
With the new abstract base classes in Py3k, I can see it being
worthwhile to have a standard mechanism to allow callbacks to be
registered for execution when particular modules are first imported.
For example, to handle the commented out case above:
@imp.imported('decimal')
def register(decimal):
Inexact.register(decimal.Decimal)
I think a PEP would be needed to decide whether to handle this in a
fashion similar to that of PJE's Importing toolkit [1] (i.e., using lazy
imports where the actual loading of the module code is deferred until
the first access to an attribute of the module), or else to add a new
mechanism directly to the interpreter code, where the registered
callbacks would be called as soon as the specified module was loaded.
Does anyone else think this is an issue worth pursuing? We've already
had a couple of instances come up in relation to the registration of
array.array and decimal.Decimal with the appropriate abstract base
classes. I expect there are other areas of the standard library (e.g.
ctypes, mmap) where being able to register container types when the
collections module is imported would be beneficial.
Cheers,
Nick.
[1] http://peak.telecommunity.com/DevCenter/Importing
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Interest in PEP for callbacks on module import
Nick Coghlan wrote:
> For example, to handle the commented out case above:
>
>@imp.imported('decimal')
>def register(decimal):
>Inexact.register(decimal.Decimal)
I like the syntax assuming that imp.imported(name) expects a method that
accepts the module object as argument.
> I think a PEP would be needed to decide whether to handle this in a
> fashion similar to that of PJE's Importing toolkit [1] (i.e., using lazy
> imports where the actual loading of the module code is deferred until
> the first access to an attribute of the module), or else to add a new
> mechanism directly to the interpreter code, where the registered
> callbacks would be called as soon as the specified module was loaded.
I find a new mechanism easier to implement. Lazy or deferred imports
require frame hacks and you know how Guido thinks about sys._getframe(). :)
An implementation based on your suggestion is simple. Add a registry to
imp which is a simple dict that maps dotted module names to a list of
callables. Upon import the IMP module calls the callables after the
module is inserted into sys.modules. That's it. :]
Zope's deferredimport [1] package has a nice idea. It supports
deprecation warnings when a deprecated attribute is accessed the first time.
>>> import somemodule
No warning is raised
>>> somemodule.deprecated_feature
DeprecationWarning ...
The package makes use of stack inspection and a proxy package.
> Does anyone else think this is an issue worth pursuing?
Yes, count me in. I like to help with the PEP and implementation. :)
Christian
[1] http://svn.zope.org/zope.deferredimport/trunk/src/zope/deferredimport/
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] markupbase
On Dec 7, 2007, at 1:54 AM, Brett Cannon wrote: > I say just go ahead and rename it. Other modules are going to need to > be renamed as well so it isn't like this is going to be a special > case. And done. -Fred -- Fred Drake ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Interest in PEP for callbacks on module import
At 12:33 PM 12/7/2007 +0100, Christian Heimes wrote:
>Nick Coghlan wrote:
> > For example, to handle the commented out case above:
> >
> >@imp.imported('decimal')
> >def register(decimal):
> >Inexact.register(decimal.Decimal)
>
>I like the syntax assuming that imp.imported(name) expects a method that
>accepts the module object as argument.
I prefer something like 'when_imported' or 'upon_import' or something
else that more specifically refers to the idea that this is
registering a handler to be called. imported() by itself sounds like
a query as to whether the module is currently imported.
> > I think a PEP would be needed to decide whether to handle this in a
> > fashion similar to that of PJE's Importing toolkit [1] (i.e., using lazy
> > imports where the actual loading of the module code is deferred until
> > the first access to an attribute of the module), or else to add a new
> > mechanism directly to the interpreter code, where the registered
> > callbacks would be called as soon as the specified module was loaded.
>
>I find a new mechanism easier to implement. Lazy or deferred imports
>require frame hacks
No, they don't. See:
http://svn.eby-sarna.com/Importing/peak/util/imports.py?view=markup
The mechanism I used is to create a subclass of ModuleType and put it
in sys.modules as a placeholder for the "real" module. When the
module is touched, I effectively change the type back to a regular
module, and call reload() to actually import the module.
Of course, since Python 2.3 (this code was originally written for
2.2), you can't change a subclass of ModuleType back to ModuleType
itself, so I actually change the custom subclass on the fly. This is
easy enough to do in Python, but I'd hate to do it in C.
If I were doing it in C, I'd just add a laziness flag and callback
list to the base ModuleType. The tp_getattro could then check the
laziness flag and do the rest.
> > Does anyone else think this is an issue worth pursuing?
A qualified yes: the Importing package took a long time to get
correct under all the crazy little twists and turns of importing,
including correctly handling things like the link between packages
and their child packages/modules, the import order of same, race
conditions, import locks, clearing out callbacks, etc. I'm somewhat
hesitant as to whether a from-scratch reimplementation is wise.
I'm also concerned about interoperability. If you add the equivalent
of Importing's whenImported, but not lazyModule, then I'll still need
Importing itself -- and the builtin implementation of whenImported
might conflict with lazyModule. In particular, the builtin
when_imported might confuse a lazyModule with something that's
already imported, and fire off callbacks when it shouldn't.
So, I vote for making module laziness part of the implementation, if
there is one.
There also should be APIs provided by imp to inspect (or change) the
laziness of a module without causing it to become un-lazy. This is
needed so that other ModuleType subclasses can play too. For
example, some tools use ModuleType subclasses to implement
attribute-level laziness instead of whole-module laziness.
There may be other interop issues with libraries that use ModuleType
subclasses or do lazy import, deprecation, and similar module content
manipulation, so a publicized PEP would be a good idea to get their
developers' input.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Combined configparse + optparse (interest?)
On Dec 7, 2007, at 10:37 AM, Neal Becker wrote: > Right now we have 2 rather different stdlib modules for parsing > options from > ini-style files and from command line. I believe it would be > desirable to > have one module that can handle both. Is there interest in pursuing > this > idea? Definitely! I'm interested, and suspect others at ZC would appreciate such a module as well. Of course, we'd be most interested if it worked with Python 2.4 forward. ;-) I'm certainly willing to help out. -Fred -- Fred Drake ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Combined configparse + optparse (interest?)
Neal Becker wrote: > Right now we have 2 rather different stdlib modules for parsing options from > ini-style files and from command line. I believe it would be desirable to > have one module that can handle both. Is there interest in pursuing this > idea? I'd be interested. I think rolling in the functionality of argparse to handle non-option arguments would also be good: http://argparse.python-hosting.com/ ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] markupbase
Fred Drake wrote: > And done. Is the py3k branch open for development again? Christian ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3108 - recommendations for PyPI transition
On Dec 6, 2007, at 8:37 AM, [EMAIL PROTECTED] wrote: > Should the PEP acknowledge this route to module sainthood for certain > modules? I think this is out of scope for the PEP. It's fine if the PEP points to new distributions for the modules as they become available. -Fred -- Fred Drake ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] markupbase
On Dec 7, 2007, at 6:33 AM, Christian Heimes wrote: > Is the py3k branch open for development again? Oops, good question. Wish I'd wondered about that. /me feels out of sync with the Python development cycle... -Fred -- Fred Drake ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] Combined configparse + optparse (interest?)
Right now we have 2 rather different stdlib modules for parsing options from ini-style files and from command line. I believe it would be desirable to have one module that can handle both. Is there interest in pursuing this idea? ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] Python 3.0a2 is out
A new alpha of Python 3000 was released a few minutes ago! http://www.python.org/download/releases/3.0/ Have fun and don't forget to report bugs at http://bugs.python.org/ Christian signature.asc Description: OpenPGP digital signature ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Py3k code freeze imminent; 3.0a2 release Friday
As people have been disregarding the freeze anyway, I declare the py3k branch back open. I tagged it with r30a2 yesterday morning and that's the version that I'll be releasing shortly (waiting for Crys & me to sort out some things around the Windows MSI installer). --Guido On Dec 5, 2007 8:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I've built and tested the latest py3k from scratch on Ubuntu, Fedora > 7, OSX 10.4 and OSX 10.5, and found no issues. > > So the code freeze is a fact. Don't check anything into the py3k > branch unless I tell you to. Please file high-priority bugs and assign > them to me if you think you've found a showstopper. > > The buildbot is green for Solaris also, so I think we're in good > shape. I don't see any green buildbots for Windows though, but Windows > is always a flakey situation; Christian, what's your assessment? > > I see a few tests leaking; in particular test_ssl (1522 refs leaned > per run!) and test_urllib2_localnet (3 per run). Anyone interested in > researching these feel free to do so; just upload a patch and file a > bug if you've squashed the leaks (or some). > > We're on for a 3.0a2 release Friday! > > --Guido > > > On Dec 5, 2007 5:46 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > I'm planning to freeze the py3k branch in 2-3 hours, some time > > after/around 8pm PST (midnight UTC). > > > > If someone wants to do another svnmerge from the trunk please do it > > before then -- though we're nearly current so I don't mind not having > > the last few changes merged into this release (it's only Raymond's > > refactoring of __length_hint__ implementations). > > > > If there's anything you think really should be in this release, please > > speak up ASAP. Filing a high priority bug and assigning it to me would > > be a great way to get my attention. > > > > -- > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PyInt_ to PyLong_ rename
On 12/3/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On Dec 2, 2007 12:56 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > It's only used for sys.maxint. Do we still need sys.maxint and > > > PyInt_GetMax()? IMO PyLong_GetNativeMax() and sys.maxnativelong are > > > better names. > > > > I think they should go entirely. They don't give any interesting > > information about the Python implementation. > > Actually it's still somewhat interesting to be able to tell whether a > particular Python build uses 64-bit pointer or 32-bit pointers. (I > realize sys.maxint doesn't quite tell us this, but on Linux at least > it does.) I also suspecet that sys.maxint is used frequently for "some > large integer" used as an approximation of infinity in some context. It is, but it doesn't appear to common: http://www.google.com/codesearch?q=+sys.maxint Only turns up ~10 unique non-Python-itself projects using within the first 5 pages of results. Much of the time it is used as a large number. Anyone porting that code forward to 2.6 or later can fix that. Please don't encourage its misuse for determining if the host has 32 or 64bit longs or pointers. It does not do that. Use platform.architecture() for the long size and look at the length of a hex pointer in the repr of a class for C pointer size. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Interest in PEP for callbacks on module import
Phillip J. Eby wrote: >> > Does anyone else think this is an issue worth pursuing? > > A qualified yes: the Importing package took a long time to get correct > under all the crazy little twists and turns of importing, including > correctly handling things like the link between packages and their child > packages/modules, the import order of same, race conditions, import > locks, clearing out callbacks, etc. I'm somewhat hesitant as to whether > a from-scratch reimplementation is wise. I'm far from convinced that a from-scratch rewrite (particularly in C) is a great idea myself - that's why I suggested a PEP to look at some of the issues. Some curly questions I thought of myself: - What do we do if something is inserted in sys.modules directly, and then imported later? Do registered callbacks for that module trigger at all? If so, when? - Does the lazy importing code need to reacquire the import lock before loading the module on attribute access? > There may be other interop issues with libraries that use ModuleType > subclasses or do lazy import, deprecation, and similar module content > manipulation, so a publicized PEP would be a good idea to get their > developers' input. Yeah, the more I think about it, the more I think a new PEP for lazy and weak importing is the right way to go (although it would be nice if using the latter didn't automatically cause the former). I'll put an initial draft together (unless someone else beats me to it - I almost certainly won't find time to do it until after Christmas) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PyInt_ to PyLong_ rename
Gregory P. Smith wrote: > look at the length of a > hex pointer in the repr of a class for C pointer size. I don't think that will work, because the repr only uses as many hex digits as it needs to represent the value: >>> o = object() >>> o I'm pretty sure my G4 PPC is using pointers longer than 20 bits. :-) -- Greg ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Armin's attribute lookup caching for 3.0
Neil Toronto wrote: > Phillip J. Eby wrote: >> That having been said, the idea that the statement 'SomeBaseClass.foo = >> 23' is actually going to walk through cache entries and invoke a >> callback for *every* subclass of SomeBaseClass in the program makes me a >> tiny bit nervous. >> >> On the other hand, I suppose it's also a good argument for not using >> class attributes when you really want a global. :) > > Heh. You never know what those crazy users will need to do. You of all > people should know that. :p > > If it's too slow, an obvious way to speed it up is to not use > update_subclasses and avoid the overhead. Besides avoiding calling a > function by pointer, not doing the shadowing check may also be faster > generally, since, as you say, assigned attributes are most likely 1) not > shadowed (they'll almost never be methods), or 2) in a leaf class. It > may be that Armin's invalidate everything approach would be generally > faster that way because it *can* skip shadowed attributes. To update you > have to check for shadowing. > > I may try it. I couldn't say whether it's worth duplicating the code. Okay, I tried it. SpecialClassAttribute sees a 3% speedup but NormalClassAttribute sees a 9% slowdown. I haven't got a clue what that asymmetry is all about. At any rate, I'll #ifdef it and post a new patch. It's yet another thing to play with. Neil ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Armin's attribute lookup caching for 3.0
Phillip J. Eby wrote: > At 12:14 PM 12/7/2007 -0700, Neil Toronto wrote: >> I found updating caches from setattr to be faster than invalidating >> entries. > > Really? Even on the SpecialClassAttribute test? I'd have assumed that > Armin's invalidation flag mechanism would make repeated sets faster. Of > course, in cases where you read the attribute every time it's set, your > approach might come out ahead somewhat. Armin's approach has to walk > the entire subclass tree to mark the versions invalid, whereas yours can > skip shadowed attributes. In Python 3.0, since everything is so much more unified, Armin's invalidate everything approach can skip shadowed attributes as well. If a subclass shadows an attribute, its cache entry either 1) doesn't exist, or 2) caches the shadowing value. The invalidating callback looks like: 1. Set type's cache ID to current, increment current The updating callback looks like: 1. Get Unicode hash (almost always pointer dereference) 2. Calculate cache index 3. If entry cache ID and name match, assign new value It's not a whole lot more, especially compared to the update_subclasses machinery. Where I think the updating approach wins is when only one attribute is set at a time, rather than a lot of them in a row, which I believe is more likely. > I suspect that in real programs, though, it's rare to be setting > attributes on a base class that are shadowed by subclass attributes. > Most likely, you'll either be changing something that's global and > inherited everywhere, or something that's on a leaf class to begin > with. Your approach should definitely be a win on the *read* side of > things, though, since it doesn't have to check version validity during > lookup. > > That having been said, the idea that the statement 'SomeBaseClass.foo = > 23' is actually going to walk through cache entries and invoke a > callback for *every* subclass of SomeBaseClass in the program makes me a > tiny bit nervous. > > On the other hand, I suppose it's also a good argument for not using > class attributes when you really want a global. :) Heh. You never know what those crazy users will need to do. You of all people should know that. :p If it's too slow, an obvious way to speed it up is to not use update_subclasses and avoid the overhead. Besides avoiding calling a function by pointer, not doing the shadowing check may also be faster generally, since, as you say, assigned attributes are most likely 1) not shadowed (they'll almost never be methods), or 2) in a leaf class. It may be that Armin's invalidate everything approach would be generally faster that way because it *can* skip shadowed attributes. To update you have to check for shadowing. I may try it. I couldn't say whether it's worth duplicating the code. FWIW and slightly topic-veering, this patch keeps hit/miss counts if you want it to. Pybench has a hit rate of 81%. It's hard to say whether a benchmark gives a good measure of hit rate, though, since most code doesn't repeat the same operations to quite the extent that a benchmark does. OTOH, build and build_ext get 99%, so it may be a bad measure in the other direction. Neil ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Armin's attribute lookup caching for 3.0
At 12:14 PM 12/7/2007 -0700, Neil Toronto wrote: >I couldn't help myself. Such a beautiful thing had to be spread, and it >was *easy* to put it in 3.0 because types are simpler. A patch is here: > > http://bugs.python.org/issue1568 > >If users are going to be encouraged to subclass from the ABC hierarchy >for new container and numeric types, they'll likely want something like >this. Both pybench and pystones are faster (pystones because its classes >are now instances of type), and those exercise attribute lookups on >classes with MROs no larger than 2. The pybench scores are good in >general (with all lookups very good), except SpecialClassAttribute, >which spends half its time doing class attribute assignments. Another >surprise is TryRaiseExcept - why should that be faster? > >I found updating caches from setattr to be faster than invalidating >entries. Really? Even on the SpecialClassAttribute test? I'd have assumed that Armin's invalidation flag mechanism would make repeated sets faster. Of course, in cases where you read the attribute every time it's set, your approach might come out ahead somewhat. Armin's approach has to walk the entire subclass tree to mark the versions invalid, whereas yours can skip shadowed attributes. I suspect that in real programs, though, it's rare to be setting attributes on a base class that are shadowed by subclass attributes. Most likely, you'll either be changing something that's global and inherited everywhere, or something that's on a leaf class to begin with. Your approach should definitely be a win on the *read* side of things, though, since it doesn't have to check version validity during lookup. That having been said, the idea that the statement 'SomeBaseClass.foo = 23' is actually going to walk through cache entries and invoke a callback for *every* subclass of SomeBaseClass in the program makes me a tiny bit nervous. On the other hand, I suppose it's also a good argument for not using class attributes when you really want a global. :) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] Armin's attribute lookup caching for 3.0
I couldn't help myself. Such a beautiful thing had to be spread, and it was *easy* to put it in 3.0 because types are simpler. A patch is here: http://bugs.python.org/issue1568 If users are going to be encouraged to subclass from the ABC hierarchy for new container and numeric types, they'll likely want something like this. Both pybench and pystones are faster (pystones because its classes are now instances of type), and those exercise attribute lookups on classes with MROs no larger than 2. The pybench scores are good in general (with all lookups very good), except SpecialClassAttribute, which spends half its time doing class attribute assignments. Another surprise is TryRaiseExcept - why should that be faster? I found updating caches from setattr to be faster than invalidating entries. (It could easily go back to invalidating all entries for a type if that's preferred.) Adding extra TPFLAGS was unnecessary. It still assumes attribute names are interned (it doesn't have to but it's a little faster this way), but AFAIK this could only affect computed names. Neil ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PyInt_ to PyLong_ rename
On Dec 7, 2007 11:23 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > sys.maxsize should be backported to 2.6. > > It's on my todo list. But at first I'm going to celebrate Python 3.0a2 > with a beer and meet some friends. Enjoy! Me, I'm going on a conference bike with the xkcd author. ;-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PyInt_ to PyLong_ rename
Guido van Rossum wrote: > sys.maxsize should be backported to 2.6. It's on my todo list. But at first I'm going to celebrate Python 3.0a2 with a beer and meet some friends. Christian ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PyInt_ to PyLong_ rename
On Dec 7, 2007 11:06 AM, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > On 12/3/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On Dec 2, 2007 12:56 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > > It's only used for sys.maxint. Do we still need sys.maxint and > > > > PyInt_GetMax()? IMO PyLong_GetNativeMax() and sys.maxnativelong are > > > > better names. > > > > > > I think they should go entirely. They don't give any interesting > > > information about the Python implementation. > > > > Actually it's still somewhat interesting to be able to tell whether a > > particular Python build uses 64-bit pointer or 32-bit pointers. (I > > realize sys.maxint doesn't quite tell us this, but on Linux at least > > it does.) I also suspecet that sys.maxint is used frequently for "some > > large integer" used as an approximation of infinity in some context. > > It is, but it doesn't appear to common: > > http://www.google.com/codesearch?q=+sys.maxint > > Only turns up ~10 unique non-Python-itself projects using within the first 5 > pages of results. Much of the time it is used as a large number. Anyone > porting that code forward to 2.6 or later can fix that. > > Please don't encourage its misuse for determining if the host has 32 or > 64bit longs or pointers. It does not do that. Use platform.architecture() > for the long size and look at the length of a hex pointer in the repr of a > class for C pointer size. sys.maxsize should be backported to 2.6. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
