Python-ideas October 2019

python-ideas@python.org

70 participants
45 discussions

PEP's shouldn't require a sponsor
by Batuhan Taskaya 03 Dec '19

03 Dec '19

Why do i need to convince a core developer for my PEP? AFAIK the steering council can include non core developers (i know it isn't that current case but for the future this is important). And if the last authority who will approve my PEP is the steering council i just need to convince them not core developers. Sponsors can stay (and they should because guidance is important) but thy shouldn't be mandatory. Let everyone to send their peps.

22 29

Percent notation for array and string literals, similar to Perl, Ruby
by Steve Jorgensen 25 Nov '19

25 Nov '19

See https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#The_%_Notati… for what Ruby offers. For me, the arrays are the most useful aspect. %w{one two three} => ["one", "two", "three"] I did a search, and I don't see that this has been suggested before, but I might have missed something. I'm guessing I'm not the first person to ask whether this seems like a desirable feature to add to Python.

19 78

Ability to set precedence of classdict (returned from __prepare__) for a metaclass type
by Steve Jorgensen 20 Nov '19

20 Nov '19

When using a custom classdict to implement a DSL or use in the body of a class definition, from what I can tell by experiment, the classdict takes priority, and the surrounding context is only referenced if trying to get an item from the classdict raises `KeyError`. There is at least one case in which I would like to do the reverse, and have the classdict be secondary to (masked by) any variables defined in the context surrounding the execution of the class body. I have been able to at least unmask builtins by having the classdict object first try to get a result from `__builtins__` and then fall back to itself. Also, in the actual class body, declaring a variable as `global` seems to be a workaround for global variables, but that has to be done explicitly in the body of any subclass that needs it. Also, that does not handle non-globals in its surrounding context. I'm not sure what the best way to deal with this would be, but my first thought is to maybe have a property that can be set on the metaclass type such as `metacls.relictant_classdict = True`.

10 26

Please consider adding of functions file system operations to pathlib
by George Fischhof 16 Nov '19

16 Nov '19

Good day all, as a continuation of thread "OS related file operations (copy, move, delete, rename...) should be placed into one module" https://mail.python.org/pipermail/python-ideas/2017-January/044217.html please consider making pathlib to a central file system module with putting file operations (copy, move, delete, rmtree etc) into pathlib. BR, George

3 3

Make itertools recipes license easier
by Todd 11 Nov '19

11 Nov '19

Per Guido's suggestion, I am starting a new thread on this. The itertools module documentation has a bunch of recipes that give various ways to combine the existing functions for useful tasks. [1] The issue is that these recipes are part of the documentation, and although IANAL, as far as I can tell this means they fall under the Python-2.0 license. [2] Normally using the Python-2.0 license is not a big deal because it is non-copyleft. You have to include the license text and explain what changes you made, which isn't a problem for any sizable use of Python code. The problem occurs for such small code snippets. Again IANAL, but it seems you have to add the license text to the project, identify which parts of the code fall under that license, and document any changes you made to it. This is a lot of work to use, in many cases, just one or two lines of code. I personally use one of the projects, like more-itertools, that implement these recipes together under the Python-2.0 license and thus segregate the license issues from the rest of my code base, but at least in my opinion this mostly defeats the purpose of making code snippets like available. As I am not a lawyer, so I don't know the best approach to deal with this issue (if it is even desirable to deal with it). And I know that there are other modules with recipes and other sorts of documentation with useful code, although the itertools ones are the ones I see mentioned the most. [1] https://docs.python.org/library/itertools.html#itertools-recipes [2] https://docs.python.org/license.html#psf-license-agreement-for-python-relea…

6 10

foo.setParseAction(lambda a, b, c: raise FuckPython(":("))
by Soni L. 05 Nov '19

05 Nov '19

foo.setParseAction(lambda a, b, c: raise FuckPython(":(")) is invalid syntax, which makes pyparsing useless.

13 37

Python 4000: Have stringlike objects provide sequence views rather than being sequences
by Steve Jorgensen 03 Nov '19

03 Nov '19

There are many cases in which it is awkward that testing whether an object is a sequence returns `True` for instances of of `str`, `bytes`, etc. This proposal is a serious breakage of backward compatibility, so would be something for Python 4.x, not 3.x. Instead of those objects _being_ sequences, have them provide views that are sequences using a method named something like `members` or `items`.

12 43

Suggestion for behaviour change import mechanics
by Richard Vogel 31 Oct '19

31 Oct '19

Hello everyone, I hope that E-Mail reaches someone. Since its the first time I am using a thing like a mailing list, I am saying sorry in advance for any inconvience caused ;-) However, I am writing you because of a small idea / feature request for the python import mechanism, which caused me some (in my opinion unnecessary) trouble yesterday: I noticed that when using an import statement, the following seems to be true: Current state: * Python will search for the first TOP-LEVEL hit when resolving an import statement and search inside there for the remainder part of the import. If it cannot find the symbols it will fail. (Tested on Python 3.8) Proposed Change: * If the import fails at some point after finding the first level match: The path is evaluated further until it eventually may be able to resolve the statement completely- o --> Fail later My use case scenario: * I have a bunch of different projects built using Python * I want to use parts of it within a new project * I place them withina sub-folder (for example libs) within the new project using git submodule or just copy / link them there, whatever * I append the libs to path (sys.path.append) * Python WILL find the packages and basically import everything right * Problem: o if themain package does actually contain a toplevel folder that is named the same like one within the other modules (for example a "ui" submodule) python will search withon one and only one of these ui modules within exactly one project o Name clashes can only be avoided by renaming I know that this is propably not the suggested and best way to reuse existing code. But its the most straight-forward and keeps the fastest development cycle, which is I think is a reason Python grew so fast. At the time of writing I cannot think of any place where this change would destroy or change any already working code and I don't see a reason why the import would completely fail under this circumstances showing a different behaviour for top level fails and nth-level fails. What do you think about that hopefully very small change of the import behaviour? Thanks for your time reading and Best wishes, Richard

