Mailman 3 October 2020 - Python-ideas

zip(x, y, z, strict=True)
by Ram Rachum Dec. 1, 2022

Dec. 1, 2022

Here's something that would have saved me some debugging yesterday: >>> zipped = zip(x, y, z, strict=True) I suggest that `strict=True` would ensure that all the iterables have been exhausted, raising an exception otherwise. This is useful in cases where you're assuming that the iterables all have the same lengths. When your assumption is wrong, you currently just get a shorter result, and it could take you a while to figure out why it's happening. What do you think?

27 179

Bringing the print statement back
by Guido van Rossum March 2, 2022

March 2, 2022

In Python 3.10 we will no longer be burdened by the old parser (though 3rd party tooling needs to catch up). One thing that the PEG parser makes possible in about 20 lines of code is something not entirely different from the old print statement. I have a prototype: Python 3.10.0a0 (heads/print-statement-dirty:5ed19fcc1a, Jun 9 2020, 16:31:17) [Clang 11.0.0 (clang-1100.0.33.8)] on darwin Type "help", "copyright", "credits" or "license" for more information. Cannot read termcap database; using … [View More]dumb terminal settings. >>> print 2+2 4 >>> print "hello world" hello world >>> print "hello", input("Name:") Name:Guido hello Guido >>> print 1, 2, 3, sep=", " 1, 2, 3 >>> But wait, there's more! The same syntax will make it possible to call *any* function: >>> len "abc" 3 >>> Or any method: >>> import sys >>> sys.getrefcount "abc" 24 >>> Really, *any* method: >>> class C: ... def foo(self, arg): print arg ... >>> C().foo 2+2 4 >>> There are downsides too, though. For example, you can't call a method without arguments: >>> print <built-in function print> >>> Worse, the first argument cannot start with a parenthesis or bracket: >>> print (1, 2, 3) 1 2 3 >>> C().foo (1, 2, 3) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: C.foo() takes 2 positional arguments but 4 were given >>> print (2+2), 42 4 (None, 42) >>> C().foo [0] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'method' object is not subscriptable >>> No, it's not April 1st. I am seriously proposing this (but I'll withdraw it if the response is a resounding "boo, hiss"). After all, we currently have a bunch of complexity in the parser just to give a helpful error message to people used to Python 2's print statement: >>> print 1, 2, 3 File "<stdin>", line 1 print 1, 2, 3 ^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1, 2, 3)? >>> And IIRC there have been a number of aborted attempts at syntactic hacks to allow people to call functions (like print) without parentheses, although (I think) none of them made it into a PEP. The PEG parser makes this much simpler, because it can simply backtrack -- by placing the grammar rule for this syntax (tentatively called "call statement") last in the list of alternatives for "small statement" we ensure that everything that's a valid expression statement (including print() calls) is still an expression statement with exactly the same meaning, while still allowing parameter-less function calls, without lexical hacks. (There is no code in my prototype that checks for a space after 'print' -- it just checks that there's a name, number or string following a name, which is never legal syntax.) One possible extension I didn't pursue (yet -- dare me!) is to allow parameter-less calls inside other expressions. For example, my prototype does not support things like this: >>> a = (len "abc") File "<stdin>", line 1 a = (len "abc") ^ SyntaxError: invalid syntax >>> I think that strikes a reasonable balance between usability and reduced detection of common errors. I could also dial it back a bit, e.g. maybe it's too much to allow 'C().foo x' and we should only allow dotted names (sufficient to access functions in imported modules and method calls on variables). Or maybe we should only allow simple names (allowing 'len x' but disallowing 'sys.getrefcount x'. Or maybe we should really only bring back print statements. I believe there are some other languages that support a similar grammar (Ruby? R? Raku?) but I haven't investigated. Thoughts? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…> [View Less]

42 66

Adding a thin wrapper class around the functions in stdlib.heapq
by bunslow Feb. 18, 2022

Feb. 18, 2022

Nothing so bombastic this time. The heapq functions are basically all named "heapsomething", and basically all take a "heap" for their first argument, with supplementary args coming after. It's a textbook example of the (hypothetical) Object Oriented Manifesto™ where defining a class increases type safety and programmers' conceptual clarity. There're practically no drawbacks, and the code to be added would be very simple. Updating the tests and docs would probably be harder. In pure Python, … [View More]

17 32

Make fnmatch.filter accept a tuple of patterns
by Andre Delfino March 26, 2021

March 26, 2021

Frequently, while globbing, one needs to work with multiple extensions. I’d like to propose for fnmatch.filter to handle a tuple of patterns (while preserving the single str argument functionality, alas str.endswith), as a first step for glob.i?glob to accept multiple patterns as well. Here is the implementation I came up with: https://github.com/python/cpython/compare/master...andresdelfino:fnmatch-mu… If this is deemed reasonable, I’ll write tests and documentation updates. Any opinion?

9 15

Dataclasses, keyword args, and inheritance
by George Leslie-Waksman March 12, 2021

March 12, 2021

The proposed implementation of dataclasses prevents defining fields with defaults before fields without defaults. This can create limitations on logical grouping of fields and on inheritance. Take, for example, the case: @dataclass class Foo: some_default: dict = field(default_factory=dict) @dataclass class Bar(Foo): other_field: int this results in the error: 5 @dataclass ----> 6 class Bar(Foo): 7 other_field: int 8 ~/.pyenv/versions/3.6.2/envs/… [View More]clover_pipeline/lib/python3.6/site-packages/dataclasses.py in dataclass(_cls, init, repr, eq, order, hash, frozen) 751 752 # We're called as @dataclass, with a class. --> 753 return wrap(_cls) 754 755 ~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/site-packages/dataclasses.py in wrap(cls) 743 744 def wrap(cls): --> 745 return _process_class(cls, repr, eq, order, hash, init, frozen) 746 747 # See if we're being called as @dataclass or @dataclass(). ~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/site-packages/dataclasses.py in _process_class(cls, repr, eq, order, hash, init, frozen) 675 # in __init__. Use "self" if possible. 676 '__dataclass_self__' if 'self' in fields --> 677 else 'self', 678 )) 679 if repr: ~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/site-packages/dataclasses.py in _init_fn(fields, frozen, has_post_init, self_name) 422 seen_default = True 423 elif seen_default: --> 424 raise TypeError(f'non-default argument {f.name!r} ' 425 'follows default argument') 426 TypeError: non-default argument 'other_field' follows default argument I understand that this is a limitation of positional arguments because the effective __init__ signature is: def __init__(self, some_default: dict = <something>, other_field: int): However, keyword only arguments allow an entirely reasonable solution to this problem: def __init__(self, *, some_default: dict = <something>, other_field: int): And have the added benefit of making the fields in the __init__ call entirely explicit. So, I propose the addition of a keyword_only flag to the @dataclass decorator that renders the __init__ method using keyword only arguments: @dataclass(keyword_only=True) class Bar(Foo): other_field: int --George Leslie-Waksman [View Less]

12 35

PEP 9999 (provisional): support for indexing with keyword arguments
by Stefano Borini March 10, 2021

March 10, 2021

PEP for support for indexing with keyword arguments is now submitted as PR. https://github.com/python/peps/pull/1612 Thanks to everybody involved in the development of the PEP and the interesting discussion. All your contributions have been received and often added to the document. If the PEP is approved, I would like to attempt an implementation, but I am not particularly skilled in the python internals. If a core developer is willing to teach me the ropes (especially in the new parser, I … [View More]

20 100

A shortcut to load a JSON file into a dict : json.loadf
by The Nomadic Coder March 10, 2021

March 10, 2021

Hi All, This is the first time I'm posting to this mailing group, so forgive me if I'm making any mistakes. So one of the most common ways to load json, is via a file. This is used extensively in data science and the lines. We often write something like :- with open(filename.json, "r") as f: my_dict = json.load(f) or my_dict = json.load(open("filename.json", "r")) Since this is sooooo common, why doesn't python have something like :- json.loadf("filename.json") Is there an obvious … [View More]

22 67

Add extend_const action to argparse
by python＠roganartu.com Feb. 8, 2021

Feb. 8, 2021

Forgive me if this idea has been discussed before, I searched the mailing lists, the CPython repo, and the issue tracker and was unable to find anything. I have found myself a few times in a position where I have a repeated argument that uses the `append` action, along with some convenience arguments that append a specific const to that same dest (eg: `--filter-x` being made equivalent to `--filter x` via `append_const`). This is particularly useful in cli apps that expose some kind of … [View More]

3 2

Re: [Python-Dev] reversed enumerate
by Steven D'Aprano Jan. 22, 2021

Jan. 22, 2021

Hi Ilya, I'm not sure that this mailing list (Python-Dev) is the right place for this discussion, I think that Python-Ideas (CCed) is the correct place. For the benefit of Python-Ideas, I have left your entire post below, to establish context. [Ilya] > I needed reversed(enumerate(x: list)) in my code, and have discovered > that it wound't work. This is disappointing because operation is well > defined. It isn't really well-defined, since enumerate can operate on infinite … [View More]iterators, and you cannot reverse an infinite stream. Consider: def values(): while True: yield random.random() a, b = reversed(enumerate(values()) What should the first pair of (a, b) be? However, having said that, I think that your idea is not unreasonable. `enumerate(it)` in the most general case isn't reversable, but if `it` is reversable and sized, there's no reason why `enumerate(it)` shouldn't be too. My personal opinion is that this is a fairly obvious and straightforward enhancement, one which (hopefully!) shouldn't require much, if any, debate. I don't think we need a new class for this, I think enhancing enumerate to be reversable if its underlying iterator is reversable makes good sense. But if you can show some concrete use-cases, especially one or two from the standard library, that would help your case. Or some other languages which offer this functionality as standard. On the other hand, I think that there is a fairly lightweight work around. Define a helper function: def countdown(n): while True: yield n n -= 1 then call it like this: # reversed(enumerate(seq)) zip(countdown(len(seq)-1), reversed(seq))) So it isn't terribly hard to work around this. But I agree that it would be nice if enumerate encapsulated this for the caller. One potentially serious question: what should `enumerate.__reversed__` do when given a starting value? reversed(enumerate('abc', 1)) Should that yield...? # treat the start value as a start value (1, 'c'), (0, 'b'), (-1, 'a') # treat the start value as an end value (3, 'c'), (2, 'b'), (1, 'a') Something else? My preference would be to treat the starting value as an ending value. Steven On Wed, Apr 01, 2020 at 08:45:34PM +0200, Ilya Kamenshchikov wrote: > Hi, > > I needed reversed(enumerate(x: list)) in my code, and have discovered that > it wound't work. This is disappointing because operation is well defined. > It is also well defined for str type, range, and - in principle, but not > yet in practice - on dictionary iterators - keys(), values(), items() as > dictionaries are ordered now. > It would also be well defined on any user type implementing __iter__, > __len__, __reversed__ - think numpy arrays, some pandas dataframes, tensors. > > That's plenty of usecases, therefore I guess it would be quite useful to > avoid hacky / inefficient solutions like described here: > https://code.activestate.com/lists/python-list/706205/. > > If deemed useful, I would be interested in implementing this, maybe > together with __reversed__ on dict keys, values, items. > > Best Regards, > -- > Ilya Kamen > > ----------- > p.s. > > *Sketch* of what I am proposing: > > class reversible_enumerate: > > def __init__(self, iterable): > self.iterable = iterable > self.ctr = 0 > > def __iter__(self): > for e in self.iterable: > yield self.ctr, e > self.ctr += 1 > > def __reversed__(self): > try: > ri = reversed(self.iterable) > except Exception as e: > raise Exception( > "enumerate can only be reversed if iterable to > enumerate can be reversed and has defined length." > ) from e > > try: > l = len(self.iterable) > except Exception as e: > raise Exception( > "enumerate can only be reversed if iterable to > enumerate can be reversed and has defined length." > ) from e > > indexes = range(l-1, -1, -1) > for i, e in zip(indexes, ri): > yield i, e > > for i, c in reversed(reversible_enumerate("Hello World")): > print(i, c) > > for i, c in reversed(reversible_enumerate([11, 22, 33])): > > print(i, c) > _______________________________________________ > Python-Dev mailing list -- python-dev(a)python.org > To unsubscribe send an email to python-dev-leave(a)python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NDDKDUD… > Code of Conduct: http://python.org/psf/codeofconduct/ [View Less]

7 14

Add command-line option to unittest for enabling post-mortem debugging
by Dominik Vilsmeier Jan. 9, 2021

Jan. 9, 2021

Consider the following example: import unittest def foo(): for x in [1, 2, 'oops', 4]: print(x + 100) class TestFoo(unittest.TestCase): def test_foo(self): self.assertIs(foo(), None) if __name__ == '__main__': unittest.main() If we were calling `foo` directly we could enter post-mortem debugging via `python -m pdb test.py`. However since `foo` is wrapped in a test case, `unittest` eats the exception and thus prevents post-… [View More]

1 1

Python JIT Compilation Thoughts
by redradist＠gmail.com Jan. 6, 2021

Jan. 6, 2021

Hi all, I do not know maybe it was already discussed ... but the toolchain like LLVM is very mature and it can provide the simpler JIT compilation to machine code functionality and it will improve performance of the Python a lot !!

9 15

@classproperty, @abc.abstractclasspropery, etc.
by K. Richard Pixley Dec. 16, 2020

Dec. 16, 2020

There's a whole matrix of these and I'm wondering why the matrix is currently sparse rather than implementing them all. Or rather, why we can't stack them as: class foo(object): @classmethod @property def bar(cls, ...): ... Essentially the permutation are, I think: {'unadorned'|abc.abstract}{'normal'|static|class}{method|property|non-callable attribute}. concreteness implicit first arg type name comments {unadorned} {unadorned} method def foo(): exists … [View More]now {unadorned} {unadorned} property @property exists now {unadorned} {unadorned} non-callable attribute x = 2 exists now {unadorned} static method @staticmethod exists now {unadorned} static property @staticproperty proposing {unadorned} static non-callable attribute {degenerate case - variables don't have arguments} unnecessary {unadorned} class method @classmethod exists now {unadorned} class property @classproperty or @classmethod;@property proposing {unadorned} class non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract {unadorned} method @abc.abstractmethod exists now abc.abstract {unadorned} property @abc.abstractproperty exists now abc.abstract {unadorned} non-callable attribute @abc.abstractattribute or @abc.abstract;@attribute proposing abc.abstract static method @abc.abstractstaticmethod exists now abc.abstract static property @abc.staticproperty proposing abc.abstract static non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract class method @abc.abstractclassmethod exists now abc.abstract class property @abc.abstractclassproperty proposing abc.abstract class non-callable attribute {degenerate case - variables don't have arguments} unnecessary I think the meanings of the new ones are pretty straightforward, but in case they are not... @staticproperty - like @property only without an implicit first argument. Allows the property to be called directly from the class without requiring a throw-away instance. @classproperty - like @property, only the implicit first argument to the method is the class. Allows the property to be called directly from the class without requiring a throw-away instance. @abc.abstractattribute - a simple, non-callable variable that must be overridden in subclasses @abc.abstractstaticproperty - like @abc.abstractproperty only for @staticproperty @abc.abstractclassproperty - like @abc.abstractproperty only for @classproperty --rich [View Less]

10 15

Add the brotli & zstandard compression algorithms as modules
by Omer Katz Dec. 14, 2020

Dec. 14, 2020

Hello everyone, We have many compression algorithms as standard modules, but we lack two important new algorithms: brotli and zstandard. Brotli is an important compression algorithm both for HTTP2 and for compressing/decompressing HTTP responses. ZStandard is another algorithm for compression that can easily beat gzip with a better compression ratio and less compression time. Both are now stable enough and are past the 1.0 mark. Let's include them in the standard library and, of course, make … [View More]

12 21

Experimental syntax proposal
by André Roberge Dec. 5, 2020

Dec. 5, 2020

# Experimental Syntax Proposal I would like to propose that Python adopts a modified process before introducing significant changes of its syntax. ## Preamble Given the following file: ```python # coding: experimental-syntax from experimental-syntax import fraction_literal from experimental-syntax import decimal_literal assert 1 /3F == Fraction(1, 3) assert 0.33D == Decimal('0.33') print("simple_test.py ran successfully.") ``` This is what happens when I run it, with the standard Python … [View More]interpreter: ``` $ python simple_test.py simple_test.py ran successfully. ``` In what follows, I use this as a concrete example for one of the three possible options mentioned. ## The problem Python evolves in many ways including with the addition of new modules in the standard library and with the introduction of new syntax. Before considering the addition of a module in the standard library, it is often suggested to have a version on Pypi so that users can experiment with it, which can lead to significant improvements. However, when it comes to proposed syntax changes, this is currently not possible to do, at least not in any standard way that would immediately be easily recognized as such by the wider community. ## Proposed solutions For those that agree that this is something that could be improved upon, I see at least three possible solutions. 1. Adoption of a simple convention to identify the use of non-standard syntax. This could take the form of a comment with a specific form introduced near the top of the file. This comment could be used as a search term, to identify modules or projects that make use of some custom syntax. 2. Addition of a special encoding module in the Python standard library that can be used to implement nonstandard syntax through source transformation. The short program written at the top provides an example of what this might look like. Note the comment at the top defining a special codec, which could also 3. Addition of a standard import hook in the standard library which could be used, like the special encoding example above, to implement syntactic changes. By doing searches in standard locations (Github, Gitlab, etc.) on, one could identify how many modules are making use of a given experimental syntax, giving an idea of the desirability of incorporating into Python. Imagine how different the discussion about the walrus operator would have been if people had had the opportunity to try it out on their own for a few months prior to a decision being made about adding it to Python. ## New Syntax: two approaches There are currently at least two ways in which one can write a Python program that can use some non standard syntax: * By using an import hook. This is the most powerful approach as it allows one to do changes either at the source level (prior to parsing), or at the AST level, or both. * By using a custom encoding. This only allows transformations at the source level. Both approaches currently require a two-step process. To use an import hook, one has first to load a function that sets up this import hook before importing the module that contains the experimental syntax. This makes it impossible to simply write ``` python module_with_new_syntax.py ``` and have it being executed. Import hooks, like the name implies, only apply to modules being imported - not to the first module executed by Python. With a custom encoding, it is however possible to first register a custom codec either via a site.py or usercustomize.py file. Once this is done, the above way of running a module with new syntax is possible, provided that the appropriate encoding declaration is included in the script. This is what I did with the example shown above. ### Current limitation of these two approaches Using an import hook for enabling new syntax does not work for code entered in the standard Python REPL, which limits the possibility of experimentation. While I have read that specifying the environment variable `PYTHONIOENCODING` enables the Python REPL to use a custom encoding, I have not been able to make it work on Windows and confirm that it is indeed possible to do so. However, I have been able to use a simple customized REPL that can make use of the above. Perhaps the standard REPL could be modified in a similar way. ## New suggested process Assuming one of the options mentioned above is adopted, before changes to the syntax are introduced in a Python version, they would be made available to be used either as an encoding variant or an import hook giving enough time for interested pythonistas to experiment with the new syntax, writing actual code and possibly trying out various alternatives. ## Proof of concept As a proof of concept shown at the beginning of this post, I have created two tiny modules that introduce new syntax that had been discussed many times on this list: 1. a new syntax for decimal literals 2. a new syntax for rationals Both modules have been uploaded separately to Pypi; I wanted to simulate what could happen if a proposal such as this one were adopted. To make use of these, you need to use the `experimental-syntax` codec found in my `ideas` package. To run the example as shown above, you first need to register the codec, which can be done by using either the `site.py` or `usercustomize.py` approach. I chose the latter, by setting the environment variable `PYTHONPATH` to be a path where the following `usercustomize.py` file is found. ```python from ideas import experimental_syntax_encoding print(f" --> {__file__} was executed") ``` Doing this on Windows, I found that it did not seem to work when using a virtual environment (I added the print statement to confirm that it was loaded). Here's a sample session using the code available currently on pypi. ``` C:\Users\andre\github\ideas>python simple_test.py --> C:\Users\andre\github\ideas\usercustomize.py was executed simple_test.py ran successfully. C:\Users\andre\github\ideas>python --> C:\Users\andre\github\ideas\usercustomize.py was executed Python 3.8.4 (tags/v3.8.4:dfa645a, Jul 13 2020, 16:30:28) [MSC v.1926 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from ideas import experimental_syntax_encoding >>> from ideas import console >>> console.start() Configuration values for the console: transform_source: <function transform_source at 0x00A8AE38> -------------------------------------------------- Ideas Console version 0.0.19. [Python version: 3.8.4] ~>> import simple_test simple_test.py ran successfully. ~>> from experimental-syntax import decimal_literal ~>> 3.46D Decimal('3.46') ~>> from experimental-syntax import fraction_literal ~>> 2/3F Fraction(2, 3) ~>> ``` Installation: python -m pip install ideas # will also install token-utils python -m pip install decimal-literal python -m pip install fraction-literal More information about "ideas" can be found at https://aroberge.github.io/ideas/docs/html/ It has not (yet) been updated to include anything about the `experimental_syntax_encoding` module, which I just worked on today. ## Final thoughts This proposal is really about the idea of adopting a standard process of some sort that enables users to experiment with any proposed new syntax, rather than the specific "silly" examples I have chosen to illustrate it. André Roberge P.S. If anyone knows how to make a usercustomize file run in a virtual environment on Windows, please let me know. [View Less]

4 7

Variadic generics PEP draft
by Matthew Rahtz Nov. 29, 2020

Nov. 29, 2020

Hi all, Something that's on many of our wishlists is support for variadic generics. Here's a first draft of a PEP detailing how they might work. https://docs.google.com/document/d/1oXWyAtnv0-pbyJud8H5wkpIk8aajbkX-leJ8JXs… (Attached is also an HTML render of the RST for easier reading.) This is an early draft so there are likely many things we're still missing. Please do take a look and give us your feedback (in the doc directly or by email, whichever is easiest for you). Thanks! Matthew

5 4

'Infinity' constant in Python
by Cade Brown Nov. 23, 2020

Nov. 23, 2020

I am positing that Python should contain a constant (similar to True, False, None), called Infinity. It would be equivalent to `float('inf')`, i.e. a floating point value representing a non-fininte value. It would be the positive constant; negative infinity could retrieved via `-Infinity` Or, to keep float representation the same, the name `inf` could be used, but that does not fit Python's normal choice for such identifiers (but indeed, this is what C uses which is the desired behavior of … [View More]

28 161

Dict unpacking assignment
by Steven D'Aprano Nov. 1, 2020

Nov. 1, 2020

I would like to propose dict (or mapping) unpacking assignment. This is inspired in part by the Python-Ideas thread "f-strings as assignment targets", dict unpacking in function calls, and iterable unpacking assignment. Comments welcome. Background ---------- Iterable unpacking assignment: values = (1, 2, 3) a, b, c = *values is a very successful and powerful technique in Python. Likewise dict unpacking in function calls and dict displays: kwargs = {'a': 1, 'b': 2} … [View More]func(**kwargs) d = {**kwargs, 'c': 3} There have been various requests for allowing dict unpacking on the right-hand side of an assignment [citation required] but in my opinion none of them have had a good justification. Motivated by the idea of scanning text strings with a scanf-style function, I propose the following behaviour for dict unpacking assignment: items = {'eggs': 2, 'cheese': 3, 'spam': 1} spam, eggs, cheese = **items assert spam == 1 and eggs == 2 and cheese == 3 Syntax ------ target_list [, **target] = **expression `target_list` is a comma-separated list of targets. Targets may be: - simple names, e.g. `spam` and `eggs` - dotted names, e.g. `spam.eggs` - numbered subscripts, e.g. `spam[1]` but is not required to support arbitrary complex targets such as: spam(*args).eggs(2*x + y)[1].cheese # not supported Likewise only int literals are supported for subscripts. (These restrictions may be lifted.) This is similar to the limited range of fields acceptabled by the string format mini-language. The same restrictions apply to `**target`. Each target must be unique. `expression` must evaluate to a dict or other mapping. Assignment proceeds by matching up targets from the left to keys on the right: 1. Every target must be matched exactly by a key. If there is a target without a corresponding key, that is an error. 2. Any key which does not match up to a target is an error, unless a `**target` is given. 3. If `**target` is given, it will collect any excess key:value pairs remaining into a dict. 4. If the targets and keys match up, then the bindings are applied from left to right, binding the target to the value associated with that key. Examples: # Targets are not unique a, b, a = **items => SyntaxError # Too many targets a, b, c = **{'a': 1, 'b': 2} => raises a runtime exception # Too few targets a = **{'a': 1, 'b': 2} => raises a runtime exception a, **extras = **{'a': 1, 'b': 2} assert a == 1 assert extras == {'b': 2} # Equal targets and keys a, b, **extras = **{'a': 1, 'b': 2} assert a == 1 assert b == 2 assert extras == {} # Dotted names from types import SimpleNamespace obj = SimpleNamespace() obj.spam = **{'obj.spam': 1} assert obj.spam == 1 # Subscripts arr = [None]*5 arr[1], arr[3] = **{'arr[3]': 33, 'arr[1]': 11} assert arr == [None, 11, None, 33, None] Assignments to dotted names or subscripts may fail, in which case the assignment may only partially succeed: spam = 'something' eggs = None spam, eggs.attr = {'spam': 1, 'eggs.attr': 2} # raises AttributeError: 'NoneType' object has no attribute 'attr' # but `spam` may have already been bound to 1 (I think that this is undesirable but unavoidable.) Motivating use-cases -------------------- The motivation comes from the discussion for scanf-like functionality. The addition of dict unpacking assignment would allow something like this: pattern = "I'll have {main} and {extra} with {colour} coffee." string = "I'll have spam and eggs with black coffee." main, extra, colour = **scanf(pattern, string) assert main == 'spam' assert extra == 'eggs' assert colour == 'black' But the possibilities are not restricted to string scanning. This will allow functions that return multiple values to choose between returning them by position or by name: height, width = get_dimensions(window) # returns a tuple height, width = **get_dimensions(window) # returns a mapping Developers can choose whichever model best suits their API. Another use-case is dealing with kwargs inside functions and methods: def method(self, **kwargs): spam, eggs, **kw = **kwargs process(spam, eggs) super().method(**kw) -- Steve [View Less]

17 32

Ricky Teachey's email to me on PEP 637, and my responses
by Jonathan Fine Oct. 28, 2020

Oct. 28, 2020

SUMMARY: I share with you extracts from a personal email Rick Teachey sent me, on my involvement in PEP 637 (keyword arguments in item access), and my answers to some important questions he asks. BACKGROUND: Last week, prior to my publicly stating my resignation as a co-author of PEP 637, Ricky Teachey sent me a personal email. I found it so deep and perceptive that I asked him for permission to share extracts with you on this list. I'm pleased that he's allowed this, and I'm most grateful to … [View More]him for this. The rest of this post consists of extracts from his email, and some brief comments from me. RICKY'S EMAIL and MY RESPONSES: Ricky Teachey wrote: > It is clear to all-- not a secret-- you take a different view on the > desirability of what is currently the favored proposal. It seems to me what > has happened here is, Guido, Steven, and now Stefano believe that your > involvement in the PEP (one that is championing that proposal you have > significant disagreements with) has been undertaken by you out of a > motivation to either get it drastically changed, or (again, in their > belief) perhaps even to replace it totally with something else. > Now I want you to know I don't get that impression from you. I get the > impression you joined the PEP team out of a simple desire to make it > better, even though you disagreed with parts of it. PEP 1 says: > The PEP author is responsible for building consensus within the community > and documenting dissenting opinions. [The PEP] should clearly explain why the existing language specification is > inadequate to address the problem that the PEP solves. I want keyword arguments in item access to be added to Python, and I want it to be done well. Something that won't cause difficulty 3 to 5 years from now. PEP 1, as above, has good advice that contributes to this goal. These are areas I particularly wanted to contribute to, as a PEP author. I have no wish to use improper methods to obtain what I think is best. > Ricky Teachey wrote: > I also understand, though, that at least part of the motivation [for > developing kwkey] is something else; you believe that if people experiment > a bit ahead of time using actual code, the deficiencies of the current > proposal will feel worse than people are imaging in their minds. I wouldn't > suggest you back down from saying that outright, too. But if you can say > so, I would emphasize that the primary purpose is helping people experiment. At least when convenient, I'm all for experiments prior to making hard-to-reverses changes to Python. PEP 1 says: > For a PEP that adds new functionality or changes language behavior, it is > helpful to include a section on how to teach users, new and experienced, > how to apply the PEP to their work. A basic idea of kwkey is an equivalence between d[1, 2, a=3, b=4] = val X(1, 2, a=3, b=4)[d] = val provided X and item keyword access are given the same semantics. This idea will I think help greatly with the 'teach users' section of the PEP. Observation, experiment and theory are fundamental to science. Astronomy has the observatory. Biology, chemistry and physics have the laboratory. All research scientists publish. We can use kwkey to do experiments, without first having to create a new version of Python. It makes experiments cheap. My opinions result in predictions for the result of these experiments. But rather than discuss opinions, I'd like us to do experiments and share our experience. I've been surprised by the results of my own experiments using kwkey! We can all learn from experiments, particularly if we're observant. Ricky Teachey wrote: > However, on the other hand, if the first is not really your purpose-- if > what you really want is for people to use the package and realize the > proposal needs to be changed, I would [...] suggest asking to write a > competing PEP, and promote kwkey a great tool that the steering council can > use to make a good choice between competing PEPs. I applaud your suggestion, that the steering council use kwkey as part of making a choice. And I think we're getting closer to having a second PEP. Here's an idea. At present both of d[1:2] d[1:2, 3:4, 5, 6] are valid syntax, but neither of d[(1:2)] d[(1:2, 3:4, 5, 6)] are valid syntax. This is, I think, a bit of an anomaly. I suggest a PEP that extended the syntax to allow (1:2) (1:2, 3:4, 5, 6) to be expressions (to be used as function arguments, with the existing item access semantics). I think this is something which most supporters of keyword arguments in item access could support. And which few opponents of keyword arguments in item access would oppose. It's a small and fairly safe change. And this change would, via constructs such as X((1:2), a=(3:4))[d] = val allow us to get perhaps 75% of the benefits provided by the larger (and more risky) change that would allow d[1:2, a=3:4] = val I think we could get (1:2) etc expressions into the next version of Python (in 2021). And then, if X((1:2), a=(3:4))[d] = val is widely used, and the semantics of X agreed upon, perhaps d[1:2, a=(3:4)] = val could be added in 2022. My big concern is making a big change now, whose problems emerge in 2023 to 2025. I hope this helps. And I thank Ricky both for his thoughtful personal email, and for giving me permission to share it with you. -- Jonathan [View Less]

6 7

Multiple dispatch for comparison operators?
by Neil Girdhar Oct. 27, 2020

Oct. 27, 2020

The way I understand it, multiple dispatch is programming language feature wehreby a function or method overload is chosen based on run time types. Python already has single dispatch (functools.singledispatch). It also has the concept of overloads for type annotations (typing.overload). My main motivation for suggesting multiple dispatch for Python is to simplify writing comparison operators and to facilitate mypy's ability to understand them. Python has a long history of writing … [View More]

1 0

Conditional function/method/dict arguments assignments
by Brian Allen Vanderburg II Oct. 26, 2020

Oct. 26, 2020

This is just a hack idea I had for functions/methods that have parameters with default values, possibly outside the control of the user of said function, where sometimes it is desired to pass an argument to the function that differs from the default but other times it is desired to just use the default, whatever that may be # An external function def dosomething(count=5): doing_something # The function using an external function def dosomething_twice(count=None): &… [View More]nbsp; # if count is none, just use the default count from dosomething if count is None: dosomething() dosomething() else: dosomething(count) dosomething(count) # or use a dict # kwargs = {} # if count is not None: # kwargs["count"] = count # dosomething(*kwargs) # dosomething(*kwargs) We could set the count's default value to 5 in dosomething_twice, but then if the external function changed its default, calling dosomething_twice with no parameters would no longer actually be using dosomething's default. If dosomething were in our control, we could set count=None as default and in the code do something like count = 5 if count is None else count. I imagine a syntax like def dosomething_twice(count=None): dosomething(count is not None ?? count) # If count is not None, pass it, else, use the dosomething's default parameter. dosomething(count is not None ?? count) This syntax is <conditional parameter test> ?? <value if test is True>. The requirements are that the parameter to be filled in in the calling method must have a default value. If the test evaluates to false, the right hand side will not be evaluated (lazy evaluation) and instead the default value will be used. This can also be used for passing by keyword arguments: def dosomething_twice(count=None): dosomething(count = count is not None ?? count) dosomething(count = count is not None ?? count) It could also be used to avoid specifying long argument lists: # external button.create(self, parent, x=0, y=0, w=64, h=32, style=...., label="", windowclass="") calling: ??, by itself, will fill in that parameter with the default. If the external code ever changes, no need to change our code to update each time. The use case here is to skip specifying a parameter in a long function parameter list but still have its default used. This probably only make sense for parameters being passed via positional arguments, since "style=??", (pass as a keyword style the default value), can just be done by omitting style call. def create_buttons(style=None): button = Button(self, 10, 10, ??, ??, style is not None ?? style, "Ok") # pass the defaults for w, h, and style if a our style parameter is None else uses the specified style, if the calling code changes the default, our code will automatically use it. button = Button(self, 110, 10, ??, ??, style is not None ?? style, "Cancel") button = Button(self, 110, 10, ??, ??, style is not None ?? style, "Retry", wiindowclass=??) # see keyword "windowclass=??" doesn't make much sense as the result is achieved by excluding it. A similar use case could possibly be made for conditional dict assignments: data = {} if count is not None: data["count"] = count Could be written as data = { "count" = count is not None ?? count, # set the "count" key in the dictionary conditionally, if count is not None, else don't set the key at all "other_param" = ... ?? ..., ... } Thanks, Brian Vanderburg II [View Less]

5 4

Inconsistency in splitting strings
by Antal Gábor Oct. 26, 2020

Oct. 26, 2020

Hey there, This is my first letter here, I'll try my best to explain the problem. First of all, I ran into this "problem" several times. I find str.split() a bit confusing. First of all, this is a corner case, but can happen like every day. print("".split()) # returns [] print("".split(" ")) # returns [''] print("".split("\t")) # returns [''] print("".split("\n")) # returns [''] print("".splitlines()) # returns [] So using split with or without a separator … [View More]

5 4

TextIOWrapper support for null-terminated lines
by Brian Allen Vanderburg II Oct. 26, 2020

Oct. 26, 2020

I have a use case where I'm writing a small filter in Python which should be able to take output from the find command to filter and optionally pass it to other commands (like xargs), but also can be passed specific filenames for the input and/or output. Find can output it's filenames in null-terminated lines since it is possible to have newlines in a filename(yuck). There are workarounds that I can use to get the same thing done, essentially using TextIOWrapper in '' mode and … [View More]

5 6

execute function on iterator items without changing or consuming iterator
by anderssonpublic＠gmail.com Oct. 26, 2020

Oct. 26, 2020

Python has many tools for iteration, such as map and filter, that change an iterator into another iterator without consuming the iterator. These make it simple to deal with many items in a list without consuming excessive memory. Occasionally it is useful to be able to tap into iterator items and execute a function (such as a side effect to validate elements or print them) without making any changes to the overall iterator. This is similar to the idea of a tap in rxjs: https://rxjs-dev.… [View More]

5 4

Extrapolating PEP 634: The walrus was waiting for patmat all along
by Valentin Berlier Oct. 24, 2020

Oct. 24, 2020

Pattern-matching is great. I think PEP 634 is on the right track, but it would be a waste to only use pattern-matching for choosing a branch in a match statement. Let’s look at Rust: if let [x, y] = my_array { ... } Rust "if let" constructs are an alternative to full-blown match statements that make it less verbose to match a single pattern. We have a similar problem. The syntax proposed by PEP 634 is pretty verbose for matching a single pattern: match my_list: … [View More]

3 4

f-string: empty expression should be allowed
by Hans Ginzel Oct. 23, 2020

Oct. 23, 2020

Hello, consider this snippet please cursor.execute(f"INSERT INTO {table} VALUES (1, '{}');") SyntaxError: f-string: empty expression not allowed It is (absolutely) correct to insert empty json into database table field. Empty expression in f-string should * (silently) expand as '{}' (opening and closing braces), * generate a (compile time) warning if requested, e.g. with -W. Thank you in advance Hans

9 14

f-strings as assignment targets
by Dennis Sweeney Oct. 23, 2020

Oct. 23, 2020

TL;DR: I propose the following behavior: >>> s = "She turned me into a newt." >>> f"She turned me into a {animal}." = s >>> animal 'newt' >>> f"A {animal}?" = s Traceback (most recent call last): File "<pyshell#2>", line 1, in <module> f"A {animal}?" = s ValueError: f-string assignment target does not match 'She turned me into a newt.' >>> f"{hh:d}:{mm:d}:{ss:d}" = "11:59:59" >>… [View More]> hh, mm, ss (11, 59, 59) === Rationale === Part of the reason I like f-strings so much is that they reduce the cognitive overhead of reading code: they allow you to see *what* is being inserted into a string in a way that also effortlessly shows *where* in the string the value is being inserted. There is no need to "paint-by-numbers" and remember which variable is {0} and which is {1} in an unnecessary extra layer of indirection. F-strings allow string formatting that is not only intelligible, but *locally* intelligible. What I propose is the inverse feature, where you can assign a string to an f-string, and the interpreter will maintain an invariant kept in many other cases: >>> a[n] = 17 >>> a[n] == 17 True >>> obj.x = "foo" >>> obj.x == "foo" True # Proposed: >>> f"It is {hh}:{mm} {am_or_pm}" = "It is 11:45 PM" >>> f"It is {hh}:{mm} {am_or_pm}" == "It is 11:45 PM" True >>> hh '11' This could be thought of as analogous to the c language's scanf function, something I've always felt was just slightly lacking in Python. I think such a feature would more clearly allow readers of Python code to answer the question "What kinds of strings are allowed here?". It would add certainty to programs that accept strings, confirming early that the data you have is the data you want. The code reads like a specification that beginners can understand in a blink. === Existing way of achieving this === As of now, you could achieve the behavior with regular expressions: >>> import re >>> pattern = re.compile(r'It is (.+):(.+) (.+)') >>> match = pattern.fullmatch("It is 11:45 PM") >>> hh, mm, am_or_pm = match.groups() >>> hh '11' But this suffers from the same paint-by-numbers, extra-indirection issue that old-style string formatting runs into, an issue that f-strings improve upon. You could also do a strange mishmash of built-in str operations, like >>> s = "It is 11:45 PM" >>> empty, rest = s.split("It is ") >>> assert empty == "" >>> hh, rest = rest.split(":") >>> mm, am_or_pm = s.split(" ") >>> hh '11' But this is 5 different lines to express one simple idea. How many different times have you written a micro-parser like this? === Specification (open to bikeshedding) === In general, the goal would be to pursue the assignment-becomes-equal invariant above. By default, assignment targets within f-strings would be matched as strings. However, adding in a format specifier would allow the matches to be evaluated as different data types, e.g. f'{foo:d}' = "1" would make foo become the integer 1. If a more complex format specifier was added that did not match anything that the f-string could produce as an expression, then we'd still raise a ValueError: >>> f"{x:.02f}" = "0.12345" Traceback (most recent call last): File "<pyshell#2>", line 1, in <module> f"{x:.02f}" = "0.12345" ValueError: f-string assignment target does not match '0.12345' If we're feeling adventurous, one could turn the !r repr flag in a match into an eval() of the matched string. The f-string would match with the same eager semantics as regular expressions, backtracking when a match is not made on the first attempt. Let me know what you think! [View Less]

22 110

Call a function at invocation
by Michael Smith Oct. 23, 2020

Oct. 23, 2020

There are many ways to invoke a function from the commandline. You can use setuptools' console_scripts entrypoint. You can use a decorator from click. And of course you can always do the classic if __name__ == "__main__": main() to call whatever main() is. But there are inconveniences with these approaches. For setuptools, you have to actually run setup, somehow. For click, you have to install click. And for __name__, you are either locked into a single function name, or you have to write … [View More]

7 12

Re: f-strings as assignment targets
by Chris Angelico Oct. 22, 2020

Oct. 22, 2020

On Wed, Oct 21, 2020 at 1:13 AM Rob Cliffe <rob.cliffe(a)btinternet.com> wrote: > > On 20/10/2020 13:05, Chris Angelico wrote: > > On Tue, Oct 20, 2020 at 10:37 PM Rob Cliffe via Python-ideas > > <python-ideas(a)python.org> wrote: > >> In short, "assigning" to f-strings is not and cannot be a simple reversal of having them in expressions. Rather, it is opening a big can of worms. > >> > > It's not a reversal of them being in expressions … [View More]

5 15

Consolidated ideas
by Madhu Mohan Nelemane Oct. 21, 2020

Oct. 21, 2020

Hi, I have been programming in python for about 6 years now. However, I am a newbie to this mailing list. My observation in the last couple of days is that this is literally an explosion of ideas and in various degrees. I am wondering if there is a common place or site where the ideas that went beyond proposal and got heads up for implementation have been listed. Are they consolidated somewhere to be discussed further ? Or is it something I have to scrape through mailing list archives ? … [View More]

2 1

Optimize out setting unused underscored local variables
by Serhiy Storchaka Oct. 21, 2020

Oct. 21, 2020

It is common to use _ as a placeholder for variable whose value is not used. For example: for _ in range(n) head, _, tail = name.partition(':') first, *_, last = items I though about optimizing out unnecessary assignments. Actually I wrote a patch half year ago and tested it. It did not add much to performance, and did not reduce the bytecode, so I ccoled down to him and put it off. Later PEP 622 was declared the use of _ in pattern matching, so I was waiting for what it would … [View More]

6 10

Upstream Patch to inherit virtual environment ?
by Matthias Bussonnier Oct. 20, 2020

Oct. 20, 2020

Hello Python Ideas, Would there be any interest in upstreaming a patch allowing virtualenv to be inherited in core python ? I'm working with a company that uses such an internal patch and would be ok with me spending some time trying to upstream it. When creating a venv, this let you point to "parents" venvs that will be used to search for existing packages; thus potentially making the creation of large venvs with a common base faster, and decreasing disk space usage. I am aware that … [View More]

4 6

I frequently find myself in the following situations
by 71f13rvj＠powerencry.com Oct. 20, 2020

Oct. 20, 2020

Hi Ideas, I frequently find myself in the following situations: 1) I wish to do something if no exception is thrown, for instance: try: logger.debug('Fiber starting: %s', self) try: self._result = self._routine() finally: logger.debug('Fiber finished: %s', self) except: raise else: raise FiberExit(self) finally: self._finished.set() unregister_fiber(self) Here it's sufficient that that if an … [View More]

