Mailman 3 June 2022 - Python-ideas

PEP 671 (late-bound arg defaults), next round of discussion!
by Chris Angelico July 23, 2023

July 23, 2023

I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/ with some additional information about the reference implementation, and some clarifications elsewhere. *PEP 671: Syntax for late-bound function argument defaults* Questions, for you all: 1) If this feature existed in Python 3.11 exactly as described, would you use it? 2) Independently: Is the syntactic distinction between "=" and "=>" a cognitive burden? (It's absolutely valid to say "yes" and "yes", and feel free to … [View More]

43 364

zip(x, y, z, strict=True)
by Ram Rachum Dec. 1, 2022

Dec. 1, 2022

Here's something that would have saved me some debugging yesterday: >>> zipped = zip(x, y, z, strict=True) I suggest that `strict=True` would ensure that all the iterables have been exhausted, raising an exception otherwise. This is useful in cases where you're assuming that the iterables all have the same lengths. When your assumption is wrong, you currently just get a shorter result, and it could take you a while to figure out why it's happening. What do you think?

27 179

Confusing naming of Optional type should be changed
by nverich07＠gmail.com July 12, 2022

July 12, 2022

(I apologize in advance if I've posted anything incorrectly before, I believe I might have sent this in python-dev instead but not sure as it's not appearing in the posts for my account). I am aware this is clarified in the Python documentation for the typing module but I and others have thought the naming of Optional is still quite confusing by itself. "Note that this is not the same concept as an optional argument, which is one that has a default. An optional argument with a default does … [View More]

5 9

dataclass field argument to allow converting value on init
by Dexter Hill July 2, 2022

July 2, 2022

The idea is to have a `default_factory` like argument (either in the `field` function, or a new function entirely) that takes a function as an argument, and that function, with the value provided by `__init__`, is called and the return value is used as the value for the respective field. For example: ```py @dataclass class Foo: x: str = field(init_fn=chr) f = Foo(65) f.x # "A" ``` The `chr` function is called, given the value `65` and `x` is set to its return value of `"A"`. I understand … [View More]that there is both `__init__` and `__post_init__` which can be used for this purpose, but sometimes it isn't ideal to override them. If you overrided `__init__`, and were using `__post_init__`, you would need to manually call it, and in my case, `__post_init__` is implemented on a base class, which all other classes inherit, and so overloading it would require re-implementing the logic from it (and that's ignoring the fact that you also need to type the field with `InitVar` to even have it passed to `__post_init__` in the first place). I've created a proof of concept, shown below: ```py def initfn(fn, default=None): class Inner: def __set_name__(_, owner_cls, owner_name): old_setattr = getattr(owner_cls, "__setattr__") def __setattr__(self, attr_name, value): if attr_name == owner_name: # Bypass `__setattr__` self.__dict__[attr_name] = fac(value) else: old_setattr(self, attr_name, value) setattr(owner_cls, "__setattr__", __setattr__) def fac(value): if isinstance(value, Inner): return default return fn(value) return field(default=Inner()) ``` It makes use of the fact that providing `default` as an argument to `field` means it checks the value for a `__set_name__` function, and calls it with the class and field name as arguments. Overriding `__setattr__` is just used to catch when a value is being assigned to a field, and if that field's name matches the name given to `__set_name__`, it calls the function on the value, at sets the field to that instead. It can be used like so: ```py @dataclass class Foo: x: str = initfn(fn=chr, default="Z") f = Foo(65) f2 = Foo() f.x # "A" f2.x # "Z" ``` It adds a little overhead, especially with having to override `__setattr__` however, I believe it would have very little overhead if directly implemented in the dataclass library. Even in the case of being able to override one of the init functions, I still think it would be nice to have as a quality of life feature as I feel calling a function is too simple to want to override the functions, if that makes sense. Thanks. Dexter [View Less]

5 22

Typescript-Like Notational Shortcuts
by kevinlu1248＠gmail.com July 1, 2022

July 1, 2022

On the theme of the addition of pip operators to indicate union, I was wondering what people think of using the following shortcuts for type hints. * type[] be a short-hand for List[type] * [type1, type2, type3] be a shorthand for Tuple[type1, type2, type3] * similar ideas for dictionaries and callables with (perhaps with javascript-like arrow notations?) I just think something like this would be easier to read. For example, a lot of functions that return tuples generally are immediately … [View More]

3 2

Pip & gpg story
by J. Pic June 28, 2022

June 28, 2022

Hi Currently we can upload signed packages on pypi. Shouldn't pip have a keyring of thrusted projects or developers and enforce whitelisting of untrusted packages, either through a requirement flag or through an interactive question in CLI? I think this would help with user security if we want to keep pypi open for upload to all on the long term. Thanks for your feedback

3 2

Generalized deferred computation in Python
by David Mertz, Ph.D. June 26, 2022

June 26, 2022

Here is a very rough draft of an idea I've floated often, but not with much specification. Take this as "ideas" with little firm commitment to details from me. PRs, or issues, or whatever, can go to https://github.com/DavidMertz/peps/blob/master/pep-9999.rst as well as mentioning them in this thread. PEP: 9999 Title: Generalized deferred computation Author: David Mertz <dmertz(a)gnosis.cx> Discussions-To: https://mail.python.org/archives/list/python-ideas@python.org/thread/ Status: … [View More]Draft Type: Standards Track Content-Type: text/x-rst Created: 21-Jun-2022 Python-Version: 3.12 Post-History: Abstract ======== This PEP proposes introducing the soft keyword ``later`` to express the concept of deferred computation. When an expression is preceded by the keyword, the expression is not evaluated but rather creates a "thunk" or "deferred object." Reference to the deferred object later in program flow causes the expression to be executed at that point, and for both the value and type of the object to become the result of the evaluated expression. Motivation ========== "Lazy" or "deferred" evaluation is useful paradigm for expressing relationships among potentially expensive operations prior their actual computation. Many functional programming languages, such as Haskell, build laziness into the heart of their language. Within the Python ecosystem, the popular scientific library `dask-delayed <dask-delayed>`_ provides a framework for lazy evaluation that is very similar to that proposed in this PEP. .. _dask-delayed: https://docs.dask.org/en/stable/delayed.html Examples of Use =============== While the use of deferred computation is principally useful when computations are likely to be expensive, the simple examples shown do not necessarily use such expecially spendy computations. Most of these are directly inspired by examples used in the documentation of dask-delayed. In dask-delayed, ``Delayed`` objects are create by functions, and operations create a *directed acyclic graph* rather than perform actual computations. For example:: >>> import dask >>> @dask.delayed ... def later(x): ... return x ... >>> output = [] >>> data = [23, 45, 62] >>> for x in data: ... x = later(x) ... a = x * 3 ... b = 2**x ... c = a + b ... output.append(c) ... >>> total = sum(output) >>> total Delayed('add-8f4018dbf2d3c1d8e6349c3e0509d1a0') >>> total.compute() 4611721202807865734 >>> total.visualize() .. figure:: pep-9999-dag.png :align: center :width: 50% :class: invert-in-dark-mode Figure 1. Dask DAG created from simple operations. Under this PEP, the soft keyword ``later`` would work in a similar manner to this dask.delayed code. But rather than requiring calling ``.compute()`` on a ``Delayed`` object to arrive at the result of a computation, every reference to a binding would perform the "compute" *unless* it was itself a deferred expression. So the equivalent code under this PEP would be:: >>> output = [] >>> data = [23, 45, 62] >>> for later x in data: ... a = later (x * 3) ... b = later (2**x) ... c = later (a + b) ... output.append(later c) ... >>> total = later sum(output) >>> type(total) # type() does not un-thunk <class 'DeferredObject'> >>> if value_needed: ... print(total) # Actual computation occurs here 4611721202807865734 In the example, we assume that the built-in function `type()` is special in not counting as a reference to the binding for purpose of realizing a computation. Alternately, some new special function like `isdeferred()` might be used to check for ``Deferred`` objects. In general, however, every regular reference to a bound object will force a computation and re-binding on a ``Deferred``. This includes access to simple names, but also similarly to instance attributes, index positions in lists or tuples, or any other means by which an object may be referenced. Rejected Spellings ================== A number of alternate spellings for creating a ``Deferred`` object are possible. This PEP-author has little preference among them. The words ``defer`` or ``delay``, or their past participles ``deferred`` and ``delayed`` are commonly used in discussions of lazy evaluation. All of these would work equally well as the suggested soft keyword ``later``. The keyword ``lazy`` is not completely implausible, but does not seem to read as well. No punctuation is immediately obvious for this purpose, although surrounding expressions with backticks is somewhat suggestive of quoting in Lisp, and perhaps slightly reminiscent of the ancient use of backtick for shell commands in Python 1.x. E.g.:: might_use = `math.gcd(a, math.factorial(b))` Relationship to PEP-0671 ======================== The concept of "late-bound function argument defaults" is introduced in :pep:`671`. Under that proposal, a special syntactic marker would be permitted in function signatures with default arguments to allow the expressions indicated as defaults to be evaluated at call time rather than at runtime. In current Python, we might write a toy function such as:: def func(items=[], n=None): if n is None: n = len(items) items.append("Hello") print(n) func([1, 2, 3]) # prints: 3 Using the :pep:`671` approach this could be simplified somewhat as:: def func(items=[], n=>len(items)): # late-bound defaults act as if bound here items.append("Hello") print(n) func([1, 2, 3]) # prints: 3 Under the current PEP, evaluation of a ``Deferred`` object only occurs upon reference. That is, for the current toy function, the evaluation would not occur until the ``print(n)`` line.:: def func(items=[], n=later len(items)): items.append("Hello") print(n) func([1, 2, 3]) # prints: 4 To completely replicate the behavior of PEP-0671, an extra line at the start of the function body would be required:: def func(items=[], n=later len(items)): n = n # Evaluate the Deferred and re-bind the name n items.append("Hello") print(n) func([1, 2, 3]) # prints: 3 References ========== https://github.com/DavidMertz/peps/blob/master/pep-9999.rst Copyright ========= This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. [View Less]

18 55

Adopting better naming conventions (food for thought)
by abed...＠gmail.com June 24, 2022

June 24, 2022

I was reading some of Kevlin Henney's views on naming conventions <https://kevlinhenney.medium.com/exceptional-naming-6e3c8f5bffac>, and I realized that, of the 65 classes that make up Python's built-in exceptions <https://docs.python.org/3/library/exceptions.html#exception-hierarchy>, only 8 (by my count) satisfy Henney's pretty basic concept of a good Exception name: *The name should represent whatever the problem is, and should do so directly and specifically. To add … [View More]Exception to the end is either redundant — so remove it — or an indication of a poor name — so rename it.* Those are: SystemExit, KeyboardInterrupt, GeneratorExit, Exception, StopIteration, StopAsyncIteration, Warning, and BaseException (though Henney also discourages the use of "Base" in a base-class's name) I'm sure there are others throughout the standard library too. I always caution novice programmers to err on the side of pragmatism over dogmatic adherence to "sacred truths". To that end: 1) I realize changing built-in exception names would break backwards compatibility and probably isn't worth doing. This post is more intended as food for thought going forward and to bring more attention to Kevlin Henney's ideas. 2) I think many of the built-in exceptions are actually fine, particularly ones that represent a broad class of more specific exceptions like OSError. I don't think OSError has a specific enough name to be raised on its own (perhaps it should be abstract or otherwise not directly instantiable?), but catching error categories can be pretty helpful even if they don't lend themselves to explicit names. I would suggest a more ideal naming scheme would be something like the following: - BaseException -> Exception # The text for GeneratorExit <https://docs.python.org/3/library/exceptions.html#GeneratorExit> seems to indicate that in Python, an Error is considered a subclass of an Exception, so this naming seems more appropriate though it contradicts other views on the distinction between Exception and Error <https://stackoverflow.com/questions/5813614/what-is-difference-between-erro…> . - SystemExit - *KeyboardInterrupt -> UserInterrupt *#This is supposed to capture a user-initiated exit, whether it came from a keyboard or a magic wand is generally much less relevant - GeneratorExit - Exception -> Error - *StopIteration* - *StopAsyncIteration* - *ArithmeticError* - FloatingPointError -> Not used, get rid of it? - OverflowError -> Overflow - ZeroDivisionError -> ZeroDivision or Undefined - *AssertionError -> Contradiction or AssertionViolation* - *AttributeError* - *+ AttributeNotFound or AttributeUnavailable* - *+ AttributeUnassignable* - *BufferError* - *<specific errors>* - *EOFError -> EndOfFile* - *ImportError * - ModuleNotFoundError -> ModuleNotFound - *LookupError * - *IndexError -> IndexOutOfBounds* - *KeyError -> KeyNotFound* - *MemoryError -> OutOfMemory * - *NameError -> InvalidName (Not needed?) * - UnboundLocalError -> UnboundLocal - *OSError * - BlockingIOError -> BlockingIO - ChildProcessError -> ChildProcessFailed - ConnectionError - BrokenPipeError -> BrokenPipe - ConnectionAbortedError -> ConnectionAborted - ConnectionRefusedError -> ConnectionRefused - ConnectionResetError -> ConnectionReset - FileExistsError -> FileAlreadyExists - FileNotFoundError -> FileNotFound - InterruptedError -> Interrupted - IsADirectoryError -> NotAFile - NotADirectoryError -> NotADirectory - PermissionError -> PermissionDenied - ProcessLookupError -> ProcessNotFound - TimeoutError -> Timeout - *ReferenceError -> ReferentCollected? * - *RuntimeError * - NotImplementedError -> NotImplemented - RecursionError -> MaxRecursionDepthExceeded or RecursionOverflow - *SyntaxError * - IndentationError - TabError -> InconsistentIndentation - *SystemError -> SystemFailure* - *TypeError -> IncompatibleType * - *ValueError * - UnicodeError - UnicodeDecodeError - UnicodeEncodeError - UnicodeTranslateError - *Warning* # Should this be under Error? - DeprecationWarning -> Deprecated - PendingDeprecationWarning -> Obsolete - RuntimeWarning - SyntaxWarning - UserWarning - FutureWarning - ImportWarning - UnicodeWarning - BytesWarning - EncodingWarning - ResourceWarning [View Less]

2 1

Ellipsis (...) to be roughly synonymous with *<varname> in destructuring but without capture.
by Steve Jorgensen June 22, 2022

June 22, 2022

This is based on previous discussions of possible ways of matching all remaining items during destructuring but without iterating of remaining final items. This is not exactly a direct replacement for that idea though, and skipping iteration of final items might or might not be part of the goal. In this proposal, the ellipsis (...) can be used in the expression on the left side of the equals sign in destructuring anywhere that `*<varname>` can appear and has approximately the same … [View More]

2 3

Re: Add a line_offsets() method to str
by Inada Naoki June 21, 2022

June 21, 2022

On Tue, Jun 21, 2022 at 3:49 AM Marco Sulla <Marco.Sulla.Python(a)gmail.com> wrote: > > On Sun, 19 Jun 2022 at 03:06, Inada Naoki <songofacandy(a)gmail.com> wrote: > > FWIW, I had proposed str.iterlines() to fix incompatibility between > > IO.readlines() and str.splitlines(). > > It's a good idea IMHO. In your mind, str.iterlines() will find only > \n, \r and \r\n, as IO.readlines() do? I ask this because > str.splitlines() finds all line boundary chars.… [View More]

1 0

Null wildcard in de-structuring to ignore remainder and stop iterating
by Steve Jorgensen June 20, 2022

June 20, 2022

A contrived use case: with open('document.txt', 'r') as io: (line1, line2, *) = io It is possible to kind of achieve the same result using `*_` except that would actually read all the lines from the file, even if we only want the first 2. …so I am suggesting that we use the bare `*` here to mean that we don't care whether there are additional items in the sequence, _and_ we want to stop iterating.

9 26

Bare wildcard in de-structuring to ignore remainder and stop iterating (restart)
by Steve Jorgensen June 20, 2022

June 20, 2022

Restarting this with an improved title "Bare" vs "Raw", and I will try not to digress so much in the new thread. My suggestion is to allow a bare asterisk at the end of a desctructuring expression to indicate that additional elements are to be ignored if present and not iterated over if the rhs is being evaluated by iterating. (first, second, *) = items This provides a way of using destructuring from something that will be processed by iterating and for which the number of items might be … [View More]

10 29

Add a line_offsets() method to str
by Jonathan Slenders June 20, 2022

June 20, 2022

Hi everyone, Today was the 3rd time I came across a situation where it was needed to retrieve all the positions of the line endings (or beginnings) in a very long python string as efficiently as possible. First time, it was needed in prompt_toolkit, where I spent a crazy amount of time looking for the most performant solution. Second time was in a commercial project where performance was very critical too. Third time is for the Rich/Textual project from Will McGugan. (See: https://twitter.com/… [View More]willmcgugan/status/1537782771137011715 ) The problem is that the `str` type doesn't expose any API to efficiently find all \n positions. Every Python implementation is either calling `.index()` in a loop and collecting the results or running a regex over the string and collecting all positions. For long strings, depending on the implementation, this results in a lot of overhead due to either: - calling Python functions (or any other Python instruction) for every \n character in the input. The amount of executed Python instructions is O(n) here. - Copying string data into new strings. The fastest solution I've been using for some time, does this (simplified): `accumulate(chain([0], map(len, text.splitlines(True))))`. The performance is great here, because the amount of Python instructions is O(1). Everything is chained in C-code thanks to itertools. Because of that, it can outperform the regex solution with a factor of ~2.5. (Regex isn't slow, but iterating over the results is.) The bad things about this solution is however: - Very cumbersome syntax. - We call `splitlines()` which internally allocates a huge amount of strings, only to use their lengths. That is still much more overhead then a simple for-loop in C would be. Performance matters here, because for these kind of problems, the list of integers that gets produced is typically used as an index to quickly find character offsets in the original string, depending on which line is displayed/processed. The bisect library helps too to quickly convert any index position of that string into a line number. The point is, that for big inputs, the amount of Python instructions executed is not O(n), but O(1). Of course, some of the C code remains O(n). So, my ask here. Would it make sense to add a `line_offsets()` method to `str`? Or even `character_offsets(character)` if we want to do that for any character? Or `indexes(...)/indices(...)` if we would allow substrings of arbitrary lengths? Thanks, Jonathan [View Less]

12 19

Add tz argument to date.today()
by Lucas Wiman June 19, 2022

June 19, 2022

Since "today" depends on the time zone, it should be an optional argument to date.today(). The interface should be the same as datetime.now(tz=None), with date.today() returning the date in the system time zone. Rationale: It is common for processes to run in different timezones than the relevant end user. The most common case is probably a server running in UTC, which needs to do date calculations in timezones elsewhere. As a contrived example, you might do something like: tomorrow = … [View More]

3 2

Type checking for **kwargs based on its use
by Mauricio Villegas June 17, 2022

June 17, 2022

Look at the following example: ``` def some_function(f1: int): assert isinstance(f1, int) def other_function(f0: str, **kwargs): assert isinstance(f0, str) some_function(**kwargs) other_function(f0='a', f1='b') ``` I would expect a static type checker to warn that f1='b' is wrong because the type should be int. There shouldn't be a need to add a type to **kwargs since what is accepted can be deduced from how it is used. Note that some_function could be defined in another module … [View More]

3 2

TaskGroup and create_task method.
by Abdulla Al Kathiri June 13, 2022

June 13, 2022

Hello all, I am trying the TaskGroup class in the python 3.11 beta version. And I like it a lot. It makes asynchronous programming intuitive enough even for the less experienced like myself. I can see myself teaching this to my colleges when they run linux parallel subprocesses. I will try to convince our IT department to download 3.11 when it’s officially out mostly because of new improved asyncio support. The speed gain will be another good justification. However, excuse my ignorance, I … [View More]

1 0

A “big picture” question.
by James Johnson June 11, 2022

June 11, 2022

The unasked question never gets answered. I don’t know if you can practically use the following suggestion, but it may be clarifying anyway. When an amateur develops code incorrectly, s/he sometimes ends up with a code object that doesn’t run because of intermediate compiler optimizations. As an example, you could ask a high school class to individually build a 26x26 grid, with the first line having abcdef…xyz; the second line having zabcd…wxy, and so on. This often results in code that has … [View More]

4 3

Re: A “big picture” question.
by Steven D'Aprano June 10, 2022

June 10, 2022

On Fri, Jun 10, 2022 at 09:59:36PM -0500, James Johnson wrote: > I guess I was jumping to conclusions. Thank you for taking the time to look > at my email. > > I apologize if I wasted your time. No stress -- opening issues up for discussion is not a waste of time. This would be a good time to mention that there have been previous requests to have more control of what optimizations the Python byte-code compiler performs, mostly for the benefit of profiling applications. While … [View More]

2 1

disallow assignment to unknown ssl.SSLContext attributes
by Thomas Grainger June 10, 2022

June 10, 2022

I was debugging some code that was using TLSv1.2 when I expected it to only support TLSv1.3, I tracked it down to a call to: context.miunimum_version = ssl.TLSVersion.TLSv1_3 it should have been: context.minimum_version = ssl.TLSVersion.TLSv1_3 I'd like invalid attribute assignment to be prevented at runtime

13 32

default as a keyword argument for dict.get and dict.pop
by martineznicolas41541＠gmail.com June 8, 2022

June 8, 2022

Hello! Do you know if there has been discussions around why is the default argument is positional only in the dict methods get and pop? I think ``` d.get(key, default=3) ``` way more readable than ``` d.get(key, 3) ``` specially since max and min builtin functions use default as a keyword argument.

6 6

Addition to fnmatch.py
by John Carter June 7, 2022

June 7, 2022

I’d like to propose a simple addition to the 'fnmatch' module. Specificity a function that returns a list of names that match a pattern AND a list of those that don't. In a recent project I found that I wished to split a list of files and move those that matched a pattern to one folder and those that didn't to another folder. I was using fnmatch.filter to select the first set of files and then a list comprehension to generate the second set. For a small number of files (~ 10) this was … [View More]perfectly adequate. However as I needed to process many files (>>10000) the execution time was very significant. Profiling the code showed that the time was spent in generating the second set. I tried a number of solutions including designing a negative filter, walking the file system to find those files that had not been moved and using more and more convoluted ways to improve the second selection. Eventually I gave in and hacked a local copy of fnmatch.py as below: def split(names, pat): """Return the subset of the list NAMES that match PAT.""" """Also returns those names not in NAMES""" result = [] notresult = [] pat = os.path.normcase(pat) pattern_match = _compile_pattern(pat) if os.path is posixpath: # normcase on posix is NOP. Optimize it away from the loop. for name in names: if not pattern_match(name): result.append(name) else: notresult.append(name) else: for name in names: if not pattern_match(os.path.normcase(name)): result.append(name) else: notresult.append(name) return result, notresult The change is the addition of else clauses to the if not pattermath statements. This solved the problem and benchmarking showed that it only took a very small additional time (20ms for a million strings) to generate both lists Number of tests cases 1000000 Example data ['Ba1txmKkiC', 'KlJx.f_AGj', 'Umwbw._Wa9', '4YlgA5LVpI’] Search for '*A*' Test Time(sec) Positive Negative WCmatch.filter 1.953125 26211 0 filter 0.328125 14259 0 split 0.343750 14259 85741 List Comp. 270.468751 14259 85741 The list comprehension [x for x in a if x not in b]*, was nearly 900 times slower. ‘fnmatch’ was an appropriate solution to this problem as typing ‘glob’ style search patterns was easier than having to enter regular expressions when prompted by my code. I would like to propose that split, even though it is very simple, be included in the 'fnmatch' module. John *a is the original and b is those that match. [View Less]

14 26

Add .except() and .only(), and .values_at(). instance methods to dict
by Steve Jorgensen June 6, 2022

June 6, 2022

I think these are an extremely common needs that are worth having standard methods for. If adding instance methods seems like a bad idea, then maybe add functions to the standard library that perform the same operations. m = {'a': 123, 'b': 456, 'c': 789} m.except(('a', 'c')) # {'b': 456} m.only(('b', 'c')) # {'b': 456, 'c': 789} m.values_at(('a', 'b')) # [123, 456] …or… from mappings import except, only, values_at m = {'a': 123, 'b': 456, 'c': 789} except(m, ('a', 'c')) # {'b': 456} … [View More]

6 5

Slice 'size' parameter (in the style of pairwise)
by Kevin June 4, 2022

June 4, 2022

I might be posting this prematurely, but I had an idea and wanted to float it. Also, I'm new here so hopefully this is appropriate. How about augmenting slicing with an additional parameter 'size' (name chosen to achieve alliteration; 'start', 'stop', 'step', and 'size'), as such: >>> a_list = [0, 1, 2, 3, 4, 5, 6, 7] >>> a_list[1:5::4] # start=1, stop=5, step=1 (default), size=4 [(1, 2, 3, 4), (2, 3, 4, 5), (3, 4, 5, 6), (4, 5, 6, 7)] >>> a_list[::2:3] [(0, 1, 2), (… [View More]

2 1

Expand the try-expect syntax to support conditional expect block
by Nadav Misgav June 3, 2022

June 3, 2022

Hello, I was thinking of a way to expand the current try-expect block to support condinitial expect block. I was imagining the new syntax as try: expression block expect Exception if condition expression block where the expect expression block would only run if the condition is met else it would raise the exception, for example the following code try: config = get_config() except Exception: if use_default: config = default else: raise would be converted … [View More]

8 11

Means of avoiding accidental import of/from an Implicit Namespace Package
by Steve Jorgensen June 1, 2022

June 1, 2022

More than once, I've had bugs that were hard to track down because I was accidentally using an implicit namespace without realizing it. The last time this happened, it was a typo, and my init file was named `_init__.py` instead of `__init__.py`. The init file imported from sub-modules, including 1 with a class that was supposed be be registered via an `__init_subclass__` callback that was not happening. I'm sure that implicit namespace packages are here to stay, and I imagine I will actually … [View More]

1 0