Re: [Python-Dev] Modify PyMem_Malloc to use pymalloc for performance

[Victor Stinner]

2016-02-04 15:05 GMT+01:00 M.-A. Lemburg :
> Sometimes, yes, but we also do allocations for e.g.
> parsing values in Python argument tuples (e.g. using
> "es" or "et"):
>
> https://docs.python.org/3.6/c-api/arg.html
>
> We do document to use PyMem_Free() on those; not sure whether
> everyone does this though.

It's well documented. If programs start to crash, they must be fixed.

I don't propose to "break the API" for free, but to get a speedup on
the overall Python.

And I don't think that we can say that it's an API change, since we
already stated that PyMem_Free() must be used.

If your program has bugs, you can use a debug build of Python 3.5 to
detect misusage of the API.


> The Python test suite doesn't test Python C extensions,
> so it's not surprising that it passes :-)

What do you mean by "C extensions"? Which modules?

Many modules in the stdlib have "C accelerators" and the PEP 399 now
*require* to test the C and Python implementations.



>> Instead of teaching developers that well, in fact, PyObject_Malloc()
>> is unrelated to object programming, I think that it's simpler to
>> modify PyMem_Malloc() to reuse pymalloc ;-)
>
> Perhaps if you add some guards somewhere :-)

We have runtime checks but only implemented in debug mode for efficiency.

By the way, I proposed once to add an environment variable to allow to
enable these checks without having to recompile Python.  Since the PEP
445, it became easy to implement this. What do you think?
https://www.python.org/dev/peps/pep-0445/#add-a-new-pydebugmalloc-environment-variable

"This alternative was rejected because a new environment variable
would make Python initialization even more complex. PEP 432 tries to
simplify the CPython startup sequence."

The PEP 432 looks stuck, so I don't think that we should block
enhancements because of this PEP. Anyway, my idea should be easy to
implement.


> Seriously, this may work if C extensions use the APIs
> consistently, but in order to tell, we'd need to check
> few.

Can you suggest me names of projects that must be tested?


> I guess the main question then is whether pymalloc is good enough
> for general memory allocation needs; and the answer may well be
> "yes".

What do you mean by "good enough"? For the runtime performance,
pymalloc looks to be faster than malloc(). What are your other
criterias? Memory fragmentation?


Victor
___
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] Modify PyMem_Malloc to use pymalloc for performance

[Victor Stinner]

2016-02-07 9:22 GMT+01:00 Stefan Behnel :
> Note that the PyObject_Malloc() functions have never been documented.

Yeah, there is an old bug to track this:
http://bugs.python.org/issue20064

> And, for example, the "what's new in 2.5" document says:
>
> """
> Python’s API has many different functions for allocating memory that are
> grouped into families. For example, PyMem_Malloc(), PyMem_Realloc(), and
> PyMem_Free() are one family that allocates raw memory, while
> PyObject_Malloc(), PyObject_Realloc(), and PyObject_Free() are another
> family that’s supposed to be used for creating Python objects.
> """
>
> I don't think there are many extensions out there in which *object* memory
> gets allocated manually, which implicitly puts a pretty clear "don't use"
> marker on these functions.

Should I understand that it's another good reason to make
PyMem_Malloc() faster for everyone?

Victor
___
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] Windows: Remove support of bytes filenames in the os module?

[Victor Stinner]

Hi,

Since 3.3, functions of the os module started to emit
DeprecationWarning when called with bytes filenames.

The rationale is quite simple: Windows native type for filenames is
Unicode, and the Windows has a weird behaviour when you use bytes. For
example, os.listdir(b'.') gives you paths which cannot be used with
open() on filenames which are not encodable the ANSI code page.
Unencodable characters are replaced with "?". The following issue was
opened to document this weird behaviour (but the doc was never
completed):

"Document that bytes OS API can returns unusable results on Windows"
http://bugs.python.org/issue16700


When the new os.scandir() API was designed, I asked to *not* support
bytes filenames since they are "broken by design".
https://www.python.org/dev/peps/pep-0471/

Recently, an user complained that os.walk() doesn't work with bytes on
Windows anymore:

"Regression: os.walk now using os.scandir() breaks bytes filenames on windows"
http://bugs.python.org/issue25911


Serhiy Storchaka just pushed a change to reintroduce support bytes
support on Windows in os.walk(), but I would prefer to do the
*opposite*: drop supports for bytes filenames on Windows.

Are we brave enough to force users to use the "right" type for filenames?

--

On Python 2, it wasn't possible to use Unicode for filenames, many
functions fail badly with Unicode, especially when you mix bytes and
Unicode.

On Python 3, Unicode is the "natural" types, most Python functions
prefer Unicode, and the PEP 383 (surrogateescape) allows to safetely
use Unicode on UNIX even with undecodable filenames (invalid bytes are
stored as Unicode surrogate characters).

Victor
___
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] Windows: Remove support of bytes filenames in the os module?

[Victor Stinner]

2016-02-08 15:32 GMT+01:00 Victor Stinner :
> Since 3.3, functions of the os module started to emit
> DeprecationWarning when called with bytes filenames.
> (...)
> Recently, an user complained that os.walk() doesn't work with bytes on
> Windows anymore:
> (...)

It's also sad to see that deprecation warnings are completly ignored.
Python 3.3 was release in 2011, 5 years ago.

I would prefer to show deprecation warnings by default. But I know
that it's an old debate: developers vs users :-) I like to see my
users as potential developers ;-)

Victor
___
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] Windows: Remove support of bytes filenames in the os module?

[Matthias Bussonnier]

> On Feb 8, 2016, at 06:40, Victor Stinner  wrote:
> 
> 2016-02-08 15:32 GMT+01:00 Victor Stinner :
>> Since 3.3, functions of the os module started to emit
>> DeprecationWarning when called with bytes filenames.
>> (...)
>> Recently, an user complained that os.walk() doesn't work with bytes on
>> Windows anymore:
>> (...)
> 
> It's also sad to see that deprecation warnings are completly ignored.
> Python 3.3 was release in 2011, 5 years ago.

> 
> I would prefer to show deprecation warnings by default. But I know
> that it's an old debate: developers vs users :-) I like to see my
> users as potential developers ;-)


This is tracked in this issue:

http://bugs.python.org/issue24294  :  
DeprecationWarnings should be visible by default in the interactive REPL

IPython have enabled them only if they come from __main__. From totally 
subjective experience, 
that has already pushed a few library to update their code to new apis[1].
-- 
M

[1] or sometime to wrap code in ignore warnings...



> 
> Victor
> ___
> 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/bussonniermatthias%40gmail.com

___
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] Improving docs for len() of set

[Ben Hoyt]

Hi folks,

Just a suggestion for a documentation tweak. Currently the docs for len()
on a set say this:

   .. describe:: len(s)

  Return the cardinality of set *s*.

I'm a relatively seasoned programmer, but I don't really have a maths
background, and I didn't know what "cardinality" meant. I could kind of
grok it by context, but could we change this to something like the
following?

   .. describe:: len(s)

  Return the number of elements in set *s* (cardinality of *s*).

Happy to open a bugs.python.org issue on this, but wanted to get general
consensus first.

-Ben
___
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] Improving docs for len() of set

