Mailman 3 May 2018 - Python-ideas

Re: [Python-ideas] Keyword for direct pass through of kwargs to super
by Jacco van Dorp 28 May '18

28 May '18

2018-05-28 11:07 GMT+02:00 Michael Lohmann <mial.lohmann(a)gmail.com>: > But maybe it is just me who thinks that you should make it as obvious as possible what a class itself really can get as an input and what is done just to get the multiple inheritance to work... So I think if no one else agrees with me, we don’t need to further spam everybody. I think the largest difference is that most people have a different opinion about what is more explicit/obvious. It does look like you could build something like this for yourself with a decorator: from inspect import signature, Parameter def forwards_kwargs_to_super(classname): def deco(method): sig = signature(method) numargs = len([param for param in sig.parameters.values() if param.kind is Parameter.POSITIONAL_ONLY]) keykwargs = {param.name for param in sig.parameters.values() if param.kind in (Parameter.POSITIONAL_OR_KEYWORD, Parameter.KEYWORD_ONLY)} def newinit(self, *args, **kwargs): print(f"Call looks like: {classname}: {args[:numargs]}, { {key: val for key, val in kwargs.items() if key in keykwargs} }") method(self, *args[:numargs], **{key: val for key, val in kwargs.items() if key in keykwargs}) super(globals()[classname], self).__init__(*args[numargs:], **{key: val for key, val in kwargs.items() if key not in keykwargs}) return newinit return deco And then use it like this: class Aardvark: @forwards_kwargs_to_super("Aardvark") def __init__(self, quantity): print("There is some quantity:", quantity) # I actually don’t care about **kwargs and just hand them on class Clever: @forwards_kwargs_to_super("Clever") def __init__(self, cleverness=1): print("You are %d clever" % cleverness) class Ethel(Aardvark, Clever): """Ethel is a very clever Aardvark""" @forwards_kwargs_to_super("Ethel") def __init__(self): pass e = Ethel(quantity="some spam", cleverness=100) Disclaimer: - Whenever you import the inspect module, you should ask yourself whether it's really a good idea. - I'm assuming that decorated functions have no *args or **kwargs in their signature that you DO want to accept, and that all arguments with a default value are given as keyword arguments. - If you are passing new positional arguments with this function, the subclass positional arguments need to come before the superclass positional arguments (only important if both have positional arguments.) - If you use multiple decorators, this should be the innermost decorator, or it'll probably make your code barf at runtime. - If you try do this in my company, i'll do whatever I can to get you fired. For the love of Python, don't use this code at places where anybody except you has to do maintenance. And if you come back in half a year and are amazed by your own code, I promise you'll understand why this might not be a real good solution. - Yes, passing your class name and then getting it from globals is an ugly hack. The alternative is grabbing it from the stack. If anybody else has a better idea, feel free, but AFAIK it's impossible to do this better. (I once wrote an overload decorator as a personal exercise, using the stack hack.) - I haven't tested this with actual positional arguments, but I -think- it will work.

1 1

ternary without else
by Jacco van Dorp 28 May '18

28 May '18

I would like to carefully suggest a half form of the ternary expression. Currently, you can write code like: >>> if cond: >>> do_something However, especially if the condition and action are both really simple, taking two lines feels like a bit of a waste. So I sometimes write: >>> if cond: do_something However, this isn't PEP8 compliant, and every linter complains about it. They'd be right if the condition and action were a bit more complicated. I would very much like to write: >>> do_something if cond and be done with it. Like a ternary expression but without the else clause. I know this is probably not gonna make it due to "not strong enough pro's, just swallow the linters complaints and roll with the 'if cond: do_something' if you care so much about that 1 line", but I still wanted to make my case. ===Example Usecases=== (inside loop) >>> continue if x > 50 (logging) >>> logger.info(f"{var}") if DEBUG (Logging module ofc already does this, and in a much better way. However, if var is expensive to get it could save a bit of time.) (singleton creation) >>> cls.inst = super().__new__(cls, *args, **kwargs) if cls.inst is None (cache) >>> cache.warm() if cache is None

