Re: [Python-Dev] libpython added to ABI tracker
Hi, Victor Stinner wrote: Hi, 2014-03-28 9:31 GMT+01:00 Andrey Ponomarenko : The libpython library has been added to the ABI tracker: http://upstream-tracker.org/versions/python.html The page lists library versions and changes in API/ABI. Nice! By the way, would it be possible to add a second page for the stable ABI of Python? Victor The public libpython API changes will be tracked here: http://upstream-tracker.org/versions/python_public_api.html For now I've excluded only symbols starting with an underscore. What other symbols should be excluded? Thanks. -- Andrey Ponomarenko, NTC IT ROSA. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libpython added to ABI tracker
2014-03-31 13:38 GMT+02:00 Andrey Ponomarenko : > The public libpython API changes will be tracked here: > http://upstream-tracker.org/versions/python_public_api.html > > For now I've excluded only symbols starting with an underscore. What other > symbols should be excluded? It's not a matter of underscore. You should define Py_LIMITED_API to 0x0302 to test the stable ABI of Python 3.2. http://docs.python.org/dev/c-api/stable.html Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Treating tokenize.Untokenizer as private
On Tue, Feb 18, 2014 at 2:09 PM, Terry Reedy wrote: > I am working through the multiple bugs afflicting tokenize.untokenize, which > is described in the tokenize doc and has an even longer docstring. While the > function could be implemented as one 70-line function, it happens to be > implemented as a 4-line wrapper for a completely undocumented (Untokenizer > class with 4 methods. (It is unmentioned in the doc and there are currently > no docstrings.) > > I view the class as a private implementation detail and would like to treat > it as such, and perhaps even rename it _Untokenizer to make that clear. The > issue arises in #9974. It appears that a fix may require the addition of an > instance attribute or .add_whitespace parameter. If there is objection to > treating the whole class as private, I would at least like to treat > add_whitespace as the private helper that it is. There is no reason to call > it directly except for testing. Otherwise, it could just as well have been > left inline at the one call site. Is this still an open question, Terry? -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making proxy types easier to write and maintain
On Thu, Mar 20, 2014 at 11:56 AM, Larry Hastings wrote: > On 03/20/2014 12:49 AM, Nick Coghlan wrote: > > So long as Graham's willing to go along with it, he doesn't have to to > be the one to write the PEP. > > > PEP? Why does it need a PEP? I didn't think it'd even be a new top-level > library module, it'd be an addition / additions to functools. Would it make sense to have a new module named classtools rather than add more class-related stuff to functools. For instance, total_ordering() is the sort of thing I would expect to find in classtools rather than functools. -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making proxy types easier to write and maintain
On Wed, Mar 19, 2014 at 12:46 PM, Antoine Pitrou wrote: > In http://bugs.python.org/issue19359#msg213530 I proposed to introduce a > "proxy > protocol" (__proxy__ / tp_proxy) that would be used as a fallback by > _PyObject_LookupSpecial to fetch the lookup target, i.e.: > > def _PyObject_LookupSpecial(obj, name): > tp = type(obj) > try: > return getattr(tp, name) > except AttributeError: > return getattr(tp.tp_proxy(), name) > > What do you think? Regardless of the attr lookup in the interpreter, it would be nice to have a standardized explicit __proxied__ attribute on proxy objects (similar to __wrapped__). -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Negative timedelta strings
On Fri, Mar 28, 2014 at 2:52 PM, Fred Drake wrote: > On Fri, Mar 28, 2014 at 5:19 PM, Greg Ewing > wrote: > > ISO 8601 doesn't seem to define a representation for > > negative durations, though, so it wouldn't solve the > > original problem. > > Aside from the horribleness of the ISO 8601 notation for a duration, it's > best not to confuse the notions of duration and delta. Notionally, a delta > contains more information than a duration. and less -- really it's different. A duration would be really useful actually, for things like "next month", etc,. IIRC, mxDateTime has something for this, but it's NOT the same as a timedelta. timedelta appears to be analogous to ISO 8601's " time interval", which requires 1. Start and end, such as "2007-03-01T13:00:00Z/2008-05-11T15:30:00Z" 2. Start and duration, such as "2007-03-01T13:00:00Z/P1Y2M10DT2H30M" 3. Duration and end, such as "P1Y2M10DT2H30M/2008-05-11T15:30:00Z" 4. Duration only, such as "P1Y2M10DT2H30M", with additional context information http://en.wikipedia.org/wiki/ISO_8601#Time_intervals I don't think there is or should be a any direct mapping from timedelta to ISO duration. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Treating tokenize.Untokenizer as private
On 3/31/2014 2:30 PM, Eric Snow wrote: On Tue, Feb 18, 2014 at 2:09 PM, Terry Reedy wrote: I am working through the multiple bugs afflicting tokenize.untokenize, which is described in the tokenize doc and has an even longer docstring. While the function could be implemented as one 70-line function, it happens to be implemented as a 4-line wrapper for a completely undocumented (Untokenizer class with 4 methods. (It is unmentioned in the doc and there are currently no docstrings.) I view the class as a private implementation detail and would like to treat it as such, and perhaps even rename it _Untokenizer to make that clear. The issue arises in #9974. It appears that a fix may require the addition of an instance attribute or .add_whitespace parameter. If there is objection to treating the whole class as private, I would at least like to treat add_whitespace as the private helper that it is. There is no reason to call it directly except for testing. Otherwise, it could just as well have been left inline at the one call site. Is this still an open question, Terry? It is not currently for #9974 because after consideration of two proposed patches (one part of another issue), I decided that the conditions being guarded against either could not occur or could be checked in the caller, so that no api change was needed. However, I believe the fix for another bug, http://bugs.python.org/issue20387 will require copying the code that correctly formats indents in the old compat method to the newer method, which incorrectly assumes that indents are spaces only. I might end up wishing I could refactor the code. So this may well become a live issue again, and I would still like to know what people think. How do we do code searches (as for use of "Untokenize") these days? -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Treating tokenize.Untokenizer as private
On Feb 18, 2014, at 1:09 PM, Terry Reedy wrote: > While the function could be implemented as one 70-line function, it happens > to be implemented as a 4-line wrapper for a completely undocumented > (Untokenizer class with 4 methods. (It is unmentioned in the doc and there > are currently no docstrings.) > > I view the class as a private implementation detail and would like to treat > it as such, and perhaps even rename it _Untokenizer to make that clear. Yes, that would be reasonable. Raymond___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Negative timedelta strings
On 2014-03-28, at 17:19 , Skip Montanaro wrote: > (*) As an aside (that is, this belongs in a separate thread if you > want to discuss it), in my opinion, attempting to support ISO 8601 > formatting is pointless without the presence of an anchor datetime. > Otherwise how would you know how far back "five months" or "seven > years" was? dateutil's relativedelta keeps the notion "abstract" until it's combined with an anchor datetime, at which point it's reified to a real duration[0]. > If that's the case, then you might as well add the timedelta to your anchor datetime and just use datetime.strftime(). You can't even express "next month" with timedelta, since the duration of a month is not a fixed number of seconds. [0] well not exactly, a relativedelta really defines a processing pipeline on its anchor date, which allows for fun stuff like "saturday the third week of next month". ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.sortedtree
vne On Mon, Mar 31, 2014 at 2:01 PM, Daniel Stutzbach wrote: > On Fri, Mar 28, 2014 at 6:45 PM, Dan Stromberg wrote: >> >> In my testing blist.sorteddict was dead last for random keys, and >> wasn't last but was still significantly underperforming for sequential >> keys (outperforming only binary tree and scapegoat tree, behind all >> others): >> >> >> http://stromberg.dnsalias.org/~strombrg/python-tree-and-heap-comparison/2014-03-18/ > > > Could you post the source code for your test tools, so that I can reproduce > them locally and understand the results better? > > I think I'm confused about what you're trying to measure. It looks like the > tests perform get and set operations, neither of which required a sorted > dict. Wouldn't a good comparison of sorted dict types include at least one > operation that relies on the sorted property? Possibly I've misunderstood > how your tests work. The code is at http://stromberg.dnsalias.org/svn/python-tree-and-heap-comparison/trunk/ You're right, I'm not comparing find_min, find_max, generate_in_order or generate_reverse_order. The first two tend to be the same as find_arbitrary. I've been thinking about trying to import some C extension module trees, and just ignoring them if they fail to import. But I haven't. Trunk only compares pure python implementations - even for treap, which has a cython version. I tossed my changes after checking blist. Trunk does operations/second. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Treating tokenize.Untokenizer as private
On Mon, Mar 31, 2014 at 1:45 PM, Terry Reedy wrote: > On 3/31/2014 2:30 PM, Eric Snow wrote: >> Is this still an open question, Terry? > > > It is not currently for #9974 because after consideration of two proposed > patches (one part of another issue), I decided that the conditions being > guarded against either could not occur or could be checked in the caller, so > that no api change was needed. > > However, I believe the fix for another bug, > http://bugs.python.org/issue20387 > will require copying the code that correctly formats indents in the old > compat method to the newer method, which incorrectly assumes that indents > are spaces only. I might end up wishing I could refactor the code. So this > may well become a live issue again, and I would still like to know what > people think. It simply depends on the utility of customizing the default behavior there. I seem to remember subclassing Untokenize for something in a personal project, but I expect doing so wasn't necessary. > > How do we do code searches (as for use of "Untokenize") these days? I believe there was one for which Guido was advocating, but I don't recall it's name. Such a search would be useful though. -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libpython added to ABI tracker
On 1 Apr 2014 01:38, "Victor Stinner" wrote: > > 2014-03-31 13:38 GMT+02:00 Andrey Ponomarenko : > > The public libpython API changes will be tracked here: > > http://upstream-tracker.org/versions/python_public_api.html > > > > For now I've excluded only symbols starting with an underscore. What other > > symbols should be excluded? > > It's not a matter of underscore. You should define Py_LIMITED_API to > 0x0302 to test the stable ABI of Python 3.2. > > http://docs.python.org/dev/c-api/stable.html Well, we have more than one ABI, with different guarantees. The "no leading underscore" one we promise not to change in maintenance releases, but we only preserve *API* compatibility in feature releases (mostly due to structs changing size). The "stable ABI" (aka Py_LIMITED_API) is the one where we promise to hide all the memory layout details and treat it as "additive only" so that binaries built with previous releases keep working. That should never break ABI compatibility, and only get new additions if the macro definition is bumped up to match the newer release. Cheers, Nick. P.S. I understand it was Anatoly that put the process in motion to get this set up. Thanks for doing that Anatoly, it's a genuinely good idea. > > Victor > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding a readinto1 method to BufferedReader
Hello, The BufferedReader (and BufferedRWPair) classes both have a read1() method in addition to the regular read() method to bypass the internal buffer. This is quite useful if you need to do some buffered reading (e.g. to parse a header) followed by a lot of bulk data that you want to process as it streams in. However, the readinto() method does not have a corresponding readinto1() method. I would like to add this method. I have proposed a patch in http://bugs.python.org/issue20578. Are there any comments, objections, encouragements...? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
