Mailman 3 May 2004 - Python-Dev

release23-maint tree closed for 2.3.4rc1
by Anthony Baxter 12 May '04

12 May '04

Unless you're involved in the 2.3.4 release process (so one of Anthony, Thomas, Fred or Jack(?)), please consider the release23-maint branch frozen until after Thursday the 20th of June. If you have something that you want to see on the branch before then, please email me first. Thanks, Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 1

Python 2.3.x doc tree closed
by Fred L. Drake, Jr. 12 May '04

12 May '04

I'm cutting the docs for Python 2.3.4; please make no changes on the the release23-maint branch. Thanks for everyone's help in getting this ready! -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

1 0

os.popen and exit codes on windows
by Mark Hammond 12 May '04

12 May '04

I'm looking at bug 602245 - http://www.python.org/sf/602245 - and would like some guidance. The issue is the return-code when closing the last handle from an os.popen() function. In a nutshell: On Linux, the result of closing the last handle is the result from the wait() function. On Windows, the result is the integer return code, exactly as specified by the child program - however, on Windows, when the result is -1, an error is raised (and hence the bug referenced above) On Linux, the value from the wait() system call is split into three parts: mask 0xff00 is the exit status mask 0x007f is the signal causing the exit mask 0x0080 is the cord dumped flag in combination with a signal As part of fixing the bug for Windows, I have 2 basic choices: 1) Fix it by masking off the high bits, thereby returning an "unsigned" result code - preventing -1, but still returning the result exactly as specified by the child process. 2) Fix it by changing the result to resemble the Linux behaviour. This would mean programs using popen() are more portable. My problem is that (2) will change the behaviour for existing programs. Most programs will only check for non-zero, but we can't know that for sure. One option is to do (1) for Python 2.3, and (2) for Python 2.4. That doesn't sound quite right either. If (2) is best, we could probably forget Python 2.3 all together, as the bug is quite old. Any thoughts? Comments directly in the bug are probably best. Thanks, Mark.

1 0

RE: [Python-Dev] Is core dump always a bug? Advice requested
by Robert Brewer 12 May '04

12 May '04

Greg: > As long as it's possible to attempt to execute arbitrary strings > as bytecode, I'd say ceval should be robust against this. > > But it appears ... that ceval has been full of gaping holes > from the beginning. Guido: > No, the holes aren't in ceval. The hole is the ability to create new > code objects from arbitrary arguments, which wasn't planned at all > when ceval was designed. I was always reluctant to add this > capability, but finally allowed it, consiciously opening up the hole, > under pressure from various people who wanted to do bytecode level > hacking. > > The responsibility to validate bytecode should really be in new.code() > (and probably in new.function, which requires the code to behave in > certain ways). My turn for the time machine :) I wrote: > Perhaps some more rigorous assertions, returning ValueErrors? > If not in C, then in the 'new' module, since that seems to be > the vector of disaster for Xaver, above. Perhaps this would also > be an argument for keeping the 'new' module around longer, > as a 'safer' Pythonic wrapper over bare code/function construction. A good starting point would be some simple boundary and type checking on arguments to new.code(). In this way, we could keep ceval fast and still get the 'safety' benefit. If you like, I can produce some assertions gleaned from my failures the last time I went bytecode hacking. ;) Robert Brewer MIS Amor Ministries fumanchu(a)amor.org

2 1

Re: Mozpython help
by Terry Reedy 12 May '04

12 May '04

The pydev list is for discussing the development of future versions of Python. Your usage questions would be better directed to comp.lang.py or, probably better, a mozpython specific group or list, assuming that there is one. tjr

1 0

Applying the PSF license to the config-py project
by Dan Gass 12 May '04

12 May '04

