Mailman 3 June 2018 - Python-ideas

A real life example of "given"
by Neil Girdhar 08 Jun '18

08 Jun '18

I thought I would share a recent use I had for "given": I have this comprehension: potential_updates = {y: command.create_potential_update(y) for x in need_initialization_nodes for y in [x, *x.synthetic_inputs()]} I want to filter out values that are None. I don't want to call the function call twice, so I have to resort to using a loop and appending or the for z in [y] trick. With "given", I can write: potential_updates = { y: potential_update for x in need_initialization_nodes for y in [x, *x.synthetic_inputs()] given potential_update = command.create_potential_update(y) if potential_update is not None} I also wanted to point out that code like this is self-commenting because the key and value of the comprehension can be given names.

6 32

Re: [Python-ideas] Trigonometry in degrees
by Hugh Fisher 08 Jun '18

08 Jun '18

> Date: Fri, 8 Jun 2018 15:45:31 +1000 > From: Steven D'Aprano <steve(a)pearwood.info> > To: python-ideas(a)python.org > Subject: Re: [Python-ideas] Trigonometry in degrees > Message-ID: <20180608054530.GC12683(a)ando.pearwood.info> > Content-Type: text/plain; charset=us-ascii > > On Fri, Jun 08, 2018 at 08:17:02AM +1000, Hugh Fisher wrote: > >> But I think that the use of >> radians in programming language APIs is more prevalent, so the initial advantage >> of easy learning will be outweighed by the long term inconvenience of >> adjusting to what everyone else is doing. > > But why would you need to? > > If we had a degrees API, why wouldn't people just use it? Is this going to be backported all the way to Python 2.7? More generally, there is a huge body of code in C, C++, Java, JavaScript, etc etc where angles are always passed as radians. Python programmers will almost certainly have to read, and often write, such code. If everybody else is doing something in a particular way then there is a strong case for doing the same thing. It's not as if Python programmers cannot use degrees. The built in conversion functions make it easier to do so than most other languages. > I never know what conversion function to use. I always expect something > like deg2rad and rad2deg. I never remember whether degrees(x) expects an > angle in degrees or returns an angle in degrees. > > So I would disagree that it is clear. The degrees and radian functions follow the Python idiom for converting values, eg str(x) is interpreted as converting x into a str. However the analogy breaks down because str(x) is a NOP if x is already a string, while degrees(x) can't tell whether x is already in degrees or not. Maybe rad2deg would have been better, but the current solution is good enough - and as noted above, much better than what you get in C or JavaScript. >> And even if your proposal is adopted, there is still going >> to be a lot of code around that uses the older math routines. > > Why would that be a problem? See above. Why do Python subscripts start from zero? Because most programmers expect them to. >> Not just young students :-) I agree with this, but I would prefer the >> check to be in the implementation of the existing functions as well. >> Any sin/cos very close to 0 becomes 0, any close to 1 becomes 1. > > Heavens no! That's a terrible idea -- that means that functions which > *ought to return 0.9999987 (say) will suddenly become horribly > inaccurate and return 1. > > The existing trig functions are as close to accurate as is practical to > expect with floating point maths. (Although some platform's maths > libraries are less accurate than others.) We shouldn't make them *less* > accurate just because some people don't care for more than three decimal > places. But I want them to be more accurate. I didn't make myself clear. Like you, I want cos(90 degrees) to be 0, not some small number. Other people have pointed out the problem with trying to guess the result from the argument value, so I am suggesting that the functions should instead look at the calculated result and if it is sufficiently close to 0.0 or 1.0, assume that the argument value was 90 degrees or some multiple thereof. >> Not "d". In the OpenGL 3D API, and many 3D languages/APIs since, appending "d" >> means "double precision". > > Python floats are already double precision. > > What advantage is there for reserving a prefix/suffix because some > utterly unrelated framework in another language uses it for a completely > different purpose? Well I program using the OpenGL API in Python, so there's at least one person who will find the d suffix confusing for that reason. And the d suffix is used for types and functions in OpenGL shading language, C, ARM/Intel assembler. The intersection with Python programmers may not be very large, but again it is at least 1. So no they are not utterly unrelated. > Like mathematicians, we use the "h" suffix for hyperbolic sin, cos and > tan; should we have done something different because C uses ".h" for > header files, or because the struct module uses "h" as the format code > for short ints? Is d used as a suffix by mathematicians though? The h works because the context makes it clear which sense is being used, mathematics, C, or struct module. Here we are discussing functions in the same module. Whether to use d or deg is an arbitrary choice for mathematicians (AFAIK), so either would work equally well. Since d can be confusing for others, to me that would make deg preferable. But see below where I change my mind. > Julia provides a full set of trigonometric functions in both radians and > degrees: > > https://docs.julialang.org/en/release-0.4/manual/mathematical-operations/#t… > > They use sind, cosd, tand etc for the variants expecting degrees. I > think that's much more relevant than OpenGL. OK, that's interesting, I did not know that. And a quick google shows that Matlab also has sind and similar variants for degrees. > Although personally I prefer the look of d as a prefix: > > dsin, dcos, dtan > > That's more obviously pronounced "d(egrees) sin" etc rather than "sined" > "tanned" etc. If Julia and Matlab are sufficiently well known, I would prefer d as suffix rather than prefix. -- cheers, Hugh Fisher