2 1

New feature
by ankith abhayan Oct. 18, 2020

Oct. 18, 2020

Hi, I would like to request a new feature that allows you to clear the console screen. Like in c++, the CLS function Thanks

22 56

option to keep TemporaryDirectory
by David Kolovratník Oct. 16, 2020

Oct. 16, 2020

Hi Everyone, When adding debug option to a program I find useful to keep temporary stuff. tempfile.NamedTemporaryFile has option delete defaulting to True. What about adding such option to tempfile.TemporaryDirectory as well? It would be just a minor modification in Lib/tempfile.py. What do you think? Kind regards, David Kolovratník

1 0

Weakrefs for lru_cache?
by Ram Rachum Oct. 16, 2020

Oct. 16, 2020

Hi everyone, For many years, I've used a `cache` decorator that I built <https://github.com/cool-RR/python_toolbox/blob/master/python_toolbox/cachin…> for caching Python functions. Then `functools.lru_cache` was implemented, which is much more standard. However, as far as I know, it holds normal references to its keys, rather than weak references. This means that it can cause memory leaks when it's storing items that don't have any references elsewhere. This often makes me reluctant to … [View More]

9 20

except-try block
by haael Oct. 16, 2020

Oct. 16, 2020

Very often I use the following construction (especially in operators): try: something except SomeError: try: something_else except AnotherError: try: something_completely_different except Whatever: return NotImplemented I propose a construction to simplify the staircase hierarchy of exception handlers: try: something except SomeError try: something_else … [View More]

