Re: [Python-Dev] PEP 484 -- proposal to allow @overload in non-stub files

2015-10-22 Thread Gregory P. Smith 
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.

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?

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.

-gps


>
>> How about this to allow overloads to have actual implementations?
>>
>> @overloaded
>> def __getitem__(self, x):
>> 
>>
>> @overloaded returns a function which will check the types against the
>> overloads (or anyway any overloads that have actual implementations),
>> call them returning the result if applicable, otherwise call the
>> original function.
>>
>> Some magic with help() would improve usability, too - it could print all
>> the overloads and their docstrings.  Maybe even @overload('__getitem__')
>> def __get_int(self, i: int), to make it so order doesn't matter.
>>
>> That just leaves the question of how's this all gonna work with
>> subclasses.
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>>
> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>
>
>
> --
> --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/greg%40krypto.org
>
___
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

2015-10-22 Thread Paul Moore 
On 22 October 2015 at 10:21, 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.
>
> 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?
>
> 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.

Is the idea that in future the "..." dummy declarations could be
replaced by specialised implementations for the particular type
combinations? If not, is there a risk that by grabbing the @overload
decorator just for typing we lose the option of using the natural
spelling for an actual multi-dspatch implementation?

Paul
___
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] Should PEP 498 specify if rf'...' is valid?

2015-10-22 Thread Eric V. Smith 
On 10/21/2015 10:57 PM, Ryan Gonzalez wrote:
> It mentions fr'...' as a formatted raw string but doesn't say anything
> about rf'...'. Right now, in implementing PEP 498 support in Howl
> (https://github.com/howl-editor/howl/pull/118 and
> https://github.com/howl-editor/howl/commit/1e577da89efc1c1de780634b531f64346cf586d6#diff-851d9b84896270cc7e3bbea3014007a5R86),
> I assumed both were valid. Should the PEP be more specific?

Yes, I'll add some wording. Note that currently, there are 24 valid
prefixes:

['B', 'BR', 'Br', 'F', 'FR', 'Fr', 'R', 'RB', 'RF', 'Rb', 'Rf', 'U',
'b', 'bR', 'br', 'f', 'fR', 'fr', 'r', 'rB', 'rF', 'rb', 'rf', 'u']

> BTW, at the rate language-python is going, GitHub will get syntax
> highlighting for f-strings in 2050. :D

Heh. If we add binary f-strings, there are 80 permutations:

['B', 'BF', 'BFR', 'BFr', 'BR', 'BRF', 'BRf', 'Bf', 'BfR', 'Bfr', 'Br',
'BrF', 'Brf', 'F', 'FB', 'FBR', 'FBr', 'FR', 'FRB', 'FRb', 'Fb', 'FbR',
'Fbr', 'Fr', 'FrB', 'Frb', 'R', 'RB', 'RBF', 'RBf', 'RF', 'RFB', 'RFb',
'Rb', 'RbF', 'Rbf', 'Rf', 'RfB', 'Rfb', 'U', 'b', 'bF', 'bFR', 'bFr',
'bR', 'bRF', 'bRf', 'bf', 'bfR', 'bfr', 'br', 'brF', 'brf', 'f', 'fB',
'fBR', 'fBr', 'fR', 'fRB', 'fRb', 'fb', 'fbR', 'fbr', 'fr', 'frB',
'frb', 'r', 'rB', 'rBF', 'rBf', 'rF', 'rFB', 'rFb', 'rb', 'rbF', 'rbf',
'rf', 'rfB', 'rfb', 'u']

I think the upper/lower ones are nuts, but it's probably too late to do
anything about it. 'FbR', really?

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] Should PEP 498 specify if rf'...' is valid?

