Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?
On 25 January 2014 17:44, Nick Coghlan ncogh...@gmail.com wrote: On 25 January 2014 01:07, Larry Hastings la...@hastings.org wrote: c) Functions that accept an 'int' when they mean 'boolean' (aka the ints instead of bools problem) Solution: 1) Use bool. 2) Use int, and I'll go relax Argument Clinic so they can use bool values as defaults for int parameters. If the temptation is to use True or False as the default, then I think that's a clear argument that these should be accepting bool. However, expanding the accepted types is also clearly a new feature that would need a versionchanged in the docs for all affected functions, so I think these changes also belong in the conversion implies semantic changes, so leave until 3.5 category. I changed my mind (slightly) on this one. For 3.4, we can go with converting the current semantics (i.e. using i), and tweaking argument clinic to all bool defaults for integers. That allows the introspection to be added sensibly, without changing the semantics of the interface. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?
On 25 January 2014 19:20, Nick Coghlan ncogh...@gmail.com wrote: On 25 January 2014 17:44, Nick Coghlan ncogh...@gmail.com wrote: On 25 January 2014 01:07, Larry Hastings la...@hastings.org wrote: c) Functions that accept an 'int' when they mean 'boolean' (aka the ints instead of bools problem) Solution: 1) Use bool. 2) Use int, and I'll go relax Argument Clinic so they can use bool values as defaults for int parameters. If the temptation is to use True or False as the default, then I think that's a clear argument that these should be accepting bool. However, expanding the accepted types is also clearly a new feature that would need a versionchanged in the docs for all affected functions, so I think these changes also belong in the conversion implies semantic changes, so leave until 3.5 category. I changed my mind (slightly) on this one. For 3.4, we can go with converting the current semantics (i.e. using i), and tweaking argument clinic to all bool defaults for integers. allow bool defaults, rather. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?
Nick Coghlan, 25.01.2014 10:20: On 25 January 2014 17:44, Nick Coghlan wrote: On 25 January 2014 01:07, Larry Hastings wrote: c) Functions that accept an 'int' when they mean 'boolean' (aka the ints instead of bools problem) Solution: 1) Use bool. 2) Use int, and I'll go relax Argument Clinic so they can use bool values as defaults for int parameters. If the temptation is to use True or False as the default, then I think that's a clear argument that these should be accepting bool. However, expanding the accepted types is also clearly a new feature that would need a versionchanged in the docs for all affected functions, so I think these changes also belong in the conversion implies semantic changes, so leave until 3.5 category. I changed my mind (slightly) on this one. For 3.4, we can go with converting the current semantics (i.e. using i), and tweaking argument clinic to all[ow] bool defaults for integers. That allows the introspection to be added sensibly, without changing the semantics of the interface. FWIW, Cython knows a type called bint that is identical to a C int except that it automatically coerces to and from a Python boolean value (using truth testing). Seems to match the use case of the p that was added to CPython's arg parsing now. Given that p hasn't been around for all that long (and that Python didn't even have a bool type in its early days), it's clear why the existing code misused i in so many places over the last decades. I otherwise agree with Nick's comments above. It's sad that this can't just be fixed at the interface level, though. Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Quick poll: should help() show bound arguments?
Larry Hastings wrote: inspect.signature gets this right: import inspect str(inspect.signature(c.foo)) '(a)' Not always. : Python 3.4.0b2+ (default:32f9e0ae23f7, Jan 18 2014, 13:56:31) : [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin : Type help, copyright, credits or license for more information. : import inspect : class C1: : ... def f(*args, **kwargs): pass : ... : c = C1() : c.f() : str(inspect.signature(c.f)) : '(**kwargs)' Not to mention: class C2: def g(**kwargs): pass It doesn't really make sense - calling C2().g is guaranteed to fail - but it's legal Python. I'm not saying you can't special-case a few things and fix this, but still, -1/B. I like explicit self. regards, Anders ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New policies for the Derby -- please read!
1) New policy for what can and cannot be converted during the Derby First, let me apologize for only figuring this out now. The Derby has been a learning process, discovering things that Argument Clinic didn't handle. And there were a lot of funny edge cases that we weren't going to discover until we tried doing the conversion. And to be honest I was pushing harder than I should have. *ahem* The new policy for conversion work for Python 3.4: We may only convert functions that have signatures that we can represent 100% accurately in an inspect.Signature object. IF the function has a default value that can't be represented in Python (e.g. NULL), but we can find a value in Python that behaves identically to not passing in that parameter (e.g. _sha1.sha1(b'') == _sha1.sha1()), then we may convert that function using that clever default value (e.g. string: object(c_default='NULL') = b'' ). IF the function has parameters with default values that are dynamic or cannot be represented accurately in Python, it cannot be converted without changing its semantics. So it cannot be converted for 3.4. IF the function *requires* optional groups (as in, the original function used switch(PyTuple_GET_SIZE(args)) and multiple calls to PyArg_ParseTuple()), then it's permissible to convert it for 3.4, but they are low priority. Such functions have semantics that are so weird, we will have to modify inspect.Parameter to support them, and that will only happen in 3.5. However, I will ensure that they otherwise convert correctly for 3.4. (They won't actually generate signatures. They will however generate the first line of the docstring.) For 3.5, I expect we'll have more leeway in doing things like this should accept an int or None. But we should talk about that then. If you have patches outstanding that convert functions that shouldn't be converted for 3.4, please put them aside. We can almost certainly use them for 3.5. If any conversions have been committed that change the semantics of the function, someone will have to back them out. I'd appreciate it if the person who checked it in could do it. I expect to make a pass before rc1 to check all the conversions myself. (Which I hope will be quite time-consuming, as hopefully there will be lots of converted functions by then!) ___ 2) New recommendation for marking to-do functions If you examine a function and determine that it can't be converted to Argument Clinic right now, please add a comment to that effect. The comment should be one line, and contain a special marker so we can find it easily with searches. I nominate two different markers: AC 3.4 means It's okay to convert this function to Argument Clinic in 3.4, but it can't be converted right now because of a bug or missing feature in Argument Clinic. AC 3.5 means This function can't be converted to Argument Clinic in 3.4, it must wait for 3.5. I encourage you to add a little text saying why, like: /* AC 3.4: waiting for *args support */ /* AC 3.5: value parameter has default value of NULL */ ___ Finally, I've realized that right now there's no good way to stay abreast of what's new and changing in clinic.py. I check in a patch just about every day for clinic.py, and sometimes I don't remember to update the howto. The best way unfortunately is to read the output of hg log. If you have questions, you can email me directly at larry at hastings dot org, or you can find me in the #python-dev IRC channel. Thank you, everybody who's participating in the Derby, and again I'm sorry I didn't realize sooner this *had* to be the policy for 3.4. Hope to see your issues in the tracker, /arry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Quick poll: should help() show bound arguments?
On Sat, Jan 25, 2014 at 3:07 PM, Larry Hastings la...@hastings.org wrote: What should it be? A) pydoc and help() should not show bound parameters in the signature, like inspect.signature. B) pydoc and help() should show bound parameters in the signature, like inspect.getfullargspec. Vote for A. As far as I'm concerned, all these foo are equally callable and equally take one parameter named a: def foo1(a): pass class C: def foo(self, a): pass foo2=C().foo class C: def __call__(self, a): pass foo3=C() def two_arg(b, a): pass foo4=lambda a: two_arg(0, a) If I call them as fooN(), fooN(1), and fooN(1,2), the middle one works and the other two throw exceptions, ergo they are one-argument functions. The fact that two of them happen to be bound methods is an implementation detail; it's just a form of currying, which foo4 happens also to be (in that C.foo takes two args, C().foo takes one). ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deprecation policy
Hi, a couple of years ago I suggested to define and document our deprecation policy in this thread: https://mail.python.org/pipermail/python-dev/2011-October/114199.html I didn't receive many replies and eventually nothing was done. Lately the same issue came up on #python-dev and Larry and Nick suggested me to bring this up again. Nick also suggested to document our deprecation policy in PEP 5 (Guidelines for Language Evolution: http://www.python.org/dev/peps/pep-0005/ ). I'm including below the full text of the original email. Best Regards, Ezio Melotti --- Hi, our current deprecation policy is not so well defined (see e.g. [0]), and it seems to me that it's something like: 1) deprecate something and add a DeprecationWarning; 2) forget about it after a while; 3) wait a few versions until someone notices it; 4) actually remove it; I suggest to follow the following process: 1) deprecate something and add a DeprecationWarning; 2) decide how long the deprecation should last; 3) use the deprecated-remove[1] directive to document it; 4) add a test that fails after the update so that we remember to remove it[2]; Other related issues: PendingDeprecationWarnings: * AFAIK the difference between PDW and DW is that PDW are silenced by default; * now DW are silence by default too, so there are no differences; * I therefore suggest we stop using it, but we can leave it around[3] (other projects might be using it for something different); Deprecation Progression: Before, we more or less used to deprecated in release X and remove in X+1, or add a PDW in X, DW in X+1, and remove it in X+2. I suggest we drop this scheme and just use DW until X+N, where N is =1 and depends on what is being removed. We can decide to leave the DW for 2-3 versions before removing something widely used, or just deprecate in X and remove in X+1 for things that are less used. Porting from 2.x to 3.x: Some people will update directly from 2.7 to 3.2 or even later versions (3.3, 3.4, ...), without going through earlier 3.x versions. If something is deprecated on 3.2 but not in 2.7 and then is removed in 3.3, people updating from 2.7 to 3.3 won't see any warning, and this will make the porting even more difficult. I suggest that: * nothing that is available and not deprecated in 2.7, will be removed until 3.x (x needs to be defined); * possibly we start backporting warnings to 2.7 so that they are visible while running with -3; Documenting the deprecations: In order to advertise the deprecations, they should be documented: * in their doc, using the deprecated-removed directive (and possibly not the 'deprecated' one); * in the what's new, possibly listing everything that is currently deprecated, and when it will be removed; Django seems to do something similar[4]. (Another thing I would like is a different rending for deprecated functions. Some part of the docs have a deprecation warning on the top of the section and the single functions look normal if you miss that. Also while linking to a deprecated function it would be nice to have it rendered with a different color or something similar.) Testing the deprecations: Tests that fail when a new release is made and the version number is bumped should be added to make sure we don't forget to remove it. The test should have a related issue with a patch to remove the deprecated function and the test. Setting the priority of the issue to release blocker or deferred blocker can be done in addition/instead, but that works well only when N == 1 (the priority could be updated for every release though). The tests could be marked with an expected failure to give some time after the release to remove them. All the deprecation-related tests might be added to the same file, or left in the test file of their module. Where to add this: Once we agree about the process we should write it down somewhere. Possible candidates are: * PEP387: Backwards Compatibility Policy[5] (it has a few lines about this); * a new PEP; * the devguide; I think having it in a PEP would be good, the devguide can then link to it. Best Regards, Ezio Melotti [0]: http://bugs.python.org/issue13248 [1]: deprecated-removed doesn't seem to be documented in the documenting doc, but it was added here: http://hg.python.org/cpython/rev/03296316a892 [2]: see e.g. http://hg.python.org/cpython/file/default/Lib/unittest/test/test_case.py#l1187 [3]: we could also introduce a MetaDeprecationWarning and make PendingDeprecationWarning inherit from it so that it can be used to pending-deprecate itself. Once PendingDeprecationWarning is gone, the MetaDeprecationWarning will become useless and can then be used to meta-deprecate itself. [4]: https://docs.djangoproject.com/en/dev/internals/deprecation/ [5]: http://www.python.org/dev/peps/pep-0387/ ___ Python-Dev mailing list Python-Dev@python.org
Re: [Python-Dev] Quick poll: should help() show bound arguments?
On 01/25/2014 03:34 AM, Anders J. Munch wrote: Larry Hastings wrote: inspect.signature gets this right: import inspect str(inspect.signature(c.foo)) '(a)' Not always. : Python 3.4.0b2+ (default:32f9e0ae23f7, Jan 18 2014, 13:56:31) : [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin : Type help, copyright, credits or license for more information. : import inspect : class C1: : ... def f(*args, **kwargs): pass : ... : c = C1() : c.f() : str(inspect.signature(c.f)) : '(**kwargs)' File a bug, if there hasn't already been one filed. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Quick poll: should help() show bound arguments?
On Fri, 24 Jan 2014 20:07:43 -0800 Larry Hastings la...@hastings.org wrote: A) pydoc and help() should not show bound parameters in the signature, like inspect.signature. -1 from me. The problem is this will make help(c.foo) inconsistent with help(c) and help(C), and is bound to confuse newcomers. Speaking of which, I think asking for votes before all arguments have been made is counter-productive. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Quick poll: should help() show bound arguments?
On 01/25/2014 05:37 AM, Antoine Pitrou wrote: Speaking of which, I think asking for votes before all arguments have been made is counter-productive. Sorry, I didn't realize there was an established protocol for this. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Quick poll: should help() show bound arguments?
On Sat, 25 Jan 2014 05:42:58 -0800 Larry Hastings la...@hastings.org wrote: On 01/25/2014 05:37 AM, Antoine Pitrou wrote: Speaking of which, I think asking for votes before all arguments have been made is counter-productive. Sorry, I didn't realize there was an established protocol for this. No, the problem is that people then vote assuming you have done all the research and presented all arguments for and against, which you haven't. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?
On 25 January 2014 19:46, Stefan Behnel stefan...@behnel.de wrote: FWIW, Cython knows a type called bint that is identical to a C int except that it automatically coerces to and from a Python boolean value (using truth testing). Seems to match the use case of the p that was added to CPython's arg parsing now. Given that p hasn't been around for all that long (and that Python didn't even have a bool type in its early days), it's clear why the existing code misused i in so many places over the last decades. I otherwise agree with Nick's comments above. It's sad that this can't just be fixed at the interface level, though. We're building up a nice collection of edge cases to address in 3.5 - it's getting to the point where I'm starting to think we should create the 3.5 release PEP early so we can start making notes of things we've decided we would like to do but are too late for 3.4... Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New policies for the Derby -- please read!
On 25 January 2014 22:19, Larry Hastings la...@hastings.org wrote: 1) New policy for what can and cannot be converted during the Derby The new policy for conversion work for Python 3.4: We may only convert functions that have signatures that we can represent 100% accurately in an inspect.Signature object. +1. The builtin callables hit a few of these, and I think simply putting them aside for reconsideration post 3.4 release is our best option right now. I encourage you to add a little text saying why, like: /* AC 3.4: waiting for *args support */ So, here's a suggestion I know you're not going to like, but I think is still worth considering: how about postponing varargs support in Argument Clinic until 3.5? Such a decision is not without cost: at least min, max and print can't be made to support programmatic introspection without it, and having unittest.mock.auto_spec(print) work would be a nice demonstration of *why* we think the cost of switching from print-as-statement to print-as-function was worth it in terms of unifying it with the rest of the language. However, you've indicated that adding varargs support is going to take you quite a bit of work, so postponing it is an option definitely worth considering at this point in the release cycle. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New policies for the Derby -- please read!
On 01/25/2014 07:26 AM, Nick Coghlan wrote: However, you've indicated that adding varargs support is going to take you quite a bit of work, so postponing it is an option definitely worth considering at this point in the release cycle. It's worth considering. I'm estimating it's about 1.5 days' worth of work. Mainly because, at the same time, I need to teach Clinic to have separate namespaces for parser and impl functions. At the same time I was going to implement a frequently-requested feature, allowing the C variable storing an argument to have a different name than the actual Python parameter. And it could be one of those hey that was easier than I thought things. 1.5 days is kind of worst-case. So maybe the best thing would be to give it a half-day and see if it turned out to be easy. Of course, If we bring the Derby to a close now-ish (debate going on in python-committers right now!), then I'll definitely put it off until 3.5. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.rreplace
On Jan 24, 2014 9:13 PM, Nick Coghlan ncogh...@gmail.com wrote: On 25 January 2014 11:14, Steven D'Aprano st...@pearwood.info wrote: On Sat, Jan 25, 2014 at 10:41:05AM +1000, Nick Coghlan wrote: In this specific case, our general communication about the different purposes of the core lists *isn't* particularly good [...] It isn't that the relevant information isn't available [...] it's that there are lots of ways to miss that ifnformation, so there's always going to be the occasional misdirected question. Should this sort of signal separation guidance be available from the following 3 URLs? - http://docs.python.org/devguide/communication.html - http://www.python.org/community/lists/ - https://mail.python.org/mailman/listinfo A do / do not treatment that could be linked to could also be helpful. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] version numbers mismatched in google search results.
On Sat, Jan 25, 2014, at 05:47 AM, Vincent Davis wrote: When I do a google search the version numbers are mismatched with the linked page (or redirected). For example search for python counter I get the following results. (see attachment) It seems like the website is redirecting incorrectly. Internal links with no version redirect to the Python 2 version for backwards compatibility reasons. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] version numbers mismatched in google search results.
Am 25.01.2014 17:12, schrieb Benjamin Peterson: On Sat, Jan 25, 2014, at 05:47 AM, Vincent Davis wrote: When I do a google search the version numbers are mismatched with the linked page (or redirected). For example search for python counter I get the following results. (see attachment) It seems like the website is redirecting incorrectly. Internal links with no version redirect to the Python 2 version for backwards compatibility reasons. Yep, and the URLs without version never served Python 3 docs as far as I can remember, so I don't know where Google has these titles from. Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] version numbers mismatched in google search results.
25.01.14 18:26, Georg Brandl написав(ла): Am 25.01.2014 17:12, schrieb Benjamin Peterson: On Sat, Jan 25, 2014, at 05:47 AM, Vincent Davis wrote: When I do a google search the version numbers are mismatched with the linked page (or redirected). For example search for python counter I get the following results. (see attachment) It seems like the website is redirecting incorrectly. Internal links with no version redirect to the Python 2 version for backwards compatibility reasons. Yep, and the URLs without version never served Python 3 docs as far as I can remember, so I don't know where Google has these titles from. Guido had forgot his time machine? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
On 01/25/2014 05:29 AM, Ezio Melotti wrote: a couple of years ago I suggested to define and document our deprecation policy +1 -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] version numbers mismatched in google search results.
On Sat, Jan 25, 2014, at 10:55 AM, Vincent Davis wrote: On Sat, Jan 25, 2014 at 10:12 AM, Benjamin Peterson benja...@python.orgwrote: Internal links with no version redirect to the Python 2 version for backwards compatibility reasons. On Sat, Jan 25, 2014 at 10:26 AM, Georg Brandl g.bra...@gmx.net wrote: Yep, and the URLs without version never served Python 3 docs as far as I can remember, so I don't know where Google has these titles from. That is not consistent with http://docs.python.org (no version number) redirects to http://docs.python.org/3/ This is recent. It used to go to Python 2 docs. Maybe this is related to google search results. Seems wrong to me to point to 2.7 rather that 3.3 but I am sure there was discussion about that. The internal links all used to go to Python 2. I looked (googled) for an example of a google link to current version of python 3.3 documentation. My approach was to google python and something listed in http://docs.python.org/3/whatsnew/3.3.html These results all seem to point to http://docs.python.org/dev/library i.e. 3.4.0b2 Vincent Davis ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #20311: asyncio: Add a granularity attribute to BaseEventLoop: maximum
On Sat, 25 Jan 2014 15:02:56 +0100 (CET) victor.stinner python-check...@python.org wrote: + +@tasks.coroutine +def wait(): +loop = self.loop +calls.append(loop._run_once_counter) +yield from tasks.sleep(loop.granularity * 10, loop=loop) +calls.append(loop._run_once_counter) +yield from tasks.sleep(loop.granularity / 10, loop=loop) +calls.append(loop._run_once_counter) + +self.loop.run_until_complete(wait()) +calls.append(self.loop._run_once_counter) +self.assertEqual(calls, [1, 3, 5, 6]) Could you add a comment explaining the number of calls to run_once()? For example, why does it jump from 1 to 3 and then 3 to 5, rather than 1 to 2 and then 2 to 3? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #20133: The audioop module now uses Argument Clinic.
On 25.01.2014 10:58, serhiy.storchaka wrote: http://hg.python.org/cpython/rev/d4099b8a7d0f changeset: 88687:d4099b8a7d0f user:Serhiy Storchaka storch...@gmail.com date:Sat Jan 25 11:57:59 2014 +0200 summary: Issue #20133: The audioop module now uses Argument Clinic. files: Modules/audioop.c| 1077 ++--- Modules/audioop.clinic.c | 836 2 files changed, 1427 insertions(+), 486 deletions(-) Coverity has detected an issue in this commit: ** CID 1164423: Division or modulo by zero (DIVIDE_BY_ZERO) /Modules/audioop.c: 1375 in audioop_ratecv_impl() *** CID 1164423: Division or modulo by zero (DIVIDE_BY_ZERO) /Modules/audioop.c: 1375 in audioop_ratecv_impl() 1369without spurious overflow is the challenge; we can 1370settle for a reasonable upper bound, though, in this 1371case ceiling(len/inrate) * outrate. */ 1372 1373 /* compute ceiling(len/inrate) without overflow */ 1374 Py_ssize_t q = len 0 ? 1 + (len - 1) / inrate : 0; CID 1164423: Division or modulo by zero (DIVIDE_BY_ZERO) In expression 9223372036854775807L / q, division by expression q which may be zero has undefined behavior. 1375 if (outrate PY_SSIZE_T_MAX / q / bytes_per_frame) 1376 str = NULL; 1377 else 1378 str = PyBytes_FromStringAndSize(NULL, 1379 q * outrate * bytes_per_frame); 1380 } ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] lambda (x, y):
On Sat, Jan 25, 2014 at 12:41 AM, Greg Ewing greg.ew...@canterbury.ac.nzwrote: Brett Cannon wrote: On Fri, Jan 24, 2014 at 10:50 AM, Ram Rachum r...@rachum.com mailto: r...@rachum.com wrote: lambda (x, y): whatever http://python.org/dev/peps/pep-3113/ Part of the rationale in that PEP is that argument unpacking can always be replaced by an explicitly named argument and an unpacking assignment. No mention is made of the fact that you can't do this in a lambda, giving the impression that lambdas are deemed second-class citizens that are not worth consideration. The author was clearly aware of the issue, since a strategy is suggested for translation of lambdas by 2to3: lambda (x, y): x + y -- lambda x_y: x_y[0] + x_y[1] That's a bit on the ugly side for human use, though. An alternative would be lambda xy: (lambda x, y: x + y)(*xy) Whether that's any better is a matter of opinion. As the author of the PEP and I can say that `lambda (x, y): x + y` can just as easily be expressed as `lambda x, y: x + y` and then be called by using *args in the argument list. Anything that gets much fancier typically calls for a defined function instead of a lambda. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
On Sat, Jan 25, 2014 at 8:29 AM, Ezio Melotti ezio.melo...@gmail.comwrote:
Hi,
a couple of years ago I suggested to define and document our
deprecation policy in this thread:
https://mail.python.org/pipermail/python-dev/2011-October/114199.html
I didn't receive many replies and eventually nothing was done.
Lately the same issue came up on #python-dev and Larry and Nick
suggested me to bring this up again. Nick also suggested to document
our deprecation policy in PEP 5 (Guidelines for Language Evolution:
http://www.python.org/dev/peps/pep-0005/ ).
I'm including below the full text of the original email.
Best Regards,
Ezio Melotti
---
Hi,
our current deprecation policy is not so well defined (see e.g. [0]),
and it seems to me that it's something like:
1) deprecate something and add a DeprecationWarning;
2) forget about it after a while;
3) wait a few versions until someone notices it;
4) actually remove it;
I suggest to follow the following process:
1) deprecate something and add a DeprecationWarning;
2) decide how long the deprecation should last;
3) use the deprecated-remove[1] directive to document it;
4) add a test that fails after the update so that we remember to remove
it[2];
Other related issues:
PendingDeprecationWarnings:
* AFAIK the difference between PDW and DW is that PDW are silenced by
default;
* now DW are silence by default too, so there are no differences;
* I therefore suggest we stop using it, but we can leave it around[3]
(other projects might be using it for something different);
Deprecation Progression:
Before, we more or less used to deprecated in release X and remove in
X+1, or add a PDW in X, DW in X+1, and remove it in X+2.
I suggest we drop this scheme and just use DW until X+N, where N is
=1 and depends on what is being removed. We can decide to leave the
DW for 2-3 versions before removing something widely used, or just
deprecate in X and remove in X+1 for things that are less used.
The way I used PendingDeprecationWarning is that it is used until two
releases before removal. If we want to add a keyword-only parameter to
DeprecationWarning which specifies when the feature will be removed then
PendingDeprecationWarning is really not needed; 'removal' maybe? Could then
come up with a template format that's consistent when 'removal' is
specified:
'{} is deprecated and slated for removal in {} {}'.format(str(self.args),
self.project, self.removal) # self.project defaults to 'Python'.
Depending on how fancy we get we could have it so that when you warn on a
DeprecationWarning where 'removal' equals sys.version (or whatever) then it
always turns into an error case and thus raised as an exception.
-Brett
Porting from 2.x to 3.x:
Some people will update directly from 2.7 to 3.2 or even later
versions (3.3, 3.4, ...), without going through earlier 3.x versions.
If something is deprecated on 3.2 but not in 2.7 and then is removed
in 3.3, people updating from 2.7 to 3.3 won't see any warning, and
this will make the porting even more difficult.
I suggest that:
* nothing that is available and not deprecated in 2.7, will be
removed until 3.x (x needs to be defined);
* possibly we start backporting warnings to 2.7 so that they are
visible while running with -3;
Documenting the deprecations:
In order to advertise the deprecations, they should be documented:
* in their doc, using the deprecated-removed directive (and possibly
not the 'deprecated' one);
* in the what's new, possibly listing everything that is currently
deprecated, and when it will be removed;
Django seems to do something similar[4].
(Another thing I would like is a different rending for deprecated
functions. Some part of the docs have a deprecation warning on the
top of the section and the single functions look normal if you miss
that. Also while linking to a deprecated function it would be nice to
have it rendered with a different color or something similar.)
Testing the deprecations:
Tests that fail when a new release is made and the version number is
bumped should be added to make sure we don't forget to remove it.
The test should have a related issue with a patch to remove the
deprecated function and the test.
Setting the priority of the issue to release blocker or deferred
blocker can be done in addition/instead, but that works well only when
N == 1 (the priority could be updated for every release though).
The tests could be marked with an expected failure to give some time
after the release to remove them.
All the deprecation-related tests might be added to the same file, or
left in the test file of their module.
Where to add this:
Once we agree about the process we should write it down somewhere.
Possible candidates are:
* PEP387: Backwards Compatibility Policy[5] (it has a few lines about
this);
* a new PEP;
* the devguide;
I think having it in a PEP would
Re: [Python-Dev] cpython: Issue 19944: Fix importlib.find_spec() so it imports parents as needed.
On Sat, 25 Jan 2014 23:37:49 +0100 (CET) eric.snow python-check...@python.org wrote: http://hg.python.org/cpython/rev/665f1ba77b57 changeset: 88710:665f1ba77b57 user:Eric Snow ericsnowcurren...@gmail.com date:Sat Jan 25 15:32:46 2014 -0700 summary: Issue 19944: Fix importlib.find_spec() so it imports parents as needed. The function is also moved to importlib.util. Is there a reason to have separate importlib (toplevel) and importlib.util namespaces? (the doc says This module contains the various objects that help in the construction of an importer, which doesn't sound related to find_spec()) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Quick poll: should help() show bound arguments?
On 01/25/2014 04:34 AM, Chris Angelico wrote: On Sat, Jan 25, 2014 at 3:07 PM, Larry Hastings la...@hastings.org wrote: What should it be? A) pydoc and help() should not show bound parameters in the signature, like inspect.signature. Vote for A. As far as I'm concerned, all these foo are equally callable and equally take one parameter named a: [snip] To strengthen this argument: -- import inspect -- from functools import partial -- def lots_of_args(a, b, c, d=3, e='wow', f=None): ...print(a, b, c, d, e, f) ... -- str(inspect.signature(lots_of_args)) (a, b, c, d=3, e='wow', f=None) -- curried = partial(lots_of_args, 9, f='Some') -- str(inspect.signature(curried)) (b, c, d=3, e='wow', f='Some') While I partially agree with Antoine that the whole self thing is confusing, I think it would be more accurate to only give help (and a signature) on parameters that you can actually change; if you are calling a bound method there is no way to pass in something else in place of self. So I vote for A. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue 19944: Fix importlib.find_spec() so it imports parents as needed.
On Sat, Jan 25, 2014 at 6:28 PM, Antoine Pitrou solip...@pitrou.net wrote: Is there a reason to have separate importlib (toplevel) and importlib.util namespaces? As to why they are separate, you'll need to ask Brett. I believe it's meant to keep the top namespace as small as possible. Regarding this changeset, it depended on importlib.util.resolve_name(), so moving find_spec() made sense. We discussed it briefly in issue #19944 and everyone there agreed it was fine. (the doc says This module contains the various objects that help in the construction of an importer, which doesn't sound related to find_spec()) We should fix that, :) -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
On Jan 25, 2014, at 5:29 AM, Ezio Melotti ezio.melo...@gmail.com wrote: Nick also suggested to document our deprecation policy in PEP 5 (Guidelines for Language Evolution: http://www.python.org/dev/peps/pep-0005/ ). Here's a few thoughts on deprecations: * If we care at all about people moving to Python 3, then we'll stop doing anything that makes the process more difficult. For someone moving from Python 2.7, it really doesn't matter if something that existed in 2.7 got deprecated in 3.1 and removed in 3.3; from their point-of-view, it just one more thing that won't work. * The notion of PendingDeprecationWarnings didn't work out very well. Conceptually, it was a nice idea, but in practice no one was benefitting from it. The warnings slowed down working, but not yet deprecated code. And no one was actually seeing the pending deprecations. * When a module becomes obsolete (say optparse vs argparse), there isn't really anything wrong with just leaving it in and making the docs indicate that something better is available. AFAICT, there isn't much value in actually removing the older tool. * A good use for deprecations is for features that were flat-out misdesigned and prone to error. For those, there is nothing wrong with deprecating them right away. Once deprecated though, there doesn't need to be a rush to actually remove it -- that just makes it harder for people with currently working code to upgrade to newer versions of Python. * When I became a core developer well over a decade ago, I was a little deprecation happy (old stuff must go, keep everything nice and clean, etc). What I learned though is that deprecations are very hard on users and that the purported benefits usually aren't really important. my-two-cents, Raymond___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] lambda (x, y):
On Jan 25, 2014, at 4:01 PM, Brett Cannon br...@python.org wrote: As the author of the PEP and I can say that `lambda (x, y): x + y` can just as easily be expressed as `lambda x, y: x + y` and then be called by using *args in the argument list. Anything that gets much fancier typically calls for a defined function instead of a lambda. I think that is an over-simplification. The argument unpacking was handy in a number of situations where *args wouldn't suffice: lambda (px, py), (qx, qy): ((px - qx) ** 2 + (py - qy) ** 2) ** 0.5 IIRC, the original reason for the change was that it simplified the compiler a bit, not that it was broken or not useful. Taking-out tuple unpacking might have been a good idea for the reasons listed in the PEP, but we shouldn't pretend that it didn't cripple some of the use cases for lambda where some of the arguments came in as tuples (host/port pairs, x-y coordinates, hue-saturation-luminosity, month-day-year, etc). Raymond___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] version numbers mismatched in google search results.
On 26 January 2014 05:05, Benjamin Peterson benja...@python.org wrote: On Sat, Jan 25, 2014, at 10:55 AM, Vincent Davis wrote: On Sat, Jan 25, 2014 at 10:12 AM, Benjamin Peterson benja...@python.orgwrote: Internal links with no version redirect to the Python 2 version for backwards compatibility reasons. On Sat, Jan 25, 2014 at 10:26 AM, Georg Brandl g.bra...@gmx.net wrote: Yep, and the URLs without version never served Python 3 docs as far as I can remember, so I don't know where Google has these titles from. That is not consistent with http://docs.python.org (no version number) redirects to http://docs.python.org/3/ This is recent. It used to go to Python 2 docs. http://www.python.org/dev/peps/pep-0430/ covers the rationale for the current arrangement. The main issue is the extensive use of existing deep links into the Python 2 documentation from Python 2 specific tutorials and other references. Those third party references not only include vast numbers of online resources that we don't control, but also books that can't be updated at all. So, the canonical URLs on docs.python.org now always include the major version number in the path so they're unambiguous, the Python 3 docs are displayed by default, and unqualified deep links redirect to Python 2 for backwards compatibility. The robots.txt on python.org is *supposed* to keep the web crawlers away from the /dev/ subtree (since most people searching for Python info aren't going to want the docs for an unreleased version), but I don't know if that's documented anywhere, or even if it's currently still configured that way. Maybe this is related to google search results. Seems wrong to me to point to 2.7 rather that 3.3 but I am sure there was discussion about that. The internal links all used to go to Python 2. There's also a lot of weight given in Google to the extensive array of existing unqualified deep links, which relate to Python 2. I looked (googled) for an example of a google link to current version of python 3.3 documentation. My approach was to google python and something listed in http://docs.python.org/3/whatsnew/3.3.html These results all seem to point to http://docs.python.org/dev/library i.e. 3.4.0b2 Which suggests that the Google web crawler *is* spidering the dev docs, which we generally don't want :P Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] version numbers mismatched in google search results.
I think subdomains need there own robots.txt which docs.python.org nor docs.python.org/(2 or 3)/ have. and http://python.org/robots.txt (below) seems a little sparse. For sure /dev/ is not blocked # Directions for robots. See this URL: # http://www.robotstxt.org/wc/norobots.html # for a description of the file format. User-agent: HTTrack User-agent: puf User-agent: MSIECrawler Disallow: / # The Krugle web crawler (though based on Nutch) is OK. User-agent: Krugle Allow: / Disallow: /moin Disallow: /pypi Disallow: /~guido/orlijn/ Disallow: /wwwstats/ Disallow: /ftpstats/ # No one should be crawling us with Nutch. User-agent: Nutch Disallow: / # Hide old versions of the documentation and various large sets of files. User-agent: * Disallow: /~guido/orlijn/ Disallow: /wwwstats/ Disallow: /webstats/ Disallow: /ftpstats/ Disallow: /moin Disallow: /pypi Disallow: /dev/buildbot/ Vincent Davis 720-301-3003 On Sat, Jan 25, 2014 at 9:04 PM, Nick Coghlan ncogh...@gmail.com wrote: On 26 January 2014 05:05, Benjamin Peterson benja...@python.org wrote: On Sat, Jan 25, 2014, at 10:55 AM, Vincent Davis wrote: On Sat, Jan 25, 2014 at 10:12 AM, Benjamin Peterson benja...@python.orgwrote: Internal links with no version redirect to the Python 2 version for backwards compatibility reasons. On Sat, Jan 25, 2014 at 10:26 AM, Georg Brandl g.bra...@gmx.net wrote: Yep, and the URLs without version never served Python 3 docs as far as I can remember, so I don't know where Google has these titles from. That is not consistent with http://docs.python.org (no version number) redirects to http://docs.python.org/3/ This is recent. It used to go to Python 2 docs. http://www.python.org/dev/peps/pep-0430/ covers the rationale for the current arrangement. The main issue is the extensive use of existing deep links into the Python 2 documentation from Python 2 specific tutorials and other references. Those third party references not only include vast numbers of online resources that we don't control, but also books that can't be updated at all. So, the canonical URLs on docs.python.org now always include the major version number in the path so they're unambiguous, the Python 3 docs are displayed by default, and unqualified deep links redirect to Python 2 for backwards compatibility. The robots.txt on python.org is *supposed* to keep the web crawlers away from the /dev/ subtree (since most people searching for Python info aren't going to want the docs for an unreleased version), but I don't know if that's documented anywhere, or even if it's currently still configured that way. Maybe this is related to google search results. Seems wrong to me to point to 2.7 rather that 3.3 but I am sure there was discussion about that. The internal links all used to go to Python 2. There's also a lot of weight given in Google to the extensive array of existing unqualified deep links, which relate to Python 2. I looked (googled) for an example of a google link to current version of python 3.3 documentation. My approach was to google python and something listed in http://docs.python.org/3/whatsnew/3.3.html These results all seem to point to http://docs.python.org/dev/library i.e. 3.4.0b2 Which suggests that the Google web crawler *is* spidering the dev docs, which we generally don't want :P Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecation policy
On 26 January 2014 12:30, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Jan 25, 2014, at 5:29 AM, Ezio Melotti ezio.melo...@gmail.com wrote: Nick also suggested to document our deprecation policy in PEP 5 (Guidelines for Language Evolution: http://www.python.org/dev/peps/pep-0005/ ). Here's a few thoughts on deprecations: * If we care at all about people moving to Python 3, then we'll stop doing anything that makes the process more difficult. For someone moving from Python 2.7, it really doesn't matter if something that existed in 2.7 got deprecated in 3.1 and removed in 3.3; from their point-of-view, it just one more thing that won't work. * The notion of PendingDeprecationWarnings didn't work out very well. Conceptually, it was a nice idea, but in practice no one was benefitting from it. The warnings slowed down working, but not yet deprecated code. And no one was actually seeing the pending deprecations. * When a module becomes obsolete (say optparse vs argparse), there isn't really anything wrong with just leaving it in and making the docs indicate that something better is available. AFAICT, there isn't much value in actually removing the older tool. * A good use for deprecations is for features that were flat-out misdesigned and prone to error. For those, there is nothing wrong with deprecating them right away. Once deprecated though, there doesn't need to be a rush to actually remove it -- that just makes it harder for people with currently working code to upgrade to newer versions of Python. * When I became a core developer well over a decade ago, I was a little deprecation happy (old stuff must go, keep everything nice and clean, etc). What I learned though is that deprecations are very hard on users and that the purported benefits usually aren't really important. +1 to what Raymond send - unless something is actively causing us maintenance hassles or is a genuine bug magnet (cf. contextlib.nested), we should be very cautious about forcing users to change their code, especially in the context of raising additional barriers to migration from Python 2 to Python 3. Ezio's suggestions make sense as a policy for how to handle the situation when we *do* decide something needs programmatic deprecation, but I think there needs to be an explicit caveat that programmatic deprecation should be a last resort. Wherever possible, we should also provide a PyPI module that helps address the issue in a cross-version compatible way (whether through a dedicated upstream and/or backport module like contextlib2 or by adding features to existing cross-version compatibility modules like six and future) As an example that hopefully helps illustrate the two different cases, the shift to enabling proper SSL/TLS verification by default would qualify as a worthy use of programmatic deprecation (since the current insecure-by-default behaviour is a genuine bug magnet that leads to security flaws), but I'm not yet convinced that we actually gain any significant benefit from deprecating the legacy import plugin APIs. While PEP 451 nominally approved deprecating the latter, on the basis that deprecating them will make importlib easier to maintain, they received a stay of execution in 3.4 because the extension module import system currently still needs them, and there are other valid use cases that PEP 451 doesn't currently cover, At this point, I have come to believe that retaining the existing strictly-more-powerful-but-also-harder-to-use-correctly plugin API is a better way to handle those more complex use cases rather than inventing something new on top of PEP 451, as the latter approach would make things *harder* to maintain (due to increased complexity and needing to manage the deprecation process), and provide a worse experience for users implementing custom import hooks that need to support multiple versions (due to the introduction of new cross-version compatibility issues). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New policies for the Derby -- please read!
On 1/25/2014 10:37 AM, Larry Hastings wrote: On 01/25/2014 07:26 AM, Nick Coghlan wrote: However, you've indicated that adding varargs support is going to take you quite a bit of work, so postponing it is an option definitely worth considering at this point in the release cycle. It's worth considering. I'm estimating it's about 1.5 days' worth of work. Mainly because, at the same time, I need to teach Clinic to have separate namespaces for parser and impl functions. At the same time I was going to implement a frequently-requested feature, allowing the C variable storing an argument to have a different name than the actual Python parameter. And it could be one of those hey that was easier than I thought things. 1.5 days is kind of worst-case. So maybe the best thing would be to give it a half-day and see if it turned out to be easy. Of course, If we bring the Derby to a close now-ish (debate going on in python-committers right now!), then I'll definitely put it off until 3.5. I have been annoyed by the mismatch between Python signatures and C-implementation for at least a decade. Now that the idea that all functions (except possible for range) should have Python signatures seems to have been accepted, I am willing for the full implementation to wait until 3.5. I think the Derby experiment has pretty well exposed what still needs to be done, so I expect it should be possible to have it all in 3.5 as long as people do not burn out first. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] version numbers mismatched in google search results.
On Sat, Jan 25, 2014, at 07:04 PM, Nick Coghlan wrote: Which suggests that the Google web crawler *is* spidering the dev docs, which we generally don't want :P I've now added a robots.txt to disallow crawling /dev. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #20133: The audioop module now uses Argument Clinic.
26.01.14 01:10, Christian Heimes написав(ла): Coverity has detected an issue in this commit: Thank you. This is false positive detection. http://bugs.python.org/issue20394. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