8 16

Fwd: Re: Experimenting with dict performance, and an immutable dict
by Marco Sulla Oct. 15, 2020

Oct. 15, 2020

On Wed, 22 Jul 2020 at 15:35, Antoine Pitrou <solipsis(a)pitrou.net> wrote: > The deltas also look small for a micro-benchmark. I certainly don't > think this is a sufficient reason to add a new datatype to Python. > I think some of the optimizations can be experimented with dict itself. Deltas seem to be small, because I divide them by the number of timeit runs. I think that a 30-45% gain in constructor speed is not something small. The benchmarks in question have the Name … [View More]that starts with "constructor". PS: sorry for double mail, I sent this message to only you by mistake. On Wed, 22 Jul 2020 at 18:26, Guido van Rossum <guido(a)python.org> wrote: > Did you study PEP 416 (frozendict) and PEP 603 (frozenmap)? > Yes. About frozenmap, at the very start I added to the benchmarks also immutables.Map, but I removed it when I realized that it was slower than frozendict in every bench. Maybe this is because immutables.Map is a C extension and not a builtin type. About PEP 416, yes, I tried to follow it. Indeed hash is calculated using the strategy described in the PEP. I also take a look to frozenset and tuple code. Frankly I must admit that the rejection of PEP 416 was a good idea. Indeed I started to implement an immutable dict only for a symmetry reason, and because I am somewhat fascinated by functional programming and immutables, without a rational reason. I suppose I would have given up and admitted that a frozendict is quite useless in Python, if I did not see that the constructor speed can be faster. I'm not sure 100% of the result. This is why I'm suggesting to try to implement the speed optimizations to the constructor of dict first: 1. the optimizations could be not safe. Indeed recently I got a segfault that I have to investigate 2. maybe dict can be really optimized further. After that, the difference between dict and frozendict performance could be minimal That said, maybe there are four good use cases for a frozendict: 1. they could be used for __annotations__ of function objects, and similar cases 2. they could be used to implement "immutable" modules or classes 3. frozendict can be easily cached, like tuples. 4. as I said, as an alternative to MappingProxyType, since it's very slow and it's used also in the C code of CPython and in the Python stdlib. This maybe is not useful because: a. the speed of MappingProxyType can be improved b. MappingProxyType can't be replaced because you *really* want and need a proxy [View Less]

