🌐 Mailman 3 May 2018 - Python-list - python.org

Re: f-string anomaly
by Ken Kundert May 14, 2018

May 14, 2018

Terry, Thanks for your response. I apologize about the double posting. I am well aware how doing so is bad form. My double posting was unintentional; it occurred when my news reader misbehaved. What I did in my code was to put double braces inside the format_spec, which the syntax specification in the f-string documentation does not allow, and so it should be a syntax error. But it does not generate a syntax error. So the question becomes, how does it interpret {{k}} and {{v}} in the format spec. I was expecting it to treat the double braces as escaped braces, and that is what the format method does. And by the last sentence in the following paragraph, it seems like f-strings should as well. Top-level format specifiers may include nested replacement fields. These nested fields may include their own conversion fields and format specifiers, but may not include more deeply-nested replacement fields. The format specifier mini-language is the same as that used by the string .format() method. > All names in the expression are resolved in the local namespace of the > f string. There are other differences. Nesting can only be one level > deep. I tried adding k and v to the local namespace: ... k = 6 v = 9 print(f'Email: {d:{{k}} {{v}}}') I still got: NameError: name 'k' is not defined I don't know where it is looking for k, but it is not in the local namespace. And I don't think the comment on nesting applies. The format string does not include nested references. Rather "{{k}} {{v}}" is meant to be treated as a literal string that should de-escaped and passed to the __format__ method, but no values should be interpolated. What the __format__ method does with the format spec is not in anyway restricted by the f string as long as __format__ returns a string. The comment that the mini-language is the same between the format method and the f string seems compelling to me. I think this is a bug. I think the f-string syntax should be updated to explicitly allow escaped braces in the format_spec, and the implementation of f-strings should be updated to be consistent with the syntax specification, and with the format method. -Ken On 05/13/2018 07:08 PM, Terry Reedy wrote: > On 5/13/2018 3:22 PM, Ken Kundert wrote: > > Please do not double post. > >> I am seeing an unexpected difference between the behavior of the string >> format method and f-strings. > > Read > https://docs.python.org/3/reference/lexical_analysis.html#formatted-string-… > carefully. > >> Here is an example: >> >> import sys, os >> from inform import error, os_error >> >> class mydict(dict): >> def __format__(self, template): >> print('Template:', template) >> return ', '.join(template.format(v, k=k, v=v) for k, v in >> self.items()) >> >> >> d = mydict(bob='239-8402', ted='371-8567', carol='891-5810', >> alice='552-2219') >> >> print('Using format():') >> print('Email: {0:{{k}}: {{v}}}'.format(d)) >> print() >> print('Using f-string:') >> print(f'Email: {d:{{k}} {{v}}}') >> print() >> print('Using f-string:') >> print(f'Email: {d:{{k}} {{v}}}', k=6, v=9) >> >> >> It generates the following response: >> >> Using format(): >> Template: {k}: {v} >> Email: bob: 239-8402, ted: 371-8567, carol: 891-5810, alice: >> 552-2219 >> >> Using f-string: >> Traceback (most recent call last): >> File "tryit", line 18, in <module> >> print(f'Email: {d:{{k}} {{v}}}') >> NameError: name 'k' is not defined > > This is what I expected. > >> Essentially I am using a format string as the template that indicates >> how to format each member of a dictionary, {{k}} should interpolate the >> key and {{v}} interpolates the value. This format string is embedded >> inside another format string, so the braces are doubled up so that they >> will be ignored by the outer format string. > > "The parts of the string outside curly braces are treated literally, > except that any doubled curly braces '{{' or '}}' are replaced with the > corresponding single curly brace. " note 'outside' > >> This idea seems to work okay when using the format() method. You can see >> I added a print statement inside __format__ that shows that the method >> is being called. >> >> However, trying the same idea with f-strings results in a NameError. It >> appears that the escaping does not work when used within the template. >> It appears the error occurs before __format__ is called (there is no >> output from the print function). >> >> Does anybody know why the format() method would work in this case but >> the f-string would not? > > All names in the expression are resolved in the local namespace of the f > string. There are other differences. Nesting can only be one level deep. > >> Is this a bug in f-strings? > > Not to me. > >

2 1

f-string anomaly
by Ken Kundert May 13, 2018

May 13, 2018

I am seeing an unexpected difference between the behavior of the string format method and f-strings in Python3.6. Here is an example: import sys, os from inform import error, os_error class mydict(dict): def __format__(self, template): print('Template:', template) return ', '.join(template.format(v, k=k, v=v) for k, v in self.items()) d = mydict(bob='239-8402', ted='371-8567', carol='891-5810', alice='552-2219') print('Using format():') print('Email: {0:{{k}}: {{v}}}'.format(d)) print() print('Using f-string:') print(f'Email: {d:{{k}} {{v}}}') print() print('Using f-string:') print(f'Email: {d:{{k}} {{v}}}', k=6, v=9) It generates the following response: Using format(): Template: {k}: {v} Email: bob: 239-8402, ted: 371-8567, carol: 891-5810, alice: 552-2219 Using f-string: Traceback (most recent call last): File "tryit", line 18, in <module> print(f'Email: {d:{{k}} {{v}}}') NameError: name 'k' is not defined Essentially I am using a format string as the template that indicates how to format each member of a dictionary, {{k}} should interpolate the key and {{v}} interpolates the value. This format string is embedded inside another format string, so the braces are doubled up so that they will be ignored by the outer format string. This idea seems to work okay when using the format() method. You can see I added a print statement inside __format__ that shows that the method is being called. However, trying the same idea with f-strings results in a NameError. It appears that the escaping does not work when used within the template. It appears the error occurs before __format__ is called (there is no output from the print function). Does anybody know why the format() method would work in this case but the f-string would not? Is this a but in f-strings? -Ken

1 0

Re: Leading 0's syntax error in datetime.date module (Python 3.6)
by bartc May 13, 2018

May 13, 2018

On 10/05/2018 19:51, Chris Angelico wrote: > On Fri, May 11, 2018 at 4:31 AM, bartc <bc(a)freeuk.com> wrote: >> 2x100 (4) Binary >> 3x100 (9) Ternary >> 4x100 (16) Quaternary >> 5x100 (25) etc >> 6x100 (36) >> 7x100 (49) >> 8x100 (64) Octal >> 9x100 (81) >> ... (Not implemented 11x to 15x, nor 10x or 16x) >> 0x100 (256) Hex > > YAGNI much? How often do you need a base-9 literal in your code?? I've used base-4 a couple of times, but not base 9 yet, excepting when toying with stuff. But you need to be able to print numbers in those bases too [not Python, or C]: a := 3x2222222222 # base-3 println a:"x9" # displays 8888 in base-9 It's interesting to see the patterns that arise when doing arithmetic in mixed bases. Anyway, those extra bases were easier to leave in than to exclude. -- bartc

3 3

Re: seeking deeper (language theory) reason behind Python design choice
by Marko Rauhamaa May 13, 2018

May 13, 2018

Chris Angelico <rosuav(a)gmail.com>: > But for the loop itself, you absolutely CAN write this more logically. > I'll take your second version as a template: > > def split_cmd(self, cmd): > args = [] > while (match := self.TERM_PTN.match(cmd)) is not None: > args.append(match.group('term')) > if not match.group('sep'): > verb = args.pop(0).upper() > return verb, args > cmd = cmd[match.end(0):] > return None, None > > And, if this is actually a regex, "is not None" is unnecessary: > > while match := self.TERM_PTN.match(cmd): > > Now do you understand what I mean about putting the condition into the > loop header? Thanks, but no thanks. The "while True" idiom beats that one hands down. As for the "is not None" test, I generally want to make it explicit because 1. that's what I mean and 2. there's a chance in some context of confusing None with other falsey values. Marko

5 13

Suggestion for a "data" object syntax
by Mikhail V May 12, 2018

May 12, 2018

