Re: [Python-Dev] Point of building without threads?
On Mon, May 7, 2012 at 9:49 PM, Antoine Pitrou solip...@pitrou.net wrote: I guess a long time ago, threading support in operating systems wasn't very widespread, but these days all our supported platforms have it. Is it still useful for production purposes to configure --without-threads? Do people use this option for something else than curiosity of mind? Gentoo (of course) allows users to build Python without threads; I'm not aware of anyone depending on that, but I sent out a quick question to gentoo-dev. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Point of building without threads?
I guess a long time ago, threading support in operating systems wasn't very widespread, but these days all our supported platforms have it. Is it still useful for production purposes to configure --without-threads? Do people use this option for something else than curiosity of mind? For EVE Online, we started out not using threads but relying solely on tasklets. We only added thread supports perhaps five years ago. Other embedded projects _might_ be omitting thread support for a leaner interpreter, but I'm not sure the difference is that large. K ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades
Carl Meyer carl at oddbird.net writes: The version key could in theory be useful to know whether a particular venv created by that Python has or has not yet been upgraded to match, but since the upgrade is trivial and idempotent I don't think that is important. Agreed it's not essential, but it also provides some useful information about the version (for a user, rather than the update script) without actually having to invoke the interpreter to check. Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.3 cannot find BeautifulSoup but Python 3.2 can
This really isn't the right mailing list to ask this kind of question (I know you got help last time with your Debian-specific problem, but that was because people got overly excited =). Python-dev is meant for discussing the development *of* Python, not using it or developing *with* it. I would try your question on comp.lang.python/python-list. On Sun, May 6, 2012 at 7:28 PM, Edward C. Jones edcjo...@comcast.netwrote: I use up-to-date Debian testing (wheezy), amd64 architecture. I compiled and installed Python 3.3.0 alpha 3 using altinstall. Debian wheezy comes with python3.2 (and 2.6 and 2.7). I installed the Debian package python3-bs4 (BeautifulSoup). I also downloaded a clone developmental copy of 3.3. Python3.3a3 cannot find module bs4. Neither can the clone. Python3.2 can find the module. Here is a session with the clone: ./python Python 3.3.0a3+ (default:10ccbb90a8e9, May 6 2012, 19:11:02) [GCC 4.6.3] on linux Type help, copyright, credits or license for more information. import bs4 Traceback (most recent call last): File stdin, line 1, in module File frozen importlib._bootstrap, line 974, in _find_and_load ImportError: No module named 'bs4' [71413 refs] What is the problem? __**_ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/**mailman/listinfo/python-devhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** brett%40python.orghttp://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.3 cannot find BeautifulSoup but Python 3.2 can
On May 08, 2012, at 11:13 AM, Brett Cannon wrote: This really isn't the right mailing list to ask this kind of question (I know you got help last time with your Debian-specific problem, but that was because people got overly excited =). Python-dev is meant for discussing the development *of* Python, not using it or developing *with* it. I would try your question on comp.lang.python/python-list. There are lots of good resources for Debian-specific Python issues (mailing lists, IRC, etc.). Start here: http://wiki.debian.org/Python Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades
Hi Paul, On 05/07/2012 04:16 PM, Paul Moore wrote: On 7 May 2012 21:55, Martin v. Löwismar...@v.loewis.de wrote: This sounds to me like a level of complexity unwarranted by the severity of the problem, especially when considering the additional burden it imposes on alternative Python implementations. OTOH, it *significantly* reduces the burden on Python end users, for whom creation of a venv under a privileged account is a significant hassle. Personally, I would find a venv which required being run as an admin account to be essentially unusable on Windows (particularly Windows 7, where this means creating venvs in an elevated console window). Allowing for symlinks as an option is fine, I guess, but I'd be -1 on it being the default. I don't think anyone has proposed making symlinks the default on Windows. At this point the two options on Windows would be to use the --symlink option explicitly, or else to need to run pyvenv --upgrade on your envs if you upgrade the underlying Python in-place (and there's a breaking incompatibility between the new stdlib and the old interpreter, which there almost never will be if the past is any indication). I expect most users will opt for the latter option (equivalent to how current virtualenv works, except virtualenv doesn't have an --upgrade flag so you have to upgrade manually), but the former is also available if some prefer it. In any case, the situation will be no worse than it is with virtualenv today. Carl ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On May 08, 2012, at 11:59 AM, Nick Coghlan wrote: No, the mcl in the call is just the designated metaclass - the *actual* metaclass of the resulting class definition may be something different. That's why this is a separate method from mcl.__new__. I'm not completely sold on adding a class method to type, but I acknowledge that it's a convenient place to put it. Still, it doesn't feel particularly more right than adding it to say, the operator module. I don't think we have any class methods on type yet, so this would be setting a precedence that we should be sure we want to establish. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades
On 8 May 2012 17:14, Carl Meyer c...@oddbird.net wrote: I don't think anyone has proposed making symlinks the default on Windows. At this point the two options on Windows would be to use the --symlink option explicitly, or else to need to run pyvenv --upgrade on your envs if you upgrade the underlying Python in-place (and there's a breaking incompatibility between the new stdlib and the old interpreter, which there almost never will be if the past is any indication). I expect most users will opt for the latter option (equivalent to how current virtualenv works, except virtualenv doesn't have an --upgrade flag so you have to upgrade manually), but the former is also available if some prefer it. In any case, the situation will be no worse than it is with virtualenv today. That sounds fine. I apologise - I'd got the impression that the proposal was to make symlinks the default. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Point of building without threads?
Antoine Pitrou solip...@pitrou.net wrote: I guess a long time ago, threading support in operating systems wasn't very widespread, but these days all our supported platforms have it. Is it still useful for production purposes to configure --without-threads? Do people use this option for something else than curiosity of mind? _decimal is about 12% faster without threads, because the expensive thread local context can be disabled. On OpenBSD threading leads to strange problems like delayed signals in the REPL http://bugs.python.org/issue8714 . Without threads these problems don't occur. Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] c/ElementTree XML serialisation
Furthermore, if I use the html method (an option given to ElementTree.write), closing tags are converted to lower case, which leads to an XML parsing error with camel-cased tag names. Using the text method instead removes all tags, and I get a ValueError if I try to use the c14n method. This seems like a limitation in ElementTree.py only, as _elementtree.c doesn't appear to contain any of these serialization or writing methods. What I think I'll do is write a _serialise_svg function and add it to the _serialize dictionary of function lookups, from the module I'm working on. That way I hope I can pass method=svg to ElementTree's write() method; it should work, and it should also be backwards-compatible. That should be quite a quick and easy fix actually. Would this be something worth incorporating into ElementTree downstream? Kind regards, Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Point of building without threads?
On Tue, 8 May 2012 19:40:32 +0200 Stefan Krah ste...@bytereef.org wrote: Antoine Pitrou solip...@pitrou.net wrote: I guess a long time ago, threading support in operating systems wasn't very widespread, but these days all our supported platforms have it. Is it still useful for production purposes to configure --without-threads? Do people use this option for something else than curiosity of mind? _decimal is about 12% faster without threads, because the expensive thread local context can be disabled. If you cached the last thread id along with the corresponding context, perhaps it could speed things up in most scenarios? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] c/ElementTree XML serialisation
On 5/8/2012 12:21 PM, Alex Leach wrote: Is there a better way? This really looks like a python-list question. I don't see that it has much to do with developing 3.3. (any more than most pythonl-list questions.) -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] c/ElementTree XML serialisation
On 08/05/12 17:21, Alex Leach wrote: The w3c SVG specification / recommendation http://www.w3.org/TR/SVG/script.html allows forscript andstyle tags, recommending to wrap the text node in a![CDATA[ … ]]. The spec uses a CDATA section in the example, for demonstration purposes only. It's not a recommendation. CDATA sections are of use for hand-authoring readability, but don't help in machine-serialised documents. You don't get away from the need to encode out-of-band sequences (notably ]] is still invalid) so it doesn't buy you any simplicity. it's definitely a problem when generating SVG No, not really. Neither XML nor SVG mandate use of CDATA sections here; a normal XML-encoded text node as produced by _serialize_xml is fine, and works with all XML processing tools. HTML serialisation has custom rules (the two CDATA elements) because the HTML syntax is not XML. XML languages (including SVG and non-legacy served-as-XML XHTML) have no such special cases. (There are other problems in ElementTree's serialiser that make the output unreflective of the infoset in certain cases, but not here.) -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/ gtalk:chat?jid=bobi...@gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2012 09:59 PM, Nick Coghlan wrote: On Mon, May 7, 2012 at 11:42 PM, Hrvoje Niksic hrvoje.nik...@avl.com wrote: On 05/07/2012 02:15 PM, Nick Coghlan wrote: Benjamin's suggestion of a class method on type may be a good one, though. Then the invocation (using all arguments) would be: mcl.build_class(name, bases, keywords, exec_body) Works for me, so unless someone else can see a problem I've missed, we'll go with that. Note that to call mcl.build_class, you have to find a metaclass that works for bases, which is the job of build_class. Putting it as a function in the operator module seems like a better solution. No, the mcl in the call is just the designated metaclass - the *actual* metaclass of the resulting class definition may be something different. That's why this is a separate method from mcl.__new__. Why not make it a static method, if there is no notion of a useful 'cls' argument? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+poCQACgkQ+gerLs4ltQ6IUwCfckUDbCCFjRPcFtvQmTXUcGuv 8RYAoKzry9l0xB7G+I0fIBqAp+3DJTdc =3kdb -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] c/ElementTree XML serialisation
On Tuesday 08 May 2012 23:15:43 And Clover wrote: | | CDATA sections are of use for hand-authoring readability, but don't help | in machine-serialised documents. You don't get away from the need to | encode out-of-band sequences (notably ]] is still invalid) so it | doesn't buy you any simplicity. It's not simplicity I'm looking for but functionality. I did initially make a true XML generator (no javascript or CSS intended or included), but including a small ecmascript rather than 500,000 separate x and y co-ordinates made the SVG about 28MB simpler, so I'm ahead already. The current XML generator can't be used to write javascript stored within any Element because it forcefully substitutes , and for their HTML counterparts. | | it's definitely a problem when generating SVG | | No, not really. Neither XML nor SVG mandate use of CDATA sections here; | a normal XML-encoded text node as produced by _serialize_xml is fine, | and works with all XML processing tools. Maybe the script block doesn't require CDATA wrappers, but style blocks without them don't work, at least in firefox. Perhaps even worse, vim highlighting breaks too! Quoting: http://www.w3.org/TR/SVG/styling.html#StylingWithCSS Note how the CSS style sheet is placed within a CDATA construct (i.e., ! [CDATA[ ... ]]). Placing internal CSS style sheets within CDATA blocks is sometimes necessary since CSS style sheets can include characters, such as , which conflict with XML parsers. Even if a given style sheet does not use characters that conflict with XML parsing, it is highly recommended that internal style sheets be placed inside CDATA blocks. | | HTML serialisation has custom rules (the two CDATA elements) because the | HTML syntax is not XML. XML languages (including SVG and non-legacy | served-as-XML XHTML) have no such special cases. True. I might not need the CDATA tag to wrap the javascript then, but I still need and symbols. I have no idea how to write a loop in javascript without one. | | (There are other problems in ElementTree's serialiser that make the | output unreflective of the infoset in certain cases, but not here.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages
On 05.05.2012 16:13, Antoine Pitrou wrote: On Sat, 05 May 2012 16:04:40 +0200 Christian Heimes li...@cheimes.de wrote: Am 05.05.2012 15:39, schrieb Antoine Pitrou: On Sat, 05 May 2012 15:31:24 +0200 Christian Heimes li...@cheimes.de wrote: Am 05.05.2012 12:36, schrieb Antoine Pitrou: Hello, On Fri, 04 May 2012 14:07:28 -0400 Edward C. Jones edcjo...@comcast.net wrote: Filelist of package libbz2-dev in wheezy of architecture amd64 /usr/include/bzlib.h /usr/lib/x86_64-linux-gnu/libbz2.a /usr/lib/x86_64-linux-gnu/libbz2.so /usr/share/doc/libbz2-dev setup.py probably doesn't search in the right paths for libbz2.so. I suggest you open a bug at http://bugs.python.org The issue might be caused by Debian's new multiarch libraries. In recent versions of Debian (and Ubuntu), 64bit and 32bit libraries can coexist on the same system. It probably is, but I thought Barry had tackled that in setup.py :-) The fix needs the dpkg-architecture program. As Tshepang pointed out it may not be available on Edward's box. I always install build-essential on all development boxes as it includes GCC, make and dpkg-dev. Perhaps setup.py should detect that? It shouldn't be too hard to parse /etc/debian_version in order to know whether the system is multiarch-enabled. That would avoid confusing build failures. IMO, the correct fix would be not to hard-code the system include and library directories, but get them from gcc directly (if CC is gcc), and not relying on dpkg-architecture. $ gcc -v -E - /dev/null [...] #include ... search starts here: /usr/lib/gcc/x86_64-linux-gnu/4.6/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. [...] LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../:/lib/:/usr/lib/ Matthias ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On Wed, May 9, 2012 at 8:37 AM, Tres Seaver tsea...@palladion.com wrote: No, the mcl in the call is just the designated metaclass - the *actual* metaclass of the resulting class definition may be something different. That's why this is a separate method from mcl.__new__. Why not make it a static method, if there is no notion of a useful 'cls' argument? We need the explicitly declared metaclass as well as the bases in order to determine the correct metaclass. As a static method, the invocation would look like: type.build_class(mcl, bases, keywords, exec_body) Since mcl will always be an instance of type in 3.x (due to all classes being subtypes of object), it makes more sense to just make it a class method and invoke the method on the declared metaclass: mcl.build_class(bases, keywords, exec_body) The following assertion *does not* hold reliably: cls = mcl.build_class(bases, keywords, exec_body) assert type(cls) == mcl # Not guaranteed Instead, the invariant that holds is the weaker assertion: cls = mcl.build_class(bases, keywords, exec_body) assert isinstance(cls, mcl) This is due to the fact that one of the bases may specify that the actual metaclass is a subtype of mcl rather than mcl itself. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
Hi Eric, Great job on the latest PEP 421. I really like it. A few additional comments/questions. * sys.implementation.version This is defined as the version of the implementation, while sys.version_info is the version of the language. The semantics of sys.version_info have been sufficiently squishy in the past, as the XXX implies. This PEP shouldn't try to untangle that, so I think it be better to represent both values explicitly in sys.implementation. * Adding new required variables. I'd claim that it's not unduly heavyweight to require a new PEP to add required variables to sys.implementation. That hypothetical PEP will have to include things like rationale, impact on other implementations, etc. That seems like enough to warrant a new PEP, even if it's relatively succinct. I'd also make it clear that adding new variables to sys.implementation.metadata explicitly does *not* require a PEP. * In Example Metadata Value: If they later have meaningful uses cases, they can be added by following the process described in Adding New Required Attributes. I'd rephrase this to If these or any other variables are deemed to have meaningful use cases across all implementations, they can be moved or added to sys.implementation directly, following the process described in Adding New Required Attributes. * I mildly prefer sys.implementation.name to be lower cased. My intuition is that to be safe, most comparisons of the value will coerce to lower case, which is easy enough in Python, but perhaps a bit more of a pain in C. I don't feel really strongly about this though. (A counter argument is that the value might be printed, so a case-sensitive version would be better.) * Since I'm advocating to be explicit about the language version and the implementation version, .hexversion is probably also useful for both. * I've said before that I think the keys in sys.implementation should be locked down (i.e. not writable). I think sys.implementation.metadata should be the same type. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages
On May 09, 2012, at 02:17 AM, Matthias Klose wrote: IMO, the correct fix would be not to hard-code the system include and library directories, but get them from gcc directly (if CC is gcc), and not relying on dpkg-architecture. $ gcc -v -E - /dev/null [...] #include ... search starts here: /usr/lib/gcc/x86_64-linux-gnu/4.6/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. [...] LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../:/lib/:/usr/lib/ +1 This would make a good fix for Python 3.3. Matthias, perhaps you can work up a patch for that? -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Tue, May 8, 2012 at 7:14 PM, Barry Warsaw ba...@python.org wrote: Hi Eric, Great job on the latest PEP 421. I really like it. Encouragement appreciated. :) A few additional comments/questions. * sys.implementation.version This is defined as the version of the implementation, while sys.version_info is the version of the language. The semantics of sys.version_info have been sufficiently squishy in the past, as the XXX implies. This PEP shouldn't try to untangle that, so I think it be better to represent both values explicitly in sys.implementation. Definitely tangled. So, sys.implementation.version and sys.implementation.lang_version? Also, my inclination is to not have a sys.version equivalent in sys.implementation for now, in the interest of keeping things as bare-bones as possible to start. * Adding new required variables. I'd claim that it's not unduly heavyweight to require a new PEP to add required variables to sys.implementation. That hypothetical PEP will have to include things like rationale, impact on other implementations, etc. That seems like enough to warrant a new PEP, even if it's relatively succinct. Agreed. I'll go with that for the PEP. I'd also make it clear that adding new variables to sys.implementation.metadata explicitly does *not* require a PEP. Good point. * In Example Metadata Value: If they later have meaningful uses cases, they can be added by following the process described in Adding New Required Attributes. I'd rephrase this to If these or any other variables are deemed to have meaningful use cases across all implementations, they can be moved or added to sys.implementation directly, following the process described in Adding New Required Attributes. That's an important distinction. I'll clean it up. * I mildly prefer sys.implementation.name to be lower cased. My intuition is that to be safe, most comparisons of the value will coerce to lower case, which is easy enough in Python, but perhaps a bit more of a pain in C. I don't feel really strongly about this though. (A counter argument is that the value might be printed, so a case-sensitive version would be better.) I'm not sure it makes a lot of difference. Since cache_tag will be provided by the implementation, I don't have any strong use-cases that would constrain the name itself. Still, my preference is for lower case as well. I'll mull this one over. * Since I'm advocating to be explicit about the language version and the implementation version, .hexversion is probably also useful for both. That's fine with me, and pretty trivial to do. * I've said before that I think the keys in sys.implementation should be locked down (i.e. not writable). I've been on and off about this. It's certainly not too hard to do, it makes sense, and I don't see a lot of reason not to do it. I'll give it a go. I think sys.implementation.metadata should be the same type. This I wonder about. The more I think about it, the more it fits. I'll give it a day and if that still holds I'll work it in. Thanks for the feedback, Barry! Feels like the PEP's getting close. -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
