[issue45511] Batch-mode input() limited to 4095 characters on *NIX
Romuald Brunet added the comment: This does not seems to be a copypaste issue. I've re-tested using xdotool to "manually" type 5000 characters in to a X terminal (gnome-terminal and xterm, to be sure) and got the same result. I also have 4 read(0, "...") with the last one ending with a "\n", that's a very strange behavior I tried to test the same thing on a macOS version, but the input() / terminal would not let me insert more than 1024 characters -- ___ Python tracker <https://bugs.python.org/issue45511> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45544] Close 2to3 issues and list them here
Change by Romuald Brunet : -- nosy: +Romuald nosy_count: 3.0 -> 4.0 pull_requests: +27383 pull_request: https://github.com/python/cpython/pull/16826 ___ Python tracker <https://bugs.python.org/issue45544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45511] input() method limited to 4095 characters on *NIX
New submission from Romuald Brunet : When run in non-interactive mode and with a TTY stdin, the input() method will not read more than 4095 characters Simple example: >>> foo = input() # paste a 5000 character pasteboard (one line) >>> print(len(foo)) 4095 Note that this will **not** happen when using an interactive shell (using python -i on the same script will not have the 4095 limit) I've traced the issue (I think) to the fgets function called from my_fgets in myreadline.c, but I have no clue as to how one might fix this. -- components: Interpreter Core messages: 404179 nosy: Romuald priority: normal severity: normal status: open title: input() method limited to 4095 characters on *NIX type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45511> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42524] [doc] pdb access to return value
Change by Romuald Brunet : -- pull_requests: +26106 pull_request: https://github.com/python/cpython/pull/27612 ___ Python tracker <https://bugs.python.org/issue42524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42524] [doc] pdb access to return value
Romuald Brunet added the comment: I'm not sure I follow. You wish to "simply" update the doc? (and not update the retval to allow storing it into a varible. I'm OK with that) But if we choose this, I'm not sure what needs changing in the doctests :-? Another interrogation: is the use locals() really necessary? I can see that I can simply use `__return__` to access the return object. Is there a reason to access it via locals() inside pdb? -- ___ Python tracker <https://bugs.python.org/issue42524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26779] pdb continue followed by an exception in the same frame shows incorrect frame linenumber
Romuald Brunet added the comment: I meant: this issue is fixed in 3.10 -- ___ Python tracker <https://bugs.python.org/issue26779> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26779] pdb continue followed by an exception in the same frame shows incorrect frame linenumber
Romuald Brunet added the comment: Ran into a similar issue today This issue (and mine is fixed) in python 3.10. Most probaly related to #24565 fix -- nosy: +Romuald versions: +Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue26779> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43703] xml.etree parser does not accept valid control characters
Romuald Brunet added the comment: Thanks for the quick reply We're getting data from about a hundred different providers around the world; some of them not really keen on standards, so we already have some hacks to fix invalid XML. We'll add one to the list In that particular case, the XML was invalid anyway since it was an XML 1.0 document, and the character was sent as "binary" (\x19) -- ___ Python tracker <https://bugs.python.org/issue43703> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43703] xml.etree parser does not accept valid control characters
New submission from Romuald Brunet : Python XML parser (xml.etree) does not seems to allow control characters that are invalid in XML 1.0, but valid in XML 1.1 [1] [2] Considering the following sample: import xml.etree.ElementTree as ET bad = 'bar baz' print(ET.fromstring(bad)) The parser raises the following error: ParseError: reference to invalid character number: line 1, column 30 [1] https://www.w3.org/TR/xml11/Overview.html#charsets [2] https://www.w3.org/TR/xml11/Overview.html#sec-xml11 -- components: XML messages: 390050 nosy: Romuald priority: normal severity: normal status: open title: xml.etree parser does not accept valid control characters versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43703> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42524] pdb access to return value
Change by Romuald Brunet : -- keywords: +patch pull_requests: +22470 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23601 ___ Python tracker <https://bugs.python.org/issue42524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42524] pdb access to return value
New submission from Romuald Brunet : When using the pdb module, there is currently no way to easy access the current return value of the stack This return value is accessed by the 'retval command' I propose using the currently unused argument to allow storing the return value in the local variables, accessible via the debugger For example: def foo(): debugger() return ComplexObject() def bar(): return foo() (pdb) retval (pdb) retval zz (pdb) zz.attribute 'some value' -- components: Library (Lib) messages: 382259 nosy: Romuald priority: normal severity: normal status: open title: pdb access to return value type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17393] stdlib import mistaken for local by import_fixer
Change by Romuald Brunet : -- keywords: +patch pull_requests: +16376 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16826 ___ Python tracker <https://bugs.python.org/issue17393> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17393] stdlib import mistaken for local by import_fixer
Romuald Brunet added the comment: Confirming that this issue is still present on 3.8 (and working on a fix) -- ___ Python tracker <https://bugs.python.org/issue17393> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17393] stdlib import mistaken for local by import_fixer
Change by Romuald Brunet : -- nosy: +Romuald ___ Python tracker <https://bugs.python.org/issue17393> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34307] NullHandler init refusing arguments
Change by Romuald Brunet : -- keywords: +patch pull_requests: +8111 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34307] NullHandler init refusing arguments
New submission from Romuald Brunet : Context: I'm using a custom Handler that relies on a third-party library that may not be present try: from acme.logging import CustomHandler as BaseHandler except ImportError: import logging.NullHandler as BaseHandler class MoreCustomHandler(BaseHandler): def handle(self): self.stuff() The logging configuration has some arguments for the CustomHandler. The problem is that the NullHandler does not accept them. I expected it to be a "dummy" handler that might accept any argument -- components: Library (Lib) messages: 322861 nosy: Romuald priority: normal severity: normal status: open title: NullHandler init refusing arguments type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32680] smtplib SMTP instances missing a default sock attribute
Romuald Brunet <romuald.bru...@gmail.com> added the comment:
My use case:
try:
s = SMTP('myhost')
s.do_some_sending()
finaly:
if s is not None and s.sock is not None:
s.quit()
But I realize just now that in that case, if s was initialized correctly, its
sock was inevitably set
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32680>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32680] smtplib SMTP instances missing a default sock attribute
Change by Romuald Brunet <romuald.bru...@gmail.com>: -- keywords: +patch pull_requests: +5192 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32680> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32680] smtplib SMTP instances missing a default sock attribute
New submission from Romuald Brunet <romuald.bru...@gmail.com>: SMTP instances from the smtplib module are not creating their sock attribute consistently after __init__ When host is sent as parameter a sock object is created (and hopefully, connected) When the host is not sent, the sock attribute doesn't exist at all -- messages: 310764 nosy: Romuald priority: normal severity: normal status: open title: smtplib SMTP instances missing a default sock attribute ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32680> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24084] pstats: sub-millisecond display
Romuald Brunet <romuald.bru...@gmail.com> added the comment: I figured we didn't want to change the size of the columns (+12 COL), but this could easily be done yes -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue24084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31443] Possibly out of date C extension documentation
Romuald Brunet added the comment:
I'm not sure this is relevant, but I've just made a simple test on Windows (7)
with my C extension using { … .tp_new = PyType_GenericNew } and the compiler
did not complain (also the code worked as expected)
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31443>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31443] Possibly out of date C extension documentation
New submission from Romuald Brunet: In the "Defining New Types documentation" basics about tp_new -> PyType_GenericNew, the doc states: > We’d like to just assign this to the tp_new slot, but we can’t, for > portability sake, On some platforms or compilers, we can’t statically > initialize a structure member with a function defined in another C > module, so, instead, we’ll assign the tp_new slot in the module > initialization function just before calling PyType_Ready(): But looking a python C code itself [1] does seem to do this. So I'm guessing that part of the documentation is now irrelevant and the example could just assign PyType_GenericNew to tp_new. [1] https://github.com/python/cpython/blob/2ebc5ce42a8a9e047e790aefbf9a94811569b2b6/Objects/listobject.c#L2733 -- assignee: docs@python components: Documentation messages: 302038 nosy: Romuald, docs@python priority: normal severity: normal status: open title: Possibly out of date C extension documentation type: enhancement ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31443> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27558] SystemError inside multiprocessing.dummy Pool.map
New submission from Romuald Brunet: Raising without a previous exception inside a method called from multiprocessing.dummy.Pool.map will trigger a SystemError. SystemError: PyEval_EvalFrameEx returned NULL without setting an error Traceback (most recent call last): File "example.py", line 16, in main() File "example.py", line 11, in main result = pool.map(test, [1]) File "/usr/local/Cellar/python3/3.5.2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/multiprocessing/pool.py", line 260, in map return self._map_async(func, iterable, mapstar, chunksize).get() File "/usr/local/Cellar/python3/3.5.2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/multiprocessing/pool.py", line 608, in get raise self._value File "/usr/local/Cellar/python3/3.5.2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/multiprocessing/pool.py", line 119, in worker result = (True, func(*args, **kwds)) File "/usr/local/Cellar/python3/3.5.2/Frameworks/Python.framework/Versions/3.5/lib/python3.5/multiprocessing/pool.py", line 44, in mapstar return list(map(*args)) SystemError: PyEval_EvalFrameEx returned NULL without setting an error Reproducible example is attached -- components: Interpreter Core files: example.py messages: 270713 nosy: Romuald priority: normal severity: normal status: open title: SystemError inside multiprocessing.dummy Pool.map type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file43772/example.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27558> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24084] pstats: sub-millisecond display
New submission from Romuald Brunet:
When running pstats with functions that take less than 0.5 millisecond (per
call for example), the value shown is '0.000, which isn't really helpful.
This patch aims to show the value in microseconds instead of seconds for values
that would otherwise be displayed as '0.000'
(the display may have to be tweaked for non-utf8 users, as the µ character is
used)
Example output:
ncalls tottime percall cumtime percall filename:lineno(function)
98270.007 7µs0.007 7µs {method 'get' of 'dict' objects}
34270.009 25µs0.017 49µs {map}
107010.006 5µs0.006 5µs {method 'lower' of 'str' objects}
314100.045 14µs0.045 14µs {method 'split' of 'str' objects}
100230.006 6µs0.006 6µs {_weakref.proxy}
318010.009 2µs0.009 2µs {len}
38920.003 7µs0.003 7µs {method 'extend' of 'list'
objects}
13970.001 8µs0.001 8µs {method 'replace' of 'str'
objects}
104880.010 9µs0.010 9µs {method 'string_literal' of
'_mysql.connection' objects}
107022.620 2447µs2.620 2447µs {method 'readline' of 'file'
objects}
100230.004 3µs0.004 3µs {method 'info' of
'_mysql.connection' objects}
100230.005 5µs0.005 5µs {method 'insert_id' of
'_mysql.connection' objects}
143270.022 15µs0.022 15µs {method 'rstrip' of 'str' objects}
--
components: Library (Lib)
files: pstats-microseconds.patch
keywords: patch
messages: 242277
nosy: Romuald
priority: normal
severity: normal
status: open
title: pstats: sub-millisecond display
type: enhancement
Added file: http://bugs.python.org/file39237/pstats-microseconds.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24084
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7980] time.strptime not thread safe
Changes by Romuald Brunet romuald.bru...@gmail.com: -- nosy: +Romuald ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7980] time.strptime not thread safe
Romuald Brunet added the comment: This is a patch attempt to fix issue: import the _strptime module at time / datetime module load instead of method call. Please note that the test is not fully reliable: it may pass without the patch / on current version, since threaded execution isn't controlled -- keywords: +patch Added file: http://bugs.python.org/file34496/issue7980-fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
