Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
"Martin v. Löwis" wrote: >> id (required): >> lower case identifier, for example "cpython", "ironpython", "jython", >> "pypy" > > Doing some bike-shedding: I'd like to not use "cpython" as the name of > the python.org implementation. This term, I believe, was coined around > JPython, somehow making the implementation language the primary means > of distinction. However, there may be alternative implementations > written in C (e.g. unladen swallow), or otherwise be "C based" (e.g. > pypy). > > So I propose that the python.org version is identified as "python". The CPython name is the traditional and commonly used name of the python.org C implementation. Even though the name is inspired by using C as implementation language, it doesn't refer to CPython being the only implementation of Python in C. I don't think there's a need to do any bike shedding on well established names. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 12 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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 about sys.implementation and implementation specific user site directory
Christian Heimes wrote: > sys.implementation > -- > > platform (required): > platform or language of the implementation, for example "C", ".NET", > "Java" I'd call this attribute "language". We already have sys.platform with a different meaning. Possible values would then be "C", "C#", "Java", "Python", etc. > runtime (required): > lower case runtime library of the implementation, for example "libc", > "msvcrt90", "java6", ".net" > > compiler (required): > verbose name of the compiler, for example "GCC 4.3.3", "Java > HotSpot(TM) Client VM (Apple Inc.)", "Mono JIT compiler version 2.0.1" If you include the compiler as well, it may make sense to also add the other creation details that platform.py parses from the sys.version string: branch, revision, buildno, builddate > ... > > > sys.userdirsuffix > - > > sys.userdirsuffix is an implementation and platform specific string that > is used to construct the path for the user site directory as explained > in PEP 370. The string contains the implementation name as well as the > version number of Python. Don't we already have this information available as site.getuserbase()/ site.getusersitepackages() ? > Examples: > python2.6 (CPython, Unix) > Python26 (CPython, Windows) > ironpython2.6 (IronPython, Unix) > IronPython26 (IronPython, Windows) > ... > Since the examples point to the name of the Python stdlib dir and this form is also used in a lot of other places to distinguish different Python versions (e.g. in distutils build dirs), perhaps we should use a more generic name for it like e.g. sys.versiondir ?! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 12 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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 about sys.implementation and implementation specific user site directory
Christian Heimes wrote: > id (required): > lower case identifier, for example "cpython", "ironpython", "jython", > "pypy" > > name (required): > mixed case name of the implementation, for example "CPython", > "IronPython", "Jython", "PyPy" Why both? Is it not true that the following is guaranteed? sys.implementation.id == sys.implementation.name.lower() Furthermore, why is a lower-case-only constant superior to a mixed-case identifier? I wonder this especially given that platform.python_implementation() already returns mixed-case constants. Why not include the version of the language? > platform (required): > platform or language of the implementation, for example "C", ".NET", > "Java" What should someone like PyPy say here? Do you have a use-case in mind? What is the relevance of this field? > runtime (required): > lower case runtime library of the implementation, for example "libc", > "msvcrt90", "java6", ".net" Same questions as above. Is the java-runtime not dependent on libc? $ ldd /opt/sun-jdk-1.6.0.15/jre/bin/java | grep libc libc.so.6 => /lib/libc.so.6 (0xb7d7) > compiler (required): > verbose name of the compiler, for example "GCC 4.3.3", "Java > HotSpot(TM) Client VM (Apple Inc.)", "Mono JIT compiler version 2.0.1" I think other commenters have already asked what exactly is considered the "compiler"? This is especially interesting if you consider PyPy, as well. What is the item being compiled that you are interested in? What is the use-case for this info? It could vary based on module: some modules could've been built with a different compiled or even compiled to bytecode by a different implementation or etc. It seems like (platform, runtime, compiler) are guesses at what *might* be useful. But, in the absence of use-cases they are not useful, perhaps misguided, and create a maintenance burden for the future. A lot of this info is available via the platform module. And the only reason given to not use the platform module was to avoid adding dependencies for site.py. I don't see that as an open invitation to adding other fields that are already available via the platform module. Until they are critical to run-time performance, why not wait to add these extra things? The only thing that has been indicated as needed is the identifier for the python implementation. sys.vm or sys.implementation may very well fully support the use cases given merely by being a string. -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Fri, 09 Oct 2009 17:49:23 +0100, Michael Foord > I wonder if it is going to be possible to make this compatible with the > upcoming distutils package management 'stuff' (querying for installed > packages, uninstallation etc) since installation/uninstallation goes > through the Windows system package management feature. I guess it would > be eminently possible but require some reasonably high level Windows-fu > to do. It's a good question. Searching on it turned up no easy way of doing control panel applications in python. A much easier way would be to just mount a package manager application in the "Programs" + "Python X.Y" menu. Users would surely find it there. Regards David ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
>> My opinion is that this tool exists only because Python doesn't >> support the installation of multiple versions for the same >> distributions. > > This is not at all how I use virtualenv. For me virtualenv is a > sandbox so that I don't have to become root whenever I need to install > a Python package for testing purposes and to allow me to hop between > sets of installed Python packages while developing on multiple Python > projects. I also use it as a sandbox for build bots so that multiple > bots on the same machine can each build their own projects with just > the known dependencies installed. +1 I also don't use virtualenv for supporting multiple versions, but rather for sandboxing, testing and experimentation. To make sure that an app works with the exact dependencies I think it should work with. Also, it's important that the 'global' site-packages typically requires root privileges while installing to a virtualenv doesn't. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] Backport new float repr to Python 2.7?
Glyph Lefkowitz wrote: I'd much rather have my doctests and float-repr'ing code break on 2.7 so I can deal with it as part of a minor-version upgrade than have it break on 3.x and have to deal with this at the same time as the unicode->str explosion. It feels like a backport of this behavior would make the 2->3 transition itself a little easier. I'm +0 on making the change, primarily for this reason. We can reuse the vast majority of the code from 3.x. 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
Re: [Python-Dev] Backport new float repr to Python 2.7?
[Guido] > I think you mean doctests? These are the primary reason I've always > been hesitant to change this in 2.x. Yes, sorry. I did of course mean doctests. It occurs to me that any doctests that depend on the precise form of repr(x) are, in a sense, already broken, since 2.x makes no guarantees about repr(x) being consistent across platforms. It's just an accident that repr(x) in 2.x pretty much *is* consistent across major platforms, so long as you steer clear of IEEE 754 oddities like subnormals, nans and infinities. [Glyph] > I'd much rather have my doctests and float-repr'ing code break on > 2.7 so I can deal with it as part of a minor-version upgrade than > have it break on 3.x and have to deal with this at the same time > as the unicode->str explosion. It feels like a backport of this > behavior would make the 2->3 transition itself a little easier. I hadn't really thought about this aspect. I find this quite convincing. [Guido] > PS. str(x) still seems to be using %.12g -- shouldn't it be made equal > to repr() in 3.1 or 3.2? *That* I would call a bug, an oversight. But str still has some value in py3k: it protects users from accumulated rounded errors produced by arithmetic operations: Python 3.2a0 (py3k:75216:75220, Oct 3 2009, 21:38:04) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> 0.1 + 0.2 0.30004 >>> 1.23 * 4.64 5.7071999 >>> str(0.1 + 0.2) '0.3' >>> str(1.23 * 4.64) '5.7072' I don't know whether this makes it worth keeping str different from repr. Mark ___ 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] Backport new float repr to Python 2.7?
On Mon, Oct 12, 2009 at 11:41 AM, Mark Dickinson wrote: > [Guido] >> PS. str(x) still seems to be using %.12g -- shouldn't it be made equal >> to repr() in 3.1 or 3.2? *That* I would call a bug, an oversight. > > But str still has some value in py3k: it protects users from > accumulated rounded errors produced by arithmetic operations: [...] I know, but this is much more questionable now. Making str() and repr() different was an intentional choice when repr() would often show ugly values even if the input was pretty; but now str() just hides real differences (1.3 != 1.2 + 1.1), and the difference between str() and repr() is pretty subtle. (Show of hands for those who didn't even know there was a difference? :-). I think if we had to start from scratch with the 3.1 float repr() I would have made float's str() equal to its repr(). But this is at most a +1 feeling. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Backport new float repr to Python 2.7?
On Mon, Oct 12, 2009 at 7:48 PM, Guido van Rossum wrote: > On Mon, Oct 12, 2009 at 11:41 AM, Mark Dickinson wrote: >> But str still has some value in py3k: it protects users from >> accumulated rounded errors produced by arithmetic operations: > [...] > > I know, but this is much more questionable now. [...] Would it be out of the question to make str = repr in 3.2, do you think? Mark ___ 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] Backport new float repr to Python 2.7?
On Mon, Oct 12, 2009 at 11:54 AM, Mark Dickinson wrote: > On Mon, Oct 12, 2009 at 7:48 PM, Guido van Rossum wrote: >> On Mon, Oct 12, 2009 at 11:41 AM, Mark Dickinson wrote: >>> But str still has some value in py3k: it protects users from >>> accumulated rounded errors produced by arithmetic operations: >> [...] >> >> I know, but this is much more questionable now. [...] > > Would it be out of the question to make str = repr in 3.2, do you think? I don't think it is out of the question. (Though it would probably break a few more doctests.) I'd like to hear other voices. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Backport new float repr to Python 2.7?
[Mark Dickinson] > It occurs to me that any doctests that depend on the precise form of > repr(x) are, in a sense, already broken, since 2.x makes no guarantees > about repr(x) being consistent across platforms. The doctest documentation has warned about this forever (look near the end of the "Warnings" section, http://docs.python.org/library/doctest.html#warnings ). > It's just an accident that repr(x) in 2.x pretty much *is* consistent across > major platforms, so long as you steer clear of IEEE 754 oddities like > subnormals, > nans and infinities. If you don't consider Windows to be a major platform ;-) Besides that there's just no guessing what the Microsoft double->string routines will produce for the 17th digit, the MS routines always produce 3 digits for the exponent in scientific notation, while AFAIK all other platforms produce 2 digits when 3 aren't necessary. For example, on Windows under Python 2.x: >>> repr(1e47) '1e+047' >>> repr(1e-47) '9.9997e-048' and "everywhere else": >>> repr(1e47) '1e+47' >>> repr(1e-47) '9.9997e-48' The leading 0 in the Window's exponents is enough to break a naive doctest too -- and repr(x) does produce scientific notation for "almost all" finite doubles. Why people are obsessed with the relative handful of doubles between 1 and 1000 is beyond me ;-) As doctest's original author, I have no sympathy for users who burn themselves with float output. Of course it's open to question whether I have sympathy for anyone, ever, but that's not the issue 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] Backport new float repr to Python 2.7?
[Tim:] > If you don't consider Windows to be a major platform ;-) Besides that > there's just no guessing what the Microsoft double->string routines > will produce for the 17th digit, the MS routines always produce 3 > digits for the exponent in scientific notation, while AFAIK all other > platforms produce 2 digits when 3 aren't necessary. For example, on > Windows under Python 2.x: > repr(1e47) > '1e+047' repr(1e-47) > '9.9997e-048' > > and "everywhere else": > repr(1e47) > '1e+47' repr(1e-47) > '9.9997e-48' Not that it's germane to the discussion, but this 3 digit exponent on Windows was fixed in 2.6. > The leading 0 in the Window's exponents is enough to break a naive > doctest too -- and repr(x) does produce scientific notation for > "almost all" finite doubles. Why people are obsessed with the > relative handful of doubles between 1 and 1000 is beyond me ;-) > > As doctest's original author, I have no sympathy for users who burn > themselves with float output. Of course it's open to question whether > I have sympathy for anyone, ever, but that's not the issue here ;-) I agree, we shouldn't base the decision to change this based on doctests. ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tarek Ziadé wrote: > = Virtualenv and the multiple version support in Distribute = > > (I am not saying "We" here because this part was not discussed yet > with everyone) > > Virtualenv allows you to create an isolated environment to install > some distribution without polluting the > main site-packages, a bit like a user site-packages. > > My opinion is that this tool exists only because Python doesn't > support the installation of multiple versions for the same > distributions. > But if PEP 376 and PEP 386 support are added in Python, we're not far > from being able to provide multiple version support with > the help of importlib. I couldn't disagree more strongly: I don't *want* multiple version support: compared to the simplicity of a virtualenv, adding such a complex feature would be a huge backward step. The idea that the "system" python should be polluted with whatever-any- random-app-decides-to-throw-into-it is a source of endless pain, confusion, and hair loss. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrToW0ACgkQ+gerLs4ltQ7fKgCdEPxU6JxKOKCFWtpQSks606DQ XeAAoICgFZ8RURvFH4p3dLTzqq51ROqP =e71z -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] Top-posting on this list
Those who feel diverse can top post. On Sun, Oct 11, 2009 at 11:23 AM, Georg Brandl wrote: >>> Is it really that big of an issue that we have to discuss it >>> ad-infinitum and potentially have a quoting cop? Sometimes top-posting >>> happens. Sometimes people don't trim messages. Sometimes people argue >>> about the color of a shed. >> >> +1 This is really getting so meta that it's off topic. > > quoting-SIG anyone? Those who don't can post below. ___ 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
