Python-ideas

python-ideas@python.org

38 participants
5327 discussions

by Steven D'Aprano

Inspired by this enhancement request: https://bugs.python.org/issue46393 I thought it might be time to revist the idea of a frozenset display. This has been discussed a few times before, such as here: https://mail.python.org/pipermail/python-ideas/2018-July/051902.html We have displays for the most important builtin data structures: - lists [1, 2, 3] - tuples (1, 2, 3) - dicts {1: 0, 2: 0, 3: 0} - sets {1, 2, 3} (as well as literals for ints, floats, strings and bytes) but not for frozensets. So the only way to guarantee that you have a frozenset is to explicitly call the builtin, which is not only a runtime call rather than a compile-time operation, but can be monkey-patched or shadowed. CPython already has some neat optimizations in place to use frozensets instead of sets, for example: >>> import dis >>> dis.dis("x in {1, 2, 3}") 1 0 LOAD_NAME 0 (x) 2 LOAD_CONST 0 (frozenset({1, 2, 3})) 4 CONTAINS_OP 0 6 RETURN_VALUE and the compiler can build frozensets of literals as a constant. Ironically, this means that actually making a frozenset explicitly does far more work than needed: >>> dis.dis("frozenset({1, 2, 3})") 1 0 LOAD_NAME 0 (frozenset) 2 BUILD_SET 0 4 LOAD_CONST 0 (frozenset({1, 2, 3})) 6 SET_UPDATE 1 8 CALL_FUNCTION 1 10 RETURN_VALUE Got that? To create a frozenset of literals, first the compiler creates a frozenset constant containing what you wanted. Then at runtime, it: - looks up frozenset in globals and builtins; - loads the pre-prepared frozenset (which is exactly what we want); - creates a new set from that frozenset; - calls the frozenset() function on that set to create a new frozenset that duplicates the pre-prepared one; - and finally garbage-collects the temporary set. So to get the frozenset we want, we start with the frozenset we want, and make an unnecessary copy the long way o_O If you didn't know that every step in that song and dance routine was necessary, it would seem ludicrously wasteful. If we had a frozenset display, we could avoid most of that work, optimizing that down to a LOAD_CONST like this: >>> dis.dis('(1, 2, 3)') 1 0 LOAD_CONST 0 ((1, 2, 3)) 2 RETURN_VALUE It seems to me that all of the machinery to make this work already exists. The compiler already knows how to create frozensets at compile-time, avoiding the need to lookup and call the frozenset() builtin. All we need is syntax for a frozenset display. How does this work for you? f{1, 2, 3} -- Steve

16 hours, 11 minutes

'frozen set' discussion - please consider taking some time off.

by C. Titus Brown

Hi all, python-ideas moderator here. It’d be great if y’all could take a few days to cool off the frozen set discussion, which is veering off the rails a little bit into emotional language. I’ll keep an eye on it and put emergency moderation into effect if I must, but it’d be nicer if I didn’t feel the need to do that. thanks, —titus

5 days, 14 hours

Allowing non-ASCII bracket and quote characters in source code

by John Sturdy

Perhaps the time isn't ripe for this, and perhaps it never will be, but UTF8 seems to be handled by just about everything these days. I suspect this is a crazy suggestion, but on the other hand perhaps people looking back from 2100 will think "It was crazy that they stuck exclusively with ASCII syntax characters for so long after Unicode was widely available". Sometimes when you have quite a few levels of brackets, and there are more than one of the same type, might it be better to allow variants of each type of bracket character? Unicode provides bold, double, small, superscript, subscript, and white-filled (hollow) variants of round, square and curly brackets, and top and bottom ticked variants of square brackets. Perhaps not enough platforms will be able to display them? And entering them may be fiddly, although programmable editors and IDEs could let you type the standard characters but pick variants on a round-robin basis within each expression. But it might be handled better in the display in editors and IDEs (perhaps syntax coloring brackets by their depth). Or some might say not to write such deeply nested bracketed expressions. Implementation parsers could simply translate all the brackets to the base types, or they could treat them as equivalent but distinct, and check that the open and close brackets match, which might catch a few errors. There are also other quote characters available, such as the guillemets traditionally used in French. There's absolutely no need to use such things, but for people working on code which will be used internally in, say, French or Quebecois organizations might welcome it. OK, shoot this one down now :-)

5 days, 22 hours

Re: Revisiting a frozenset display literal

by Steven D'Aprano

On Wed, Jan 19, 2022 at 01:56:54PM +0100, Marco Sulla wrote: > PEP 351 for the frozen protocol was rejected. I didn't read why, but > it's probably hard to resurrect. This is not a proposal for a generic frozen protocol. It is a simple proposal for a set method that returns a frozenset, with the aim that the peephole optimiser will be able to optimise the call out for set displays consisting only of literals. -- Steve