2015-10-22 Thread Eric V. Smith 
On 10/22/2015 7:32 AM, Eric V. Smith wrote:
> On 10/21/2015 10:57 PM, Ryan Gonzalez wrote:
>> It mentions fr'...' as a formatted raw string but doesn't say anything
>> about rf'...'. Right now, in implementing PEP 498 support in Howl
>> (https://github.com/howl-editor/howl/pull/118 and
>> https://github.com/howl-editor/howl/commit/1e577da89efc1c1de780634b531f64346cf586d6#diff-851d9b84896270cc7e3bbea3014007a5R86),
>> I assumed both were valid. Should the PEP be more specific?
> 
> Yes, I'll add some wording.

Now that I check, in the Specification section, the PEP already says
"'f' may be combined with 'r', in either order, to produce raw f-string
literals". So I think this case is covered, no?

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] Should PEP 498 specify if rf'...' is valid?

2015-10-22 Thread Ryan Gonzalez 
Ah, I missed that part. Sorry! :/

On October 22, 2015 7:27:41 AM CDT, "Eric V. Smith"  wrote:
>On 10/22/2015 7:32 AM, Eric V. Smith wrote:
>> On 10/21/2015 10:57 PM, Ryan Gonzalez wrote:
>>> It mentions fr'...' as a formatted raw string but doesn't say
>anything
>>> about rf'...'. Right now, in implementing PEP 498 support in Howl
>>> (https://github.com/howl-editor/howl/pull/118 and
>>>
>https://github.com/howl-editor/howl/commit/1e577da89efc1c1de780634b531f64346cf586d6#diff-851d9b84896270cc7e3bbea3014007a5R86),
>>> I assumed both were valid. Should the PEP be more specific?
>> 
>> Yes, I'll add some wording.
>
>Now that I check, in the Specification section, the PEP already says
>"'f' may be combined with 'r', in either order, to produce raw f-string
>literals". So I think this case is covered, no?
>
>Eric.

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.___
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] Should PEP 498 specify if rf'...' is valid?

2015-10-22 Thread Sven R. Kunze 

On 22.10.2015 13:32, Eric V. Smith wrote:

['B', 'BF', 'BFR', 'BFr', 'BR', 'BRF', 'BRf', 'Bf', 'BfR', 'Bfr', 'Br',
'BrF', 'Brf', 'F', 'FB', 'FBR', 'FBr', 'FR', 'FRB', 'FRb', 'Fb', 'FbR',
'Fbr', 'Fr', 'FrB', 'Frb', 'R', 'RB', 'RBF', 'RBf', 'RF', 'RFB', 'RFb',
'Rb', 'RbF', 'Rbf', 'Rf', 'RfB', 'Rfb', 'U', 'b', 'bF', 'bFR', 'bFr',
'bR', 'bRF', 'bRf', 'bf', 'bfR', 'bfr', 'br', 'brF', 'brf', 'f', 'fB',
'fBR', 'fBr', 'fR', 'fRB', 'fRb', 'fb', 'fbR', 'fbr', 'fr', 'frB',
'frb', 'r', 'rB', 'rBF', 'rBf', 'rF', 'rFB', 'rFb', 'rb', 'rbF', 'rbf',
'rf', 'rfB', 'rfb', 'u']

I think the upper/lower ones are nuts, but it's probably too late to do
anything about it. 'FbR', really?


Why not disallowing them?

I for one could live with all-lower-case AND a predefined order.

Best,
Sven
___
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] Should PEP 498 specify if rf'...' is valid?

2015-10-22 Thread Ryan Gonzalez 


