Re: [Python-Dev] PyDict_Get/SetItem and dict subclasses

On Nov 6, 2011, at 1:26 PM, Martin v. Löwis wrote: > Am 06.11.2011 17:39, schrieb Antoine Pitrou: >> Le 05/11/2011 17:34, Éric Araujo a écrit : >>> Hi Victor, >>> PyDict_GetItem() and PyDict_SetItem() don't call __getitem__ and __setitem__ for dict subclasses. Is there a reason fo

Re: [Python-Dev] PyDict_Get/SetItem and dict subclasses

Am 06.11.2011 17:39, schrieb Antoine Pitrou: > Le 05/11/2011 17:34, Éric Araujo a écrit : >> Hi Victor, >> >>> PyDict_GetItem() and PyDict_SetItem() don't call __getitem__ and >>> __setitem__ >>> for dict subclasses. Is there a reason for that? >> >> http://bugs.python.org/issue10977 “Currently, th

Re: [Python-Dev] PEP 382 specification and implementation complete

Am 06.11.2011 16:38, schrieb PJ Eby: > On Sun, Nov 6, 2011 at 7:29 AM, Nick Coghlan > wrote: > > I think this was based on the assumption that *existing* namespace > package approaches would break under the new scheme. Since that is not > the case, I suspect

Re: [Python-Dev] PEP 382 specification and implementation complete

> I think this was based on the assumption that *existing* namespace > package approaches would break under the new scheme. Since that is not > the case, I suspect those previous objections were overstated (and all > packaging related code manages to cope well enough with modules where > the file n

Re: [Python-Dev] None as slice params to list.index() and tuple.index()

On Nov 6, 2011, at 12:49 AM, Petri Lehtinen wrote: > Currently, find(), rfind(), index(), rindex(), count(), startswith() > and endswith() of str, bytes and bytearray accept None. Should > list.index() and tuple.index() accept it, too? The string methods accept None as a historical artifact of b

Re: [Python-Dev] [Python-checkins] cpython: Fix #13327. Remove the need for an explicit None as the second argument to

On Sun, Nov 6, 2011 at 13:46, Benjamin Peterson wrote: > 2011/11/6 brian.curtin : >> - >> -    if (!PyArg_ParseTuple(args, "O&O:utime", >> +    PyObject* arg = NULL; > > You could set arg = Py_None here. >> + >> +    if (!PyArg_ParseTuple(args, "O&|O:utime", >>                           PyUnicode_

Re: [Python-Dev] [Python-checkins] cpython: Fix #13327. Remove the need for an explicit None as the second argument to

2011/11/6 brian.curtin : > - > -    if (!PyArg_ParseTuple(args, "O&O:utime", > +    PyObject* arg = NULL; You could set arg = Py_None here. > + > +    if (!PyArg_ParseTuple(args, "O&|O:utime", >                           PyUnicode_FSConverter, &opath, &arg)) >         return NULL; >     path = PyB

Re: [Python-Dev] None as slice params to list.index() and tuple.index()

On Mon, Nov 7, 2011 at 8:16 AM, Antoine Pitrou wrote: > Either that or fix the error message. I can't find much benefit in > accepting None, that said (nor in refusing it). Its very convenient when working with slices to not have to special case the end points. +1 on accepting None, FWIW. -Rob _

Re: [Python-Dev] None as slice params to list.index() and tuple.index()

On Sun, 6 Nov 2011 09:49:27 +0200 Petri Lehtinen wrote: > list.index() and list.tuple() don't currently accept None as slice > parameters, as reported in http://bugs.python.org/issue13340. For > example: > > >>> [1, 2, 3].index(2, None, None) > Traceback (most recent call last): > File "", line

Re: [Python-Dev] Why does _PyUnicode_FromId return a new reference?

Le 06/11/2011 08:08, "Martin v. Löwis" a écrit : Am 05.11.2011 23:26, schrieb Antoine Pitrou: Given it returns an eternal object, and it's almost always used temporarily (for attribute lookup, string joining, etc.), it would seem more practical for it to return a borrowed reference. For purit

Re: [Python-Dev] PyDict_Get/SetItem and dict subclasses

Le 05/11/2011 17:34, Éric Araujo a écrit : Hi Victor, PyDict_GetItem() and PyDict_SetItem() don't call __getitem__ and __setitem__ for dict subclasses. Is there a reason for that? http://bugs.python.org/issue10977 “Currently, the concrete object C API bypasses any methods defined on subclasse

Re: [Python-Dev] PEP 382 specification and implementation complete

On Sun, Nov 6, 2011 at 7:29 AM, Nick Coghlan wrote: > I think this was based on the assumption that *existing* namespace > package approaches would break under the new scheme. Since that is not > the case, I suspect those previous objections were overstated (and all > packaging related code manag

Re: [Python-Dev] genious hack in python

Write Oleg, If there is a better way to implemant this? sure. But the idea is still good. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python

Re: [Python-Dev] PEP 382 specification and implementation complete

On Sun, Nov 6, 2011 at 6:10 PM, "Martin v. Löwis" wrote: > I had announced this to import-sig already; now python-dev. > > I have now written an implementation of PEP 382, and fixed some details > of the PEP in the process. The implementation is available at > > http://hg.python.org/features/pep-3

[Python-Dev] None as slice params to list.index() and tuple.index()

list.index() and list.tuple() don't currently accept None as slice parameters, as reported in http://bugs.python.org/issue13340. For example: >>> [1, 2, 3].index(2, None, None) Traceback (most recent call last): File "", line 1, in TypeError: slice indices must be integers or None or have an __

[Python-Dev] PEP 382 specification and implementation complete

I had announced this to import-sig already; now python-dev. I have now written an implementation of PEP 382, and fixed some details of the PEP in the process. The implementation is available at http://hg.python.org/features/pep-382-2/ With this PEP, a Python package P can consist of either a P/_

Re: [Python-Dev] Packaging and binary distributions

> I agree in principle, but one thing you get with setup.cfg which seems harder > to > achieve with MSI is the use of Python to do things at installation time. For > example, with setup.cfg hooks, you can use ctypes to make Windows API calls at > installation time to decide where to put things. Wh

Re: [Python-Dev] Why does _PyUnicode_FromId return a new reference?

Am 05.11.2011 23:26, schrieb Antoine Pitrou: > > Given it returns an eternal object, and it's almost always used > temporarily (for attribute lookup, string joining, etc.), it would seem > more practical for it to return a borrowed reference. For purity reasons: all PyUnicode_From* functions retu