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
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
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
[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
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
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
[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
(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,
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
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
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
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 |
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
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
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
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
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
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
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
[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
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
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
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
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
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
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
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.
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
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
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
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
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
[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.
...
For Py3k, any thoughts on changing the syntax of
the except clause from
except type, value:
to
except type as value:
so that things like
except TypeError, ValueError:
will do what is expected?
Greg
___
Python-Dev mailing list
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 =
[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
On 3/15/06, Greg Ewing [EMAIL PROTECTED] wrote:
For Py3k, any thoughts on changing the syntax of
the except clause from
except type, value:
to
except type as value:
so that things like
except TypeError, ValueError:
will do what is expected?
Not a bad idea. The trend seems
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
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.
39 matches
Mail list logo
