New submission from Serge Matveenko :
Negative `timedelta` string representation is ambiguous.
```
>>> from datetime import datetime, timedelta
>>> d2 = datetime.now()
>>> d1 = d2 - timedelta(days=42, seconds=5)
>>> str(d2 - d1)
'42 days, 0:00:05'
New submission from Serge Matveenko :
It looks handy to be able to leverage `collections.deque` ability to be sized
it `asyncio.Queue`.
This could provide the ability to implement backpressure in the queue or just
use it as a buffer in messaging systems.
The implementation provided in the
Serge Matveenko added the comment:
I would be happy to submit a PR if there would be an agreement on the format.
--
___
Python tracker
<https://bugs.python.org/issue38
Change by Serge Matveenko :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue33953>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Serge Matveenko :
--
versions: +Python 3.6
___
Python tracker
<https://bugs.python.org/issue33953>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Serge Matveenko :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue38701>
___
___
Python-bugs-list
Change by Serge Matveenko :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue33953>
___
___
Python-bugs-list
Change by Serge Matveenko :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue40616>
___
___
Python-bugs-list
New submission from Serge Matveenko :
There is the corresponding section on the topic here
https://github.com/python/cpython/blob/3.6/Doc/library/secrets.rst#how-many-bytes-should-tokens-use
The current value of 32 bytes is mentioned there correctly.
Unfortunately, there is no way to know
Serge Matveenko added the comment:
Zach, ok I got your point. But there is Python implementation in the library
still which does not conform the one done in C. Such a behavior is tremendously
confusing.
If there is both Python and C implementation in the library they must conform
each other
Serge Matveenko added the comment:
If Python source does conform the one in C, it will be completely fine and
understandable to have such a change and to rely on it in using version checks
or whatever.
--
___
Python tracker
<http://bugs.python.
Serge Matveenko added the comment:
Ok, then the OrderedDict is useless for any advanced hacking like altering the
order in which __setitem__ stores items.
It is just useless Python code and so much appliances missed for this class:(
Thank you all for these completely helpful answers
Serge Matveenko added the comment:
Sorry for reopening. I completely agree with the point that is it not necessary
for Python and C implementations to duplicate each other.
But then the Python OrderedDict implementation should be dropped from the
library source. The code that is there now is
New submission from Serge Matveenko (lig):
Consider this code in Python 3.5.0:
Python 3.5.0 (default, Sep 26 2015, 14:59:25)
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>&
14 matches
Mail list logo
