Mailman 3 July 2017 - Python-ideas

@classproperty, @abc.abstractclasspropery, etc.
by K. Richard Pixley Dec. 16, 2020

Dec. 16, 2020

There's a whole matrix of these and I'm wondering why the matrix is currently sparse rather than implementing them all. Or rather, why we can't stack them as: class foo(object): @classmethod @property def bar(cls, ...): ... Essentially the permutation are, I think: {'unadorned'|abc.abstract}{'normal'|static|class}{method|property|non-callable attribute}. concreteness implicit first arg type name comments {unadorned} {unadorned} method def foo(): exists … [View More]now {unadorned} {unadorned} property @property exists now {unadorned} {unadorned} non-callable attribute x = 2 exists now {unadorned} static method @staticmethod exists now {unadorned} static property @staticproperty proposing {unadorned} static non-callable attribute {degenerate case - variables don't have arguments} unnecessary {unadorned} class method @classmethod exists now {unadorned} class property @classproperty or @classmethod;@property proposing {unadorned} class non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract {unadorned} method @abc.abstractmethod exists now abc.abstract {unadorned} property @abc.abstractproperty exists now abc.abstract {unadorned} non-callable attribute @abc.abstractattribute or @abc.abstract;@attribute proposing abc.abstract static method @abc.abstractstaticmethod exists now abc.abstract static property @abc.staticproperty proposing abc.abstract static non-callable attribute {degenerate case - variables don't have arguments} unnecessary abc.abstract class method @abc.abstractclassmethod exists now abc.abstract class property @abc.abstractclassproperty proposing abc.abstract class non-callable attribute {degenerate case - variables don't have arguments} unnecessary I think the meanings of the new ones are pretty straightforward, but in case they are not... @staticproperty - like @property only without an implicit first argument. Allows the property to be called directly from the class without requiring a throw-away instance. @classproperty - like @property, only the implicit first argument to the method is the class. Allows the property to be called directly from the class without requiring a throw-away instance. @abc.abstractattribute - a simple, non-callable variable that must be overridden in subclasses @abc.abstractstaticproperty - like @abc.abstractproperty only for @staticproperty @abc.abstractclassproperty - like @abc.abstractproperty only for @classproperty --rich [View Less]

10 15

Specify number of items to allocate for array.array() constructor
by Sven Rahmann Feb. 22, 2020

Feb. 22, 2020

At the moment, the array module of the standard library allows to create arrays of different numeric types and to initialize them from an iterable (eg, another array). What's missing is the possiblity to specify the final size of the array (number of items), especially for large arrays. I'm thinking of suffix arrays (a text indexing data structure) for large texts, eg the human genome and its reverse complement (about 6 billion characters from the alphabet ACGT). The suffix array is a long int … [View More]

14 20

Asynchronous exception handling around with/try statement borders
by Erik Bray Sept. 24, 2018

Sept. 24, 2018

Hi folks, I normally wouldn't bring something like this up here, except I think that there is possibility of something to be done--a language documentation clarification if nothing else, though possibly an actual code change as well. I've been having an argument with a colleague over the last couple days over the proper way order of statements when setting up a try/finally to perform cleanup of some action. On some level we're both being stubborn I think, and I'm not looking for resolution … [View More]as to who's right/wrong or I wouldn't bring it to this list in the first place. The original argument was over setting and later restoring os.environ, but we ended up arguing over threading.Lock.acquire/release which I think is a more interesting example of the problem, and he did raise a good point that I do want to bring up. </prologue> My colleague's contention is that given lock = threading.Lock() this is simply *wrong*: lock.acquire() try: do_something() finally: lock.release() whereas this is okay: with lock: do_something() Ignoring other details of how threading.Lock is actually implemented, assuming that Lock.__enter__ calls acquire() and Lock.__exit__ calls release() then as far as I've known ever since Python 2.5 first came out these two examples are semantically *equivalent*, and I can't find any way of reading PEP 343 or the Python language reference that would suggest otherwise. However, there *is* a difference, and has to do with how signals are handled, particularly w.r.t. context managers implemented in C (hence we are talking CPython specifically): If Lock.__enter__ is a pure Python method (even if it maybe calls some C methods), and a SIGINT is handled during execution of that method, then in almost all cases a KeyboardInterrupt exception will be raised from within Lock.__enter__--this means the suite under the with: statement is never evaluated, and Lock.__exit__ is never called. You can be fairly sure the KeyboardInterrupt will be raised from somewhere within a pure Python Lock.__enter__ because there will usually be at least one remaining opcode to be evaluated, such as RETURN_VALUE. Because of how delayed execution of signal handlers is implemented in the pyeval main loop, this means the signal handler for SIGINT will be called *before* RETURN_VALUE, resulting in the KeyboardInterrupt exception being raised. Standard stuff. However, if Lock.__enter__ is a PyCFunction things are quite different. If you look at how the SETUP_WITH opcode is implemented, it first calls the __enter__ method with _PyObjet_CallNoArg. If this returns NULL (i.e. an exception occurred in __enter__) then "goto error" is executed and the exception is raised. However if it returns non-NULL the finally block is set up with PyFrame_BlockSetup and execution proceeds to the next opcode. At this point a potentially waiting SIGINT is handled, resulting in KeyboardInterrupt being raised while inside the with statement's suite, and finally block, and hence Lock.__exit__ are entered. Long story short, because Lock.__enter__ is a C function, assuming that it succeeds normally then with lock: do_something() always guarantees that Lock.__exit__ will be called if a SIGINT was handled inside Lock.__enter__, whereas with lock.acquire() try: ... finally: lock.release() there is at last a small possibility that the SIGINT handler is called after the CALL_FUNCTION op but before the try/finally block is entered (e.g. before executing POP_TOP or SETUP_FINALLY). So the end result is that the lock is held and never released after the KeyboardInterrupt (whether or not it's handled somehow). Whereas, again, if Lock.__enter__ is a pure Python function there's less likely to be any difference (though I don't think the possibility can be ruled out entirely). At the very least I think this quirk of CPython should be mentioned somewhere (since in all other cases the semantic meaning of the "with:" statement is clear). However, I think it might be possible to gain more consistency between these cases if pending signals are checked/handled after any direct call to PyCFunction from within the ceval loop. Sorry for the tl;dr; any thoughts? [View Less]

7 15

Positional-only parameters
by Victor Stinner Sept. 11, 2018

Sept. 11, 2018

Hi, For technical reasons, many functions of the Python standard libraries implemented in C have positional-only parameters. Example: ------- $ ./python Python 3.7.0a0 (default, Feb 25 2017, 04:30:32) >>> help(str.replace) replace(self, old, new, count=-1, /) # <== notice "/" at the end ... >>> "a".replace("x", "y") # ok 'a' >>> "a".replace(old="x", new="y") # ERR! TypeError: replace() takes at least 2 arguments (0 given) ------- When converting the … [View More]

19 27

Implicit string literal concatenation considered harmful?
by Guido van Rossum March 14, 2018

March 14, 2018

I just spent a few minutes staring at a bug caused by a missing comma -- I got a mysterious argument count error because instead of foo('a', 'b') I had written foo('a' 'b'). This is a fairly common mistake, and IIRC at Google we even had a lint rule against this (there was also a Python dialect used for some specific purpose where this was explicitly forbidden). Now, with modern compiler technology, we can (and in fact do) evaluate compile-time string literal concatenation with the '+' … [View More]

51 165

HTTP compression support for http.server
by Pierre Quentel Aug. 7, 2017

Aug. 7, 2017

I have reported an issue in the tracker (https://bugs.python.org/issue30576) and proposed a Pull Request on the Github CPython repository ( https://github.com/python/cpython/pull/2078) to make http.server in the standard library support HTTP compression (gzip). I have been suggested to require feedback from core devs : - should HTTP compression be supported ? - if so, should it be supported by default ? It is the case in the PR, where a number of content types, eg text/html, are compressed if … [View More]

5 5

namedtuple literals [Was: RE a new namedtuple]
by Giampaolo Rodola' July 31, 2017

July 31, 2017

On Tue, Jul 18, 2017 at 6:31 AM, Guido van Rossum <guido(a)python.org> wrote: > On Mon, Jul 17, 2017 at 6:25 PM, Eric Snow <ericsnowcurrently(a)gmail.com> > wrote: > >> On Mon, Jul 17, 2017 at 6:01 PM, Ethan Furman <ethan(a)stoneleaf.us> wrote: >> > Guido has decreed that namedtuple shall be reimplemented with speed in >> mind. >> >> FWIW, I'm sure that any changes to namedtuple will be kept as minimal >> as possible. Changes … [View More]would be limited to the underlying >> implementation, and would not include the namedtuple() signature, or >> using metaclasses, etc. However, I don't presume to speak for Guido >> or Raymond. :) >> > > Indeed. I referred people here for discussion of ideas like this: > > >>> a = (x=1, y=0) > Thanks for bringing this up, I'm gonna summarize my idea in form of a PEP-like draft, hoping to collect some feedback. Proposal ======== Introduction of a new syntax and builtin function to create lightweight namedtuples "on the fly" as in: >>> (x=10, y=20) (x=10, y=20) >>> ntuple(x=10, y=20) (x=10, y=20) Motivations =========== Avoid declaration ----------------- Other than the startup time cost: https://mail.python.org/pipermail/python-dev/2017-July/148592.html ...the fact that namedtuples need to be declared upfront implies they mostly end up being used only in public, end-user APIs / functions. For generic functions returning more than 1 argument it would be nice to just do: def get_coordinates(): return (x=10, y=20) ...instead of: from collections import namedtuple Coordinates = namedtuple('coordinates', ['x', 'y']) def get_coordinates(): return Coordinates(10, 20) Declaration also has the drawback of unnecessarily polluting the module API with an object (Coordinates) which is rarely needed. AFAIU namedtuple was designed this way for efficiency of the pure-python implementation currently in place and for serialization purposes (e.g. pickle), but I may be missing something else. Generally namedtuples are declared in a private module, imported from elsewhere and they are never exposed in the main namespace, which is kind of annoying. In case of one module scripts it's not uncommon to add a leading underscore which makes __repr__ uglier. To me, this suggests that the factory function should have been a first-class function instead. Speed ------ Other than the startup declaration overhead, a namedtuple is slower than a tuple or a C structseq in almost any aspect: - Declaration (50x slower than cnamedtuple): $ python3.7 -m timeit -s "from collections import namedtuple" \ "namedtuple('Point', ('x', 'y'))" 1000 loops, best of 5: 264 usec per loop $ python3.7 -m timeit -s "from cnamedtuple import namedtuple" \ "namedtuple('Point', ('x', 'y'))" 50000 loops, best of 5: 5.27 usec per loop - Instantiation (3.5x slower than tuple): $ python3.7 -m timeit -s "import collections; Point = collections.namedtuple('Point', ('x', 'y')); x = [1, 2]" "Point(*x)" 1000000 loops, best of 5: 310 nsec per loop $ python3.7 -m timeit -s "x = [1, 2]" "tuple(x)" 5000000 loops, best of 5: 88 nsec per loop - Unpacking (2.8x slower than tuple): $ python3.7 -m timeit -s "import collections; p = collections.namedtuple( \ 'Point', ('x', 'y'))(5, 11)" "x, y = p" 5000000 loops, best of 5: 41.9 nsec per loop $ python3.7 -m timeit -s "p = (5, 11)" "x, y = p" 20000000 loops, best of 5: 14.8 nsec per loop - Field access by name (1.9x slower than structseq and cnamedtuple): $ python3.7 -m timeit -s "from collections import namedtuple as nt; \ p = nt('Point', ('x', 'y'))(5, 11)" "p.x" 5000000 loops, best of 5: 42.7 nsec per loop $ python3.7 -m timeit -s "from cnamedtuple import namedtuple as nt; \ p = nt('Point', ('x', 'y'))(5, 11)" "p.x" 10000000 loops, best of 5: 22.5 nsec per loop $ python3.7 -m timeit -s "import os; p = os.times()" "p.user" 10000000 loops, best of 5: 22.6 nsec per loop - Field access by index is the same as tuple: $ python3.7 -m timeit -s "from collections import namedtuple as nt; \ p = nt('Point', ('x', 'y'))(5, 11)" "p[0]" 10000000 loops, best of 5: 20.3 nsec per loop $ python3.7 -m timeit -s "p = (5, 11)" "p[0]" 10000000 loops, best of 5: 20.5 nsec per loop It is being suggested that most of these complaints about speed aren't an issue but in certain circumstances such as busy loops, getattr() being 1.9x slower could make a difference, e.g.: https://github.com/python/cpython/blob/3e2ad8ec61a322370a6fbdfb2209cf74546f… Same goes for values unpacking. isinstance() ------------ Probably a minor complaint, I just bring this up because I recently had to do this in psutil's unit tests. Anyway, checking a namedtuple instance isn't exactly straightforward: https://stackoverflow.com/a/2166841 Backward compatibility ====================== This is probably the biggest barrier other than the "a C implementation is less maintainable" argument. In order to avoid duplication of functionality it would be great if collections.namedtuple() could remain a (deprecated) factory function using ntuple() internally. FWIW I tried running stdlib's unittests against https://github.com/llllllllll/cnamedtuple, I removed the ones about "_source", "verbose" and "module" arguments and I get a couple of errors about __doc__. I'm not sure about more advanced use cases (subclassing, others...?) but overall it appears pretty doable. collections.namedtuple() Python wrapper can include the necessary logic to implement "verbose" and "rename" parameters when they're used. I'm not entirely sure about the implications of the "module" parameter though (Raymond?). _make(), _asdict(), _replace() and _fields attribute should also be exposed; as for "_source" it appears it can easily be turned into a property which would also save some memory. The biggest annoyance is probably fields' __doc__ assignment: https://github.com/python/cpython/blob/ced36a993fcfd1c76637119d31c03156a877… ...which would require returning a clever class object slowing down the namedtuple declaration also in case no parameters are passed, but considering that the long-term plan is the replace collections.namedtuple() with ntuple() I consider this acceptable. Thoughts? -- Giampaolo - http://grodola.blogspot.com [View Less]

32 81

namedtuple nit...
by Chris Barker July 29, 2017

July 29, 2017

Since we are talking about namedtuple and implementation, I just noticed: In [22]: Point = namedtuple('Point', ['x', 'y']) In [23]: p = Point(2,3) In [24]: p.x = 5 --------------------------------------------------------------------------- AttributeError Traceback (most recent call last) <ipython-input-24-328d3fab3e30> in <module>() ----> 1 p.x = 5 AttributeError: can't set attribute OK -- that makes sense. but then, if you try: In [25]: p.z = 5 ----… [View More]

7 11

Idea : for smarter assignment?
by Jason H July 25, 2017

July 25, 2017

I experimented with Python in college and I've been for close to 20 years now. (Coming and going as needed) I love the language. But there is one annoyance that I continually run into. There are basically two assignment operators, based on context, = and : a = 1 { a: 1 } They cannot be used interchangeably: a: 1 # error {a=1} # error I don't think I should be this way. There are times when I have a bunch of variables that I want to collect into an object or destructure. This involves … [View More]

9 8

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]
by C Anthony Risinger July 25, 2017

July 25, 2017

On Jul 23, 2017 1:56 PM, "MRAB" <python(a)mrabarnett.plus.com> wrote: On 2017-07-23 17:08, Todd wrote: > On Jul 20, 2017 1:13 AM, "David Mertz" <mertz(a)gnosis.cx <mailto: > mertz(a)gnosis.cx>> wrote: > > I'm concerned in the proposal about losing access to type > information (i.e. name) in this proposal. For example, I might > write some code like this now: > > >>> from collections import namedtuple > >>> … [View More]

3 4

Re: [Python-ideas] namedtuple redesign goals
by Ethan Furman July 25, 2017

July 25, 2017

[redirecting back to list] On 07/24/2017 04:19 AM, Michel Desmoulin wrote: > Le 24/07/2017 à 13:02, Ethan Furman a écrit : >> On 07/23/2017 10:47 AM, Michel Desmoulin wrote: >>> I'm not sure why everybody have such a grip on the type. >> >> If I understand the goal of "a new namedtuple" correctly, it is not to >> come up with yet another namedtuple type -- it is to make the existing >> collections.namedtuple a faster experience, and possibly add … [View More]

3 3

namedtuple redesign goals
by Ethan Furman July 24, 2017

July 24, 2017

On 07/23/2017 10:47 AM, Michel Desmoulin wrote: > I'm not sure why everybody have such a grip on the type. If I understand the goal of "a new namedtuple" correctly, it is not to come up with yet another namedtuple type -- it is to make the existing collections.namedtuple a faster experience, and possibly add another way to create such a thing. This means that the "replacement" namedtuple MUST be backwards compatible with the existing collections.namedtuple, and keeping track of type is … [View More]

1 0

namedtuple from ordereddict
by Jim J. Jewett July 21, 2017

July 21, 2017

Several of the replies seemed to suggest that re-using the current dict structure for a tuple wouldn't work. Since I'm not sure whether people are still thinking of the old structure, or I'm missing something obvious, I'll be more explicit. Per https://github.com/python/cpython/blob/master/Include/dictobject.h#L40 the last element of a dict object is now a separate pointer to ma_values, which is an array of objects. Per https://github.com/python/cpython/blob/master/Include/tupleobject.h#L27 … [View More]

2 1

Fwd: Consider allowing the use of abstractmethod without metaclasses
by INADA Naoki July 21, 2017

July 21, 2017

Hi, Neil. > I want to use abstractmethod, but I have my own metaclasses and I don't want > to build composite metaclasses using abc.ABCMeta. > > Thanks to PEP 487, one approach is to facator out the abstractmethod checks > from ABCMeta into a regular (non-meta) class. So, my first suggestion is to > split abc.ABC into two pieces, a parent regular class with metaclass "type": > I'm +1 with your idea in performance point of view. Some people having other language … [View More]

5 9

a new namedtuple
by Ethan Furman July 20, 2017

July 20, 2017

Guido has decreed that namedtuple shall be reimplemented with speed in mind. I haven't timed it (I'm hoping somebody will volunteer to be the bench mark guru), I'll offer my NamedTuple implementation from my aenum [1] library. It uses the same metaclass techniques as Enum, and offers doc string and default value support in the class-based form. -- ~Ethan~ [1] https://pypi.python.org/pypi/aenum/1.4.5

