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
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/issu
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
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
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
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
Laurie Opperman added the comment:
Will this close https://bugs.python.org/issue36077 ?
--
nosy: +Epic_Wink
___
Python tracker
<https://bugs.python.org/issue43
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
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/issu
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.o
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 ra
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
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/issu
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/issue36
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 Pytho
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.o
Change by Laurie Opperman :
--
versions: +Python 3.9 -Python 3.8
___
Python tracker
<https://bugs.python.org/issue36602>
___
___
Python-bugs-list mailin
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 'rec
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 f
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/issue35
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 enou
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 direct
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/issue36
23 matches
Mail list logo