On October 22, 2015 11:10:48 AM CDT, "Sven R. Kunze"  wrote:
>On 22.10.2015 13:32, Eric V. Smith wrote:
>> ['B', 'BF', 'BFR', 'BFr', 'BR', 'BRF', 'BRf', 'Bf', 'BfR', 'Bfr',
>'Br',
>> 'BrF', 'Brf', 'F', 'FB', 'FBR', 'FBr', 'FR', 'FRB', 'FRb', 'Fb',
>'FbR',
>> 'Fbr', 'Fr', 'FrB', 'Frb', 'R', 'RB', 'RBF', 'RBf', 'RF', 'RFB',
>'RFb',
>> 'Rb', 'RbF', 'Rbf', 'Rf', 'RfB', 'Rfb', 'U', 'b', 'bF', 'bFR', 'bFr',
>> 'bR', 'bRF', 'bRf', 'bf', 'bfR', 'bfr', 'br', 'brF', 'brf', 'f',
>'fB',
>> 'fBR', 'fBr', 'fR', 'fRB', 'fRb', 'fb', 'fbR', 'fbr', 'fr', 'frB',
>> 'frb', 'r', 'rB', 'rBF', 'rBf', 'rF', 'rFB', 'rFb', 'rb', 'rbF',
>'rbf',
>> 'rf', 'rfB', 'rfb', 'u']
>>
>> I think the upper/lower ones are nuts, but it's probably too late to
>do
>> anything about it. 'FbR', really?
>
>Why not disallowing them?
>
>I for one could live with all-lower-case AND a predefined order.
>

Well, now it's backwards-compatibility.

>Best,
>Sven
>___
>Python-Dev mailing list
>[email protected]
>https://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe:
>https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
___
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] Generated Bytecode ...

2015-10-22 Thread Stéphane Wirtel 
Hi all,

When we compile a python script 

# test.py
if 0:
x = 1

python -mdis test.py

There is no byte code for the condition.

So my question is, the byte code generator removes the unused functions, 
variables etc…, is it right?

What are the cases where the generator does not generate the byte codes ?

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] Should PEP 498 specify if rf'...' is valid?

2015-10-22 Thread Sven R. Kunze 

On 22.10.2015 18:17, Ryan Gonzalez wrote:



anything about it. 'FbR', really?

Why not disallowing them?

I for one could live with all-lower-case AND a predefined order.


Well, now it's backwards-compatibility.


Huh? There are no fb strings yet.

Best,
Sven
___
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 ...

2015-10-22 Thread Stéphane Wirtel 
Thank you Brett,

I am going to read the source code, I am going to give a presentation at 
PyCon.IE about this part and I wanted to be sure about the dead branches.

Thanks

On 22 Oct 2015, at 19:02, Brett Cannon wrote:

> On Thu, 22 Oct 2015 at 09:37 Stéphane Wirtel  wrote:
>
>> Hi all,
>>
>> When we compile a python script
>>
>> # test.py
>> if 0:
>>   x = 1
>>
>> python -mdis test.py
>>
>> There is no byte code for the condition.
>>
>> 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.
>
>
>>
>> What are the cases where the generator does not generate the byte codes ?
>>
>
> 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.


--
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] Should PEP 498 specify if rf'...' is valid?

2015-10-22 Thread Ryan Gonzalez 
But it'd be weird now if fR worked but fbR didn't.

On Thu, Oct 22, 2015 at 12:02 PM, Sven R. Kunze  wrote:

> On 22.10.2015 18:17, Ryan Gonzalez wrote:
>
>>
>>> anything about it. 'FbR', really?

>>> Why not disallowing them?
>>>
>>> I for one could live with all-lower-case AND a predefined order.
>>>
>>> Well, now it's backwards-compatibility.
>>
>
> Huh? There are no fb strings yet.
>
> Best,
> Sven
>



-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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] Should PEP 498 specify if rf'...' is valid?

2015-10-22 Thread Eric V. Smith 
On 10/22/2015 1:09 PM, Ryan Gonzalez wrote:
> But it'd be weird now if fR worked but fbR didn't.

Or bR (which is currently allowed) but not fbR in the future.

Eric.

> 
> On Thu, Oct 22, 2015 at 12:02 PM, Sven R. Kunze  > wrote:
> 
> On 22.10.2015 18:17, Ryan Gonzalez wrote:
> 
> 
> anything about it. 'FbR', really?
> 
> Why not disallowing them?
> 
> I for one could live with all-lower-case AND a predefined order.
> 
> Well, now it's backwards-compatibility.
> 
> 
> Huh? There are no fb strings yet.
> 
> Best,
> Sven
> 
> 
> 
> 
> -- 
> Ryan
> [ERROR]: Your autotools build scripts are 200 lines longer than your
> program. Something’s wrong.
> http://kirbyfan64.github.io/
>  
> 
> 
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.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

Re: [Python-Dev] Generated Bytecode ...

2015-10-22 Thread Brett Cannon 
On Thu, 22 Oct 2015 at 09:37 Stéphane Wirtel  wrote:

> Hi all,
>
> When we compile a python script
>
> # test.py
> if 0:
> x = 1
>
> python -mdis test.py
>
> There is no byte code for the condition.
>
> 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.


>
> What are the cases where the generator does not generate the byte codes ?
>

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.
___
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] Should PEP 498 specify if rf'...' is valid?

2015-10-22 Thread Sven R. Kunze 

Yeah, that would be weird.

Really? That's ridiculous. We don't allow DEF or DeF for function 
definitions either. So, I don't see any value in it.



IMHO, It's time for a clean up again.


On 22.10.2015 19:09, Ryan Gonzalez wrote:

But it'd be weird now if fR worked but fbR didn't.

On Thu, Oct 22, 2015 at 12:02 PM, Sven R. Kunze > wrote:


On 22.10.2015 18:17, Ryan Gonzalez wrote:


anything about it. 'FbR', really?

Why not disallowing them?

I for one could live with all-lower-case AND a predefined
order.

Well, now it's backwards-compatibility.


Huh? There are no fb strings yet.



Best,
Sven
___
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

2015-10-22 Thread Guido van Rossum 
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)
___
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 ...

2015-10-22 Thread R. David Murray 
On Thu, 22 Oct 2015 17:02:48 -, Brett Cannon  wrote:
> On Thu, 22 Oct 2015 at 09:37 Stéphane Wirtel  wrote:
> 
> > Hi all,
> >
> > When we compile a python script
> >
> > # test.py
> > if 0:
> > x = 1
> >
> > python -mdis test.py
> >
> > There is no byte code for the condition.
> >
> > 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.

There's an issue (http://bugs.python.org/issue2506) for being able to
disable all optimizations (that Ned Batchelder, among others, would really
like to see happen :).  Raymond rejected it as not being worthwhile.

I still agree with Ned and others that there should, just on principle,
be a way to disable all optimizations.  Most (all?) compilers have such
a feature, for debugging reasons if nothing else.  We even have a way
to spell it in the generated byte code files now (opt-0).  But, someone
would have to champion it and write a patch proposal.

--David
___
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 ...

2015-10-22 Thread Terry Reedy 

On 10/22/2015 1:56 PM, R. David Murray wrote:

On Thu, 22 Oct 2015 17:02:48 -, Brett Cannon  wrote:

On Thu, 22 Oct 2015 at 09:37 Stéphane Wirtel  wrote:


Hi all,

When we compile a python script

# test.py
if 0:
 x = 1

python -mdis test.py

There is no byte code for the condition.


The code above is logically equivalent to 'pass'.  CPython could compile 
'pass' (or code equivalent to it) to the NOP bytecode, but I believe it 
does not.  (The doc implies that NOP is only introduced by the peephole 
optimizer as a replacement for other statements.)



So my question is,

>>> the byte code generator removes the unused functions, variables etc…,

It does not do this.

>>> def f(): a=111

>>> dis(f)
  1   0 LOAD_CONST   1 (111)
  3 STORE_FAST   0 (a)
  6 LOAD_CONST   0 (None)
  9 RETURN_VALUE

A code checker might report that a in unused, suggesting that you remove 
the assignment manually, but python does not do it for you.


>>> is it right?

