[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2015-10-16 - 2015-10-23) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open5181 (+29) closed 32043 (+17) total 37224 (+46) Open issues with patches: 2287 Issues opened (40) == #24379: operator.subscript http://bugs.python.org/issue24379 reopened by rhettinger #25154: Drop the pyvenv script http://bugs.python.org/issue25154 reopened by brett.cannon #25234: test_eintr.test_os_open hangs under Xcode 7 http://bugs.python.org/issue25234 reopened by brett.cannon #25421: Make __sizeof__ for builtin types more subclass friendly http://bugs.python.org/issue25421 opened by serhiy.storchaka #25423: Deprecate benchmarks that execute too quickly http://bugs.python.org/issue25423 opened by brett.cannon #25425: white-spaces encountered in 3.4 http://bugs.python.org/issue25425 opened by pavan kumar Dharmavarapu #25426: Deprecate the regex_compile benchmark http://bugs.python.org/issue25426 opened by brett.cannon #25427: Remove the pyvenv script in Python 3.8 http://bugs.python.org/issue25427 opened by brett.cannon #25430: speed up ipaddress __contain__ method http://bugs.python.org/issue25430 opened by gescheit #25431: implement address in network in ipaddress module http://bugs.python.org/issue25431 opened by gescheit #25432: isinstance documentation doesn't explain what happens when typ http://bugs.python.org/issue25432 opened by Michael Crouch #25433: whitespace in strip()/lstrip()/rstrip() http://bugs.python.org/issue25433 opened by Dimitri Papadopoulos Orfanos #25435: Wrong function calls and referring to not removed concepts in http://bugs.python.org/issue25435 opened by David Becher #25436: argparse.ArgumentError missing error message in __repr__ http://bugs.python.org/issue25436 opened by dfortunov #25437: Issue with ftplib.FTP_TLS and server forcing SSL connection re http://bugs.python.org/issue25437 opened by dwaites #25438: document what codec PyMemberDef T_STRING decodes the char * as http://bugs.python.org/issue25438 opened by gregory.p.smith #25439: Add type checks to urllib.request.Request http://bugs.python.org/issue25439 opened by ezio.melotti #25442: Shelve consistency issues http://bugs.python.org/issue25442 opened by Yanyan Jiang #25443: Add a count of how many benchmarks are left to run http://bugs.python.org/issue25443 opened by brett.cannon #25444: Py Launch Icon http://bugs.python.org/issue25444 opened by Nils-Hero #25446: smtplib.py AUTH LOGIN code messed up sending login and passwor http://bugs.python.org/issue25446 opened by merkel #25447: TypeError invoking deepcopy on lru_cache http://bugs.python.org/issue25447 opened by jason.coombs #25449: Test OrderedDict subclass http://bugs.python.org/issue25449 opened by serhiy.storchaka #25450: Python 3.5 starts in C:\Windows\system32 as current directory http://bugs.python.org/issue25450 opened by Maja Tomic #25451: tkinter: PhotoImage transparency methods http://bugs.python.org/issue25451 opened by None Becoming #25452: Add __bool__() method to subprocess.CompletedProcess http://bugs.python.org/issue25452 opened by conqp #25453: Arithmetics with complex infinities is inconsistent with C/C++ http://bugs.python.org/issue25453 opened by Francesco Biscani #25454: operator.methodcaller should accept additional arguments durin http://bugs.python.org/issue25454 opened by abacabadabacaba #25455: Some repr implementations don't check for self-referential str http://bugs.python.org/issue25455 opened by abacabadabacaba #25456: 3.4 _tkinter build requires undocumented manual steps to be us http://bugs.python.org/issue25456 opened by terry.reedy #25457: json dump fails for mixed-type keys when sort_keys is specifie http://bugs.python.org/issue25457 opened by [email protected] #25458: ftplib: command response shift - mismatch http://bugs.python.org/issue25458 opened by peterpan #25459: EAGAIN errors in Python logging module http://bugs.python.org/issue25459 opened by Henrique Andrade #25460: Misc/.gdbinit uses preprocessor macro http://bugs.python.org/issue25460 opened by philtweir #25461: Unclear language (the word ineffective) in the documentation f http://bugs.python.org/issue25461 opened by Bernt.Røskar.Brenna #25462: Avoid repeated hash calculation in C implementation of Ordered http://bugs.python.org/issue25462 opened by serhiy.storchaka #25463: 2.7.10 glibc double free detected http://bugs.python.org/issue25463 opened by wcolburnnrao #25464: Tix HList header_exists should be "exist" http://bugs.python.org/issue25464 opened by rtw #25465: Pickle uses O(n) memory overhead http://bugs.python.org/issue25465 opened by prinsherbert #25466: offer "from __future__ import" option for "raise... from" http://bugs.python.org/issue25466 opened by alanf Most recent 15 issues with no replies (15) ===
Re: [Python-Dev] Generated Bytecode ...
Thank you for your confirmation,
I am going to read the devguide.
> On 25 oct. 2015, at 7:50 PM, Raymond Hettinger
> wrote:
>
>
>>> On Oct 25, 2015, at 12:33 PM, Raymond Hettinger
>>> wrote:
>>>
>>> On Oct 22, 2015, at 10:02 AM, Brett Cannon wrote:
>>>
>>> So my question is, the byte code generator removes the unused functions,
>>> variables etc…, is it right?
>>>
>>> Technically the peepholer removes the dead branch, but since the peepholer
>>> is run on all bytecode you can't avoid it.
>>
>> IIRC, the code was never generated in the first place (before the peephole
>> pass). This used to be true before the AST branch was added and I think it
>> may still be true.
>
> I just verified this. So Brett's post was incorrect and misleading.
>
>
> Raymond
>
>
> --- Verify by turning-off the optimizations --
> cpython $ hg diff Python/peephole.c
> diff --git a/Python/peephole.c b/Python/peephole.c
> --- a/Python/peephole.c
> +++ b/Python/peephole.c
> @@ -383,7 +383,7 @@
> /* Avoid situations where jump retargeting could overflow */
> assert(PyBytes_Check(code));
> codelen = PyBytes_GET_SIZE(code);
> -if (codelen > 32700)
> +if (codelen > 0)
> goto exitUnchanged;
>
> Then run a simple disassembly ---
>
> from dis import dis
>
> def f(x):
>if 0:
>print('First')
>print('Second')
>
> dis(f)
>
> The output is ---
>
> $ py tmp.py
> 6 0 LOAD_GLOBAL 0 (print)
> 3 LOAD_CONST 1 ('Second')
> 6 CALL_FUNCTION1 (1 positional, 0 keyword pair)
> 9 POP_TOP
> 10 LOAD_CONST 0 (None)
> 13 RETURN_VALUE
>
___
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] Where is defined the grammar of Python?
Hi all, Just to understand, we have the Parser/Python.asdl and Grammar/Grammar files. Which one is used for the AST ? I would like to understand this part of Python, could you help me? Thank you Stéphane -- Stéphane Wirtel - http://wirtel.be - @matrixise signature.asc Description: OpenPGP digital signature ___ 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] PEP 484 -- proposal to allow @overload in non-stub files
On 22 October 2015 at 19:51, Guido van Rossum wrote:
> On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith wrote:
>> What would it Foo.__getitem__.__annotations__ contain in this situation?
>> It'd unfortunately be an empty dict if implemented in the most trivial
>> fashion rather than a dict containing your Unions... Do we care?
>
> Initially it would indeed be {}. Once we have a true multi-dispatch PEP we
> can iterate, both on how to spell it (perhaps the final __getitem__ needs an
> @overload as well) and on what happens in the annotations (or at least, what
> typing.get_type_hints() returns).
Just ensuring I understand the problem with using a third @overload in
the spelling from the start:
class Foo(Generic[T]):
@overload
def __getitem__(self, i: int) -> T: ...
@overload
def __getitem__(self, s: slice) -> Foo[T]: ...
@overload
def __getitem__(self, x):
If we did this, the implied annotation on the last method would be:
@overload
def __getitem__(self, x: Any) -> Any:
which gets the signature wrong - this isn't an Any:Any mapping, it's a sequence.
Leaving the "@overload" out thus indicates that the definition is an
implementation of the preceding type based dispatch declaration,
rather than a new overload.
Assuming a future multidispatch implementation used
"functools.multidispatch" as the decorator (to complement the existing
functools.singledispatch) rather than "typing.overload", this seems
like a reasonable short term solution to me.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
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] Generated Bytecode ...
> On Oct 25, 2015, at 12:33 PM, Raymond Hettinger
> wrote:
>
>> On Oct 22, 2015, at 10:02 AM, Brett Cannon wrote:
>>
>> So my question is, the byte code generator removes the unused functions,
>> variables etc…, is it right?
>>
>> Technically the peepholer removes the dead branch, but since the peepholer
>> is run on all bytecode you can't avoid it.
>
> IIRC, the code was never generated in the first place (before the peephole
> pass). This used to be true before the AST branch was added and I think it
> may still be true.
I just verified this. So Brett's post was incorrect and misleading.
Raymond
--- Verify by turning-off the optimizations --
cpython $ hg diff Python/peephole.c
diff --git a/Python/peephole.c b/Python/peephole.c
--- a/Python/peephole.c
+++ b/Python/peephole.c
@@ -383,7 +383,7 @@
/* Avoid situations where jump retargeting could overflow */
assert(PyBytes_Check(code));
codelen = PyBytes_GET_SIZE(code);
-if (codelen > 32700)
+if (codelen > 0)
goto exitUnchanged;
Then run a simple disassembly ---
from dis import dis
def f(x):
if 0:
print('First')
print('Second')
dis(f)
The output is ---
$ py tmp.py
6 0 LOAD_GLOBAL 0 (print)
3 LOAD_CONST 1 ('Second')
6 CALL_FUNCTION1 (1 positional, 0 keyword pair)
9 POP_TOP
10 LOAD_CONST 0 (None)
13 RETURN_VALUE
___
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] Generated Bytecode ...
> On Oct 22, 2015, at 10:02 AM, Brett Cannon wrote: > > So my question is, the byte code generator removes the unused functions, > variables etc…, is it right? > > Technically the peepholer removes the dead branch, but since the peepholer is > run on all bytecode you can't avoid it. IIRC, the code was never generated in the first place (before the peephole pass). This used to be true before the AST branch was added and I think it may still be true. Raymond Hettinger ___ 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] PEP 484 -- proposal to allow @overload in non-stub files
On Fri, Oct 23, 2015 at 8:38 AM, Nick Coghlan wrote:
> On 22 October 2015 at 19:51, Guido van Rossum wrote:
> > On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith
> wrote:
> >> What would it Foo.__getitem__.__annotations__ contain in this situation?
> >> It'd unfortunately be an empty dict if implemented in the most trivial
> >> fashion rather than a dict containing your Unions... Do we care?
> >
> > Initially it would indeed be {}. Once we have a true multi-dispatch PEP
> we
> > can iterate, both on how to spell it (perhaps the final __getitem__
> needs an
> > @overload as well) and on what happens in the annotations (or at least,
> what
> > typing.get_type_hints() returns).
>
> Just ensuring I understand the problem with using a third @overload in
> the spelling from the start:
>
> class Foo(Generic[T]):
> @overload
> def __getitem__(self, i: int) -> T: ...
>
> @overload
> def __getitem__(self, s: slice) -> Foo[T]: ...
>
> @overload
> def __getitem__(self, x):
>
>
> If we did this, the implied annotation on the last method would be:
>
> @overload
> def __getitem__(self, x: Any) -> Any:
>
>
> which gets the signature wrong - this isn't an Any:Any mapping, it's a
> sequence.
>
Well, a type checker could handle the special case of the last overload.
There should be a rule that overloads are handled in the order in which
they are processed; it's not explicit in the PEP but it's meant to be that
way, in case there's overlap between signatures. (This differs from
singledispatch: when overloading on multiple types it's not always possible
to disambiguate by using the most derived type.)
But allowing this in code without having a full-fledged multi-dispatch
implementation in @overload would cause confusion in readers, which is why
we decided to disallow it outside stubs.
> Leaving the "@overload" out thus indicates that the definition is an
> implementation of the preceding type based dispatch declaration,
> rather than a new overload.
>
Yeah, that was the proposal. But I no longer think it's worth it.
> Assuming a future multidispatch implementation used
> "functools.multidispatch" as the decorator (to complement the existing
> functools.singledispatch) rather than "typing.overload", this seems
> like a reasonable short term solution to me.
>
But once we have a functools.multidispatch, why would we also need
typing.overload? (Outside stubs, that is.) Given that a short-term solution
is already possible using a stub, I'm not sure that adding another
short-term solution is worth it, if we don't intend to keep it around.
--
--Guido van Rossum (python.org/~guido)
___
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] PEP 484 -- proposal to allow @overload in non-stub files
I've thought this over and I don't think it's worth it. We need to wait for
a working proposal for multi-dispatch first. Otherwise we'll just end up
having to support this interim syntax *and* whatever the new multi-dispatch
is. Keeping @overload restricted to stub files makes it much more tractable.
On Thu, Oct 22, 2015 at 10:51 AM, Guido van Rossum wrote:
> On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith wrote:
>
>>
>>
>> On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum
>> wrote:
>>
>>> Well the whole point is not to have to figure out how to implement that
>>> right now.
>>>
>>> On Wed, Oct 21, 2015 at 6:45 PM, Random832
>>> wrote:
>>>
Guido van Rossum writes:
> The proposal is to allow this to be written as follows in
> implementation (non-stub) modules:
>
> class Foo(Generic[T]):
> @overload
> def __getitem__(self, i: int) -> T: ...
> @overload
> def __getitem__(self, s: slice) -> Foo[T]: ...
> def __getitem__(self, x):
>
>
> The actual implementation must be last, so at run time it will
> override the definition.
>>>
>> I think this *could* be fine. It is certainly readable. And, as is
>> already possible in .pyi files, more accurately expressive than the Union
>> which doesn't imply a parameter type to return value type relationship.
>>
>
> Right, which is how this got started.
>
>
>> What would it Foo.__getitem__.__annotations__ contain in this situation?
>> It'd unfortunately be an empty dict if implemented in the most trivial
>> fashion rather than a dict containing your Unions... Do we care?
>>
>
> Initially it would indeed be {}. Once we have a true multi-dispatch PEP we
> can iterate, both on how to spell it (perhaps the final __getitem__ needs
> an @overload as well) and on what happens in the annotations (or at least,
> what typing.get_type_hints() returns).
>
> We could also wait for a multidispatch PEP to land -- but I'm worried that
> we'll be waiting past 3.6.
>
> Then again I don't see how true multidispatch would be able to deal with
> the syntax proposed here -- you need some kind of decorator on the fallback
> implementation.
>
>
>> Note that it would also slow down module import time as the code for each
>> of the earlier ... definitions with annotation structures and @overload
>> decorator calls is executed, needlessly creating objects and structures
>> that are immediately discarded upon each subsequent definition.
>>
>
> Yes, but I don't think this is going to make a noticeable difference.
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
--
--Guido van Rossum (python.org/~guido)
___
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] PEP 484 -- proposal to allow @overload in non-stub files
All these overloads makes the code hard to read. The whole idea of 'i have to know which decorator got called before the other one' is a smell that you have too many decorators. This whole idea reeks 'i can be very, very clever here'. Laura ___ 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] Where is defined the grammar of Python?
"Stéphane Wirtel" writes: > I would like to understand this part of Python, could you help me? You should also know the Python Language Reference documentation https://docs.python.org/3/reference/>, especially the Full Grammar specification https://docs.python.org/3/reference/grammar.html>. -- \ “Holy astringent plum-like fruit, Batman!” —Robin | `\ | _o__) | Ben Finney ___ 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] Generated Bytecode ...
On 10/23/2015 4:23 AM, Victor Stinner wrote: Hi, 2015-10-22 19:02 GMT+02:00 Brett Cannon : It's not specified anywhere; it's just what the peepholer decides to remove. The exact code can be found at https://hg.python.org/cpython/file/default/Python/peephole.c . There has been talk in the past for adding a -X flag to disable the peepholer, but it never went any farther beyond that. Yeah, I remember that I had the same issue than Stéphane when I worked on my astoptimizer project :-) I wanted to completly disable the peephole optimizer because I wanted to reimplement the optimizations on the AST instead of rewriting the bytecode. I would be nice to have a "-X noopt" command line option for that. How about -x nopeep to specifically skip the peephole optimizer? -- 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
