Mailman 3 April 2018 - Python-Dev

PEP 572: Why not := as standard assignment operator?
by Martin Teichmann 26 Apr '18

26 Apr '18

Hi list, when reading PEP 572 I actually liked it a lot - I think it's actually a cool idea. I think it's actually that cool an idea that it should be made the default way of doing an assignment, over time phasing out the good ole =. This would have several benefits: - people wouldn't have to worry about two different options - different things would have a different look: assignment is :=, keyword args is =, while comparison is ==. Especially beginners would benefit from this clarity. in this case, for sure, we should make it possible to chain :=s, for example by making it bind right-to-left, so that a := b := 3 would be a := (b := 3) I'm sorry if somebody brought that up already, but the discussion has grown so huge that I couldn't read through it entirely. Greetings Martin

5 5

Nickname Binding (PEP 572)
by Jim J. Jewett 26 Apr '18

26 Apr '18

I think part of the disconnect is that this enhancement could very easily be abused, and it seems likely that it will be, because the problems aren't visible while writing the code -- only when reading it later. I therefore suggest making it very clear in the PEP -- and probably in PEP 8 -- how these expressions should be limited. Simply renaming them to "nickname binding" would be start, but here is a rough draft for wording. When scanning code by eye, it is helpful that assignments are (almost) always at the start of a line. Even def and class statements can cause confusion if the reader didn't realize that the name referred to a class, rather than an instance. Moving assignments to the middle of a line will make it harder for someone else to read your code -- so don't do that. A nickname is just a regular name, except that it also suggests an intimate environment. If the name is purely for documentation, or will be used only later in the same expression (or, possibly, the same block or just after), then a nickname may be appropriate. But * If you are wondering what to do about type hints, then the expression is probably too complex to leave inline. Separate it out into a regular assignment statement; nicknames do not support type hints. * If you will be saving the value -- even as an attribute on self -- there is a chance it will be retrieved in a very different context. Use a regular assignment statement; nicknames are just simple names, not attributes or keys. * If you will be using the value somewhere else in your code, use a regular assignment statement. This makes it easier to find, and warns people that the value may be used again later. -jJ

1 0

PEP 573 -- Module State Access from C Extension Methods
by Marcel Plch 26 Apr '18

26 Apr '18

