Working with paths

Hello, I finally had a look at the pathlib module. (Should have done it long ago, but anyway...). Having in mind the replies from my older thread (File system path annotations), what is the best way to support all possible path types? def doit(path: str | bytes | os.PathLike): match path: case

Best practices for using super()

As a follow-up to my yesterday's question - are there any recommendations on the usage of super()? It's clear that super() can be used to invoke parent's: - instance methods - static methods - constants ("static" attributes in the parent class, e.g. super().NUMBER). This all works, but are

Re: Multiple inheritance and a broken super() chain

> > Also, you might find that because of the MRO, super() in your Bottom > class would actually give you what you want. > I knew this, but I wanted to save myself some refactoring, as the legacy code used different signatures for Left.__init__() and Right.__init__(). I realized the formatting of

Multiple inheritance and a broken super() chain

Hello. The legacy code I'm working with uses a classic diamond inheritance. Let me call the classes *Top*, *Left*, *Right*, and *Bottom*. This is a trivial textbook example. The classes were written in the pre-super() era, so all of them initialized their parents and Bottom initialized both Left

Re: File system path annotations

Thank you, Roel. You've answered all my questions. > [PEP 519]: ...as that can be represented with typing.Union[str, bytes, os.PathLike] easily enough and the hope is users > will slowly gravitate to path objects only. I read a lot on Python and, frankly, I don't see this happening. People on

File system path annotations

Hello, what is the preferred way of annotating file system paths? This StackOverflow answer (and a few others) recommend using the str | os.PathLike union. However, byte arrays can be used as paths too, and including them would make the

Re: Python: How to use the 'trace' module programmatically?

Barry wrote: > > > On 15 Feb 2023, at 17:23, Peter Slížik wrote: > > Hello, > > I'm trying to analyze complex Python code. For some specific reasons, I > decided to use tracing instead of a debugger. > > The first thing I tried was: > > python -m trac

Python: How to use the 'trace' module programmatically?

Hello, I'm trying to analyze complex Python code. For some specific reasons, I decided to use tracing instead of a debugger. The first thing I tried was: python -m trace -t /path/to/file.py The output of this command turned out to be completely useless. The reason is that there was a thread

Re: Iterators, iterables and special objects

> Works in what way? You can't use it in a 'for' loop if it doesn't > define __iter__. > class Iterable: def __iter__(self): return Iterator(...) class Iterator: def __next__(self): return # No __iter__ here. # I've just forgotten to def it. With this setup,

Re: True is True / False is False?

Dear Tim, in Python 2, None is a keyword and True and False are just identifiers. In Python 3, all of them are keywords. There is an interesting article by Guido explaining the reason for their different implementations. http://python-history.blogspot.com/2013/11/story-of-none-true-false.html

Re: Iterators, iterables and special objects

> The view are iterables. They can be iterated more than once and used in > other operations. > > The transformers should be once-through iterators because they can be > passed once-through interators. This is important, thank you for pointing it out. > Python's design that iter(iterator) is

Iterators, iterables and special objects

Hi list, two related questions: 1. Why do functions used to iterate over collections or dict members return specialized objects like type(dict.keys()) -> class 'dict_keys' type(dict.values()) -> class 'dict_values' type(dict.items()) -> class 'dict_items' type(filter(..., ...)) -> class 'filter'