[Python-Dev] 2.7.9 regression in argparse
Just a pointer for possible regression http://bugs.python.org/issue23058 -- anatoly t. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] super() does not work during class initialization
Hi list, while a class is being initialized in a metaclass, it is not always possible to call classmethods of the class, as they might use super(), which in turn uses __class__, which is not initialized yet. I know that this is a known issue, but well, sometimes it even makes sense to fix already known issues... so I wrote a patch that moves the initialization of __class__ into type.__new__, so that one may use super() in a class once it starts existing. It's issue 23722 on the issue tracker. To illustrate what the problem is, the following code raises a RuntimeError: class Meta(type): def __init__(self, name, bases, dict): super().__init__(name, bases, dict) self.f() class A(metaclass=Meta): @classmethod def f(self): super() it works fine with my patch applied. Technically, my patch slightly changes the semantics of python if a metaclass returns something different in its __new__ than what type.__new__ returns. But I could not find any documentation of the current behavior, and also the tests don't test for it, and I consider the current behavior actually buggy. As an example let me give the following simple Singleton metaclass: class Singleton(type): def __new__(cls, name, bases, dict): return super().__new__(cls, name, bases, dict)() class A(metaclass=Singleton): def test(self): assert(isinstance(__class__, type)) A.test() The current python fails the assertion, while with my patch everything is fine, and I personally think __class__ should always actually refer to the class being defined, which means at the minimum that it is actually, well, a class. Greetings Martin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2015-03-13 - 2015-03-20) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open4798 (-19) closed 30685 (+81) total 35483 (+62) Open issues with patches: 2258 Issues opened (49) == #2211: Cookie.Morsel interface needs update http://bugs.python.org/issue2211 reopened by haypo #22181: os.urandom() should use Linux 3.17 getrandom() syscall http://bugs.python.org/issue22181 reopened by haypo #22359: Remove incorrect uses of recursive make http://bugs.python.org/issue22359 reopened by doko #22516: Windows Installer won't - even when using "just for me"option http://bugs.python.org/issue22516 reopened by NaCl #23187: Segmentation fault, possibly asyncio related http://bugs.python.org/issue23187 reopened by haypo #23637: Warnings error with non-ascii chars. http://bugs.python.org/issue23637 reopened by serhiy.storchaka #23661: Setting a exception side_effect on a mock from create_autospec http://bugs.python.org/issue23661 opened by Ignacio Rossi #23662: Cookie.domain is undocumented http://bugs.python.org/issue23662 opened by Malcolm Smith #23663: Crash on failure in ctypes on Cygwin http://bugs.python.org/issue23663 opened by elieux #23664: Modernize HTML output of difflib.HtmlDiff.make_file() http://bugs.python.org/issue23664 opened by berker.peksag #23665: Provide IDLE menu option to set command-line arguments http://bugs.python.org/issue23665 opened by rhettinger #23666: Add shell session logging option to IDLE http://bugs.python.org/issue23666 opened by rhettinger #23667: IDLE to provide option for making trailing whitespace visible http://bugs.python.org/issue23667 opened by rhettinger #23668: Support os.[f]truncate on Windows http://bugs.python.org/issue23668 opened by steve.dower #23669: test_socket.NonBlockingTCPTests failing due to race condition http://bugs.python.org/issue23669 opened by steve.dower #23670: Modifications to support iOS as a cross-compilation target http://bugs.python.org/issue23670 opened by freakboy3742 #23671: string.Template doesn't work with the self keyword argument http://bugs.python.org/issue23671 opened by serhiy.storchaka #23672: IDLE can crash if file name contains non-BMP Unicode character http://bugs.python.org/issue23672 opened by kamisky #23674: super() documentation isn't very clear http://bugs.python.org/issue23674 opened by Tapani Kiiskinen #23675: glossary entry for 'method resolution order' links to somethin http://bugs.python.org/issue23675 opened by r.david.murray #23676: Add support of UnicodeTranslateError in standard error handler http://bugs.python.org/issue23676 opened by serhiy.storchaka #23677: Mention dict and set comps in library reference http://bugs.python.org/issue23677 opened by FrankMillman #23680: Sporadic freeze in test_interrupted_write_retry_text http://bugs.python.org/issue23680 opened by pitrou #23684: urlparse() documentation does not account for default scheme http://bugs.python.org/issue23684 opened by vadmium #23686: Update Windows and OS X installer OpenSSL to 1.0.2a http://bugs.python.org/issue23686 opened by alex #23688: unnecessary copying of memoryview in gzip.GzipFile.write? http://bugs.python.org/issue23688 opened by wolma #23689: Memory leak in Modules/sre_lib.h http://bugs.python.org/issue23689 opened by abacabadabacaba #23690: re functions never release GIL http://bugs.python.org/issue23690 opened by abacabadabacaba #23691: re.finditer iterator is not reentrant, but doesn't protect aga http://bugs.python.org/issue23691 opened by abacabadabacaba #23692: Undocumented feature prevents re module from finding certain m http://bugs.python.org/issue23692 opened by abacabadabacaba #23693: timeit accuracy could be better http://bugs.python.org/issue23693 opened by rbcollins #23695: idiom for clustering a data series into n-length groups http://bugs.python.org/issue23695 opened by Paddy McCarthy #23697: Module level map & submit for concurrent.futures http://bugs.python.org/issue23697 opened by ncoghlan #23698: Fix inconsistencies in behaviour and document it correctly for http://bugs.python.org/issue23698 opened by pythonhacker #23699: Add a macro to ease writing rich comparisons http://bugs.python.org/issue23699 opened by encukou #23701: Drop extraneous comment from winreg.QueryValue's docstring http://bugs.python.org/issue23701 opened by Claudiu.Popa #23702: docs.python.org/3/howto/descriptor.html still refers to "unbou http://bugs.python.org/issue23702 opened by pfalcon #23703: urljoin() with no directory segments duplicates filename http://bugs.python.org/issue23703 opened by vadmium #23704: Make deques a full MutableSequence by adding index(), insert() http://bugs.python.org/issue23704 opened by rhettinger #23705: Speed-up deque.__contains__ http://bugs.python.org/issue23705 opened by
[Python-Dev] Final call for PEP 488: eliminating PYO files
I have decided to have the default case of no optimization levels mean that
the .pyc file name will have *no* optimization level specified in the name
and thus be just as it is today. I made this decision due to potential
backwards-compatibility issues -- although I expect them to be minutes --
and to not force other implementations like PyPy to have some bogus value
set since they don't have .pyo files to begin with (PyPy actually uses
bytecode for -O and don't bother with -OO since PyPy already uses a bunch
of memory when running).
Since this closes out the last open issue, I need either a BDFL decision or
a BDFAP to be assigned to make a decision. Guido?
==
PEP: 488
Title: Elimination of PYO files
Version: $Revision$
Last-Modified: $Date$
Author: Brett Cannon
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 20-Feb-2015
Post-History:
2015-03-06
2015-03-13
2015-03-20
Abstract
This PEP proposes eliminating the concept of PYO files from Python.
To continue the support of the separation of bytecode files based on
their optimization level, this PEP proposes extending the PYC file
name to include the optimization level in the bytecode repository
directory when it's called for (i.e., the ``__pycache__`` directory).
Rationale
=
As of today, bytecode files come in two flavours: PYC and PYO. A PYC
file is the bytecode file generated and read from when no
optimization level is specified at interpreter startup (i.e., ``-O``
is not specified). A PYO file represents the bytecode file that is
read/written when **any** optimization level is specified (i.e., when
``-O`` **or** ``-OO`` is specified). This means that while PYC
files clearly delineate the optimization level used when they were
generated -- namely no optimizations beyond the peepholer -- the same
is not true for PYO files. To put this in terms of optimization
levels and the file extension:
- 0: ``.pyc``
- 1 (``-O``): ``.pyo``
- 2 (``-OO``): ``.pyo``
The reuse of the ``.pyo`` file extension for both level 1 and 2
optimizations means that there is no clear way to tell what
optimization level was used to generate the bytecode file. In terms
of reading PYO files, this can lead to an interpreter using a mixture
of optimization levels with its code if the user was not careful to
make sure all PYO files were generated using the same optimization
level (typically done by blindly deleting all PYO files and then
using the `compileall` module to compile all-new PYO files [1]_).
This issue is only compounded when people optimize Python code beyond
what the interpreter natively supports, e.g., using the astoptimizer
project [2]_.
In terms of writing PYO files, the need to delete all PYO files
every time one either changes the optimization level they want to use
or are unsure of what optimization was used the last time PYO files
were generated leads to unnecessary file churn. The change proposed
by this PEP also allows for **all** optimization levels to be
pre-compiled for bytecode files ahead of time, something that is
currently impossible thanks to the reuse of the ``.pyo`` file
extension for multiple optimization levels.
As for distributing bytecode-only modules, having to distribute both
``.pyc`` and ``.pyo`` files is unnecessary for the common use-case
of code obfuscation and smaller file deployments. This means that
bytecode-only modules will only load from their non-optimized
``.pyc`` file name.
Proposal
To eliminate the ambiguity that PYO files present, this PEP proposes
eliminating the concept of PYO files and their accompanying ``.pyo``
file extension. To allow for the optimization level to be unambiguous
as well as to avoid having to regenerate optimized bytecode files
needlessly in the `__pycache__` directory, the optimization level
used to generate the bytecode file will be incorporated into the
bytecode file name. When no optimization level is specified, the
pre-PEP ``.pyc`` file name will be used (i.e., no change in file name
semantics). This increases backwards-compatibility while also being
more understanding of Python implementations which have no use for
optimization levels (e.g., PyPy[10]_).
Currently bytecode file names are created by
``importlib.util.cache_from_source()``, approximately using the
following expression defined by PEP 3147 [3]_, [4]_, [5]_::
'{name}.{cache_tag}.pyc'.format(name=module_name,
cache_tag=sys.implementation.cache_tag)
This PEP proposes to change the expression when an optimization
level is specified to::
'{name}.{cache_tag}.opt-{optimization}.pyc'.format(
name=module_name,
cache_tag=sys.implementation.cache_tag,
optimization=str(sys.flags.optimize))
The "opt-" prefix was chosen so as to provide a visual separator
from the cache tag. The placement of the optimization level after
the cache tag was chosen to preserve lexicographi
Re: [Python-Dev] Final call for PEP 488: eliminating PYO files
I am willing to be the BDFL for this PEP. I have tried to skim the recent
discussion (only python-dev) and I don't see much remaining controversy.
HOWEVER... The PEP is not clear (or at least too subtle) about the actual
name for optimization level 0. If I have foo.py, and I compile it three
times with three different optimization levels (no optimization; -O; -OO),
and then I look in __pycache__, would I see this:
# (1)
foo.cpython-35.pyc
foo.cpython-35.opt-1.pyc
foo.cpython-35.opt-2.pyc
Or would I see this?
# (2)
foo.cpython-35.opt-0.pyc
foo.cpython-35.opt-1.pyc
foo.cpython-35.opt-2.pyc
Your lead-in ("I have decided to have the default case of no optimization
levels mean that the .pyc file name will have *no* optimization level
specified in the name and thus be just as it is today.") makes me think I
should expect (1), but I can't actually pinpoint where the language of the
PEP says this.
On Fri, Mar 20, 2015 at 11:34 AM, Brett Cannon wrote:
> I have decided to have the default case of no optimization levels mean
> that the .pyc file name will have *no* optimization level specified in
> the name and thus be just as it is today. I made this decision due to
> potential backwards-compatibility issues -- although I expect them to be
> minutes -- and to not force other implementations like PyPy to have some
> bogus value set since they don't have .pyo files to begin with (PyPy
> actually uses bytecode for -O and don't bother with -OO since PyPy already
> uses a bunch of memory when running).
>
> Since this closes out the last open issue, I need either a BDFL decision
> or a BDFAP to be assigned to make a decision. Guido?
>
> ==
>
> PEP: 488
> Title: Elimination of PYO files
> Version: $Revision$
> Last-Modified: $Date$
> Author: Brett Cannon
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 20-Feb-2015
> Post-History:
> 2015-03-06
> 2015-03-13
> 2015-03-20
>
> Abstract
>
>
> This PEP proposes eliminating the concept of PYO files from Python.
> To continue the support of the separation of bytecode files based on
> their optimization level, this PEP proposes extending the PYC file
> name to include the optimization level in the bytecode repository
> directory when it's called for (i.e., the ``__pycache__`` directory).
>
>
> Rationale
> =
>
> As of today, bytecode files come in two flavours: PYC and PYO. A PYC
> file is the bytecode file generated and read from when no
> optimization level is specified at interpreter startup (i.e., ``-O``
> is not specified). A PYO file represents the bytecode file that is
> read/written when **any** optimization level is specified (i.e., when
> ``-O`` **or** ``-OO`` is specified). This means that while PYC
> files clearly delineate the optimization level used when they were
> generated -- namely no optimizations beyond the peepholer -- the same
> is not true for PYO files. To put this in terms of optimization
> levels and the file extension:
>
> - 0: ``.pyc``
> - 1 (``-O``): ``.pyo``
> - 2 (``-OO``): ``.pyo``
>
> The reuse of the ``.pyo`` file extension for both level 1 and 2
> optimizations means that there is no clear way to tell what
> optimization level was used to generate the bytecode file. In terms
> of reading PYO files, this can lead to an interpreter using a mixture
> of optimization levels with its code if the user was not careful to
> make sure all PYO files were generated using the same optimization
> level (typically done by blindly deleting all PYO files and then
> using the `compileall` module to compile all-new PYO files [1]_).
> This issue is only compounded when people optimize Python code beyond
> what the interpreter natively supports, e.g., using the astoptimizer
> project [2]_.
>
> In terms of writing PYO files, the need to delete all PYO files
> every time one either changes the optimization level they want to use
> or are unsure of what optimization was used the last time PYO files
> were generated leads to unnecessary file churn. The change proposed
> by this PEP also allows for **all** optimization levels to be
> pre-compiled for bytecode files ahead of time, something that is
> currently impossible thanks to the reuse of the ``.pyo`` file
> extension for multiple optimization levels.
>
> As for distributing bytecode-only modules, having to distribute both
> ``.pyc`` and ``.pyo`` files is unnecessary for the common use-case
> of code obfuscation and smaller file deployments. This means that
> bytecode-only modules will only load from their non-optimized
> ``.pyc`` file name.
>
>
> Proposal
>
>
> To eliminate the ambiguity that PYO files present, this PEP proposes
> eliminating the concept of PYO files and their accompanying ``.pyo``
> file extension. To allow for the optimization level to be unambiguous
> as well as to avoid having to regenerate optimized bytecode files
> needlessly in the `__pycache__` directory, the optimization level
Re: [Python-Dev] 2.7.9 regression in argparse
On 3/20/2015 9:31 AM, anatoly techtonik wrote: Just a pointer for possible regression http://bugs.python.org/issue23058 I just added the argparse maintainer to the nosy list -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Final call for PEP 488: eliminating PYO files
On Fri, Mar 20, 2015 at 4:41 PM Guido van Rossum wrote:
> I am willing to be the BDFL for this PEP. I have tried to skim the recent
> discussion (only python-dev) and I don't see much remaining controversy.
> HOWEVER... The PEP is not clear (or at least too subtle) about the actual
> name for optimization level 0. If I have foo.py, and I compile it three
> times with three different optimization levels (no optimization; -O; -OO),
> and then I look in __pycache__, would I see this:
>
> # (1)
> foo.cpython-35.pyc
> foo.cpython-35.opt-1.pyc
> foo.cpython-35.opt-2.pyc
>
> Or would I see this?
>
> # (2)
> foo.cpython-35.opt-0.pyc
> foo.cpython-35.opt-1.pyc
> foo.cpython-35.opt-2.pyc
>
#1
>
> Your lead-in ("I have decided to have the default case of no optimization
> levels mean that the .pyc file name will have *no* optimization level
> specified in the name and thus be just as it is today.") makes me think I
> should expect (1), but I can't actually pinpoint where the language of the
> PEP says this.
>
It was meant to be explained by "When no optimization level is specified,
the pre-PEP ``.pyc`` file name will be used (i.e., no change in file name
semantics)", but obviously it's a bit too subtle. I just updated the PEP
with an explicit list of bytecode file name examples based on no -O, -O,
and -OO.
-Brett
>
>
> On Fri, Mar 20, 2015 at 11:34 AM, Brett Cannon wrote:
>
>> I have decided to have the default case of no optimization levels mean
>> that the .pyc file name will have *no* optimization level specified in
>> the name and thus be just as it is today. I made this decision due to
>> potential backwards-compatibility issues -- although I expect them to be
>> minutes -- and to not force other implementations like PyPy to have some
>> bogus value set since they don't have .pyo files to begin with (PyPy
>> actually uses bytecode for -O and don't bother with -OO since PyPy already
>> uses a bunch of memory when running).
>>
>> Since this closes out the last open issue, I need either a BDFL decision
>> or a BDFAP to be assigned to make a decision. Guido?
>>
>> ==
>>
>> PEP: 488
>> Title: Elimination of PYO files
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Brett Cannon
>> Status: Draft
>> Type: Standards Track
>> Content-Type: text/x-rst
>> Created: 20-Feb-2015
>> Post-History:
>> 2015-03-06
>> 2015-03-13
>> 2015-03-20
>>
>> Abstract
>>
>>
>> This PEP proposes eliminating the concept of PYO files from Python.
>> To continue the support of the separation of bytecode files based on
>> their optimization level, this PEP proposes extending the PYC file
>> name to include the optimization level in the bytecode repository
>> directory when it's called for (i.e., the ``__pycache__`` directory).
>>
>>
>> Rationale
>> =
>>
>> As of today, bytecode files come in two flavours: PYC and PYO. A PYC
>> file is the bytecode file generated and read from when no
>> optimization level is specified at interpreter startup (i.e., ``-O``
>> is not specified). A PYO file represents the bytecode file that is
>> read/written when **any** optimization level is specified (i.e., when
>> ``-O`` **or** ``-OO`` is specified). This means that while PYC
>> files clearly delineate the optimization level used when they were
>> generated -- namely no optimizations beyond the peepholer -- the same
>> is not true for PYO files. To put this in terms of optimization
>> levels and the file extension:
>>
>> - 0: ``.pyc``
>> - 1 (``-O``): ``.pyo``
>> - 2 (``-OO``): ``.pyo``
>>
>> The reuse of the ``.pyo`` file extension for both level 1 and 2
>> optimizations means that there is no clear way to tell what
>> optimization level was used to generate the bytecode file. In terms
>> of reading PYO files, this can lead to an interpreter using a mixture
>> of optimization levels with its code if the user was not careful to
>> make sure all PYO files were generated using the same optimization
>> level (typically done by blindly deleting all PYO files and then
>> using the `compileall` module to compile all-new PYO files [1]_).
>> This issue is only compounded when people optimize Python code beyond
>> what the interpreter natively supports, e.g., using the astoptimizer
>> project [2]_.
>>
>> In terms of writing PYO files, the need to delete all PYO files
>> every time one either changes the optimization level they want to use
>> or are unsure of what optimization was used the last time PYO files
>> were generated leads to unnecessary file churn. The change proposed
>> by this PEP also allows for **all** optimization levels to be
>> pre-compiled for bytecode files ahead of time, something that is
>> currently impossible thanks to the reuse of the ``.pyo`` file
>> extension for multiple optimization levels.
>>
>> As for distributing bytecode-only modules, having to distribute both
>> ``.pyc`` and ``.pyo`` files is unnecessary for the common use-case
>> of code obfuscation
Re: [Python-Dev] Missing *-unpacking generalizations (issue 2292)
Wow, this is an excellent review. Thank you.
My only question is with respect to this:
I think there ought to be two opcodes; one for unpacking maps in
function calls and another for literals. The whole function location
thing is rather hideous.
What are the two opcodes? BUILD_MAP_UNPACK and BUILD_MAP_UNPACK_WITH_CALL?
The first takes (n) a number of maps that it will merge, and the second
does the same but also accepts (function_call_location) for the purpose of
error reporting?
Thanks,
Neil
On Thu, Mar 19, 2015 at 1:53 PM, wrote:
> It's a start.
>
> There need to be documentation updates.
>
> There are still unrelated style changes in compile.c that should be
> reverted.
>
>
> http://bugs.python.org/review/2292/diff/14152/Include/opcode.h
> File Include/opcode.h (right):
>
> http://bugs.python.org/review/2292/diff/14152/Include/opcode.h#newcode71
> Include/opcode.h:71: #define DELETE_GLOBAL 98
> This file should not be manually changed. Rather,
> Tools/scripts/generate_opcode_h.py should be run.
>
> http://bugs.python.org/review/2292/diff/14152/Lib/importlib/_bootstrap.py
> File Lib/importlib/_bootstrap.py (right):
>
>
> http://bugs.python.org/review/2292/diff/14152/Lib/importlib/_bootstrap.py#newcode428
> Lib/importlib/_bootstrap.py:428: MAGIC_NUMBER = (3321).to_bytes(2,
> 'little') + b'\r\n'
> As the comment above indicates, the magic value should be incremented by
> 10 not 1. Also, the comment needs to be updated.
>
> http://bugs.python.org/review/2292/diff/14152/Lib/test/test_ast.py
> File Lib/test/test_ast.py (right):
>
>
> http://bugs.python.org/review/2292/diff/14152/Lib/test/test_ast.py#newcode937
> Lib/test/test_ast.py:937: main()
> Why is this here?
>
> http://bugs.python.org/review/2292/diff/14152/Lib/test/test_parser.py
> File Lib/test/test_parser.py (right):
>
>
> http://bugs.python.org/review/2292/diff/14152/Lib/test/test_parser.py#newcode334
> Lib/test/test_parser.py:334: self.check_expr('{**{}, 3:4, **{5:6,
> 7:8}}')
> Should there be tests for the new function call syntax, too?
>
> http://bugs.python.org/review/2292/diff/14152/Python/ast.c
> File Python/ast.c (right):
>
> http://bugs.python.org/review/2292/diff/14152/Python/ast.c#newcode1746
> Python/ast.c:1746: ast_error(c, n, "iterable unpacking cannot be used in
> comprehension");
> |n| should probably be |ch|
>
> http://bugs.python.org/review/2292/diff/14152/Python/ast.c#newcode2022
> Python/ast.c:2022: if (TYPE(CHILD(ch, 0)) == DOUBLESTAR)
> int is_dict = TYPE(CHILD(ch, 0)) == DOUBLESTAR;
>
> http://bugs.python.org/review/2292/diff/14152/Python/ast.c#newcode2026
> Python/ast.c:2026: && TYPE(CHILD(ch, 1)) == COMMA)) {
> boolean operators should be on the previous line
>
> http://bugs.python.org/review/2292/diff/14152/Python/ast.c#newcode2031
> Python/ast.c:2031: && TYPE(CHILD(ch, 1)) == comp_for) {
> ditto
>
> http://bugs.python.org/review/2292/diff/14152/Python/ast.c#newcode2036
> Python/ast.c:2036: && TYPE(CHILD(ch, 3 - is_dict)) == comp_for) {
> ditto
>
> http://bugs.python.org/review/2292/diff/14152/Python/ceval.c
> File Python/ceval.c (right):
>
> http://bugs.python.org/review/2292/diff/14152/Python/ceval.c#newcode2403
> Python/ceval.c:2403: as_tuple = PyObject_CallFunctionObjArgs(
> Use PyList_AsTuple.
>
> http://bugs.python.org/review/2292/diff/14152/Python/ceval.c#newcode2498
> Python/ceval.c:2498: TARGET(BUILD_MAP_UNPACK) {
> I think there ought to be two opcodes; one for unpacking maps in
> function calls and another for literals. The whole function location
> thing is rather hideous.
>
> http://bugs.python.org/review/2292/diff/14152/Python/ceval.c#newcode2526
> Python/ceval.c:2526: if (PySet_Size(intersection)) {
> Probably this would be faster with PySet_GET_SIZE(so).
>
> http://bugs.python.org/review/2292/diff/14152/Python/compile.c
> File Python/compile.c (right):
>
> http://bugs.python.org/review/2292/diff/14152/Python/compile.c#newcode2931
> Python/compile.c:2931: asdl_seq_SET(elts, i, elt->v.Starred.value);
> The compiler should not be mutating the AST.
>
> http://bugs.python.org/review/2292/diff/14152/Python/compile.c#newcode3088
> Python/compile.c:3088: int i, nseen, nkw = 0;
> Many of these should probably be Py_ssize_t.
>
> http://bugs.python.org/review/2292/diff/14152/Python/symtable.c
> File Python/symtable.c (right):
>
> http://bugs.python.org/review/2292/diff/14152/Python/symtable.c#newcode1372
> Python/symtable.c:1372: if (e != NULL) {
> Please fix the callers, so they don't pass NULL here.
>
> http://bugs.python.org/review/2292/
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Final call for PEP 488: eliminating PYO files
Awesome, that's what I was hoping. Accepted! Congrats and thank you very
much for writing the PEP and guiding the discussion.
On Fri, Mar 20, 2015 at 4:00 PM, Brett Cannon wrote:
>
>
> On Fri, Mar 20, 2015 at 4:41 PM Guido van Rossum wrote:
>
>> I am willing to be the BDFL for this PEP. I have tried to skim the recent
>> discussion (only python-dev) and I don't see much remaining controversy.
>> HOWEVER... The PEP is not clear (or at least too subtle) about the actual
>> name for optimization level 0. If I have foo.py, and I compile it three
>> times with three different optimization levels (no optimization; -O; -OO),
>> and then I look in __pycache__, would I see this:
>>
>> # (1)
>> foo.cpython-35.pyc
>> foo.cpython-35.opt-1.pyc
>> foo.cpython-35.opt-2.pyc
>>
>> Or would I see this?
>>
>> # (2)
>> foo.cpython-35.opt-0.pyc
>> foo.cpython-35.opt-1.pyc
>> foo.cpython-35.opt-2.pyc
>>
>
> #1
>
>
>>
>> Your lead-in ("I have decided to have the default case of no optimization
>> levels mean that the .pyc file name will have *no* optimization level
>> specified in the name and thus be just as it is today.") makes me think I
>> should expect (1), but I can't actually pinpoint where the language of the
>> PEP says this.
>>
>
> It was meant to be explained by "When no optimization level is specified,
> the pre-PEP ``.pyc`` file name will be used (i.e., no change in file name
> semantics)", but obviously it's a bit too subtle. I just updated the PEP
> with an explicit list of bytecode file name examples based on no -O, -O,
> and -OO.
>
> -Brett
>
>
>>
>>
>> On Fri, Mar 20, 2015 at 11:34 AM, Brett Cannon wrote:
>>
>>> I have decided to have the default case of no optimization levels mean
>>> that the .pyc file name will have *no* optimization level specified in
>>> the name and thus be just as it is today. I made this decision due to
>>> potential backwards-compatibility issues -- although I expect them to be
>>> minutes -- and to not force other implementations like PyPy to have some
>>> bogus value set since they don't have .pyo files to begin with (PyPy
>>> actually uses bytecode for -O and don't bother with -OO since PyPy already
>>> uses a bunch of memory when running).
>>>
>>> Since this closes out the last open issue, I need either a BDFL decision
>>> or a BDFAP to be assigned to make a decision. Guido?
>>>
>>> ==
>>>
>>> PEP: 488
>>> Title: Elimination of PYO files
>>> Version: $Revision$
>>> Last-Modified: $Date$
>>> Author: Brett Cannon
>>> Status: Draft
>>> Type: Standards Track
>>> Content-Type: text/x-rst
>>> Created: 20-Feb-2015
>>> Post-History:
>>> 2015-03-06
>>> 2015-03-13
>>> 2015-03-20
>>>
>>> Abstract
>>>
>>>
>>> This PEP proposes eliminating the concept of PYO files from Python.
>>> To continue the support of the separation of bytecode files based on
>>> their optimization level, this PEP proposes extending the PYC file
>>> name to include the optimization level in the bytecode repository
>>> directory when it's called for (i.e., the ``__pycache__`` directory).
>>>
>>>
>>> Rationale
>>> =
>>>
>>> As of today, bytecode files come in two flavours: PYC and PYO. A PYC
>>> file is the bytecode file generated and read from when no
>>> optimization level is specified at interpreter startup (i.e., ``-O``
>>> is not specified). A PYO file represents the bytecode file that is
>>> read/written when **any** optimization level is specified (i.e., when
>>> ``-O`` **or** ``-OO`` is specified). This means that while PYC
>>> files clearly delineate the optimization level used when they were
>>> generated -- namely no optimizations beyond the peepholer -- the same
>>> is not true for PYO files. To put this in terms of optimization
>>> levels and the file extension:
>>>
>>> - 0: ``.pyc``
>>> - 1 (``-O``): ``.pyo``
>>> - 2 (``-OO``): ``.pyo``
>>>
>>> The reuse of the ``.pyo`` file extension for both level 1 and 2
>>> optimizations means that there is no clear way to tell what
>>> optimization level was used to generate the bytecode file. In terms
>>> of reading PYO files, this can lead to an interpreter using a mixture
>>> of optimization levels with its code if the user was not careful to
>>> make sure all PYO files were generated using the same optimization
>>> level (typically done by blindly deleting all PYO files and then
>>> using the `compileall` module to compile all-new PYO files [1]_).
>>> This issue is only compounded when people optimize Python code beyond
>>> what the interpreter natively supports, e.g., using the astoptimizer
>>> project [2]_.
>>>
>>> In terms of writing PYO files, the need to delete all PYO files
>>> every time one either changes the optimization level they want to use
>>> or are unsure of what optimization was used the last time PYO files
>>> were generated leads to unnecessary file churn. The change proposed
>>> by this PEP also allows for **all** optimization levels to be
>>> pre-compiled for bytecode file
[Python-Dev] Fwd: class os.DirEntry is confusing,
-- Forwarded message -- From: 罗勇刚(Yonggang Luo) Date: 2015-03-21 2:24 GMT+08:00 Subject: class os.DirEntry is confusing, To: Python Should be replaced with os.FsEntry or os.ScanEntry -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pep 7
If ever someone wants to clean up the repository to conform to PEP 7, I
wrote a program that catches a couple hundred PEP 7 violations in ./Python
alone (1400 in the whole codebase):
import os
import re
def grep(path, regex):
reg_obj = re.compile(regex, re.M)
res = []
for root, dirs, fnames in os.walk(path):
for fname in fnames:
if fname.endswith('.c'):
path = os.path.join(root, fname)
with open(path) as f:
data = f.read()
for m in reg_obj.finditer(data):
line_number = sum(c == '\n'
for c in data[:m.start()]) + 1
res.append("{}: {}".format(path, line_number))
return res
for pattern in [
r'^\s*\|\|',
r'^\s*\&\&',
r'} else {',
r'\___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] some minor questions about pep8
In pep8 there are two conflicting statements, both https://www.python.org/dev/peps/pep-0008/#version-bookkeeping https://www.python.org/dev/peps/pep-0008/#imports Stipulate that they should be "at the top of the file after any module comments and docstrings." Which of these takes precedence? Secondly, we also have an "__author__", and "__project__" variables, I assume these would be put with the version information as well? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] some minor questions about pep8
Lewis Coates writes: > In pep8 there are two conflicting statements, both > > https://www.python.org/dev/peps/pep-0008/#version-bookkeeping > https://www.python.org/dev/peps/pep-0008/#imports > > Stipulate that they should be "at the top of the file after any module > comments and docstrings." Which of these takes precedence? I don't know an official answer. The convention I've observed is overwhelmingly in one direction: import statements come before any assignment statements. > Secondly, we also have an "__author__", and "__project__" variables, I > assume these would be put with the version information as well? Yes. -- \ “Welchen Teil von ‘Gestalt’ verstehen Sie nicht? [What part of | `\‘gestalt’ don't you understand?]” —Karsten M. Self | _o__) | Ben Finney ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep 7
On Fri, Mar 20, 2015 at 7:54 PM, Neil Girdhar wrote:
> If ever someone wants to clean up the repository to conform to PEP 7, I
> wrote a program that catches a couple hundred PEP 7 violations in ./Python
> alone (1400 in the whole codebase):
>
> import os
> import re
>
> def grep(path, regex):
> reg_obj = re.compile(regex, re.M)
> res = []
> for root, dirs, fnames in os.walk(path):
> for fname in fnames:
> if fname.endswith('.c'):
> path = os.path.join(root, fname)
> with open(path) as f:
> data = f.read()
> for m in reg_obj.finditer(data):
> line_number = sum(c == '\n'
> for c in data[:m.start()]) + 1
> res.append("{}: {}".format(path, line_number))
> return res
>
> for pattern in [
> r'^\s*\|\|',
> r'^\s*\&\&',
> r'} else {',
> r'\ ]:
> print("Searching for", pattern)
> print("\n".join(grep('.', pattern)))
>
> In my experience, it was hard to write PEP 7 conforming code when the
> surrounding code is inconsistent.
You can usually change surrounding code within reason if you want to
add conforming code of your own, but there's little value and high
risk in any mass change just to apply the style guidelines.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep 7
The code reviews I got asked me to revert PEP 7 changes. I can understand
that, but then logically someone should go ahead and clean up the code.
It's not "high risk" if you just check for whitespace equivalence of the
source code and binary equivalence of the compiled code. The value is for
people who are new to the codebase.
Best,
Neil
On Fri, Mar 20, 2015 at 10:35 PM, Brian Curtin wrote:
> On Fri, Mar 20, 2015 at 7:54 PM, Neil Girdhar
> wrote:
> > If ever someone wants to clean up the repository to conform to PEP 7, I
> > wrote a program that catches a couple hundred PEP 7 violations in
> ./Python
> > alone (1400 in the whole codebase):
> >
> > import os
> > import re
> >
> > def grep(path, regex):
> > reg_obj = re.compile(regex, re.M)
> > res = []
> > for root, dirs, fnames in os.walk(path):
> > for fname in fnames:
> > if fname.endswith('.c'):
> > path = os.path.join(root, fname)
> > with open(path) as f:
> > data = f.read()
> > for m in reg_obj.finditer(data):
> > line_number = sum(c == '\n'
> > for c in data[:m.start()]) + 1
> > res.append("{}: {}".format(path, line_number))
> > return res
> >
> > for pattern in [
> > r'^\s*\|\|',
> > r'^\s*\&\&',
> > r'} else {',
> > r'\ > ]:
> > print("Searching for", pattern)
> > print("\n".join(grep('.', pattern)))
> >
> > In my experience, it was hard to write PEP 7 conforming code when the
> > surrounding code is inconsistent.
>
> You can usually change surrounding code within reason if you want to
> add conforming code of your own, but there's little value and high
> risk in any mass change just to apply the style guidelines.
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep 7
On Fri, Mar 20, 2015 at 10:02 PM, Neil Girdhar wrote: > The code reviews I got asked me to revert PEP 7 changes. I can understand > that, but then logically someone should go ahead and clean up the code. > It's not "high risk" if you just check for whitespace equivalence of the > source code and binary equivalence of the compiled code. The value is for > people who are new to the codebase. There are a lot of areas of the C code that aren't explicitly or directly tested, so yes, a lot of changes are high risk, especially in bulk. While a one time change while checking binary equivalence would do it, it's also a huge amount of churn just to follow a guideline. Without an automated checker for the guidelines, if things get in they just get in, and sometimes you can modify them while making improvements to the code, but sometimes it depends on what exactly you're doing as well. On top of this, we already disallow mass PEP 8 changes to avoid the churn there as well, and it took a good bit of convincing for another semi-recent mass change (although I can't remember the topic, but it was deemed safe enough to make). Another common issue with mass code churn like this is that it affects tooling, such as `hg blame` ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] some minor questions about pep8
FWIW, I think __version__, __author__ etc. were bad ideas. Almost nobody manages these correctly. Note that the PEP 8 section starts with less than an endorsement: "If you *have* to have Subversion, CVS, or RCS crud in your source file, do it as follows." That said, if an official answer is required, common sense would suggest that __version__ should go before the imports. (I would put it before the docstring too, except then the docstring wouldn't be a docstring any more. Go figure.) On Fri, Mar 20, 2015 at 6:38 PM, Ben Finney wrote: > Lewis Coates writes: > > > In pep8 there are two conflicting statements, both > > > > https://www.python.org/dev/peps/pep-0008/#version-bookkeeping > > https://www.python.org/dev/peps/pep-0008/#imports > > > > Stipulate that they should be "at the top of the file after any module > > comments and docstrings." Which of these takes precedence? > > I don't know an official answer. The convention I've observed is > overwhelmingly in one direction: import statements come before any > assignment statements. > > > Secondly, we also have an "__author__", and "__project__" variables, I > > assume these would be put with the version information as well? > > Yes. > > -- > \ “Welchen Teil von ‘Gestalt’ verstehen Sie nicht? [What part of | > `\‘gestalt’ don't you understand?]” —Karsten M. Self | > _o__) | > Ben Finney > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep 7
Neil, you have no idea. Please back off.
On Fri, Mar 20, 2015 at 8:02 PM, Neil Girdhar wrote:
> The code reviews I got asked me to revert PEP 7 changes. I can understand
> that, but then logically someone should go ahead and clean up the code.
> It's not "high risk" if you just check for whitespace equivalence of the
> source code and binary equivalence of the compiled code. The value is for
> people who are new to the codebase.
>
> Best,
>
> Neil
>
> On Fri, Mar 20, 2015 at 10:35 PM, Brian Curtin wrote:
>
>> On Fri, Mar 20, 2015 at 7:54 PM, Neil Girdhar
>> wrote:
>> > If ever someone wants to clean up the repository to conform to PEP 7, I
>> > wrote a program that catches a couple hundred PEP 7 violations in
>> ./Python
>> > alone (1400 in the whole codebase):
>> >
>> > import os
>> > import re
>> >
>> > def grep(path, regex):
>> > reg_obj = re.compile(regex, re.M)
>> > res = []
>> > for root, dirs, fnames in os.walk(path):
>> > for fname in fnames:
>> > if fname.endswith('.c'):
>> > path = os.path.join(root, fname)
>> > with open(path) as f:
>> > data = f.read()
>> > for m in reg_obj.finditer(data):
>> > line_number = sum(c == '\n'
>> > for c in data[:m.start()]) + 1
>> > res.append("{}: {}".format(path, line_number))
>> > return res
>> >
>> > for pattern in [
>> > r'^\s*\|\|',
>> > r'^\s*\&\&',
>> > r'} else {',
>> > r'\> > ]:
>> > print("Searching for", pattern)
>> > print("\n".join(grep('.', pattern)))
>> >
>> > In my experience, it was hard to write PEP 7 conforming code when the
>> > surrounding code is inconsistent.
>>
>> You can usually change surrounding code within reason if you want to
>> add conforming code of your own, but there's little value and high
>> risk in any mass change just to apply the style guidelines.
>>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] some minor questions about pep8
Guido, In that case would you be open to a patch to update the PEP accordingly? Additionally, does that official statement cover other dunder assignments (e.g. "__author__"?). If so I'll update the PEP8 tool accordingly. Thanks, ~ Ian Lee On Mar 20, 2015 8:55 PM, "Guido van Rossum" wrote: > FWIW, I think __version__, __author__ etc. were bad ideas. Almost nobody > manages these correctly. Note that the PEP 8 section starts with less than > an endorsement: "If you *have* to have Subversion, CVS, or RCS crud in > your source file, do it as follows." > > That said, if an official answer is required, common sense would suggest > that __version__ should go before the imports. (I would put it before the > docstring too, except then the docstring wouldn't be a docstring any more. > Go figure.) > > On Fri, Mar 20, 2015 at 6:38 PM, Ben Finney > wrote: > >> Lewis Coates writes: >> >> > In pep8 there are two conflicting statements, both >> > >> > https://www.python.org/dev/peps/pep-0008/#version-bookkeeping >> > https://www.python.org/dev/peps/pep-0008/#imports >> > >> > Stipulate that they should be "at the top of the file after any module >> > comments and docstrings." Which of these takes precedence? >> >> I don't know an official answer. The convention I've observed is >> overwhelmingly in one direction: import statements come before any >> assignment statements. >> >> > Secondly, we also have an "__author__", and "__project__" variables, I >> > assume these would be put with the version information as well? >> >> Yes. >> >> -- >> \ “Welchen Teil von ‘Gestalt’ verstehen Sie nicht? [What part of | >> `\‘gestalt’ don't you understand?]” —Karsten M. Self | >> _o__) | >> Ben Finney >> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > > -- > --Guido van Rossum (python.org/~guido) > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/ianlee1521%40gmail.com > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep 7
On Fri, Mar 20, 2015 at 10:57 PM, Guido van Rossum wrote: > Neil, you have no idea. Please back off. I wouldn't go that far. Wanting a quality code base certainly isn't a bad thing, but there's a lot more progress to be made by working with what's there and being as mindful as possible of the guidelines moving forward. After all, they're guidelines, not rules. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] How to document functions with optional positional parameters?
How to document functions with optional positional parameters? For example binascii.crc32(). It has two positional parameters, one is mandatory, and one is optional with default value 0. With Argument Clinic its signature is crc32(data, crc=0, /). In the documentation it is written as crc32(data[, crc]) (and noted that the default value of the second parameter is 0). Both are not valid Python syntax. Can the documentation be change to crc32(data, crc=0)? Related issues: https://bugs.python.org/issue21488 (changed encode(obj, encoding='ascii', errors='strict') to encode(obj, [encoding[, errors]])) https://bugs.python.org/issue22832 (changed ioctl(fd, op[, arg[, mutate_flag]]) to ioctl(fd, request, arg=0, mutate_flag=True)) https://bugs.python.org/issue22341 (discussed changing crc32(data[, crc]) to crc32(data, crc=0)) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] some minor questions about pep8
FWIW, I would vote for the "__version__", "__author__", etc assignments
being after the imports. Reason being cases where the "__version__" is not
from VCS, but is calculated from pkg_resources:
from pkg_resources import get_distribution
__version__ = get_distribution('mypackage').version
Also, then more useful things like "__all__" (which can very reasonably
rely on imports), can be together with "__version__" and "__author__"
assignments.
I would vote:
shebang
docstring
imports
dunder assignments
other code...
~ Ian Lee
On Fri, Mar 20, 2015 at 9:24 PM, Ian Lee wrote:
> Guido,
>
> In that case would you be open to a patch to update the PEP accordingly?
>
> Additionally, does that official statement cover other dunder assignments
> (e.g. "__author__"?). If so I'll update the PEP8 tool accordingly.
>
> Thanks,
>
> ~ Ian Lee
> On Mar 20, 2015 8:55 PM, "Guido van Rossum" wrote:
>
>> FWIW, I think __version__, __author__ etc. were bad ideas. Almost nobody
>> manages these correctly. Note that the PEP 8 section starts with less than
>> an endorsement: "If you *have* to have Subversion, CVS, or RCS crud in
>> your source file, do it as follows."
>>
>> That said, if an official answer is required, common sense would suggest
>> that __version__ should go before the imports. (I would put it before the
>> docstring too, except then the docstring wouldn't be a docstring any more.
>> Go figure.)
>>
>> On Fri, Mar 20, 2015 at 6:38 PM, Ben Finney
>> wrote:
>>
>>> Lewis Coates writes:
>>>
>>> > In pep8 there are two conflicting statements, both
>>> >
>>> > https://www.python.org/dev/peps/pep-0008/#version-bookkeeping
>>> > https://www.python.org/dev/peps/pep-0008/#imports
>>> >
>>> > Stipulate that they should be "at the top of the file after any module
>>> > comments and docstrings." Which of these takes precedence?
>>>
>>> I don't know an official answer. The convention I've observed is
>>> overwhelmingly in one direction: import statements come before any
>>> assignment statements.
>>>
>>> > Secondly, we also have an "__author__", and "__project__" variables, I
>>> > assume these would be put with the version information as well?
>>>
>>> Yes.
>>>
>>> --
>>> \ “Welchen Teil von ‘Gestalt’ verstehen Sie nicht? [What part of |
>>> `\‘gestalt’ don't you understand?]” —Karsten M. Self |
>>> _o__) |
>>> Ben Finney
>>>
>>> ___
>>> Python-Dev mailing list
>>> [email protected]
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>>
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/ianlee1521%40gmail.com
>>
>>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
