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, and
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 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
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 remain unconvinced.
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's
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 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 releases (2.x.1 and
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
___
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
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 new
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 clients in
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 that this
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 surprised that you
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 by
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 to
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 for
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
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
-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
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
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 the same
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 to
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
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 calls
24 matches
Mail list logo
