Re: [Python-Dev] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c

"Martin v. Löwis" writes: > > If they do fail, they're not "false" positives. If they're "false", > > then the test is broken, no? > > Correct. But they might well be broken, no? I would hope some effort is made that they not be. If they generate a positive, I would expect that the contrib

Re: [Python-Dev] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c

Andrew Bennetts wrote: > "Martin v. Löwis" wrote: > [...] >> There is a certain prevention already that later maintenance fixes don't >> break the earlier ones: those fixes typically get checked into the trunk >> also, where the tests do exist. So the committer would find out even >> before the pat

Re: [Python-Dev] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c

"Martin v. Löwis" wrote: [...] > There is a certain prevention already that later maintenance fixes don't > break the earlier ones: those fixes typically get checked into the trunk > also, where the tests do exist. So the committer would find out even > before the patch gets to the maintenance bran

Re: [Python-Dev] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c

> Presumably if the new tests cover functionality that somebody cares > about, it would be valuable to make sure that maintenance bugfixes don't > break this functionality in maintenance branches either? Yes. At the same time, there is also a risk that the new tests just fail because they are not

Re: [Python-Dev] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c

> If they do fail, they're not "false" positives. If they're "false", > then the test is broken, no? Correct. But they might well be broken, no? > So find a way to label them as tests > added ex-post, with the failures *not* being regressions but rather > latent bugs newly detected, and (presuma

Re: [Python-Dev] Documentation idea

This is a really interesting idea. If extra memory/lookup overhead is a concern, you could enable this new feature by default when the interactive interpreter is started (where it's more likely to be invoked), and turn it off by default when running scripts/modules. Jared On 9 Oct 2008, at

Re: [Python-Dev] Documentation idea

On 9 Oct, 11:12 pm, [EMAIL PROTECTED] wrote: Background -- In the itertools module docs, I included pure python equivalents for each of the C functions. Necessarily, some of those equivalents are only approximate but they seem to have greatly enhanced the docs. Why not go the other

[Python-Dev] another test message - please ignore

still working on spam filter... 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

[Python-Dev] test message - please ignore

(messing with the python.org spam filter - please ignore) 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] Documentation idea

Yes, I'm looking a couple of different approaches to loading the strings. For now though, I want to focus on the idea itself, not the implementation. The important thing is to gather widespread support before getting into the details of how the strings get loaded. Raymond - Original Messa

Re: [Python-Dev] Documentation idea

On Thu, Oct 9, 2008 at 8:50 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Christian Heimes] >> >> The idea sounds great! >> >> Are you planing to embed the pure python code in C code? > > Am experimenting with a descriptor that fetches the attribute string from a > separate text file. Have y

Re: [Python-Dev] __getattr__ and new style classes

On Thu, Oct 9, 2008 at 5:37 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Amaury Forgeot d'Arc wrote: > >> But this is already the case, and the reason why there are three >> variable to describe an exception: type, value and traceback. > > Yes, but you only get one object for the value, which means

Re: [Python-Dev] Documentation idea

On Thu, Oct 9, 2008 at 4:12 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: [SNIP] > Bright idea > -- > Let's go one step further and do this just about everywhere and instead of > putting it in the docs, attach an exec-able string as an attribute to our C > functions. Further, those pure

Re: [Python-Dev] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c

"Martin v. Löwis" writes: > I'm skeptical that new tests actually need backporting at all. Python > doesn't really get better by new tests being added to an old branch. > Near-term, it might get worse because the new tests might cause false > positives, making users worried for no reason. If

Re: [Python-Dev] __getattr__ and new style classes

Amaury Forgeot d'Arc wrote: But this is already the case, and the reason why there are three variable to describe an exception: type, value and traceback. Yes, but you only get one object for the value, which means at least allocating a tuple if you want to be able to report something like "At

Re: [Python-Dev] __getattr__ and new style classes