1 week

Re: Revisiting a frozenset display literal

by Steven D'Aprano

On Wed, Jan 19, 2022 at 02:20:06PM +0100, Marco Sulla wrote: > I can understand, but if you do it for set, why not for list, > bytearray... And so it becomes a sort of protocol for freezing > objects. YAGNI. If you want a frozen list, you can already write that as a tuple. There is no need to do: [1, 2, 3].frozen() when you can just write `(1, 2, 3)`. Same for bytearray and bytes. We already have display or literal syntax for frozen lists and frozen bytearrays. It is only frozensets which don't, and since people cannot agree on syntax for a frozenset display, we're stuck with approaching it side-ways: a method call which, if applied to a set display of literals, could be safely optimized out by the compiler. The rest of the time, someset.frozen() would just call frozenset. -- Steve

1 week

Allow syntax "func(arg=x if condition)"

by Peter O'Connor

I often find that python lacks a nice way to say "only pass an argument under this condition". (See previous python-list email in "Idea: Deferred Default Arguments?") Example 1: Defining a list with conditional elements include_bd = True current_way = ['a'] + (['b'] if include_bd else [])+['c']+(['d'] if include_bd else []) new_way = ['a', 'b' if include_bd, 'c', 'd' if include_bd] also_new_way = list('a', 'b' if include_bd, 'c', 'd' if include_bd) Example 2: Deferring to defaults of called functions def is_close(a, b, precicion=1e-9): return abs(a-b) < precision def approach(pose, target, step=0.1, precision=None): # Defers to default precision if not otherwise specified: velocity = step*(target-pose) \ if not is_close(pose, target, precision if precision is not None) \ else 0 return velocity Not sure if this has been discussed, but I cannot see any clear downside to adding this, and it has some clear benefits (duplicated default arguments and **kwargs are the scourge of many real world code-bases)

1 week

mimetypes.guess_type should not return deprecated mimetype application/x-javascript

by milahu＠gmail.com

mimetypes are parsed from the file /etc/mime.types cat /etc/mime.types | grep javascript application/javascript js application/x-javascript js actual: mimetypes.guess_type("x.js") == "application/x-javascript" -> deprecated mimetype expected: mimetypes.guess_type("x.js") == "application/javascript" spoiler: here, the "x-" part is deprecated. mimetypes.guess_type returns the deprecated mimetype because python returns the last entry in the /etc/mime.types file which is sorted alphabetically proposed solution: use a smarter conflict-resolution when parsing /etc/mime.types. when two entries are found for one file-extension, avoid using a deprecated mimetype. rfc4329 lists 16 items for "unregistered media type" these could be hard-coded as set-of-strings, or as regex. related bug report https://bugs.python.org/issue46035 mimetypes.guess_type https://docs.python.org/3/library/mimetypes.html#mimetypes.guess_type unregistered media type https://datatracker.ietf.org/doc/html/rfc4329#section-3

1 week, 1 day

Limit scope of variables using round brackets

by Iyad Ahmed

Example use cases: - Loop variables and similar, it is sometimes more comfortable to scope it to the loop body only - Not having to name variables var1, var2, var3, or makeup unnecessarily unique variable names, in some situations In other languages the curly bracket is used, in Python round brackets might fit more in the syntax. I don’t have much experience with the implementation of Python, so not sure if there’s a technical reason against such idea, feedback is very appreciated Best regards, Iyad Ahmed Email: iyadahmed(a)cgonfire.com Socials: Twitter <https://twitter.com/cgonfire> GitHub: https://github.com/iyadahmed

1 week, 2 days

Shouldn't 'input' prompt be going to stderr?

by MRAB

There was a discussion on another forum that mentioned the 'input' function, and it made me wonder whether 'input' should be printing the prompt to stderr instead of stdout. The convention is for normal output to go to stdout and error messages to go to stderr, so if a program needs to ask the user, shouldn't it be using stderr for prompts in order not to mess up the normal output?

1 week, 3 days

PEP Idea: Better return type annotation syntax

by Tushar Sadhwani

With the recent submission of [PEP 677][1], I was reminded of an idea I had with function annotation syntax since the very beginning: why not let me write: ```python def f() -> tuple[int, str]: return 42, 'foo' ``` as: ```python def f() -> (int, str): return 42, 'foo' ``` Is there any inherent reason for this, other than that it isn't an actual "type"? I think it looks much cleaner, and if there isn't any drawbacks to adding this syntax, I'd love to work on bringing this to life. [1]: https://www.python.org/dev/peps/pep-0677/

1 week, 3 days

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas