[issue38545] Implement setter and deleter on functools.cached_property
New submission from Laurie Opperman : Support setting/updating and clearing the cached value of a cached-property (getter implemented by bpo-21145). Pretty straight-forward to implement The question is whether cached-property updating should be: a) always allowed b) enabled with a cached-property instance attribute c) enabled with the decorated method's class attribute d) enabled with the decorated method's instance attribute e) enabled in a separate decorator (eg functools.updatable_cached_property) Note: options a, b, c, and d will make functools.cached_property a data descriptor. I prefer option b or c, as the decision to make the property updatable becomes the property's definer's. Also, should a warning be raised if a cached value is being overwritten? Should a warning be raised if no cached value is to be deleted? -- components: Library (Lib) messages: 355045 nosy: Epic_Wink priority: normal severity: normal status: open title: Implement setter and deleter on functools.cached_property type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38545] Implement setter and deleter on functools.cached_property
Change by Laurie Opperman : -- keywords: +patch pull_requests: +16417 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16872 ___ Python tracker <https://bugs.python.org/issue38545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38545] Implement setter and deleter on functools.cached_property
Laurie Opperman added the comment:
Turns out, that as a non-data descriptor, a cached property already has
setting/updating and clearing through the normal mechanisms in Python. This
feature request is therefore redundant: perhaps a new issue to document this
inherent behaviour?
Unless you explicitly want to make cached property updating not allowed, but
that's easily implemented in application code by sub-classing
`functools.cached_property` and defining `__set__` and `__delete__` to raise:
class unupdatable_cached_property(functools.cached_property):
def __set__(self, instance, value):
raise AttributeError("can't set attribute")
def __delete__(self, instance):
raise AttributeError("can't delete attribute")
--
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue38545>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38553] Document functools.cached_property supports value updating and clearing
New submission from Laurie Opperman :
As I discovered during working on bpo-38545, `functools.cached_property`
natively supports cached value setting/updating and clearing (via attribute
assignment and deletion, respectively) through mechanisms defined in the
language for non-data descriptors:
class A:
j = 0
@functools.cached_property
def b(self):
self.j += 1
return self.j
a = A()
print(a.b) # 1
print(a.b) # 1
del a.b
print(a.b) # 2
print(a.b) # 2
a.b = 42
print(a.b) # 42
print(a.b) # 42
del a.b
print(a.b) # 3
print(a.b) # 3
I propose that this functionality be documented, for two reasons:
1. To notify developers that this functionality is available, and how to access
it
2. To notify developers that this functionality needs to be explicitly
disabled. This is important as the built-in `property` is the reverse: property
setting and deletion needs to be explicitly implemented
Disabling the value can be achieved by subclassing `functools.cached_property`
and overriding/implementing `__set__` and `__delete__` to raise:
class immutable_cached_property(functools.cached_property):
def __set__(self, instance, value):
raise AttributeError("can't set attribute")
def __delete__(self, instance):
raise AttributeError("can't delete attribute")
Further reading:
- Defining descriptors:
https://docs.python.org/3/reference/datamodel.html#implementing-descriptors
- Descriptor how-to: https://docs.python.org/3/howto/descriptor.html
- Class construction:
https://docs.python.org/3/reference/datamodel.html#creating-the-class-object
--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 355110
nosy: Epic_Wink, docs@python
priority: normal
severity: normal
status: open
title: Document functools.cached_property supports value updating and clearing
type: enhancement
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue38553>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38553] Document functools.cached_property supports value updating and clearing
Laurie Opperman added the comment: @hongweipeng What can be solved? Do you mean `functools.cached_property` should inherit `property`? First, this would break existing code dependant on the functionality of `functools.cached_property` (admittedly, Python 3.8 was release less than two weeks ago). Second, that seems like arbitrary restriction: I'd prefer just to update the documentation -- ___ Python tracker <https://bugs.python.org/issue38553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38483] [venv] Add ~/.venvrc to change module defaults
Laurie Opperman added the comment:
".xrc" usually means a file to be run (by a shell) at shell start, and
therefore is a script of command to run ("rc" seems to come from "runcom", ie
run commands).
INI files usually have a ".ini" or ".cfg" suffix. `virtualenv`, for example,
used an INI file similar to your proposal:
https://virtualenv.pypa.io/en/stable/reference/#configuration-file.
--
nosy: +Epic_Wink
___
Python tracker
<https://bugs.python.org/issue38483>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43532] Add keyword-only fields to dataclasses
Laurie Opperman added the comment: Will this close https://bugs.python.org/issue36077 ? -- nosy: +Epic_Wink ___ Python tracker <https://bugs.python.org/issue43532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42414] unable to document fields of dataclass
Laurie Opperman added the comment: No new mailing list thread, but there is one from January 2020: https://mail.python.org/archives/list/python-id...@python.org/thread/RHB6XFGFVM66AZTRKNTBAKFEVVEYUDD3/ -- nosy: +Epic_Wink ___ Python tracker <https://bugs.python.org/issue42414> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36077] Inheritance dataclasses fields and default init statement
Change by Laurie Opperman : -- keywords: +patch pull_requests: +16808 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17322 ___ Python tracker <https://bugs.python.org/issue36077> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36077] Inheritance dataclasses fields and default init statement
Laurie Opperman added the comment: I've added a PR implementing Daniel L's suggestion -- nosy: +Epic_Wink versions: +Python 3.6 -Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue36077> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36077] Inheritance dataclasses fields and default init statement
Laurie Opperman added the comment: Daniel's suggestion (and my PR) introduce a mechanism that is as far as I know almost completely bakwards-compatible. The only issue is if people were wanting (and acting on) a TypeError to be raised on dataclass construction (which I would say is rare to non-existant), and is the issue raised by the original post. -- ___ Python tracker <https://bugs.python.org/issue36077> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41125] Display exit-codes for abruptly terminated processes in concurrent.futures
New submission from Laurie Opperman : When a process terminates in the process-pool of concurrent.futures.process, it simply gives the exception (with no __cause__): BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending. I would like to include the terminated processes' exit codes in the error, either as part of the message or as a separate exception set as the error's __cause__ -- components: Library (Lib) messages: 372409 nosy: Epic_Wink priority: normal severity: normal status: open title: Display exit-codes for abruptly terminated processes in concurrent.futures type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41125] Display exit-codes for abruptly terminated processes in concurrent.futures
Change by Laurie Opperman : -- keywords: +patch pull_requests: +20324 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21166 ___ Python tracker <https://bugs.python.org/issue41125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36602] Recursive directory list with pathlib.Path.iterdir
Laurie Opperman added the comment: I think I may have broken bedevere-bot by request change reviews before the PR was assigned... -- ___ Python tracker <https://bugs.python.org/issue36602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36964] `python3 -m venv NAME`: virtualenv is not portable
Laurie Opperman added the comment: > Furthermore I do not understand why the simlink is created. I suppose that > `python3` is already on the `PATH`, so what's the purpose of simlink? On machines with multiple Python installs (eg Python 3.6 and Python 3.7, or a distributed Python 3.7 and a user-built Python 3.7), `python3` from PATH may refer to the incorrect installed version. Having a symlink to the the Python executable which built the environment (by default; `--copies` overcomes this) forces an executable. This `python3` symlink still makes it distributable to other machines on the same platform anyway: `/usr/bin/python3` should always be available on other distributions with Python installed normally, and Windows copies the Python executable anyway AFAIK. Across-platform is likely not going to work anyway: it's likely that your virtual environment will contain platform-specific installations of the packages, meaning they won't work on other platforms. If you just want Linux/MacOS portability, check out the Pex project. I agree with VIRTUAL_ENV being relative however -- nosy: +Epic_Wink ___ Python tracker <https://bugs.python.org/issue36964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36964] `python3 -m venv NAME`: virtualenv is not portable
Laurie Opperman added the comment: If you're moving the virtual environment directory in Linux you'll also need to update the shebangs for the scripts/binaries -- ___ Python tracker <https://bugs.python.org/issue36964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36602] Recursive directory list with pathlib.Path.iterdir
Change by Laurie Opperman : -- versions: +Python 3.9 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue36602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36602] Recursive directory list with pathlib.Path.iterdir
New submission from Laurie Opperman : Currently, 'pathlib.Path.iterdir' can only list the contents of the instance directory. It is common to also want the contents of subdirectories recursively. The proposal is for 'pathlib.Path.iterdir' to have an argument 'recursive' which when 'True' will cause 'iterdir' to yield contents of subdirectories recursively. This would be trivial to implement as 'iterdir' can simply yield from subdirectories' 'iterdir'. A decision would have to be made whether to continue to yield the subdirectories, or skip them. Another decision would be for whether each path should be resolved before checking if it is a directory to be recursed into. -- components: Library (Lib) messages: 339959 nosy: Epic_Wink priority: normal severity: normal status: open title: Recursive directory list with pathlib.Path.iterdir type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36602] Recursive directory list with pathlib.Path.iterdir
Laurie Opperman added the comment:
> Is the behaviour you're proposing any different from using `Path.rglob('*')`?
By that logic, we should remove `Path.iterdir()` in favour of `Path.glob('*')`.
In addition, having `iterdir` the way it is makes it easy for subclasses to
extend its functionality (for example, one of my `Path` subclasses allows a
callable to be passed to the `iterdir` which can filter paths)
> One thing you may need to worry about here is the fact that symlinks can have
> cycles, so you may need to do some cycle detection to avoid creating the
> dangerous possibility of infinite loops.
I agree, which is the main reason the current implementation in the
pull-request is to not resolve symlinks: users can subclass and implement
symlink resolving if they want
> There's also the question of whether you want this to be a depth-first or
> breadth-first traversal, and whether you would want both of these to be
> options.
As much as I want to say that I don't see a use-case for breadth-first file
listing (when I list files, I expect the next file provided to be 'next to' the
current file), users currently have no standard-library functionality to
perform breadth-first searches as far as I know: they'd have to implement it
themself or find it in a third-party library
> Slightly related, pathlib.walk was proposed in the past in python-ideas...
I've never really liked the interface to `walk`, personal preference
--
___
Python tracker
<https://bugs.python.org/issue36602>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35279] asyncio uses too many threads by default
Laurie Opperman added the comment: What about making it dependant on memory as well as logical processor count: `n_workers = min(RAM_GB / some_number, N_CORES * 5)` -- nosy: +Epic_Wink ___ Python tracker <https://bugs.python.org/issue35279> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36602] Recursive directory list with pathlib.Path.iterdir
Laurie Opperman added the comment: Having `iterdir(recursive=True)` recurse into symlinks to directories would mean we would either not yield those symlinks, or we yield those symlinks and all other directories. I feel like not yielding directories is the way to go, but it's easy enough to check if a yielded path is a directory in application code. The current implementation of using recursion to list subdirectory contents doesn't seem to allow for the obvious implementation of symlink cycle-detection: keeping track of which (real) directories have been listed. PS: I've updated the pull-request to not follow symlinks to directories. This is not a final decision, but just updating to be in line with what I've implied up to this point -- ___ Python tracker <https://bugs.python.org/issue36602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36602] Recursive directory list with pathlib.Path.iterdir
Laurie Opperman added the comment: I've updated the pull-request to list directories pointed to by listed symbolic links, preventing cyclic listing. An extra instance method `pathlib.Path._iterdir_recursive` was added for this. We still need to decide whether to yield the directories themselves rather than just the files under those directories. Very easy to implement this. One thing I just realised is that a symlink can point to a subdirectory further down the chain. The current implementation will list the files under that directory using the symlink as prefix rather than the full path. Shouldn't matter though. -- ___ Python tracker <https://bugs.python.org/issue36602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36602] Recursive directory list with pathlib.Path.iterdir
Laurie Opperman added the comment: Would this change also have to copy implemented in the new ZipFile Pathlib API? https://bugs.python.org/issue36832 -- ___ Python tracker <https://bugs.python.org/issue36602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