[Ethan Furman]

On 02/08/2016 08:23 AM, Ben Hoyt wrote:

> .. describe:: len(s)
>
>Return the number of elements in set *s* (cardinality of *s*).

 Return the number of elements (cardinality) of *s*.

+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] Improving docs for len() of set

[Lorenzo Moriondo]

@Ben I am not either a great fan of formal (mathematic) definitions (:

Lorenzo Moriondo, from mobile
~~it.linkedin.com~in~lorenzomoriondo~~
On Feb 8, 2016 5:38 PM, "Ethan Furman"  wrote:
>
> On 02/08/2016 08:23 AM, Ben Hoyt wrote:
>
> > .. describe:: len(s)
> >
> >Return the number of elements in set *s* (cardinality of *s*).
>
>  Return the number of elements (cardinality) of *s*.
>
> +1

+1 to this for me as well

>
> --
> ~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/tunedconsulting%40gmail.com
___
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] Improving docs for len() of set

[Andrew Barnert via Python-Dev]

On Monday, February 8, 2016 8:23 AM, Ben Hoyt  wrote:


>Just a suggestion for a documentation tweak. Currently the docs for len() on a 
>set say this:

>
>   .. describe:: len(s)>
>  Return the cardinality of set *s*.
>
>I'm a relatively seasoned programmer, but I don't really have a maths 
>background, and I didn't know what "cardinality" meant. I could kind of grok 
>it by context, but could we change this to something like the following?
>
>   .. describe:: len(s)
>
>  Return the number of elements in set *s* (cardinality of *s*).


+{{}}

(using the normal von Neumann definitions for 0={} and Succ(n) = n U {n})
___
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] Improving docs for len() of set

[Ethan Furman]

On 02/08/2016 08:49 AM, Andrew Barnert via Python-Dev wrote:

> +{{}}
>
> (using the normal von Neumann definitions for 0={} and
> Succ(n) = n U {n})

I'm glad you know what you meant, 'cause I haven't got a clue!

:)

--
~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] Windows: Remove support of bytes filenames in the os module?

[Brett Cannon]

On Mon, 8 Feb 2016 at 06:33 Victor Stinner  wrote:

> Hi,
>
> Since 3.3, functions of the os module started to emit
> DeprecationWarning when called with bytes filenames.
>
> The rationale is quite simple: Windows native type for filenames is
> Unicode, and the Windows has a weird behaviour when you use bytes. For
> example, os.listdir(b'.') gives you paths which cannot be used with
> open() on filenames which are not encodable the ANSI code page.
> Unencodable characters are replaced with "?". The following issue was
> opened to document this weird behaviour (but the doc was never
> completed):
>
> "Document that bytes OS API can returns unusable results on Windows"
> http://bugs.python.org/issue16700
>
>
> When the new os.scandir() API was designed, I asked to *not* support
> bytes filenames since they are "broken by design".
> https://www.python.org/dev/peps/pep-0471/
>
> Recently, an user complained that os.walk() doesn't work with bytes on
> Windows anymore:
>
> "Regression: os.walk now using os.scandir() breaks bytes filenames on
> windows"
> http://bugs.python.org/issue25911
>
>
> Serhiy Storchaka just pushed a change to reintroduce support bytes
> support on Windows in os.walk(), but I would prefer to do the
> *opposite*: drop supports for bytes filenames on Windows.
>
> Are we brave enough to force users to use the "right" type for filenames?
>
> --
>
> On Python 2, it wasn't possible to use Unicode for filenames, many
> functions fail badly with Unicode, especially when you mix bytes and
> Unicode.
>
> On Python 3, Unicode is the "natural" types, most Python functions
> prefer Unicode, and the PEP 383 (surrogateescape) allows to safetely
> use Unicode on UNIX even with undecodable filenames (invalid bytes are
> stored as Unicode surrogate characters).
>

If Unicode string don't work in Python 2 then what is Python 2/3 to do as a
cross-platform solution if we completely remove bytes support in Python 3?
Wouldn't that mean there is no common type between Python 2 & 3 that one
can use which will work with the os module except native strings (which are
difficult to get right)?
___
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] Windows: Remove support of bytes filenames in the os module?

[Alexander Walters]

On 2/8/2016 12:02, Brett Cannon wrote:



If Unicode string don't work in Python 2 then what is Python 2/3 to do 
as a cross-platform solution if we completely remove bytes support in 
Python 3? Wouldn't that mean there is no common type between Python 2 
& 3 that one can use which will work with the os module except native 
strings (which are difficult to get right)?


The only solution then would be to do `if not PY3: arg = 
arg.encode(...);; os.SOMEFUNC(arg)`, pardon my psudocode.  Its annoying, 
but at least its not a language syntax change which means it isn't 
intractable, just an annoying roadblock.  If I had my druthers it would 
be put off until after 2.x is well and truly dead.


___
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] HackIllinois 2016 + Python

[Kevin Hong]

Hi all!

My name is Kevin and I am a staff member of HackIllinois, a 36-hour
hackathon at the University of Illinois Urbana-Champaign where students
from across the nation come to build some of the most innovative hardware
and software projects. For highlights from last year’s event, check out
go.hackillinois.org/video.

>From February 19-21st 2016, HackIllinois returns and we are introducing a
new initiative called OpenSource@HackIllinois to promote Open Source
development during the event. This program is designed to provide students
with the opportunity to meet and collaborate with experienced developers,
like you all, who serve as a guide and mentor into the open source world.
Over the course of the event, you and your group of hackers will build
features for an open source project of your choosing. Please see
http://www.hackillinois.org/opensource for more details!

If you or any other open source developers you work with are interested in
learning more about OpenSource@HackIllinois, feel free to email me at
kevin.h...@hackillinois.org. I look forward to speaking with you soon!

Best Regards,

Kevin Hong
___
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] HackIllinois 2016 + Python

[Alexander Walters]

Hello.  You might want to post this in the psf-community list too. There 
are a lot of open source developers in the community they are not 
working directly on CPython (what this list is about).


On 2/8/2016 12:19, Kevin Hong wrote:

Hi all!

My name is Kevin and I am a staff member of HackIllinois, a 36-hour 
hackathon at the University of Illinois Urbana-Champaign where 
students from across the nation come to build some of the most 
innovative hardware and software projects. For highlights from last 
year’s event, check outgo.hackillinois.org/video 
.


From February 19-21st 2016, HackIllinois returns and we are 
introducing a new initiative called OpenSource@HackIllinois to promote 
Open Source development during the event. This program is designed to 
provide students with the opportunity to meet and collaborate with 
experienced developers, like you all, who serve as a guide and mentor 
into the open source world. Over the course of the event, you and your 
group of hackers will build features for an open source project of 
your choosing. Please see http://www.hackillinois.org/opensource for 
more details!


If you or any other open source developers you work with are 
interested in learning more about OpenSource@HackIllinois, feel free 
to email me at kevin.h...@hackillinois.org 
. I look forward to speaking with 
you soon!


Best Regards,

Kevin Hong




___
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/tritium-list%40sdamon.com


___
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] PEP 0492 __aenter__ & __aexit__

[Yury Selivanov]

Brett,

Do you think we should update PEP 492 with links to the docs?  I'm 
thinking of adding a new section to the top.


