Martin v. Löwis wrote:
> Steve Holden schrieb:
>> Or simply that this inability isn't currently
>> described in a bug report on Sourceforge?
>
> No: sys.path is specified (originally) as containing a list of byte
> strings; it was extended to also support path importers (or whatever
> that PEP ca
On 9/8/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> Ensuring modifications to that array are atomic would be tricky, but I
> think it would be doable if we use a read-copy-update approach (with
> two alternating signal handler functions). Not sure how to ensure
> there's no currently running signal
On 9/8/06, Jan Kanis <[EMAIL PROTECTED]> wrote:
> At the risk of waking up a thread that was already declared dead, but
> perhaps this is usefull.
I don't think we should let this die, at least not yet. Nick seems to
be arguing that ANY signal handler is prone to random crashes or
corruption (due
At the risk of waking up a thread that was already declared dead, but
perhaps this is usefull.
So, what happens is pythons signal handler sets a flag and registrers a
callback. Then the main thread should check the flag and make the callback
to actually do something with the signal. However
Patch / Bug Summary
___
Patches : 413 open ( +1) / 3407 closed (+10) / 3820 total (+11)
Bugs: 897 open ( -3) / 6167 closed (+18) / 7064 total (+15)
RFE : 234 open ( +1) / 238 closed ( +2) / 472 total ( +3)
New / Reopened Patches
__
Fix decim
Barry Scott <[EMAIL PROTECTED]> wrote:
>
> I have the tool chains to build extensions against your binary python
> 2.2, 2.3 and 2.4 on windows.
>
> What are the tool chain requirements for building extensions against
> python 2.5 on windows?
The compiler requirements for 2.5 on Windows is t
On Fri, Sep 08, 2006 at 06:27:08PM -0400, Barry Warsaw wrote:
>
> On Sep 8, 2006, at 6:06 PM, Mihai Ibanescu wrote:
>
> >There is no description of what happens when Py_BuildValue fails.
> >Will it
> >decref the python object passed in? Will it not?
>
> I just want to point out that the C API
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 8, 2006, at 6:06 PM, Mihai Ibanescu wrote:
> There is no description of what happens when Py_BuildValue fails.
> Will it
> decref the python object passed in? Will it not?
I just want to point out that the C API documentation is pretty
sil
I have the tool chains to build extensions against your binary python
2.2, 2.3 and 2.4 on windows.
What are the tool chain requirements for building extensions against
python 2.5 on windows?
Barry
___
Python-Dev mailing list
Python-Dev@python.org
Hi,
Looking at:
http://docs.python.org/api/arg-parsing.html
The description for "O" is:
"O" (object) [PyObject *]
Store a Python object (without any conversion) in a C object pointer. The
C program thus receives the actual object that was passed. The object's
reference count is not
Giovanni Bajo schrieb:
> +1, but I would love to see a more formal definition of what a "bugfix" is,
> which would reduce the ambiguous cases, and thus reduce the number of times
> the
> release managers are called to pronounce.
>
> Other projects, for instance, describe point releases as "open f
Steve Holden schrieb:
> I don't regard this as the provision of a new feature but as the removal
> of an unnecessary restriction (which I would prefer to call a bug).
You got the definition of "bug" wrong. Primarily, a bug is a deviation
from the specification. Extending the domain of an argument
Nick Coghlan schrieb:
>> But it *is* a desirable, albeit new, feature, so I'm surprised that you
>> don't appear to perceive it as such for a downstream release.
>
> And unlike 2.2's True/False problem, it is an *environmental* feature, rather
> than a programmatic one.
Not sure what you mean b
Steve Holden schrieb:
>>> I agree it's a relatively large patch for a release candidate but if
>>> prudence suggests deferring it, it should be a *definite* for 2.5.1 and
>>> subsequent releases.
>>
>> Possibly. I remain unconvinced.
>>
>
> But it *is* a desirable, albeit new, feature, so I'm sur
Steve Holden schrieb:
>> As this can't be considered a bugfix (that I can see), I'd be against it
>> being
>> checked into 2.5.
>>
> Are you suggesting that Python's inability to correctly handle Unicode
> path elements isn't a bug?
Not sure whether Anthony suggests it, but I do.
> Or simply
Kristján V. Jónsson wrote:
> Hello All.
> I just added patch 1552880 to sourceforge. It is a patch for 2.6 (and 2.5)
> which allows unicode paths in sys.path and uses the unicode file api on
> windows.
> This is tried and tested on 2.5, and backported to 2.3 and is currently
> running on client
Giovanni Bajo wrote:
>
>+1, but I would love to see a more formal definition of what a "bugfix" is,
>which would reduce the ambiguous cases, and thus reduce the number of times the
>release managers are called to pronounce.
>
>
Sorry, that is just a pipe-dream. To some degree, all bug-fixes are
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> IMO it's the call of the release managers. Board members ought to
> trust the release managers and not apply undue pressure.
+1, but I would love to see a more formal definition of what a "bugfix" is,
which would reduce the ambiguous cases, and thus
Guido> IMO it's the call of the release managers. Board members ought to
Guido> trust the release managers and not apply undue pressure.
Indeed. Let's not go whacking people with boards. The Perl people would
just laugh at us...
Skip
___
Pyth
On 9/8/06, Steve Holden <[EMAIL PROTECTED]> wrote:
> Anthony Baxter wrote:
> > On Friday 08 September 2006 19:19, Steve Holden wrote:
> >
> >>But it *is* a desirable, albeit new, feature, so I'm surprised that you
> >>don't appear to perceive it as such for a downstream release.
> >
> >
> > Point r
Anthony Baxter wrote:
> On Friday 08 September 2006 19:19, Steve Holden wrote:
>
>>But it *is* a desirable, albeit new, feature, so I'm surprised that you
>>don't appear to perceive it as such for a downstream release.
>
>
> Point releases (2.x.1 and suchlike) are absolutely not for new features
On Friday 08 September 2006 19:19, Steve Holden wrote:
> But it *is* a desirable, albeit new, feature, so I'm surprised that you
> don't appear to perceive it as such for a downstream release.
Point releases (2.x.1 and suchlike) are absolutely not for new features.
They're for bugfixes, only. It'
Steve Holden wrote:
> Anthony Baxter wrote:
>> On Friday 08 September 2006 18:24, Steve Holden wrote:
>>> I agree it's a relatively large patch for a release candidate but if
>>> prudence suggests deferring it, it should be a *definite* for 2.5.1 and
>>> subsequent releases.
>>
>> Possibly. I remai
Anthony Baxter wrote:
> On Friday 08 September 2006 18:24, Steve Holden wrote:
>
>>>As this can't be considered a bugfix (that I can see), I'd be against it
>>>being checked into 2.5.
>>
>>Are you suggesting that Python's inability to correctly handle Unicode
>>path elements isn't a bug? Or simply
On Friday 08 September 2006 18:24, Steve Holden wrote:
> > As this can't be considered a bugfix (that I can see), I'd be against it
> > being checked into 2.5.
>
> Are you suggesting that Python's inability to correctly handle Unicode
> path elements isn't a bug? Or simply that this inability isn't
Anthony Baxter wrote:
> On Friday 08 September 2006 02:56, Kristján V. Jónsson wrote:
>
>>Hello All.
>>I just added patch 1552880 to sourceforge. It is a patch for 2.6 (and 2.5)
>>which allows unicode paths in sys.path and uses the unicode file api on
>>windows. This is tried and tested on 2.5, a
26 matches
Mail list logo