I've gotten negative feedback on my use of the GPL on this project, especially since I hope to get this module into the python core. I am going to make another release soon with some minor (backward compatible) improvements and would like to change the license to the PSF. I cannot find good definitive documentation on how to use this license in this situation. What text do I need to place or reference in my code? If someone could direct me to that documentation (if it exists) I would very much appreciate it. BTW, feedback on this project has been positive but slow. There have been 55 downloads in the 8 days it has been out there. http://config-py.sourceforge.net/. For better/worse I'm hoping to hear from the Zope/ZConfig guys :-) Thanks, Dan Gass _________________________________________________________________ Express yourself with the new version of MSN Messenger! Download today - it's FREE! http://messenger.msn.com/go/onm00200471ave/direct/01/

5 4

PEP 328 and __import__ contract
by Samuele Pedroni 12 May '04

12 May '04

PEP 328 seems at the moment to only describe the syntactic, surface and as-seen-by-the-user aspects of the new behavior for absolute/relative imports. What is going to happen to __import__ hook? At the moment relative imports as the default are implemented at that level, through get_parent and the first load_next in import_module_ex which is exported as __import__. Will imports still be implemented in terms of/on top of __import__. What will be the contract for __import__ then? I suppose it could be kept the same, relaxing over time the obligation to implement relative imports. At the moment a __import__ hook can be forced in absolute import mode by passing an empty globals dict. I think the PEP should cover some of this. regards.

1 0

Re: [Python-Dev] Is core dump always a bug? Advice requested
by Michel Pelletier 12 May '04

12 May '04

> Message: 6 > Date: Tue, 11 May 2004 07:12:00 -0700 > From: Guido van Rossum <guido(a)python.org> > Subject: Re: [Python-Dev] Is core dump always a bug? Advice requested > To: Greg Ewing <greg(a)cosc.canterbury.ac.nz> > Cc: python-dev(a)python.org > No, the holes aren't in ceval. The hole is the ability to create new > code objects from arbitrary arguments, which wasn't planned at all > when ceval was designed. I was always reluctant to add this > capability, but finally allowed it, consiciously opening up the hole, > under pressure from various people who wanted to do bytecode level > hacking. Please excuse me if I'm wrong, but wasn't the hole always there, you just made it wider? It seems it has always been possible to handcraft an evil .pyc file and cause its import, it's just more laborious than using the new module. > The responsibility to validate bytecode should really be in new.code() > (and probably in new.function, which requires the code to behave in > certain ways). This seems to only cover the part of the hole you widened, not the whole hole. For example, Java verifies bytecode when a .class file is loaded (See section 4.9 of the Java VM Specification). At this time it does quite a bit of verification, the spec is very interesting and could be a possible starting point for a Python bytecode verifier. It would seem a similar verification should happen any time the Python VM attempts to execute a code object for the first time, not just when the new module is used. > Note that while I like the general principle that Python code > shouldn't be able to cause segfaults, I don't think we should see that > property as a safety *guarantee*. It's more a code-of-honor of the > Python implementation. There are many violations of the principle, > mostly in platform-specific extensions (it is easy to crash Python > with certain win32 primitives, for example, and it seems unreasonable > to expect otherwise). While it's reasonable that C extensions can cause seg-faults, the problem to me seems to be the way in which bytecode can be used to exploit the interpreter without the involvement of extensions and not necessarily causing hard failures like seg faults. -Michel

1 0

RE: [Python-Dev] Python 2.3.4 schedule
by Geoffrey Talvola 11 May '04

11 May '04

Tino Lange wrote: > Is it possible to include the patch #945642 in 2.3.4? > > If not, this would mean that *no version Python of 2.3(.x)* was ever > able to handle nonblocking SSL socket connections properly (what the > former Python-Versions 2.x could). > > See: > https://sourceforge.net/tracker/?func=detail&atid=305470&aid=945642&group_id =5470 I'd like to see this in 2.3.4 too; since I was responsible for the breakage in the first place, it will help assuage my guilt to see this fix get in... - Geoff

4 3

Access to generator type
by James William Pye 11 May '04

11 May '04

Greetings, Can access to the generator type(gentype in ceval.c) and associated data/structures be made available in a public interface/header(genobject.h)? I know I can get the type by compiling a little generator and fetching its type, but that seems to be a bit redundant as each project that needs it, needs to make its own, nonstandardized version of access. Regards, James William Pye

2 1