Yury

On 2016-02-06 5:05 PM, Brett Cannon wrote:



On Sat, 6 Feb 2016 at 13:50 Daniel Miller > wrote:


Hi Python-Dev Group,

I am trying to implement __aenter__ and __aexit__ for the
RethinkDB  Python driver. Looking at the
PEP I don't see any definitions as to what the expected parameters
that __exit__ are supposed to take and couldn't find any other
similar implementations. Is there a piece of documentation I
should be looking at that I'm missing?


https://www.python.org/dev/peps/pep-0492/#asynchronous-context-managers-and-async-with


The arguments to __aexit__ are the same as __exit__ in a normal 
context manager. See 
https://docs.python.org/3.5/reference/datamodel.html#object.__aexit__ for 
the official docs for __aexit__.



___
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/yselivanov.ml%40gmail.com


___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Victor Stinner]

Hi,

I changed the Python compiler to ignore any kind "constant
expressions", whereas it only ignored strings and integers before:
http://bugs.python.org/issue26204

The compiler now also emits a SyntaxWarning on such case. IMHO the
warning can help to detect bugs for developers who just learnt Python.

The warning is *not* emited for strings, since triple quoted strings
are a common syntax for multiline comments.

The warning is *not* emited neither for ellispis (...) since "f():
..." is a legit syntax for abstract function.

Are you ok with the new warning?


New behaviour:

haypo@smithers$ ./python
Python 3.6.0a0 (default:759a975e1230, Feb  8 2016, 18:21:23)
>>> def f():
...  False
...
:2: SyntaxWarning: ignore constant statement

>>> import dis; dis.dis(f)
  2   0 LOAD_CONST   0 (None)
  3 RETURN_VALUE


Old behaviour:

haypo@smithers$ python3
Python 3.4.3 (default, Jun 29 2015, 12:16:01)
>>> def f():
...  False
...
>>> import dis; dis.dis(f)
  2   0 LOAD_CONST   1 (False)
  3 POP_TOP
  4 LOAD_CONST   0 (None)
  7 RETURN_VALUE



Before strings and numbers were already ignored. Example:

haypo@smithers$ python3
Python 3.4.3 (default, Jun 29 2015, 12:16:01)

>>> def f():
...  123
...
>>> import dis; dis.dis(f)
  2   0 LOAD_CONST   0 (None)
  3 RETURN_VALUE


Victor
___
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] Improving docs for len() of set

[Gregory P. Smith]

On Mon, Feb 8, 2016 at 8:24 AM Ben Hoyt  wrote:

> Hi folks,
>
> Just a suggestion for a documentation tweak. Currently the docs for len()
> on a set say this:
>
>.. describe:: len(s)
>
>   Return the cardinality of set *s*.
>
> I'm a relatively seasoned programmer, but I don't really have a maths
> background, and I didn't know what "cardinality" meant. I could kind of
> grok it by context, but could we change this to something like the
> following?
>
>.. describe:: len(s)
>
>   Return the number of elements in set *s* (cardinality of *s*).
>
>
Agreed. Done. :)

-gps
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[francismb]

Hi,

On 02/08/2016 06:44 PM, Victor Stinner wrote:
> Hi,
> 
> I changed the Python compiler to ignore any kind "constant
> expressions", whereas it only ignored strings and integers before:
> http://bugs.python.org/issue26204
> 
> The compiler now also emits a SyntaxWarning on such case. IMHO the
> warning can help to detect bugs for developers who just learnt Python.
> 
[...]
> New behaviour:
>
> haypo@smithers$ ./python
> Python 3.6.0a0 (default:759a975e1230, Feb  8 2016, 18:21:23)
 def f():
> ...  False
> ...
> :2: SyntaxWarning: ignore constant statement
>


Just for my understanding:

What would happen if someone has functions where some return
constant expressions and others not and then that functions
are used depending on some other context. E.g:


def behaviour2(ctx):
   return 1

def behaviour1(ctx):
   return some_calculation_with(ctx)


[...]

if ... :
  return behaviour1(ctx)
else :
  return behaviour2()


Is that going to raise a warning?


Thanks in advance!
francis

___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Gregory P. Smith]

On Mon, Feb 8, 2016 at 9:44 AM Victor Stinner 
wrote:

> Hi,
>
> I changed the Python compiler to ignore any kind "constant
> expressions", whereas it only ignored strings and integers before:
> http://bugs.python.org/issue26204
>
> The compiler now also emits a SyntaxWarning on such case. IMHO the
> warning can help to detect bugs for developers who just learnt Python.
>
> The warning is *not* emited for strings, since triple quoted strings
> are a common syntax for multiline comments.
>
> The warning is *not* emited neither for ellispis (...) since "f():
> ..." is a legit syntax for abstract function.
>
> Are you ok with the new warning?
>

I'm +1 on this.

-gps


>
>
> New behaviour:
>
> haypo@smithers$ ./python
> Python 3.6.0a0 (default:759a975e1230, Feb  8 2016, 18:21:23)
> >>> def f():
> ...  False
> ...
> :2: SyntaxWarning: ignore constant statement
>
> >>> import dis; dis.dis(f)
>   2   0 LOAD_CONST   0 (None)
>   3 RETURN_VALUE
>
>
> Old behaviour:
>
> haypo@smithers$ python3
> Python 3.4.3 (default, Jun 29 2015, 12:16:01)
> >>> def f():
> ...  False
> ...
> >>> import dis; dis.dis(f)
>   2   0 LOAD_CONST   1 (False)
>   3 POP_TOP
>   4 LOAD_CONST   0 (None)
>   7 RETURN_VALUE
>
>
>
> Before strings and numbers were already ignored. Example:
>
> haypo@smithers$ python3
> Python 3.4.3 (default, Jun 29 2015, 12:16:01)
>
> >>> def f():
> ...  123
> ...
> >>> import dis; dis.dis(f)
>   2   0 LOAD_CONST   0 (None)
>   3 RETURN_VALUE
>
>
> Victor
> ___
> 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/greg%40krypto.org
>
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Ethan Furman]

On 02/08/2016 10:00 AM, francismb wrote:
> On 02/08/2016 06:44 PM, Victor Stinner wrote:

>> I changed the Python compiler to ignore any kind "constant
>> expressions", whereas it only ignored strings and integers before:
>> http://bugs.python.org/issue26204
>>
>> The compiler now also emits a SyntaxWarning on such case. IMHO the
>> warning can help to detect bugs for developers who just learnt
>> Python.
>>
> [...]
>> New behaviour:
>>
>> haypo@smithers$ ./python
>> Python 3.6.0a0 (default:759a975e1230, Feb  8 2016, 18:21:23)
>> --> def f():
>> ...  False
>> ...
>> :2: SyntaxWarning: ignore constant statement
>
> Just for my understanding:
>
> What would happen if someone has functions where some return
> constant expressions and others not and then that functions
> are used depending on some other context. E.g:
>
> def behaviour2(ctx):
> return 1
>
> def behaviour1(ctx):
> return some_calculation_with(ctx)
>
>
> [...]
>
> if ... :
>return behaviour1(ctx)
> else :
>return behaviour2()
>
>
> Is that going to raise a warning?