2 1

Re: [Python-ideas] Trigonometry in degrees
by Adam Bartoš 08 Jun '18

08 Jun '18

Wouldn't sin(45 * DEG) where DEG = 2 * math.pi / 360 be better that sind(45)? This way we woudn't have to introduce new functions. (The problem with nonexact results for nice angles is a separate issue.) Regards, Adam Bartoš

2 1

Trigonometry in degrees
by Robert Vanden Eynde 07 Jun '18

07 Jun '18

I suggest adding degrees version of the trigonometric functions in the math module. - Useful in Teaching and replacing calculators by python, importing something is seen by the young students much more easy than to define a function. - Special values could be treated, aka when the angle is a multiple of 90, young students are often surprise to see that cos(pi/2) != 0 Testing for a special value Isn't very costly (x % 90 == 0) but it could be pointed out that there is a small overhead using the "degrees" equivalent of trig function because of the radians to degrees conversion And the special values testing. - Standard names will be chosen so that everyone will use the same name convention. I suggest adding a "d" like sind, cosd, tand, acosd, asind, atand, atan2d. Another option would be to add "deg" or prepend "d" or "deg" however the name should be short. sind, dsin, sindeg or degsin ? We can look in other languages what they chose. Creating a new package like 'from math.degrees import cos' however I would not recommend that because "cos" in the source code would mean to lookup the import to know if it's in degrees or radians (and that leads to very filthy bugs). Also "degrees" is already so the name would have to change the name of the package. - Also in the cmath module. Even though the radians make more sense in the complex plane. The same functions sin cos tan, asin acos atan, alongside with phase and polar. Here's my current implementation : def cosd(x): if x % 90 == 0: return (1, 0, -1, 0)[int(x // 90) % 4] else: return cos(radians(x)) def sind(x): if x % 90 == 0: return (0, 1, 0, -1)[int(x // 90) % 4] else: return sin(radians(x)) def tand(x): if x % 90 == 0: return (0, float('inf'), 0, float('-inf'))[int(x // 90) % 4] else: return tan(radians(x)) The infinity being positive of negative is debatable however, here I've chosen the convention lim tan(x) as x approaches ±90° from 0 def acosd(x): if x == 1: return 0 if x == 0: return 90 if x == -1: return 180 return degrees(acos(x)) def asind(x): if x == 1: return 90 if x == 0: return 0 if x == -1: return -90 return degrees(asin(x)) However, currently [degrees(acos(x)) for x in (1,0,-1)] == [0, 90, 180] on my machine so maybe the test isn't necessary. Testing for Special values of abs(x) == 0.5 could be an idea but I don't think the overhead is worth the effort. Probably this has already been discussed but I don't know how to check that.

