Python-ideas May 2018

python-ideas@python.org

110 participants
84 discussions

by Jacco van Dorp

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

2 years, 9 months

"Assignment expression" with function call-alike syntax

by Kirill Balunov

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

2 years, 9 months

Keyword for direct pass through of kwargs to super

by Michael Lohmann

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

2 years, 9 months

Reuse "for" to express "given"

by Alexander Belopolsky

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.

2 years, 9 months

Thoughts on "extended mapping unpacking"

by Neil Girdhar

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

2 years, 9 months

Meta-PEP about built-in functions

by Jeroen Demeyer

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.

2 years, 9 months

Make asyncio.get_event_loop a builtin

by Ken Hilton

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 ;

2 years, 9 months

Modern language design survey for "assign and compare" statements

by Mike Miller

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

2 years, 9 months

Allow multiple imports from a package while preserving its namespace

by Julian DeMille

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.

2 years, 9 months

Make keywords KEYwords only in places they would have syntactical meaning

by Ken Hilton

Hi all, Yes, this is another idea for avoiding breaking existing code when introducing new keywords. I'm not sure if this is too similar to Guido's previous "allow keywords in certain places" idea, but here goes: Only treat keywords as having any special meaning when they are in places with syntactical significance. So, currently, let's say someone set the variable "and_" to some value. The following lines are both SyntaxErrors: True and_ False obj.and = value And the following are both correct: True and False obj.and_ = value My idea is to only treat keywords as having special meaning when they're in the right place. So the following would all be legal: >>> from operator import and >>> var = and(True, False) >>> var False >>> var = True and False >>> var False >>> def except(exc, def): ... try: ... return def() ... except exc as e: ... return e ... >>> except(ZeroDivisionError, lambda: 1/0) ZeroDivisionError('division by zero',) >>> except(ZeroDivisionError, lambda: 0/1) 0.0 >>> import asyncio as await #this is already currently legal, but will not be in the __future__ >>> async def async(def): ... return await await.get_event_loop().run_in_executor(None, def) ... >>> And so on. What are your thoughts? Sharing, Ken Hilton ;

2 years, 9 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas May 2018