Mailman 3 January 2019 - Python-ideas

Re: [Python-ideas] NAN handling in the statistics module
by Steven D'Aprano 08 Jan '19

08 Jan '19

On Tue, Jan 08, 2019 at 04:25:17PM +0900, Stephen J. Turnbull wrote: > Steven D'Aprano writes: > > > By definition, data containing Not A Number values isn't numeric :-) > > Unfortunately, that's just a joke, because in fact numeric functions > produce NaNs. I'm not sure if you're agreeing with me or disagreeing, so I'll assume you're agreeing and move on :-) > I agree that this can easily be resolved by documenting that it is the > caller's responsibility to remove NaNs from numeric data, but I prefer > your proposed flags. > > > The only reason why I don't call it a bug is that median() makes no > > promises about NANs at all, any more than it makes promises about the > > median of a list of sets or any other values which don't define a total > > order. > > Pedantically, I would prefer that the promise that ordinal data > (vs. specifically numerical) has a median be made explicit, as there > are many cases where statistical data is ordinal. I think that is reasonable. Provided the data defines a total order, the median is well-defined when there are an odd number of data points, or you can use median_low and median_high regardless of the number of data points. > This may be a moot > point, as in most cases ordinal data is represented numerically in > computation (Likert scales, for example, are rarely coded as "hate, > "dislike", "indifferent", "like", "love", but instead as 1, 2, 3, 4, > 5), and from the point of view of UI presentation, IntEnums do the > right thing here (print as identifiers, sort as integers). > > Perhaps a better way to document this would be to suggest that ordinal > data be represented using IntEnums? (Again to be pedantic, one might > want OrderedEnums that can be compared but don't allow other > arithmetic operations.) That's a nice solution. -- Steve (the other one)

1 0

Possible PEP regarding the use of the continue keyword in try/except blocks
by Simon 07 Jan '19

07 Jan '19

I was writing some python code earlier, and I noticed that in a code that looks somwhat like this one : try: i = int("string") print("continued on") j = int(9.0) except ValueError as e: print(e) >>> "invalid literal for int() with base 10: 'string'" this code will handle the exception, but the code in the try block will not continue. I propose to be able to use the continue keyword to continue the execution of the try block even when an error is handled. The above could then be changed to : try: i = int("string") print("continued on") j = int(9.0) except ValueError as e: print(e) continue >>> "invalid literal for int() with base 10: 'string'" >>> "continued on"

13 16

Re: [Python-ideas] NAN handling in the statistics module
by Tim Peters 06 Jan '19

06 Jan '19

[David Mertz <david.mertz(a)gmail.com>] > Thanks Tim for clarifying. Is it even the case that sorts are STABLE in > the face of non-total orderings under __lt__? A couple quick examples > don't refute that, but what I tried was not very thorough, nor did I > think much about TimSort itself. I'm not clear on what "stable" could mean in the absence of a total ordering. Not only does sort not assume __lt__ is a total ordering, it doesn't assume it's transitive, or even deterministic. We really can't assume anything about potentially user-defined functions. What sort does guarantee is that the result list is some permutation of the input list, regardless of how insanely __lt__ may behave. If __lt__ sanely defines a deterministic total order, then "stable" and "sorted" are guaranteed too, with their obvious meanings.

3 4

Re: [Python-ideas] NAN handling in the statistics module
by David Mertz 06 Jan '19

06 Jan '19

[... apologies if this is dup, got a bounce ...] > [David Mertz <mertz(a)gnosis.cx>] >> I have to say though that the existing behavior of `statistics.median[_low|_high|]` >> is SURPRISING if not outright wrong. It is the behavior in existing Python, >> but it is very strange. >> >> The implementation simply does whatever `sorted()` does, which is an >> implementation detail. In particular, NaN's being neither less than nor >> greater than any floating point number, just stay where they are during >> sorting. > > I expect you inferred that from staring at a handful of examples, but > it's illusion. Python's sort uses only __lt__ comparisons, and if > those don't implement a total ordering then _nothing_ is defined about > sort's result (beyond that it's some permutation of the original > list). Thanks Tim for clarifying. Is it even the case that sorts are STABLE in the face of non-total orderings under __lt__? A couple quick examples don't refute that, but what I tried was not very thorough, nor did I think much about TimSort itself. > So, certainly, if you want median to be predictable in the presence of > NaNs, sort's behavior in the presence of NaNs can't be relied on in > any respect. Playing with Tim's examples, this suggests that statistics.median() is simply outright WRONG. I can think of absolutely no way to characterize these as reasonable results: Python 3.7.1 | packaged by conda-forge | (default, Nov 13 2018, 09:50:42) In [4]: statistics.median([9, 9, 9, nan, 1, 2, 3, 4, 5]) Out[4]: 1 In [5]: statistics.median([9, 9, 9, nan, 1, 2, 3, 4]) Out[5]: nan

1 0

Fixed point format for numbers with locale based separators
by Stefan Krah 06 Jan '19

06 Jan '19

Eric V. Smith wrote: > If the locale character is "*", use locale-aware formatting for the > given "type", with LC_NUMERIC. So, "*g" would be equivalent to the > existing "n", and "*f" would give you the current "f" formatting, except > using LC_NUMERIC for the decimal point. If the locale character is "$" > use locale-aware LC_MONETARY. So then we could use "$g", "$f", etc. > These locale characters would also work with int, so "*d" would make "n" > obsolete (but I'm not proposing to remove it). +1. I also think it's best to have a modifier and cover all cases. > But it's probably worth keeping '#' orthogonal to the locale character. > Maybe someday we'll want to use them together. Yes, somehow it feels right to keep them separate, even if we never use them together. > I think it might also require a PEP, but it would be as simple as > PEP 378 for adding comma grouping formatting. Somewhere to memorialize > the decision and how we got there, including rejected alternate > proposals, would be a good thing. It would be nice (if anyone wants to do the work), but your proposal is already perfect for me. I like the "*" and "$" choices. Stefan Krah

1 0

回复：Python-ideas Digest, Vol 146, Issue 13
by Moon丶sun 05 Jan '19

05 Jan '19

Thanks for your reply.But the answer is not I except, I will show you some examples to explain what result I except: @contextmanagerdef cm(): print('open file') yield print('close file')with cm(): 1/0 If I use a contextmanager ,I except it can help me to close the file anytime,even raise an error,but if I define a function with @contextmanager like the example which I have showed for you, it will never print('close file') I can only modify it like this:@contextmanagerdef cm(): try: print('open file') yield except Exception as e: print('Error',e) finally: print('close file') It is not friendly for us to use it, so I modify the contextlib to fix it,you can catch it from the e-mail attachment.It's in the line 79 and line 97---------------------------------------------------------------------- 发件人：python-ideas-request(a)python.org 收件人：python-ideas(a)python.org 主题：Python-ideas Digest, Vol 146, Issue 13 日期：2019年01月06日 01点05分 Send Python-ideas mailing list submissions to python-ideas(a)python.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.python.org/mailman/listinfo/python-ideas or, via email, send a message with subject or body 'help' to python-ideas-request(a)python.org You can reach the person managing the list at python-ideas-owner(a)python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-ideas digest..." Today's Topics: 1. Re: Make the @contextmanager of contextlib to be a real contextmanager (Serhiy Storchaka) 2. Re: Fixed point format for numbers with locale based separators (?ukasz Stelmach) ---------------------------------------------------------------------- Message: 1 Date: Sat, 5 Jan 2019 16:45:34 +0200 From: Serhiy Storchaka <storchaka(a)gmail.com> To: python-ideas(a)python.org Subject: Re: [Python-ideas] Make the @contextmanager of contextlib to be a real contextmanager Message-ID: <q0qfqd$q1q$1(a)blaine.gmane.org> Content-Type: text/plain; charset=UTF-8; format=flowed 05.01.19 14:52, Moon?sun ????: > As we know,when we import the module--'contextlib',we can use the > decorator '@contextmanager' and keyword ?yield? to make a 'instance' of > Class '_GeneratorContextManager' in 'contextlib' module,then we can use > it like: > with 'instance' as 'xx': > ? ? 'code block' > ? ? pass > But there is a little bug,when the code block raise a error,the instance > cannot run the code which after the keyword 'yield'. This is not a bug. Consider the following example: @contextmanager def cm(): try: yield except BaseException as err: print('Fail:', err) raise else: print('Success') with cm(): 1/0 What result would you expect? Test it with the stdlib implementation and with your implementation. ------------------------------ Message: 2 Date: Sat, 05 Jan 2019 16:41:20 +0100 From: ?ukasz Stelmach <steelman(a)post.pl> To: Steven D'Aprano <steve(a)pearwood.info> Cc: python-ideas(a)python.org Subject: Re: [Python-ideas] Fixed point format for numbers with locale based separators Message-ID: <87y37z9knz.fsf%steelman(a)post.pl> Content-Type: text/plain; charset="utf-8" Steven D'Aprano <steve(a)pearwood.info> writes: > On Fri, Jan 04, 2019 at 03:57:53PM +0100, ?ukasz Stelmach wrote: >> Hi, >> >> I would like to present two pull requests[1][2] implementing fixed point >> presentation of numbers and ask for comments. The first is mine. I >> learnt about the second after publishing mine. > > Before I look at the implementation, can you explain the functional > requirements please? As I stated in the original message below the table: >> In the application I want to create I am going to present users numbers >> ranging up to 3 orders of magnitude and I (my users) want them to be >> presented consistently with regards to number of decimal digits AND I >> want to conform to rules of languages of my users. And I would like to >> avoid the exponent notation by all means. The pint[1] library I use, implements formatting of physical quantities using the format()/__format__ code. As far as I can tell my patch for Python is shorter and more straightforward than a patch for pint to use locale.format(). Because the "g" based "n" formatter has been present since the advanced string formatting was described in PEP-3101, I think it is necessary to add the "m" formatter based on "f". The advanced string formatting facility in Python is very convenient and programmers shouldn't forced to use locale.format() like this "The total length of {} sticks is {} meters.".format(n_sticks, locale.format(".2f", l_sticks)) instead of "The total length of {} sticks is {:.2f} meters.".format(n_sticks, l_sticks) > In other words, what is the new feature you hope to have excepted? > Explain the intention and the API (the interface). The implementation is > the least important part :-) I wish to add a new formatter "m" for float/complex/decimal numbers, which behaves like the existing "f", but uses the decimal separator from the locale database. There is "n" formmatter which behaves like "g" but it does not fit my needs. > [...] >> Formatting 1.23456789 * n (LC_ALL=3Dpl_PL.UTF-8) >> | n | ".2f" | ".3n" | >> |---+----------+----------| >> | 1 | 1.23 | 1,23 | >> | 2 | 12.35 | 12,3 | >> | 3 | 123.46 | 123 | >> | 4 | 1234.57 | 1,23e+03 | > > I'm afraid I cannot work out what that table means. You say "Formatting > 1.23... * n" (multiplying by n) but the results shown aren't multiplied > by n=2, n=3, n=4 as the table suggests. > > Can you show what Python code you expect will produce the expected > output? for n in range(1,5): print("| {} | {:8.2f} | {:8.3n} |".format(n,1.23456789 * 10**n, 1.23456789 * 10**n)) [1] http://pint.readthedocs.io/ -- By?o mi bardzo mi?o. --- Rurku. --- ... >?ukasz< --- To dobrze, ?e mnie s?uchasz.

2 1

Make the @contextmanager of contextlib to be a real contextmanager
by Moon丶sun 05 Jan '19

05 Jan '19

As we know,when we import the module--'contextlib',we can use the decorator '@contextmanager' and keyword ‘yield’ to make a 'instance' of Class '_GeneratorContextManager' in 'contextlib' module,then we can use it like:with 'instance' as 'xx': 'code block' passBut there is a little bug,when the code block raise a error,the instance cannot run the code which after the keyword 'yield'.So I try to repair this bug, I add a method '_next()' in the Class '_GeneratorContextManager',and then insert it to the the method '__exit__',then we can make the instance like a realcontextmanager.You can cat the concrete content in the attachment. Conmments:the method '_next()' in in line 79,the method '__exit__' in line 97.

2 1

Add regex pattern literal p""
by Ma Lin 01 Jan '19

01 Jan '19

We can use this literal to represent a compiled pattern, for example: >>> p"(?i)[a-z]".findall("a1B2c3") ['a', 'B', 'c'] >>> compiled = p"(?<=abc)def" >>> m = compiled.search('abcdef') >>> m.group(0) 'def' >>> rp'\W+'.split('Words, words, words.') ['Words', 'words', 'words', ''] This allows peephole optimizer to store compiled pattern in .pyc file, we can get performance optimization like replacing constant set by frozenset in .pyc file. Then such issue [1] can be solved perfectly. [1] Optimize base64.b16decode to use compiled regex [1] https://bugs.python.org/issue35559 Two shortcomings: 1, Elevating a class in a module (re.Pattern) to language level, this sounds not very natural. This makes Python looks like Perl. 2, We can't use regex module as a drop-in replacement: import regex as re IMHO, I would like to see regex module be adopted into stdlib after cutting off its "full case-folding" and "fuzzy matching" features. Related links: [2] Chris Angelico conceived of "compiled regexes be stored in .pyc file" in March 2013. [2] https://mail.python.org/pipermail/python-ideas/2013-March/020043.html [3] Ken Hilton conceived of "Give regex operations more sugar" in June 2018. [3] https://mail.python.org/pipermail/python-ideas/2018-June/051395.html

14 27