Hello, On Fri, Oct 10, 2008 at 2:15 AM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Nick Coghlan wrote: > >> If the time is being spent in PyErr_Format, how far could you get adding >> a dedicated function for creating AttributeErrors? Something along the >> lines of: >> >> PyErr_AttributeError(PyObje

Re: [Python-Dev] __getattr__ and new style classes

Nick Coghlan wrote: If the time is being spent in PyErr_Format, how far could you get adding a dedicated function for creating AttributeErrors? Something along the lines of: PyErr_AttributeError(PyObject *object, PyObject *attr_name) More generally, it might be useful to have some mechanism f

Re: [Python-Dev] Documentation idea

[Christian Heimes] The idea sounds great! Are you planing to embed the pure python code in C code? Am experimenting with a descriptor that fetches the attribute string from a separate text file. This keeps the C build from getting fat. More importantly, it let's us write the execable string

Re: [Python-Dev] Documentation idea

Raymond Hettinger wrote: lots of cool stuff! The idea sounds great! Are you planing to embed the pure python code in C code? That's going to increase the data segment of the executable. It should be possible to disable and remove the pure python example with a simple ./configure option and so

Re: [Python-Dev] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c

On 11:12 pm, [EMAIL PROTECTED] wrote: - The backport to release26-maint http://svn.python.org/view?rev=66865&view=rev also merged other changes (new unrelated unit tests). IMO unrelated changes should be committed separately: different commit messages help to understand the motivation of each

Re: [Python-Dev] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c

> It seems to me that Skip was asking whether the "memory leak" impacted > the 2.6 branch, and the answer should have been "No": the change that > introduced the memory leak had just been committed 10 minutes before. You are probably right (although it's not quite clear from Skip's question). > -

[Python-Dev] Documentation idea

Background -- In the itertools module docs, I included pure python equivalents for each of the C functions. Necessarily, some of those equivalents are only approximate but they seem to have greatly enhanced the docs. Something similar is in the builtin docs for any() and all(). The ne

Re: [Python-Dev] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c

Hello, Concerning the management of this particular change / development, I see three additional issues: - First, I think that the answer given here: http://mail.python.org/pipermail/python-checkins/2008-October/074659.html does not match the question. It seems to me that Skip was asking whet

Re: [Python-Dev] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c

[switching to python-dev] Georg Brandl wrote: > Martin v. Löwis schrieb: >> Raymond Hettinger wrote: Merges should be handled by the original committer. >>> Respectfully disagree. Some people here having been taking >>> responsibility for keeping the branches in-sync >> Which people specifi

[Python-Dev] Distutils/packaging sprint this weekend

Tarek Zidae' is organizing a sprint on general distutils/setuptools/packaging this weekend. Physically it's in Arlington VA, but participants will be hanging out in #distutils on freenode's IRC. More information at . --am"If

Re: [Python-Dev] python dll no longer in system directory?

> I confirm this. The following lines in msi.py seem to be the cause of > the change: > > #dlldir = PyDirectory(db, cab, root, srcdir, "DLLDIR", ".") > #install python30.dll into root dir for now > dlldir = root > > They were added by r61109: " Bundle msvcr90.dll as a "private assembl

Re: [Python-Dev] python dll no longer in system directory?

Amaury Forgeot d'Arc schrieb: > 2008/10/8 "Martin v. Löwis" <[EMAIL PROTECTED]>: >> Thomas Heller wrote: >>> Is it intended that python30.dll and python26.dll are not longer >>> installed in the \windows\system32 directory? >> >> No, it's not. Please create a bug report (or, better, study the >> ms

Re: [Python-Dev] asyncore fixes in Python 2.6 broke Zope's version of medusa

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guido van Rossum wrote: > On Wed, Oct 8, 2008 at 6:39 PM, Bill Janssen <[EMAIL PROTECTED]> wrote: >> Josiah Carlson <[EMAIL PROTECTED]> wrote: >> >>> But yes, zope needs to be changed to reflect the updated >>> asyncore/asynchat semantics. Trust me; i

Re: [Python-Dev] __getattr__ and new style classes

It's an interesting idea... But it seems hard to forge the magic that does this (creating it in args[0] on demand) without some heavy work. In my opinion, the problem is that we are raising all these errors at all, with object creation and all that it entails. We are using exceptions very much a

Re: [Python-Dev] Subversion access down?

On Thu, Oct 09, 2008 at 10:50:24AM +0200, Ulrich Eckhardt wrote: > Is it only me or does it fail for other people, too? I'm getting > > | Server sent unexpected return value (503 Service > | Unavailable) in response to OPTIONS request > | for 'http://svn.python.org/projects/python/trunk' svn.p

Re: [Python-Dev] Subversion access down?

On Thu, Oct 09, 2008 at 10:50:24AM +0200, Ulrich Eckhardt wrote: > Is it only me or does it fail for other people, too? I'm getting > > | Server sent unexpected return value (503 Service > | Unavailable) in response to OPTIONS request > | for 'http://svn.python.org/projects/python/trunk' pytho

Re: [Python-Dev] Subversion access down?

Ulrich Eckhardt wrote: > Hi! > > Is it only me or does it fail for other people, too? I'm getting > > | Server sent unexpected return value (503 Service > | Unavailable) in response to OPTIONS request > | for 'http://svn.python.org/projects/python/trunk' svn+ssh access is working for me - it lo

Re: [Python-Dev] __getattr__ and new style classes

Kristján Valur Jónsson wrote: > Running regular python code through a profiler, and especially code that > relies much on the use of > __getattr__() to emulate attribute access, will show hideous amounts of time > spent formatting > attribute exceptions that get thrown away. > > Any thoughts on

Re: [Python-Dev] __getattr__ and new style classes

Christian Heimes wrote: > Nick Coghlan wrote: >> I think it's actually some single quotes that got mangled by the mailer. >> Either way, something else is going on for Kristján to see such wildly >> different results between old-style and new-style attribute access, when >> the differences are in t

Re: [Python-Dev] effect of "exec" on local scope

Guido van Rossum wrote: > Well, I don't recall what CLPython is, but I believe it is broken and > that code should work -- there are (or used to be) examples of using > exec to populate classes in the standard library so while it may look > dodgy it really is exected to work... I think this behavi

Re: [Python-Dev] __getattr__ and new style classes

Nick Coghlan wrote: I think it's actually some single quotes that got mangled by the mailer. Either way, something else is going on for Kristján to see such wildly different results between old-style and new-style attribute access, when the differences are in the noise for the other folks checkin

Re: [Python-Dev] __getattr__ and new style classes

No, it was really me being sloppy using outlook and fighting the editor trying to insert smart quotes :) Sorry for the confusion. K > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Christian Heimes > Kristján is using the old style and alternative

Re: [Python-Dev] __getattr__ and new style classes

Thanks for trying this out. When I saw your comments, I realized that the difference is due to a speed patch that we have her at CCP. The test was run using current 2.5 python, with a patch applied, as attached this message. The patch was written by me a few years back when I noticed that python

Re: [Python-Dev] __getattr__ and new style classes

Christian Heimes wrote: > Steven D'Aprano wrote: >> Not only don't I observe the same results as you, I'm afraid I can't >> even get your code to run. I get a SyntaxError from the funny quotes >> you're using: ´d.foo´ instead of 'd.foo' or "d.foo". > > Kristján is using the old style and alternati

Re: [Python-Dev] python dll no longer in system directory?

2008/10/8 "Martin v. Löwis" <[EMAIL PROTECTED]>: > Thomas Heller wrote: >> Is it intended that python30.dll and python26.dll are not longer >> installed in the \windows\system32 directory? > > No, it's not. Please create a bug report (or, better, study the > msiexec logs, and msi.py, to find out wh

[Python-Dev] Subversion access down?

Hi! Is it only me or does it fail for other people, too? I'm getting | Server sent unexpected return value (503 Service | Unavailable) in response to OPTIONS request | for 'http://svn.python.org/projects/python/trunk' Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht H