Re: [Python-Dev] PEP 561 rework

[Nick Coghlan]

On 13 November 2017 at 17:33, Ethan Smith  wrote:
> On Sun, Nov 12, 2017 at 8:07 PM, Nathaniel Smith  wrote:
>> PyPI doesn't distinguish between the names 'foo-stubs' and 'foo_stubs'
>> -- they get normalized together. So even if you use 'foo-stubs' as the
>> directory name on sys.path to avoid collisions at import time, it
>> still won't allow someone to distribute a separate 'foo_stubs' package
>> on PyPI.
>>
>> If you do go with a fixed naming convention like this, the PEP should
>> probably also instruct the PyPI maintainers that whoever owns 'foo'
>> automatically has the right to control the name 'foo-stubs' as well.
>> Or maybe some tweak to PEP 541 is needed.
>
> As I understand it however, the distribution name need not map to to the
> package name in any way. So regardless of if foo-stubs is seen as foo_stubs,
> I could name the distribution Albatross if I wished, and install the
> foo-stubs package into site/dist-packages, and it would work. Also I'm not
> sure if the PyPI change would require an edict from a PEP, but if so, I
> wouldn't be opposed to the idea, I think it would be nice to default the
> stub packages to the owners of the normal packages (people should, to my
> understanding, be able to make alternate distributions without hassle).

Questions like the following aren't new ones:

- If I am responsible for the name 'foo' on PyPI, how much influence,
if any, should I have over the use of 'foo' as a prefix in other
distribution package names?
- If I ship a distribution package through PyPI containing an import
package named 'bar', how much influence, if any, should I have over
the use of 'bar' as an import package or module name in other
distribution packages?

I expect that the PSF will need to address them directly some day, but
I don't think PEP 561 itself needs to address them (and the first
version of PEP 541 probably won't either).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

[Serhiy Storchaka]

13.11.17 05:48, Nathaniel Smith пише:

On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan  wrote:

This change will lead to DeprecationWarning being displayed by default for:

* code executed directly at the interactive prompt
* code executed directly as part of a single-file script


Technically it's orthogonal, but if you're trying to get better
warnings in the REPL, then you might also want to look at:

https://bugs.python.org/issue1539925
https://github.com/ipython/ipython/issues/6611


The idea LGTM. Do you mind to create a pull request Nathaniel?

___
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] [python-committers] Enabling depreciation warnings feature code cutoff

[Serhiy Storchaka]

12.11.17 03:47, Guido van Rossum пише:
- In Python 3 code, using `\u` escapes in a b'...' literal gives 
"DeprecationWarning: invalid escape sequence '\u'"


In both cases these warnings are currently only generated if you run 
mypy with these warnings enabled, e.g. `python3 -Wd -m mypy `. 
But this means that mypy would start generating these by default if 
those warnings were enabled everywhere by default (per Antoine's 
preference). And while it's debatable whether they are useful, there 
should at least be a way to turn them off (e.g. when checking Python 2 
code that's never going to be ported).. Running mypy in the above way is 
awkward; mypy would likely have to grow a new flag to control this.


It is hard to determine what category is better for this warnings: 
DeprecationWarning or SyntaxWarning. On one hand, SyntaxWarning looks 
more appropriate since the warning is generated by the Python parser. On 
other hand, numerous warnings can confuse end users of Python 
applications, and DeprecationWarning is silenced by default.


This warning is a special case. When it is converted to an error, it 
becomes a SyntaxError, because the latter contains information about 
location of an invalid escape sequence, and produces better error report 
(containing source line, cursor, etc).


___
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 565: Show DeprecationWarning in __main__

[Antoine Pitrou]

On Sun, 12 Nov 2017 19:48:28 -0800
Nathaniel Smith  wrote:
> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan  wrote:
> > This change will lead to DeprecationWarning being displayed by default for:
> >
> > * code executed directly at the interactive prompt
> > * code executed directly as part of a single-file script  
> 
> Technically it's orthogonal, but if you're trying to get better
> warnings in the REPL, then you might also want to look at:
> 
> https://bugs.python.org/issue1539925
> https://github.com/ipython/ipython/issues/6611

Depends what you call "better".  Personally, I don't want to see
warnings each and every time I use a deprecated or questionable
construct or API from the REPL.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

[Chris Angelico]

On Mon, Nov 13, 2017 at 9:46 PM, Antoine Pitrou  wrote:
> On Sun, 12 Nov 2017 19:48:28 -0800
> Nathaniel Smith  wrote:
>> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan  wrote:
>> > This change will lead to DeprecationWarning being displayed by default for:
>> >
>> > * code executed directly at the interactive prompt
>> > * code executed directly as part of a single-file script
>>
>> Technically it's orthogonal, but if you're trying to get better
>> warnings in the REPL, then you might also want to look at:
>>
>> https://bugs.python.org/issue1539925
>> https://github.com/ipython/ipython/issues/6611
>
> Depends what you call "better".  Personally, I don't want to see
> warnings each and every time I use a deprecated or questionable
> construct or API from the REPL.

Isn't that the entire *point* of warnings? When you're working at the
REPL, you're the one in control of which APIs you use, so you should
be the one to know about deprecations.

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] PEP 565: Show DeprecationWarning in __main__

[Antoine Pitrou]

On Mon, 13 Nov 2017 22:37:46 +1100
Chris Angelico  wrote:
> On Mon, Nov 13, 2017 at 9:46 PM, Antoine Pitrou  wrote:
> > On Sun, 12 Nov 2017 19:48:28 -0800
> > Nathaniel Smith  wrote:  
> >> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan  wrote:  
> >> > This change will lead to DeprecationWarning being displayed by default 
> >> > for:
> >> >
> >> > * code executed directly at the interactive prompt
> >> > * code executed directly as part of a single-file script  
> >>
> >> Technically it's orthogonal, but if you're trying to get better
> >> warnings in the REPL, then you might also want to look at:
> >>
> >> https://bugs.python.org/issue1539925
> >> https://github.com/ipython/ipython/issues/6611  
> >
> > Depends what you call "better".  Personally, I don't want to see
> > warnings each and every time I use a deprecated or questionable
> > construct or API from the REPL.  
> 
> Isn't that the entire *point* of warnings? When you're working at the
> REPL, you're the one in control of which APIs you use, so you should
> be the one to know about deprecations.

If I see a warning once every REPL session, I know about the deprecation
already, thank you.  I don't need to be taken by the hand like a little
child.  Besides, the code I write in the REPL is not meant for durable
use.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

[Stefan Krah]

On Mon, Nov 13, 2017 at 10:37:46PM +1100, Chris Angelico wrote:
> >> https://bugs.python.org/issue1539925
> >> https://github.com/ipython/ipython/issues/6611
> >
> > Depends what you call "better".  Personally, I don't want to see
> > warnings each and every time I use a deprecated or questionable
> > construct or API from the REPL.
> 
> Isn't that the entire *point* of warnings? When you're working at the
> REPL, you're the one in control of which APIs you use, so you should
> be the one to know about deprecations.

I haven't followed the long discussions, so this is probably not a very
novel observation.

But it seems to me that we have a problem getting users to treat the
python command like e.g. gcc.

If I want gcc warnings, I use -Wall -Wextra.


I think the whole problem is that python warnings are a bit of an obscure
feature (they were to me for a long time).



Stefan Krah



___
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 565: Show DeprecationWarning in __main__

[Serhiy Storchaka]

13.11.17 14:29, Antoine Pitrou пише:

On Mon, 13 Nov 2017 22:37:46 +1100
Chris Angelico  wrote:

On Mon, Nov 13, 2017 at 9:46 PM, Antoine Pitrou  wrote:

On Sun, 12 Nov 2017 19:48:28 -0800
Nathaniel Smith  wrote:

On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan  wrote:

This change will lead to DeprecationWarning being displayed by default for:

* code executed directly at the interactive prompt
* code executed directly as part of a single-file script


Technically it's orthogonal, but if you're trying to get better
warnings in the REPL, then you might also want to look at:

https://bugs.python.org/issue1539925
https://github.com/ipython/ipython/issues/6611


Depends what you call "better".  Personally, I don't want to see
warnings each and every time I use a deprecated or questionable
construct or API from the REPL.


Isn't that the entire *point* of warnings? When you're working at the
REPL, you're the one in control of which APIs you use, so you should
be the one to know about deprecations.


If I see a warning once every REPL session, I know about the deprecation
already, thank you.  I don't need to be taken by the hand like a little
child.  Besides, the code I write in the REPL is not meant for durable
use.


Hmm, now I see that the simple Nathaniel's solution is not completely 
correct. If the warning action is 'module', it should be emitted only 
once if used directly in the REPL, because '__main__' is the same module.


But if you use functions foo() and bar(), and both emit the same 
warning, you should get a warning from every entered command, because 
after the first warning you know only about the first function.


___
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] Disallow ambiguous syntax f(x for x in [1],)

[Ivan Levkivskyi]

FWIW, it is common to have syntax checks in ast.c.
Especially situations like class ``C(x for x in [1]): ...`` I think would
be hard to prohibit in Grammar.
Since anyway we have many checks in ast.c already, I wouldn't care much
about implementing these corner cases in Grammar.

--
Ivan
___
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 561 rework

[Ivan Levkivskyi]

Thanks Ethan for all the work!

I will be glad to see this accepted and implemented in mypy.

--
Ivan
___
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] Add a developer mode to Python: -X dev command line option

[Victor Stinner]

Hi,

The discussion on DeprecationWarning reminded me my old idea of a
"development mode" for CPython: -X dev. Since Brett likes it, I post
it on python-dev. Last year, I posted this idea to python-ideas but my
idea was rejected:

https://mail.python.org/pipermail/python-ideas/2016-March/039314.html

In short:
   python3.7 -X dev script.py
behaves as:
   PYTHONMALLOC=debug python3.7 -Wd -b -X faulthandler script.py

The idea of -X dev is to enable "debug checks". Some of these checks
are already enabled by default if CPython is compiled in debug mode.
These checks help to debug bugs earlier.

The problem is that outside CPython development, Python developers use
a Python binary from their Linux distributor or a binary installed
from python.org: a binary compiled in release mode. Well, some Linux
distributions provide a debug build, but the ABI is incompatible, and
so is hard to use in practice.

Running the tests of your code in -X dev mode should help you to catch
subtle bugs and prevent regressions if you upgrade Python.

The -X dev mode doesn't raise hard exceptions, but usually only emits
warnings. It allows you to fix bugs one by one in your own code,
without having to fix bugs in third party code.

If you control your whole code base, you may want to enable -X
dev=strict which raises hard exceptions, to make sure that you are
really safe.

My "-X dev" idea is not incompatible with Nick's PEP 565 "Show
DeprecationWarning in __main__" and it's different: it's an opt-in
option, while Nick wants to change the default behaviour.

---

Full copy of my email sent last year to python-ideas.

When I develop on CPython, I'm always building Python in debug mode
using ./configure --with-pydebug. This mode enables a *lot* of extra
checks which helps me to detect bugs earlier. The debug mode makes
Python much slower and so is not the default. "python3" in Linux
distributions is a binary compiled in release mode. When they also
provide a binary compiled in debug mode, you will probably have issues
to use your existing C extensions, since they all of them are compiled
in release mode which is not compatible (you must recompile C
extensions in debug mode).

I propose to add a "development mode" to Python, to get a few checks
to detect bugs earlier: a new -X dev command line option. Example:

   python3.6 -X dev script.py

Checks enabled by this flag must:

* Not flood the stdout/stderr (ex: don't write one message per second)
* Have a low overhead in term of CPU and memory (ex: max 10%)

I propose to enable:

* Show DeprecationWarning and ResourceWarning warnings: python -Wd
* Show BytesWarning warning: python -b
* Enable Python assertions (assert) and set __debug__ to True: remove
(or just ignore) -O or -OO command line arguments
* faulthandler to get a Python traceback on segfault and fatal errors:
python -X faulthandler
* Debug hooks on Python memory allocators: PYTHONMALLOC=debug

For example, I consider that enabling tracemalloc is too expensive
(CPU & memory) and must not be enabled in -X dev.

I wrote a proof-of-concept: if -X dev is used, executable Python once
again with more parameters. Basically, replace:
   python3.6 -X dev ...
with
   PYTHONMALLOC=debug python3.6 -Wd -b -X faulthandler ...


The list of checks can be extended later. For example, we may enable
the debug mode of asyncio: PYTHONASYNCIODEBUG=1.


The scope of the "developer mode" is unclear to me. Many modules (ex:
asyncio) already have a debug mode. Would it be a bad idea to enable
*all* debug modes of *all* modules? For example, http.client has a
debug level: do you expect debug traces of the HTTP client when you
develop your application?

IMHO the scope must be well defined: don't modify modules of the
stdlib, only enable more debug flags in the Python core (warnings,
unicode, memory allocators, etc.).


Maybe we even a need -X dev=strict which would be stricter:

* use -Werror instead of -Wd: raise an exception when a warning is emitted
* use -bb instead of -b: get BytesWarning exceptions
* Replace "inconsistent use of tabs and spaces in indentation" warning
with an error in the Python parser
* etc.

Again, this list can be extended later.


Or maybe we need multiple level to control the quantity of debug
traces, warnings, ... written into stdout/stderr?


In my experience, the problem with converting warnings to errors is
that you don't control the code of your whole application. It's common
that third party modules raise DeprecationWarning, ResourceWarning,
etc. Even some modules of the Python stdlib raise DeprecatingWarning!
For example, I recall that distutils raises a DeprecationWarning on
Python 3.4 when importing the imp module.


"Similar" idea in other programming languages:

* Perl: http://perldoc.perl.org/strict.html
* PHP: https://secure.php.net/manual/fr/function.error-reporting.php

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/p

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

[Victor Stinner]

> The change proposed in this PEP is to update the default warning filter list
> to be::
>
> default::DeprecationWarning:__main__
> ignore::DeprecationWarning
> ignore::PendingDeprecationWarning
> ignore::ImportWarning
> ignore::BytesWarning
> ignore::ResourceWarning

This PEP can break applications parsing Python stderr, application
which don't expect to get DeprecationWarning in their output.

Is it possible to disable this PEP using a command line option and/or
environment variable to get the Python 3.6 behaviour (always
DeprecationWarning)?

I guess that it's
"PYTHONWARNINGS=ignore::DeprecationWarning:__main__". Am I right?
Would you mind to mention that in the PEP, please?

Sorry, I'm not an expert of the warnings module. Is it possible to
also configure Python to ignore DeprecationWarning using the warnings
module, at the start of the __main__ script? Something like
warnings.filterwarnings("ignore", '', DeprecationWarning)? Again,
maybe explain that in the PEP?

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] PEP 565: Show DeprecationWarning in __main__

[Victor Stinner]

Hi,

I'm not convinced that this PEP 565 will prevent developers to be
surprised when upgrading Python, since more and more applications are
using an entry point: an import + a single function call. For example,
*all* OpenStack applications use an entry point and so will be
unaffected by this PEP.

There is no suprise, it's documented in the PEP: "code imported from
an executable script wrapper generated at installation time based on a
console_scripts or gui_scripts entry point definition".

It's hard to find a compromise between two incompatible use cases:
"run an application" ("user") and "develop an application"
("developer"). I proposed again my "-X dev" idea in another thread for
the "develop an application" use case ;-)

If the Python REPL is included in the "run an application" use case,
the frontier between user and developer becomes blurry :-) Is REPL
designed for users or developers? Should Python guess the intent of
the human connected to the keyboard? ...

Victor

2017-11-12 10:24 GMT+01:00 Nick Coghlan :
> I've written a short(ish) PEP for the proposal to change the default
> warnings filters to show DeprecationWarning in __main__:
> https://www.python.org/dev/peps/pep-0565/
>
> The core proposal itself is just the idea in
> https://bugs.python.org/issue31975 (i.e. adding
> "default::DeprecationWarning:__main__" to the default filter set), but
> the PEP fills in some details on the motivation for the original
> change to the defaults, and why the current proposal is to add a new
> filter for __main__, rather than dropping the default
> DeprecationWarning filter entirely.
>
> The PEP also proposes repurposing the existing FutureWarning category
> to explicitly mean "backwards compatibility warnings that should be
> shown to users of Python applications" since:
>
> - we don't tend to use FutureWarning for its original nominal purpose
> (changes that will continue to run but will do something different)
> - FutureWarning was added in 2.3, so it's available in all still
> supported versions of Python, and is shown by default in all of them
> - it's at least arguably a less-jargony spelling of
> DeprecationWarning, and hence more appropriate for displaying to end
> users that may not have encountered the specific notion of "API
> deprecation"
>
> Cheers,
> Nick.
>
> ==
> PEP: 565
> Title: Show DeprecationWarning in __main__
> Author: Nick Coghlan 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 12-Nov-2017
> Python-Version: 3.7
> Post-History: 12-Nov-2017
>
>
> Abstract
> 
>
> In Python 2.7 and Python 3.2, the default warning filters were updated to hide
> DeprecationWarning by default, such that deprecation warnings in development
> tools that were themselves written in Python (e.g. linters, static analysers,
> test runners, code generators) wouldn't be visible to their users unless they
> explicitly opted in to seeing them.
>
> However, this change has had the unfortunate side effect of making
> DeprecationWarning markedly less effective at its primary intended purpose:
> providing advance notice of breaking changes in APIs (whether in CPython, the
> standard library, or in third party libraries) to users of those APIs.
>
> To improve this situation, this PEP proposes a single adjustment to the
> default warnings filter: displaying deprecation warnings attributed to the 
> main
> module by default.
>
> This change will mean that code entered at the interactive prompt and code in
> single file scripts will revert to reporting these warnings by default, while
> they will continue to be silenced by default for packaged code distributed as
> part of an importable module.
>
> The PEP also proposes a number of small adjustments to the reference
> interpreter and standard library documentation to help make the warnings
> subsystem more approachable for new Python developers.
>
>
> Specification
> =
>
> The current set of default warnings filters consists of::
>
> ignore::DeprecationWarning
> ignore::PendingDeprecationWarning
> ignore::ImportWarning
> ignore::BytesWarning
> ignore::ResourceWarning
>
> The default ``unittest`` test runner then uses ``warnings.catch_warnings()``
> ``warnings.simplefilter('default')`` to override the default filters while
> running test cases.
>
> The change proposed in this PEP is to update the default warning filter list
> to be::
>
> default::DeprecationWarning:__main__
> ignore::DeprecationWarning
> ignore::PendingDeprecationWarning
> ignore::ImportWarning
> ignore::BytesWarning
> ignore::ResourceWarning
>
> This means that in cases where the nominal location of the warning (as
> determined by the ``stacklevel`` parameter to ``warnings.warn``) is in the
> ``__main__`` module, the first occurrence of each DeprecationWarning will once
> again be reported.
>
> This change will lead to DeprecationWarning being displayed by default for:
>
> * code executed directly at th

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

[Antoine Pitrou]

On Mon, 13 Nov 2017 17:08:06 +0100
Victor Stinner  wrote:
> Hi,
> 
> The discussion on DeprecationWarning reminded me my old idea of a
> "development mode" for CPython: -X dev. Since Brett likes it, I post
> it on python-dev. Last year, I posted this idea to python-ideas but my
> idea was rejected:
> 
> https://mail.python.org/pipermail/python-ideas/2016-March/039314.html
> 
> In short:
>python3.7 -X dev script.py
> behaves as:
>PYTHONMALLOC=debug python3.7 -Wd -b -X faulthandler script.py

I would personally not add `-b` in those options.  I think it was
useful while porting stuff to 3.x, but not so much these days.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

[Victor Stinner]

2017-11-13 17:40 GMT+01:00 Antoine Pitrou :
> I would personally not add `-b` in those options.  I think it was
> useful while porting stuff to 3.x, but not so much these days.

You should consider youself as lucky if you completed to port all your
code to Python 3. It's not my case yet :-) (I'm thinking to code that
I have to port, not only code that I wrote myself.)

I confirm that I usually use -b while I'm porting code from Python 2
to Python 3. So, usually I know that I will get Python 3 compatibility
issues. Sometimes, you may still get Python 3 compatibility issues
while the project is already tagged as "compatible with Python 3",
just because you get into a code path which wasn't properyl tested
before.

Well, I don't have a strong opinion on -b.

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] Add a developer mode to Python: -X dev command line option

[Serhiy Storchaka]

13.11.17 18:40, Antoine Pitrou пише:

On Mon, 13 Nov 2017 17:08:06 +0100
Victor Stinner  wrote:

In short:
python3.7 -X dev script.py
behaves as:
PYTHONMALLOC=debug python3.7 -Wd -b -X faulthandler script.py


I would personally not add `-b` in those options.  I think it was
useful while porting stuff to 3.x, but not so much these days.


I concur with Antoine.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

[Antoine Pitrou]

Le 13/11/2017 à 17:46, Victor Stinner a écrit :
> 2017-11-13 17:40 GMT+01:00 Antoine Pitrou :
>> I would personally not add `-b` in those options.  I think it was
>> useful while porting stuff to 3.x, but not so much these days.
> 
> You should consider youself as lucky if you completed to port all your
> code to Python 3. It's not my case yet :-) (I'm thinking to code that
> I have to port, not only code that I wrote myself.)

The main issue I have with `-b` is actually that you can get spurious
warnings about properly working code.  You can also get warnings in
well-tested third-party libraries, e.g.:

distributed/tests/test_client.py::test_get_versions
  
/home/antoine/miniconda3/envs/dask36/lib/python3.6/site-packages/pandas/core/dtypes/common.py:20:
 BytesWarning: Comparison between bytes and string
for t in ['O', 'int8', 'uint8', 'int16', 'uint16',
  
/home/antoine/miniconda3/envs/dask36/lib/python3.6/site-packages/pandas/io/packers.py:231:
 BytesWarning: Comparison between bytes and string
7: np.dtype('int64'),

distributed/tests/test_client.py::test_serialize_collections_of_futures_sync
  
/home/antoine/miniconda3/envs/dask36/lib/python3.6/site-packages/numpy/core/numeric.py:583:
 BytesWarning: Comparison between bytes and string
return array(a, dtype, copy=False, order=order, subok=True)

distributed/tests/test_client.py::test_serialize_collections_of_futures
  
/home/antoine/miniconda3/envs/dask36/lib/python3.6/site-packages/numpy/core/numeric.py:583:
 BytesWarning: Comparison between bytes and string
return array(a, dtype, copy=False, order=order, subok=True)


(this is an excerpt of the warnings I got by running our test suite with
"python -b")

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Add a developer mode to Python: -X dev command line option

[Victor Stinner]

2017-11-13 17:51 GMT+01:00 Antoine Pitrou :
> The main issue I have with `-b` is actually that you can get spurious
> warnings about properly working code.  You can also get warnings in
> well-tested third-party libraries, e.g.:
>
> distributed/tests/test_client.py::test_get_versions
>   
> /home/antoine/miniconda3/envs/dask36/lib/python3.6/site-packages/pandas/core/dtypes/common.py:20:
>  BytesWarning: Comparison between bytes and string
> for t in ['O', 'int8', 'uint8', 'int16', 'uint16',
>   
> /home/antoine/miniconda3/envs/dask36/lib/python3.6/site-packages/pandas/io/packers.py:231:
>  BytesWarning: Comparison between bytes and string
> 7: np.dtype('int64'),

Oh right, that's a very good reason to not include -b option in the -X
dev mode ;-)

Usually, I mostly care of ResourceWarning and DeprecationWarning warnings.

PYTHONMALLOC=debug and -X faulthandler just comes "for free", they
don't change the behaviour as -b, and should help to debug crashes.

---

By the way, My worst memory of BytesWarning is when implemented/fixed
(I don't call) os.get_exec_path():

# {b'PATH': ...}.get('PATH') and {'PATH': ...}.get(b'PATH') emit a
# BytesWarning when using python -b or python -bb: ignore the warning
with warnings.catch_warnings():
warnings.simplefilter("ignore", BytesWarning)
...

I really dislike this code since warnings.catch_warnings() is
process-wide and so impact other threads :-(

(Maybe Yury's PEP "context variables" would help here? ;-))

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] process-wide warning settings

[Antoine Pitrou]

On Mon, 13 Nov 2017 18:19:07 +0100
Victor Stinner  wrote:
> 
> I really dislike this code since warnings.catch_warnings() is
> process-wide and so impact other threads :-(
> 
> (Maybe Yury's PEP "context variables" would help here? ;-))

They can't really help unless we break the catch_warnings() API to make
it affect some kind of thread-local warning settings (which don't exist
currently).

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Standardise the AST (Re: PEP 563: Postponed Evaluation of Annotations)

[Greg Ewing]

Guido van Rossum wrote:

But Python's syntax changes in nearly every release.


The changes are almost always additions, so there's no
reason why the AST can't remain backwards compatible.

the AST level ... elides many details 
(such as whitespace and parentheses).


That's okay, because the AST is only expected to
represent the semantics of Python code, not its
exact lexical representation in the source. It's
the same with Lisp -- comments and whitespace have
been stripped out by the time you get to Lisp
data.

Lisp had almost no syntax so I presume the mapping to data structures 
was nearly trivial compared to Python.


Yes, the Python AST is more complicated, but we
already have that much complexity in the AST being
used by the compiler.

If I understand correctly, we also have a process
for converting that internal structure to and from
an equally complicated set of Python objects, that
isn't needed by the compiler and exists purely for
the convenience of Python code.

I can't see much complexity being added if we were
to decide to standardise the Python representation.

--
Greg
___
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] Standardise the AST (Re: PEP 563: Postponed Evaluation of Annotations)

[Brett Cannon]

On Mon, Nov 13, 2017, 13:37 Greg Ewing,  wrote:

> Guido van Rossum wrote:
> > But Python's syntax changes in nearly every release.
>
> The changes are almost always additions, so there's no
> reason why the AST can't remain backwards compatible.
>
> > the AST level ... elides many details
> > (such as whitespace and parentheses).
>
> That's okay, because the AST is only expected to
> represent the semantics of Python code, not its
> exact lexical representation in the source. It's
> the same with Lisp -- comments and whitespace have
> been stripped out by the time you get to Lisp
> data.
>
> > Lisp had almost no syntax so I presume the mapping to data structures
> > was nearly trivial compared to Python.
>
> Yes, the Python AST is more complicated, but we
> already have that much complexity in the AST being
> used by the compiler.
>
> If I understand correctly, we also have a process
> for converting that internal structure to and from
> an equally complicated set of Python objects, that
> isn't needed by the compiler and exists purely for
> the convenience of Python code.
>

The internal and stdlib AST are generated from the AST definition which is
written in a DEAL. The conversion code is also auto-generated. (The
devguide has the details.)


> I can't see much complexity being added if we were
> to decide to standardise the Python representation.
>

Do you have a specific example in a recent release where a change was made
that you disapproved of? Those of us who have mutated the AST have tried to
not be gratuitous in the changes to begin with while also not letting the
AST make maintaining Python harder. Plus there are external libraries like
typed_ast and asteroid that try to make the AST uniform across releases so
we don't have to worry quite as much about this explicitly.

-brett


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

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

[Brett Cannon]

On Sun, Nov 12, 2017, 10:22 Koos Zevenhoven,  wrote:

> On Nov 12, 2017 19:10, "Guido van Rossum"  wrote:
>
> On Sun, Nov 12, 2017 at 4:14 AM, Koos Zevenhoven 
> wrote:
>
>> So actually my question is: What should happen when the annotation is
>> already a string literal?
>>
>
> The PEP answers that clearly (under Implementation):
>
> > If an annotation was already a string, this string is preserved
> > verbatim.
>
>
> Oh sorry, I was looking for a spec, so I somehow assumed I can ignore the
> gory implementation details just like I routinely ignore things like
> headers and footers of emails.
>
> There's two thing I don't understand here:
>
> * What does it mean to preserve the string verbatim? No matter how I read
> it, I can't tell if it's with quotes or without.
>
> Maybe I'm missing some context.
>

I believe the string passes through unchanged (i.e. no quotes). Think of
the PEP as simply turning all non-string annotations into string ones.

-brett


>
> -- Koos (mobile)
>
> ___
> 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

Re: [Python-Dev] PEP 561 rework

[Guido van Rossum]

Hi Ethan!

This is a nice piece of work. I expect to accept it pretty much verbatim
(with some small edits, see https://github.com/python/peps/pull/467). I
agree with Nick that we don't have to do anything specifically about
control of foo_stubs packages -- nor do I think we need to worry about
foo_stubs vs. foo-stubs.

Everyone else: if you think this should not go through, now's the time to
reply-all here!

--Guido

On Mon, Nov 13, 2017 at 7:58 AM, Ivan Levkivskyi 
wrote:

> Thanks Ethan for all the work!
>
> I will be glad to see this accepted and implemented in mypy.
>
> --
> Ivan
>
>
>
> ___
> 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] Standardise the AST (Re: PEP 563: Postponed Evaluation of Annotations)

[Nathaniel Smith]

Can you give any examples of problems caused by the ast not being
standardized? The original motivation of being able to distinguish between
  foo(x: int)
  foo(x: "int")
isn't very compelling – it's not clear it's a problem in the first place,
and even if it is then all we need is some kind of boolean flag, not an ast
standard.

On Nov 13, 2017 13:38, "Greg Ewing"  wrote:

> Guido van Rossum wrote:
>
>> But Python's syntax changes in nearly every release.
>>
>
> The changes are almost always additions, so there's no
> reason why the AST can't remain backwards compatible.
>
> the AST level ... elides many details (such as whitespace and parentheses).
>>
>
> That's okay, because the AST is only expected to
> represent the semantics of Python code, not its
> exact lexical representation in the source. It's
> the same with Lisp -- comments and whitespace have
> been stripped out by the time you get to Lisp
> data.
>
> Lisp had almost no syntax so I presume the mapping to data structures was
>> nearly trivial compared to Python.
>>
>
> Yes, the Python AST is more complicated, but we
> already have that much complexity in the AST being
> used by the compiler.
>
> If I understand correctly, we also have a process
> for converting that internal structure to and from
> an equally complicated set of Python objects, that
> isn't needed by the compiler and exists purely for
> the convenience of Python code.
>
> I can't see much complexity being added if we were
> to decide to standardise the Python representation.
>
> --
> Greg
> ___
> 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/njs%
> 40pobox.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] PEP 549 vs. PEP 562

[Guido van Rossum]

I've pondered two PEPs that are in (friendly) competition with each other:

- PEP 549 -- Instance Descriptors (Larry Hastings)
- PEP 562 -- Module __getattr__ (Ivan Levkivskyi)

In the end I am *rejecting* PEP 549 and I hope to *accept* PEP 562, with a
small addition to the latter to also support overriding __dir__ (so that
one can provide a __dir__ implementation that matches the __getattr__
implementation, or perhaps counteracts it, in case one wants deprecated
attributes to be omitted from dir() but still usable).

The __dir__ addition is mentioned here:
https://github.com/ilevkivskyi/cpython/pull/3#issuecomment-343591293 .

A bit more motivation for my choice: re-reading PEP 549 reminded me of how
its implementation is remarkably subtle (invoking Armin Rigo; for more
details read https://www.python.org/dev/peps/pep-0549/#implementation). On
the contrary, the implementation of PEP 562 is much simpler. With the Zen
of Python in mind, this gives a hint that it is the better idea, and
possibly even a good idea.

Ivan, once you've added the __dir__ thing to your PEP, please post it to
python-dev to solicit review from its (larger) readership.

-- 
--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] PEP 561 rework

[Sebastian Rittau]

Hello everyone,


Am 14.11.2017 um 00:29 schrieb Guido van Rossum:
This is a nice piece of work. I expect to accept it pretty much 
verbatim (with some small edits, see 
https://github.com/python/peps/pull/467). I agree with Nick that we 
don't have to do anything specifically about control of foo_stubs 
packages -- nor do I think we need to worry about foo_stubs vs. foo-stubs.


Everyone else: if you think this should not go through, now's the time 
to reply-all here!
I am really looking forward to the implementation of this PEP and I am 
glad that it is close to acceptance. One thing that is not really clear 
to me is how module-only packages are handled. Say I have a package 
"foo" that installs the file "foo.py" to site-packages, where would I 
install "foo.pyi" and py.typed to? Or is this case not supported and I 
have to convert the foo module into a package containing just __init__.py?


 - Sebastian
___
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 565: Show DeprecationWarning in __main__

[Nick Coghlan]

On 14 November 2017 at 02:27, Victor Stinner  wrote:
>> The change proposed in this PEP is to update the default warning filter list
>> to be::
>>
>> default::DeprecationWarning:__main__
>> ignore::DeprecationWarning
>> ignore::PendingDeprecationWarning
>> ignore::ImportWarning
>> ignore::BytesWarning
>> ignore::ResourceWarning
>
> This PEP can break applications parsing Python stderr, application
> which don't expect to get DeprecationWarning in their output.

Right, but anything affected by this would eventually have broken
anyway, when the change being warned about actually happens.

That said, reducing the likelihood of breaking application output
parsers is part of the rationale for restricting the change to
unpackaged scripts (we know from the initial PEP 538 implementation
that there's plenty of code out there that doesn't cope well with
unexpected lines appearing on stderr).

> Is it possible to disable this PEP using a command line option and/or
> environment variable to get the Python 3.6 behaviour (always
> DeprecationWarning)?

The patch for the PEP will also update the documentation for the
`PYTHONWARNINGS` environment variable to explicitly call out the
following settings:

PYTHONWARNINGS=error # Convert to exceptions
PYTHONWARNINGS=always # Warn every time
PYTHONWARNINGS=default # Warn once per call location
PYTHONWARNINGS=module # Warn once per calling module
PYTHONWARNINGS=once # Warn once per Python process
PYTHONWARNINGS=ignore # Never warn

And then also cover their respective shorthand command line
equivalents (`-We`, `-Wa`, `-Wd`, `-Wm`,`-Wo`, `-Wi`).

While https://docs.python.org/3/using/cmdline.html#cmdoption-w does
currently explain this, neither it nor
https://docs.python.org/3/using/cmdline.html#envvar-PYTHONWARNINGS
show specific examples

They also don't link directly to
https://docs.python.org/3/library/warnings.html#the-warnings-filter,
and that section doesn't explain the shorthand `:`-separated notation
used in sys.warnoptions.

> I guess that it's
> "PYTHONWARNINGS=ignore::DeprecationWarning:__main__". Am I right?

`PYTHONWARNINGS=ignore::DeprecationWarning` would be the shortest way
to suppress deprecations everywhere again while still getting other
warnings.

> Would you mind to mention that in the PEP, please?

Will do - I actually meant to cover this anyway (hence the reference
to docs changes in the abstract), but I missed it in the initial
draft.

> Sorry, I'm not an expert of the warnings module. Is it possible to
> also configure Python to ignore DeprecationWarning using the warnings
> module, at the start of the __main__ script? Something like
> warnings.filterwarnings("ignore", '', DeprecationWarning)? Again,
> maybe explain that in the PEP?

`warnings.simplefilter("ignore", DeprecationWarning)` is the simplest
runtime option for ensuring that deprecation warnings are never
displayed.

The downside of doing this programmatically is that you can end up
overriding environmental and command line settings, so the best
application level "Only show warnings if my users ask for them"
snippet actually looks like:

if not sys.warnoptions:
warnings.simplefilter("ignore")

(I'll mention this in the PEP and docs patch as well)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

[Nathaniel Smith]

On Mon, Nov 13, 2017 at 6:09 AM, Serhiy Storchaka  wrote:
> 13.11.17 14:29, Antoine Pitrou пише:
>>
>> On Mon, 13 Nov 2017 22:37:46 +1100
>> Chris Angelico  wrote:
>>>
>>> On Mon, Nov 13, 2017 at 9:46 PM, Antoine Pitrou 
>>> wrote:

 On Sun, 12 Nov 2017 19:48:28 -0800
 Nathaniel Smith  wrote:
>
> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan 
> wrote:
>>
>> This change will lead to DeprecationWarning being displayed by default
>> for:
>>
>> * code executed directly at the interactive prompt
>> * code executed directly as part of a single-file script
>
>
> Technically it's orthogonal, but if you're trying to get better
> warnings in the REPL, then you might also want to look at:
>
> https://bugs.python.org/issue1539925
> https://github.com/ipython/ipython/issues/6611


 Depends what you call "better".  Personally, I don't want to see
 warnings each and every time I use a deprecated or questionable
 construct or API from the REPL.
>>>
>>>
>>> Isn't that the entire *point* of warnings? When you're working at the
>>> REPL, you're the one in control of which APIs you use, so you should
>>> be the one to know about deprecations.
>>
>>
>> If I see a warning once every REPL session, I know about the deprecation
>> already, thank you.  I don't need to be taken by the hand like a little
>> child.  Besides, the code I write in the REPL is not meant for durable
>> use.
>
>
> Hmm, now I see that the simple Nathaniel's solution is not completely
> correct. If the warning action is 'module', it should be emitted only once
> if used directly in the REPL, because '__main__' is the same module.

True. The fundamental problem is that generally, Python uses
(filename, lineno) pairs to identify lines of code. But (a) the
warning module assumes that for each namespace dict, there is a unique
mapping between line numbers and lines of code, so it ignores filename
and just keys off lineno, and (b) the REPL re-uses the same (file,
lineno) for different lines of code anyway.

So I guess the fully correct solution would be to use a unique
"filename" when compiling each block of code -- e.g. the REPL could do
the equivalent of compile(, "REPL[1]", ...) for the first line,
compile(, "REPL[2]", ...) for the second line, etc. -- and then
also teach the warnings module's duplicate detection logic to key off
of (file, lineno) pairs instead of just lineno.

-n

-- 
Nathaniel J. Smith -- https://vorpus.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] PEP 561 rework

[Guido van Rossum]

On Mon, Nov 13, 2017 at 3:50 PM, Sebastian Rittau 
wrote:

> Am 14.11.2017 um 00:29 schrieb Guido van Rossum:
>
>> This is a nice piece of work. I expect to accept it pretty much verbatim
>> (with some small edits, see https://github.com/python/peps/pull/467). I
>> agree with Nick that we don't have to do anything specifically about
>> control of foo_stubs packages -- nor do I think we need to worry about
>> foo_stubs vs. foo-stubs.
>>
>> Everyone else: if you think this should not go through, now's the time to
>> reply-all here!
>>
>

> I am really looking forward to the implementation of this PEP and I am
> glad that it is close to acceptance. One thing that is not really clear to
> me is how module-only packages are handled. Say I have a package "foo" that
> installs the file "foo.py" to site-packages, where would I install
> "foo.pyi" and py.typed to? Or is this case not supported and I have to
> convert the foo module into a package containing just __init__.py?
>

Good call. I think that conversion to a package is indeed the best approach
-- it doesn't seem worth it to add more special-casing for this scenario.

Ethan, if you agree, you should just add a sentence about this to the PEP.

-- 
--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] PEP 561 rework

[Ethan Smith]

On Mon, Nov 13, 2017 at 3:50 PM, Sebastian Rittau 
wrote:

> Hello everyone,
>
>
> Am 14.11.2017 um 00:29 schrieb Guido van Rossum:
>
>> This is a nice piece of work. I expect to accept it pretty much verbatim
>> (with some small edits, see https://github.com/python/peps/pull/467). I
>> agree with Nick that we don't have to do anything specifically about
>> control of foo_stubs packages -- nor do I think we need to worry about
>> foo_stubs vs. foo-stubs.
>>
>> Everyone else: if you think this should not go through, now's the time to
>> reply-all here!
>>
> I am really looking forward to the implementation of this PEP and I am
> glad that it is close to acceptance. One thing that is not really clear to
> me is how module-only packages are handled. Say I have a package "foo" that
> installs the file "foo.py" to site-packages, where would I install
> "foo.pyi" and py.typed to? Or is this case not supported and I have to
> convert the foo module into a package containing just __init__.py?
>
> The PEP as of right now provides no support for module only distributions.
I don't think it would be possible to support inline typing in module only
distributions, as a random mymod.py in site/dist-packages is hard to trust.
Refactoring into a package is probably the best option. Alternatively, I
believe a mymod_stubs with just an __init__.pyi might work as a work around
as well.

Ethan


>  - Sebastian
> ___
> 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/ethan%
> 40ethanhs.me
>
___
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] Python possible vulnerabilities in concurrency

[Stephen Michell]

I am looking for one or two experts to discuss with me how Python concurrency 
features fit together, and possible vulnerabilities associated with that.

TR 24772 lists 5 vulnerabilities associated with 

1. activating threads, tasks or pico-threads
2. Directed termination of threads, tasks or pico-threads
3. Premature termination of threads, tasks or pico-threads
4. Concurrent access to data shared between threads, tasks or pico-threads,   
and
5. Lock protocol errors for concurrent entities 

I need to document how these appear (or don’t appear) in Python. The writeups 
would possibly swamp this email reflector, so I am looking for a small number 
of people to review these sections of our language-independent document and 
discuss with me how these are handled in Python. 

I have a good background in these issues, but no relevant experience with 
Python. 

Please contact me at stephen.mich...@maurya.on.ca 
 to respond directly.

Thank you

…stephen michell
Convenor
ISO/IEC/JTC 1/SC 22/WG 23 Programming Language Vulnerabilities Working Group___
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] Add a developer mode to Python: -X dev command line option

[Nick Coghlan]

On 14 November 2017 at 02:08, Victor Stinner  wrote:
> My "-X dev" idea is not incompatible with Nick's PEP 565 "Show
> DeprecationWarning in __main__" and it's different: it's an opt-in
> option, while Nick wants to change the default behaviour.

I'm +1 on a `-X dev` mode, since it enables a lot of things that are
useful for making an application more robust (extension module
debugging, explicit scope-controlled resource management) that I
wouldn't want turned at the REPL by default. It also implicitly
adjusts over time as we add more debugging capabilities.

I don't consider it a replacement for tweaking how we handle
DeprecationWarning by default, though :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com