[issue25478] Consider adding a normalize() method to collections.Counter()
David Mertz added the comment:
Raymond wrote:
> The idea is that the method would return a new counter instance
> and leave the existing instance untouched.
Your own first example suggested:
c /= sum(c.values())
That would suggest an inplace modification. But even if it's not that, but
creating a new object, that doesn't make much difference to the end user who
has rebound the name `c`.
Likewise, I think users would be somewhat tempted by:
c = c.scale_by(1.0/c.total) # My property/attribute suggestion
This would present the same attractive nuisance. If the interface was the
slightly less friendly:
freqs = {k:v/c.total for k, v in c.items()}
I think there would be far less temptation to rebind the same name
unintentionally.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25478>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25478] Consider adding a normalize() method to collections.Counter()
David Mertz added the comment: I definitely wouldn't want a mutator that "normalized" counts for the reason Antoine mentions. It would be a common error to normalize then continue meaningless counting. One could write a `Frequency` subclass easily enough. The essential feature in my mind would be to keep an attribute `Counter.total` around to perform the normalization. I'm +1 on adding that to `collections.Counter` itself. I'm not sure if this would be better as an attribute kept directly or as a property that called `sum(self.values())` when accessed. I believe that having `mycounter.total` would provide the right normalization in a clean API, and also expose easy access to other questions one would naturally ask (e.g. "How many observations were made?") ------ nosy: +David Mertz ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33084] Computing median, median_high an median_low in statistics library
David Mertz added the comment: I believe that the current behavior of `statistics.median[|_low|_high\]` is simply broken. It relies on the particular behavior of Python sorting, which only utilizes `.__lt__()` between objects, and hence does not require a total order. I can think of absolutely no way to characterize these as reasonable results: Python 3.7.1 | packaged by conda-forge | (default, Nov 13 2018, 09:50:42) >>> statistics.median([9, 9, 9, nan, 1, 2, 3, 4, 5]) 1 >>> statistics.median([9, 9, 9, nan, 1, 2, 3, 4]) nan -- nosy: +David Mertz ___ Python tracker <https://bugs.python.org/issue33084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40563] Support pathlike objects on dbm/shelve
David Mertz added the comment: If anyone wants to look at my not-yet-complete changes (see other comment), it's https://github.com/DavidMertz/cpython/tree/bpo-45133. It has a different bpo because I filed a duplicate before realizing. I can change the branch name before a PR, but making it work is the more important issue. -- ___ Python tracker <https://bugs.python.org/issue40563> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40563] Support pathlike objects on dbm/shelve
David Mertz added the comment:
I've made the few additional changes to those in this PR. When I work out the
issues, I'll make a new PR. I took out an attempt with `path_t`. However,
here is why I think argument clinic (or something else?!) is actually
intercepting the attempted call:
With my temporary debugging, I have this function in `Modules/_gdbmmodule.c`:
```c
[clinic start generated code]*/
static PyObject *
dbmopen_impl(PyObject *module, PyObject *filename, const char *flags,
int mode)
/*[clinic end generated code: output=9527750f5df90764 input=812b7d74399ceb0e]*/
{
PyObject_Print(filename, stdout, 0);
printf(" from _gdbmmodule.c (XXX)\n");
/* ... rest of function ...*/
```
And I have a very simplified test script:
```python
import _gdbm
import sys
from pathlib import Path
print(sys.version)
path = '/tmp/tmp.db'
db = _gdbm.open(path, 'c')
print("Opened with string path")
db.close()
db = _gdbm.open(Path(path), 'c')
print("Opened with path-like")
db.close()
```
The output of running this is:
```
3.11.0a0
(heads/[bpo-45133](https://bugs.python.org/issue45133)-dirty:0376feb030, Sep 8
2021, 00:39:39) [GCC 10.3.0]
'/tmp/tmp.db' from _gdbmmodule.c (XXX)
Opened with string path
Traceback (most recent call last):
File "/home/dmertz/tmp/pathlike-dbm.py", line 12, in
db = _gdbm.open(Path(path), 'c')
^^^
TypeError: open() argument 1 must be str, not PosixPath
```
So before I get to the first line of the _gdbm.open() function, the TypeError
is already occurring when passed a PosixPath.
--
nosy: +DavidMertz
type: -> enhancement
versions: +Python 3.11 -Python 3.9
___
Python tracker
<https://bugs.python.org/issue40563>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45133] Open functions in dbm submodule should support path-like objects
New submission from David Mertz : Evan Greenup via Python-ideas Currently, in Python 3.9, `dbm.open()`, `dbm.gnu.open()` and `dbm.ndbm.open()` doesn't support path-like object, class defined in `pathlib`. It would be nice to add support with it. -- components: Library (Lib), Tests messages: 401334 nosy: DavidMertz priority: normal severity: normal status: open title: Open functions in dbm submodule should support path-like objects type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45133] Open functions in dbm submodule should support path-like objects
David Mertz added the comment: Oops... I missed prior closely related or identical issue at: https://bugs.python.org/issue40563 -- resolution: -> duplicate ___ Python tracker <https://bugs.python.org/issue45133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
