Mailman 3 September 2023 - Python-ideas

Re: Extract variable name from itself
by Dom Grigonis 09 Nov '23

09 Nov '23

> the output will have the expression text This is exactly what I want. If there was an extra check for validity at parser level, it is a plus. > You want to produce a name, that is an identifier <https://docs.python.org/3/reference/lexical_analysis.html#identifiers>. Not necessarily, I want the first part of f’{expr=}’. There are outputs: a) `expr=repr(expr)` b) `repr(expr)` why is it a bad idea to have: c) `expr` without `repr(expr)`? This does cover `identifier only` case as well, but is not limited to it. Is it difficult to achieve? Apologies if I am missing something, but if you know the workings of python, could you point me to where f’{expr=}' is parsed and compiled? Obviously I might be wrong, but it is difficult to believe that it is done in such way, that I can have B, A&B, but not A without B. Would appreciate if you convinced me with some support for your rather strong statements. Regards, DG > On 23 Sep 2023, at 23:18, Tiago Illipronti Girardi <tiagoigirardi(a)gmail.com> wrote: > > I think I did something wrong and we are responding to one another instead of the list, please correct this if you can. > > Let's start with `f'{name=}'`. This is from the docs <https://docs.python.org/3/reference/lexical_analysis.html#f-strings> (the link has the docs for f-strings, so read it): > > When the equal sign '=' is provided, the output will have the expression text, the '=' and the evaluated value. Spaces after the opening brace '{', within the expression and after the '=' are all retained in the output. By default, the '=' causes the repr() <https://docs.python.org/3/library/functions.html#repr> of the expression to be provided, unless there is a format specified. When a format is specified it defaults to the str() <https://docs.python.org/3/library/stdtypes.html#str> of the expression unless a conversion '!r' is declared. > > That's not what you want. You want to produce a name, that is an identifier <https://docs.python.org/3/reference/lexical_analysis.html#identifiers>. The semantics of name binding are described here <https://docs.python.org/3/reference/executionmodel.html#naming-and-binding>. Which means that you cannot infer the name from the value. > Python only deals with values, not names. The names are how you refer to the values. That is the semantics. There's no inverse transformation embedded in the language. That's what everyone is trying to communicate to you. > If you pay close attention to the execution model <https://docs.python.org/3/reference/executionmodel.html#naming-and-binding> there is a link from the name to the object but not the other way around, so you can't get it from the object. That's it. You need to change the whole execution model (that is the interpreter) to get what you want > > Em sáb., 23 de set. de 2023 às 13:16, Dom Grigonis <dom.grigonis(a)gmail.com <mailto:dom.grigonis@gmail.com>> escreveu: > > >> On 23 Sep 2023, at 18:00, Tiago Illipronti Girardi <tiagoigirardi(a)gmail.com <mailto:tiagoigirardi@gmail.com>> wrote: >> >> The `f'{obj!fmt}'` syntax formats the `obj` with `repr` if `fmt` is `r`, with `str` if it is `s`, or with `ascii` if its `a`. >> With a new format `id` or `i` it would do nothing, but it could signal to an editor that it is an identifier (editors, I believe, already parse the contents of the curly brackets on f-strings). > I know the formatting syntax, I wasn’t clear what your point was. I see now that you are referring to new syntax which does nothing apart from signalling the editor. > > Your suggestion is leaning towards python adapting to the editor, while I would argue that things are simpler and more robust if editors treat code expression as code expression and strings as strings. Making a mess here does seem like too big of a cost for not so profound benefits of what I am proposing. > >> Identifiers are syntactical constructs in python, they only have semantics given a context, and more than one identifier can have the same semantic meaning in a given context, which makes your proposal a no-go from start. > Can you elaborate on this? > > Given f’{expr=}’ syntax already exists, how is this an issue for my proposal? > >> Except if we were to change the whole execution model of the language. > Although I am open to be proven wrong. Could you give an explanation why stripping `repr(expr)` part from f’{expr=}’ and leaving expr literal is problematic, given substituting expr literal is already being done? > > >> However, for the "change this identifier from this to that" case (which is an editor problem), subclassing `typing.LiteralString` would basically solve the problem: >> >> ``` >> x = 6 >> print(typing.Id('x') = f'{x}') >> ``` >> >> Or import Id from typing to save some keystrokes. >> >> With an interpreter change to the f-string we could do something like: >> >> ``` >> print(f'In this context {x!id} means the horizontal coordinate') >> ``` >> >> or without one and just changing the typing module: >> >> ``` >> print('In this context', typing.Id('x'), 'means the horizontal coordinate') >> ``` > I get all of the above, it just doesn’t seem elegant solution to a much more simpler approach that I am proposing. From my individual POV, the extra complication cost of your approach pretty much outweighs the subtle benefits of my proposal. > >> And with editor support, changing `x` to `y` would cleanly change the references to the variables/identifiers. >> But this use case is essentially impossible for the interpreter alone to solve: it needs editor support. > (above) > >> The other cases that you cite are kinda nonsensical (as I already wrote above). > No, you have just stated this (at least in this manner) for the first time. Care to explain how keeping dictionary keys in sync with identifiers or having extra syntactic via f-string construction check is “nonsensical”? I agree that these might not be the top practices, but given python is often used as a plugin / prototyping language, I would argue that some things are just plainly useful in certain cases. Python already allows many practices that are discouraged. This one would definitely be on a lower end of such risks. > >> Hope I was clear, and best regards >> >> Tiago I Girardi >> >> >> Em sáb., 23 de set. de 2023 às 10:53, Dom Grigonis <dom.grigonis(a)gmail.com <mailto:dom.grigonis@gmail.com>> escreveu: >> >>> On 23 Sep 2023, at 16:24, Tiago Illipronti Girardi <tiagoigirardi(a)gmail.com <mailto:tiagoigirardi@gmail.com>> wrote: >>> >>> but: >>> 1. There are costs doing it in python. And easy implementation doing it in editor (with the typing support it's almost already done). >> What are those costs? >> >>> 2. The f-string functionality is not there right now, but f'{name!id}' would leverage what is there and, with editor support, give the exact `nameof`` support even without further interpret support. >> What do you mean by f’{name!id}’ ? I don’t understand your point here. >> >> Are you proposing f’{name!id}’ syntax for it? My whole point is to do this in f-strings. >> >> Namely my proposal is f’{=expr}’. >> >> `nameof` function is out of the question - it has no benefits over f-string implementation. >> >>> The other use cases you mention are easily dealt with, assuming editor and typing.LiteralString (subclassed) support. >> Can you elaborate? I have only basic user knowledge about typing library and use it sparsely. >> >> But from what I know, tying this to typing does not seem like a good idea. It is very basic functionality and from my POV stands at lower level, while typing is optional feature and not everyone uses it or even needs to know it. >> >> DG >> —Evaluation of deferred evaluation can be deferred, but not indefinitely — >> >> >>> Em sáb., 23 de set. de 2023 às 09:51, Dom Grigonis <dom.grigonis(a)gmail.com <mailto:dom.grigonis@gmail.com>> escreveu: >>>> This is the only use case I can think of. >>> Yes, probably most common one, but I have mentioned couple more. >>> >>> 1. Keeping dictionary keys in sync with variable name. >>> 2. eval / exec statements. Although eval / exec are not recommended in high standard production code, python is widely used in plugins for various apps. E.g. Alfred / Sublime text, where exec/eval can be very useful. Why not have a method to do it a bit more robustly? >>> >>> Given python being flexible multipurpose interpreted language, I am sure more use cases would surface. >>> >>>> Couldn’t we just subclass typing.LiteralString to typing.Id or something for this “functionality” and let editing tools deal with it. >>> >>> “Could”, but: >>> 1. There are benefits doing it in python. And undesired costs of implementing this in editor (see my later e-mails) >>> 2. The f-string functionality for it is already there: >>> f'{a=}'.rstrip(f'{a}') >>> # or a bit better >>> f'{a=}'.split('=')[0] >>> # = exactly what I am proposing (Except the unneeded evaluation part) >>> So if it is already there, why not have it done well given there is little to none overall cost to it? I think cost implementing such things in Editor is much greater. >>> >>> Regards, >>> DG >> >

3 3

Re: Extract variable name from itself
by Eric V. Smith 28 Sep '23

28 Sep '23

5 23

Reconstructing datetime from microsecond timestamp
by Samuel Freilich 25 Sep '23

25 Sep '23

datetime.datetime has microsecond precision, and if you want to reconstruct a datetime from microseconds since the Unix epoch in a provided timezone, you can do: (datetime(1970, 1, 1, tzinfo=timezone.utc) + timedelta(microseconds=timestamp_us)).astimezone(tz) This is a general solution, but it constructs two extra datetimes and a timedelta on the way. datetime.fromtimestamp could bring that to just the one, but it takes float seconds, so there's no way to avoid losing precision (for far enough date in the future, but well short of datetime.max). One solution is to handle the micros separately: datetime.fromtimestamp(timestamp_us // 1000000, tz).replace(microsecond=timestamp_us % 1000000) This still requires constructing two datetimes, and it bakes in an assumption that the timezone offset doesn't affect and isn't affected by the millisecond component. (Which probably is the case! I think.) This might all be too much thought about edge cases that don't matter, but given the *_ns() functions in the time module (PEP 564), I'm curious why datetime doesn't have a constructor that takes an integer timestamp with the full precision that supports. Peace, -Sam

2 2

Re: Extract variable name from itself
by Pyrous 23 Sep '23

