I like the idea of an scans like ability, but I"m afraid the existing
format language is poorly suited to that.
It's simply no designed to be a two-way street:
* ANYTHING can be stringified in Python -- so there is no defined way to
turn a string back into a particular type.
OK, so we restrict ourselves to builtins -- how would you reverse this:
In [17]: x, y, z = 23, 45, 67
In [18]: f"{x}{y}{z}"
Out[18]: '234567'
so we require a type specifier, but similar problem:
In [19]: f"{x:d}{y:d}{z:d}"
Out[19]: '234567'
So we require a field size specifier:
In [20]: f"{x:2d}{y:2d}{z:2d}"
Out[20]: '234567'
OK, I guess that is clearly defined. but we've now limited ourselves to a
very small subset of the formatting language -- maybe it's not the right
language for the job?
-CHB
On Thu, Sep 17, 2020 at 1:08 PM Alex Hall
On Thu, Sep 17, 2020 at 9:50 PM Ricky Teachey
wrote: On Thu, Sep 17, 2020 at 3:44 PM Alex Hall
wrote: On Thu, Sep 17, 2020 at 9:27 PM Ricky Teachey
wrote: A difficulty I have with the idea as presented is this.
If I can say this:
"{x:d} {y:d} {z:d}" = "1 2 3"
...thus assigning 1, 2, 3 to x, y, z respectively, I might want to also do the same thing this way:
q = "{x:d} {y:d} {z:d}" q = "1 2 3"
The intent being: save the f-string as a variable, and then use it to assign later. But that can obviously never work because q would just become the string "1 2 3" .
The same problem exists for assignments to tuples, subscripts, attributes, even plain variables. I've often wanted to put an assignment target in a variable.
Feels to me akin to what Einstein called spooky action at a distance. ;)
# module A x = f"{a:d}"
# module B x.parse("1") assert a == 1
This seems like a joke I would want to play on someone*, not a useful feature.
* well, if i were a bad person... ;)
I'm not actually proposing being able to store assignment targets in variables. I'm saying the hypothetical misconception you bring up already exists for every other kind of thing that can be assigned to, because they all intentionally look like expressions. I don't think I've ever seen learners be confused about this. I don't think it's a good argument against the proposal. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JZQ5BN... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython