[issue21061] Is contextlib.redirect_stdout reentrant or not?
New submission from Timothy Pederick: The docs are contradictory on whether or not contextlib.redirect_stdout is reentrant, or reusable-but-not-reentrant. This would seem to be an oversight from issue19403, which probably should have changed "reusable but not reentrant" to "reentrant". Present in both current and upcoming docs: http://docs.python.org/3/library/contextlib.html http://docs.python.org/3.5/library/contextlib.html contextlib.redirect_stdout(new_target) ... This context manager is reusable but not reentrant. 29.6.3.1. Reentrant context managers ... threading.RLock is an example of a reentrant context manager, as are suppress() and redirect_stdout(). ... Note also that being reentrant is not the same thing as being thread safe. redirect_stdout(), for example... -- assignee: docs@python components: Documentation messages: 214801 nosy: docs@python, perey priority: normal severity: normal status: open title: Is contextlib.redirect_stdout reentrant or not? versions: Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue21061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19004] datetime: Read in isoformat() output
New submission from Timothy Pederick: At present, the datetime module does not provide the capability to parse its own output from the isoformat() methods. strptime() can't handle timezones with colons in them (and anyway it seems to me you'd need to try several possible format strings depending on ' ' vs 'T' separators, presence/absence of microseconds, pres/abs timezone...). Adding this capability would be one option (%f already establishes a precedent for adding codes outside of what C supports). Another, perhaps superior option would be a specific method for parsing the output of isoformat(). -- components: Library (Lib) messages: 197482 nosy: perey priority: normal severity: normal status: open title: datetime: Read in isoformat() output type: enhancement versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue19004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14999] ctypes ArgumentError lists arguments from 1, not 0
New submission from Timothy Pederick : The ctypes ArgumentError exception indicates the location of the problem by argument number. It counts arguments starting from 1, not 0 as is typical in Python. Observed An example (anonymised) traceback: Traceback (most recent call last): ... foreign_function(a, b, c, d) ctypes.ArgumentError: argument 2: : wrong type The error here was with the argument "b". Expected Standard, zero-indexed Python counting would suggest that argument 2 should mean "c", and "b" would be argument 1. Rationale - This may be as intended, but for me it violates the principle of least surprise. I *think* this is the vicinity of the bug: http://hg.python.org/cpython/file/696d3631a4a1/Modules/_ctypes/callproc.c#l1103 _ctypes_extend_error(PyExc_ArgError, "argument %d: ", i+1); If I'm right and the "i+1" (here and/or in subsequent lines) is the cause, that definitely makes it look intentional. -- components: ctypes messages: 162251 nosy: perey priority: normal severity: normal status: open title: ctypes ArgumentError lists arguments from 1, not 0 type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue14999> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8662] bytes join cannot join bytes
Timothy Pederick added the comment: Brett: Well, I was more thinking along the lines of making join() recognise when it's been passed a bytes object, rather than changing the semantics of indexing bytes. That would be a bit overdramatic! But if it's wontfix, it's wontfix. Antoine: Yes, the str example was just for comparison, since the behaviour of bytes is generally supposed to be the same as str. (But I'm sure I could think of some silly examples where it could be used.) The bytes problem actually came up in code I was writing... though I later ripped it out and did it differently... -- ___ Python tracker <http://bugs.python.org/issue8662> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8662] bytes join cannot join bytes
New submission from Timothy Pederick :
This code behaves as expected:
>>> ' '.join('cat')
'c a t'
This code does not:
>>> b'\x00'.join(b'cat')
Traceback (most recent call last):
...
b'\x00'.join(b'cat')
TypeError: sequence item 0: expected bytes, int found
Instead, you have to do something like this:
>>> b'\x00'.join(bytes((i,)) for i in b'cat')
b'c\x00a\x00t'
The cause is that indexing a bytes object gives an int, not a bytes. I know,
it's as designed, PEP 3137, etc. But in this specific instance, it causes
Python to behave inconsistently (bytes vs. str) and unintuitively (to me,
anyway).
(Same problem with bytes or bytearray in either position.)
--
files: joinerror.py
messages: 105317
nosy: perey
priority: normal
severity: normal
status: open
title: bytes join cannot join bytes
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file17262/joinerror.py
___
Python tracker
<http://bugs.python.org/issue8662>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
