Mailman 3 September 2016 - Python-ideas

(Windows-only - calling Steve Dower) Is Python for Windows using PGO? If not consider this a suggestion.
by João Matos 18 Sep '16

18 Sep '16

Hello, Is Python for Windows using PGO (Profile Guided Optimizations)? If not consider this a suggestion. Best regards, JM

2 2

(Windows-only - calling Steve Dower) Consider adding a symlink to pip in the same location as the py launcher
by João Matos 18 Sep '16

18 Sep '16

Hello, If Py3.5 is installed in user mode instead of admin (all users) and we follow your advice that we shouldn't add it to the PATH env var, we can execute Python using the py launcher, but we can't use pip. Please consider adding a pip symlink in the same location as the py launcher. Best regards, JM

3 4

typing.modifiers
by אלעזר 17 Sep '16

17 Sep '16

With the new variable annotation syntax, it is possible to implement a useful "modifiers" library, all used as superclasses. Possible modifiers: * Named / Struct: annotation-defined fields. No monkey patching. * Immutable / Const * Sealed / Final: unsubclassable class * Array: a mutable tuple. (No "+" or "*" operators) There of course may be others. Subclasses of the modifiers get default methods and behavior. The modifiers can used in combinations. For example: class Command(Immutable, Named): cmd : str = "NOP" value : int = None load = Command(cmd="load", value=1000) # no positional arguments The syntax for Array is less pretty: class Command(Array): _0 : str = "NOP" _1 : int = None load = Command("load", 1000) # no positional arguments Many other combinations are useful too. "Sealed" is almost orthogonal to the others, Obviously, some combinations already exists: * (Immutable, Array) is similar to Tuple * NamedTuple is another name for (Immutable, Named, Array). * Enum should be on this list too Some less promising modifiers: * Namespace / Static: uninstantiable class. A module. * Volatile, for externally facing classes. Hints the static checkers / jitters that they should not assume they know the values. * Abstract Alternatives and cons : I suggest base classes instead of decorators since NamedTuple and tuple go this way, and since it is static information. I am not sure which is better though. Metaclass parameters can be used (and actually used in my implementation, and in NamedTuple's), but the syntax is uglier. "array" is only for numeric values in Python, so this name is problematic.So is struct. I have a rough implementation for most of the above; much of it is not hard in general, though some details are hard to get right. --- Benefits of putting such a collection in stdlib (instead of as an external package) include: 1. This information can be used by typecheckers, and also by users, to reason about programs. If isinstance(x, ImmutableArray), then x is an instantiation of ImmutableArray. 2. A conventional syntax and a single answer for "How do I make my class immutable", "How do I make my class unsubclassable" 3. The syntax, especially for Struct as above, is pretty and clean. The Array syntax is less so. 4. I think that the array implementation can use internal CPython details to be implemented efficiently. I am not sure that typing.modifiers is the right place, since these are not exactly type hints; they generate methods, and are intended to be enforced at runtime. I think that even if this idea is not accepted, the general theme is something that might be useful to keep in mind, stdlib might accumulate such modifiers, and it will be nice to keep things uniform. Opinions? ~Elazar

5 9

Adding bytes.frombuffer() constructor
by INADA Naoki 16 Sep '16

16 Sep '16

bytearray is used as read / write buffer in asyncio. When implementing reading stream, read() API may be defined as returns "bytes". To get front n bytes from bytearray, there are two ways. 1. bytes(bytearray[:n]) 2. bytes(memoryview(bytearray)[:n]) (1) is simplest, but it produces temporary bytearray having n bytes. While (2) is more efficient than (1), it uses still temporary memoryview object, and it looks bit tricky. I want simple, readable, and temporary-less way to get part of bytearray as bytes. The API I propose looks like this: bytes.frombuffer(byteslike, length=-1, offset=0) How do you feel about it? -- INADA Naoki <songofacandy(a)gmail.com>

3 4

Naming convention for Enums
by Bar Harel 15 Sep '16

15 Sep '16

