Tim Peters wrote:
Today I noticed this happened when the buildbot started to run tests,
and I'm 100% sure it's due to this code in
Tools/buildbot/kill_python.c
Didn't you know that you signed in to run arbitrary viruses, worms, and
trojan horses when you added your machine to the buildbot
Collin Winter wrote:
Is it intentional that Python 2.5 is (currently) shipping with
distutils 2.4.0, while Python 2.4 (at least 2.4.1, 2.4.2 and 2.4.3)
shipped with distutils 2.4.1? Judging from my own tests, distutils
2.4.1 fixed several bugs that some of my test suites depend on (the
fixes,
On Thursday 27 July 2006 16:40, Martin v. Löwis wrote:
Collin Winter wrote:
Is it intentional that Python 2.5 is (currently) shipping with
distutils 2.4.0, while Python 2.4 (at least 2.4.1, 2.4.2 and
2.4.3) shipped with distutils 2.4.1? Judging from my own tests,
distutils 2.4.1 fixed
An updated version is now available, based to the feedback of Phillip J.
Eby and David Hopwood (stand-alone module[1], patch[2]):
- the module is now reentrant
- the sloppy case with Name nodes is now covered properly
- the node lookup procedure was optimized, leading to a 20% speed
increase on
I've uploaded a patch sent to me in private email by Damien Miller, who
is packaging ctypes for the OpenBSD port tree.
I'm requesting permission to commit this for Python 2.5.
http://python.org/sf/1529514
Thanks,
Thomas
___
Python-Dev mailing list
Neal Norwitz wrote:
What is the behaviour that was added which broke compliance? What is
the benefit of the behaviour?
sys.path_importer_cache is now used to cache if a real directory
exists on the filesystem. Previously, a value of None for a given
sys.path entry told find_module that no
Hi,
On Thu, Jul 27, 2006 at 03:39:39AM -0400, Sylvain Fourmanoit wrote:
Having JSON there would indeed be nice: In fact, I recall being initially
surprised it was not supported by the standard library.
But is there a need to choose? Why not have both? The miniconf approach
has its
Hi Phillip,
On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote:
If we don't revert it, there are two ways to fix it. One is to just change
PEP 302 so that the behavior is unbroken by definition. :) The other is
to actually go ahead and fix it by adding PathImporter and
Armin Rigo wrote:
Hi Phillip,
On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote:
If we don't revert it, there are two ways to fix it. One is to just change
PEP 302 so that the behavior is unbroken by definition. :) The other is
to actually go ahead and fix it by adding
Hi David,
Your proposal is too vague to be useful. In Python I would not feel
that any compiler-enforced restrictions are going to be too restrictive,
and so I believe that your approach is not viable, but I cannot give you
many concrete examples of why before you come up with a more concrete
Bug #1526834: if you do 'b f(' in pdb, the debugger crashes. This bug
stems from pdb just sticking the string in a regex and compiling it.
cre = re.compile(r'def\s+%s\s*[(]' % funcname)
A side effect of this is that 'b f()' works to match the function 'f',
because the empty parens are legal
Hi Michael,
On Thu, Jul 27, 2006 at 12:46:04PM +0100, Michael Foord wrote:
leaves for a safe and cross-version dumper/loader for simple objects
using the Python syntax. In the same spirit, maybe it could be slightly
re-oriented towards a dumper/loader for more than config files; for
The UUID test suite, which wasn't run by regrtest.py until now, is
now failing on some buildbots (and my machine). This should be fixed
before releasing something.
Georg
___
Python-Dev mailing list
Python-Dev@python.org
At 12:52 PM 7/27/2006 +0200, Georg Brandl wrote:
Armin Rigo wrote:
Hi Phillip,
On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote:
If we don't revert it, there are two ways to fix it. One is to just
change
PEP 302 so that the behavior is unbroken by definition. :) The
Georg Brandl wrote:
The UUID test suite, which wasn't run by regrtest.py until now, is
now failing on some buildbots (and my machine). This should be fixed
before releasing something.
Okay, after fixing the test on my machine (locale issue) it looks like
some ifconfigs don't like to be called
Phillip J. Eby wrote:
sys.path_importer_cache is quite an internal thing
Whose behavior is documented in a PEP.
Correct.
and
most code, even import hooks, shouldn't have to deal with it.
That doesn't make it unimportant. It's a visible change in specified
behavior between Python
On Thu, Jul 27, 2006 at 05:40:57PM +0200, Georg Brandl wrote:
The UUID test suite, which wasn't run by regrtest.py until now, is
now failing on some buildbots (and my machine). This should be fixed
before releasing something.
Looking at the failures, there seem to be two problems on Unix
Armin Rigo wrote:
Hi David,
Your proposal is too vague to be useful. In Python I would not feel
that any compiler-enforced restrictions are going to be too restrictive,
and so I believe that your approach is not viable, but I cannot give you
many concrete examples of why before you come up
David Hopwood wrote:
The intention was not to require the restrictions to be compiler-enforced;
only to *allow* them to be compiler-enforced.
Code like this, for example:
def someMethod(self, x):
if self == x:
if self is x:, I meant.
foo(x._internal)
should not
On Jul 27, 2006, at 3:52 AM, Georg Brandl wrote:
Armin Rigo wrote:
Hi Phillip,
On Wed, Jul 26, 2006 at 02:40:27PM -0400, Phillip J. Eby wrote:
If we don't revert it, there are two ways to fix it. One is to
just change
PEP 302 so that the behavior is unbroken by definition. :) The
On Jul 27, 2006, at 6:20 PM, Georg Brandl wrote:
Georg Brandl wrote:
The UUID test suite, which wasn't run by regrtest.py until now, is
now failing on some buildbots (and my machine). This should be fixed
before releasing something.
Okay, after fixing the test on my machine (locale issue)
On 7/27/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Collin Winter wrote:
Is it intentional that Python 2.5 is (currently) shipping with
distutils 2.4.0, while Python 2.4 (at least 2.4.1, 2.4.2 and 2.4.3)
shipped with distutils 2.4.1? Judging from my own tests, distutils
2.4.1 fixed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since Anthony didn't speak up, I took his silence as assent and went
ahead and committed the changes. r50881 and r50885 for *nix and
Windows, just in case the deafening silence turns into a howl of
derision :).
- -Barry
-BEGIN PGP
[Martin v. Löwis]
Didn't you know that you signed in to run arbitrary viruses, worms, and
trojan horses when you added your machine to the buildbot infrastructure
:-?
Hey, I signed up for that when I bought a Windows box :-)
You just haven't seen buildbot erasing your hard disk and filling
David Hopwood wrote:
Inheritance should be defined as though the code of inherited methods and
attributes were copied into the subclass (with global accesses updated to
point to the original module).
You'll have to propose an implementation strategy for that
which works without actually
Greg Ewing wrote:
David Hopwood wrote:
Inheritance should be defined as though the code of inherited methods and
attributes were copied into the subclass (with global accesses updated to
point to the original module).
You'll have to propose an implementation strategy for that
which works
Richard Jones wrote:
On 27/07/2006, at 12:19 PM, David Hopwood wrote:
A restricted interpreter refuses access to any object attribute or
method with a name beginning with '_' (by throwing a new exception type
'InternalAccessException'), unless the access is from a method and its
Georg discovered that test_uuid didn't run any tests, and fixed that
on Thursday. A number of buildbots have failed that test since then.
My XP box appears unique among the Windows buildbots in failing. It
always fails like so:
AssertionError: different sources disagree on node:
from
[Tim]
... uuid.getnode() tries things in this order on Windows:
getters = [_windll_getnode, _netbios_getnode, _ipconfig_getnode]
It's only the first one that returns the bogus 0x00038a15; both of
the latter return 0x00B2B7BF [the correct MAC address for my
network card].
On 7/27/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Personally, I would prefer to see it properly fixed in 2.5 rather than
having to rip it out. It's more work for me to create the proper fix than
it is to just work around it in my code, but it seems a more righteous
labor, if you know what
At 09:49 PM 7/27/2006 -0700, Neal Norwitz wrote:
On 7/27/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Personally, I would prefer to see it properly fixed in 2.5 rather than
having to rip it out. It's more work for me to create the proper fix than
it is to just work around it in my code, but it
I suggest that there be a third beta release and that we then wait just
a bit before going final.
The bugs that were found and fixed in the first two beta releases
suggest that Py2.5 is not yet as stable as we would like. Over the next
few days, I'll try to run it on as much third-party code
Phillip J. Eby wrote:
I'm willing to write code that makes it PEP 302 compliant, if the release
manager will bless such an addition. But if that's not acceptable, then
somebody needs to produce the necessary documentation updates or revert the
patch. It absolutely should not be allowed to
On Friday 28 July 2006 15:32, Raymond Hettinger wrote:
I suggest that there be a third beta release and that we then wait
just a bit before going final.
The bugs that were found and fixed in the first two beta releases
suggest that Py2.5 is not yet as stable as we would like. Over the
next
34 matches
Mail list logo
