Re: [Python-Dev] [Windows, buildbot] kill_python.c mystery
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 infrastructure
:-? You just haven't seen buildbot erasing your hard disk and filling
your coffee machine with tea, yet.
(strstr(path, build\\python.exe) != NULL)) {
Why is the second clause there?
That's for Cygwin (i.e. Anthony Baxter's machine). As Neal suggests,
preceding the executable path with another backslash should solve
this problem.
As a related note, this entire approach will also manage to kill
python.exe from an unrelated buildbot installation, e.g. a 2.4
build job might kill python.exe from the trunk. This actually helped
when I tried to get the Cygwin slave to get unstuck, and shouldn't
do harm since we currently don't run to builds on the same slave
simultaneously, but could be surprising when parallel builds
are activated some day.
Sorry for messing with your machine,
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] Which version of distutils to ship with Python 2.5?
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, not the bugs ; ). Are these bugs not fixed in the distutils that shipped with Python 2.5b2? In any case, I bumped the version number to 2.5, according to the policy discussed in http://mail.python.org/pipermail/distutils-sig/2005-January/004368.html Thanks for pointing this out. 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] Which version of distutils to ship with Python 2.5?
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 several bugs that some of my test suites depend on (the fixes, not the bugs ; ). Are these bugs not fixed in the distutils that shipped with Python 2.5b2? In any case, I bumped the version number to 2.5, according to the policy discussed in Could this not simply use the Python version number directly, instead? Separate version numbers only make sense if the package is separately distributed - and even then, something like Barry's setup for the email package could keep that version number out of the Python trunk. Fiddly little version numbers scattered throughout the standard library == pain. Anthony ___ 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] New miniconf module
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 the average case... Phillip, I was wrong to doubt you. ;-)
There is undoubtedly still room from improvement, but that's a good start.
But I agree this looks a lot like JSON, since ecmascript syntax for
literals looks a lot like the one of Python... For the same reasons there
is a need for JSON, I think having something like miniconf in the
standard lib would benefit the users.
Actually, I would see more reason to include JSON in the standard library,
since it's at least something approaching an internet protocol these days.
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 advantages and differences:
- The code is short and simple. Since all the real work is performed by
the Python parser, very little has to be done on top of that: it should be
easy to maintain, and will benefit of all the future work (patches, etc.)
that will be integrated to it in the future.
- The source it works on is valid Python source, which seems to be a plus
for a dynamic, reflexive language such as Python... Things such as this
will work:
from miniconf import dump
file('test.py','w').write(dump({'spam': 1}))
import test
I know this in not the best example, but you get the idea...
- Unlike JSON, miniconf is not introducing any new notation or syntax at
all: it uses a strict, well defined subset of the Python grammar that
every Python user is already familiar with; it is in no way a
data-interchange format, but it feels pretty natural in a all-python
environment... In that sense, it is well documented and standardized.
- Am I missing something, or is JSON not supporting comments inside the
parse tree? That's not really convenient for storage of configuration
information.
Anyway, if I had to choose between the two, I would definitively want
simplejson part of the standard library well before miniconf, since it can
be used in so many different situations, but I wouldn't
choose JSON as a configuration format given the choice to use the Python
notation employed by miniconf either.
Yours,
--
Sylvain [EMAIL PROTECTED]
Nobody said computers were going to be polite.
[1]http://cheeseshop.python.org/pypi?:action=displayname=miniconfversion=1.1.0
[2]http://sourceforge.net/tracker/index.php?func=detailaid=1527597group_id=5470atid=355470
___
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] Patch for building ctypes on more OpenBSD target platforms
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 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] Release manager pronouncement needed: PEP 302 Fix
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 import hook exist, so it should look for a filesystem directory. Now, the entry is set to True if that directory really exists and to False if it doesn't exist, thus saving quite a few open() calls to files in these not existing dirs. From your description of fixing the problem, it seems there's some risk invovled as it's modiyfing import.c, plus adding new features. What is your recommendation? I would prefer fixing the docs. Importing from filesystem directories is common enough to be special cased. 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] New miniconf module
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 advantages and differences: I support this point of view: miniconf fills the hole that the stdlib 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 example, it could provide a safe inverse of repr() for common built-in types. Such a functionality has been discussed here a few times if I remember correctly, but the code in miniconf is very close to providing it. A bientot, Armin ___ 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] Release manager pronouncement needed: PEP 302 Fix
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 NullImporter types to import.c, along with a factory function on sys.path_hooks to create them. (This would've been the PEP-compliant way to implement the need-for-speed patch.) So, fix by documentation, fix by fixing, or fix by reverting? Which should it be? fix by changing the definition looks like a bad idea to me. The import logic is already extremely complicated and delicate, any change to it is bound to break *some* code somewhere. So although import.c is already by far the longest piece of code around, I think that we need a patch doing the right thing, or else revert. A bientot, Armin ___ 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] Release manager pronouncement needed: PEP 302 Fix
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 PathImporter and NullImporter types to import.c, along with a factory function on sys.path_hooks to create them. (This would've been the PEP-compliant way to implement the need-for-speed patch.) So, fix by documentation, fix by fixing, or fix by reverting? Which should it be? fix by changing the definition looks like a bad idea to me. The import logic is already extremely complicated and delicate, any change to it is bound to break *some* code somewhere. Though beta1 and beta2 shipped with this change nobody reported any bug that could be linked to it. sys.path_importer_cache is quite an internal thing and most code, even import hooks, shouldn't have to deal with it. 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] Internal namespace proposal
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 specification. More importantly, this is going to depend critically on a restricted interpreter in the first place, in the sense of Brett, but the safety of your proposal depends on the restricted interpreter forbidding many operations that it would not otherwise forbid for its original goal. For example, in Brett's use case there is no need to prevent reading the 'func_globals' attribute of function objects, but if that's allowed, then accessing any _attribute of any module is easy. About special methods: how do built-in functions like str(), int(), and so on, know in which context they are called? Surely you don't propose that '2+3' should be invalid because it accesses the hidden attribute '2 .__add__' ? How would you formulate a rule in term on Python's attribute look-up algorithm to prevent the following trivial attack? : x.py: # supposedly secure? _hidden = [1,2,3] class A: def __init__(self): self._authorized = ... def read(self): if not self._authorized: raise Forbidden return _hidden attack.py: import x class B(x.A): def __init__(self): self._authorized = True b = B() print b.read() # = [1,2,3] On any real-life example I'm sure that hacks like overriding selected methods on the instance itself would allow an attacker to confuse the remaining methods enough to leak hidden information. Here is a metaclass attack against the rule self._attr is only allowed if syntactically inside the class definition of the exact class of self: class SupposedlySecure(object): _hidden = [1,2,3] class MetaAttack(type): def read(self): return self._hidden # seen as an instance attribute class Attack(SupposedlySecure): __metaclass__ = MetaAttack print Attack.read() A bientot, Armin. ___ 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] Release manager: pdb bugfix incompatibility
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 regex syntax declaring an empty
group that matches the null string.
It's easy to fix the crash by doing re.escape(funcname). But this
means that 'b f()' will no longer find the function 'f' -- it will
look for 'f(' followed by another paren, and won't find it.
Should this be fixed by the re.escape(), or should the fix attempt to
keep 'b f()' working? The pdb documentation doesn't claim that 'b
f()' should work.
--amk
___
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] New miniconf module
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 example, it could provide a safe inverse of repr() for common built-in types. Such a functionality has been discussed here a few times if I remember correctly, but the code in miniconf is very close to providing it. ConfigObj [1] gained an 'unrepr' mode a while back. The code is simple, and originally came from CherryPy. I'm sure, but my point was that the discussed miniconf already contains mostly the same code already, so I suggested that it would be a worthwhile addition to it, in its stdlib-hole-filler role. If it goes in that direction, I'd suggest to rename the module to give it a name closer to existing persistence-related modules already in the stdlib. Armin ___ 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] uuid test suite failing
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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Release manager pronouncement needed: PEP 302 Fix
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 other is to actually go ahead and fix it by adding PathImporter and NullImporter types to import.c, along with a factory function on sys.path_hooks to create them. (This would've been the PEP-compliant way to implement the need-for-speed patch.) So, fix by documentation, fix by fixing, or fix by reverting? Which should it be? fix by changing the definition looks like a bad idea to me. The import logic is already extremely complicated and delicate, any change to it is bound to break *some* code somewhere. Though beta1 and beta2 shipped with this change nobody reported any bug that could be linked to it. Because in at least setuptools' case, you have to be using unzipped namespace packages under the right set of circumstances to trigger a propblem. sys.path_importer_cache is quite an internal thing Whose behavior is documented in a PEP. 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 versions -- precisely the sort of thing that makes people mad at us renegade cowboy Python-dev hackers changing their language for no apparent reason. The strftime thing that recently got hashed to death here was also an internal thing which most code shouldn't have to deal with. This is precisely how these kinds of problems happen. So, this needs to either be documented in the What's New document and PEP 302 at a minimum, or it needs to be reverted, unless somebody wants to bless the feature addition to fix it. 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 remain in *and* undocumented because it is a backwards-incompatible change to documented behavior of Python for two major releases (2.3 and 2.4). ___ 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] uuid test suite failing
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 without arguments. -a seems to be supported everywhere though, so I guess it's reasonable to use that flag on every platform. Any objections? 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] Release manager pronouncement needed: PEP 302 Fix
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 versions -- precisely the sort of thing that makes people mad at us renegade cowboy Python-dev hackers changing their language for no apparent reason. The strftime thing that recently got hashed to death here was also an internal thing which most code shouldn't have to deal with. This is precisely how these kinds of problems happen. So, this needs to either be documented in the What's New document and PEP 302 at a minimum, or it needs to be reverted, unless somebody wants to bless the feature addition to fix it. I agree with you (now). ;) 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. A possible third option would be to store the information this is an invalid path somewhere else, that is, an internal dictionary only available to import.c. I will write up docs and update the PEP in any case, if the release manager agrees. 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] uuid test suite failing
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 variants: 1) on some, '/sbin/ifconfig' prints a help message; you need 'ifconfig -a' to print information about all interfaces. 2) on Solaris 9 (the only version in the SF compile farm), I can't figure out how to make ifconfig print MAC addresses at all. Searching online finds the incantation 'arp hostname' to print the MAC. The XP build fails because it seems to be getting different node IDs from different calls. The cygwin build is very unhappy, for reasons that don't look connected to the newly-enabled tests. --amk ___ 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] Internal namespace proposal
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 with a more concrete specification. 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: foo(x._internal) should not have to work. More importantly, this is going to depend critically on a restricted interpreter in the first place, in the sense of Brett, but the safety of your proposal depends on the restricted interpreter forbidding many operations that it would not otherwise forbid for its original goal. For example, in Brett's use case there is no need to prevent reading the 'func_globals' attribute of function objects, but if that's allowed, then accessing any _attribute of any module is easy. I disagree that there is no need to prevent reading func_globals. func_globals is clearly incompatible with capability security (as are func_dict and func_closure; also the other function attributes should be read-only). Functions in a capability language should be opaque. I don't see that there is any problem with the proposal depending on a restricted interpreter to prevent access via loopholes such as func_globals, since that is the main intended context of its use. Remember that Brett's document stated that protection could only be obtained at interpreter granularity, rather than object granularity, primarily because objects have no way to prevent access to their private state. My intention in describing the basic idea of enforcing the PEP 8 convention for internal attributes/methods, was to get precisely this kind of feedback on potential problems. I have already obtained useful feedback (including yours), and will prepare a more concrete proposal based on it. About special methods: how do built-in functions like str(), int(), and so on, know in which context they are called? Surely you don't propose that '2+3' should be invalid because it accesses the hidden attribute '2 .__add__' ? This and other examples have convinced me that names starting and ending with double underscores should not automatically be considered internal. There are a few such names that should be internal (e.g. __dict__), but it is reasonable to treat those as special cases. How would you formulate a rule in term on Python's attribute look-up algorithm to prevent the following trivial attack? : x.py: # supposedly secure? _hidden = [1,2,3] class A: def __init__(self): self._authorized = ... def read(self): if not self._authorized: raise Forbidden return _hidden attack.py: import x class B(x.A): def __init__(self): self._authorized = True b = B() print b.read() # = [1,2,3] 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). IOW, B acts as though it is defined like this: attack.py: class B(x.A): def __init__(self): self._authorized = True def read(self): if not self._authorized: raise Forbidden return x._hidden Since x._hidden is not accessible from attack.py, the attack fails. On any real-life example I'm sure that hacks like overriding selected methods on the instance itself would allow an attacker to confuse the remaining methods enough to leak hidden information. Yes, Java was subject to many attacks of this type. However, a code-copying semantics for inheritance prevents all of them, by ensuring that a class cannot do anything by inheritance that it could not do without it. Here is a metaclass attack against the rule self._attr is only allowed if syntactically inside the class definition of the exact class of self: class SupposedlySecure(object): _hidden = [1,2,3] class MetaAttack(type): def read(self): return self._hidden # seen as an instance attribute class Attack(SupposedlySecure): __metaclass__ = MetaAttack print Attack.read() Metaclasses are a reflective feature; almost all such features would have to be limited in restricted interpreters. -- David Hopwood [EMAIL PROTECTED] ___ 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] Internal namespace proposal
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 have to work. -- David Hopwood [EMAIL PROTECTED] ___ 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] Release manager pronouncement needed: PEP 302 Fix
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 other is to actually go ahead and fix it by adding PathImporter and NullImporter types to import.c, along with a factory function on sys.path_hooks to create them. (This would've been the PEP-compliant way to implement the need-for-speed patch.) So, fix by documentation, fix by fixing, or fix by reverting? Which should it be? fix by changing the definition looks like a bad idea to me. The import logic is already extremely complicated and delicate, any change to it is bound to break *some* code somewhere. Though beta1 and beta2 shipped with this change nobody reported any bug that could be linked to it. sys.path_importer_cache is quite an internal thing and most code, even import hooks, shouldn't have to deal with it. Anyone trying to emulate what imp.find_module does in a PEP 302 compliant way will need to introspect sys.path_importer_cache. I have some unreleased code based on the PEP 302 spec that does this and the way it was originally written would have broke in 2.5 if I had tested it there. Just because it's obscure doesn't mean we should go change how things work in a way that's not consistent with the documentation. The documentation should change to match the code or vice versa, though I really don't have any strong feelings one way or the other. -bob ___ 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] uuid test suite failing
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) it looks like some ifconfigs don't like to be called without arguments. -a seems to be supported everywhere though, so I guess it's reasonable to use that flag on every platform. Any objections? IIRC at least some versions of HP-UX do not support the -a flag for ifconfig, I'll check this tomorrow. Ronald ___ 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] Which version of distutils to ship with Python 2.5?
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 several bugs that some of my test suites depend on (the fixes, not the bugs ; ). Are these bugs not fixed in the distutils that shipped with Python 2.5b2? I now believe this to be a new regression that I had confused with an earlier bug report. I've filed a new report, http://python.org/sf/1529871. I'd appreciate it if anyone could shed some light on this. Thanks, Collin Winter ___ 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] Support for PyGetSetDefs in pydoc
-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 SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRMlSV3EjvBPtnXfVAQL3WQP9H2RBIDG3FCEkzHjzmwyRWl4HU467yWMQ bse0/XhUEAQHivwP2nLvAqn+Qrb8XaXIT3n5i9++saMFtxjTdfMJX2ZNBK+0JmVl N+XvhTIXIu9XJy47c4FsZ6tbfHVSKQ3KRaE81sfMYuKQsPCnB9cNskKEJEpaS0Cy F7GmpdE96sM= =T3Ia -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] [Windows, buildbot] kill_python.c mystery
[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
your coffee machine with tea, yet.
Not the buildbot, no, but visiting random web pages does that routinely.
(strstr(path, build\\python.exe) != NULL)) {
Why is the second clause there?
That's for Cygwin (i.e. Anthony Baxter's machine). As Neal suggests,
preceding the executable path with another backslash should solve
this problem.
And he checked that in, and I haven't noticed another similar problem
since (but then it was rare to begin with).
As a related note, this entire approach will also manage to kill
python.exe from an unrelated buildbot installation, e.g. a 2.4
build job might kill python.exe from the trunk. This actually helped
when I tried to get the Cygwin slave to get unstuck, and shouldn't
do harm since we currently don't run to builds on the same slave
simultaneously, but could be surprising when parallel builds
are activated some day.
I don't think we /can/ yet -- I believe some tests T exist that
implicitly assume only one instance of T is running. I don't recall
details, although I'm sure we'll bump into them sporadically the
instant parallel builds are enabled. As a purely pragmatic matter, I
expect my hard drive would quickly be reduced to dust if two instances
of test_largefile ran simultaneously (Windows XP writes physical
zeroes in the entire multi-GB file, and that takes finite time only if
the disk head doesn't have to keep seeking).
Sorry for messing with your machine,
No problem! That's what it's here for :-)
___
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] Internal namespace proposal
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 copying all the code, though. Since x._hidden is not accessible from attack.py, the attack fails. But if _hidden were an attribute of the A instance that you were trying to protect, it would succeed. So you can't actually protect any direct attribute of a class that can be subclassed. Which means we're back to the situation of having to prevent access to class objects. -- 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] Internal namespace proposal
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 without actually copying all the code, though. The only difference between the copying semantics and the current semantics, is in the visibility of module-global internal variables and functions. It's sufficient to keep track of whether each class could access a variable or function that is internal to its module. If it does, then it cannot be subclassed from a different module. (It must not be possible to access internal variables/ functions reflectively.) The effect of this is that if a programmer intends a class to be subclassable from outside the module, they must make sure that all of the variables/functions it depends on are public. Anyone performing a security review of the module then does not have to consider inheritance from a different module when deciding which variables/functions might be accessible. There is a slightly more flexible version of this approach that is just as secure, provided that functions are restricted to be stateless. If it is possible to prove statically that a class does not access any internal *variables* of a module (regardless of whether it accesses internal functions), then it is safe to allow the class to be subclassed from another module. This is because the subclassing module could have copied all of the code of the original module (assuming it is written purely in Python); the only possible sources of authority in a capability language are from access to variables or primitives, not code. If a class is not written in Python, then we cannot analyse whether it accesses internal variables. In that case the class will be part of the TCB, and we have to trust the class writer to mark whether it can be safely subclassed from another module. Since x._hidden is not accessible from attack.py, the attack fails. But if _hidden were an attribute of the A instance that you were trying to protect, it would succeed. No, attack.py could only access a _hidden attribute in an instance of B. This is harmless, because it could just as well define the _hidden attribute of B itself, rather than by subclassing. -- David Hopwood [EMAIL PROTECTED] ___ 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] Internal namespace proposal
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 static target is that method's first argument variable. Also, a restricted interpreter refuses access to any module-global variable or module-global function with a name beginning with '_' (by throwing 'InternalAccessException'), unless the access is statically from the same module. Note that this is a rule that Zope enforces in its restricted environment. Is that documented anywhere? -- David Hopwood [EMAIL PROTECTED] ___ 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] how about adding ping's uuid module to the standard lib ?
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 source 'getnode1', node was 00038a15 from source 'getnode2', node was 00038a15 from source 'ipconfig', node was 00b2b7bf 0x00038a15 /is/ the last 6 bytes returned by the Windows UuidCreateSequential() on my box. I confirmed that by writing a C program calling it directly. However, it doesn't appear to correspond to any MAC address of any HW on my box. All documented ways of determining the MAC address of my Ethernet card (using UuidCreateSequential for this appears to be folklore rather than documented behavior) agree that 0x00b2b7bf is correct on this box; e.g., $ getmac /fo list /v Connection Name: Local Area Connection Network Adapter: Marvell Yukon 88E8050 PCI-E ASF Gigabit Ethernet Controller Physical Address: 00-11-11-B2-B7-BF Transport Name: \Device\Tcpip_... Connection Name: 1394 Connection Network Adapter: 1394 Net Adapter Physical Address: 62-A1-AC-6C-FD-BE Transport Name: \Device\Tcpip_... Connection Name: 1394 Connection 2 Network Adapter: 1394 Net Adapter Physical Address: E2-1F-01-C6-5D-88 Transport Name: \Device\Tcpip_... The last two are for firewire interfaces, and don't match the purported MAC address extracted from UuidCreateSequential's output anyway. So, at least on my box, this comment in uuid.py is incorrect (UuidCreateSequential does not behave as it says): # On Windows prior to 2000, UuidCreate gives a UUID containing the # hardware address. On Windows 2000 and later, UuidCreate makes a # random UUID and UuidCreateSequential gives a UUID containing the # hardware address. ... Unfortunately, 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. However, there's nothing I can do to that list to make test_uuid pass on this box. It wants to insist that all three ways of getting/guessing the MAC address return the same thing, and that's never going to happen here. Given that _windll_getnode's actual behavior appears to have nothing in common with what was expected for it here, best suggestion I can make is to throw its code away. ___ 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] how about adding ping's uuid module to the standard lib ?
[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]. That was on my desktop XP Pro SP2 box. On my similar laptop box, it's quite different: _windll_getnode and _ipconfig_getnode return the MAC address of my wireless Ethernet adapter, while _netbios_getnode returns the MAC address of my LAN Ethernet card. However, there's nothing I can do to that list to make test_uuid pass on this box. It wants to insist that all three ways of getting/guessing the MAC address return the same thing, and that's never going to happen here. Or on my laptop, but for different reasons there. Given that _windll_getnode's actual behavior appears to have nothing in common with what was expected for it here, best suggestion I can make is to throw its code away. Which wouldn't improve things on my laptop. Best next ;-) suggestion is to change test_uuid to stop believing that uuid.py knows multiple ways to find a well-defined MAC address. I'm going to make that change -- someone who hates that can revert it after they buy me two new computers that work they way they think computers should work ;-) ___ 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] Release manager pronouncement needed: PEP 302 Fix
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 I mean. It also means that already-shipped and distributed versions of my code would work with the 2.5 release. Based on this comment, is it really acceptable to just document a behaviour change? ISTM there should really only be 2 choices: fix 2.5 properly or revert the change. This seemed to be Armin's position. n ___ 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] Release manager pronouncement needed: PEP 302 Fix
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 seems a more righteous labor, if you know what I mean. It also means that already-shipped and distributed versions of my code would work with the 2.5 release. Based on this comment, is it really acceptable to just document a behaviour change? ISTM there should really only be 2 choices: fix 2.5 properly or revert the change. This seemed to be Armin's position. Well, it's a moot question since nobody has volunteered to update the docs. Fixing it and reverting it are the only options unless somebody steps up to do the doc work. I'll happily fix it or revert it, just tell me which one is the approved course of action and I'll get started. :) ___ 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] Py2.5 release schedule
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 as possible. That would have detected the recently surfaced grammar error a little bit earlier (the one where for x, in listOfTuples would not unpack). The release process itself is going well but I don't think the pervasive AST changes have been fully shaken-out yet. 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] Release manager pronouncement needed: PEP 302 Fix
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 remain in *and* undocumented because it is a backwards-incompatible change to documented behavior of Python for two major releases (2.3 and 2.4). You don't need a release manager pronouncement for that. It's a bug, changing it is a bug fix, you don't need RM permission to fix a bug. Do you have a patch ready that restores path_importer_cache behavior, yet preserves the property that it caches existence of a directory? If not, I will have to produce one. 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] Py2.5 release schedule
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 few days, I'll try to run it on as much third-party code as possible. That would have detected the recently surfaced grammar error a little bit earlier (the one where for x, in listOfTuples would not unpack). The release process itself is going well but I don't think the pervasive AST changes have been fully shaken-out yet. I've been thinking the same thing, too. A quick chat to Neal says that he also agrees. There's still a lot more bugs popping up than I'm really comfortable with. I guess this is inevitable - there's a lot of new stuff in 2.5. Does anyone disagree with making the next release beta3? Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