23 Sep '23

3 3

Extract variable name from itself
by Dom Grigonis 23 Sep '23

23 Sep '23

As far as I understand, it is not possible. Is it? Something similar to: var = 710 variable_name = [k for k, v in locals().items() if v == 710][0] print("Your variable name is " + variable_name) ,except robust. Possible ways to expose it: * builtin function `varname(obj: object) —> str` * object.__varname__ dunder (this one wouldn’t clutter general namespace) I am working on some code and just got to the point where it seems I could make use of it. The case is as follows: # What I do now: class A: defaults = dict() def set_default(self, a): self.defaults['a'] = a def make_something(self, a=None): a = a if a is not None else self.defaults.get('a') return Something(a) # What I would like to be able to do: class A: defaults = dict() def set_default(self, a): self.defaults[a.__varname__] = a def make_something(self, a=None): a = a if a is not None else self.defaults.get(a.__varname__) return Something(a) In this case I like second one, because it allows a tight coupling of variable names, which has the following benefits: 1. General simplification, where one doesn’t have to think variable name and its key value in dictionary. Code looks cleaner. 2. If one was to change a variable name of `set_default` it would immediately surface as an error. 3. For someone working with IDEs or making use of clever multiple selection tools, it would be easy to change all in one go. Any reasons why the above would not be a good practice? Any reasons why exposing it is not a good idea? Would this be difficult to achieve from python dev’s perspective? — This one can’t be solved with deferred eval :/ — Regards, DG

11 42

Revise using the colon ( : )
by Morteza Mirzakhan 20 Sep '23

20 Sep '23

Dear Python Developers, I would like to share my thoughts on the use of the colon mark “:” in Python code. In my opinion, using a colon after keywords such as `if`, `elif`, `else`, `for`, `while`, `try`, `except`, and `finally` is quite unnecessary. Using mandatory indentation in Python to group commands into a block is similar to how curly braces `{}` are used in ‘curly-bracket languages’ like C-family, Perl, Java, PHP, etc. to group multiple commands into a single statement. While those compilers don't differentiate between one or more ‘space’ or ‘return’ characters, so they don't recognize new lines and indents, the indentation is also used, not forced but traditionally, to increase readability. However, when it comes to writing just one instruction after the head command, you can omit the curly braces `{}` and simply write it in a new line, traditionally indented in C-family languages. So Python is one step forward by not requiring curly braces `{}` whether the block includes one or more lines. In contrast, the requirement to use a colon after those keywords in Python is a drawback! The colon “:” doesn't improve readability but adds unnecessary complexity, increases the potential for errors, and requires more effort to code. This is because the requirement does not have a logical meaning while the block is made obvious by indentation, so coders may forget to include the colon and face errors. This can be particularly frustrating for those who are used to coding in languages such as C and C++, where blocks of code are traditionally indented and no curly braces `{}` are used when the following tail is a singe-command instruction. The suggestion is removing the need by interpreter for the use of colon after keyword syntaxes (and making it optional due to Backward Compatibility) in the new revision of Python. I believe this change would make Python code easier to read, less prone to errors, and require less effort to code. Thank you for your time and attention. Best regards, Morteza Mirzakhan

4 7

Have del return a value
by Daniel Walker 12 Sep '23

12 Sep '23

Perhaps this is a solution in search of a problem but I recently encountered this situation in one of my projects. I have an object, foo, which, due to the references it contains, I'd rather not keep around longer than necessary. I use foo to instantiate another object: bar = Bar(foo) bar is free to manipulate foo however it wants and even del it if necessary. However, since the foo name is still around, those resources won't get cleaned up even if bar is done with them. The simple solution is bar = Bar(foo) del foo bar.do_stuff() I think it would be a nice (and, I hope, painless) addition to the Python grammar to have del return a reference to the underlying object. That way, I could simply do bar = Bar(del foo) What do y'all think? Juice not worth the squeeze? Dan

8 11