Mailman 3 February 2021 - Python-ideas

Arrow functions polyfill
by Paul Sokolovsky 11 Mar '21

11 Mar '21

Hello, On Fri, 12 Feb 2021 18:26:53 +1100 Chris Angelico <rosuav(a)gmail.com> wrote: > On Fri, Feb 12, 2021 Paul Sokolovsky <pmiscml(a)gmail.com> wrote: > > ... And on the 2nd thought, that won't work. The reason it works in > > JS is that it doesn't have tuples. In Python, "(a, b) => (1, 2)" > > means "compare a tuple for greater-or-equal". > > Should be safe actually - "=>" is not a valid comparison operator. To punish myself for making such stupid mistakes, I volunteered to implement PoC of that. And by long honorable tradition, improvements to Python get implemented in Python first. So with my "imphook" thingy https://pypi.org/project/imphook/, and with the hook module at the end, following works as expected: =========== $ cat example_arrow_func.py f = (a, b) => a + b print(f(1, 2)) res = ((a, b) => a + b)(3, 4) print(res) print(list(map((x) => x * 2, [1, 2, 3, 4]))) # Confirm there's no crashing on bare tuple at the tail of file. (1, 2) $ python3 -m imphook -i mod_arrow_func -m example_arrow_func 3 7 [2, 4, 6, 8] =========== The implementation was written a bit cowboyishly in 15 mins, maybe, just maybe, you can still crash it. (For example, it clearly doesn't support newlines in arrow param list): ===== mod_arrow_func.py ====== import sys import tokenize import imphook class TokBuf: def __init__(self): self.tokens = [] def append(self, t): self.tokens.append(t) def clear(self): self.tokens.clear() def empty(self): return not self.tokens def spool(self): yield from self.tokens self.clear() def xform(token_stream): tokbuf = TokBuf() for t in token_stream: if t[1] == "(": # We're interested only in the deepest parens. if not tokbuf.empty(): yield from tokbuf.spool() tokbuf.append(t) elif t[1] == ")": nt1 = next(token_stream) nt2 = next(token_stream) if nt1[1] == "=" and nt2[1] == ">": yield (tokenize.NAME, "lambda") yield from tokbuf.tokens[1:] tokbuf.clear() yield (tokenize.OP, ":") else: yield from tokbuf.tokens tokbuf.clear() yield t yield nt1 yield nt2 elif not tokbuf.empty(): tokbuf.append(t) else: yield t def hook(modname, filename): with open(filename, "rb") as f: # Fairly speaking, tokenizing just to convert back to string form # isn't too efficient, but CPython doesn't offer us a way to parse # token stream so far, so we have no choice. source = tokenize.untokenize(xform(tokenize.tokenize(f.readline))) mod = type(imphook)(modname) exec(source, vars(mod)) return mod imphook.add_import_hook(hook, (".py",)) =========== -- Best regards, Paul mailto:pmiscml@gmail.com

23 62

PEP 9999 (provisional): support for indexing with keyword arguments
by Stefano Borini 10 Mar '21

10 Mar '21

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 barely understood the syntax of the old one, but have no idea about the new one) and review my code I can give it a try. I would not mind refreshing my C a bit. -- Kind regards, Stefano Borini

20 100

A shortcut to load a JSON file into a dict : json.loadf
by The Nomadic Coder 10 Mar '21

10 Mar '21

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 issue by defining this in the cpython? I don't whipping up a PR if it gains traction.

22 67

SimpleNamespace vs object
by Sven R. Kunze 02 Mar '21

02 Mar '21

