New submission from sds :
>>> import datetime, locale
>>> locale.getlocale()
('en_US', 'UTF-8')
>>> datetime.datetime.strptime("%c",datetime.datetime.now().strftime("%c"))
Traceback (most recent call last):
File &qu
New submission from sds :
ast parsing error locations are hard to pinpoint.
See https://stackoverflow.com/q/46933995/850781.
--
components: Library (Lib)
files: ast.diff
keywords: patch
messages: 382449
nosy: sam-s
priority: normal
severity: normal
status: open
title: better error
sds added the comment:
On a closer observation, I think you are eminently right.
Idle workers take far far far too much RAM.
In fact, I would like to be able to specify that the workers are to be spinned
up on demand only and terminated immediately when they they are done
sds added the comment:
I don't think you need this complexity - just keep the pool max size and submit
jobs only when the loadavg drops below the threshold.
See my implementation attached.
--
Added file: https://bugs.python.org/file48898/run-at-load-a
sds added the comment:
cf https://github.com/joblib/loky/issues/233
--
___
Python tracker
<https://bugs.python.org/issue39617>
___
___
Python-bugs-list mailin
sds added the comment:
cf https://github.com/joblib/joblib/issues/1006
--
___
Python tracker
<https://bugs.python.org/issue39617>
___
___
Python-bugs-list mailin
New submission from sds :
The number of workers (max_workers) I want to use often depends on the server
load.
Imagine this scenario: I have 64 CPUs and I need to run 200 processes.
However, others are using the server too, so currently loadavg is 50, thus I
will set `max_workers` to (say) 20
sds added the comment:
Upstream claims that this is fixed by
http://git.gnu.org.ua/cgit/gdbm.git/commit/?id=a0d6c1a8
--
___
Python tracker
<https://bugs.python.org/issue13
Change by sds :
--
versions: +Python 3.6 -Python 3.7
___
Python tracker
<https://bugs.python.org/issue13947>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by sds :
--
components: +Library (Lib)
versions: +Python 3.7 -Python 2.7, Python 3.2
___
Python tracker
<https://bugs.python.org/issue13947>
___
___
Pytho
Change by sds :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue13947>
___
___
Python-bugs-list mailing list
Unsubscrib
sds added the comment:
I observe the same behavior on Linux 4.18.0-17-generic #18-Ubuntu
with Python 3.6.7 (default, Oct 22 2018, 11:32:17) [GCC 8.2.0].
gdbm 1.14.1-6:
after
db = dbm.gnu.open("asdf","n")
db["a"] = "124"
db.reorganize()
db.close()
I se
sds added the comment:
thanks for the patch.
alas, I do not build python myself, so I cannot try it.
--
___
Python tracker
<https://bugs.python.org/issue34
New submission from sds :
`dbm` errors should contain file names when appropriate, just like `OSError`.
E.g.:
```
>>> open("fo")
Traceback (most recent call last):
File "", line 1, in
FileNotFoundError: [Errno 2] No such file or directory: 'fo&#x
sds added the comment:
I think consistency would be nice -- so, yes, `dbm.dumb.error` instead of
`ValueError` (or at least a subtype of `dbm.dumb.error`).
Thanks!
--
___
Python tracker
<https://bugs.python.org/issue33
sds added the comment:
Same problem with 3.6.4, start with
>>> from dbm import gnu as gdbm
then the same incorrect behavior
--
versions: +Python 3.6 -Python 2.7
___
Python tracker
<https://bugs.python.or
New submission from sds :
deleting a key from a read-only gdbm should be gdbm.error, not KeyError:
>>> import gdbm
>>> db = gdbm.open("foo","n") # create new
>>> db["a"] = "b"
>>> db.close()
>>> db =
New submission from sds :
gdbm offers a function to quickly find number of records: gdbm_count()
http://www.gnu.org/software/gdbm/manual/html_node/Count.html
It would be nice to be able to call it.
--
components: Library (Lib)
messages: 309483
nosy: sam-s
priority: normal
severity
New submission from sds :
After upgrading to gdbm stable 1.14, I get this:
```
>>> import gdbm
Traceback (most recent call last):
File "", line 1, in
ImportError: dlopen(/.../lib/python2.7/lib-dynload/gdbm.so, 2): Symbol not
found: _gdbm_errno
Referenced from: /..
sds added the comment:
the problem is not present in
Python 3.6.2 (default, Jul 17 2017, 16:44:45):
```
>>> import dbm
>>> import dbm.gnu
>>> db = dbm.gnu.open("foo","c")
>>> "a" in db
False
>>> u"a" in db
New submission from sds:
`in` and `has_key` have different behavior for Unicode keys for `gdbm` in 2.7:
```
>>> import gdbm
>>> db = gdbm.open("foo.gdbm","c")
>>> db.has_key("a")
0
>>> db.has_key(u"a")
0
>>> &q
sds added the comment:
platform:
Python 2.7.13 (default, Jul 18 2017, 09:17:00)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)] on darwin
--
___
Python tracker
<https://bugs.python.org/issue31
22 matches
Mail list logo