9 12

"Assignment expression" with function call-alike syntax
by Kirill Balunov 28 May '18

28 May '18

Just one more variation on "assignment exression" syntax to make the list more complete :) Sorry, if something similar has already been suggested. The idea is to use function's call-like syntax in the from: `this( name = expr )`. I'm not sure that such idea will find its supporters and whether it is possible to implement it in a general way, but nevertheless. Below is a half- and slow-working prototype and some silly examples just for the sake of feeling the idea: import sys import ctypes def this(**assign): assert len(assign) == 1 [(name, value)] = assign.items() frame = sys._getframe(1) frame.f_locals[name] = value ctypes.pythonapi.PyFrame_LocalsToFast(ctypes.py_object(frame), ctypes.c_int(0)) return value Loop-and-a-half example with `dummy` function[1]: # in global scope everything works ok since locals is globals >>> while len( this( val = dummy() ) ) >= 0: ... print(val) [0, 1] [0, 1, 2] [0, 1, 2, 3] ... # needs to set the same local name to work inside function def func(): val = ... while len( this( val = dummy() ) ) >= 0: print(val) >>> # relies on the implicit underlying function's local `x` >>> [[this(x = (x+10)), x//10, x*10] for x in [100, 200, 300]] [[110, 11, 1100], [210, 21, 2100], [310, 31, 3100]] In this way it is somewhat possible to make an assignment in `while` and `if ` headers right now, which covers 90% cases, but it is damn slow. Maybe be it is worth to make `this` magic call-alike object work fast...on the other hand does anyone like `this`? With kind regards, -gdg [1]: def dummy(ls = [0]): ls.append(ls[-1]+1) return ls

7 11

Keyword for direct pass through of kwargs to super
by Michael Lohmann 25 May '18

25 May '18

Hi! ***Disclaimer: I am relatively new to Python*** I propose to add some mechanism that can automatically collect everything what would normally be collected by **kwargs in the __init__ method and directly pass it through to the super().__init__ call without being accessible in the __init__ itself. This way the autocompletion/docstring generation could safely ignore this argument which before would have showed up as **kwargs. I believe that this could greatly enhance the readability of automated documentation and especially the autocomplete of an IDE. I would like something like this to work: class A: @pass_through_kwargs # like this? Or maybe __init__(self, a_value, ***pass_through_kwargs)? def __init__(self, a_value): super().__init__() # <- realize that nothing is passed in here class B: def __init__(self, some_value): pass class MyClass(A, B): def __init__(self): super().__init__(a_value=1, some_value=2) Where the autocomplete of `A(` shows me just `A(a_value)`. The pass_through_kwargs can safely be ignored, since it is not "a real input" of A. It is automatically merged with the parameters of the `super(A, self).__init__()` call. How exactly this should be done would have to be discussed in more detail (I guess the actual values should probably override the passed through ones). With the current python version the code would have looked like class A: def __init__(self, a_value, **kwargs): super().__init__(**kwargs) But the user could have had the false impression that additional kwargs could be given when instantiating A. Obviously they are purely there for getting the init in the MRO working with multiple inheritance. One could also add something like pass_through_args as well but the usability of that is probably much more limited. Could this even work in theory? I guess it might be quite tricky since `super().__init__` doesn't even have to be called. If that would be the case: should it be called automatically if pass_through_kwargs were given after the init is done? By the way: Thank you all for this amazing language! Cheers, Michael

3 2

Reuse "for" to express "given"
by Alexander Belopolsky 25 May '18

25 May '18