Hey guys, This is something that has been discussed before several times, whether in Python mailing list and whether in stackoverflow, each providing different answers. I believe that we should add a naming convention in pep8 to solve this issue. Enums in Python are a unique creature - it's a class, the members aren't injected into module level, it can have methods, but it's attributes are somewhat consts (although they can be modified via __new__). The fact that currently every person names them differently defies the whole purpose of a convention document. Although I'm in favor of lower-case instead of upper-case, I believe that we need to make a decision as no decision is somewhat worse and causes a lot of confusion. I'm not entirely sure how pep-8 was built (was it a poll? was it a BDFL announcement? was it discovered in a fortune cookie just like pep 285?), regardless how it built I believe we should make that addition for a clearer future :-) Any thoughts?

6 11

Generics Syntax
by אלעזר 15 Sep '16

15 Sep '16

This suggestion is so obvious that it's likely has been discussed, but I can't find any reference (It's not what PEP-3124 talks about). Generic class syntax, now: _T_co = TypeVar('_T', covariant=True) class Container(Generic[_T_co]): @abstractmethod def __contains__(self, x: _T_co) -> bool: ... (yes it's object in reality) Generic class syntax, suggested: class Container[+T]: @abstractmethod def __contains__(self, x: T) -> bool: ... The + signifies covariant type, as in Scala. The need for underscore prefix and explicit name for covariant types is gone, since it's class-scoped. The + is a bit cryptic, but so are term "covariant" and Generic[_T_co]. The syntax by large is exactly what users coming from statically-typed languages will expect. Giving a bound can be done using "T <: AnyStr", "T: AnyStr" or any other syntax. Again, I assume it was discussed before, but my Google skills are failing me; a pointer will be helpful. ~Elazar

3 7

New Python syntax for continuing definitions for existing classes
by Pim Schellart 14 Sep '16

14 Sep '16

Dear Python Developers, we have a potential idea for enhancing Python. Below you will find what the PEP might look like. A reference implementation has been written and will be posted in a follow up message. We are look forward to hearing your feedback and ideas. Kind regards, Pim Schellart & Nate Lust Abstract ======== This PEP proposes the introduction of new syntax to create a community standard, readable way to continue a definition for classes which are already defined. Rationale ========= Extending existing classes with new members currently requires the members to be defined outside of class scope and then assigned to the class, as in:: def foo(self): pass A.foo = foo del foo This pattern frequently occurs when extending classes from extension modules written in other languages, but is also not uncommon in pure Python code. This syntax is however cumbersome and error prone for the following reasons: 1. The name of the new member might clash with an existing name at module scope. 2. The developer might forget the assignment. 3. The developer might forget to delete the temporary, leaving it at module scope where it is meaningless (or worse non functional as a stand alone function). Alternatives are to use inheritance, lambda or a decorator. Inheritance is not a good option for use with Python extension modules (written in for instance C / C++). The reason is that if in the other language the inheritance relation is A<-B, and this is exposed to Python, we can't add functionality to A in Python by subclassing A<-A' without also introducing B' that inherits from B and A'. Thus one change propagates all the way down the inheritance chain. Inheritance with pure Python classes exhibit the same issue. It might be tempting to avoid (1) and (2) by subclassing, reusing the name of the base class. However this approach suffers from two issues. The first issue, like above, has to do with the inheritance relation. If A subclasses A and B subclasses A (A<-A<-B), then calls to super in B may have unexpected behavior (anything using the method resolution order may exhibit the same unexpectedness). The second issue arises when class B inherits from class A before it is extended (A<-B) and then class A is extended though inheritance (A<-A). Class A will now have new methods and data members which are not present in B, as it is a subclass only of the original A. This would be confusing to anyone examining B as it would be apparently missing members of it's parent. Adding attributes to a class using lambda is not equivalent because it only allows for expressions and not statements. A class decorator (say "@continue_class(A)" that takes methods and attributes from the class and attaches them to the wrapped type) works, but is cumbersome and requires a new class name to be introduced for each extended type. Thus suffering from the same problems numbered (1) and (2) above. A function decorator could extend a class, but also requires defining a new name and suffers from problems (1) and (2). This proposal adds the keyword combination "continue class" which instructs the interpreter to add members to an existing class. This syntax requires no new keywords and allows all existing Python code to continue to function with no modification. By combining existing keywords it avoids name clashes. Precedents for this exists in "is not" and "yield from". Another big advantage of the "continue class" syntax is discoverability. For humans, the meaning of the syntax is evident, the class will be continued with the following block. Automated tools will also benefit from this syntax as parsing a file to discover the complete definition of a class will be easier than trying to detect 'monkey patching'. Semantics ========= The following two snippets are semantically identical:: continue class A: x = 5 def foo(self): pass def bar(self): pass def foo(self): pass def bar(self): pass A.x = 5 A.foo = foo A.bar = bar del foo del bar Alternatives ============ An alternative could be to allow a function definition to include a class specifier as in:: def A.foo(self): pass Implementation ============== Adapting Python's grammar to support the continue class keyword combination requires modifying the grammar file to parse for the new keyword combination. Additional changes to Python.asdl, ast.c, compile.c, symtable.c will be required to process the parsed syntax to byte code. A reference implementation (already written and posted separately) parses the continue class line for the name of the class to be modified and loads it. Next the body of the block is compiled into a code object scoped by the name of the class. The class and the code are used as arguments to a new built-in module, called __continue_class__. This function evaluates the code block, passing the results to setattr on the supplied class.