6 20

Exact decimal multiplication and division operations
by Random832 Oct. 15, 2020

Oct. 15, 2020

I was making a "convert Fraction to Decimal, exactly if possible" function and ran into a wall: it's not possible to do some of the necessary operations with exact precision in decimal: - multiplication - division where the result can be represented exactly [the divisor is an integer whose prime factors are only two and five, or a rational number whose numerator qualifies] I assume there's some way around it that I haven't spent enough time to figure out [create a temporary context with … [View More]

9 27

Enhancing Python custom memory allocators
by Julien Danjou Oct. 15, 2020

Oct. 15, 2020

Hi there, Since Python 3.4, once can replace easily the Python memory allocators via the C API with its own copy (https://docs.python.org/3/c-api/memory.html#customize-memory-allocators). This is a great feature for implementing performance optimizations or profiling. This has given the ability to build powerful tools such as tracemalloc! However, there's one cruelly missing feature. The API only gives you access to the number of bytes to allocate and later to the pointer to free. It would … [View More]

1 0

Exceptions as function calls to kill boilerplate
by jmward01＠gmail.com Oct. 14, 2020

Oct. 14, 2020

I generally find exception objects are really just boilerplate heavy objects masking what I really want them to be, function calls: class MySpecialException(Exception): def __init__(self, some, variables, i, am, tracking): self.some = some ... ... try: if some_test_that_fails(variables): raise MySpecialException(a, b, c, d, e, f) except MySpecialException as e: logger.warning(f"BAD THING {e.a} HAPPENED!") if not handle_it(e.a, e.b, e.c, e.f): raise ... Instead of … [View More]

15 32

Add _KB, _MB, _GB to numeric literals
by malincns＠163.com Oct. 14, 2020

Oct. 14, 2020

PEP 515 added underscore to numeric literals, it brings better readability. PEP 515 -- Underscores in Numeric Literals https://www.python.org/dev/peps/pep-0515/ Is it possible to add _KB, _MB, _GB to numeric literals, for example: 200_KB (200*1024) 150_MB (150*1024*1024) 2_GB (2*1024*1024*1024) Do you think it's a good code style?

9 10

I'm no longer a co-author of PEP 637 - keyword args in item access
by Jonathan Fine Oct. 13, 2020

Oct. 13, 2020

Hi The following is copied and pasted from https://github.com/python/peps/pull/1650 Stefano Borini =========== Commit message: PEP 637 I've asked Jonathan Fine to resign as PEP author, and he's agreed to do so. Details in the pull request Pull request comment: Hi Jonathan Thank you for accepting my invitation to be a co-author of PEP 637. I regret that because of disagreeing direction for the PEP I think it best for the community that I ask you to resign as co-author. Thank you for your … [View More]

1 0

Introducing array shape in function declaration
by vdimirc＠gmail.com Oct. 9, 2020

Oct. 9, 2020

Hello! I want to discuss one feature for handful working with shapes of array-like objects. If we want to pass arrays to function we can declare their sizes directly with argument declaration: ``` def foo(a[m, n], b[n]): for i in range(m): for j in range(n): a[i, j] = b[j] ``` Will be equivalent to ``` def foo(a, b): m, n = a.__shape__() n_b = b.__shape__() if n_b != n: raise ShapeNotValidException() ... ``` Objects should implement `… [View More]

1 0

SupportsString Protocol Type Annotation
by aleksiy123 Oct. 8, 2020

Oct. 8, 2020

Currently there are a few Protocols https://docs.python.org/3/library/typing.html#protocols defined in the typing module. One that I recently felt like was missing was a typing annotation for classes with a __str__() method defined. Seems like a fairly straightforward implementation. @runtime_checkable class SupportsString(Protocol): """An ABC with one abstract method __str__.""" __slots__ = () @abstractmethod def __str__(self) -> str: pass Perhaps there is another way to do this that I am missing?

5 8

CPP Namespaces For Python
by Alperen Keleş Oct. 8, 2020

Oct. 8, 2020

Hi, Please pardon me if my idea is not making sense or already exists, I'm kind of new to developing in Python but I had this idea today and I wanted to share it with you. I think a class type such as "@functionclass" may be helpful for creating functions intended to keep a list of methods in a scope. At the moment, I achieved this via writing "@classmethod" to all my functions but I think such a decorator might help clarify intent for the reader and ease the programmers' job. My regards, Alperen

10 17

Method to efficiently advance iterators for sequences that support random access
by Kevin Mills Oct. 8, 2020

Oct. 8, 2020

str_iterator, bytes_iterator, range_iterator, list_iterator, and tuple_iterator (and probably others) should have a method that is capable of efficiently advancing the iterator, instead of having to call next repeatedly. I suggest adding an itertools.advance function which dispatches to a dunder __advance__ method (if one exists) or, as a fallback, calls next repeatedly. Then, the iterators mentioned above (and any others capable of efficiently doing so) would implement __advance__, which … [View More]

13 28

Allow writing optional types as ?int
by Sebastian Noel Lübke Oct. 7, 2020

Oct. 7, 2020

Hey, python 3.9 introduced the | operator for union types. it would be nice to have something like that for optional types. maybe like name: ? int or name: int ? best regards Sebastian Lübke

4 4

PEP 637 - problems not solved by existing language
by Jonathan Fine Oct. 7, 2020

Oct. 7, 2020

SUMMARY This post asks for some examples that will improve PEP 637, by providing examples where the existing language specification is not adequate (but PEP 637 is). The rest of this post should tell you why I want these examples, and what they should look like. DISCLAIMER I'm an editor of PEP 637, writing in my personal capacity. And I'm also the author of package kwkey mentioned below. SUMMARY PEP 637 adds to Python's syntax and semantics. It adds statements such as >>> x[1, 2, … [View More]

3 6

__call__ on lists, dicts etc.
by george.winton.harding＠gmail.com Oct. 5, 2020

Oct. 5, 2020

Hi all, I've been working in q and k, which is where this idea comes from. My idea is to make lists and dicts callable, with __call__ = __getitem__. So that: [3,4,5](1) gives 4 {'a':1, 'b': 2}('b') gives 2 Arguably a list is a function which maps from range(len(list)) to the list entries, and a dictionary is a function that maps from keys to values. This would mean that functions designed to take functions, can be repurposed to take data, for example: map(lst, idxs) instead of (lst[i] … [View More]

3 2

A new suggestion for Python
by Jonatan Oct. 3, 2020

Oct. 3, 2020

Hi, My name is Jonatan and i am programming in Python for about 4 years, I have a great idea, there are iX` methods, such as __ior__, __iadd__, __iand__ etc.., which implements the |=, +=, &= behavior, it would be nice if you could implement also __igetattr__ or something, which means: instead of con = "some text here" con = con.replace("here", "there") we could do con = "some text here" con .= replace("here", "there") Please let me know what do you think about it, Jonatan

12 16

Trouble with "decorator mixins" and ABCs
by Ben Avrahami Oct. 1, 2020

Oct. 1, 2020

Hey all, I recently ran into some trouble and that I think deserves some attention. Consider the following case: class A(ABC): @abstractmethod def __lt__(self, other): pass @dataclass(order=True) class B(A): x: int = 0 class C(B): pass Although B technically implements A's abstract methods, it is still considered an abstract class, and calling B() will fail. However, C is considered a non-abstract class and calling C() will succeed.… [View More]

5 16