I have read most of the PEP 572 related threads, but I don't think I've seen this idea. As many other people mentioned, Python already allows a trick to introduce local bindings in generator expressions and list comprehensions. This can be achieved by adding a "for var in [<expr>]" clause. I propose to make "for var = <expr>" have the same effect as "for var in [<expr>]". Note that in the case of filters, the order will be different from that in the original "given" proposal: instead of [(x, y, x/y) for x in data if y given y = f(x)] we will write [(x, y, x/y) for x in data for y = f(x) if y] The use of "for" in place of "given" in the if statements does not look too bad: if m for m = pattern.search(data): ... elif m for m = other_pattern.search(data)): ... else: ... I have to admit that while m for m = pattern.search(remaining_data): ... looks strange at first because both while and for are strongly associated with loops, but if you read "for var = <expr>" as "for var equals expression", the difference between that and "for var in (iterable) expression" becomes apparent.

7 11

Thoughts on "extended mapping unpacking"
by Neil Girdhar 24 May '18

24 May '18

I was previously constructing an object like this: tb = TemporalBehavior(**kwargs, **parameters) where various subclasses were doing things like def __init__(self, some_kwarg, some_other_kwargs, some_parameter, some_other_parameter): Then I realized that I want to pass the paramters as a dictionary so that I can store it. I changed the code to this: def __init__(self, some_kwarg, some_other_kwargs, parameters): but I still need "some_parameter", so I did some_parmeter = parameters['some_parameter'] some_other_parmeter = parameters['some_other_parameter'] Great, but now I have to check that exactly the list of parameters that I need is being sent in, so I need to do something like if set(parameters) != ('some_parameter', 'some_other_parameter'): raise ValueError It might be nice to do instead {'some_parameter': p, 'some_other_parameter': q} = parameters I'm just throwing this suggestion out there. I realize that this is pretty niche, but who knows where Python will be in ten years. I also know that this is possible (and fairly easy) to implement from when I worked on PEP 448. This is similar to unpacking iterables like this: a, b = range(2) a, b, *c = range(5) It's the mapping version of it: {'a': a, 'b': b} = some_dict {'a': a, 'b': b, **c} = some_dict Best, Neil

4 5

Meta-PEP about built-in functions
by Jeroen Demeyer 23 May '18

23 May '18

Hello, Both PEP 573 and PEP 575 deal with built-in functions. Additionally, some people (Stefan Behnel, Robert Bradshaw, Jim Pivarski and me) are currently brainstorming about a yet-to-be-written PEP to allow calling the underlying C function of a built-in function using native types (for example, a C long instead of a Python int). Think of it as analogous to the buffer protocol: the buffer protocol exposes C *data* while this would expose C *callables*. Since all these PEPs would overlap somewhat, I'm starting to wonder about the best way to organize this. Ideally, I would like some kind of "meta-PEP" where we discuss the future of built-in functions in general terms without too much details. This would be followed by several PEPs each going in detail about one specific aspect. Is there a precedent for this? What do the seasoned Python developers think? Jeroen.

3 2

Make asyncio.get_event_loop a builtin
by Ken Hilton 22 May '18

22 May '18

Hi all, Just a simple idea I wanted to bring forth. Although I know that you get a lot more asyncio control by importing the asyncio module itself, I'd like to see a way to make simple asynchronous applications without ever importing asyncio itself. To that end, I propose making asyncio.get_event_loop() a builtin. This would enable simple things like this (example copied from websockets.readthedocs.io with slight modifications): import websockets async def hello(): async with websockets.connect('wss://echo.websocket.org') as ws: amsg = 'a message' print(f'> {amsg}') await ws.send(amsg) ret = await ws.recv() print(f'< {ret}') get_event_loop().run_until_complete(hello()) See how that never imported asyncio? I just think it would be more convenient this way. But there may be major problems that I hadn't anticipated, so as always: Thoughts? Sincerely, Ken H ilton ;

4 3

Modern language design survey for "assign and compare" statements
by Mike Miller 22 May '18

22 May '18

