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 alternative syntax
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 behaviour
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 how to
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 looks
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'
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
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 the noise
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
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 why this
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
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
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'
-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; it's faster,
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
msiexec logs, and
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 assembly.
but I
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
http://www.openplans.org/projects/plone-conference-2008-dc/distribute.
--amIf
[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 specifically?
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
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
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).
-
On 11:12 pm, [EMAIL PROTECTED] wrote:
- The backport to release26-maint
http://svn.python.org/view?rev=66865view=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
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
[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
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
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(PyObject *object,
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
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 they
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
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
at least
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 you ever
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
(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:
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
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
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,
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 (presumably) as
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
37 matches
Mail list logo