Here is an idea for 'data object' a syntax. For me it is interesting, how would users find such syntax. I personally find that this should be attractive from users perspective. Main aim is more readable presenting of typical data chunks and some typical data types (tuples/lists) directly in code. Further this should significantly simplify typing. *Example 1. Multi-line strings* Here is a 3 lines multi-line string, it will be automatically 'dedented' by the parser by one level of indent: data === S : this is multi-line string escape chars: same as in strings (\\, \\n, \\t ...) , but "no need to 'escape' quotes" (Of course, assuming this feature will be added to the lexers of your editor, otherwise it may mess up syntax highlighting) So the proposed statement header is like: variable === "type" : ... The "===" token and type id's are of course subject to discussion. "type" is type of data, which tells the parser to convert data to specific type of Python object. The above is type "S", a multi-line string. *Example 2. Tuples* Tuple is a data block with normal Python elements. data === T : 1 2 3 "hello" a b c + d Here the separators of elements are : tab character, new line (and maybe some white-space character like em-space?) The above construct will be direct synonym for: data = (1, 2, 3, "hello", a, b, c + d) Benefits are easy to see: say I want a tuple of strings: data === T : "foo bar" "hello world" "to be continued..." VS current: data = ( "foo bar" , "hello world" , "to be continued..." , ) Main problem with the latter are commas, it is not easy to type and, whats more important - hard to notice missing commas. And brackets of course does not make it nicer either. The above are typical cases where I see clear win, and IMO they are quite common constructs. More complicated examples : *Example 3. Two-dimensional tuple.* data === T/T : 1 2 3 "hello" a b c + d e f is a synonym for: data = ( (1, 2, 3, "hello") , (a, b, c + d, e, f ) ) The rule here is: TAB character is inner elements' separator, and the new line is outer elements' separator. Line continuation character is \ (to help with long lines). *The benefits is just as in above examples : readability and 'typeability' boost.* To present nesting of elements of higher than 2 levels, normal Python syntax can be used for deeper nesting: data === T/T : 1 2 (3 4 5) a b c Or maybe even allow commas: data === T/T : 1 2 (3, 4, 5) a b c VS normal: data = ( (1, 2, (3, 4, 5) ) , (a, b, c ) ) So the idea is to cover only first two levels of nesting of course. Further, common types may be defined, like e.g. L/L (list of lists) but I don't want to go far into details and want to stop on common cases to help evaluate the idea in general. *Main rules: * - the definition is allowed only as a statement (no passing as argument) - (imo) data starts always as a new line after the header - implicit string concatenation disallowed So the question is, how do you like such syntax, and if so, what common examples can be fit in here. Any ideas, comments are of course welcome. Suggest some data and I'll try to express it in this syntax. M

7 24

Re: Leading 0's syntax error in datetime.date module (Python 3.6)
by bartc May 12, 2018

May 12, 2018

On 12/05/2018 05:29, Steven D'Aprano wrote: > On Fri, 11 May 2018 16:56:09 +0100, bartc wrote: > >> 0100, if not intended as octal, is >> an undetectable error in C and Python 2. > > How fortunate then that Python 2 is history (soon to be ancient history) > and people can use Python 3 where that error of judgement has been > rectified. At least you're agreeing it was a mistake. Although it does still mean that Python 3 has this funny quirk: a = 00000 # ok a = 00123. # ok a = int("00123") # ok a = 00123 # error -- bartc

1 0

Re: Leading 0's syntax error in datetime.date module (Python 3.6)
by Gregory Ewing May 12, 2018

May 12, 2018

Chris Angelico wrote: > Tack setuid onto "owner", setgid onto "group", and sticky > onto "others"? Pretty arbitrary, and disrupts the fundamental meaning > of each set. Yes, it would be totally silly if e.g. the "ls" command were to regroup them that way when displaying the permission bits... oh, wait... % echo > blarg.txt % chmod 7777 blarg.txt % ls -l blarg.txt -rwsrwsrwt 1 greg staff 1 12 May 20:40 blarg.txt -- Greg

2 1

Re: Leading 0's syntax error in datetime.date module (Python 3.6)
by Marko Rauhamaa May 12, 2018

May 12, 2018

Chris Angelico <rosuav(a)gmail.com>: > Octal makes a lot of sense in the right contexts. I think octal is a historical relic from a time when people weren't yet comfortable with hexadecimal. > Allowing octal literals is a Good Thing. I think it's just unavoidable mainly because of os.chmod. Marko

10 14

Re: Leading 0's syntax error in datetime.date module (Python 3.6)
by Gregory Ewing May 12, 2018

May 12, 2018

Steven D'Aprano wrote: > You had > computers with 6, 9, or even 60 bits per byte, And some early machines were even weirder, e.g. the EDSAC with effectively 17-bit words and 35-bit longwords. -- Greg

1 0

Re: Meaning of abbreviated terms
by Bob Martin May 12, 2018

May 12, 2018

in 793617 20180511 072806 Steven D'Aprano <steve+comp.lang.python(a)pearwood.info> wrote: >On Fri, 11 May 2018 07:20:36 +0000, Bob Martin wrote: > >> in 793605 20180511 044309 T Berger <brgrt2(a)gmail.com> wrote: >>>On Saturday, May 5, 2018 at 6:45:46 PM UTC-4, MRAB wrote: >>>> On 2018-05-05 17:57, T Berger wrote: >>>> > What does the "p" in "plist" stand for? Is there a python glossary >>>> > that spells out the meanings of abbreviated terms? >>>> > >>>> "plist" is "property list". It's listed in the Python documentation. >>> >>>Thanks for the answer. Missed it till now. >> >> In IBM-speak it was parameter list. > > > >But that's not where plists came from, was it? As I understand it, the >plist data format was invented by Apple, and they called it a property >list. How old is Apple? I was using plist for parameter list in OS/360 in 1965.

2 1