10 17

Enabling Event.set to notify all waiters with an exception
by Pau Freixes July 19, 2017

July 19, 2017

Morning guys, I came across with that idea trying to resolve a typical dogpile pattern [1], having many DNS calls to the same domain because of a miss in a DNS cache. The usage of the the set either to notify that the waiters could be awake and get the result from the cache or use it to notify that something was wrong helped me to reduce the complexity of the code. Just as an example: ``` if key in throttle_dns_events: yield from throttle_dns_events[key].wait() else: … [View More]

3 5

namedtuple with ordereddict
by Jim J. Jewett July 19, 2017

July 19, 2017

Given that (1) dicts now always pay the price for ordering (2) namedtuple is being accelerated is there any reason not to simply define it as a view on a dict, or at least as a limited proxy to one? Then constructing a specific instance from the arguments used to create it could be as simple as keeping a reference to the temporary created to pass those arguments... -jJ

8 8

pathlib.Path should handle Pythonpath or package root
by George Fischhof July 19, 2017

July 19, 2017

Hi there, I created a program which uses plugins (import them). I started to test it, and found that I need two types of paths: one for file system and another one which is package relative. So I thing this is a good idea, to enhance pathlib to handle package roots. (I know about sys.path, environment variables, importlib etc, but I think it should be in pathlib.) BR, George

2 5

Alternative Unicode implementations (NSString/NSMutableString)
by Jim J. Jewett July 19, 2017

July 19, 2017

Ronald Oussoren came up with a concrete use case for wanting the interpreter to consider something a string, even if it isn't implemented with the default datastructure. In https://mail.python.org/pipermail/python-ideas/2017-July/046407.html he writes: The reason I need to subclass str: in PyObjC I use a subclass of str to represent Objective-C strings (NSString/NSMutableString), and I need to keep track of the original value; mostly because there are some Objective-C APIs that … [View More]

4 4

between block and function [was: Custom Code Folding: Standardized Rules and Syntax?]
by Jim J. Jewett July 19, 2017

July 19, 2017

There have been times when I wanted to group portions of a module, class, or function. Giving names to each of those groupings would be useful, and would be appropriate for python-level changes. That said, it would probably need more proof in the wild first, so the first step would be getting support in an editor (such as PyCharm), and the second would be an informational PEP on how to standardize the practice, like PEP 257 does for docstrings. https://www.python.org/dev/peps/pep-0257/ For … [View More]

2 1

tempfile.TemporaryDirectory() should be able to create temporary directory at a given arbitrary place
by George Fischhof July 18, 2017

July 18, 2017

Hi there, I used tempfile.TemporaryDirectory(). On first usage it was good, but on second one there was a need to create tempopray directory and files in it a given place. (It needed for a test). And I found that TemporaryDirectory() is not able to do this. So my idea is to implement this behaviour with an addittional path parameter in it. BR, George

3 3

Is this PEP viable?
by Evan Adler July 17, 2017

July 17, 2017

I would like to submit the following proposal. In the logging module, I would like handlers (like file handlers and stream handlers) to have a field for exc_info printing. This way, a call to logger.exception() will write the stack trace to the handlers with this flag set, and only print the message and other info to handlers without the flag set. This allows a single logger to write to a less detailed console output, a less detailed run log, and a more detailed error log.

2 1

Arguments to exceptions
by Ken Kundert July 17, 2017

July 17, 2017

All, Here is a proposal for enhancing the way BaseException handles arguments. -Ken Rationale ========= Currently, the base exception class takes all the unnamed arguments passed to an exception and saves them into args. In this way they are available to the exception handler. A commonly used and very useful idiom is to extract an error message from the exception by casting the exception to a string. If you do so while passing one argument, you get that argument as a string: &… [View More]gt;>> try: ... raise Exception('Hey there!') ... except Exception as e: ... print(str(e)) Hey there! However, if more than one argument is passed, you get the string representation of the tuple containing all the arguments: >>> try: ... raise Exception('Hey there!', 'Something went wrong.') ... except Exception as e: ... print(str(e)) ('Hey there!', 'Something went wrong.') That behavior does not seem very useful, and I believe it leads to people passing only one argument to their exceptions. An example of that is the system NameError exception: >>> try: ... foo ... except Exception as e: ... print('str:', str(e)) ... print('args:', e.args) str: name 'foo' is not defined args: ("name 'foo' is not defined",) Notice that the only argument is the error message. If you want access to the problematic name, you have to dig it out of the message. For example ... >>> import Food >>> try: ... import meals ... except NameError as e: ... name = str(e).split("'")[1] # <-- fragile code ... from difflib import get_close_matches ... candidates = ', '.join(get_close_matches(name, Food.foods, 1, 0.6)) ... print(f'{name}: not found. Did you mean {candidates}?') In this case, the missing name was needed but not directly available. Instead, the name must be extracted from the message, which is innately fragile. The same is true with AttributeError: the only argument is a message and the name of the attribute, if needed, must be extracted from the message. Oddly, with a KeyError it is the opposite situation, the name of the key is the argument and no message is included. With IndexError there is a message but no index. However none of these behaviors can be counted on; they could be changed at any time. When writing exception handlers it is often useful to have both a generic error message and access to the components of the message if for no other reason than to be able to construct a better error message. However, I believe that the way the arguments are converted to a string when there are multiple arguments discourages this. When reporting an exception, you must either give one argument or add a custom __str__ method to the exception. To do otherwise means that the exception handlers that catch your exception will not have a reasonable error message and so would be forced to construct one from the arguments. This is spelled out in PEP 352, which explicitly recommends that there be only one argument and that it be a helpful human readable message. Further it suggests that if more than one argument is required that Exception should be subclassed and the extra arguments should be attached as attributes. However, the extra effort required means that in many cases people just pass an error message alone. This approach is in effect discouraging people from adding additional arguments to exceptions, with the result being that if they are needed by the handler they have to be extracted from the message. It is important to remember that the person that writes the exception handler often does not raise the exception, and so they just must live with what is available. As such, a convention that encourages the person raising the exception to include all the individual components of the message should be preferred. That is the background. Here is my suggestion on how to improve this situation. Proposal ======== I propose that the Exception class be modified to allow passing a message template as a named argument that is nothing more than a format string that interpolates the exception arguments into an error message. If the template is not given, the arguments would simply be converted to strings individually and combined as in the print function. So, I am suggesting the BaseException class look something like this: class BaseException: def __init__(self, *args, **kwargs): self.args = args self.kwargs = kwargs def __str__(self): template = self.kwargs.get('template') if template is None: sep = self.kwargs.get('sep', ' ') return sep.join(str(a) for a in self.args) else: return template.format(*self.args, **self.kwargs) Benefits ======== Now, NameError could be defined as: class NameError(Exception): pass A NameError would be raised with: try: raise NameError(name, template="name '{0}' is not defined.") except NameError as e: name = e.args[0] msg = str(e) ... Or, perhaps like this: try: raise NameError(name=name, template="name '{name}' is not defined.") except NameError as e: name = e.kwargs['name'] msg = str(e) ... One of the nice benefits of this approach is that the message printed can be easily changed after the exception is caught. For example, it could be converted to German. try: raise NameError(name, template="name '{0}' is not defined.") except NameError as e: print('{}: nicht gefunden.'.format(e.args[0])) A method could be provided to generate the error message from a custom format string: try: raise NameError(name, template="name '{0}' is not defined.") except NameError as e: print(e.render('{}: nicht gefunden.')) Another nice benefit of this approach is that both named and unnamed arguments to the exception are retained and can be processed by the exception handler. Currently this is only true of unnamed arguments. And since named arguments are not currently allowed, this proposal is completely backward compatible. Of course, with this change, the built-in exceptions should be changed to use this new approach. Hopefully over time, others will change the way they write exceptions to follow suit, making it easier to write more capable exception handlers. Conclusion ========== Sorry for the length of the proposal, but I thought it was important to give a clear rationale for it. Hopefully me breaking it into sections made it easier to scan. Comments? [View Less]

19 58

Custom Code Folding: Standardized Rules and Syntax?
by Connor Farrell July 17, 2017

July 17, 2017

Background: I work in scientific computing and use Community Pycharm IDE. I'm a religious follower of the 'readability counts' mantra, and two things I find myself doing often are: - Writing custom code folds to segregate code, from groups of classes in a file, to groups of lines in an individual function. While spacing works great to separate ideas, my IDE allows me to collapse the entirety of the code in exchange for a line of English. For my purposes, this enhances readability immensely, as … [View More]

4 3

Re: [Python-ideas] Python-ideas Digest, Vol 128, Issue 41
by Connor Farrell July 16, 2017

July 16, 2017

Thanks for your feedback, I guess I was a little unclear. In short, I was thinking of a pair of comment tokens (something like #<<, #>>, idk) that would indicate a code fold, like what virtually all IDEs do for classes and methods, but with more granularity. It would allow devs to better organize their code. I agree with what you're saying about separation of language and text editor, but we already have the *typing* module in 3.6, so improved linting and communication is apparently … [View More]game. I have no desire to get the interpreter involved, this is pure linter. A good example would be something like: class A: #<< INTERFACE def foo(): .... def bar(): .... #>> #<< BACKEND def _guts(): .... #>> Would become something like: class A: *>+ INTERFACE* * >+ BACKEND* Where *modern* editors should fold the code. It provides an optional additional layer of granularity above the current system, but has no effect on behaviour otherwise. It increases visual information density in complex functions, large classes, and lets you group classes. It looks stupid with only three functions, but at larger sizes, or with complex code, I'd rather see: def func(f: Callable[[float],float, float]) -> None: *>+* *Input validation* *>+ Some complex algorithm* * >+ Some other complex algorithm* * >+ Generating plot* It adds a human explanation of the code within, an additional level(s) of organization, and easier navigation. It's not for everyone, but I feel like it improves on the idea of modular code at for active devs, without any drawbacks for library users. On Sun, Jul 16, 2017 at 12:00 PM, <python-ideas-request(a)python.org> wrote: > 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: Custom Code Folding: Standardized Rules and Syntax? > (Steven D'Aprano) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 17 Jul 2017 01:15:59 +1000 > From: Steven D'Aprano <steve(a)pearwood.info> > To: python-ideas(a)python.org > Subject: Re: [Python-ideas] Custom Code Folding: Standardized Rules > and Syntax? > Message-ID: <20170716151559.GW3149(a)ando.pearwood.info> > Content-Type: text/plain; charset=us-ascii > > Hi Connor, and welcome! > > On Sun, Jul 16, 2017 at 10:37:26AM -0400, Connor Farrell wrote: > > Background: I work in scientific computing and use Community Pycharm IDE. > > > > I'm a religious follower of the 'readability counts' mantra, and two > things > > I find myself doing often are: > > - Writing custom code folds to segregate code, from groups of classes in > a > > file, to groups of lines in an individual function. While spacing works > > great to separate ideas, my IDE allows me to collapse the entirety of the > > code in exchange for a line of English. For my purposes, this enhances > > readability immensely, as first time users are confronted with an > > explanation of the contents, rather than the code itself with a comment > on > > top. I find comments don't draw the eye, and also don't have the ability > to > > their code as well. > > I'm afraid I'm having a lot of difficulty understanding this. I think > the last sentence is missing a word. Comments don't have the ability to > **what** their (whose?) code? > > Which IDE are you using? When you say it collapses the "entirety of the > code", do you mean the entire file? > > > > - Writing high level code, such as __init__ calls for large aggregates, > > with one keyworded argument per line (plus dict unpackings at the end), > > sort of like a simple XML file. > > Even if I accept that this is a reasonable design for __init__, I would > not agree that it is a reasonable design for "high level code" in > general. > > > > This allows me to make parameters explicit > > for other users, and optionally provide a comment indicating physical > > units, cite sources, and/or give a list of tag/enum options for every > > parameter. In the end I have 30+ line inits, but the readability is 10x > > greater. > > Perhaps I might be convinced if I saw some actual code, but from your > description alone, it doesn't sound particularly more readable. Why > would I want to read citations in the parameter list of a method? I want > to call the method, not do peer review on the theory behind it. > > > > My IDE doesn't yet offer to fold long parameter lists by default, > > but I think it makes sense. > > *shrug* > > Personally, I don't find code folding a big help. Perhaps once in a blue > moon. I'm glad you like it and that it helps you. > > > > In the end, I end up with very well folded code (except for large > parameter > > lists) and a bunch of co-workers asking about all the "editor-fold" > > comments that don't work in their API. > > I'm afraid I'm not understanding you here either. What's an > "editor-fold" comment? What do they mean by API? API for which > application? How does the programming interface to an application relate > to code folding in a text editor? > > > > Python was a trail-blazer in terms of emphasizing the importance of code > > readability and effective syntax. I think that we should consider some > sort > > of standard for folding comments, if not only to promote stronger code > > organizations. I know standards don't usually interact with IDEs, but > hey, > > the 'typing' module is pretty dang nice. > > > > TL;DR: Code folding is great, custom code folding is great, let's upgrade > > it to a language feature. > > What does that even mean? Are you suggesting that the Python interpreter > should raise a SyntaxError or something if your code was written in an > editor that didn't support code folding? How would it know? > > Python is a programming language. The source code is text. I should be > able to write Python code in NotePad if I want. Why should the Python > core devs try to force every text editor and IDE fold code exactly the > same way? That sounds awful to me. People choose different editors > because they like different features, and that may include the > particular way the editor folds code. Or to not fold it at all. > > I'm sorry to be so negative, but I don't understand your proposal, and > the bits that I *think* I understand sound pretty awful to me. Perhaps > you can explain a bit better what you mean and why it should be a > language feature, apart from "I want everyone to lay out their source > code the way I do". Because that's what it sounds like to me. > > > -- > Steve > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > > > ------------------------------ > > End of Python-ideas Digest, Vol 128, Issue 41 > ********************************************* > [View Less]

3 2