No, because those constants are being used (returned).  Only constants 
that aren't used at all get omitted.


--
~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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Ethan Furman]

On 02/08/2016 09:44 AM, Victor Stinner wrote:

> Are you ok with the new warning?

+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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[xiscu]

>> New behaviour:
>>
>> haypo@smithers$ ./python
>> Python 3.6.0a0 (default:759a975e1230, Feb  8 2016, 18:21:23)
> def f():
>> ...  False
>> ...

Ok, I see in your case there's no return :-)

___
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] Windows: Remove support of bytes filenames in the os module?

[Andrew Barnert via Python-Dev]

On Monday, February 8, 2016 9:11 AM, Alexander Walters 
 wrote:


> 
> On 2/8/2016 12:02, Brett Cannon wrote:
>> 
>> 
>>  If Unicode string don't work in Python 2 then what is Python 2/3 to do 
>>  as a cross-platform solution if we completely remove bytes support in 
>>  Python 3? Wouldn't that mean there is no common type between Python 2 
>>  & 3 that one can use which will work with the os module except native 
>>  strings (which are difficult to get right)?
> 
> The only solution then would be to do `if not PY3: arg = 
> arg.encode(...);; os.SOMEFUNC(arg)`, pardon my psudocode.  
That's exactly what you _don't_ want to do.

More generally, the assumption here is wrong. 

It's not true that you can't use Unicode for Window filenames on Python 2. What 
is true is that you have to be a lot more careful about using Unicode 
_consistently_. And that Python 2 gives you very little help in doing so. And 
some third-party modules may make it harder on you. But if you always use 
unicode, `os.listdir(u'.')` calls FindFirstFileW instead of FindFirstFileA and 
gives you back unicode filenames, os.stat or open call _wstat or _wopen with 
those unicode filenames, etc.

The problem is that on POSIX, you're often better off using str everywhere, 
because Python 2.7 doesn't do surrogate escape. And once you're using str on 
one platform/unicode on the other for filenames, it gets very easy to mix str 
and unicode in other places (like strings you want to print out for the user or 
store in a database), and then you're in mojibake hell.

The io module, the pathlib backport, and six can help a bit (at the cost of 
performance and/or simplicity), but there's no easy answer--if there _were_ an 
easy answer, we wouldn't have Python 3 in the first place, right?
___
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] PEP 0492 __aenter__ & __aexit__

[Brett Cannon]

On Mon, 8 Feb 2016 at 09:34 Yury Selivanov  wrote:

> Brett,
>
> Do you think we should update PEP 492 with links to the docs?  I'm
> thinking of adding a new section to the top.
>

Probably. Links around the Internet, search engines, etc. will point to the
PEP for a while, and so knowing that the most up-to-date info is actually
the docs and not the PEP would be good. I honestly just know all of this
stuff because of a massive blog post I'm writing on async/await ATM.

-Brett


>
> Yury
>
> On 2016-02-06 5:05 PM, Brett Cannon wrote:
> >
> >
> > On Sat, 6 Feb 2016 at 13:50 Daniel Miller  > > wrote:
> >
> > Hi Python-Dev Group,
> >
> > I am trying to implement __aenter__ and __aexit__ for the
> > RethinkDB  Python driver. Looking at the
> > PEP I don't see any definitions as to what the expected parameters
> > that __exit__ are supposed to take and couldn't find any other
> > similar implementations. Is there a piece of documentation I
> > should be looking at that I'm missing?
> >
> >
> https://www.python.org/dev/peps/pep-0492/#asynchronous-context-managers-and-async-with
> >
> >
> > The arguments to __aexit__ are the same as __exit__ in a normal
> > context manager. See
> > https://docs.python.org/3.5/reference/datamodel.html#object.__aexit__
> for
> > the official docs for __aexit__.
> >
> >
> > ___
> > 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/yselivanov.ml%40gmail.com
>
> ___
> 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/brett%40python.org
>
___
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] Syntax Highlightning for C API of CPython in VIM

[Stephane Wirtel]

Hi everyone,

With my talk "Exploring our Python Interpreter", I think this VIM plugin 
can be useful for the community. It's a syntax highlighter for the C API 
of CPython 3.5 and 3.6. I used Clang for the parsing and automatically 
generated the keywords for VIM.


PyObject and the others typedefs of CPython will have the defined color 
of your favourite editor and it's the same for the enums, the typedefs, 
the functions and the macros.


Where can you use this VIM plugin ? If you want to write a CPython 
extension or if you want to hack in the CPython code.


Check this screenshot: http://i.imgur.com/0k13KOU.png

Here is the repository:

https://github.com/matrixise/cpython-vim-syntax

Please, if you see some issues, tell me via an issue on Github.

Thank you so much,

Stephane

--
Stéphane Wirtel - http://wirtel.be - @matrixise
___
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] Windows: Remove support of bytes filenames in the os module?

[Paul Moore]

On 8 February 2016 at 14:32, Victor Stinner  wrote:
> Since 3.3, functions of the os module started to emit
> DeprecationWarning when called with bytes filenames.

Everywhere? Or just on Windows? I can't tell from your email and I
don't have a Unix system to hand to check.

> The rationale is quite simple: Windows native type for filenames is
> Unicode, and the Windows has a weird behaviour when you use bytes. For
> example, os.listdir(b'.') gives you paths which cannot be used with
> open() on filenames which are not encodable the ANSI code page.
> Unencodable characters are replaced with "?". The following issue was
> opened to document this weird behaviour (but the doc was never
> completed):
>
> "Document that bytes OS API can returns unusable results on Windows"
> http://bugs.python.org/issue16700

OK, that seems fine, but obviously of limited interest to Unix users
who aren't worried about cross-platform portability :-)

> When the new os.scandir() API was designed, I asked to *not* support
> bytes filenames since they are "broken by design".
> https://www.python.org/dev/peps/pep-0471/
>
> Recently, an user complained that os.walk() doesn't work with bytes on
> Windows anymore:
>
> "Regression: os.walk now using os.scandir() breaks bytes filenames on windows"
> http://bugs.python.org/issue25911
>
> Serhiy Storchaka just pushed a change to reintroduce support bytes
> support on Windows in os.walk(), but I would prefer to do the
> *opposite*: drop supports for bytes filenames on Windows.

But leave those APIs as Unix only? That seems like a regression, too
(sure, the bytes APIs are problematic on Windows, but only for certain
characters AIUI). Windows users currently using programs written using
the bytes API (presumably originally intended for Unix where the bytes
API was a deliberate choice), who don't hit any encoding issues
currently, will see those programs broken for no reason other than
"users using different character sets than you may have been hitting
issues before". That seems like a weird justification to me...

> Are we brave enough to force users to use the "right" type for filenames?

If it were *all* users I'd say it's worth considering. But
practicality beats purity here IMO, and I feel that allowing people's
code to be "portable by default" is a more important goal than
enforcing encoding purity on a single platform.

Paul
___
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] speed.python.org

[Yury Selivanov]

Zachary,

Do you run the benchmarks in rigorous mode?

Yury

On 2016-02-04 1:48 AM, Zachary Ware wrote:

I'm happy to announce that speed.python.org is finally functional!
There's not much there yet, as each benchmark builder has only sent
one result so far (and one of those involved a bit of cheating on my
part), but it's there.

There are likely to be rough edges that still need smoothing out.
When you find them, please report them at
https://github.com/zware/codespeed/issues or on the sp...@python.org
mailing list.

Many thanks to Intel for funding the work to get it set up and to
Brett Cannon and Benjamin Peterson for their reviews.

Happy benchmarking,


___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Guido van Rossum]

On Mon, Feb 8, 2016 at 9:44 AM, Victor Stinner  wrote:
> I changed the Python compiler to ignore any kind "constant
> expressions", whereas it only ignored strings and integers before:
> http://bugs.python.org/issue26204
>
> The compiler now also emits a SyntaxWarning on such case. IMHO the
> warning can help to detect bugs for developers who just learnt Python.

Hum. I'm not excited by this idea. It is not bad syntax. Have you
actually seen newbies who were confused by such things?

-- 
--Guido van Rossum (python.org/~guido)
___
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] speed.python.org

[Zachary Ware]

On Mon, Feb 8, 2016 at 1:09 PM, Yury Selivanov  wrote:
> Zachary,
>
> Do you run the benchmarks in rigorous mode?

Not currently.  I think I need to reschedule when the benchmarks are
run anyway, to avoid conflicts with PyPy's usage of that box, and will
add rigorous mode when I do that.

-- 
Zach
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Andrew Barnert via Python-Dev]

> On Feb 8, 2016, at 11:13, Guido van Rossum  wrote:
> 
>> On Mon, Feb 8, 2016 at 9:44 AM, Victor Stinner  
>> wrote:
>> I changed the Python compiler to ignore any kind "constant
>> expressions", whereas it only ignored strings and integers before:
>> http://bugs.python.org/issue26204
>> 
>> The compiler now also emits a SyntaxWarning on such case. IMHO the
>> warning can help to detect bugs for developers who just learnt Python.
> 
> Hum. I'm not excited by this idea. It is not bad syntax. Have you
> actually seen newbies who were confused by such things?

This does overlap to some extent with a problem that newbies *do* get confused 
by (and that transplants from Ruby don't find confusing, but do keep 
forgetting): writing an expression as the last statement in a function and then 
getting a TypeError or AttributeError about NoneType from the caller. Victor's 
example of a function that was presumably meant to return False, but instead 
just evaluates False and returns None, does happen.

But often, that last expression isn't a constant, but something like self.y - 
self.x. So I'm not sure how much this warning would help that case. In fact, it 
might add to the confusion if sometimes you get a warning and sometimes you 
don't. (And you wouldn't want a warning about any function with no return whose 
last statement is an expression, because often that's perfectly reasonable 
code, where the expression is a mutating method call, like 
self.spam.append(arg).)

Also, there are plenty of other common newbie/transplant problems that are 
similar to this one but can't be caught with a warning, like just referencing a 
function or method instead of calling it because you left the parens off. 
That's *usually* a bug, but not always--it could be a LBYL check for an 
attribute's presence, for example.
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Victor Stinner]

Le 8 févr. 2016 8:14 PM, "Guido van Rossum"  a écrit :
> Hum. I'm not excited by this idea. It is not bad syntax.

Do you see an use case for "constant statements" other than strings and
ellipsis?

Such statement does nothing. Previously the compiler emited
LOAD_CONST+POP_TOP.

GCC also emits a warning on such code.

> Have you
> actually seen newbies who were confused by such things?

Well, not really. But I don't see any use case of such code except of
obvious mistakes. Sometimes such code appears after multiple refactoring
(and mistakes).

Are you suggesting to remove the warning?

Victor
___
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] Improving docs for len() of set

[Ben Hoyt]

Thanks!

Commit ref: https://hg.python.org/cpython/rev/a67fda8e33b0

-Ben

On Mon, Feb 8, 2016 at 1:00 PM, Gregory P. Smith  wrote:

>
>
> On Mon, Feb 8, 2016 at 8:24 AM Ben Hoyt  wrote:
>
>> Hi folks,
>>
>> Just a suggestion for a documentation tweak. Currently the docs for len()
>> on a set say this:
>>
>>.. describe:: len(s)
>>
>>   Return the cardinality of set *s*.
>>
>> I'm a relatively seasoned programmer, but I don't really have a maths
>> background, and I didn't know what "cardinality" meant. I could kind of
>> grok it by context, but could we change this to something like the
>> following?
>>
>>.. describe:: len(s)
>>
>>   Return the number of elements in set *s* (cardinality of *s*).
>>
>>
> Agreed. Done. :)
>
> -gps
>
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Alexander Walters]

I am not keen on a SyntaxWarning.  Either something is python syntax, or 
it is not.  This warning catches something linters have been catching 
for ages.  I really don't see the value in adding this, and can see it 
causing more confusion than it solves.  In the #python irc channel, we 
see quite a few newbie mistakes, but declaring a constant that isn't 
used is rarely if ever one of them.


On 2/8/2016 12:44, Victor Stinner wrote:

Hi,

I changed the Python compiler to ignore any kind "constant
expressions", whereas it only ignored strings and integers before:
http://bugs.python.org/issue26204

The compiler now also emits a SyntaxWarning on such case. IMHO the
warning can help to detect bugs for developers who just learnt Python.

The warning is *not* emited for strings, since triple quoted strings
are a common syntax for multiline comments.

The warning is *not* emited neither for ellispis (...) since "f():
..." is a legit syntax for abstract function.

Are you ok with the new warning?


New behaviour:

haypo@smithers$ ./python
Python 3.6.0a0 (default:759a975e1230, Feb  8 2016, 18:21:23)

def f():

...  False
...
:2: SyntaxWarning: ignore constant statement


import dis; dis.dis(f)

   2   0 LOAD_CONST   0 (None)
   3 RETURN_VALUE


Old behaviour:

haypo@smithers$ python3
Python 3.4.3 (default, Jun 29 2015, 12:16:01)

def f():

...  False
...

import dis; dis.dis(f)

   2   0 LOAD_CONST   1 (False)
   3 POP_TOP
   4 LOAD_CONST   0 (None)
   7 RETURN_VALUE



Before strings and numbers were already ignored. Example:

haypo@smithers$ python3
Python 3.4.3 (default, Jun 29 2015, 12:16:01)


def f():

...  123
...

import dis; dis.dis(f)

   2   0 LOAD_CONST   0 (None)
   3 RETURN_VALUE


Victor
___
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/tritium-list%40sdamon.com


___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Guido van Rossum]

On Mon, Feb 8, 2016 at 11:51 AM, Victor Stinner
 wrote:
> Le 8 févr. 2016 8:14 PM, "Guido van Rossum"  a écrit :
>> Hum. I'm not excited by this idea. It is not bad syntax.
>
> Do you see an use case for "constant statements" other than strings and
> ellipsis?

The same use case as for all dead code: it could be a placeholder for
something better in the future.

It could also be generated code where the generator expects the
optimizer to remove it (or doesn't care).

If you want to do linter integration that should probably be
integrated with the user's editor, like it is in PyCharm, and IIUC
people can do this in e.g. Emacs, Sublime or Vim as well. Leave the
interpreter alone.

> Such statement does nothing. Previously the compiler emited
> LOAD_CONST+POP_TOP.
>
> GCC also emits a warning on such code.
>
>> Have you
>> actually seen newbies who were confused by such things?
>
> Well, not really. But I don't see any use case of such code except of
> obvious mistakes. Sometimes such code appears after multiple refactoring
> (and mistakes).
>
> Are you suggesting to remove the warning?

I haven't seen this warning yet. I take it this is new in the 3.6 branch?

-- 
--Guido van Rossum (python.org/~guido)
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Ethan Furman]

On 02/08/2016 10:15 AM, Ethan Furman wrote:

On 02/08/2016 09:44 AM, Victor Stinner wrote:

 > Are you ok with the new warning?

+1


Changing my vote:

-1 on the warning

+0 on simply removing the unused constant

--
~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] Windows: Remove support of bytes filenames in the os module?

[Chris Barker]

On Mon, Feb 8, 2016 at 6:32 AM, Victor Stinner 
wrote:

>  Windows native type for filenames is
> Unicode, and the Windows has a weird behaviour when you use bytes.


Just to clarify -- what does it currently do for bytes? IIUC, Windows uses
UTF-16, so can you pass in UTF-16 bytes? Or when using bytes is is assuming
some Windows ANSI-compatible encoding? (and what does it return?)

Are we brave enough to force users to use the "right" type for filenames?
>

I think so :-)

On Python 2, it wasn't possible to use Unicode for filenames, many
> functions fail badly with Unicode,


I've had fine success using Unicode filenames with py2 on Windows -- in
fact, as soon as my users have non-ansi characters in their names I'm
pretty sure I have no choice

especially when you mix bytes and
> Unicode.
>

well yes, that sure does get ugly!

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Victor Stinner]

Le 8 févr. 2016 9:34 PM, "Guido van Rossum"  a écrit :
> If you want to do linter integration that should probably be
> integrated with the user's editor, like it is in PyCharm, and IIUC
> people can do this in e.g. Emacs, Sublime or Vim as well. Leave the
> interpreter alone.

In GCC, warnings are welcome because it does one thing: compile code. GCC
is used by developers. Users use the produced binary.

In Python, it's different because it executes code and runs code. It's used
by developers and users.

It's more tricky to make choices like showing or not deprecation warnings.

It looks like most Python developers prefer to use an external linter.

I don't really care of the warning, I will remove it.

> I haven't seen this warning yet. I take it this is new in the 3.6 branch?

Yes it's a recent change in the default branch (a few hours ago).

Victor
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Victor Stinner]

Le 8 févr. 2016 9:10 PM, "Alexander Walters"  a
écrit :
>
> I am not keen on a SyntaxWarning.  Either something is python syntax, or
it is not.

Oh I forgot to mention that Python already emits SyntaxWarning, on "assert
True" for example.

Victor
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Guido van Rossum]

On Mon, Feb 8, 2016 at 1:20 PM, Victor Stinner  wrote:
> Le 8 févr. 2016 9:34 PM, "Guido van Rossum"  a écrit :
>> If you want to do linter integration that should probably be
>> integrated with the user's editor, like it is in PyCharm, and IIUC
>> people can do this in e.g. Emacs, Sublime or Vim as well. Leave the
>> interpreter alone.
>
> In GCC, warnings are welcome because it does one thing: compile code. GCC is
> used by developers. Users use the produced binary.
>
> In Python, it's different because it executes code and runs code. It's used
> by developers and users.
>
> It's more tricky to make choices like showing or not deprecation warnings.
>
> It looks like most Python developers prefer to use an external linter.
>
> I don't really care of the warning, I will remove it.

Thanks!

-- 
--Guido van Rossum (python.org/~guido)
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Alexander Walters]

What incantation do you need to do to make that behavior apparent?

tritium@gesa:~$ python3.5 -W all
Python 3.5.1 (default, Dec 18 2015, 02:15:10)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
Jedi is not installed, falling back to readline
>>> assert True
>>>


On 2/8/2016 16:23, Victor Stinner wrote:



Le 8 févr. 2016 9:10 PM, "Alexander Walters" > a écrit :

>
> I am not keen on a SyntaxWarning.  Either something is python 
syntax, or it is not.


Oh I forgot to mention that Python already emits SyntaxWarning, on 
"assert True" for example.


Victor



___
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/tritium-list%40sdamon.com


___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[John Mark Vandenberg]

On Tue, Feb 9, 2016 at 8:20 AM, Victor Stinner  wrote:
> Le 8 févr. 2016 9:34 PM, "Guido van Rossum"  a écrit :
>> If you want to do linter integration that should probably be
>> integrated with the user's editor, like it is in PyCharm, and IIUC
>> people can do this in e.g. Emacs, Sublime or Vim as well. Leave the
>> interpreter alone.
>
> In GCC, warnings are welcome because it does one thing: compile code. GCC is
> used by developers. Users use the produced binary.
>
> In Python, it's different because it executes code and runs code. It's used
> by developers and users.
>
> It's more tricky to make choices like showing or not deprecation warnings.
>
> It looks like most Python developers prefer to use an external linter.

fwiw, pyflakes doesnt detect this.  I've created a bug for that

https://bugs.launchpad.net/pyflakes/+bug/1543246

-- 
John Vandenberg
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Alexander Walters]

On 2/8/2016 16:37, John Mark Vandenberg wrote:
fwiw, pyflakes doesnt detect this. I've created a bug for that 
https://bugs.launchpad.net/pyflakes/+bug/1543246 


Flake8 does, so it might be in the ... poorly named ... pep8 checker.

___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[John Mark Vandenberg]

On Tue, Feb 9, 2016 at 8:41 AM, Alexander Walters
 wrote:
>
>
> On 2/8/2016 16:37, John Mark Vandenberg wrote:
>>
>> fwiw, pyflakes doesnt detect this. I've created a bug for that
>> https://bugs.launchpad.net/pyflakes/+bug/1543246
>
>
> Flake8 does, so it might be in the ... poorly named ... pep8 checker.

I believe the pep8 checker does not have a check for this.
Could you confirm; which flake8 code are you seeing?

-- 
John Vandenberg
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Victor Stinner]

2016-02-08 22:28 GMT+01:00 Alexander Walters :
> What incantation do you need to do to make that behavior apparent?

I didn't know. I just checked. It's assert used with a non-empty tuple:

>>> assert ("tuple",)
:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?

Victor
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[John Mark Vandenberg]

On Tue, Feb 9, 2016 at 8:51 AM, Victor Stinner  wrote:
> 2016-02-08 22:28 GMT+01:00 Alexander Walters :
>> What incantation do you need to do to make that behavior apparent?
>
> I didn't know. I just checked. It's assert used with a non-empty tuple:
>
 assert ("tuple",)
> :1: SyntaxWarning: assertion is always true, perhaps remove 
> parentheses?

And pyflakes also has a check for this, but it is similarly tight.

https://github.com/pyflakes/pyflakes/pull/51

It seems that the pyflakes maintainers tend to only accepts patches
for scenarios that Python does emit a SyntaxWarning.
So it is a bit of catch-22 there wrt unused constants.

pylint of course reports these unused constants with its message id
"pointless-statement".