Hello, I am an intern at Red Hat mentored by Petr Viktorin. As a part of my internship, I learned the CPython internals and how to contribute to the CPython interpreter. As a result, I have prepared PEP 573, which solves some problems that PEP 489 (Multi-phase extension module initialization) has left open. Specifically, this PEP proposes a way to access per-module state from methods of built-in and extension types. Like PEP 489, it aims to make subinterpreter-friendly built-in/extension modules easier to create. A big problem found when converting many modules to PEP 489 multi-phase initialization is subinterpreter-friendly access to exception types defined in built-in/extension modules. This PEP solves this by introducing "immutable exception types". The current implementation requires one new type flag and two new pointers in the heap type structure. It should be possible to remove eiher the flag or one of the two pointers, if we agree on the other mechanics in the PEP . =================== PEP: 573 Title: Module State Access from C Extension Methods Version: $Revision$ Last-Modified: $Date$ Author: Petr Viktorin <encukou(a)gmail.com>, Nick Coghlan <ncoghlan(a)gmail.com>, Eric Snow <ericsnowcurrently(a)gmail.com>, Marcel Plch <gmarcel.plch(a)gmail.com> Discussions-To: import-sig(a)python.org Status: Active Type: Process Content-Type: text/x-rst Created: 02-Jun-2016 Python-Version: 3.8 Post-History: Abstract ======== This PEP proposes to add a way for CPython extension methods to access context such as the state of the modules they are defined in. This will allow extension methods to use direct pointer dereferences rather than PyState_FindModule for looking up module state, reducing or eliminating the performance cost of using module-scoped state over process global state. This fixes one of the remaining roadblocks for adoption of PEP 3121 (Extension module initialization and finalization) and PEP 489 (Multi-phase extension module initialization). Additionaly, support for easier creation of immutable exception classes is added. This removes the need for keeping per-module state if it would only be used for exception classes. While this PEP takes an additional step towards fully solving the problems that PEP 3121 and PEP 489 started tackling, it does not attempt to resolve *all* remaining concerns. In particular, accessing the module state from slot methods (``nb_add``, etc) remains slower than accessing that state from other extension methods. Terminology =========== Process-Global State -------------------- C-level static variables. Since this is very low-level memory storage, it must be managed carefully. Per-module State ---------------- State local to a module object, allocated dynamically as part of a module object's initialization. This isolates the state from other instances of the module (including those in other subinterpreters). Accessed by ``PyModule_GetState()``. Static Type ----------- A type object defined as a C-level static variable, i.e. a compiled-in type object. A static type needs to be shared between module instances and has no information of what module it belongs to. Static types do not have ``__dict__`` (although their instances might). Heap Type --------- A type object created at run time. Rationale ========= PEP 489 introduced a new way to initialize extension modules, which brings several advantages to extensions that implement it: * The extension modules behave more like their Python counterparts. * The extension modules can easily support loading into pre-existing module objects, which paves the way for extension module support for ``runpy`` or for systems that enable extension module reloading. * Loading multiple modules from the same extension is possible, which makes testing module isolation (a key feature for proper sub-interpreter support) possible from a single interpreter. The biggest hurdle for adoption of PEP 489 is allowing access to module state from methods of extension types. Currently, the way to access this state from extension methods is by looking up the module via ``PyState_FindModule`` (in contrast to module level functions in extension modules, which receive a module reference as an argument). However, ``PyState_FindModule`` queries the thread-local state, making it relatively costly compared to C level process global access and consequently deterring module authors from using it. Also, ``PyState_FindModule`` relies on the assumption that in each subinterpreter, there is at most one module corresponding to a given ``PyModuleDef``. This does not align well with Python's import machinery. Since PEP 489 aimed to fix that, the assumption does not hold for modules that use multi-phase initialization, so ``PyState_FindModule`` is unavailable for these modules. A faster, safer way of accessing module-level state from extension methods is needed. Immutable Exception Types ------------------------- For isolated modules to work, any class whose methods touch module state must be a heap type, so that each instance of a module can have its own type object. With the changes proposed in this PEP, heap type instances will have access to module state without global registration. But, to create instances of heap types, one will need the module state in order to get the type object corresponding to the appropriate module. In short, heap types are "viral" – anything that “touches” them must itself be a heap type. Curently, most exception types, apart from the ones in ``builtins``, are heap types. This is likely simply because there is a convenient way to create them: ``PyErr_NewException``. Heap types generally have a mutable ``__dict__``. In most cases, this mutability is harmful. For example, exception types from the ``sqlite`` module are mutable and shared across subinterpreters. This allows "smuggling" values to other subinterpreters via attributes of ``sqlite3.Error``. Moreover, since raising exceptions is a common operation, and heap types will be "viral", ``PyErr_NewException`` will tend to "infect" the module with "heap type-ness" – at least if the module decides play well with subinterpreters/isolation. Many modules could go without module state entirely if the exception classes were immutable. To solve this problem, a new function for creating immutable exception types is proposed. Background =========== The implementation of a Python method may need access to one or more of the following pieces of information: * The instance it is called on (``self``) * The underlying function * The class the method was defined in * The corresponding module * The module state In Python code, the Python-level equivalents may be retrieved as:: import sys def meth(self): instance = self module_globals = globals() module_object = sys.modules[__name__] # (1) underlying_function = Foo.meth # (1) defining_class = Foo # (1) defining_class = __class__ # (2) .. note:: The defining class is not ``type(self)``, since ``type(self)`` might be a subclass of ``Foo``. The statements marked (1) implicitly rely on name-based lookup via the function's ``__globals__``: either the ``Foo`` attribute to access the defining class and Python function object, or ``__name__`` to find the module object in ``sys.modules``. In Python code, this is feasible, as ``__globals__`` is set appropriately when the function definition is executed, and even if the namespace has been manipulated to return a different object, at worst an exception will be raised. The ``__class__`` closure, (2), is a safer way to get the defining class, but it still relies on ``__closure__`` being set appropriately. By contrast, extension methods are typically implemented as normal C functions. This means that they only have access to their arguments and C level thread-local and process-global states. Traditionally, many extension modules have stored their shared state in C-level process globals, causing problems when: * running multiple initialize/finalize cycles in the same process * reloading modules (e.g. to test conditional imports) * loading extension modules in subinterpreters PEP 3121 attempted to resolve this by offering the ``PyState_FindModule`` API, but this still has significant problems when it comes to extension methods (rather than module level functions): * it is markedly slower than directly accessing C-level process-global state * there is still some inherent reliance on process global state that means it still doesn't reliably handle module reloading It's also the case that when looking up a C-level struct such as module state, supplying an unexpected object layout can crash the interpreter, so it's significantly more important to ensure that extension methods receive the kind of object they expect. Proposal ======== Currently, a bound extension method (``PyCFunction`` or ``PyCFunctionWithKeywords``) receives only ``self``, and (if applicable) the supplied positional and keyword arguments. While module-level extension functions already receive access to the defining module object via their ``self`` argument, methods of extension types don't have that luxury: they receive the bound instance via ``self``, and hence have no direct access to the defining class or the module level state. The additional module level context described above can be made available with two changes. Both additions are optional; extension authors need to opt in to start using them: * Add a pointer to the module to heap type objects. * Pass the defining class to the underlying C function. The defining class is readily available at the time built-in method object (``PyCFunctionObject``) is created, so it can be stored in a new struct that extends ``PyCFunctionObject``. The module state can then be retrieved from the module object via ``PyModule_GetState``. Note that this proposal implies that any type whose method needs to access per-module state must be a heap type, rather than a static type. This is necessary to support loading multiple module objects from a single extension: a static type, as a C-level global, has no information about which module it belongs to. Slot methods ------------ The above changes don't cover slot methods, such as ``tp_iter`` or ``nb_add``. The problem with slot methods is that their C API is fixed, so we can't simply add a new argument to pass in the defining class. Two possible solutions have been proposed to this problem: * Look up the class through walking the MRO. This is potentially expensive, but will be useful if performance is not a problem (such as when raising a module-level exception). * Storing a pointer to the defining class of each slot in a separate table, ``__typeslots__`` [#typeslots-mail]_. This is technically feasible and fast, but quite invasive. Due to the invasiveness of the latter approach, this PEP proposes adding an MRO walking helper for use in slot method implementations, deferring the more complex alternative as a potential future optimisation. Modules affected by this concern also have the option of using thread-local state or PEP 567 context variables, or else defining their own reload-friendly lookup caching scheme. Immutable Exception Types ------------------------- To faciliate creating static exception classes, a new function is proposed: ``PyErr_PrepareImmutableException``. It will work similarly to ``PyErr_NewExceptionWithDoc`` but will take a ``PyTypeObject **`` pointer, which points to a ``PyTypeObject *`` that is either ``NULL`` or an initialized ``PyTypeObject``. This pointer may be declared in process-global state. The function will then allocate the object and will keep in mind that already existing exception should not be overwritten. The extra indirection makes it possible to make ``PyErr_PrepareImmutableException`` part of the stable ABI by having the Python interpreter, rather than extension code, allocate the ``PyTypeObject``. Specification ============= Adding module references to heap types -------------------------------------- The ``PyHeapTypeObject`` struct will get a new member, ``PyObject *ht_module``, that can store a pointer to the module object for which the type was defined. It will be ``NULL`` by default, and should not be modified after the type object is created. A new factory method will be added for creating modules:: PyObject* PyType_FromModuleAndSpec(PyObject *module, PyType_Spec *spec, PyObject *bases) This acts the same as ``PyType_FromSpecWithBases``, and additionally sets ``ht_module`` to the provided module object. Additionally, an accessor, ``PyObject * PyType_GetModule(PyTypeObject *)`` will be provided. It will return the ``ht_module`` if a heap type with module pointer set is passed in, otherwise it will set a SystemError and return NULL. Usually, creating a class with ``ht_module`` set will create a reference cycle involving the class and the module. This is not a problem, as tearing down modules is not a performance-sensitive operation (and module-level functions typically also create reference cycles). The existing "set all module globals to None" code that breaks function cycles through ``f_globals`` will also break the new cycles through ``ht_module``. Passing the defining class to extension methods ----------------------------------------------- A new style of C-level functions will be added to the current selection of ``PyCFunction`` and ``PyCFunctionWithKeywords``:: PyObject *PyCMethod(PyObject *self, PyTypeObject *defining_class, PyObject *args, PyObject *kwargs) A new method object flag, ``METH_METHOD``, will be added to signal that the underlying C function is ``PyCMethod``. To hold the extra information, a new structure extending ``PyCFunctionObject`` will be added:: typedef struct { PyCFunctionObject func; PyTypeObject *mm_class; /* Passed as 'defining_class' arg to the C func */ } PyCMethodObject; To allow passing the defining class to the underlying C function, a change to private API is required, now ``_PyMethodDef_RawFastCallDict`` and ``_PyMethodDef_RawFastCallKeywords`` will receive ``PyTypeObject *cls`` as one of their arguments. A new macro ``PyCFunction_GET_CLASS(cls)`` will be added for easier access to mm_class. Method construction and calling code and will be updated to honor ``METH_METHOD``. Argument Clinic --------------- To support passing the defining class to methods using Argument Clinic, a new converter will be added to clinic.py: ``defining_class``. Each method may only have one argument using this converter, and it must appear after ``self``, or, if ``self`` is not used, as the first argument. The argument will be of type ``PyTypeObject *``. When used, Argument Clinic will select ``METH_METHOD`` as the calling convention. The argument will not appear in ``__text_signature__``. This will be compatible with ``__init__`` and ``__new__`` methods, where an MRO walker will be used to pass the defining class from clinic generated code to the user's function. Slot methods ------------ To allow access to per-module state from slot methods, an MRO walker will be implemented:: PyTypeObject *PyType_DefiningTypeFromSlotFunc(PyTypeObject *type, int slot, void *func) The walker will go through bases of heap-allocated ``type`` and search for class that defines ``func`` at its ``slot``. The ``func`` needs not to be inherited by ``type``, only requirement for the walker to find the defining class is that the defining class must be heap-allocated. On failure, exception is set and NULL is returned. Static exceptions ----------------- A new function will be added:: int PyErr_PrepareImmutableException(PyTypeObject **exc, const char *name, const char *doc, PyObject *base) Creates an immutable exception type which can be shared across multiple module objects. If the type already exists (determined by a process-global pointer, ``*exc``), skip the initialization and only ``INCREF`` it. If ``*exc`` is NULL, the function will allocate a new exception type and initialize it using given parameters the same way ``PyType_FromSpecAndBases`` would. The ``doc`` and ``base`` arguments may be ``NULL``, defaulting to a missing docstring and ``PyExc_Exception`` base class, respectively. The exception type's ``tp_flags`` will be set to values common to built-in exceptions and the ``Py_TPFLAGS_HEAP_IMMUTABLE`` flag (see below) will be set. On failure, ``PyErr_PrepareImmutableException`` will set an exception and return -1. If called with an initialized exception type (``*exc`` is non-NULL), the function will do nothing but incref ``*exc``. A new flag, ``Py_TPFLAGS_HEAP_IMMUTABLE``, will be added to prevent mutation of the type object. This makes it possible to share the object safely between multiple interpreters. This flag is checked in ``type_setattro`` and blocks setting of attributes when set, similar to built-in types. A new pointer, ``ht_moduleptr``, will be added to heap types to store ``exc``. On deinitialization of the exception type, ``*exc`` will be set to ``NULL``. This makes it safe for ``PyErr_PrepareImmutableException`` to check if the exception was already initialized. PyType_offsets -------------- Some extension types are using instances with ``__dict__`` or ``__weakref__`` allocated. Currently, there is no way of passing offsets of these through ``PyType_Spec``. To allow this, a new structure and a spec slot are proposed. A new structure, ``PyType_offsets``, will have two members containing the offsets of ``__dict__`` and ``__weakref__``:: typedef struct { Py_ssize_t dict; Py_ssize_t weaklist; } PyType_offsets; The new slot, ``Py_offsets``, will be used to pass a ``PyType_offsets *`` structure containing the mentioned data. Helpers ------- Getting to per-module state from a heap type is a very common task. To make this easier, a helper will be added:: void *PyType_GetModuleState(PyObject *type) This function takes a heap type and on success, it returns pointer to state of the module that the heap type belongs to. On failure, two scenarios may occure. When a type without a module is passed in, ``SystemError`` is set and ``NULL`` returned. If the module is found, pointer to the state, which may be ``NULL``, is returned without setting any exception. Modules Converted in the Initial Implementation ----------------------------------------------- To validate the approach, several modules will be modified during the initial implementation: The ``zipimport``, ``_io``, ``_elementtree``, and ``_csv`` modules will be ported to PEP 489 multiphase initialization. Summary of API Changes and Additions ==================================== New functions: * PyType_GetModule * PyType_DefiningTypeFromSlotFunc * PyType_GetModuleState * PyErr_PrepareImmutableException New macros: * PyCFunction_GET_CLASS New types: * PyCMethodObject New structures: * PyType_offsets Modified functions: * _PyMethodDef_RawFastCallDict now receives ``PyTypeObject *cls``. * _PyMethodDef_RawFastCallKeywords now receives ``PyTypeObject *cls``. Modified structures: * _heaptypeobject - added ht_module and ht_moduleptr Other changes: * METH_METHOD call flag * defining_class converter in clinic * Py_TPFLAGS_HEAP_IMMUTABLE flag * Py_offsets type spec slot Backwards Compatibility ======================= Two new pointers are added to all heap types. All other changes are adding new functions, structures and a type flag. The new ``PyErr_PrepareImmutableException`` function changes encourages modules to switch from using heap type Exception classes to immutable ones, and a number of modules will be switched in the initial implementation. This change will prevent adding class attributes to such types. For example, the following will raise AttributeError:: sqlite.OperationalError.foo = None Instances and subclasses of such exceptions will not be affected. Implementation ============== An initial implementation is available in a Github repository [#gh-repo]_; a patchset is at [#gh-patch]_. Possible Future Extensions ========================== Easy creation of types with module references --------------------------------------------- It would be possible to add a PEP 489 execution slot type to make creating heap types significantly easier than calling ``PyType_FromModuleAndSpec``. This is left to a future PEP. Optimization ------------ CPython optimizes calls to methods that have restricted signatures, such as not allowing keyword arguments. As proposed here, methods defined with the ``METH_METHOD`` flag do not support these optimizations. Optimized calls still have the option of accessing per-module state the same way slot methods do. References ========== .. [#typeslots-mail] [Import-SIG] On singleton modules, heap types, and subinterpreters (https://mail.python.org/pipermail/import-sig/2015-July/001035.html) .. [#gh-repo] https://github.com/Traceur759/cpython/commits/pep-c .. [#gh-patch] https://github.com/Traceur759/cpython/compare/master...Traceur759:pep-c.pat… Copyright ========= This document has been placed in the public domain.

3 2

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods
by Jeroen Demeyer 26 Apr '18

26 Apr '18

On 2018-04-26 16:37, Nick Coghlan wrote: > PEP 487 refers to this as the "owner" of a descriptor That's just copied from the Python docs: https://docs.python.org/3.8/reference/datamodel.html#object.__get__ Anyway, I never liked the name "owner" there, "cls" would have been much clearer. For PEP 575, I thought of "owner" too, but I don't like it because it sounds too possessive. It sounds like the "owner" somehow has complete control over the function and I don't want that association.

1 0

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods
by Jeroen Demeyer 26 Apr '18

26 Apr '18

On 2018-04-25 20:33, Petr Viktorin wrote: > Perhaps "m_objclass" could point to the module in this case That was exactly my idea also today. Instead of treating m_objclass as the defining class, we should generalize it to be the "parent" of the function: either the class or the module.

3 2

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods
by Jeroen Demeyer 26 Apr '18

26 Apr '18

> - In Python code, __objclass__ should be the defining class, not the module. Indeed. My idea would be to add an accessor __parent__ returning the m_parent field (whatever it is) and then implement __objclass__ as something like: @property def __objclass__(self): parent = getattr(self, "__parent__", None) if isinstance(parent, type): return parent else: raise AttributeError In PEP 575, I don't plan to add a Python attribute specifically for getting the defining module: I'll leave that to PEP 573.

1 0

Visual similarity of "=" and "==" (in context of PEP 572)
by Mikhail V 25 Apr '18

25 Apr '18

Since the discussion about operator choice has completely migrated here, I'll put my note also here. >From the very beginning of PEP 572 discussion I have noticed a strange fact - there is told a lot about visual similarity of "=" and "==" in Python. *Same is told in the PEP 572 (frequently asked question) as the reason for rejection of "=" as operator.* I realize that currently there are other technical arguments against "=", but I am the opinion that this very reason, namely similarity of "=" and "==", cannot be taken seriously. I'll try to explain: I have opened Notepad++ and went to syntax highlighting configurator. It took me 2 minutes to choose a syntax setup that defines "==" (and other comparison operators if you wish) as a token with custom style. Now I can apply *custom color and size* to it and this alone makes the operator very well seen and different from "=". If that is not enough, I can set different *font* for the operator: so I can basically turn "==" into anything I want. With this in mind, I personally can't understand why you complain about "=="? Ok, you could say - not all editors can do this. But even without that tweaks - I still don't find the problem worth exaggeration. It is not like I accidentally choose very similar names for variables and then spend an hour trying to figure out where is the bug comes from. With "==" it just takes some attention to look at -if- statements and recheck if I write "==" and not "=" where I need comparison. I see it as as a "typo-magnet" but no way as a "bug-magnet" as it was claimed repeatedly in the discussion. A programmer already knows about this similarity and can fix the typos easily. The ":=" operator is of course slightly more different, but still, only _slightly_ better in this regard. With that said, I am not much interested in either adding of the expression assignment, although I am really worrying about the reasoning made about "=" and "==" in the discussion. Hope you get my point here. IMO either the PEP 572 should remove or at least rephrase this point somehow or, even better, concentrate on something more convincing in this regard. Also I think Yury has made good point about the introduction of ":=" -- it would co-exist with the "=". So imo, if you get familiar with ":=", later on it will just cause additional visual noise. And I don't think a regular user will be much interested in nuances of internal implementation of new assignment - they'll just follow the logic of the code and another operator will constantly gain unnecessary attention at reading. Mikhail

2 1

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods
by Jeroen Demeyer 25 Apr '18

25 Apr '18

On 2018-04-24 14:53, Nick Coghlan wrote: >> In PEP 575, I'm already proposing a flag (METH_ARG0_FUNCTION) to pass the >> function *instead* of self. Unless PEP 573 is rejected, maybe that should >> change to passing the function *in addition* to self. > > That would definitely be an elegant way of addressing both use cases. On the other hand, if you are passing the function object, then you can get __self__ from it (unless it's an unbound method: in that case __self__ is NULL and self is really args[0]). So there wouldn't be a need for passing "self". I'm not saying that this is better than passing "self" explicitly... I haven't yet decided what is best. In any case, these things would be handled by Argument Clinic anyway, so it only matters if you are parsing arguments "by hand". Jeroen.

3 3

assignment expressions: an alternative proposal
by Yury Selivanov 25 Apr '18

25 Apr '18

I propose to use the following syntax for assignment expressions: ( NAME = expr ) I know that it was proposed before and this idea was rejected, because accidentally using '=' in place of '==' is a pain point in C/C++/JavaScript. That said, I believe we can still use this syntax as long as we impose the following three restrictions on it: 1. Only NAME token is allowed as a single target. 2. Parenthesis are required. 3. Most importantly: it is *not* allowed to mask names in the current local scope. Let's see how each restriction affects the syntax in detail: (1) NAME tokens only: if (a[1] = value) # SyntaxError if (a.attr = value) # SyntaxError (2) Required parens disambiguate the new syntax from keyword-arguments and prevent using '=' in place of '==': if a = value # SyntaxError if expr and a = value # SyntaxError (3) No masking of existing names in local scope makes using '=' in place of '==' by mistake even less probable: flag = get_flag() ... if (flag = 'win') # SyntaxError # or def foo(value): if (value = 1) # SyntaxError # or py> (c = 1) and (c = 2) # SyntaxError # etc The following code snippets are perfectly valid though: py> a = (b = (c = 3)) py> a, b, c (3, 3, 3) # and py> f = lambda x: x * 10 py> [[(y = f(x)), x/y] for x in range(1,5)] [[10, 0.1], [20, 0.1], [30, 0.1], [40, 0.1]] # and def read(): while (command = input("> ")) != "quit": print('you entered', command) # and py> if (match = re.search(r'wor\w+', 'hello world')): py. print(match) <re.Match object; span=(6, 11), match='world'> # and if (diff = x - x_base) and (g = gcd(diff, n)) > 1: return g Enabling '=' for assignment expressions introduces a limited form of the more general assignment statement. It is designed to be useful in expressions and is deliberately simple to make it hard for users to shoot in the foot. The required Python grammar changes are simple and unambiguous. Although it is still possible to accidentally mask a global name or a name from an outer scope, the risk of that is significantly lower than masking a local name. IDEs and linters can improve the usability further by highlighting invalid or suspicious assignment expressions. I believe that this syntax is the best of both worlds: it allows to write succinct code just like PEP 572, but without introducing a new ':=' operator. An implementation of this proposal is available here: https://github.com/1st1/cpython/tree/assign. If this idea is deemed viable I will write a PEP detailing the grammar/compiler changes and syntax restrictions. Thanks, Yury

16 58

Meta-question about this mailing list
by Stéfane Fermigier 25 Apr '18

25 Apr '18

Hi, the description on https://mail.python.org/mailman/listinfo/python-dev reads: "On this list the key Python developers discuss the future of the language and its implementation." I interpret this sentence as "only key (core?) developers are supposed to participate in the discussion (ie. post messages), the rest is welcome to lurk." Is this the intended meaning ? There is an additional description in the devguide: "python-dev is the primary mailing list for discussions about Python’s development. The list is open to the public and is subscribed to by all core developers plus many people simply interested in following Python’s development. Discussion is focused on issues related to Python’s development, such as how to handle a specific issue, a PEP, etc." I would interpret it as "it's OK for non core developers to post", except for the "many people simply interested in following Python’s development" part which hints that we are welcome to "follow" but not actively participate. So in either case (and both descriptions) it would IMHO be useful to use clearer language. Another point: later in the Mailman description, one reads: "Consider using Gmane." (with a link to http://dir.gmane.org/gmane.comp.python.devel ). I went to Gmane and found all the links broken. I remember there was some turmoil at Gmane a couple of years back: https://en.wikipedia.org/wiki/Gmane#References => It seems the migration didn't work that well and the service shouldn't been relied upon. Regards, S. -- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, Free&OSS Group @ Systematic Cluster - http://www.gt-logiciel-libre.org/ Co-Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/

1 0