It depends on whether one philosophically considers the meaning of 
python code to be a particular computational operation or a particular 
computational result.  From the former viewpoint, one might think or 
want the useless assignment.  From the latter viewpoint, in this 
particular context, deleting the assignment statement would be correct. 
 But this is too sophisticated a judgement for CPython's simple code 
improvement.


The philosophical question is illustrated by "What is the meaning of 
'2+2'?".  Does it mean 'get 2 and add 2' (and if so, when must this be 
done)?  Does it mean '4'?  Current constant folding at the AST or 
pre-bytecode stage presumes that the answer '4', at runtime, is adequate.


Indeed, whether 'pass' should be compiled to 'NOP' or nothing depends on 
one's view of the meaning of pass and whether it must be executed (by 
going though the ceval loop once and doing nothing) or not.



Technically the peepholer removes the dead branch,

>> but since the peepholer is run on all bytecode you can't avoid it.


There's an issue (http://bugs.python.org/issue2506) for being able to
disable all optimizations (that Ned Batchelder, among others, would really


Ned initially just asked for the peephole optimizer to be disabled, 
which is specific and concrete.  He then seemed to ask to be able to 
disable 'all optimizations'.  This is somewhat vague and presupposed a 
baseline of no optimizations, which is not practical.



like to see happen :).  Raymond rejected it as not being worthwhile.


He noted that there are multiple costs for implementation, maintenance, 
documentation, and testing.  Also that most things currently done by the 
peephole optimizer, after code is generated, could be done before or as 
code is generated, and that one cost might be to make better code 
generation more difficult.



I still agree with Ned and others that there should, just on principle,
be a way to disable all optimizations.


The question is what counts as an optimization? Generating byte code is 
not part of the language. It could be considered a CPython optimization 
versus storing the original text or an ast version thereof.  This is not 
practical.


More realistic: would you have the optimization of no code for 'pass' 
disabled?  Or how about constant folding? Or the optimization of having 
successive string literals pasted together in the parser, rather than 
later in the total process?  (I believe I have read that this is where 
it currently happens.)  My point here is that optimizations are spread 
throughout the chain from code to result.



 Most (all?) compilers have such
a feature, for debugging reasons if nothing else.


Compilers that make iffy assumptions and do non-equivalent 
transformations to produce faster code, at the cost of breaking some 
legal code, must have a means to disable such assumptions and 
transformations.  Or rather, such optimizations should be off by 
default.  Each optimization level defines a subset of the language for 
which the assumptions and transformations are valid.


For CPython, it has been proposed that there should be optional 
optimization levels that assume that some dynamic features are not being 
used: the builtins module is not modified; built-in objects are not 
masked; modules are not monkey patched.  Guido has so far rejected the 
idea of such language-subsetting optimizations.


My strong impression is that the -O0 'no optimization' level of modern 
compilers (for C, for instance) *generally* means 'no potentially 
dangerous and wrong optimizations' and that they in fact include many 
safe optimizations relative to compilers of a few decades ago.  I am 
sure that there is no way to disable many of the safe optimizations that 
are now so taken for granted that they are 'normal' and not seen as 
'optimizations'.  In other words, I believe that the meaning of 'no 
optimizations' has evolved.

Re: [Python-Dev] Generated Bytecode ...

2015-10-22 Thread Chris Angelico 
On Fri, Oct 23, 2015 at 3:05 PM, Terry Reedy  wrote:
> Indeed, whether 'pass' should be compiled to 'NOP' or nothing depends on
> one's view of the meaning of pass and whether it must be executed (by going
> though the ceval loop once and doing nothing) or not.

Hmm. I thought 'pass' was a syntactic element, not an executable
statement. For instance, these functions all contain the same code:

def f1():
pass

def f2():
"""docstring"""

def f3():
return None

def f4():
global foo

Or is there something I'm misunderstanding here?

ChrisA
___
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