-- 
John Vandenberg
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Terry Reedy]

On 2/8/2016 4:51 PM, Victor Stinner wrote:

2016-02-08 22:28 GMT+01:00 Alexander Walters :

What incantation do you need to do to make that behavior apparent?


I didn't know. I just checked. It's assert used with a non-empty tuple:


assert ("tuple",)

:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?


I think this should be left to linters also.


--
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Yury Selivanov]

On 2016-02-08 5:19 PM, Terry Reedy wrote:

On 2/8/2016 4:51 PM, Victor Stinner wrote:

2016-02-08 22:28 GMT+01:00 Alexander Walters :

What incantation do you need to do to make that behavior apparent?


I didn't know. I just checked. It's assert used with a non-empty tuple:


assert ("tuple",)
:1: SyntaxWarning: assertion is always true, perhaps remove 
parentheses?


I think this should be left to linters also.



I agree.  I'd remove that warning.

Yury

___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Chris Barker]

On Mon, Feb 8, 2016 at 1:51 PM, Victor Stinner 
wrote:

> I didn't know. I just checked. It's assert used with a non-empty tuple:
>
> >>> assert ("tuple",)
>

which is more interesting with a tuple without the parentheses:

t = In [*4*]: t = True,

In [*5*]: t

Out[*5*]: (True,)

works fine, but not if you use an assert:

In [*7*]: assert True,

  File "", line 1

assert True,

^

SyntaxError: invalid syntax
I actually like the Warning with the note about the problem better:

:1: SyntaxWarning: assertion is always true, perhaps remove
> parentheses?


And, of course, more relevant with something Falsey in the tuple:

In [*14*]: assert (False,)

:1: SyntaxWarning: assertion is always true,
perhaps remove parentheses?

  assert (False,)

But I am curious why you get a different error without the parens?

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[MRAB]

On 2016-02-08 23:21, Chris Barker wrote:

On Mon, Feb 8, 2016 at 1:51 PM, Victor Stinner mailto:victor.stin...@gmail.com>> wrote:

I didn't know. I just checked. It's assert used with a non-empty tuple:

 >>> assert ("tuple",)


which is more interesting with a tuple without the parentheses:

t = In [*4*]: t = True,

In [*5*]: t

Out[*5*]: (True,)

works fine, but not if you use an assert:

In [*7*]: assert True,

   File "", line 1

 assert True,

 ^

SyntaxError:invalid syntax

I actually like the Warning with the note about the problem better:

:1: SyntaxWarning: assertion is always true, perhaps remove
parentheses?


And, of course, more relevant with something Falsey in the tuple:

In [*14*]: assert (False,)

:1: SyntaxWarning: assertion is always
true, perhaps remove parentheses?

   assert (False,)

But I am curious why you get a different error without the parens?


Try:

help('assert')

You'll see that in "assert (True,)", the tuple (an object) is the first 
condition (and probably a mistake), whereas in "assert True,", the True 
is the condition and the second expression (after the comma) is missing.

___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Chris Barker]

On Mon, Feb 8, 2016 at 3:48 PM, MRAB  wrote:

> help('assert')
>
> You'll see that in "assert (True,)", the tuple (an object) is the first
> condition (and probably a mistake), whereas in "assert True,", the True is
> the condition and the second expression (after the comma) is missing.


yes, of course, that explains it.

-CHB




>
> ___
> 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/chris.barker%40noaa.gov
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Windows: Remove support of bytes filenames in the os module?

[eryk sun]

On Mon, Feb 8, 2016 at 2:41 PM, Chris Barker  wrote:
> Just to clarify -- what does it currently do for bytes? IIUC, Windows uses
> UTF-16, so can you pass in UTF-16 bytes? Or when using bytes is is assuming
> some Windows ANSI-compatible encoding? (and what does it return?)

UTF-16 is used in the [W]ide-character API. Bytes paths use the [A]NSI
codepage. For a single-byte codepage, the ANSI API rountrips, i.e. a
bytes path that's passed to CreateFileA matches the listing from
FindFirstFileA. But for a DBCS codepage arbitrary bytes paths do not
roundtrip. Invalid byte sequences map to the default character. Note
that an ASCII question mark is not always the default character. It
depends on the codepage.

For example, in codepage 932 (Japanese), it's an error if a lead byte
(i.e. 0x81-0x9F, 0xE0-0xFC) is followed by a trailing byte with a
value less than 0x40 (note that ASCII 0-9 is 0x30-0x39, so this is not
uncommon). In this case the ANSI API substitutes the default character
for Japanese, '・' (U+30FB, Katakana middle dot).

>>> locale.getpreferredencoding()
'cp932'
>>> open(b'\xe05', 'w').close()
>>> os.listdir('.')
['・']
>>> os.listdir(b'.')
[b'\x81E']

All invalid sequences get mapped to '・', which roundtrips as
b'\x81\x45', so you can't reliably create and open files with
arbitrary bytes paths in this locale.
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Guido van Rossum]

The warning for 'assert (cond, msg)' was specifically put in because
this is a nasty trap. It's *always* a mistaken attempt to write
'assert cond, msg' -- usually in an attempt to break a long line
without using a backslash. I'd actually consider promoting it to a
syntax error rather than removing the warning.

Compared to other "lint warnings" this one is much nastier -- it is
also much more certain that it is a mistake. (Much more certain than
e.g. an undefined variable, which could still be legitimate code due
to dynamic updates to globals() or builtins.)

-- 
--Guido van Rossum (python.org/~guido)
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Steven D'Aprano]

On Mon, Feb 08, 2016 at 05:43:25PM -0500, Yury Selivanov wrote:
> 
> 
> On 2016-02-08 5:19 PM, Terry Reedy wrote:
> >On 2/8/2016 4:51 PM, Victor Stinner wrote:
> >>2016-02-08 22:28 GMT+01:00 Alexander Walters :
> >>>What incantation do you need to do to make that behavior apparent?
> >>
> >>I didn't know. I just checked. It's assert used with a non-empty tuple:
> >>
> >assert ("tuple",)
> >>:1: SyntaxWarning: assertion is always true, perhaps remove 
> >>parentheses?
> >
> >I think this should be left to linters also.
> >
> 
> I agree.  I'd remove that warning.


Please don't remove the warning, it is very useful. 

Compare an assertion written correctly:

py> assert 1==2, "Error in arithmetic"
Traceback (most recent call last):
  File "", line 1, in 
AssertionError: Error in arithmetic


with the simple mistake of wrapping the "tuple" in parens:

py> assert (1==2, "Error in arithmetic")
:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?
py> 


This especially hurts people who think that assert is a function. In 
Python 2.5 and older, you get no warning, and can write wrong code:

py> x = 2
py> assert(x==1, 'expected 1 but got %s' % x)
py>


Removing this warning would be a regression.


-- 
Steve
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[MRAB]

On 2016-02-09 00:53, Guido van Rossum wrote:

The warning for 'assert (cond, msg)' was specifically put in because
this is a nasty trap. It's *always* a mistaken attempt to write
'assert cond, msg' -- usually in an attempt to break a long line
without using a backslash. I'd actually consider promoting it to a
syntax error rather than removing the warning.

