Re: [Python-Dev] [Python-checkins] cpython: Issue #12981: rewrite multiprocessing_{sendfd, recvfd} in Python.
2011/9/26 Charles-François Natali : > I'm not sure I understand what you mean. You actually understood what I meant, I was just wrong because I misread the conditional. Nothing to see here, please move along :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] PEP 393 close to pronouncement
Martin has asked me to pronounce on PEP 393, after he's updated it in response to various feedback (including mine :-). I'm currently looking very favorable on it, but I thought I'd give folks here one more chance to bring up showstoppers. So, if you have the time, please review PEP 393 and/or play with the code (the repo is linked from the PEP's References section now). Please limit your feedback to show-stopping issues; we're past the stage of bikeshedding here. It's Good Enough (TM) and we'll have to rest of the 3.3 release cycle to improve incrementally. But we need to get to the point where the code can be committed to the 3.3 branch. In a few days I'll pronounce. -- --Guido van Rossum (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] range objects in 3.x
On Sat, 24 Sep 2011 08:13:11 -0700, Guido van Rossum wrote: > I expect that to implement a version worthy of the stdlib math module, > i.e. that computes values that are correct within 0.5ULP under all > circumstances (e.g. lots of steps, or an end point close to the end of > the floating point range) we'd need a numerical wizard like Mark > Dickinson or Tim Peters (retired). Or maybe we could just borrow numpy's > code. +1 to using the numpy api, having continuity of API between the two would be great (people work interactively with 'from numpy import *', so having the linspace() call continue to work identically would be a bonus). License-wise there shouldn't be major issues in using the numpy code, as numpy is all BSD. Hopefully if there are any, the numpy community can help out. And now that Mark Dickinson is at Enthought (http:// enthought.com/company/developers.php) where Travis Oliphant --numpy author-- works, I'm sure the process of ironing out any implementation/api quirks could be handled easily. Cheers, f ___ 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] PEP 393 close to pronouncement
Hi, Le lundi 26 septembre 2011 23:00:06, Guido van Rossum a écrit : > So, if you have the time, please review PEP 393 and/or play with the > code (the repo is linked from the PEP's References section now). I played with the code. The full test suite pass on Linux, FreeBSD and Windows. On Windows, there is just one failure in test_configparser, I didn't investigate it yet. I like the new API: a classic loop on the string length, and a macro to read the nth character. The backward compatibility is fully transparent and is already well tested because some modules still use the legacy API. It's quite easy to move from the legacy API to the new API. It's just boring, but it's almost done in the core (unicodeobject.c, but also some modules like _io). Since the introduction of PyASCIIObject, the PEP 393 is really good in memory footprint, especially for ASCII-only strings. In Python, you manipulate a lot of ASCII strings. PEP === It's not clear what is deprecated. It would help to have a full list of the deprecated functions/macros. Sometimes Martin wrote PyUnicode_Ready, sometimes PyUnicode_READY. It's confusing. Typo: PyUnicode_FAST_READY => PyUnicode_READY. "PyUnicode_WRITE_CHAR" is not listed in the New API section. Typo in "PyUnicode_CONVERT_BYTES(from_type, tp_type, begin, end, to)": tp_type => to_type. "PyUnicode_Chr(ch)": Why introducing a new function? PyUnicode_FromOrdinal was not enough? "GDB Debugging Hooks" It's not done yet. "None of the functions in this PEP become part of the stable ABI (PEP 384)." Why? Some functions don't depend on the internal representation, like PyUnicode_Substring or PyUnicode_FindChar. Typo: "In order to port modules to the new API, try to eliminate the use of these API elements: ... PyUnicode_GET_LENGTH ..." PyUnicode_GET_LENGTH is part of the new API. I suppose that you mean PyUnicode_GET_SIZE. Victor ___ 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] PEP 393 close to pronouncement
On Tue, 2011-09-27 at 00:19 +0200, Victor Stinner wrote: > Hi, > > Le lundi 26 septembre 2011 23:00:06, Guido van Rossum a écrit : > > So, if you have the time, please review PEP 393 and/or play with the > > code (the repo is linked from the PEP's References section now). > > PEP > === > "GDB Debugging Hooks" It's not done yet. I can do these if need be, but IIRC you (Victor) said on #python-dev that you were already working on them. ___ 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] range objects in 3.x
Fernando Perez wrote: On Sat, 24 Sep 2011 08:13:11 -0700, Guido van Rossum wrote: I expect that to implement a version worthy of the stdlib math module, i.e. that computes values that are correct within 0.5ULP under all circumstances (e.g. lots of steps, or an end point close to the end of the floating point range) we'd need a numerical wizard like Mark Dickinson or Tim Peters (retired). Or maybe we could just borrow numpy's code. +1 to using the numpy api, having continuity of API between the two would be great (people work interactively with 'from numpy import *', so having the linspace() call continue to work identically would be a bonus). The audience for numpy is a small minority of Python users, and they tend to be more sophisticated. I'm sure they can cope with two functions with different APIs While continuity of API might be a good thing, we shouldn't accept a poor API just for the sake of continuity. I have some criticisms of the linspace API. numpy.linspace(start, stop, num=50, endpoint=True, retstep=False) http://docs.scipy.org/doc/numpy/reference/generated/numpy.linspace.html * It returns a sequence, which is appropriate for numpy but in standard Python it should return an iterator or something like a range object. * Why does num have a default of 50? That seems to be an arbitrary choice. * It arbitrarily singles out the end point for special treatment. When integrating, it is just as common for the first point to be singular as the end point, and therefore needing to be excluded. * If you exclude the end point, the stepsize, and hence the values returned, change: >>> linspace(1, 2, 4) array([ 1., 1., 1.6667, 2.]) >>> linspace(1, 2, 4, endpoint=False) array([ 1. , 1.25, 1.5 , 1.75]) This surprises me. I expect that excluding the end point will just exclude the end point, i.e. return one fewer point. That is, I expect num to count the number of subdivisions, not the number of points. * The retstep argument changes the return signature from => array to => (array, number). I think that's a pretty ugly thing to do. If linspace returned a special iterator object, the step size could be exposed as an attribute. * I'm not sure that start/end/count is a better API than start/step/count. * This one is pure bike-shedding: I don't like the name linspace. We've gone 20 years without a floating point range in Python. I think we should give people a bit of time to pay around with alternative APIs rather than just grab the first one that comes along. -- Steven ___ 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] range objects in 3.x
On Mon, Sep 26, 2011 at 6:25 PM, Steven D'Aprano wrote: > While continuity of API might be a good thing, we shouldn't accept a poor > API just for the sake of continuity. I have some criticisms of the linspace > API. [...] > * I'm not sure that start/end/count is a better API than start/step/count. On this particular one, I think start/end/count *is* better, because in the most common use case the start and end points are given, and the step is somewhat of an afterthought (e.g. how many integration steps, or how many points in the chart). I also keep thinking that numerically, if start and end are given exactly, we should be able to compute the intermediate points within 0.5ULP, whereas it would seem that given start and step our computation for end may be considerably off, if the count is high. Or, maybe what I'm trying to say is, if the user has start/end/count but the API wants start/step/count, after computing step = (end-start) / count, the value of start + count*step might not quite equal to end; whereas if the user has start/step/count but the API wants start/end/count I think there's nothing wrong with computing end = start + step*count. -- --Guido van Rossum (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] range objects in 3.x
Guido van Rossum wrote: Or, maybe what I'm trying to say is, if the user has start/end/count but the API wants start/step/count, after computing step = (end-start) / count, the value of start + count*step might not quite equal to end; whereas if the user has start/step/count but the API wants start/end/count I think there's nothing wrong with computing end = start + step*count. +1, that makes sense to me. And I don't like "linspace" either. Something more self explanatory such as "subdivide" or "interpolate" might be better. -- Greg ___ 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] PEP 393 close to pronouncement
>> "GDB Debugging Hooks" It's not done yet. > I can do these if need be, but IIRC you (Victor) said on #python-dev > that you were already working on them. I already changed it for an earlier version of the PEP. It still needs to sort out the various compact representations. I could do them as well, so don't worry. 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
