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 staticme
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
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 b
[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" fo
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
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://ma
[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.
...
_
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
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
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 absolut
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 m
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 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.
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
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 wan
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 co
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 gl
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 "
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.
[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
Unsubsc
> 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...
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:
> 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
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
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 relativ
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
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-h
| [ 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 has
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 |
>> > 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
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 f
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 p
> (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,
[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 fo
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 o
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 pro
[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
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 terminati
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. How
>> 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
>> =
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
>
41 matches
Mail list logo
