Re: [Python-Dev] Unicode Imports
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 backported to 2.3 and is >>currently running on clients in china and esewhere. It is minimally >>intrusive to the inporting mechanism, at the cost of some string conversion >>overhead (to utf8 and then back to unicode). > > > 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 currently described in a bug report on Sourceforge? 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. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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 currently > described in a bug report on Sourceforge? I'm suggesting that adding the ability to handle unicode paths is a *new* *feature*. If people actually want to see 2.5 final ever released, they're going to have to accept that "oh, but just this _one_ _more_ _thing_" is not going to fly. We're _well_ past beta1, where new features should have been added. At this point, we have to cut another release candidate. This is far too much to add during the release candidate stage. > 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. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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 inability isn't currently >>described in a bug report on Sourceforge? > > I'm suggesting that adding the ability to handle unicode paths is a *new* > *feature*. > That's certainly true. > If people actually want to see 2.5 final ever released, they're going to have > to accept that "oh, but just this _one_ _more_ _thing_" is not going to fly. > > We're _well_ past beta1, where new features should have been added. At this > point, we have to cut another release candidate. This is far too much to add > during the release candidate stage. > Right. I couldn't argue for putting this in to 2.5 - it would certainly represent unwarranted feature creep at the rc2 stage. > >>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 don't appear to perceive it as such for a downstream release. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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. >> > > 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. So while it's a new feature, it would merely mean that 2.5.1 works correctly in more environments than 2.5. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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 possible that this could be considered a bugfix, but as I said right now I'm dubious. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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. > They're for bugfixes, only. It's possible that this could be considered a > bugfix, but as I said right now I'm dubious. > OK, in that case I'm going to argue that the current behaviour is buggy. I suppose your point is that, assuming the patch is correct (and it seems the authors are relying on it for production purposes in tens of thousands of installations), it doesn't change the behaviour of the interpreter in existing cases, and therefore it is providing a new feature. 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). If it was *documented* somewhere that Unicode paths aren't legal I would find your arguments more convincing. As things stand new Python users would, IMHO, be within their rights to assume that arbitrary directories could be added to the path without breakage. Ultimately, your call, I guess. Would it help if I added "inability to import from Unicode directories" as a bug? Or would you prefer to change the documentation to state that some directories can't be used as path elements <0.3 wink>? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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 suchlike) are absolutely not for new features. > > They're for bugfixes, only. It's possible that this could be considered a > > bugfix, but as I said right now I'm dubious. > > > OK, in that case I'm going to argue that the current behaviour is buggy. > > I suppose your point is that, assuming the patch is correct (and it > seems the authors are relying on it for production purposes in tens of > thousands of installations), it doesn't change the behaviour of the > interpreter in existing cases, and therefore it is providing a new feature. > > 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). If > it was *documented* somewhere that Unicode paths aren't legal I would > find your arguments more convincing. As things stand new Python users > would, IMHO, be within their rights to assume that arbitrary directories > could be added to the path without breakage. > > Ultimately, your call, I guess. Would it help if I added "inability to > import from Unicode directories" as a bug? Or would you prefer to change > the documentation to state that some directories can't be used as path > elements <0.3 wink>? We've all heard the arguments for both sides enough times I think. IMO it's the call of the release managers. Board members ought to trust the release managers and not apply undue pressure. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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 reduce the number of times the release managers are called to pronounce. Other projects, for instance, describe point releases as "open for regression fixes only", which means that a patch, to be eligible for a point release, must fix a regression (something which used to work before, and doesn't anymore). Regressions are important because they affect people wanting to upgrade Python. If something never worked before (like this unicode path thingie), surely existing Python users are not affected by the bug (or they have already workarounds in place), so that NOT having the bug fixed in a point release is not a problem. Anyway, I'm not pushing for this specific policy (even if I like it): I'm just suggesting Release Managers to more formally define what should and what should not go in a point release. Giovanni Bajo ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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 features in that there is some behavioral difference, something will now work that wouldn't work before. While some cases are clear-cut (such as API changes), the ones that are interesting will defy definition and need a human judgment call as to whether a given change will help more than it hurts. The RMs are also strongly biased against extensive patches than haven't had a chance to go through a beta-cycle -- they don't want their releases mucked-up. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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 china and esewhere. It is minimally intrusive to the > inporting mechanism, at the cost of some string conversion overhead (to utf8 > and then back to unicode). +1 on adding it to Python 2.6. -0 for Python 2.5.x: Applications/modules written for Python 2.4 and 2.5 won't be expecting Unicode strings in sys.path with all the consequences that go with it, so this is a true change in semantics, not just a nice to have additional feature or "bug" fix. OTOH, those applications will just break in a different place with the patch applied :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 08 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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 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 them). It was never extended to support Unicode strings. That other PEP e > 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. I'm not so sure it should. It *is* a new feature: it makes applications possible which aren't possible today, and the documentation does not ever suggest that these applications should have been possible. In fact, it is common knowledge that this currently isn't supported. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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 > don't appear to perceive it as such for a downstream release. Because 2.5.1 shouldn't include any new features. If it is a new feature (which it is), it should go into 2.6. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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 that; if you mean "thus existing applications cannot break": this is not true. In fact, it seems that some applications are extremely susceptible to the types of objects on sys.path. Some applications apparently know exactly what you can and cannot find on sys.path; changing that might break them. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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 an existing function is a new feature. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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 regression > fixes only", which means that a patch, to be eligible for a point release, > must > fix a regression (something which used to work before, and doesn't anymore). In Python, the tradition has excepted bug fixes beyond that. For example, fixing a memory leak would also count as a bug fix. In general, I think a "bug" is a deviation from the specification (it might be necessary to interpret the specification first to find out whether the implementation deviates). A bug fix is then a behavior change so that the new behavior follows the specification, or a specification change so that it correctly describes the behavior. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Py_BuildValue and decref
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 increased. The pointer stored is not NULL.
There is no description of what happens when Py_BuildValue fails. Will it
decref the python object passed in? Will it not?
Looking at tupleobject.h:
/*
Another generally useful object type is a tuple of object pointers.
For Python, this is an immutable type. C code can change the tuple items
(but not their number), and even use tuples are general-purpose arrays of
object references, but in general only brand new tuples should be mutated,
not ones that might already have been exposed to Python code.
*** WARNING *** PyTuple_SetItem does not increment the new item's reference
count, but does decrement the reference count of the item it replaces,
if not nil. It does *decrement* the reference count if it is *not*
^^^
inserted in the tuple. Similarly, PyTuple_GetItem does not increment the
returned item's reference count.
*/
So, if the call to PyTuple_SetItem fails, the value passed in is lost. Should
I expect the same thing with Py_BuildValue?
Looking at how other modules deal with this, I picked typeobject.c:
result = Py_BuildValue("[O]", (PyObject *)type);
if (result == NULL) {
Py_DECREF(to_merge);
return NULL;
}
so no attempt to DECREF type in the error case.
Further down...
if (n) {
state = Py_BuildValue("(NO)", state, slots);
if (state == NULL)
goto end;
}
and further down:
end:
Py_XDECREF(cls);
Py_XDECREF(args);
Py_XDECREF(args2);
Py_XDECREF(slots);
Py_XDECREF(state);
Py_XDECREF(names);
Py_XDECREF(listitems);
Py_XDECREF(dictitems);
Py_XDECREF(copy_reg);
Py_XDECREF(newobj);
return res;
so it will attempt to DECREF the (non-NULL) slots in the error case.
It's probably not a big issue since if Py_BuildValue fails, you have bigger
issues than memory leaks, but it seems inconsistent to me. Can someone that
knows the internal implementation clarify one way over the other?
Thanks!
Misa
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] What windows tool chain do I need for python 2.5 extensions?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py_BuildValue and decref
-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 silent about the refcounting side-effects in error conditions (and often in success conditions too) of most Python functions. For example, what is the refcounting side-effects of PyDict_SetItem() on val? What about if that function fails? Has val been incref'd or not? What about the side-effects on any value the new one replaces, both in success and failure? The C API documentation has improved in documenting the refcount behavior for return values of many of the functions, but the only reliable way to know what some other side-effects are is to read the code. After I perfect my human cloning techniques, I'll be assigning one of my minions to fix this situation (I'll bet my clean-the-kitty- litter-and-stalk-er-keep-tabs-on-Britney clone would love to take a break for a few weeks to work on this). - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRQHuQnEjvBPtnXfVAQJfFAP9GHIRhiVc7lkzwEkPtJgqNsrN8edQcKh3 l4edSlDD7JoJrIaOElqyIaEKcJSkjpKfJt6qdA1qIt8LD9x4pGvdxpxgodGVYfFo VGPwm+pU9SH6JJIZcCOOf9bJbEmR9iqZKceAJMGgJvZjBnTnoVSyf52254q3JJGR b9glwqbddi0= =3iWf -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py_BuildValue and decref
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 documentation is pretty
> silent about the refcounting side-effects in error conditions (and
> often in success conditions too) of most Python functions. For
> example, what is the refcounting side-effects of PyDict_SetItem() on
> val? What about if that function fails? Has val been incref'd or
> not? What about the side-effects on any value the new one replaces,
> both in success and failure?
In this particular case, it doesn't decref it (or so I read the code).
Relevant code is in do_mkvalue from Python/modsupport.c
case 'N':
case 'S':
case 'O':
if (**p_format == '&') {
typedef PyObject *(*converter)(void *);
converter func = va_arg(*p_va, converter);
void *arg = va_arg(*p_va, void *);
++*p_format;
return (*func)(arg);
}
else {
PyObject *v;
v = va_arg(*p_va, PyObject *);
if (v != NULL) {
if (*(*p_format - 1) != 'N')
Py_INCREF(v);
}
else if (!PyErr_Occurred())
/* If a NULL was passed
* because a call that should
* have constructed a value
* failed, that's OK, and we
* pass the error on; but if
* no error occurred it's not
* clear that the caller knew
* what she was doing. */
PyErr_SetString(PyExc_SystemError,
"NULL object passed to
Py_BuildValue");
return v;
}
Barry, where can I ship you my cloning machine? :-)
Misa
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What windows tool chain do I need for python 2.5 extensions?
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 as 2.4 . - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
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 decimal context management for 2.5 (2006-09-02) CLOSED http://python.org/sf/1550886 opened by Nick Coghlan Fix for rpartition() end-case (2006-09-03) CLOSED http://python.org/sf/1551339 opened by Raymond Hettinger Updated spec file for 2.5 release. (2006-09-03) CLOSED http://python.org/sf/1551340 opened by Sean Reifschneider unparse.py decorator support (2006-09-04) http://python.org/sf/1552024 opened by Adal Chiriliuc eval docstring typo (2006-09-04) CLOSED http://python.org/sf/1552093 opened by Ori Avtalion Fix error checks and leaks in setobject.c (2006-09-05) CLOSED http://python.org/sf/1552731 reopened by gbrandl Fix error checks and leaks in setobject.c (2006-09-05) CLOSED http://python.org/sf/1552731 opened by Raymond Hettinger Unicode Imports (2006-09-05) http://python.org/sf/1552880 opened by Kristján Valur Fix inspect.py 2.5 slowdown (2006-09-06) CLOSED http://python.org/sf/1553314 opened by Nick Coghlan locale.getdefaultlocale() bug when _locale is missing (2006-09-06) http://python.org/sf/1553427 opened by STINNER Victor UserDict New Style (2006-09-09) http://python.org/sf/1555097 opened by Indy Performance enhancements. (2006-09-09) http://python.org/sf/1555098 opened by Indy Patches Closed __ Fix decimal context management for 2.5 (2006-09-02) http://python.org/sf/1550886 closed by ncoghlan Fix for rpartition() end-case (2006-09-02) http://python.org/sf/1551339 closed by nnorwitz Updated spec file for 2.5 release. (2006-09-02) http://python.org/sf/1551340 closed by nnorwitz eval docstring typo (2006-09-04) http://python.org/sf/1552093 closed by nnorwitz crash in dict_equal (2006-08-24) http://python.org/sf/1546288 closed by nnorwitz Patches for OpenBSD 4.0 (2006-08-15) http://python.org/sf/1540470 closed by nnorwitz Fix error checks and leaks in setobject.c (2006-09-05) http://python.org/sf/1552731 closed by rhettinger Fix error checks and leaks in setobject.c (2006-09-05) http://python.org/sf/1552731 closed by gbrandl make exec a function (2006-09-01) http://python.org/sf/1550800 closed by gbrandl Ellipsis literal "..." (2006-09-01) http://python.org/sf/1550786 closed by gbrandl Fix inspect.py 2.5 slowdown (2006-09-06) http://python.org/sf/1553314 closed by ncoghlan New / Reopened Bugs ___ from . import bug (2006-09-02) CLOSED http://python.org/sf/1550938 opened by ganges master random.choice(setinstance) fails (2006-09-02) CLOSED http://python.org/sf/1551113 opened by Alan Build of 2.4.3 on fedora core 5 fails to find asm/msr.h (2006-09-02) http://python.org/sf/1551238 opened by George R. Goffe tiny bug in win32_urandom (2006-09-03) CLOSED http://python.org/sf/1551427 opened by Rocco Matano __unicode__ breaks for exception class objects (2006-09-03) http://python.org/sf/1551432 opened by Marcin 'Qrczak' Kowalczyk Wrong link to unicode database (2006-09-03) CLOSED http://python.org/sf/1551669 opened by Yevgen Muntyan unpack list of singleton tuples not unpacking (2006-07-11) CLOSED http://python.org/sf/1520864 reopened by gbrandl UnixCCompiler runtime_library_dir uses -R instead of -Wl,-R (2006-09-04) CLOSED http://python.org/sf/1552304 opened by TFKyle PEP 290 <-> normal docu... (2006-09-05) CLOSED http://python.org/sf/1552618 opened by Jens Diemer Python polls unecessarily every 0.1 when interactive (2006-09-05) http://python.org/sf/1552726 opened by Richard Boulton Python polls unnecessarily every 0.1 second when interactive (2006-09-05) http://python.org/sf/1552726 reopened by akuchling subprocess.Popen(cmd, stdout=sys.stdout) fails (2006-07-31) CLOSED http://python.org/sf/1531862 reopened by nnorwitz ConfigParser converts option names to lower case on set() (2006-09-05) CLOSED http://python.org/sf/1552892 opened by daniel Pythonw doesn't get rebuilt if version number changes (2006-09-05) http://python.org/sf/1552935 opened by Jack Jansen python 2.5 install can't find tcl/tk in /usr/lib64 (2006-09-06) http://python.org/sf/1553166 opened by David Strozzi logging.handlers.RotatingFileHandler - inconsistent mode (2006-09-06) http://python.org/sf/1553496 opened by Walker Hale datetime.datetime.now() mangles tzinfo (2006-09-06) http://python.org/sf/1553577 opened by Skip Montanaro Class instance apparently not destructed when expected (2006-09-06) http://python.org/sf/1553819 opened by Peter Donis PyOS_InputHook() and related API funcs. not d
Re: [Python-Dev] Signals, threads, blocking C functions
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 the main thread is blocked in GTK and can't check the flag. Nick Maclaren wrote: ...lots of reasons why you can't do anything reliably from within a signal handler... As far as I understand it, what could work is this: -PyGTK registrers a callback. -Pythons signal handler does not change at all. -All threads that run in the Python interpreter occasionally check the flag which the signal handler sets, like the main thread does nowadays. If it is set, the thread calls PyGTKs callback. It does not do anything else with the signal. -PyGTKs callback wakes up the main thread, which actually handles the signal just like it does now. PyGTKs callback could be called from any thread, but it would be called in a normal context, not in a signal handler. As the signal handler does not change, the risk of breaking anything or causing chaos is as large/small as it is under the current scheme. However, PyGTKs problem does get solved, as long as there is _a_ thread that returns to the interpreter within some timeframe. It seems plausible that this will happen. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Signals, threads, blocking C functions
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 bugs). However, we already have a signal handler, so we should already be exposed to the random crashes/corruption. If we're going to rely on signal handling being correct then I think we should also rely on write() being correct. Note that I'm not suggesting an API that allows arbitrary signal handlers, but rather one that calls write() on an array of prepared file descriptors (ignoring errors). 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 handlers in another thread though. Maybe have to rip the atomic read/write stuff out of the Linux sources to ensure it's *always* defined behavior. Looking into the existing signalmodule.c, I see no attempts to ensure atomic access to the Handlers data structure. Is the current code broken, at least on non-x86 platforms? -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Signals, threads, blocking C functions
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 handlers in another thread though. > Maybe have to rip the atomic read/write stuff out of the Linux > sources to ensure it's *always* defined behavior. Doh, except that's exactly what sig_atomic_t is for. Ah well, can't win them all. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode Imports
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 them). It was never extended to support Unicode strings. > That other PEP e That other PEP being PEP 302. That said, Unicode strings *are* permitted on sys.path - the import system will automatically encode them to an 8-bit string using the default filesystem encoding as part of the import process. This works fine on Unix systems that use UTF-8 encoded strings to handle Unicode paths at the C API level, but is screwed on Windows because the default mbcs filesystem encoding can't handle the full range of possible Unicode path names (such as the Chinese directories that originally gave Kristján grief). To get Unicode path names to work on Windows, you have to use the Windows-specific wide character API instead of the normal C API, and the import machinery doesn't do that. So this is taking something that *already works properly on POSIX systems* and making it work on Windows as well. >> 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. > > I'm not so sure it should. It *is* a new feature: it makes applications > possible which aren't possible today, and the documentation does not > ever suggest that these applications should have been possible. In fact, > it is common knowledge that this currently isn't supported. It should already work fine on POSIX filesystems that use the default filesystem encoding for path names. As far as I am aware, it is only Windows where it doesn't work. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
