date:20180513

Re: f-string anomaly

2018-05-13 Thread Ken Kundert

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-literals
> 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 
>>  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.
> 
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

random.choices() Suggest that the code confirm that cum_weights sequence is in ascending order

2018-05-13 Thread Paul

Hi,
  I just learned how to use random.choices().  I initially misunderstood
the documentation for cum_weights as meaning that a cumulative sequence
would be *constructed from* the sequence which I supplied.  Consequently, I
specified 'cum_weights' with a sequence which wasn't in ascending order.  I
got back k results but I determined that they weren't correct (eg, certain
population values were never returned).

  Since the non-ascending sequence, which I had supplied, could not
possibly be valid input, why isn't this checked (and an error returned)?
 Returning incorrect results (which could be hard to spot as being
incorrect) is much more dangerous.  Also, checking that the list is in
ascending order need only be done once, and seems like it would be
inexpensive.

  Thanks,
  Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33479] Document tkinter and threads

2018-05-13 Thread Ivan Pozdeev

Ivan Pozdeev added the comment:

I was composing a letter to python-dev with all I know of how tkinter works
with regard to threads and Tcl, and the fixing plans so that we're all on the
same page if you wish to participate.

I'm no longer sure if it belongs in the mailing list so see it in the
attachment.

The plan I have for fixing the documentation is there towards the end.
It includes what you suggested but is more detailed. I'll recite it below:

---

* Document the current behaviour by rewriting
https://docs.python.org/3/library/tkinter.html .

Since I've recently learned Tkinter, I can say which critical information is
missing and which existing one proved useless.

Principles:

* include fundamental information critical to understand the module's
behaviour
* concentrate on reference documentation for the module because it's more
important to have than a user guide (
https://meta.serverfault.com/questions/8934/what-to-do-with-questions-when-the-answer-is-in-a-man-page#comment22241_8938
)
* split off/drop anything unrelated to the above two

Resulting scheme:

0. Intro: +supported Tcl/Tk versions and the two flavors; the fact that
Tkinter adds its own logic, and the Tkinter doc concentrates on that logic and
refers to Tcl/Tk docs for details that are taken from there without changes.

* Move external links section to be bottom.

1. Architecture. "Unlike most other GUI toolkits, Tcl/Tk consists of a few
separate modules with a clear distinction between them, and this is
non-transparect to the user:..." Base on
https://docs.python.org/3/library/tkinter.html#how-tk-and-tkinter-are-related ,
but focus on what implements what rather than what _calls_ what; drop Xlib
entry (transparent implementation detail, not required for understanding).

2. Threading model. The above-described general idea and user-visible
limitations what can be called where and when. (the letter has details that
this refers to, too long to recite)

3. References for `tkinter`, `tkinter.Tk()`, `_tkinter.Tkapp` (public
interface only -- `call()` at least). Mention which functions cannot be called
from other threads. Do not mention the two issue33257 bugs.

* Move widget reference to another page.
* Drop Python-Tcl mappings unless the reference sections need them as
supplemental reference.
* Drop tutorial: too primitive to be useful. Move tutorials to another page
like https://docs.python.org/3/library/logging.html does.
* Drop https://docs.python.org/3/library/tk.html -- proved hard to find.
Make https://docs.python.org/3/library/tkinter.html the head page instead.

* Discuss which of the described behaviour is as intended and which is a bug.
Proceed with fixing.

--
assignee: -> docs@python
components: +Documentation
nosy: +Ivan.Pozdeev, docs@python
Added file: https://bugs.python.org/file47586/[Python-Dev] Tkinter threading
model description and fix plan.eml

___
Python tracker

___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

70 matches

Mail list logo