[EMAIL PROTECTED] wrote:
> if (b == 1) {
> -literal = sre_literal_template(ptr, n);
> + literal = sre_literal_template((SRE_CHAR *)ptr, n);
> } else {
> #if defined(HAVE_UNICODE)
> -literal = sre_uliteral_template(ptr, n);
On Mon, 17 Apr 2006, [ISO-8859-1] "Martin v. L?wis" wrote:
> > There is a patch on SourceForge
> > python.org/sf/721464
> > which allows pdb to read/write from/to arbitrary file objects. Would it
> > answer some of your concerns (eg remote debugging)?
> >
> > I guess, I could revive it if anyo
[Thomas Wouters]
> ...
> One remaining issue with refleakhunting on my machine is that test_tcl can't
> stand being run twice. Even without -R, this makes Python hang while waiting
> for a mutex in the second run through test_tcl:
>
> ...trunk $ ./python -E -tt Lib/test/regrtest test_tcl test_tcl
>
[EMAIL PROTECTED]
> I'm on the blame list for the current gentoo buildbot failures. I promise I
> ran "make test" before checking anything in. I don't see where the changes
> I checked in would have caused the reported test failures, but I'm
> investigating. If anyone has any suggestions, let me
On Tuesday 18 April 2006 11:27, [EMAIL PROTECTED] wrote:
> During the 16-bit pass, SRE_CHAR expands to Py_UNICODE, so the call
> to sre_literal_template is incorrect. Any ideas how to fix things?
I thought (but haven't had time to test) that making getstring return
a union that's either SRE_CHAR
I'm on the blame list for the current gentoo buildbot failures. I promise I
ran "make test" before checking anything in. I don't see where the changes
I checked in would have caused the reported test failures, but I'm
investigating. If anyone has any suggestions, let me know.
Skip
_
I checked in a number of minor changes this evening to correct various
problems compiling Python with a C++ compiler, in my case Apple's version of
g++ 4.0. I'm stuck on Modules/_sre.c though. After applying this change:
Index: Modules/_sre.c
On 4/17/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > This PEP proposes a generalization of the class-declaration syntax,
> > the ``make`` statement. The proposed syntax and semantics parallel
> > the syntax for class definition, and so::
> >
> >make :
> >
>
On 4/17/06, Russell E. Owen <[EMAIL PROTECTED]> wrote:
> At some point folks were discussing use cases of "make" where it was
> important to preserve the order in which items were added to the
> namespace.
>
> I'd like to suggest adding an implementation of an ordered dictionary to
> standard pytho
Bug 532646 is a check for recursive __call__ methods where it is just
set to an instance of the same class::
class A:
pass
A.__call__ = A()
a = A()
try:
a() # This should not segfault
except RuntimeError:
pass
else:
raise TestFailed, "how could this not have overflowed the stack?"
At some point folks were discussing use cases of "make" where it was
important to preserve the order in which items were added to the
namespace.
I'd like to suggest adding an implementation of an ordered dictionary to
standard python (e.g. as a library or built in type). It's inherently
useful
Steven Bethard wrote:
> This PEP proposes a generalization of the class-declaration syntax,
> the ``make`` statement. The proposed syntax and semantics parallel
> the syntax for class definition, and so::
>
>make :
>
I can't really see any use case for . In particular, you could
Tim Peters wrote:
>> I might see if I can work up a patch over the easter long weekend if
>> no one beats me to it. What files should I be looking at (it would
>> be my first C-level python patch)?
Blegh - my parents came to visit ...
Tim Delaney
___
P
Tim> Explicitly casting -1 is both the obvious and best way, and is
Tim> guaranteed to "work as intended" by the standards.
Thanks. I'll fix 'em.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
Fred> Looks like a bug to me. It should be set just before confstr() is
Fred> called.
Thanks. I'll fix, test and check in...
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
[EMAIL PROTECTED]
> I'm fiddling with the "compile Python w/ C++" stuff and came across a number
> of places where a function is defined as returning unsigned long or unsigned
> long long but returns -1. For example, see PyInt_AsUnsignedLongMask.
> What's the correct fix for that, return ~0 (assu
On Monday 17 April 2006 17:39, [EMAIL PROTECTED] wrote:
> 1. Why is errno being set to 0?
The C APIs don't promise to clear errno on input; you have to do that
yourself.
> 2. Why is errno's value then tested to see if it's not zero?
>
> Looks like this have been that way since December 1999
More C++ stuff...
According to the man page on my Mac:
If the call to confstr() is not successful, -1 is returned and errno is
set appropriately.
but the code in posix_confstr looks like:
if (PyArg_ParseTuple(args, "O&:confstr", conv_confstr_confname, &name)) {
int len = con
hello folksafter several people (several > 10) contacted me and said "IMHO 'construct' is a good candidate for stdlib",i thought i should give it a try. of course i'm
not saying it should be included right now, but in 6 months time, or such a
timeframe (aiming at python 2.6? some 2.5.x release?)a
I'm fiddling with the "compile Python w/ C++" stuff and came across a number
of places where a function is defined as returning unsigned long or unsigned
long long but returns -1. For example, see PyInt_AsUnsignedLongMask.
What's the correct fix for that, return ~0 (assuming twos-complement
arith
[Thomas Wouters]
>> test_threading_local is not entirely consistent, but it looks a lot more
>> reliable on my box than on Neal's automated mails:
>>
>> test_threading_local
>> beginning 11 repetitions
>> 12345678901
>> ...
>> test_threading_local leaked [34, 34, 34, 34, 34, 26, 26, 22, 34]
Martin v. Löwis wrote:
> Grégoire Dooms wrote:
>
>> What should I do to get it reviewed further ? (perhaps just this :
>> posting to python-dev :-)
>>
>
> It didn't help that much, except for keeping your mail in my inbox.
>
> In any case, I went back to it and checked it in.
>
Thank
Tim Peters wrote:
> No, what's surprising is that it keeps running _forever_. This isn't
> Unix, and, e.g., a defunct child process doesn't sit around waiting
> for its parent to reap it. Why doesn't the leftover python_d.exe
> complete running the test suite, and then go away all by itself? It
Hi,
I've uploaded 3 patches that form the core of the python24-fat tree
that Bob Ippolito and I have been maintaining for a while. With these
patches one can build fat/universal binaries for python that run
natively on OSX 10.3 and later.
I'd like to merge these patches to the trunk, but wo
[Tim]
>> ...
>> 2. The buildbot code tries to kill the process itself. It appears (to judge
>>from the buildbot messges) that this never works on Windows.
>>
>> 3. For reasons that are still unknown, python_d.exe keeps running,
>>and forever.
[Martin]
> It's actually not too surprising th
Ronald Oussoren wrote:
> A couple of lines down it says:
> "The pointer returned by readdir() points to data which may be
> overwritten by another call to readdir() on the same directory
> stream. This data is not overwritten by another call to readdir() on
> a different directory stream."
>
Anthony Baxter wrote:
> There's a scripts Tools/scripts/reindent.py - put it somewhere on your
> PATH and run it before checkin, like "reindent.py -r Lib". It means Tim
> or I don't have to run it for you
As I kept forgetting what the name, location, and command line options
of that script are, I
Peter Moore wrote:
> I'm responsible for setting up free FishEye hosting for community
> projects. As a long time python user I of course added Python up
> front. You can see it here:
>
> http://fisheye.cenqua.com/viewrep/python/
Can you please move that to the subversion repository
(http://sv
Grégoire Dooms wrote:
> What should I do to get it reviewed further ? (perhaps just this :
> posting to python-dev :-)
It didn't help that much, except for keeping your mail in my inbox.
In any case, I went back to it and checked it in.
Regards,
Martin
__
On 17-apr-2006, at 20:50, Martin v. Löwis wrote:
> Ronald Oussoren wrote:
>> AFAIK readdir is only unsafe when multiple threads use the same
>> DIR* at
>> the same time. The spec[1] seems to agree with me.
>> [1] : http://www.opengroup.org/onlinepubs/009695399/functions/
>> readdir.html
>
> Wh
> OTOH, we could just as well check in an executable that
> does all that, e.g. like the one in
I did something like this: I checked the source of a
kill_python.exe application which looks at all running processes
and tries to kill python_d.exe. After several rounds of
experimentation, this now wa
Ronald Oussoren wrote:
> AFAIK readdir is only unsafe when multiple threads use the same DIR* at
> the same time. The spec[1] seems to agree with me.
> [1] : http://www.opengroup.org/onlinepubs/009695399/functions/readdir.html
What specific sentence makes you think so? I see
"The readdir() interf
On 17-apr-2006, at 18:19, Martin v. Löwis wrote:
> Currently, the readdir() call releases the GIL. I believe
> this is not thread-safe, because readdir() does not need
> to be re-entrant; we should use readdir_r where available
> to get a thread-safe version.
>
> Comments?
AFAIK readdir is only
At 12:53 PM 4/17/2006 -0400, Phillip J. Eby wrote:
>By the way, the above cycle will leak even if the generator is never
>iterated even once; it's quite simple to set up. I'm testing this using
>-R:: on test_generators, and hacking on the _fib function and friends.
Follow-up note: it's possible t
If PyObject_REPR changes or gets renamed in Py2.5, I suggest modifying
the implementation so that it returns a newly allocated C pointer rather
one embedded in an inaccessible (unfreeable) PyStringObject. Roughly:
r = PyObject_Repr(o);
if (r == NULL)
return NULL;
s1 = PyObject_AS_STRING(r);
s2 =
I've been fiddling a bit with test_generators this morning, and have found
that a stripped down version of the fibonacci test only leaks if the
generator has a reference to a *copied* tee object. It doesn't matter
whether the copied tee object is the second result from tee(), or if you
just cr
Currently, the readdir() call releases the GIL. I believe
this is not thread-safe, because readdir() does not need
to be re-entrant; we should use readdir_r where available
to get a thread-safe version.
Comments?
Regards,
Martin
___
Python-Dev mailing l
Ilya Sandler wrote:
> There is a patch on SourceForge
> python.org/sf/721464
> which allows pdb to read/write from/to arbitrary file objects. Would it
> answer some of your concerns (eg remote debugging)?
>
> The patch probably will not apply to the current code, but I guess, I
> could revive it
David Abrahams wrote:
> I just wanted to write to encourage some Python developers to look at
> (and accept!) Christoph's patch. This is really crucial for smooth
> interoperability between C++ and Python.
I did, and accepted the patch. If there is anything left to be done,
please submit another
Tim Peters wrote:
> 2. The buildbot code tries to kill the process itself. It appears (to judge
>from the buildbot messges) that this never works on Windows.
>
> 3. For reasons that are still unknown, python_d.exe keeps running,
>and forever.
It's actually not too surprising that python_
Neal Norwitz wrote:
> If the patch won't fix the problem, is there something else we can do
> to ensure the python DLL is no longer used regardless of whether the
> previous test passed or not?
Rebooting the machine will help, and might be the only cure.
It's Windows, after all :-(
Of course, we
Tim Peters wrote:
> Putting a collection call inside an initialize/finalize loop isn't
> doing it late, it's doing it early. If we can't collect cyclic trash
> after Py_Initialize(), that would be a showstopper for apps embedding
> Python "in a loop"! There's either nothing to fear here, or Pytho
We've only got a short time to get setup for Google's Summer of Code.
We need to start identifying mentors and collecting ideas for students
to implement. We have the SimpleTodo list
(http://wiki.python.org/moin/SimpleTodo), but nothing on the SoC page
yet (http://wiki.python.org/moin/SummerOfCod
43 matches
Mail list logo
