Re: [Python-Dev] Making staticmethod objects callable?
On 3/15/06, Nicolas Fleury <[EMAIL PROTECTED]> wrote: > I think we all agree on this list that there's no point using a > staticmethod for that use case. My suggestion was for some > comp.lang.python people, a lot coming from other languages. Their > reflex would be much more to define a staticmethod. This issue has been > pointed a lot of times on comp.lang.python. There's no need to change Python so that people coming from other languages won't make silly mistakes, is there? BTW I question the claimed reflex -- assuming by "other languages" you mean Java or C++ (the only languages I know that *have* static methods) -- since those languages don't have the ability to call methods (static or otherwise) at class definition time. So perhaps you need to dig deeper to find out *why* this is a recurring issue. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Making staticmethod objects callable?
Armin Rigo wrote: > Hi Nicolas, > > On Thu, Mar 02, 2006 at 01:55:03AM -0500, Nicolas Fleury wrote: >> (...) A use case is not hard to >> imagine, especially a private static method called only to build a class >> attribute. > > Uh. I do this all the time, and the answer is simply: don't make that a > staticmethod. Staticmethods are for the rare case where you need > dynamic class-based dispatch but don't have an instance around. I think we all agree on this list that there's no point using a staticmethod for that use case. My suggestion was for some comp.lang.python people, a lot coming from other languages. Their reflex would be much more to define a staticmethod. This issue has been pointed a lot of times on comp.lang.python. Regards, Nicolas ___ 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] Py3k: Except clause syntax
On 3/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > For Py3k, any thoughts on changing the syntax of > the except clause from > >except , : > > to > >except as : > > so that things like > >except TypeError, ValueError: > > will do what is expected? Not a bad idea. The trend seems to be that each use of 'as' is some kind of assignment to the name after 'as' but the relationship with the thing before 'as' is different in each case. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] open() mode is lax
[Greg Ewing]
> I've just noticed that (in 2.3.4) open() seems to accept
> just about anything after the first character of the
> mode argument:
>
> Python 2.3.4 (#1, Jun 30 2004, 16:47:37)
> [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> f = open("DU", "rqwerty")
> >>>
Yes. That's because virtually all C libraries accept just about
anything in the mode string, so that code using mode-string extensions
specific to other platforms doesn't just blow up. Python passes the
mode string on to the platform C, and complains if and only if the
platform C complains.
___
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] open() mode is lax
I've just noticed that (in 2.3.4) open() seems to accept
just about anything after the first character of the
mode argument:
Python 2.3.4 (#1, Jun 30 2004, 16:47:37)
[GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open("DU", "rqwerty")
>>>
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand | (I'm not a morning person.) |
[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
[Python-Dev] Py3k: Except clause syntax
For Py3k, any thoughts on changing the syntax of the except clause from except , : to except as : so that things like except TypeError, ValueError: will do what is expected? 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] Still looking for volunteer to run Windows buildbot
[Martin v. Löwis] > So PythonWin needs to be installed on a Windows buildbot slave, right? It must, since that's what my wiki page says ;-): http://wiki.python.org/moin/BuildbotOnWindows ... o Install a matching version of pywin32. ... ___ 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] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
Thomas Heller wrote: > BTW: Is a "porting guide" to make extension modules compatible with 2.5 > available somewhere? PEP 353 scratches only the surface... Wrt. ssize_t changes, PEP 353 is meant to be comprehensive. Which particular aspect are you missing? 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] Another threading idea
Raymond Hettinger wrote: > FWIW, I've been working on a way to simplify the use of queues with daemon > consumer threads > > Sometimes, I launch one or more consumer threads that wait for a task to > enter a > queue and then work on the task. A recurring problem is that I sometimes need > to > know if all of the tasks have been completed so I can exit or do something > with > the result. > > If each thread only does a single task, I can use t.join() to wait until the > task is done. However, if the thread stays alive and waits for more Queue > entries, then there doesn't seem to be a good way to tell when all the > processing is done. The pattern I use is to use the None object to indicate that no more tasks are coming - just add it to your queue once for every worker thread that exists and have your worker threads exit when they get a task of None. Your setup code to start the threads and add tasks to the queue wouldn't need to change; once all the tasks have been enqueued you'd wait for completion like this: # Tell all the workers to quit for t in worker_threads(): q.put(None) # Wait for all the workers to quit for t in worker_threads(): t.join() do_work_on_results() The worker thread looks like this: while 1: task = q.get() if task is None: break do_work(task) -Dave ___ 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] [Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py
Done. Index: pep-0008.txt === --- pep-0008.txt(revision 42952) +++ pep-0008.txt(working copy) @@ -156,8 +156,9 @@ - Relative imports for intra-package imports are highly discouraged. Always use the absolute package path for all imports. - (However, once PEP 328 [7] is fully implemented, its style of - explicit relative imports will be recommended.) + Even now that PEP 328 [7] is fully implemented in Python 2.5, + its style of explicit relative imports is actively discouraged; + absolute imports are more portable and usually more readable. - When importing a class from a class-containing module, it's usually okay to spell this On 3/15/06, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Wed, 2006-03-15 at 17:33 -0500, Jeremy Hylton wrote: > > On 3/15/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > Well, absolute imports without the future statement will not use the > > > 5th argument, so they won't break, right? That's what MAL also says. > > > Someone please fix this. > > > > I'd much rather see us change imports to use absolute imports than to > > use relative imports in count-the-dots fashion. Could we add that to > > PEP 8? > > +1 > -Barry > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2.2 (GNU/Linux) > > iQCVAwUARBiYFXEjvBPtnXfVAQJPzQP/aOcipFhTU+Z6SYB7aeIwOIl+TcUObHzo > xdp3ufscF1R4emX7vgw/BChJfCwt6vcOzKQsyjVgAFYnDuh6XdRdtL3gjex/Z2L0 > OLBKMhOjd3OScyhypefruhXJJ8o1SvQn4eQeGacIsYaqbohs3OEEqv3RW5o1h3Qo > azV3CQn+2Fs= > =qcFp > -END PGP SIGNATURE- > > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] [Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py
On Wed, 2006-03-15 at 17:33 -0500, Jeremy Hylton wrote: > On 3/15/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Well, absolute imports without the future statement will not use the > > 5th argument, so they won't break, right? That's what MAL also says. > > Someone please fix this. > > I'd much rather see us change imports to use absolute imports than to > use relative imports in count-the-dots fashion. Could we add that to > PEP 8? +1 -Barry signature.asc Description: This is a digitally signed message part ___ 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] [Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py
On 3/15/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Well, absolute imports without the future statement will not use the > 5th argument, so they won't break, right? That's what MAL also says. > Someone please fix this. I'd much rather see us change imports to use absolute imports than to use relative imports in count-the-dots fashion. Could we add that to PEP 8? Jeremy > > On 3/15/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > > > > > On 3/15/06, guido.van.rossum <[EMAIL PROTECTED]> wrote: > > > > > > Use relative imports in a few places where I noticed the need. > > > (Ideally, all packages in Python 2.5 will use the relative import > > > syntax for all their relative import needs.) > > > > > > You should be aware that using relative imports (or absolute imports) in the > > standard library may cause custom __import__'s that don't take the optional > > fifth argument to break, whereas using 'old-style' imports does not. I don't > > know how common custom __import__ hooks are, and adding the optional fifth > > argument is backwardly compatible, but I would personally not add absolute > > or relative imports to the oft-used parts of the stdlib until after 2.5. > > > > On the other hand, code using sys.path_hooks (like zipimport) don't need any > > tweaking, as the absolute/relative choice is made before they are queried, > > so I don't know howmuch impact this has, all in all. > > > > -- > > Thomas Wouters <[EMAIL PROTECTED]> > > > > Hi! I'm a .signature virus! copy me into your .signature file to help me > > spread! > > ___ > > 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/guido%40python.org > > > > > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > 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/jeremy%40alum.mit.edu > ___ 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] [Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py
On 3/15/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > Ah, so it's *relative* imports that require a 5th argument. I was thinking > it was there to support absolute imports. I was thinking that relative > imports could be implemented by popping bits off of __name__ to get an > absolute location. Well, also absolute imports when the future statement is in effect -- __import__ needs to know whether to interpret "import foo" as "first try __path__, then sys.path" or as "only look in sys.path". > It seems to me that backward compatibility would be greatly enhanced by > having the interpreter convert everything but "legacy" imports into > absolute imports, as this would then work with the existing __import__ code > in the field, even when new relative/absolute code was doing the > importing. Otherwise, this forces __import__ hooks to be rewritten. (I > personally avoid writing __import__ hooks if at all possible, but there are > certainly some out there.) How would the conversion be done? The compiler can't tell whether a classic "import foo" is intended to be a relative or absolute import. > The mechanism I have in mind would be to just have an IMPORT_EXACT opcode > that takes a relative or absolute name. This opcode would process relative > names relative to the __name__ in globals to produce an exact module name, > and leave absolute names alone. It would then invoke __import__ using the > builtins or sys module dictionary as the "globals" argument *instead of the > current globals*, so that __import__ will not do any legacy-style fallback. Yes, but it would defeat the purpose of import hooks -- import hooks need to be able to assign their own semantics. (Long, long ago, there was no built-in support for packages, but you could install an import hook that enabled it.) > When absolute imports are in effect, or when an explicit relative import is > used, it would be compiled such that IMPORT_NAME is replaced by IMPORT_EXACT. > > This mechanism doesn't require any change to the __import__() signature, > and so remains backward compatible with any existing import hook that > doesn't do weird things to the globals dictionary of the module that > invoked it. > > On the other hand, perhaps it would be better to fail loudly by breaking on > the 5th argument, than to fail silently for really weird __import__ > hooks. That is, if it breaks, it will force people to make sure their > __import__ code is safe for use with absolute imports. So, the existing > approach might well be better than what I had in mind. I think so. Import hooks requires a lot of careful work. Requiring import hooks to be explicitly ported probably provides better guarantees that they actually work. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] [Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py
At 01:34 PM 3/15/2006 -0800, Guido van Rossum wrote: >Because Thomas designed it this way. :-) > >I believe his design makes sense though: "import foo" translates to >__import__(foo, ...). > >There's a separate setting, only known to the compiler, that says >whether "from __future__ import absolute_import" is in effect (there's >no way to slip a flag into globals to convey this setting, since code >is compiled independently from globals, and there are ways to pass >flags to the compiler without explicitly doing the future import). > >So the compiler emits different code when the future syntax is in >effect, and that opcode must pass its knowledge to __import__. This is >done trough the 5th argument, which also tells us how many leading >dots there were. Without the future import, the 5th argument is >omitted (as long as there aren't any leading dots). Ah, so it's *relative* imports that require a 5th argument. I was thinking it was there to support absolute imports. I was thinking that relative imports could be implemented by popping bits off of __name__ to get an absolute location. It seems to me that backward compatibility would be greatly enhanced by having the interpreter convert everything but "legacy" imports into absolute imports, as this would then work with the existing __import__ code in the field, even when new relative/absolute code was doing the importing. Otherwise, this forces __import__ hooks to be rewritten. (I personally avoid writing __import__ hooks if at all possible, but there are certainly some out there.) The mechanism I have in mind would be to just have an IMPORT_EXACT opcode that takes a relative or absolute name. This opcode would process relative names relative to the __name__ in globals to produce an exact module name, and leave absolute names alone. It would then invoke __import__ using the builtins or sys module dictionary as the "globals" argument *instead of the current globals*, so that __import__ will not do any legacy-style fallback. When absolute imports are in effect, or when an explicit relative import is used, it would be compiled such that IMPORT_NAME is replaced by IMPORT_EXACT. This mechanism doesn't require any change to the __import__() signature, and so remains backward compatible with any existing import hook that doesn't do weird things to the globals dictionary of the module that invoked it. On the other hand, perhaps it would be better to fail loudly by breaking on the 5th argument, than to fail silently for really weird __import__ hooks. That is, if it breaks, it will force people to make sure their __import__ code is safe for use with absolute imports. So, the existing approach might well be better than what I had in mind. ___ 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] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
Tim Peters wrote: > [Martin] >> ... >> I believe it does: the ctypes maintainer wants to keep the >> code identical across releases (AFAICT). Correct, that's why I listed it in PEP 291. > Fair enough -- I reverted the checkin. It's going to need #if'ery on > the Python version, though, if it wants to match a > Python-version-dependent data width with an appropriate format code. You could have left it in, I'm very thankful for any help that I get. Making the patch version independent is my job - unless someone else takes care of it, of course. BTW: Is a "porting guide" to make extension modules compatible with 2.5 available somewhere? PEP 353 scratches only the surface... 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] [Python-checkins] r43028 - python/trunk/Modules/_ctypes/cfield.c
On 3/15/06, Tim Peters <[EMAIL PROTECTED]> wrote: > > [Neal Norwitz] > > This isn't exactly correct. On a 64-bit system, the value will be > > cast into a 32-bit integer. This is true for both Win64 and Unix. If > > you change the cast to a long and use %ld (lowercase ell), that will > > work correctly on Unix, but not Win64. To always display the correct > > value on all platforms, you need an #ifdef MS_WIN64. For Windows, you > > use %Id (that's a capital letter eye) and reference the value without > > a cast. For Unix, you use %ld (lowercase ell), and cast the value to > > a (long) to avoid a warning. > > I'm copying this to python-dev because it's important people > understand this :-): all of the above is kinda true but irrelevant. Whoops, my comment only applies to *printf(), not PyString's as you correctly point out. For an example, see the definition for PRINT_TOTAL_REFS() in http://svn.python.org/view/python/trunk/Python/pythonrun.c?rev=42876&view=markup n -- > Martin already checked in a patch so that PyString_FromFormat() > understands the C99 "z" qualifier on _all_ platforms. So the correct > way to repair this one wasn't to add a cast, and much less to add an > #ifdef, it was to change > > ofs=%d > > to > > ofs=%zd > > in the format. I'm going to check that change in now, but don't make > me do it again :-) > ___ > 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/nnorwitz%40gmail.com > ___ 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] [Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py
Because Thomas designed it this way. :-) I believe his design makes sense though: "import foo" translates to __import__(foo, ...). There's a separate setting, only known to the compiler, that says whether "from __future__ import absolute_import" is in effect (there's no way to slip a flag into globals to convey this setting, since code is compiled independently from globals, and there are ways to pass flags to the compiler without explicitly doing the future import). So the compiler emits different code when the future syntax is in effect, and that opcode must pass its knowledge to __import__. This is done trough the 5th argument, which also tells us how many leading dots there were. Without the future import, the 5th argument is omitted (as long as there aren't any leading dots). --Guido On 3/15/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 10:33 AM 3/15/2006 -0800, Guido van Rossum wrote: > >Well, absolute imports without the future statement will not use the > >5th argument, so they won't break, right? That's what MAL also says. > >Someone please fix this. > > Why is a 5th argument needed to do absolute imports? Shouldn't it suffice > to supply a globals argument with no __path__ and an undotted > __name__? ISTM that passing in the builtins dictionary as the globals > argument ought to do the trick. > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Coverity report
Attached is an image from a coverity report for ctypes.
Here is the text:
3866val = Simple_get_value(self);
3867if (val == NULL)
3868return NULL;
3869
3870name = PyString_FromString(self->ob_type->tp_name);
Event var_compare_op: Added "name" due to comparison "name == 0"
Also see events: [var_deref_op]
At conditional (1): "name == 0" taking true path
3871if (name == NULL) {
Event var_deref_op: Variable "name" tracked as NULL was dereferenced.
Also see events: [var_compare_op]
3872Py_DECREF(name);
3873return NULL;
3874}
3875
3876args = PyTuple_Pack(2, name, val);
3877Py_DECREF(name);
3878Py_DECREF(val);
3879if (args == NULL)
3880return NULL;
What is being described is that name is known to be NULL and it is
being free()d which is incorrect. As you can see from the context,
line 3872 (of Modules/_ctypes/_ctypes.c) should be Py_DECREF(val);
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] Still looking for volunteer to run Windows buildbot
On Wed, 15 Mar 2006 20:18:28 +0100, Fredrik Lundh <[EMAIL PROTECTED]> wrote: >Martin v. L� wrote: > >> Jean-Paul Calderone wrote: >> > It should actually be using TerminateProcess (depending on the >> > Twisted version being used, the relevant code is either in >> > twisted/internet/_dumbwin32proc.py or >> > twisted/internet/win32eventreactor.py, in the signalProcess method in >> > either case) >> >> So PythonWin needs to be installed on a Windows buildbot slave, right? > >unless someone hacks Twisted to use _subprocess.TerminateProcess >instead of the win32all version... Twisted's Win32 process support also uses win32api, win32con, win32event, win32file, win32pipe, and win32security. ;P So the new subprocess module alone isn't quite a sufficient replacement... Jean-Paul ___ 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] Deprecated modules going away in 2.5
[Neal Norwitz wrote] > In addition, I will swap sre and re. This will make help(re) work properly. Yay! Trent -- Trent Mick [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] Still looking for volunteer to run Windows buildbot
> Martin v. L?wis wrote: > > So PythonWin needs to be installed on a Windows buildbot slave, right? PyWin32 you mean. PythonWin is the IDE-thing that is part of PyWin32. [Fredrik Lundh wrote] > unless someone hacks Twisted to use _subprocess.TerminateProcess > instead of the win32all version... +1 Trent -- Trent Mick [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] [Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py
At 10:33 AM 3/15/2006 -0800, Guido van Rossum wrote: >Well, absolute imports without the future statement will not use the >5th argument, so they won't break, right? That's what MAL also says. >Someone please fix this. Why is a 5th argument needed to do absolute imports? Shouldn't it suffice to supply a globals argument with no __path__ and an undotted __name__? ISTM that passing in the builtins dictionary as the globals argument ought to do the trick. ___ 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] Still looking for volunteer to run Windows buildbot
Martin v. Löwis wrote: > Jean-Paul Calderone wrote: > > It should actually be using TerminateProcess (depending on the > > Twisted version being used, the relevant code is either in > > twisted/internet/_dumbwin32proc.py or > > twisted/internet/win32eventreactor.py, in the signalProcess method in > > either case) > > So PythonWin needs to be installed on a Windows buildbot slave, right? unless someone hacks Twisted to use _subprocess.TerminateProcess instead of the win32all version... ___ 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] Still looking for volunteer to run Windows buildbot
Jean-Paul Calderone wrote: > It should actually be using TerminateProcess (depending on the > Twisted version being used, the relevant code is either in > twisted/internet/_dumbwin32proc.py or > twisted/internet/win32eventreactor.py, in the signalProcess method in > either case) So PythonWin needs to be installed on a Windows buildbot slave, right? 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] [Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py
Well, absolute imports without the future statement will not use the 5th argument, so they won't break, right? That's what MAL also says. Someone please fix this. On 3/15/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > > On 3/15/06, guido.van.rossum <[EMAIL PROTECTED]> wrote: > > > > Use relative imports in a few places where I noticed the need. > > (Ideally, all packages in Python 2.5 will use the relative import > > syntax for all their relative import needs.) > > > You should be aware that using relative imports (or absolute imports) in the > standard library may cause custom __import__'s that don't take the optional > fifth argument to break, whereas using 'old-style' imports does not. I don't > know how common custom __import__ hooks are, and adding the optional fifth > argument is backwardly compatible, but I would personally not add absolute > or relative imports to the oft-used parts of the stdlib until after 2.5. > > On the other hand, code using sys.path_hooks (like zipimport) don't need any > tweaking, as the absolute/relative choice is made before they are queried, > so I don't know howmuch impact this has, all in all. > > -- > Thomas Wouters <[EMAIL PROTECTED]> > > Hi! I'm a .signature virus! copy me into your .signature file to help me > spread! > ___ > 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/guido%40python.org > > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] [Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py
On 3/15/06, guido.van.rossum <[EMAIL PROTECTED]> wrote: Use relative imports in a few places where I noticed the need.(Ideally, all packages in Python 2.5 will use the relative importsyntax for all their relative import needs.)You should be aware that using relative imports (or absolute imports) in the standard library may cause custom __import__'s that don't take the optional fifth argument to break, whereas using 'old-style' imports does not. I don't know how common custom __import__ hooks are, and adding the optional fifth argument is backwardly compatible, but I would personally not add absolute or relative imports to the oft-used parts of the stdlib until after 2.5.On the other hand, code using sys.path_hooks (like zipimport) don't need any tweaking, as the absolute/relative choice is made before they are queried, so I don't know howmuch impact this has, all in all. -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] Still looking for volunteer to run Windows buildbot
On Wed, 15 Mar 2006 00:00:06 -0500, Tim Peters <[EMAIL PROTECTED]> wrote: >[Trent Mick] >> Yes I've noticed it too. I've had to kill python_d.exe a few times. I >> haven't yet had the chance to look into it. I am NOT getting this error >> on another Windows Python build slave that I am running in-house for >> play. > >The last run on your Win2K slave that got beyond the compile step: > >http://www.python.org/dev/buildbot/all/x86%20W2k%20trunk/builds/16/step-test/0 > >Looks like it was running test_bsddb at the time, and the test >framework gave up after waiting 20 minutes for more output. I had one >of those "recently" that waited 20 minutes for output after starting >test_shelve, but it's scrolled off the page. Berkeley DB is fishy. >Looks like the buildbot doesn't know how to kill a process on Windows >either (SIGKILL sure ain't gonna do it ;-)). It should actually be using TerminateProcess (depending on the Twisted version being used, the relevant code is either in twisted/internet/_dumbwin32proc.py or twisted/internet/win32eventreactor.py, in the signalProcess method in either case), but even this doesn't seem to be a completely reliable way to end a process. Twisted's buildbot has run into this problem as well, but we haven't figure out how to fix it yet. Suggestions welcome - patches even more so :) Jean-Paul ___ 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] Making builtins more efficient
| [ Raymond Hettinger ]: | > If someone really cared about the double lookup, they could | > flatten a level by starting their modules with: | > | >from __builtin__ import * | > | > However, we don't see people writing this kind of code. That | > could mean that the double lookup hasn't been a big concern. [ Steven Elliott <[EMAIL PROTECTED]> ]: | It could mean that. I think what you are suggesting is sufficiently | cleaver that the average Python coder may not have thought of it. | | # small cut | | And the "from __builtin__ import *" additionally imposes a startup | cost and memory cost (at least a word per builtin, I would guess). I suppose that if someone decided to use "from __builtin__ import *" to avoid double lookup, this person *knows* what builtins should be optmized, and therefore could use import specific builtins "from __builtin__ import len, max" avoiding a startup/memory penalty. Otherwise, the startup/memory penalty might be non-issues. cheers, Rod Senra ___ 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] PEP 338 implemented in SVN
Nick Coghlan wrote: > Following Guido's acceptance of the PEP in SVN, PEP 338 has now been checked > in for 2.5. (PEP's 0, 338 and 356 have been updated to reflect this). And thanks to buildbot, the test code that was broken on Windows has been fixed, too. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] About "Coverity Study Ranks LAMP Code Quality"
>> > return=NULL; output=junk => out of memory >> > return=junk; output=-1 => cannot do this >> > return=pointer; output=value => did this, returned value bytes >> >> > I agree that the design is a bit questionable; >> >> It sure is. If you get both NULL and -1 returned, how are >> you supposed to know which one is the junk? > > I was about to say "by doing the tests in the prescribed order", > but you're right that it's not obvious that the function checks > that it returns the right kind of junk... (it's possible that the > junk in the second line is actually "pointer to some other ob- > ject"). footnote: it is; the table should read return=NULL; output=junk => out of memory return=old pointer; output=-1 => no need do this; returning old pointer return=new pointer; output=value => did this, returned pointer to newly allocated area containing 'value' bytes ___ 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] PEP 338 implemented in SVN
Following Guido's acceptance of the PEP in SVN, PEP 338 has now been checked in for 2.5. (PEP's 0, 338 and 356 have been updated to reflect this). Cheers, Nick. P.S. Has the change to the new look site broken the automatic update of pydotorg after PEP checkins? (PEP 356 looks fairly different from the latest SVN version) -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Using relative imports in std lib packages ([Python-checkins] r43033 - in python/trunk/Lib: distutils/sysconfig.py encodings/__init__.py)
guido.van.rossum wrote:
> Author: guido.van.rossum
> Date: Wed Mar 15 05:33:54 2006
> New Revision: 43033
>
> Modified:
>python/trunk/Lib/distutils/sysconfig.py
>python/trunk/Lib/encodings/__init__.py
> Log:
> Use relative imports in a few places where I noticed the need.
> (Ideally, all packages in Python 2.5 will use the relative import
> syntax for all their relative import needs.)
Instead of adding relative imports to packages in the
standard lib, I'd suggest to use absolute imports instead.
These are much easier to manage, maintain and read.
There's also no "need" for relative imports in std lib
packages since these won't be subject to possible
relocation.
> Modified: python/trunk/Lib/distutils/sysconfig.py
> ==
> --- python/trunk/Lib/distutils/sysconfig.py (original)
> +++ python/trunk/Lib/distutils/sysconfig.py Wed Mar 15 05:33:54 2006
> @@ -16,7 +16,7 @@
> import string
> import sys
>
> -from errors import DistutilsPlatformError
> +from .errors import DistutilsPlatformError
>
> # These are needed in a couple of spots, so just compute them once.
> PREFIX = os.path.normpath(sys.prefix)
>
> Modified: python/trunk/Lib/encodings/__init__.py
> ==
> --- python/trunk/Lib/encodings/__init__.py(original)
> +++ python/trunk/Lib/encodings/__init__.pyWed Mar 15 05:33:54 2006
> @@ -27,7 +27,8 @@
>
> """#"
>
> -import codecs, types, aliases
> +import codecs, types
> +from . import aliases
>
> _cache = {}
> _unknown = '--unknown--'
> ___
> Python-checkins mailing list
> [EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/python-checkins
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Mar 15 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
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] About "Coverity Study Ranks LAMP Code Quality"
> (there's still a possibility that someone checks in a fix without realizing > that > the original bug is an attack vector, but I don't think Coverity has > discovered > anything like that in the Python code base; we're mainly talking about leaks > and null-pointer references here). to clarify, "potential leaks and null-pointer references". we already have Neal for leaks, and a large user base for null-pointer references... ___ 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] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
[Martin] > ... > I believe it does: the ctypes maintainer wants to keep the > code identical across releases (AFAICT). Fair enough -- I reverted the checkin. It's going to need #if'ery on the Python version, though, if it wants to match a Python-version-dependent data width with an appropriate format code. ___ 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] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
Tim Peters wrote: >>Unfortunately, only so in Python 2.5. If the code is also >>meant to be used for earlier versions, it won't work there >>at all. > > > Does that matter? I believe it does: the ctypes maintainer wants to keep the code identical across releases (AFAICT). > has Py_ssize_t all over the place, and that's unique to 2.5 (so far) too, > right? Not necessarily. For example, Modules/_elementtree.c has /* compatibility macros */ #if (PY_VERSION_HEX < 0x0205) typedef int Py_ssize_t; #define lenfunc inquiry #endif I believe ctypes "wants" to take that approach also. 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] About "Coverity Study Ranks LAMP Code Quality"
Martin v. Löwis wrote: > > On the other hand, the exploit could be crafted based on reading the SVN > > check-ins ... > > Sure. However, at that point, the bug is fixed (atleast in SVN); > crackers need to act comparatively fast then to exploit it. OTOH, if > only the report was available, the project might not take any action > for some time, increasing the risk of an exploit. it should also be mentioned that Python has an established procedure for dealing with more serious security problems, and "go check it in" is not part of that procedure. (there's still a possibility that someone checks in a fix without realizing that the original bug is an attack vector, but I don't think Coverity has discovered anything like that in the Python code base; we're mainly talking about leaks and null-pointer references here). ___ 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] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
[tim.peters]
>> CField_repr(): PyString_FromFormat() understands the
>> C99 "z" qualifier on all platforms.
[Martin v. Löwis]
> Unfortunately, only so in Python 2.5. If the code is also
> meant to be used for earlier versions, it won't work there
> at all.
Does that matter? I checked the patch in on the Python trunk, and
that's 2.5 to me ;-) The change was in:
static void
CField_repr(CFieldObject *self)
and:
typedef struct {
PyObject_HEAD
Py_ssize_t offset;
Py_ssize_t size;
Py_ssize_t index; /* Index into CDataObject's
object array */
PyObject *proto;/* a type or NULL */
GETFUNC getfunc;/* getter function if proto is NULL */
SETFUNC setfunc;/* setter function if proto is NULL */
} CFieldObject;
has Py_ssize_t all over the place, and that's unique to 2.5 (so far) too, right?
___
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] Still looking for volunteer to run Windows buildbot
Trent Mick wrote: > Yes I've noticed it too. I've had to kill python_d.exe a few times. I > haven't yet had the chance to look into it. I am NOT getting this error > on another Windows Python build slave that I am running in-house for > play. I believe this originated from a test run not terminating. buildbot then tried to kill the test run after the timeout; that also failed. Subsequent build now fail to compile. It just happened again: http://www.python.org/dev/buildbot/trunk/x86%20W2k%20trunk/builds/23/step-test/0 http://www.python.org/dev/buildbot/trunk/x86%20W2k%20trunk/builds/23/step-test/1 http://www.python.org/dev/buildbot/trunk/x86%20W2k%20trunk/builds/23/step-test/2 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] About "Coverity Study Ranks LAMP Code Quality"
Alexander Schremmer wrote: >>I can understand that position. The bugs they find include potential >>security flaws, for which exploits could be created if the results are >>freely available. > > > On the other hand, the exploit could be crafted based on reading the SVN > check-ins ... Sure. However, at that point, the bug is fixed (atleast in SVN); crackers need to act comparatively fast then to exploit it. OTOH, if only the report was available, the project might not take any action for some time, increasing the risk of an exploit. Only telling the developers is an established tradition for security-relevant bugs, and a reasonable one IMO. 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] [Python-checkins] r43028 - python/trunk/Modules/_ctypes/cfield.c
>> Author: thomas.heller
>> Date: Tue Mar 14 21:39:27 2006
>> New Revision: 43028
>>
>> Modified:
>>python/trunk/Modules/_ctypes/cfield.c
>> Log:
>> Cast an Py_ssize_t to int, to avoid a compiler warning.
>>
>> Modified: python/trunk/Modules/_ctypes/cfield.c
>> ==
>> --- python/trunk/Modules/_ctypes/cfield.c (original)
>> +++ python/trunk/Modules/_ctypes/cfield.c Tue Mar 14 21:39:27 2006
>> @@ -251,10 +251,10 @@
>>
>> if (bits)
>> result = PyString_FromFormat("",
>> -name, self->offset, size, bits);
>> +name,
(int)self->offset, size, bits);
>> else
>> result = PyString_FromFormat("",
>> -name, self->offset, size);
>> +name, (int)self->offset, size);
>> return result;
>> }
[Neal Norwitz]
> This isn't exactly correct. On a 64-bit system, the value will be
> cast into a 32-bit integer. This is true for both Win64 and Unix. If
> you change the cast to a long and use %ld (lowercase ell), that will
> work correctly on Unix, but not Win64. To always display the correct
> value on all platforms, you need an #ifdef MS_WIN64. For Windows, you
> use %Id (that's a capital letter eye) and reference the value without
> a cast. For Unix, you use %ld (lowercase ell), and cast the value to
> a (long) to avoid a warning.
I'm copying this to python-dev because it's important people
understand this :-): all of the above is kinda true but irrelevant.
Martin already checked in a patch so that PyString_FromFormat()
understands the C99 "z" qualifier on _all_ platforms. So the correct
way to repair this one wasn't to add a cast, and much less to add an
#ifdef, it was to change
ofs=%d
to
ofs=%zd
in the format. I'm going to check that change in now, but don't make
me do it again :-)
___
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] Bug Day?
Neil Schemenauer wrote: > I think it would be a good idea to follow the Plone project and try > to encourage new developers by offering assistance to get them up > and running. AFAIK, we've done that for the other bug days but it > might help to publish the fact that no prior Python development > experience is necessary. That's right, though I guess it'll be hard to find new core developers. Unfortunately, for most people developing _with_ Python is much more fun than developing Python. Settling on Friday, how about the 31st of March? If that's okay for the VIPs, I will send out announcements on python-list, the non-english newsgroups and lists and ask Tim to place it on the website. 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