Background: While the previous discussions about assignment-expressions (PEP 572) (abbreviated AE below) have been raging one thing that was noticeable is that folks have been looking back to C for a solution. But how are newer languages solving the problem today? Believe Ryan brought this up first on the list, but it had been in the back of my mind as well. Finally have compiled my research, corrections welcome. In alphabetical order: Dart, 2011: Design goal: Less confusing, conservative replacement for JavaScript. - Assignment is a statement, not an expression. - JS allows AE to used freely, Dart doesn't support them. - Only option is to write simple, mildly redundant code. Details: https://www.dartlang.org/guides/language/language-tour#assignment-operators https://github.com/dart-lang/sdk/issues/55 Golang, 2009: Design goal: Simple, maintainable replacement for C++/Java/C#. - Assignment is a statement, not an expression. - Precursors allowed AE to be used freely - Golang doesn't them but allows assignment inside the if statement: if x := f(); x < y { … } - No assignment in while (spelled for) currently allowed. Use mildly redundant code in other locations. Details: https://stackoverflow.com/questions/13127929/assign-and-compare-in-gos-whil… https://clipperhouse.com/statements-are-statements-and-expressions-are-expr… Kotlin, 2011: Design goal: Terse, modern replacement for Java with high interop. - Assignment is a statement, not an expression. - Java allows AE to used freely, Kotlin doesn't support them. - Main option is to write simple, mildly redundant code. (Or use std lib functionality such as forEachLine, etc.) Details: https://blog.kotlin-academy.com/kotlin-programmer-dictionary-statement-vs-e… https://discuss.kotlinlang.org/t/assignment-not-allow-in-while-expression/3… https://stackoverflow.com/questions/41537638/assignment-not-allowed-in-whil… Rust, 2010: Design goal: Safe replacement for C/C++, etc. - Assignment is a statement, not an expression. - C/C++ allow AE - Rust doesn't, but allows an assignment clause in if/while. if let Some(3) = some_u8_value { … } while let Some(byte) = input.next() { … } Details: https://doc.rust-lang.org/book/second-edition/ch06-03-if-let.html https://doc.rust-lang.org/stable/rust-by-example/flow_control/while_let.html Swift, 2014: Design goal: Modern replacement for ObjectiveC with high interop. - Assignment returns Void - ObjC allows AE - Swift doesn't, but allows an assignment clause in if/while statements: if let NAME = … { … } if var NAME = … { … } while let line = aStreamReader.nextLine() { … } Details: https://stackoverflow.com/questions/34173084/what-was-the-reason-for-swift-… https://developer.apple.com/library/content/documentation/Swift/Conceptual/… Conclusions ------------ It appears assignment expressions are no longer the favored solution for the "assign and compare" use case. Not one of these five newer languages supports them fully, as the language generations from C to C# did. Of those that have recognized the use case to be large enough—the solution has been rather more limited to the "if" and "while" statements only. Several folks here have expressed the same desire to confine AE there. Since Python's design goals are similar—to be safe and maintainable I'd recommend a similar strategy, with the addition of the list comprehension case. Going back to the C-style solution seems like the wrong direction. Since that would mean this special assignment functionality is not allowed to be used everywhere, it alleviates the pressure to make it fit into with/import/except statements. Furthermore, that frees up the keyword "as" again, which is Pythonic, short, memorable and has a history of being used for various assignment purposes, not to mention a prominent feature of SQL. In short, extend the "if/elif", "while", and comprehension to: if pattern.search(data) as match: … while read_next_item() as value: … May be best to disallow multiple assignment/conditions for now, but up for discussion. That leaves comprehensions, which could support a EXPR as NAME target also: filtered_data = [f(x) as y, x/y for x in data] or perhaps reuse of the if…as statement to keep it simpler: filtered_data = [y, x/y for x in data if f(x) as y] That variant might need an extra test if f(x) returns a falsey value, perhaps "is not None" on the end. Thoughts? -Mike

18 68

Allow multiple imports from a package while preserving its namespace
by Julian DeMille 22 May '18

22 May '18

I personally would like a feature where instead of doing `from ... import ...` (which imports the specified items into the current namespace), one could use something along the lines of `import <lib>.{ <mod1>, <mod2>, ... }` such that the imported modules/attributes could be accessed as `<lib>.<mod1>`, etc. -- Thanks, Julian DeMille CEO, demilleTech, LLC This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

10 19