8 23

add a .with_stem() method to pathlib objects
by Ricky Teachey 30 Oct '19

30 Oct '19

This is obviously a small thing, but it would be nice to be able to say: >>> Path(r"C:\x.txt").with_stem("y") WindowsPath('C:/y.txt') Rather than having to do some variation of: >>> old_path = Path(r"C:\x.txt") >>> old_path.with_name("y"+old_path.suffix) WindowsPath('C:/y.txt') Or: >>> old_path = Path(r"C:\x.txt") >>> old_path.with_name("y"+old_path.suffix) WindowsPath('C:/y.txt') Or (god forbid): >>> (old_path := Path(r"C:\x.txt")).with_name("y"+old_path.suffix) WindowsPath('C:/y.txt') There are already .with_suffix() and with_name() methods. Including with_stem() seems obvious, no? --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler

6 13

Ability to specify function for auto-test in Enum and pass the given value as an argument to _generate_next_value_
by Steve Jorgensen 28 Oct '19

28 Oct '19

After messing around with `Enum` for a while, there's one small thing that I'd like to see improved. It seems limiting to me that the only way to trigger `_generate_next_value` is to pass `auto()`. What if, for a particular `Enum`, I would like to be able to use `()` as a shorthand for `auto()`? How about a more complex auto-generation that determines the final value based on both the given value and the name/key As an example of the second case, start with an `Enum` subclas in which each item, by default, has the name/key as its value and a prettified version of the name as its label, but one can also specify the value and label using a 2-item tuple for the value. Now, let's say we want to be able to specify a custom label and still use the name/key as the value either as a None/label tuple or as a string starting with a comma. Using a custom test for auto, one could identify those cases, Passing the assigned value to the `_generate_next_value_` function would allow it to make use of that information. For backward compatibility, the signature of the `_generate_next_value_` function can be checked to make sure it can accept the extra argument for that before passing that.

4 6

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas October 2019