Starting this as a new thread for the interested reader: On 17.02.21 11:18, Chris Angelico wrote: > On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze <srkunze(a)mail.de> wrote: >> Still think that "object()" should be writable since this seems like an >> arbitrary restriction (+SimpleNamespace is no builtin and at least I >> would use object() for fast PoCs or dirty hackery). But I guess there's >> been discussion around this already. >> [...] > Using SimpleNamespace is the best way to do this, and maybe there's a > good argument for making it a builtin (or at least giving it a shorter > name), but changing object would be problematic. I would be skeptical that either those ideas would help a lot. My reasoning is the following: Given the usual terminology in computer science and programming courses, we think in "objects". "Namespaces" on the other side are quite static, usual representing surroundings or environments which in turn can contain "objects". Sadly, the terminology-wise ideal solution is blocked by technical reasons. The thinking in the concepting use-case goes like "I need a blank object which I can do random things with" (yes, including attaching new attributes to it, maybe other stuff as well). The thinking "hey I need a (simple) namespace which I can attach attributes to" requires quite some thoughts especially when being in a more "concepting"/"trying out ideas" mood. In this phase, one does not simply know what one needs ("could be sentinel only", "could be data carrying", "could be signalling", "could something else") and things move quickly. So, just as an example when renaming/aliasing "types.SimpleNamespace" to "builtins.thing", my expectation would be that people could be horribly confused seeing "object" and "thing" being a builtin when used in a project simultaneously. This always leads to questions like "what to use now?" As a conclusion I would say let's leave it like it is since it's a minor issue. Best Sven

19 44

Have virtual environments led to neglect of the actual environment?
by Random832 01 Mar '21

01 Mar '21

I was reading a discussion thread <https://gist.github.com/tiran/2dec9e03c6f901814f6d1e8dad09528e> about various issues with the Debian packaged version of Python, and the following statement stood out for me as shocking: Christian Heimes wrote: > Core dev and PyPA has spent a lot of effort in promoting venv because we don't want users to break their operating system with sudo pip install. I don't think sudo pip install should break the operating system. And I think if it does, that problem should be solved rather than merely advising users against using it. And why is it, anyway, that distributions whose package managers can't coexist with pip-installed packages don't ever seem to get the same amount of flak for "damaging python's brand" as Debian is getting from some of the people in the discussion thread? Why is it that this community is resigned to recommending a workaround when distributions decide the site-packages directory belongs to their package manager rather than pip, instead of bringing the same amount of fiery condemnation of that practice as we apparently have for *checks notes* splitting parts of the stdlib into optional packages? Why demand that pip be present if we're not going to demand that it works properly? I think that installing packages into the actual python installation, both via distribution packaging tools and pip [and using both simultaneously - the Debian model of separated dist-packages and site-packages folders seems like a reasonable solution to this problem] can and should be a supported paradigm, and that virtual environments [or more extreme measures such as shipping an entire python installation as part of an application's deployment] should ideally be reserved for the rare corner cases where that doesn't work for some reason. How is it that virtual environments have become so indispensable, that no-one considers installing libraries centrally to be a viable model anymore? Are library maintainers making breaking changes too frequently, reasoning that if someone needs the old version they can just venv it? Is there some other cause?

13 20

argparse: mutually inclusive arguments
by Paul Korir 26 Feb '21

26 Feb '21

Hi All, I've been using the argparse library for a long time and one use case that repeatedly shows us is the need to have two arguments appear together i.e either both appear or none of them appear. I'll refer to these as *mutually inclusive* in contrast to the existing *mutual exclusive* feature present. I might be wrong but there seems to be no way to enforce this. Of course it is possible to have two arguments that are *required* but it's not always the case that they will be needed. A more relevant example would be a situation in which you have a set of mutually exclusive arguments, one of which is a group of arguments. For example, consider a scenario in which a user is required to enter multiple related files that share the same file root (excluding the extension). The program would then infer the various files (co-files) by searching for the extensions. The first option would have the user only need to provide the file name root. However, the user may also provide the paths to the various co-files. In this case, the co-files must occur together but must occur mutually-exclusively from the file root option. Another example would be a case in which activating one set of options implies the need for other options to be simultaneously activated and for which defaults may not be easily discerned. Quite often the author has to perform pythonic gymnastics to catch such invalid options, which might be better handled by the argparse library. In evaluating the need for this I've come across the following responses: https://stackoverflow.com/questions/15935092/creating-mutually-inclusive-po… https://bugs.python.org/issue11588 https://bugs.python.org/issue23298 https://stackoverflow.com/questions/19414060/argparse-required-argument-y-i… https://www.debugcn.com/en/article/57242307.html https://picocli.info/#_mutually_dependent_options I perceive there is a compelling use-case to be addressed here despite an earlier request being turned down. With kind regards, *Paul*

5 5

Deprecate/change the behaviour of ~bool
by Soni L. 24 Feb '21

24 Feb '21

Currently ~False is -1 and ~True is -2. Would be nicer if ~bool was the same as not bool. Hopefully nobody actually relies on this but nevertheless, it would be a backwards-incompatible change so the whole deprecation warnings and whatnot would be required. In particular, this is nice for xnor operator: a ^~ b. This currently works on ints, but not on bools, while most other operators, including xor, do successfully work on bools.

8 15

Re: [Python-Dev] Re: Have virtual environments led to neglect of the actual environment?
by Random832 24 Feb '21

24 Feb '21

I accidentally removed Python-Ideas from the recipient list while posting this reply. On Wed, Feb 24, 2021, at 09:16, Random832 wrote: > On Wed, Feb 24, 2021, at 06:27, Christian Heimes wrote: > > Separate directories don't prevent clashes and system breakage. But they > > provide an easy way to *recover* from a broken system. > > I think it could be turned into a way to prevent them by A) having > site-packages always take precedence over dist-packages [i believe this > is already the case] in normal usage and B) providing an option to the > interpreter, used by system scripts, to exclude site-packages entirely > from the path. > > Basically, site-packages would effectively be layered on top of "Lib + > dist-packages" in a similar way to how a venv is layered on top of the > main python installation - the inverse of the suggestion someone else > in the thread made for the system python to be a venv. This wouldn't > *exactly* be a venv because it wouldn't imply the other things that > entering a venv does such as "python" [and script names such as pip] > being an alias for the correct version of python, but it would provide > the same kind of one-way isolation, whereby the "system environment" > can influence the "normal environment" and not vice-versa, in the same > way that packages installed in the main installation affect a venv > [unless system-site-packages is disabled] but the venv obviously has no > effect on the main installation.

1 0

Re: [Python-Dev] Re: Have virtual environments led to neglect of the actual environment?
by Henk-Jaap Wagenaar 24 Feb '21

24 Feb '21

On Wed, 24 Feb 2021 at 10:18, Antoine Pitrou <antoine(a)python.org> wrote: > On Tue, 23 Feb 2021 20:29:52 -0500 > Jonathan Goble <jcgoble3(a)gmail.com> wrote: > > > > I can't speak for distributors or maintainers [1], but I can speak for > > myself as a user. I run Debian testing (currently bullseye as that is > > preparing for release) as my daily OS on my personal laptop, used for > > personal matters and school assignments (I'm a university computer > > science student in my senior year). > > > > I don't use the system Python for anything of my own, whether it's a > > school assignment or a personal project, precisely because I don't > > want to risk screwing something up. Rather, I maintain a clone/fork of > > the official CPython GitHub repo, and periodically build from source > > and `make altinstall` into `~/.local/`. > > For the record, instead of building Python by hand, you could use a > distribution such as Anaconda or the community-maintained conda-forge. > > Regards > > Antoine. > > I've been using pyenv (on MacBooks to be fair, not Linux/Debian) and been quite happy with that, and it basically does what Jonathan does manually: clone the github repo and build python from scratch.

2 1

Alternate lambda syntax
by J. Pic 23 Feb '21

23 Feb '21

Hi all, Lambdas can be defined as such: w = lambda: [12] x = lambda y: len(y) I'd like to propose the following: w = (): [12] x = (y): len(y) Or even another contraction for when there are no arguments: w =: [12] This would also be consistent with the other proposal on anonymous functions for defaults: https://mail.python.org/pipermail/python-list/2021-February/900795.html -- ∞

26 66