Mailman 3 June 2018 - Python-ideas

Re: [Python-ideas] Add dict.append and dict.extend
by Chris Barker June 6, 2018

June 6, 2018

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 June 6, 2018

June 6, 2018

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 June 5, 2018

June 5, 2018

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 June 1, 2018

June 1, 2018

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