Re: [Python-Dev] pyc files, constant folding and borderline portability issues
On Apr 07, 2009 at 02:10AM, Steven D'Aprano wrote: > On the other hand, I'm with Guido when he wrote "it is certainly not > right to choose speed over correctness". This is especially a problem > for floating point optimizations, and I urge Cesare to be conservative > in any f.p. optimizations he introduces, including constant folding. The principle that I followed on doing constant folding was: "do what Python will do without constant folding enabled". So if Python will generate LOAD_CONST 1 LOAD_CONST 2 BINARY_ADD the constant folding code will simply replace them with a single LOAD_CONST 3 When working with such kind of optimizations, the temptation is to apply them at any situation possible. For example, in other languages this a = b * 2 * 3 will be replaced by a = b * 6 In Python I can't do that, because b can be an object which overloaded the * operator, so it *must* be called two times, one for 2 and one for 3. That's the way I choose to implement constant folding. The only difference at this time is regards invalid operations, which will raise exceptions at compile time, not at running time. So if you write: a = 1 / 0 an exception will be raised at compile time. I decided to let the exception be raised immediately, because I think that it's better to detect an error at compile time than at execution time. However, this can leed to incompatibilities with existing code, so in the final implementation I will add a flag to struct compiling (in ast.c) so that this behaviour can be controlled programmatically (enabling or not the exception raising). I already introduced a flag in struct compiling to control the constant folding, that can be completely disabled, if desired. > So... +1 on the general principle of constant folding, -0.5 on any such > optimizations which change the semantics of a f.p. operation. The only > reason it's -0.5 rather than -1 is that (presumably) anyone who cares > about floating point correctness already knows to never trust the > compiler. As Raymond stated, there's no loss in precision working with constant folding code on float datas. That's because there will be a rounding and a store of computed values each time that a result is calculated. Other languages will use FPU registers to hold results as long as possibile, keeping full 80 bit precision (16 bit exponent + 64 bit mantissa). That's not the Python case. Cesare ___ 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] pyc files, constant folding and borderline portability issues
On 07/04/2009, at 7:27 AM, Guido van Rossum wrote: On Mon, Apr 6, 2009 at 7:28 AM, Cesare Di Mauro wrote: The Language Reference says nothing about the effects of code optimizations. I think it's a very good thing, because we can do some work here with constant folding. Unfortunately the language reference is not the only thing we have to worry about. Unlike languages like C++, where compiler writers have the moral right to modify the compiler as long as they stay within the weasel-words of the standard, in Python, users' expectations carry value. Since the language is inherently not that fast, users are not all that focused on performance (if they were, they wouldn't be using Python). Unsurprising behavior OTOH is valued tremendously. Rather than trying to get the optimizer to guess, why not have a "const" keyword and make it explicit? The result would be a symbol that essentially only exists at compile time - references to the symbol would be replaced by the computed value while compiling. Okay, maybe that would suck a bit (no symbolic debug output). Yeah, I know... take it to python-wild-and-ill-considered-id...@python.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] FWD: Library Reference is incomplete
Thomas Wouters schrieb: > > Anyone able to look into this and fix it? Having all of the normal > entrypoints for documentation broken is rather inconvenient for users :-) A rebuild should do the trick, I'll fix this ASAP. Georg ___ 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] deprecating BaseException.message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Coghlan wrote: > Tres Seaver wrote: >> I don't think either of these classes should be subject to a deprecation >> warning for a feature they never used or depended on. > > Agreed. Could you raise a tracker issue for the spurious warnings? (I > believe we should be able to make the warning condition a bit smarter to > eliminate these). Done: http://bugs.python.org/issue5716? 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ20IX+gerLs4ltQ4RAkuDAKCTZNp0r38d+hW8TmvjIh9Sj59CJQCfbJlQ taNbsBUT79MF8t7owySE2dg= =LjZf -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] Adding new features to Python 2.x (PEP 382: Namespace Packages)
On 2009-04-06 15:21, Jesse Noller wrote: > On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg wrote: >> On 2009-04-02 17:32, Martin v. Löwis wrote: >>> I propose the following PEP for inclusion to Python 3.1. >> Thanks for picking this up. >> >> I'd like to extend the proposal to Python 2.7 and later. >> > > -1 to adding it to the 2.x series. There was much discussion around > adding features to 2.x *and* 3.0, and the consensus seemed to *not* > add new features to 2.x and use those new features as carrots to help > lead people into 3.0. I must have missed that discussion :-) Where's the PEP pinning this down ? The Python 2.x user base is huge and the number of installed applications even larger. Cutting these users and application developers off of important new features added to Python 3 is only going to work as "carrot" for those developers who: * have enough resources (time, money, manpower) to port their existing application to Python 3 * can persuade their users to switch to Python 3 * don't rely much on 3rd party libraries (the bread and butter of Python applications) Realistically, such a porting effort is not likely going to happen for any decent sized application, except perhaps a few open source ones. Such a policy would then translate to a dead end for Python 2.x based applications. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 07 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/ 2009-03-19: Released mxODBC.Connect 1.0.1 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] Evaluated cmake as an autoconf replacement
Ondrej> ... while scons and other Python solutions imho encourage to Ondrej> write full Python programs, which imho is a disadvantage for the Ondrej> build system, as then every build system is nonstandard. Hmmm... Like distutils setup scripts? I don't know thing one about cmake, but if it's good for the goose (building Python proper) would it be good for the gander (building extensions)? -- Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/ "XML sucks, dictionaries rock" - Dave Beazley ___ 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 382: Namespace Packages
[Resent due to a python.org mail server problem] On 2009-04-03 22:07, Martin v. Löwis wrote: >> I'd like to extend the proposal to Python 2.7 and later. > > I don't object, but I also don't want to propose this, so > I added it to the discussion. > > My (and perhaps other people's) concern is that 2.7 might > well be the last release of the 2.x series. If so, adding > this feature to it would make 2.7 an odd special case for > users and providers of third party tools. I certainly hope that we'll see more useful features backported from 3.x to the 2.x series or forward ported from 2.x to 3.x (depending on what the core developer preferences are). Regarding this particular PEP, it is well possible to implement an importer that provides the functionality for Python 2.3-2.7 versions, so it doesn't have to be an odd special case. >> That's going to slow down Python package detection a lot - you'd >> replace an O(1) test with an O(n) scan. > > I question that claim. In traditional Unix systems, the file system > driver performs a linear search of the directory, so it's rather > O(n)-in-kernel vs. O(n)-in-Python. Even for advanced file systems, > you need at least O(log n) to determine whether a specific file is > in a directory. For all practical purposes, the package directory > will fit in a single disk block (containing a single .pkg file, and > one or few subpackages), making listdir complete as fast as stat. On second thought, you're right, it won't be that costly. It requires an os.listdir() scan due to the wildcard approach and in some cases, such a scan may not be possible, e.g. when using frozen packages. Indeed, the freeze mechanism would not even add the .pkg files - it only handles .py file content. The same is true for distutils, MANIFEST generators and other installer mechanisms - it would have to learn to package the .pkg files along with the Python files. Another problem with the .pkg file approach is that the file extension is already in use for e.g. Mac OS X installers. You don't have those issues with the __pkg__.py file approach I suggested. >> Wouldn't it be better to stick with a simpler approach and look for >> "__pkg__.py" files to detect namespace packages using that O(1) check ? > > Again - this wouldn't be O(1). More importantly, it breaks system > packages, which now again have to deal with the conflicting file names > if they want to install all portions into a single location. True, but since that means changing the package infrastructure, I think it's fair to ask distributors who want to use that approach to also take care of looking into the __pkg__.py files and merging them if necessary. Most of the time the __pkg__.py files will be empty, so that's not really much to ask for. >> This would also avoid any issues you'd otherwise run into if you want >> to maintain this scheme in an importer that doesn't have access to a list >> of files in a package directory, but is well capable for the checking >> the existence of a file. > > Do you have a specific mechanism in mind? Yes: frozen modules and imports straight from a web resource. The .pkg file approach requires a directory scan and additional support from all importers. The __pkg__.py approach I suggested can use existing importers without modifications by checking for the existence of such a Python module in an importer managed resource. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 07 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/ 2009-03-19: Released mxODBC.Connect 1.0.1 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] Mercurial?
On Tue, Apr 7, 2009 at 13:42, Steven D'Aprano wrote: > Perhaps you should ask Aahz what he thinks about being forced to provide > two names before being allowed to contribute. Huh? The contributor's agreement list would presumably include real names only (so Aahz is out of luck), but the names wouldn't need to be limited to just one "word". I don't think I was implying otherwise; maybe my example much earlier in the thread was simplistic and I should have put it in EBNF (with Unicode character classes just to be very sure). Oh, yes, I am excluding people whose names include non-Unicode characters. Tough luck. 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] Mercurial?
On Tue, 7 Apr 2009 04:30:10 pm Dirkjan Ochtman wrote: > On Tue, Apr 7, 2009 at 08:25, Ben Finney wrote: > > Remembering, of course, that full names don't follow any template > > (especially not first-name last-name). The person's full name must > > be treated as free-form text, since there's no format common to > > all. > > Of course, unless we lock it down through a list of people who have > contributor's agreements. Perhaps you should ask Aahz what he thinks about being forced to provide two names before being allowed to contribute. To say nothing of noted MIT professor and computer scientist Arvind, British lords, the magician Teller, and millions of people from Spanish, Portuguese, Indonesian, Burmese and Malaysian cultures. Ben is correct: you can't assume that contributors will have both a first name and a last name, or that a first name and last name is sufficient to legally identify them. Those from Spanish and Portuguese cultures usually have two family names as well as a personal name; people from Indonesian, Burmese and Malaysian cultures often only use a single name. -- Steven D'Aprano ___ 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] pyc files, constant folding and borderline portability issues
2009/4/7 Cesare Di Mauro : > The principle that I followed on doing constant folding was: "do what Python > will do without constant folding enabled". > > So if Python will generate > > LOAD_CONST 1 > LOAD_CONST 2 > BINARY_ADD > > the constant folding code will simply replace them with a single > > LOAD_CONST 3 > > When working with such kind of optimizations, the temptation is to > apply them at any situation possible. For example, in other languages > this > > a = b * 2 * 3 > > will be replaced by > > a = b * 6 > > In Python I can't do that, because b can be an object which overloaded > the * operator, so it *must* be called two times, one for 2 and one for 3. > > That's the way I choose to implement constant folding. That sounds sufficiently "super risk-averse" to me, so I'm in favour of constant folding being implemented with this attitude :-) 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] PEP 382: Namespace Packages
On 2009-04-03 02:44, P.J. Eby wrote: > At 10:33 PM 4/2/2009 +0200, M.-A. Lemburg wrote: >> Alternative Approach: >> - >> >> Wouldn't it be better to stick with a simpler approach and look for >> "__pkg__.py" files to detect namespace packages using that O(1) check ? > >> One of the namespace packages, the defining namespace package, will have >> to include a __init__.py file. > > Note that there is no such thing as a "defining namespace package" -- > namespace package contents are symmetrical peers. That was a definition :-) Definition namespace package := the namespace package having the __pkg__.py file This is useful to have since packages allowing integration of other sub-packages typically come as a base package with some basic infra-structure in place which is required by all other namespace packages. If the __init__.py file is not found among the namespace directories, the importer will have to raise an exception, since the result would not be a proper Python package. >> * It's possible to have a defining package dir and add-one package >> dirs. > > Also possible in the PEP, although the __init__.py must be in the first > such directory on sys.path. (However, such "defining" packages are not > that common now, due to tool limitations.) That's a strange limitation of the PEP. Why should the location of the __init__.py file depend on the order of sys.path ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 03 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/ 2009-03-19: Released mxODBC.Connect 1.0.1 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] Evaluated cmake as an autoconf replacement
pobox.com> writes: > > I don't know thing one about cmake, but if it's good for the goose (building > Python proper) would it be good for the gander (building extensions)? African or European? ___ 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
[Python-Dev] What's missing from easy_install
1. easy_remove! 2. Various utilities to provide query package management. - easy_install --list (list files installed) ___ 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] What's missing from easy_install
I need an CPyAN. -- Best Regards, -- KDr2, at x-macro.com. On Tue, Apr 7, 2009 at 9:02 PM, Neal Becker wrote: > 1. easy_remove! > > 2. Various utilities to provide query package management. > - easy_install --list (list files installed) > > > ___ > 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/kdr2%40x-macro.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] What's missing from easy_install
On Tue, Apr 7, 2009 at 9:02 AM, Neal Becker wrote: > 1. easy_remove! > > 2. Various utilities to provide query package management. > - easy_install --list (list files installed) This discussion should happen on the distutils-sig list; not python-dev ___ 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] What's missing from easy_install
Neal Becker gmail.com> writes: > > 2. Various utilities to provide query package management. >- easy_install --list (list files installed) "yolk" will tell you that. http://pypi.python.org/pypi/yolk 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] Evaluated cmake as an autoconf replacement
On Tue, Apr 7, 2009 at 9:14 PM, wrote: > > Ondrej> ... while scons and other Python solutions imho encourage to > Ondrej> write full Python programs, which imho is a disadvantage for the > Ondrej> build system, as then every build system is nonstandard. > > Hmmm... Like distutils setup scripts? fortunately, waf and scons are much better than distutils, at least for the build part :) I think it is hard to overestimate the importance of a python solution for python softwares (python itself is different). Having a full fledged language for complex builds is nice, I think most familiar with complex makefiles would agree with this. > > I don't know thing one about cmake, but if it's good for the goose (building > Python proper) would it be good for the gander (building extensions)? For complex softwares, specially ones relying on lot of C and platform idiosyncrasies, distutils is just too cumbersome and limited. Both Ondrej and me use python for scientific usage, and I think it is no hazard that we both look for something else. In those cases, scons - and cmake it seems - are very nice; build tools are incredibly hard to get right once you want to manage dependencies automatically. For simple python projects (pure python, a few .c source files without much dependencies), I think it is just overkill. cheers, David > > -- > Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/ > "XML sucks, dictionaries rock" - Dave Beazley > ___ > 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/cournape%40gmail.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] Evaluated cmake as an autoconf replacement
On Tue, Apr 7, 2009 at 2:14 PM, wrote: > >Ondrej> ... while scons and other Python solutions imho encourage to >Ondrej> write full Python programs, which imho is a disadvantage for the >Ondrej> build system, as then every build system is nonstandard. I fully agree here. > Hmmm... Like distutils setup scripts? > > I don't know thing one about cmake, but if it's good for the goose (building > Python proper) would it be good for the gander (building extensions)? What is involved in building python extensions ? Can you please explain ? 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] Evaluated cmake as an autoconf replacement
On Tue, Apr 7, 2009 at 10:08 PM, Alexander Neundorf wrote: > > What is involved in building python extensions ? Can you please explain ? Not much: at the core, a python extension is nothing more than a dynamically loaded library + a couple of options. One choice is whether to take options from distutils or to set them up independently. In my own scons tool to build python extensions, both are possible. The hard (or rather time consuming) work is to do everything else that distutils does related to the packaging. That's where scons/waf are more interesting than cmake IMO, because you can "easily" give up this task back to distutils, whereas it is inherently more difficult with cmake. cheers, 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] PEP 382: Namespace Packages
At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote: >> Wouldn't it be better to stick with a simpler approach and look for >> "__pkg__.py" files to detect namespace packages using that O(1) check ? > > Again - this wouldn't be O(1). More importantly, it breaks system > packages, which now again have to deal with the conflicting file names > if they want to install all portions into a single location. True, but since that means changing the package infrastructure, I think it's fair to ask distributors who want to use that approach to also take care of looking into the __pkg__.py files and merging them if necessary. Most of the time the __pkg__.py files will be empty, so that's not really much to ask for. This means your proposal actually doesn't add any benefit over the status quo, where you can have an __init__.py that does nothing but declare the package a namespace. We already have that now, and it doesn't need a new filename. Why would we expect OS vendors to start supporting it, just because we name it __pkg__.py instead of __init__.py? ___ 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] Mercurial?
On Tue, Apr 07, 2009, Dirkjan Ochtman wrote: > On Tue, Apr 7, 2009 at 13:42, Steven D'Aprano wrote: >> >> Perhaps you should ask Aahz what he thinks about being forced to provide >> two names before being allowed to contribute. Thanks for speaking up! I'm not sure I would have noticed the implication of Dirkjan's post (I'm not paying a huge amount of attention to the conversion process). > Huh? The contributor's agreement list would presumably include real > names only (so Aahz is out of luck), but the names wouldn't need to be > limited to just one "word". What you apparently are unaware of is that "Aahz" is in fact my full legal name. (Which was clearly the point of Steven's post since he knows that Teller also has only one legal name -- it's not common, but we do exist.) -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "...string iteration isn't about treating strings as sequences of strings, it's about treating strings as sequences of characters. The fact that characters are also strings is the reason we have problems, but characters are strings for other good reasons." --Aahz ___ 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] Mercurial?
On Tue, Apr 7, 2009 at 16:29, Aahz wrote: > What you apparently are unaware of is that "Aahz" is in fact my full > legal name. (Which was clearly the point of Steven's post since he knows > that Teller also has only one legal name -- it's not common, but we do > exist.) Ah, sorry about that. But I hope you also concluded from my email that that wouldn't be a problem. 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] Mercurial?
On Tue, Apr 07, 2009, Dirkjan Ochtman wrote: > On Tue, Apr 7, 2009 at 16:29, Aahz wrote: >> >> What you apparently are unaware of is that "Aahz" is in fact my full >> legal name. (Which was clearly the point of Steven's post since he knows >> that Teller also has only one legal name -- it's not common, but we do >> exist.) > > Ah, sorry about that. But I hope you also concluded from my email that > that wouldn't be a problem. Nope, thanks for clearing it up. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "...string iteration isn't about treating strings as sequences of strings, it's about treating strings as sequences of characters. The fact that characters are also strings is the reason we have problems, but characters are strings for other good reasons." --Aahz ___ 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
[Python-Dev] Shorter float repr in Python 3.1?
Executive summary (details and discussion points below)
=
Some time ago, Noam Raphael pointed out that for a float x,
repr(x) can often be much shorter than it currently is, without
sacrificing the property that eval(repr(x)) == x, and proposed
changing Python accordingly. See
http://bugs.python.org/issue1580
For example, instead of the current behaviour:
Python 3.1a2+ (py3k:71353:71354, Apr 7 2009, 12:55:16)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 0.01
0.01
>>> 0.02
0.02
>>> 0.03
0.02
>>> 0.04
0.040001
>>> 0.04 == eval(repr(0.04))
True
we'd have this:
Python 3.1a2+ (py3k-short-float-repr:71350:71352M, Apr 7 2009, )
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 0.01
0.01
>>> 0.02
0.02
>>> 0.03
0.03
>>> 0.04
0.04
>>> 0.04 == eval(repr(0.04))
True
Initial attempts to implement this encountered various
difficulties, and at some point Tim Peters pointed out
(I'm paraphrasing horribly here) that one can't have all
three of {fast, easy, correct}.
One PyCon 2009 sprint later, Eric Smith and I have
produced the py3k-short-float-repr branch, which implements
short repr of floats and also does some major cleaning
up of the current float formatting functions.
We've gone for the {fast, correct} pairing.
We'd like to get this into Python 3.1.
Any thoughts/objections/counter-proposals/...?
More details
Our solution is based on an adaptation of David Gay's
'perfect rounding' code for inclusion in Python. To make
eval(repr(x)) roundtripping work, one needs to have
correctly rounded float -> decimal *and* decimal -> float
conversions: Gay's code provides correctly rounded
dtoa and strtod functions for these two conversions.
His code is well-known and well-tested: it's used as the
basis of the glibc strtod, and is also in OS X. It's
available from
http://www.netlib.org/fp/dtoa.c
So our branch contains a new file Python/dtoa.c,
which is a cut down version of Gay's original file. (We've
removed stuff for VAX and IBM floating-point formats,
hex NaNs, hex floating-point formats, locale-aware
interpretation of the decimal separator, K&R headers,
code for correct setting of the inexact flag, and various
other bits and pieces that Python doesn't care about.)
Most of the rest of the work is in the existing file
Python/pystrtod.c. Every float -> string or string -> float
conversion goes through a function in this file at
some point.
Gay's code also provides the opportunity to clean
up the current float formatting code, and Eric has
reworked a lot of the float formatting in the py3k-short-float-repr
branch. This reworking should make finishing off the
implementation of things like thousands separators much
more straightforward.
One example of this: the previous string -> float conversion
used the system strtod, which is locale-aware, so the code
had to first replace the '.' by the current locale's decimal
separator, *then* call strtod. There was a similar dance in
the reverse direction when doing float -> string conversion.
Both these are now unnecessary.
The current code is pretty close to ready for merging
to py3k. I've uploaded a patchset to Rietveld:
http://codereview.appspot.com/33084/show
Apart from the short float repr, and a couple of bugfixes,
all behaviour should be unchanged from before. There
are a few exceptions:
- format(1e200, '<') doesn't behave quite as it did
before. See item (3) below for details
- repr switches to using exponential notation at
1e16 instead of the previous 1e17. This avoids
a subtle issue where the 'short float repr' result
is padded with bogus zeros.
- a similar change applies to str, which switches
to exponential notation at 1e11, not 1e12. This
fixes the following minor annoyance, which goes
back at least as far as Python 2.5 (and probably
much further):
>>> x = 1e11 + 0.5
>>> x
1000.5
>>> print(x)
1000.0
That .0 seems wrong to me: if we're going to
go to the trouble of printing extra digits (str
usually only gives 12 significant digits; here
there are 13), they should be the *right* extra digits.
Discussion points
=
(1) Any objections to including this into py3k? If there's
controversy, then I guess we'll need a PEP.
(2) Should other Python implementations (Jython,
IronPython, etc.) be expected to use short float repr, or should
it just be considered an implementation detail of CPython?
I propose the latter, except that all implementations should
be required to satisfy eval(repr(x)) == x for finite floats x.
(3) There's a PEP 3101 line we don't know what to do with.
In py3k, we currently have:
>>> format(1e200, '<')
'1.0e+200'
but in our py3k-short-float-repr branch:
>>> format(1e200, '<')
'1e+200'
Which is correct? The py3k behaviour
comes from the
Re: [Python-Dev] PEP 382: Namespace Packages
On 2009-04-07 16:05, P.J. Eby wrote: > At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote: >> >> Wouldn't it be better to stick with a simpler approach and look for >> >> "__pkg__.py" files to detect namespace packages using that O(1) >> check ? >> > >> > Again - this wouldn't be O(1). More importantly, it breaks system >> > packages, which now again have to deal with the conflicting file names >> > if they want to install all portions into a single location. >> >> True, but since that means changing the package infrastructure, I think >> it's fair to ask distributors who want to use that approach to also take >> care of looking into the __pkg__.py files and merging them if >> necessary. >> >> Most of the time the __pkg__.py files will be empty, so that's not >> really much to ask for. > > This means your proposal actually doesn't add any benefit over the > status quo, where you can have an __init__.py that does nothing but > declare the package a namespace. We already have that now, and it > doesn't need a new filename. Why would we expect OS vendors to start > supporting it, just because we name it __pkg__.py instead of __init__.py? I lost you there. Since when do we support namespace packages in core Python without the need to add some form of magic support code to __init__.py ? My suggestion basically builds on the same idea as Martin's PEP, but uses a single __pkg__.py file as opposed to some non-Python file yaddayadda.pkg. Here's a copy of the proposal, with some additional discussion bullets added: """ Alternative Approach: - Wouldn't it be better to stick with a simpler approach and look for "__pkg__.py" files to detect namespace packages using that O(1) check ? This would also avoid any issues you'd otherwise run into if you want to maintain this scheme in an importer that doesn't have access to a list of files in a package directory, but is well capable for the checking the existence of a file. Mechanism: -- If the import mechanism finds a matching namespace package (a directory with a __pkg__.py file), it then goes into namespace package scan mode and scans the complete sys.path for more occurrences of the same namespace package. The import loads all __pkg__.py files of matching namespace packages having the same package name during the search. One of the namespace packages, the defining namespace package, will have to include a __init__.py file. After having scanned all matching namespace packages and loading the __pkg__.py files in the order of the search, the import mechanism then sets the packages .__path__ attribute to include all namespace package directories found on sys.path and finally executes the __init__.py file. (Please let me know if the above is not clear, I will then try to follow up on it.) Discussion: --- The above mechanism allows the same kind of flexibility we already have with the existing normal __init__.py mechanism. * It doesn't add yet another .pth-style sys.path extension (which are difficult to manage in installations). * It always uses the same naive sys.path search strategy. The strategy is not determined by some file contents. * The search is only done once - on the first import of the package. * It's possible to have a defining package dir and add-one package dirs. * The search does not depend on the order of directories in sys.path. There's no requirement for the defining package to appear first on sys.path. * Namespace packages are easy to recognize by testing for a single resource. * There's no conflict with existing files using the .pkg extension such as Mac OS X installer files or Solaris packages. * Namespace __pkg__.py modules can provide extra meta-information, logging, etc. to simplify debugging namespace package setups. * It's possible to freeze such setups, to put them into ZIP files, or only have parts of it in a ZIP file and the other parts in the file-system. * There's no need for a package directory scan, allowing the mechanism to also work with resources that do not permit to (easily and efficiently) scan the contents of a package "directory", e.g. frozen packages or imports from web resources. Caveats: * Changes to sys.path will not result in an automatic rescan for additional namespace packages, if the package was already loaded. However, we could have a function to make such a rescan explicit. """ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 07 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/ 2009-03-19: Released mxODBC.Connect 1.0.1 http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services Gmb
Re: [Python-Dev] Evaluated cmake as an autoconf replacement
Greg Ewing wrote: Steve Holden wrote: Isn't it strange how nobody every complained about the significance of whitespace in makefiles: only the fact that leading tabs were required rather than just-any-old whitespace. Make doesn't care how *much* whitespace there is, though, only whether it's there or not. If it accepted anything that looks like whitespace, there would be no cause for complaint. Make and the *roff formats had the nasty feature that they treated homographs differently. That is, you could print two sources that placed all the same ink on the paper at the same places, but they would perform differently. For make it was tabs. For the *roff files, the periods ending sentences and the periods for abbreviations (such as honorifics) were distinguished by following end-of-sentence periods with two spaces. This left any line ending in a period ambiguous, and tools to strip whitespace off the end of lines as information-destroying. --Scott David Daniels scott.dani...@acm.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] PyDict_SetItem hook
On 3 Apr, 2009, at 0:57, Guido van Rossum wrote: The primary use case is some kind of trap on assignment. While this cannot cover all cases, most non-local variables are stored in dicts. List mutations are not in the same league, as use case. I have a slightly different use-case than a debugger, although it boils down to "some kind of trap on assignment": implementing Key- Value Observing support for Python objects in PyObjC. "Key-Value Observing" is a technique in Cocoa where you can get callbacks when a property of an object changes and is something I cannot support for plain python objects at the moment due to lack of a callback mechanism. A full implementation would require hooks for mutation of lists and sets as well. The lack of mutation hooks is not a terrible problem for PyObjC, we can always use Cocoa datastructures when using KVO, but it is somewhat annoying that Cocoa datastructures leak into code that could be pure python just because I want to use KVO. Ronald smime.p7s Description: S/MIME cryptographic 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] os.defpath for Windows
Hi, I've added the issue to tracker. http://bugs.python.org/issue5717 --anatoly t. On Sun, Dec 21, 2008 at 12:19 PM, Yinon Ehrlich wrote: > Hi, > > just saw that os.defpath for Windows is defined as > Lib/ntpath.py:30:defpath = '.;C:\\bin' > > Most Windows machines I saw has no c:\bin directory. > > Any reason why it was defined this way ? > Thanks, > Yinon > ___ > 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/techtonik%40gmail.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] pyc files, constant folding and borderline portability issues
Cesare> The only difference at this time is regards invalid operations, Cesare> which will raise exceptions at compile time, not at running Cesare> time. Cesare> So if you write: Cesare> a = 1 / 0 Cesare> an exception will be raised at compile time. I think I have to call *bt* here. This is a common technique used during debugging. Insert a 1/0 to force an exception (possibly causing the running program to drop into pdb). I think you have to leave that in. Skip ___ 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] Evaluated cmake as an autoconf replacement
>> I don't know thing one about cmake, but if it's good for the goose >> (building Python proper) would it be good for the gander (building >> extensions)? Antoine> African or European? I was thinking Canadian... Skip ___ 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] pyc files, constant folding and borderline portability issues
In data 07 aprile 2009 alle ore 17:19:25, ha scritto: > > Cesare> The only difference at this time is regards invalid operations, > Cesare> which will raise exceptions at compile time, not at running > Cesare> time. > > Cesare> So if you write: > > Cesare> a = 1 / 0 > > Cesare> an exception will be raised at compile time. > > I think I have to call *bt* here. This is a common technique used > during debugging. Insert a 1/0 to force an exception (possibly causing the > running program to drop into pdb). I think you have to leave that in. > > Skip Many tests rely on this, and I have changed them from something like: try: 1 / 0 except: to try: a = 1; a / 0 except: But I know that it's a major source of incompatibilities, and in the final code I'll enabled it only if user demanded it (through a flag). Cesare ___ 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 382: Namespace Packages
On Tue, Apr 7, 2009 at 11:58 PM, M.-A. Lemburg wrote: >> >> This means your proposal actually doesn't add any benefit over the >> status quo, where you can have an __init__.py that does nothing but >> declare the package a namespace. We already have that now, and it >> doesn't need a new filename. Why would we expect OS vendors to start >> supporting it, just because we name it __pkg__.py instead of __init__.py? > > I lost you there. > > Since when do we support namespace packages in core Python without > the need to add some form of magic support code to __init__.py ? I think P. Eby refers to the problem that most packaging systems don't like several packages to have the same file - be it empty or not. That's my main personal grip against namespace packages, and from this POV, I think it is fair to say the proposal does not solve anything. Not that I have a solution, of course :) cheers, David > > My suggestion basically builds on the same idea as Martin's PEP, > but uses a single __pkg__.py file as opposed to some non-Python > file yaddayadda.pkg. > > Here's a copy of the proposal, with some additional discussion > bullets added: > > """ > Alternative Approach: > - > > Wouldn't it be better to stick with a simpler approach and look for > "__pkg__.py" files to detect namespace packages using that O(1) check ? > > This would also avoid any issues you'd otherwise run into if you want > to maintain this scheme in an importer that doesn't have access to a list > of files in a package directory, but is well capable for the checking > the existence of a file. > > Mechanism: > -- > > If the import mechanism finds a matching namespace package (a directory > with a __pkg__.py file), it then goes into namespace package scan mode and > scans the complete sys.path for more occurrences of the same namespace > package. > > The import loads all __pkg__.py files of matching namespace packages > having the same package name during the search. > > One of the namespace packages, the defining namespace package, will have > to include a __init__.py file. > > After having scanned all matching namespace packages and loading > the __pkg__.py files in the order of the search, the import mechanism > then sets the packages .__path__ attribute to include all namespace > package directories found on sys.path and finally executes the > __init__.py file. > > (Please let me know if the above is not clear, I will then try to > follow up on it.) > > Discussion: > --- > > The above mechanism allows the same kind of flexibility we already > have with the existing normal __init__.py mechanism. > > * It doesn't add yet another .pth-style sys.path extension (which are > difficult to manage in installations). > > * It always uses the same naive sys.path search strategy. The strategy > is not determined by some file contents. > > * The search is only done once - on the first import of the package. > > * It's possible to have a defining package dir and add-one package > dirs. > > * The search does not depend on the order of directories in sys.path. > There's no requirement for the defining package to appear first > on sys.path. > > * Namespace packages are easy to recognize by testing for a single > resource. > > * There's no conflict with existing files using the .pkg extension > such as Mac OS X installer files or Solaris packages. > > * Namespace __pkg__.py modules can provide extra meta-information, > logging, etc. to simplify debugging namespace package setups. > > * It's possible to freeze such setups, to put them into ZIP files, > or only have parts of it in a ZIP file and the other parts in the > file-system. > > * There's no need for a package directory scan, allowing the > mechanism to also work with resources that do not permit to > (easily and efficiently) scan the contents of a package "directory", > e.g. frozen packages or imports from web resources. > > Caveats: > > * Changes to sys.path will not result in an automatic rescan for > additional namespace packages, if the package was already loaded. > However, we could have a function to make such a rescan explicit. > """ > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Apr 07 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/ > > 2009-03-19: Released mxODBC.Connect 1.0.1 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/ >
Re: [Python-Dev] What's missing from easy_install
On Tue, Apr 7, 2009 at 15:05, KDr2 wrote: > I need an CPyAN. On the lighter side of things: That would be pronounced "spy-ann", which mean "the vomit" is swedish. Do you still want it? :-D -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] Shorter float repr in Python 3.1?
Mark Dickinson wrote: [snip...] Discussion points = (1) Any objections to including this into py3k? If there's controversy, then I guess we'll need a PEP. Big +1 (2) Should other Python implementations (Jython, IronPython, etc.) be expected to use short float repr, or should it just be considered an implementation detail of CPython? I propose the latter, except that all implementations should be required to satisfy eval(repr(x)) == x for finite floats x. Short float repr should be an implementation detail, so long as eval(repr(x)) == x still holds. Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] Shorter float repr in Python 3.1?
It would have helped if I'd copied the list... Sorry, Paul. 2009/4/7 Paul Moore : > 2009/4/7 Michael Foord : >> Mark Dickinson wrote: >>> >>> [snip...] >>> Discussion points >>> = >>> >>> (1) Any objections to including this into py3k? If there's >>> controversy, then I guess we'll need a PEP. >>> >> >> Big +1 >>> >>> (2) Should other Python implementations (Jython, >>> IronPython, etc.) be expected to use short float repr, or should >>> it just be considered an implementation detail of CPython? >>> I propose the latter, except that all implementations should >>> be required to satisfy eval(repr(x)) == x for finite floats x. >>> >> >> Short float repr should be an implementation detail, so long as >> eval(repr(x)) == x still holds. > > What he said :-) > 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] Shorter float repr in Python 3.1?
Mark Dickinson wrote:
One PyCon 2009 sprint later, Eric Smith and I have
produced the py3k-short-float-repr branch, which implements
short repr of floats and also does some major cleaning
up of the current float formatting functions.
We've gone for the {fast, correct} pairing.
We'd like to get this into Python 3.1.
Any thoughts/objections/counter-proposals/...?
As part of the decision process, we've tried this on several buildbots,
and it has been successful on at least:
AMD64 Gentoo:
http://www.python.org/dev/buildbot/3.x/amd64%20gentoo%203.x/builds/592
PPC Debian unstable:
http://www.python.org/dev/buildbot/3.x/ppc%20Debian%20unstable%203.x/builds/584
Sparc Solaris 10:
http://www.python.org/dev/buildbot/3.x/sparc%20solaris10%20gcc%203.x/builds/493
The Sparc test failed, but that wasn't our fault! Our tests succeeded.
These builds are in addition to x86 Linux and x86 Mac, which we've
developed on.
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] Shorter float repr in Python 3.1?
On Tue, Apr 07, 2009, Mark Dickinson wrote: > > Executive summary (details and discussion points below) > = > > Some time ago, Noam Raphael pointed out that for a float x, > repr(x) can often be much shorter than it currently is, without > sacrificing the property that eval(repr(x)) == x, and proposed > changing Python accordingly. See > > http://bugs.python.org/issue1580 Sounds good to me! -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "...string iteration isn't about treating strings as sequences of strings, it's about treating strings as sequences of characters. The fact that characters are also strings is the reason we have problems, but characters are strings for other good reasons." --Aahz ___ 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 new features to Python 2.x (PEP 382: Namespace Packages)
On Tue, Apr 7, 2009 at 5:25 AM, M.-A. Lemburg wrote: > On 2009-04-06 15:21, Jesse Noller wrote: >> On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg wrote: >>> On 2009-04-02 17:32, Martin v. Löwis wrote: I propose the following PEP for inclusion to Python 3.1. >>> Thanks for picking this up. >>> >>> I'd like to extend the proposal to Python 2.7 and later. >>> >> >> -1 to adding it to the 2.x series. There was much discussion around >> adding features to 2.x *and* 3.0, and the consensus seemed to *not* >> add new features to 2.x and use those new features as carrots to help >> lead people into 3.0. > > I must have missed that discussion :-) > > Where's the PEP pinning this down ? > > The Python 2.x user base is huge and the number of installed > applications even larger. > > Cutting these users and application developers off of important new > features added to Python 3 is only going to work as "carrot" for > those developers who: > > * have enough resources (time, money, manpower) to port their existing > application to Python 3 > > * can persuade their users to switch to Python 3 > > * don't rely much on 3rd party libraries (the bread and butter > of Python applications) > > Realistically, such a porting effort is not likely going to happen > for any decent sized application, except perhaps a few open source > ones. > > Such a policy would then translate to a dead end for Python 2.x > based applications. Think of the advantages though! Python 2 will finally become *stable*. The group of users you are talking to are usually balking at the thought of upgrading from 2.x to 2.(x+1) just as much as they might balk at the thought of Py3k. We're finally giving them what they really want. Regarding calling this a dead end, we're committed to supporting 2.x for at least five years. If that's not enough, well, it's open source, so there's no reason why some group of rogue 2.x fans can't maintain it indefinitely after that. -- --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] pyc files, constant folding and borderline portability issues
Well I'm sorry Cesare but this is unacceptable. As Skip points out there is plenty of code that relies on this. Also, consider what "problem" you are trying to solve here. What is the benefit to the user of moving this error to compile time? I cannot see any. --Guido On Tue, Apr 7, 2009 at 8:19 AM, Cesare Di Mauro wrote: > In data 07 aprile 2009 alle ore 17:19:25, ha scritto: > >> >> Cesare> The only difference at this time is regards invalid operations, >> Cesare> which will raise exceptions at compile time, not at running >> Cesare> time. >> >> Cesare> So if you write: >> >> Cesare> a = 1 / 0 >> >> Cesare> an exception will be raised at compile time. >> >> I think I have to call *bt* here. This is a common technique used >> during debugging. Insert a 1/0 to force an exception (possibly causing the >> running program to drop into pdb). I think you have to leave that in. >> >> Skip > > Many tests rely on this, and I have changed them from something like: > > try: > 1 / 0 > except: > > > to > > try: > a = 1; a / 0 > except: > > > But I know that it's a major source of incompatibilities, and in the final > code I'll enabled it only if user demanded it (through a flag). > > Cesare > ___ > 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/guido%40python.org > -- --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] calling dictresize outside dictobject.c
On Mon, Apr 06, 2009, Dan Schult wrote: > > I'm trying to write a C extension which is a subclass of dict. > I want to do something like a setdefault() but with a single lookup. python-dev is for core development, not for questions about using Python. Please use comp.lang.python or the capi-sig list. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "...string iteration isn't about treating strings as sequences of strings, it's about treating strings as sequences of characters. The fact that characters are also strings is the reason we have problems, but characters are strings for other good reasons." --Aahz ___ 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] pyc files, constant folding and borderline portability issues
On Tue, Apr 7, 2009 06:25PM, Guido van Rossum wrote: > Well I'm sorry Cesare but this is unacceptable. As Skip points out > there is plenty of code that relies on this. Guido, as I already said, in the final code the normal Python behaviour will be kept, and the stricter one will be enabled solely due to a flag set by the user. > Also, consider what > "problem" you are trying to solve here. What is the benefit to the > user of moving this error to compile time? I cannot see any. > > --Guido In my experience it's better to discover a bug at compile time rather than at running time. Cesare > On Tue, Apr 7, 2009 at 8:19 AM, Cesare Di Mauro > wrote: >> In data 07 aprile 2009 alle ore 17:19:25, ha scritto: >> >>> >>> Cesare> The only difference at this time is regards invalid >>> operations, >>> Cesare> which will raise exceptions at compile time, not at running >>> Cesare> time. >>> >>> Cesare> So if you write: >>> >>> Cesare> a = 1 / 0 >>> >>> Cesare> an exception will be raised at compile time. >>> >>> I think I have to call *bt* here. This is a common technique used >>> during debugging. Insert a 1/0 to force an exception (possibly causing >>> the >>> running program to drop into pdb). I think you have to leave that in. >>> >>> Skip >> >> Many tests rely on this, and I have changed them from something like: >> >> try: >> 1 / 0 >> except: >> >> >> to >> >> try: >> a = 1; a / 0 >> except: >> >> >> But I know that it's a major source of incompatibilities, and in the >> final >> code I'll enabled it only if user demanded it (through a flag). >> >> Cesare >> ___ >> 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/guido%40python.org >> > > > > -- > --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] pyc files, constant folding and borderline portability issues
On Tue, Apr 7, 2009 at 9:46 AM, Cesare Di Mauro wrote: > On Tue, Apr 7, 2009 06:25PM, Guido van Rossum wrote: >> Well I'm sorry Cesare but this is unacceptable. As Skip points out >> there is plenty of code that relies on this. > > Guido, as I already said, in the final code the normal Python behaviour > will be kept, and the stricter one will be enabled solely due to a flag > set by the user. Ok. >> Also, consider what >> "problem" you are trying to solve here. What is the benefit to the >> user of moving this error to compile time? I cannot see any. >> >> --Guido > > In my experience it's better to discover a bug at compile time rather than > at running time. That's my point though, which you seem to be ignoring: if the user explicitly writes "1/0" it is not likely to be a bug. That's very different than "1/x" where x happens to take on zero at runtime -- *that* is likely bug, but a constant folder can't detect that (at least not for Python). -- --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] Evaluated cmake as an autoconf replacement
On Wed, Apr 8, 2009 at 2:24 AM, Heikki Toivonen wrote: > David Cournapeau wrote: >> The hard (or rather time consuming) work is to do everything else that >> distutils does related to the packaging. That's where scons/waf are >> more interesting than cmake IMO, because you can "easily" give up this >> task back to distutils, whereas it is inherently more difficult with >> cmake. > > I think this was the first I heard about using SCons this way. Do you > have any articles or examples of this? If not, could you perhaps write one? I developed numscons as an experiment to build numpy, scipy, and other complex python projects depending on many library/compilers: http://github.com/cournape/numscons/tree/master The general ideas are somewhat explained on my blog http://cournape.wordpress.com/?s=numscons And also the slides from SciPy08 conf: http://conference.scipy.org/static/wiki/numscons.pdf It is plugged into distutils through a scons command (which bypasses all the compiled build_* ones, so that the whole build is done through scons for correct dependency handling). It is not really meant as a general replacement (it is too fragile, partly because of distutils, partly because of scons, partly because of me), but it shows it is possible not only theoretically. cheers, 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] PEP 382: Namespace Packages
At 04:58 PM 4/7/2009 +0200, M.-A. Lemburg wrote: On 2009-04-07 16:05, P.J. Eby wrote: > At 02:30 PM 4/7/2009 +0200, M.-A. Lemburg wrote: >> >> Wouldn't it be better to stick with a simpler approach and look for >> >> "__pkg__.py" files to detect namespace packages using that O(1) >> check ? >> > >> > Again - this wouldn't be O(1). More importantly, it breaks system >> > packages, which now again have to deal with the conflicting file names >> > if they want to install all portions into a single location. >> >> True, but since that means changing the package infrastructure, I think >> it's fair to ask distributors who want to use that approach to also take >> care of looking into the __pkg__.py files and merging them if >> necessary. >> >> Most of the time the __pkg__.py files will be empty, so that's not >> really much to ask for. > > This means your proposal actually doesn't add any benefit over the > status quo, where you can have an __init__.py that does nothing but > declare the package a namespace. We already have that now, and it > doesn't need a new filename. Why would we expect OS vendors to start > supporting it, just because we name it __pkg__.py instead of __init__.py? I lost you there. Since when do we support namespace packages in core Python without the need to add some form of magic support code to __init__.py ? My suggestion basically builds on the same idea as Martin's PEP, but uses a single __pkg__.py file as opposed to some non-Python file yaddayadda.pkg. Right... which completely obliterates the primary benefit of the original proposal compared to the status quo. That is, that the PEP 382 way is more compatible with system packaging tools. Without that benefit, there's zero gain in your proposal over having __init__.py files just call pkgutil.extend_path() (in the stdlib since 2.3, btw) or pkg_resources.declare_namespace() (similar functionality, but with zipfile support and some other niceties). IOW, your proposal doesn't actually improve the status quo in any way that I am able to determine, except that it calls for loading all the __pkg__.py modules, rather than just the first one. (And the setuptools implementation of namespace packages actually *does* load multiple __init__.py's, so that's still no change over the status quo for setuptools-using packages.) ___ 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] pyc files, constant folding and borderline portability issues
On Tue, Apr 7, 2009 07:22PM, Guido van Rossum wrote: >> In my experience it's better to discover a bug at compile time rather >> than >> at running time. > > That's my point though, which you seem to be ignoring: if the user > explicitly writes "1/0" it is not likely to be a bug. That's very > different than "1/x" where x happens to take on zero at runtime -- > *that* is likely bug, but a constant folder can't detect that (at > least not for Python). > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) I agree. My only concern was about user mistyping that can leed to an error interceptable by a stricter constant folder. But I admit that it's a rarer case compared to an explicit exception raising such the one you showed. Cesare ___ 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] Generator methods - "what's next" ?
Greg Ewing a écrit : Firephoenix wrote: I basically agreed with renaming the next() method to __next__(), so as to follow the naming of other similar methods (__iter__() etc.). But I noticed then that all the other methods of the generator had stayed the same (send, throw, close...) Keep in mind that next() is part of the iterator protocol that applies to all iterators, whereas the others are specific to generators. By your reasoning, any object that has any __xxx__ methods should have all its other methods turned into __xxx__ methods as well. Indeed, I kind of mixed up generators with the wider family of iterators. ___ 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] Mercurial?
> Ben is correct: you can't assume that contributors will have both a > first name and a last name, or that a first name and last name is > sufficient to legally identify them. Those from Spanish and Portuguese > cultures usually have two family names as well as a personal name; > people from Indonesian, Burmese and Malaysian cultures often only use a > single name. That's why asking for a policy. We have to have *some* way of identifying where a certain change originated from. I'm sure there is solution, and it doesn't matter to me whether I need to identify myself as "Martin v. Löwis" or "Martinv von Löwis of Menar". Regards, Martin ___ 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] pyc files, constant folding and borderline portability issues
On 7 Apr 2009, at 11:59, Alexandru Moșoi wrote: Not necessarily. For example C/C++ doesn't define the order of the operations inside an expression (and AFAIK neither Python) and therefore folding 2 * 3 is OK whether b is an integer or an arbitrary object with mul operator overloaded. Moreover one would expect * to be associative and commutative (take a look at Python strings); if a * 2 * 3 returns a different result from a * 6 I will find it very surprising and probably reject such code. That's not true. All ops in C/C++ have associativity that is fixed and well-defined; the star op is left-associative: 2*3*x is (2*3)*x is 6*x x*2*3 is (x*2)*3, and this is NOT x*6 (You can show this in C++ by creating a class that has a side-effect in its * operator). The star operator is not commutative in Python or C/C++ (otherwise what would __rmul__ do?). It's easier to see that + is not commutative: "abc"+"def" and "def"+"abc" are definitely different! You may be confusing the "order is undefined" for the evaluation of parameter lists in C/C++. Example: foo(f(),g()) calls f and g in an undefined order. Jared ___ 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] pyc files, constant folding and borderline portability issues
On Tue, Apr 7, 2009 at 8:59 PM, Alexandru Moșoi wrote: > Not necessarily. For example C/C++ doesn't define the order of the > operations inside an expression (and AFAIK neither Python) and > therefore folding 2 * 3 is OK whether b is an integer or an arbitrary > object with mul operator overloaded. Moreover one would expect * to be > associative and commutative (take a look at Python strings); if a * 2 > * 3 returns a different result from a * 6 I will find it very > surprising and probably reject such code. Multiplication is not associative for floats: >>> a = 0.1 >>> a*3*5 1.5002 >>> a*(3*5) 1.5 Fredrik ___ 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] $Id$ and sys.subversion (Was: Mercurial?)
One issue that the PEP needs to address is what to do with the files that use svn (really, CVS) keywords, and what should happen to sys.subversion. Along with it goes the question what sys.version should say. It probably would be good if somebody could produce a patch that can be applied to a mercurial checkout that gets these things right (perhaps a Mercurial branch in itself?). Subversion-specific code is both in configure.in, Makefile.pre.in, and PCbuild/make_buildinfo.c (not sure whether that would still be needed). Regards, Martin ___ 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 new features to Python 2.x (PEP 382: Namespace Packages)
> Such a policy would then translate to a dead end for Python 2.x > based applications. 2.x based applications *are* in a dead end, with the only exit being portage to 3.x. Regards, Martin ___ 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] Mercurial?
Dirkjan Ochtman wrote: > One of the nicer features of Mercurial/DVCSs, in my experience, is > that non-committers get to keep the credit on their patches. That > means that it's impossible to enforce a policy more extensive than > some basic checks (such as the format above). Unless we keep a list of > people who have signed an agreement, which will mean people will have > to re-do the username on commits that don't constitute a non-trivial > contribution. Maybe it'd be better to first replicate the current workflow, shortcomings and all, then later discuss a new policy? That would mean no credits for non-commiters should come from the VCS alone: those come from commit messages, the ACKS file, copyright notices in source, etc. BTW, keep in mind some people will prefer to submit diff-generated, non-hg patches. IMO, this use case should be supported before the rich-patch one. Regards, Daniel ___ 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] Mercurial?
On Tue, Apr 7, 2009 at 20:25, Daniel (ajax) Diniz wrote: > BTW, keep in mind some people will prefer to submit diff-generated, > non-hg patches. IMO, this use case should be supported before the > rich-patch one. Sure, that will be in the PEP as well (and it's quite simple). 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
[Python-Dev] pyc files, constant folding and borderline portability issues
> From: "Cesare Di Mauro" > So if Python will generate > > LOAD_CONST 1 > LOAD_CONST 2 > BINARY_ADD > > the constant folding code will simply replace them with a single > > LOAD_CONST 3 > > When working with such kind of optimizations, the temptation is to > apply them at any situation possible. For example, in other languages > this > > a = b * 2 * 3 > > will be replaced by > > a = b * 6 > > In Python I can't do that, because b can be an object which overloaded > the * operator, so it *must* be called two times, one for 2 and one for 3. Not necessarily. For example C/C++ doesn't define the order of the operations inside an expression (and AFAIK neither Python) and therefore folding 2 * 3 is OK whether b is an integer or an arbitrary object with mul operator overloaded. Moreover one would expect * to be associative and commutative (take a look at Python strings); if a * 2 * 3 returns a different result from a * 6 I will find it very surprising and probably reject such code. However you can fix the order of operations like this: a = (b * 2) * 3 or a = b * (2 * 3) or a = b * 2 a = a * 3 -- Alexandru Moșoi http://alexandru.mosoi.googlepages.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] decorator module in stdlib?
Daniel Fetchinson wrote: The decorator module [1] written by Michele Simionato is a very useful tool for maintaining function signatures while applying a decorator. Many different projects implement their own versions of the same functionality, for example turbogears has its own utility for this, I guess others do something similar too. Was the issue whether to include this module in the stdlib raised? If yes, what were the arguments against it? If not, what do you folks think, shouldn't it be included? I certainly think it should be. Originally I sent this message to c.l.p [2] and Michele suggested it be brought up on python-dev. He also pointed out that a PEP [3] is already written about this topic and it is in draft form. What do you guys think, wouldn't this be a useful addition to functools? [1] http://pypi.python.org/pypi/decorator [2] http://groups.google.com/group/comp.lang.python/browse_thread/thread/d4056023f1150fe0 [3] http://www.python.org/dev/peps/pep-0362/ This probably should have gone to the python-ideas list. In any case, I think it needs to start with a clear offer from Michele (directly or relayed by you) to contribute it to the PSF with the usual conditions. ___ 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] pyc files, constant folding and borderline portability issues
Cesare Di Mauro wrote: On Tue, Apr 7, 2009 07:22PM, Guido van Rossum wrote: In my experience it's better to discover a bug at compile time rather than at running time. That's my point though, which you seem to be ignoring: if the user explicitly writes "1/0" it is not likely to be a bug. That's very different than "1/x" where x happens to take on zero at runtime -- *that* is likely bug, but a constant folder can't detect that (at least not for Python). -- --Guido van Rossum (home page: http://www.python.org/~guido/) I agree. My only concern was about user mistyping that can leed to an error interceptable by a stricter constant folder. But I admit that it's a rarer case compared to an explicit exception raising such the one you showed. I would guess that it is so rare as to not be worth bothering about. ___ 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] pyc files, constant folding and borderline portability issues
Alexandru Moșoi wrote: From: "Cesare Di Mauro" So if Python will generate LOAD_CONST 1 LOAD_CONST 2 BINARY_ADD the constant folding code will simply replace them with a single LOAD_CONST 3 When working with such kind of optimizations, the temptation is to apply them at any situation possible. For example, in other languages this a = b * 2 * 3 will be replaced by a = b * 6 In Python I can't do that, because b can be an object which overloaded the * operator, so it *must* be called two times, one for 2 and one for 3. Not necessarily. For example C/C++ doesn't define the order of the operations inside an expression (and AFAIK neither Python) Yes is does. Expression/Evaluation order "Python evaluates expressions from left to right." ___ 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] Evaluated cmake as an autoconf replacement
On Tue, Apr 7, 2009 at 3:23 PM, David Cournapeau wrote: > On Tue, Apr 7, 2009 at 10:08 PM, Alexander Neundorf > wrote: > >> >> What is involved in building python extensions ? Can you please explain ? > > Not much: at the core, a python extension is nothing more than a > dynamically loaded library + a couple of options. CMake has support (slightly but intentionally undocumented) for this, from FindPythonLibs.cmake: # PYTHON_ADD_MODULE( src1 src2 ... srcN) is used to build modules for python. # PYTHON_WRITE_MODULES_HEADER() writes a header file you can include # in your sources to initialize the static python modules Using python_add_module(name file1.c file2.c) you can build python modules, and decide at cmake time whether it should be a dynamically loaded module (default) or whether it should be built as a static library (useful for platforms without shared libs). Installation then happens simply via install(TARGETS ...) > One choice is whether to take options from distutils or to set them up What options ? > independently. In my own scons tool to build python extensions, both > are possible. > > The hard (or rather time consuming) work is to do everything else that > distutils does related to the packaging. That's where scons/waf are > more interesting than cmake IMO, because you can "easily" give up this > task back to distutils, whereas it is inherently more difficult with > cmake. Can you please explain ? It is easy to run external tools with cmake at cmake time and at build time, and it is also possible to run them at install time. 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
[Python-Dev] ANN: deps extension (fwd)
I know the subject of external dependencies came up here in the discussion about Mercurial. I just saw this on the Mercurial mailing list. Perhaps it will be of interest to our hg mavens. Skip --- Begin Message --- Hi, I've recently cloned the deps extension, originally developed by Aleix Conchillo Flaque, and have made some improvements. I'd love to hear your comments. http://ratatanek.cz/hg/hgdeps It should work with version 1.0 and above (tested on 1.0 and 1.2.1). The extension allows you to comfortably work with external dependencies. The dependency lists are versioned and can be quickly applied with 'hg depupdate' command. The easiest way to start is to define the dependencies you'll be using. $ hg depalias gui http://ratatanek.cz/hg/gui A file named .hgdeps will appear in your working dir. Don't forget to commit! Use 'hg dep' to move and update dependencies. $ hg dep gui lib/gui v0.1 You can always check the state of your dependencies with 'hg -v depstatus'. After you make sure your project works correctly with the new dependency or the new version of an old dependency, commit your changes and then run 'hg depcommit', which will record your changes into .hgdeps file and automatically commit them. Think of this command the same way you think about 'hg tag'. You can safely run 'hg depcommit' after each 'hg commit', the dependency list will only be recorded if some changes were made. $ hg depcommit $ hg log changeset: 6:7be195f652bf tag: tip user:Martin Vejnar date:Tue Apr 07 14:19:29 2009 +0200 summary: Updated dependency list for changeset 7220338eb0ac changeset: 5:7220338eb0ac user:Martin Vejnar date:Sat Apr 04 16:44:40 2009 +0200 summary: Updated gui to v0.2 and fixed dependent code. You can also use the extension to work with svn dependencies. Read 'hg help hgdeps' for more info. I'm planning on wrapping 'hg up', 'hg st' and 'hg ci' to automatically run 'hg depup', 'hg depst' and 'hg depci', respectively. This way, the management of dependencies would be completely transparent. Hope you like it, -- Martin ___ Mercurial mailing list mercur...@selenic.com http://selenic.com/mailman/listinfo/mercurial --- End Message --- ___ 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] Evaluated cmake as an autoconf replacement
David Cournapeau wrote: Having a full fledged language for complex builds is nice, I think most familiar with complex makefiles would agree with this. Yes, people will still need general computation in their build process from time to time whether the build tool they're using supports it or not. And if it doesn't, they'll resort to some ungodly mash such as Makefile+ shell+m4. Python has got to be a better choice than that. -- Greg ___ 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] Evaluated cmake as an autoconf replacement
On Wed, Apr 8, 2009 at 12:43 AM, Greg Ewing wrote: > David Cournapeau wrote: >> >> Having a full >> fledged language for complex builds is nice, I think most familiar >> with complex makefiles would agree with this. > > Yes, people will still need general computation in their > build process from time to time whether the build tool > they're using supports it or not. I'm maintaining the CMake-based buildsystem for KDE4 since 3 years now in my sparetime, millions lines of code, multiple code generators, all major operating systems. My experience is that people don't need general computation in their build process. CMake supports now more general purpose programming features than it did 2 years ago, e.g. it has now functions with local variables, it can do simple math, regexps and other things. If we get to the point where this is not enough, it usually means a real program which does real work is required. In this case it's actually a good thing to have this as a separate tool, and not mixed into the buildsystem. Having a not very powerful, but therefor domain specific language for the buildsystem is really a feature :-) (even if it sounds wrong in the first moment). >From what I saw when I was building Python I didn't actually see too complicated things. In KDE4 we are not only building and installing programs, but we are also installing and shipping a development platform. This includes CMake files which contain functionality which helps in developing KDE software, i.e. variables and a bunch of KDE-specific macros. They are documented here: http://api.kde.org/cmake/modules.html#module_FindKDE4Internal (this is generated automatically from the cmake file we ship). I guess something similar could be useful for Python, maybe this is what distutils actually do ? I.e. they help with developing python-standard-conformant software ? This could be solved easily if python would install a cmake file which provides the necessary utility functions/macros. 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
[Python-Dev] Is there an issue with bugs.python.org currently
Sadly, my work firewall/proxy often handles things badly, so I can't actually tell. Is bugs.python.org accepting changes at the moment (I'm trying to update the Stage of an issue)? Cheers, -T -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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] Evaluated cmake as an autoconf replacement
Alexander Neundorf wrote: My experience is that people don't need general computation in their build process. > ... CMake supports now more general purpose programming features than it did 2 years ago, e.g. it has now functions with local variables, it can do simple math, regexps and other things. In other words, it's growing towards being able to do general computation. Why is it doing that, if people don't need general computation in their build process? If we get to the point where this is not enough, it usually means a real program which does real work is required. In this case it's actually a good thing to have this as a separate tool, and not mixed into the buildsystem. There's some merit in that idea, but the build tool and the program need to work together smoothly somehow. If the build tool is implemented in Python, there's more chance of that happening (e.g. the Python code can import parts of the build system and call them directly, rather than having to generate a file in some other language). -- Greg ___ 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] Evaluated cmake as an autoconf replacement
On Wed, Apr 8, 2009 at 6:42 AM, Alexander Neundorf wrote: > What options ? Compilation options. If you build an extension with distutils, the extension is built with the same flags as the ones used by python, the options are taken from distutils.sysconfig (except for MS compilers, which has its own options, which is one of the big pain in distutils). > > Can you please explain ? If you want to stay compatible with distutils, you have to do quite a lot of things. Cmake (and scons, and waf) only handle the build, but they can't handle all the packaging done by distutils (tarballs generation, binaries generation, in place build, develop mode of setuptools, eggs, .pyc and .pyo generation, etc...), so you have two choices: add support for this in the build tool (lot of work) or just use distutils once everything is built with your tool of choice. > It is easy to run external tools with cmake at cmake time and at build > time, and it is also possible to run them at install time. Sure, what can of build tool could not do that :) But given the design of distutils, if you want to keep all its packaging features, you can't just launch a few commands, you have to integrate them somewhat. Everytime you need something from distutils, you would need to launch python for cmake, whether with scons/waf, you can just use it as you would use any python library. That's just inherent to the fact that waf/scons are in the same language as distutils; if we were doing ocaml builds, having a build tool in ocaml would have been easier, etc... 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] Evaluated cmake as an autoconf replacement
On Wed, Apr 8, 2009 at 7:54 AM, Alexander Neundorf wrote: > On Wed, Apr 8, 2009 at 12:43 AM, Greg Ewing > wrote: >> David Cournapeau wrote: >>> >>> Having a full >>> fledged language for complex builds is nice, I think most familiar >>> with complex makefiles would agree with this. >> >> Yes, people will still need general computation in their >> build process from time to time whether the build tool >> they're using supports it or not. > > I'm maintaining the CMake-based buildsystem for KDE4 since 3 years now > in my sparetime, millions lines of code, multiple code generators, all > major operating systems. My experience is that people don't need > general computation in their build process. > CMake supports now more general purpose programming features than it > did 2 years ago, e.g. it has now functions with local variables, it > can do simple math, regexps and other things. > If we get to the point where this is not enough, it usually means a > real program which does real work is required. > In this case it's actually a good thing to have this as a separate > tool, and not mixed into the buildsystem. > Having a not very powerful, but therefor domain specific language for > the buildsystem is really a feature :-) > (even if it sounds wrong in the first moment). Yes, there are some advantages to that. The point of python is to have the same language for the build specification and the extensions, in my mind. For extensions, you really need a full language - for example, if you want to add support for tools which generate unknown files in advance, and handle this correctly from a build POV, a macro-like language is not sufficient. > > >From what I saw when I was building Python I didn't actually see too > complicated things. In KDE4 we are not only building and installing > programs, but we are also installing and shipping a development > platform. This includes CMake files which contain functionality which > helps in developing KDE software, i.e. variables and a bunch of > KDE-specific macros. They are documented here: > http://api.kde.org/cmake/modules.html#module_FindKDE4Internal > (this is generated automatically from the cmake file we ship). > I guess something similar could be useful for Python, maybe this is > what distutils actually do ? distutils does roughly everything that autotools does, and more: - configuration: not often used in extensions, we (numpy) are the exception I would guess - build - installation - tarball generation - bdist_ installers (msi, .exe on windows, .pkg/.mpkg on mac os x, rpm/deb on Linux) - registration to pypi - more things which just ellude me at the moment cheers, 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
[Python-Dev] http://bugs.python.org/issue2240
This issue has been largely resolved, but there is an outstanding bug where the (reviewed and committed) solution does not work on certain versions of FreeBSD (broken in 6.3, working in 7+). Do we have a list of 'supported platforms', and is FreeBSD 6.3 in it? What's the policy with regards to supporting dependencies like this? Should I set this issue to 'pending' seeing as no-one is currently working on a patch for this? Or is leaving this open and hanging around exactly the right thing to do? Cheers, -T -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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] calling dictresize outside dictobject.c
Did you read the post until the end? The OP is asking a question related to a very low level detail of dict implementation and making an offer to write a patch that could speed-up dict.setdefault() in core CPython... IMHO, a poll on python-dev do makes sense... On Tue, Apr 7, 2009 at 1:34 PM, Aahz wrote: > On Mon, Apr 06, 2009, Dan Schult wrote: >> >> I'm trying to write a C extension which is a subclass of dict. >> I want to do something like a setdefault() but with a single lookup. > > python-dev is for core development, not for questions about using Python. > Please use comp.lang.python or the capi-sig list. > -- > Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ > > "...string iteration isn't about treating strings as sequences of strings, > it's about treating strings as sequences of characters. The fact that > characters are also strings is the reason we have problems, but characters > are strings for other good reasons." --Aahz > ___ > 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/dalcinl%40gmail.com > -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ 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] http://bugs.python.org/issue2240
On Tue, Apr 7, 2009 at 11:54 PM, Tennessee Leeuwenburg wrote: > This issue has been largely resolved, but there is an outstanding bug where > the (reviewed and committed) solution does not work on certain versions of > FreeBSD (broken in 6.3, working in 7+). Do we have a list of 'supported > platforms', and is FreeBSD 6.3 in it? > > What's the policy with regards to supporting dependencies like this? Should > I set this issue to 'pending' seeing as no-one is currently working on a > patch for this? Or is leaving this open and hanging around exactly the right > thing to do? > I would find more appropriate to close this as fixed because the issue was about adding setitimer and getitimer wrappers and that is done. We could then create another issue regarding this bug in specific versions of freebsd towards this setitimer/getitimer wrapper. That is what makes more sense to me. > Cheers, > -T > > > > -- > -- > Tennessee Leeuwenburg > http://myownhat.blogspot.com/ > "Don't believe everything you think" > Regards, -- -- Guilherme H. Polo Goncalves ___ 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] http://bugs.python.org/issue2240
On Wed, Apr 8, 2009 at 1:14 PM, Guilherme Polo wrote: > On Tue, Apr 7, 2009 at 11:54 PM, Tennessee Leeuwenburg > wrote: > > This issue has been largely resolved, but there is an outstanding bug > where > > the (reviewed and committed) solution does not work on certain versions > of > > FreeBSD (broken in 6.3, working in 7+). Do we have a list of 'supported > > platforms', and is FreeBSD 6.3 in it? > > > > What's the policy with regards to supporting dependencies like this? > Should > > I set this issue to 'pending' seeing as no-one is currently working on a > > patch for this? Or is leaving this open and hanging around exactly the > right > > thing to do? > > > > I would find more appropriate to close this as fixed because the issue > was about adding setitimer and getitimer wrappers and that is done. > > We could then create another issue regarding this bug in specific > versions of freebsd towards this setitimer/getitimer wrapper. That is > what makes more sense to me. Hi Guilherme, I'd agree with that. I just wonder whether it's necessary to create another issue, or whether the issue can be marked as 'fixed' without opening the new issue. It seems like the bug relates only to an older version of a 'weird' operating system and could perhaps be left unfixed without causing anyone any problems. Cheers, -T ___ 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
[Python-Dev] RELEASED Python 2.6.2 candidate 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm happy to announce the release of Python 2.6.2 candidate 1. This release contains dozens of bug fixes since Python 2.6.1. Please see the NEWS file for a detailed list of changes. Barring unforeseen problems, Python 2.6.2 final will be released within a few days. http://www.python.org/download/releases/2.6.2/NEWS.txt For more information on Python 2.6 please see http://docs.python.org/dev/whatsnew/2.6.html Source tarballs and Windows installers for this release candidate can be downloaded from the Python 2.6.2 page: http://www.python.org/download/releases/2.6.2/ Bugs can be reported in the Python bug tracker: http://bugs.python.org Enjoy, Barry Barry Warsaw ba...@python.org Python 2.6/3.0 Release Manager (on behalf of the entire python-dev team) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSdwZ0HEjvBPtnXfVAQJTsAP+Krt1F6qGjuk9a7q8HwF2oAWr/peIAfDf 7HGjOpieoyyAKO1ZNqWvxZ1Ftx+I0YHjfk5OKz/1FN9H3eteFU/L5EEbJD1iTSmK LAOycWWtWJp+OPatqveHZbGr4ap4XON05yMrzlewnnIH0iGnYjMAgxKkwVKA7MwN BiXDeBPba1A= =HdKG -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] decorator module in stdlib?
On Tue, Apr 7, 2009 at 11:04 PM, Terry Reedy wrote: > > This probably should have gone to the python-ideas list. In any case, I > think it needs to start with a clear offer from Michele (directly or relayed > by you) to contribute it to the PSF with the usual conditions. I have no problem to contribute the module to the PSF and to maintain it. I would just prefer to have the ability to change the function signature in the core language rather than include in the standard library a clever hack. M. Simionato ___ 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] http://bugs.python.org/issue2240
Tennessee Leeuwenburg writes: > I'd agree with that. I just wonder whether it's necessary to create another > issue, or whether the issue can be marked as 'fixed' without opening the new > issue. Opening a new issue has the effect of running a poll of those who watch such issues on the tracker (in particular, I'd grandfather the nosy list). You could even set the new issue to pending at that time. ___ 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
[Python-Dev] slightly inconsistent set/list pop behaviour
Now, I know that sets aren't ordered, but... foo = set([1,2,3,4,5]) bar = [1,2,3,4,5] foo.pop() will reliably return 1 while bar.pop() will return 5 discuss :) Cheers, -T ___ 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] slightly inconsistent set/list pop behaviour
[Tennessee Leeuwenburg ] Now, I know that sets aren't ordered, but... foo = set([1,2,3,4,5]) bar = [1,2,3,4,5] foo.pop() will reliably return 1 while bar.pop() will return 5 discuss :) If that's what you need: http://code.activestate.com/recipes/576694/ Raymond ___ 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] http://bugs.python.org/issue2240
-On [20090408 05:24], Tennessee Leeuwenburg (tleeuwenb...@gmail.com) wrote: >It seems like the bug relates only to an older version of a 'weird' >operating system and could perhaps be left unfixed without causing >anyone any problems. Being one of the FreeBSD guys I'll throw peanuts at you. :P In any case, 6.3 is from early 2008 and 6.4 is from November 2008. The 6-STABLE branch is still open and a lot of users are still tracking this. However, the main focus is 7 and with 8 looming on the horizon. And FreeBSD 7 does away with libc_r and uses a whole different model for its threading. Are the tests going ok there? If so, then I shouldn't worry about the 6 branch. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Few are those who see with their own eyes and feel with their own hearts... ___ 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] decorator module in stdlib?
On Wed, Apr 8, 2009 at 12:09 AM, Michele Simionato wrote: > On Tue, Apr 7, 2009 at 11:04 PM, Terry Reedy wrote: >> >> This probably should have gone to the python-ideas list. In any case, I >> think it needs to start with a clear offer from Michele (directly or relayed >> by you) to contribute it to the PSF with the usual conditions. > > I have no problem to contribute the module to the PSF and to maintain it. > I would just prefer to have the ability to change the function signature in > the core language rather than include in the standard library a clever hack. Flipping Michele's commit bit (if he wants it) is overdue. A quick google doesn't show he refused it in the past, but the same search shows the things things he did do - including the explication of MRO in 2.3 (http://www.python.org/download/releases/2.3/mro/). Plus he's a softie for decorators, as am I. -Jack ___ 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] slightly inconsistent set/list pop behaviour
Tennessee Leeuwenburg wrote: > Now, I know that sets aren't ordered, but... > > foo = set([1,2,3,4,5]) > bar = [1,2,3,4,5] > > foo.pop() will reliably return 1 > while bar.pop() will return 5 > > discuss :) As designed. If you play around a bit it becomes clear that what set.pop() returns is independent of the insertion order: PythonWin 2.5.2 (r252:60911, Mar 27 2008, 17:57:18) [MSC v.1310 32 bit (Intel)] on win32. >>> foo = set([5,4,3,2,1]) # Order reversed from above >>> foo.pop() 1 >>> foo = set([-1,0,1,2,3,4,5]) >>> foo.pop() 0 >>> foo = set([-1,1,2,3,4,5]) >>> foo.pop() 1 As the documentation says (http://docs.python.org/library/stdtypes.html#set.pop) set.pop() is free to return an arbitrary element. list.pop() however always returns the last element of the list, unless of course you specify some other index: http://docs.python.org/library/stdtypes.html#mutable-sequence-types, point 6. John ___ 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] slightly inconsistent set/list pop behaviour
On Wed, Apr 8, 2009 at 7:13 AM, John Barham wrote: > If you play around a bit it becomes clear that what set.pop() returns > is independent of the insertion order: It might look like that, but I don't think this is true in general (at least, with the current implementation): >>> foo = set([1, 65537]) >>> foo.pop() 1 >>> foo = set([65537, 1]) >>> foo.pop() 65537 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