4 3

Re: [Python-ideas] Make asyncio.get_event_loop a builtin
by Ken Hilton 06 Jun '18

06 Jun '18

On Tue May 22 22:08:40 (-0400), Chris Barker wrote: > while asyncio is in the standard library, it is not intended to be THE async event loop implementation I'm surprised this is true - with dedicated syntax like async def/await, it's still not THE async event loop implementation? As far as I know, "async def" is a shorthand for @asyncio.coroutine def and "await" is short for "yield from". Sincerely, Ken Hilton;

7 8

Re: [Python-ideas] Add dict.append and dict.extend
by Chris Barker 06 Jun '18

06 Jun '18

I think your proposal got a bit confused by the choice of names, and that you were proposing two things, one of which I think already exists (setdefault). So, I _think_ what you are proposing is that there be a method something like: def exclusive_add(self, key, value): if key in self: raise KeyError("the key: {} already exists in this dict".format(key)) self[key] = value Which would make sense if that is a common use case, and you make a pretty good case for that, with the analogy to UNIQUE in database tables. I will point out that the DB case is quite different, because python dicts have a way to of spelling it that's really pretty straightforward, performant and robust. However, .setdefault() is essentially a replacement for: if key in a_dict: value = a_dict(key) else: a_dict[key] = default_value value = default_value or a similar try: except block: try: value = a_dict[key] except KeyError: a_dict[key] = default_value value = default_value And I'm glad it's there. So - -if this is a fairly common use case, then maybe it's worth adding. Note that this would be adding a new method to not just dict, but to the entire mapping protocol (ABC) -- so maybe a heavier lift than you're imagining. -CHB PS: making sure this is what you are suggesting: In [*12*]: *class* *my_dict*(dict): ...: *def* exclusive_add(self, key, value): ...: *if* key *in* self: ...: *raise* *KeyError*("the key: *{}* already exists in this dict".format(key)) ...: self[key] = value ...: In [*13*]: d = my_dict() In [*14*]: d.exclusive_add('this', 5) In [*15*]: d.exclusive_add('that', 6) In [*16*]: d.exclusive_add('this', 7) --------------------------------------------------------------------------- KeyError Traceback (most recent call last) <ipython-input-16-b7600f2469fb> in <module>() ----> 1 d.exclusive_add('this', 7) <ipython-input-12-5f1c0f0709c6> in exclusive_add(self, key, value) * 2* def exclusive_add(self, key, value): * 3* if key in self: ----> 4 raise KeyError("the key: {} already exists in this dict".format(key)) * 5* self[key] = value * 6* KeyError: 'the key: this already exists in this dict' -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

3 3

Re: [Python-ideas] Runtime assertion with no overhead when not active
by Eloi Gaudry 06 Jun '18

06 Jun '18

By 'self-contained', I meant that using the assert keyword and its expression is sufficient. An inline assertive expression as the one you describe does not fulfill this assert requirement. My proposal is simply to extend the current assert to non-debug builds and allow to switch it off/on at runtime. The syntax example I gave illustrated what I meant by syntax aware. De : Serhiy Storchaka Envoyé : samedi 5 mai à 15:10 Objet : Re: [Python-ideas] Runtime assertion with no overhead when not active À : python-ideas(a)python.org 05.05.18 15:54, Eloi Gaudry пише: > I meant avoiding the overhead of the expression evaluation enclosed in the assert itself, not the active/disabled state (that comes at virtually no cost). > ex: >>>> runtime_assert( { i:None for i in range( 10000000 ) } ) > > By using the syntax you describe ('boolean and not expr'), you loose all the benefit of the Python grammar: > - self-contained Could you please explain what you mean? > - able to catch semantic/syntax bugs > > ex: >>>> f=1 >>>> runtime_assert( f==1 ) >>>> runtime_assert( f=1 ) > File "", line 1 > runtime_assert( f=1 ) > ^ > SyntaxError: invalid syntax Until inline assignment expression is implemented, this is an error too: >>> if debug and not f=1: File "", line 1 if debug and not f=1: ^ SyntaxError: invalid syntax _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

11 34

Runtime assertion with no overhead when not active
by Eloi Gaudry 05 Jun '18

05 Jun '18

Hi folks, I intend to add a runtime assertion feature in python. Before submitting a PEP, I am sending a draft to this mailing list to discuss whether it would make sense (above this message). I have actually been using it for the last 2 years and it has proven to be robust and has achieved its primary goal. Briefly, the idea is to add a new assert that can be switch on/off depending on some variable/mechanism at runtime. The whole point of this assert is that it should not bring any overhead when off, i.e. by avoiding evaluating the expression enclosed in the runtime assert. It thus relies on Python grammar. Thanks for your feedback. Eloi Abstract This PEP aims at offering a runtime assert functionnality, extending the compiletime assert already available. Rationale There is no runtime assert relying on python grammar available. For diagnostics and/or debugging reasons, it would be valuable to add such a feature. A runtime assert makes sense when extra checks would be needed in a production environment (where non-debug builds are used). By extending the current python grammar, it would be possible to limit the overhead induces by those runtime asserts when running in a non "assertive" mode (-ed). The idea here is to avoid evaluating the expression when runtime assertion is not active. A brief example why avoiding evaluating the expression is needed to avoid any overhead in case the runtime assert should be ignored. :: runtime_assert( 999 in { i:None for i in range( 10000000 ) } ) Usage :: runtime_assert( expr ) #would result in if expr and runtime_assert_active: print RuntimeAssertionError() Implementation details There is already an implementation available, robust enough for production. The implementation is mainly grammar based, and thus the parser and the grammar needs to be updated: * Python/graminit.c * Python/ast.c * Python/symtable.c * Python/compile.c * Python/Python-ast.c * Python/sysmodule.c * Modules/parsermodule.c * Include/Python-ast.h * Include/graminit.h * Include/pydebug.h * Grammar/Grammar * Parser/Python.asdl * Lib/lib2to3/Grammar.txt * Lib/compiler/ast.py * Lib/compiler/pycodegen.py * Lib/compiler/transformer.py * Lib/symbol.py * Modules/parsermodule.c References [1] PEP 306, How to Change Python's Grammar (http://www.python.org/dev/peps/pep-0306) Copyright This document has been placed in the public domain.

4 7

Let try-except check the exception instance
by Danilo J. S. Bellini 01 Jun '18

01 Jun '18

Hi! I was working on handling some exceptions from external software (e.g. database constraint triggers) switching the handler based on the messages that had been sent. Today we can do something like (running on Python 3.6.5): >>> try: ... # [...] ... session.commit() # Here it raises! ... # [...] ... except DatabaseError as exc: ... msg = get_db_error_msg_from_exception(exc) ... if msg == "beyond_limit": ... # [...] ... elif msg == "no_funds": ... # [...] ... else: ... raise That works, but I'd like to do something like: >>> try: ... # [...] ... except BeyondLimit: ... # [...] ... except NoFunds: ... # [...] Creating classes to "match" the exception in their __instancecheck__. Well, I tried to do so. A simplified example would be: >>> class MsgCheckerMeta(type): ... def __instancecheck__(cls, instance): ... return str(instance) == cls.internal ... >>> class ExceptionHasMessage(Exception, metaclass=MsgCheckerMeta): ... internal = "message" Using these new classes, we would get this: >>> try: ... raise Exception("message") ... except ExceptionHasMessage: ... print("Yeah!") ... Traceback (most recent call last): File "<stdin>", line 2, in <module> Exception: message Yet, >>> isinstance(Exception("message"), ExceptionHasMessage) True >>> try: ... raise Exception("message") ... except Exception as exc: ... print(isinstance(exc, ExceptionHasMessage)) ... True The idea is to allow catching exceptions beyond checking their MRO, using a class that checks the exception instance by implementing a custom __instancecheck__. -- Danilo J. S. Bellini --------------- "*It is not our business to set up prohibitions, but to arrive at conventions.*" (R. Carnap)

14 16