10 15

An exciting opportunity to update PEP 3156
by Yury Selivanov 13 Sep '16

13 Sep '16

Guido and I are looking for help with PEP 3156. Currently it's out of sync with the docs. It would be cool if someone could volunteer and update it (at least make sure that all APIs are up to date). Yury

6 6

Fwd: Null coalescing operator
by David Mertz 13 Sep '16

13 Sep '16

Sorry, I sent this accidentally as private reply, then tried to fix it on phone. The latter produced horrible formatting. Please just read this version. On Sat, Sep 10, 2016 at 4:10 PM, Guido van Rossum <guido(a)python.org> wrote: > So you're offering `NoneCoalesce(x).bar` as less-ugly alternative to > `x?.bar`... Color me unconvinced. > No, I'm offering a more realistic use pattern: for x in get_stuff(): x = NoneCoalesce(x) # ... bunch of stuff with x ... # ... more stuff with nested keys or attributes ... x2 = x.foo x3 = x.bar.baz[x2] x4 = x(x.val) result = x3(x4) As a less ugly alternative in the fairly uncommon case that you want None coalescing as the behavior of getting attributes, keys, call values, etc. that may or may not be available (AND where you don't want to wrap all of those access patterns in one try/except block). In contrast, the ugly version of even this pretty simple toy code with the hypothetical syntax would be: for x in get_stuff(): # ... bunch of stuff with x ... # ... more stuff with nested keys or attributes ... x2 = x?.foo x3 = x?.bar?.baz?[x2] x4 = x?(x?.val) result = x3?(x4) This second case looks absolutely awful to me. And real world uses, if implemented, would quickly get much worse than that. Yours, David... -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

15 45

Re: [Python-ideas] Changing optimisation level from a script
by Damien George 13 Sep '16

13 Sep '16

Thanks all for the input on this topic. Let me summarise what was said. There was discussion that the ability to change the "optimize" value is not enough and there should be more fine grained control over other flags/settings. Perhaps that is true, but at least for our case in MicroPython there's only one (runtime) optimisation variable and it mimics CPython's -O command line option (affecting __debug__, assert compilation, and whether line numbers are included in the bytecode). Suggestions for setting the opt level were: 1) sys.set_default_optimize(level), with the existing sys.flags.optimize attribute as the accessor. 2) sys.opt_level, being a read/write attribute 3) sys._setflag(name, value) as implemented by eGenix PyRun I think option 1 is the most consistent with the existing sys module, although the name is rather long and I think sys.set_optimize(level) would be better (after all, none of the other sys.set functions have the word default in them). As a second preference I like micropython.opt_level([value]), which can set and get the value, and keeps it specific to uPy. Cheers, Damien.

2 1