Compared to other "lint warnings" this one is much nastier -- it is
also much more certain that it is a mistake. (Much more certain than
e.g. an undefined variable, which could still be legitimate code due
to dynamic updates to globals() or builtins.)
Would there be less chance of confusion if there were some kind of 
syntax such as "assert cond with msg"?


___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Chris Angelico]

On Tue, Feb 9, 2016 at 12:41 PM, MRAB  wrote:
> On 2016-02-09 00:53, Guido van Rossum wrote:
>>
>> The warning for 'assert (cond, msg)' was specifically put in because
>> this is a nasty trap. It's *always* a mistaken attempt to write
>> 'assert cond, msg' -- usually in an attempt to break a long line
>> without using a backslash. I'd actually consider promoting it to a
>> syntax error rather than removing the warning.
>>
>> Compared to other "lint warnings" this one is much nastier -- it is
>> also much more certain that it is a mistake. (Much more certain than
>> e.g. an undefined variable, which could still be legitimate code due
>> to dynamic updates to globals() or builtins.)
>
> Would there be less chance of confusion if there were some kind of syntax
> such as "assert cond with msg"?

Is assert the *only* statement that has a comma separating unrelated
items? Every other statement that uses a comma is separating identical
items (eg "import os, sys" - "os" and "sys" are equivalent), and
tokens that have completely different meaning are separated by a word.
The only other exception I can think of - pun intended - is the old
"except BaseException, e:" syntax, which got dropped in Py3. Maybe
it's time to introduce a new syntax with a view to deprecating the
comma syntax ("use this old syntax if you need to support Python
2.7").

+1.

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

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Guido van Rossum]

On Mon, Feb 8, 2016 at 5:41 PM, MRAB  wrote:
> On 2016-02-09 00:53, Guido van Rossum wrote:
>>
>> The warning for 'assert (cond, msg)' was specifically put in because
>> this is a nasty trap. It's *always* a mistaken attempt to write
>> 'assert cond, msg' -- usually in an attempt to break a long line
>> without using a backslash. I'd actually consider promoting it to a
>> syntax error rather than removing the warning.
>>
>> Compared to other "lint warnings" this one is much nastier -- it is
>> also much more certain that it is a mistake. (Much more certain than
>> e.g. an undefined variable, which could still be legitimate code due
>> to dynamic updates to globals() or builtins.)
>
> Would there be less chance of confusion if there were some kind of syntax
> such as "assert cond with msg"?

Perhaps, but as long as the "with msg" isn't mandatory and the "assert
x, y" syntax is still valid we'd still have to warn about "assert (x,
y)". Note that in general "assert constant" is not a problem (assert
True and assert False have their uses :-). It's only the literal tuple
form.

-- 
--Guido van Rossum (python.org/~guido)
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Guido van Rossum]

Personally I don't think it's worth the churn.

On Mon, Feb 8, 2016 at 5:49 PM, Chris Angelico  wrote:
> On Tue, Feb 9, 2016 at 12:41 PM, MRAB  wrote:
>> On 2016-02-09 00:53, Guido van Rossum wrote:
>>>
>>> The warning for 'assert (cond, msg)' was specifically put in because
>>> this is a nasty trap. It's *always* a mistaken attempt to write
>>> 'assert cond, msg' -- usually in an attempt to break a long line
>>> without using a backslash. I'd actually consider promoting it to a
>>> syntax error rather than removing the warning.
>>>
>>> Compared to other "lint warnings" this one is much nastier -- it is
>>> also much more certain that it is a mistake. (Much more certain than
>>> e.g. an undefined variable, which could still be legitimate code due
>>> to dynamic updates to globals() or builtins.)
>>
>> Would there be less chance of confusion if there were some kind of syntax
>> such as "assert cond with msg"?
>
> Is assert the *only* statement that has a comma separating unrelated
> items? Every other statement that uses a comma is separating identical
> items (eg "import os, sys" - "os" and "sys" are equivalent), and
> tokens that have completely different meaning are separated by a word.
> The only other exception I can think of - pun intended - is the old
> "except BaseException, e:" syntax, which got dropped in Py3. Maybe
> it's time to introduce a new syntax with a view to deprecating the
> comma syntax ("use this old syntax if you need to support Python
> 2.7").
>
> +1.
>
> 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/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)
___
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] Windows: Remove support of bytes filenames in the os module?

[Chris Barker - NOAA Federal]

All I can say is "ouch". Hard to call it a regression to no longer
allow this mess...

CHB

> On Feb 8, 2016, at 4:37 PM, eryk sun  wrote:
>
>> On Mon, Feb 8, 2016 at 2:41 PM, Chris Barker  wrote:
>> Just to clarify -- what does it currently do for bytes? IIUC, Windows uses
>> UTF-16, so can you pass in UTF-16 bytes? Or when using bytes is is assuming
>> some Windows ANSI-compatible encoding? (and what does it return?)
>
> UTF-16 is used in the [W]ide-character API. Bytes paths use the [A]NSI
> codepage. For a single-byte codepage, the ANSI API rountrips, i.e. a
> bytes path that's passed to CreateFileA matches the listing from
> FindFirstFileA. But for a DBCS codepage arbitrary bytes paths do not
> roundtrip. Invalid byte sequences map to the default character. Note
> that an ASCII question mark is not always the default character. It
> depends on the codepage.
>
> For example, in codepage 932 (Japanese), it's an error if a lead byte
> (i.e. 0x81-0x9F, 0xE0-0xFC) is followed by a trailing byte with a
> value less than 0x40 (note that ASCII 0-9 is 0x30-0x39, so this is not
> uncommon). In this case the ANSI API substitutes the default character
> for Japanese, '・' (U+30FB, Katakana middle dot).
>
 locale.getpreferredencoding()
>'cp932'
 open(b'\xe05', 'w').close()
 os.listdir('.')
>['・']
 os.listdir(b'.')
>[b'\x81E']
>
> All invalid sequences get mapped to '・', which roundtrips as
> b'\x81\x45', so you can't reliably create and open files with
> arbitrary bytes paths in this locale.
___
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] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[John Mark Vandenberg]

On Tue, Feb 9, 2016 at 7:34 AM, Guido van Rossum  wrote:
> On Mon, Feb 8, 2016 at 11:51 AM, Victor Stinner
>  wrote:
>> Le 8 févr. 2016 8:14 PM, "Guido van Rossum"  a écrit :
>>> Hum. I'm not excited by this idea. It is not bad syntax.
>>
>> Do you see an use case for "constant statements" other than strings and
>> ellipsis?
>
> The same use case as for all dead code: it could be a placeholder for
> something better in the future.

Allowing dead code is useful as it allows complex code to be left in
place.  It can be risky removing the code.

Unused literals are stupefyingly simple statements.
A line of merely a constant, e.g. 'True' or '1', does not present the
same risks or benefits.
That it is a hope for something better?
It could be easily replaced with 'pass', '...', a comment, and/or a
string literal explaining what needs improving.

> It could also be generated code where the generator expects the
> optimizer to remove it (or doesn't care).

Why shouldnt a user see that it is generating such code?
There is a decent chance that it is a bug in the generated code.

fwiw, this is a syntax warning in Ruby - "unused literal ignored",
since 2003 (5aadcd9).

--
John Vandenberg
___
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