[issue12271] Python 2.7.x on IA64 running SLES 11 SP1
New submission from Vincent : Hello everybody, With the same build/compile command, I'm able to have "my" runing python version (2.6.x or 2.7.x) on IA64 server runing SLES 10 SP2/SP3,not on IA64 server runing SLES 11 SP1. I've try with 2.7, 2.7.1 and 2.7.2rc1 version without success. On both configuration types, I've installed all the available libraries, but on SLES 11 SP1, the make resulting message is the following (the complete building messages are in the joined gzip text file): -- ... Python build finished, but the necessary bits to build these modules were not found: _bsddb _sqlite3 _ssl _tkinter bsddb185 bz2 dl imageopreadline sunaudiodevzlib To find the necessary bits, look in setup.py in detect_modules() for the module's name. Failed to build these modules: _curses_panel running build_scripts -- Any advice will be welcome. Thanks a lot for your attention and your process. All the best, Vincent -- components: Build files: Building_error_SLES11SP1_ia64.txt.gz messages: 137737 nosy: v.clau...@free.fr priority: normal severity: normal status: open title: Python 2.7.x on IA64 running SLES 11 SP1 type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file22263/Building_error_SLES11SP1_ia64.txt.gz ___ Python tracker <http://bugs.python.org/issue12271> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12271] Python 2.7.x on IA64 running SLES 11 SP1
Vincent added the comment: Hello Stefan, Thanks a lot for your time and answer, but here are some additional information regarding the requires "panel.h" file. I've just launched a find command onto my ia64 server, and here is the result: hesione:/ # find / -name "panel.h" /usr/include/ncurses/panel.h /usr/include/ncurses6/ncurses/panel.h /usr/include/ncurses6/ncursesw/panel.h /usr/include/ncursesw/panel.h /usr/src/linux-2.6.32.12-0.7-obj/ia64/default/include/config/panel.h As you may have also observed, the build command is claiming also ncurses, which is installed. hesione:~ # rpm -qa|grep ncurses yast2-ncurses-pkg-2.17.16-0.1.77 libncurses6-5.6-90.55 ncurses-devel-5.6-90.55 libncurses5-5.6-90.55 yast2-ncurses-2.17.17-0.4.38 ncurses-utils-5.6-90.55 libncurses5-x86-5.6-90.55 libncurses6-x86-5.6-90.55 Any further information will be welcome. Thanks again for your patience, time and answer. All the best, Vincent -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue12271> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43462] canvas.bbox returns None on 'hidden' items while coords doesn't
Vincent added the comment: HI Terry, yes, that's completely true. But what I meant is I have to invoke coords on every item belonging to a tag and then perform some calculations to get the boundary box of all the items belonging to the item. Let's close this issue and I will knock on the door of the developers of Tk. -- ___ Python tracker <https://bugs.python.org/issue43462> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43462] canvas.bbox returns None on 'hidden' items while coords doesn't
Change by Vincent : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43462> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43462] canvas.bbox returns None on 'hidden' items while coords doesn't
New submission from Vincent :
canvas.bbox() should return a tuple containing values whether an item is hidden
or not. canvax.coords() does return a tuple when an item is hidden.
Steps to reproduce:
```
from tkinter import *
root = Tk()
canvas = Canvas(root)
id1 = canvas.create_line(10,5,20,5, tags='tunnel')
id2 = canvas.create_line(10,8,20,8, tags='tunnel')
canvas.bbox('tunnel') # return a tupple
canvas.itemconfig('tunnel', state='hidden')
canvas.bbox('tunnel') # return nothing not even None
```
I need bbox to return a tuple containing values. The consequences is that the
code must make the items temporarily visible before it can invoke the bbox
function. This turning on and off creates flashing items in my program.
Thanks in advance!
--
components: Tkinter
messages: 388432
nosy: Vincent
priority: normal
severity: normal
status: open
title: canvas.bbox returns None on 'hidden' items while coords doesn't
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue43462>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43462] canvas.bbox returns None on 'hidden' items while coords doesn't
Change by Vincent : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue43462> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43462] canvas.bbox returns None on 'hidden' items while coords doesn't
Vincent added the comment:
No, not hang. It returns a NoneType.
See this example:
>>> x = canvas.bbox('tunnel')
>>> type(x)
>>>
--
___
Python tracker
<https://bugs.python.org/issue43462>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43462] canvas.bbox returns None on 'hidden' items while coords doesn't
Vincent added the comment: Thank you for your comments. Yes, I would doubt that, too. You would expect to get a bounding box regardless what state the canvas item are in. The only way to fix this (and I'm open to suggestions), is to create a (custom) function that calculate every object belonging to a specific tag and add/subtract the coordinates - this is cumbersome. -- ___ Python tracker <https://bugs.python.org/issue43462> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43462] canvas.bbox returns None on 'hidden' items while coords doesn't
Vincent added the comment: ... calculate the coordinates using the canvas.coords function -- ___ Python tracker <https://bugs.python.org/issue43462> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46139] Boolean Logic Check - Built-in Types Documentation page
New submission from Abri Vincent : On the documentation page https://docs.python.org/3/library/stdtypes.html the header 'Boolean Operations — and, or, not' provides a table (attached as an image). It states: a.1) x OR y - if x is false, then y, else x ** a.2) x AND y - if x is false, then x, else y ** When I read this i intuit the following b.1) x OR y - if x is false, then x, else y b.2) x AND y - if x is false, then y, else x Providing an example with a.1 which is currently listed in the documentation If x is false -> else x = False (we don't check if Y=True which is the definition of an OR operator). ** This is a short-circuit operator, so it only evaluates the second argument if the first one is false. I would appreciate clarification on this and if others see an issue with the documentation after reading my description able then movement on consensus to correct the documentation -- assignee: docs@python components: Documentation messages: 408972 nosy: abriabrisham, docs@python priority: normal severity: normal status: open title: Boolean Logic Check - Built-in Types Documentation page ___ Python tracker <https://bugs.python.org/issue46139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46139] Boolean Logic Check - Built-in Types Documentation page
Change by Abri Vincent : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46139] Boolean Logic Check - Built-in Types Documentation page
Abri Vincent added the comment: A short circuit operator. x OR y - if x is false, then y, else x (1). (1) This is a short-circuit operator, so it only evaluates the second argument if the first one is false. The first argument is 'if' The second argument is 'then' The third argument is 'else' Move to the second argument if the first is false. Evaluate the first argument 'if x is false' - look at the second argument if the first argument is false - 'then y'. -- ___ Python tracker <https://bugs.python.org/issue46139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46916] There is a problem with escape characters in the path passed in by pathlib.Path.mkdir()
New submission from Vincent FUNG : This problem occurs when the directory starts with 't', but works with os.makedirs(e) or macOS. >>> e = Path(r'F:\ceven\test2') >>> e.mkdir() Traceback (most recent call last): File "", line 1, in File "C:\Program Files\Python310\lib\pathlib.py", line 1173, in mkdir self._accessor.mkdir(self, mode) FileNotFoundError: [WinError 3] The system cannot find the path specified: 'F:\\ceven\\test2' >>> os.makedirs(e) -- components: Windows messages: 414483 nosy: paul.moore, steve.dower, tim.golden, vincent.fung, zach.ware priority: normal severity: normal status: open title: There is a problem with escape characters in the path passed in by pathlib.Path.mkdir() type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46916] There is a problem with escape characters in the path passed in by pathlib.Path.mkdir()
Vincent FUNG added the comment: This problem occurs when the directory starts with 't', but works with os.makedirs(e) or macOS. >>> e = Path(r'F:\ceven\test2') >>> e.mkdir() Traceback (most recent call last): File "", line 1, in File "C:\Program Files\Python310\lib\pathlib.py", line 1173, in mkdir self._accessor.mkdir(self, mode) FileNotFoundError: [WinError 3] The system cannot find the path specified: 'F:\\ceven\\test2' >>> os.makedirs(e) Another question about \t: If a directory is passed as a parameter it will not be possible to use the parameter as a raw string. os.makedirs gives the same error whether it's r'%s' or repr(). -- ___ Python tracker <https://bugs.python.org/issue46916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46916] There is a problem with escape characters in the path passed in by pathlib.Path.mkdir()
Vincent FUNG added the comment: Oh. Got it. I thought pathlib would solve this problem completely now, without having to replace the slashes. Thank you for your patient answer. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46916] There is a problem with escape characters in the path passed in by pathlib.Path.mkdir()
Vincent FUNG added the comment: Thank you very much for your patient answer, I am still a developer who has just started, and it seems that I need to learn more about it. I used repr().replace to replace with forward slashes, and also restricted paths ending in a slash to Improve reliability. Thanks anagin. ;) -- ___ Python tracker <https://bugs.python.org/issue46916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1462525] URI parsing library
vincent kraeutler added the comment: Quite like urlparse, uriparse does not fail on input which does not represent valid URI's. At least not early or reliably enough. Specifically, I noticed that urisplit does not fail on input strings with a missing scheme, such as "foo.com/bar". I see no (straightforward) solution to this problem, short of using a proper parser library such as Haskell's Parsec (I unfortunately know of no Python equivalent), but I thought I might want to report this issue nevertheless. The following might work as a quick-fix: Replace regex.match(foo,bar).groups() with something like: mm = re.match(regex, uri) sp = mm.span() if (-1 in sp) or (sp[1] - sp[0] != len(uri)): raise ValueError, "uri regex did not match complete input" p = mm.groups() -- nosy: +vincentk _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1462525> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1462525] URI parsing library
vincent kraeutler added the comment:
Some more notes.
a) RFC3986 explicitly states that the presented regex (which you use)
""" is the regular expression for breaking-down a *well-formed* URI
reference into its components. """ (Emphasis added). I am not sure this
is a particularly good starting point for parsing potentially
security-critical data.
b) The parser fails on URI's containing numerical IPv6 addresses (e.g.
"http://[::1]:88/path";). Specifically, the following code in
split_authority is broken:
if hostport and ':' in hostport:
host, port = hostport.split(':', 1)
Clearly, if the authority may contain a ":" in the host's IP field, you
cannot simply split() off the port part.
Again, I am afraid I have no simple solution. Hate to sound so negative.
Kind regards,
v.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1462525>
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1462525] URI parsing library
vincent kraeutler added the comment: In the meantime, I have found a very nice parser combinator library for Python (pyparse) and have implemented a validating parser for RFC 3986 URI's by more or less simply converting the complete ABNF grammar found in the RFC. Obviously, this will never make it into the stdlib, due to a dependency on an external library (pyparse), but it might be useful to other people as well. It's available here: http://www.kraeutler.net/vincent/pub/netaddress/netaddress-0.1.tar.gz _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1462525> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13512] ~/.pypirc created insecurely
New submission from Vincent Danen : A bug was reported in python's distutils in that ~/.pypirc was created insecurely by first creating and writing user/password information to the file, then chmod'ing it to 0600. Perhaps the file should be created (empty), chmod'd, and then written to or perhaps tempfile.mkstemp() could be used to create the file and then move it in-place. On systems where /home/user is 0700 by default this isn't a problem, but there is a race condition that could possibly (although the window would be small) to expose credentials in a home directory that is 0755, for instance. I searched and couldn't find a similar report here, so decided to make upstream aware of the bug reported to Debian. References: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650555 https://bugzilla.redhat.com/show_bug.cgi?id=758905 -- assignee: tarek components: Distutils messages: 148697 nosy: Vincent.Danen, eric.araujo, tarek priority: normal severity: normal status: open title: ~/.pypirc created insecurely type: security versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13512> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11302] Add more tests to test_ast.py
Vincent Legoll added the comment: OK I'll look at it and respin with the comments in mind -- ___ Python tracker <http://bugs.python.org/issue11302> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11302] Add more tests to test_ast.py
Vincent Legoll added the comment: Here we are, I left the exact messages for raised exceptions as comments so they can easily be checked in case of test failure... Does that look OK ? -- Added file: http://bugs.python.org/file22495/add-more-tests-for-ast_py-2.patch ___ Python tracker <http://bugs.python.org/issue11302> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11302] Add more tests to test_ast.py
Vincent Legoll added the comment:
I was testing exact matches on the strings because I think pypy wants to be as
compliant as possible with cpython, and IMHO that include exception msgs as far
as possible. I don't see any reason to be different just for the sake of it.
As a user I'd find strange not to get same exc msgs from different
implementations, and it'll make me loose some time digging why those difference
exist...
Back to the patch:
The multiline (and also differing offsets) are there for testing .lineno &
.col_offset AST node's attributes. (there was a bug in pypy's implementation of
those back then...)
Do you want that explained in the comment ?
Do you want me to add "self.assertIn("foobar", str(e))" in the tests, remove
the comments or let them as in the patch #2 ?
--
___
Python tracker
<http://bugs.python.org/issue11302>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11302] Add more tests to test_ast.py
Vincent Legoll added the comment: * removed the comments for exc msgs * added explanation to multiline statements * added 2 tests to test_AST_objects() Regarding Éric's comment, I'm starting to wonder if those Exception tests should be added to cpython's testsuite. Maybe that would only be beneficial for pypy... -- Added file: http://bugs.python.org/file22496/add-more-tests-for-ast_py-3.patch ___ Python tracker <http://bugs.python.org/issue11302> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12432] remove a bunch of unused imports in Lib
New submission from Vincent Legoll : Using pylint I found some unused imports in Lib. I filtered the most obvious ones by hand to produce the attached patch. Should I submit individual patches, one for each file, so as to ease review ? -- components: Library (Lib) files: unused-imports-2.patch keywords: patch messages: 139362 nosy: vincele priority: normal severity: normal status: open title: remove a bunch of unused imports in Lib versions: Python 3.4 Added file: http://bugs.python.org/file22508/unused-imports-2.patch ___ Python tracker <http://bugs.python.org/issue12432> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12432] remove a bunch of unused imports in Lib
Vincent Legoll added the comment: Looking through http://hg.python.org/cpython/rev/8c17e898e0e8 I see that the glob.py hunk has been applied reversed. The changeset 68349:55bea11d892e removing it is 3 monthes old... Looks like I missed a svn->hg migration on my side, sorry for the screwup... -- resolution: fixed -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue12432> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12432] remove a bunch of unused imports in Lib
Vincent Legoll added the comment: This one reverts glob.py to the previous state -- Added file: http://bugs.python.org/file22510/reremove-sys-import-from-glob.patch ___ Python tracker <http://bugs.python.org/issue12432> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11302] Add more tests to test_ast.py
New submission from Vincent Legoll : While working to improve pypy's compliance with cpython2.7 I added more tests to the ast module test suite. They may be of interest here too... -- components: Tests files: add-more-tests-for-ast_py.patch keywords: patch messages: 129225 nosy: vincele priority: normal severity: normal status: open title: Add more tests to test_ast.py versions: Python 2.7 Added file: http://bugs.python.org/file20869/add-more-tests-for-ast_py.patch ___ Python tracker <http://bugs.python.org/issue11302> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3146] Sphinx/LaTeX fails on Python 3.0b1 documentation
New submission from Vincent Manis <[EMAIL PROTECTED]>:
When attempting to build the LaTeX for the documentation provided with
Python 3.0b1, the following error is produced while writing the Library
documentation (full backtrace provided). I am running Sphinx on Python
2.5.
Traceback (most recent call last):
File "/Users/vmanis/myenv/py3k/Doc/tools/sphinx/__init__.py", line
135, in main
app.builder.build_update()
File "/Users/vmanis/myenv/py3k/Doc/tools/sphinx/builder.py", line 194,
in build_update
self.build(['__all__'], to_build)
File "/Users/vmanis/myenv/py3k/Doc/tools/sphinx/builder.py", line 238,
in build
self.write(docnames, updated_docnames, method)
File "/Users/vmanis/myenv/py3k/Doc/tools/sphinx/builder.py", line 852,
in write
docwriter.write(doctree, destination)
File
"/Users/vmanis/myenv/py3k/Doc/tools/docutils/writers/__init__.py", line
78, in write
self.translate()
File "/Users/vmanis/myenv/py3k/Doc/tools/sphinx/latexwriter.py", line
70, in translate
self.document.walkabout(visitor)
File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159,
in walkabout
child.walkabout(visitor)
File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159,
in walkabout
child.walkabout(visitor)
File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159,
in walkabout
child.walkabout(visitor)
File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159,
in walkabout
child.walkabout(visitor)
File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159,
in walkabout
child.walkabout(visitor)
File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159,
in walkabout
child.walkabout(visitor)
File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159,
in walkabout
child.walkabout(visitor)
File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159,
in walkabout
child.walkabout(visitor)
File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 159,
in walkabout
child.walkabout(visitor)
File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line 151,
in walkabout
visitor.dispatch_visit(self)
File "/Users/vmanis/myenv/py3k/Doc/tools/docutils/nodes.py", line
1502, in dispatch_visit
return method(node)
File "/Users/vmanis/myenv/py3k/Doc/tools/sphinx/latexwriter.py", line
1012, in unknown_visit
raise NotImplementedError("Unknown node: " +
node.__class__.__name__)
NotImplementedError: Unknown node: subscript
--
assignee: georg.brandl
components: Documentation, Documentation tools (Sphinx)
messages: 68426
nosy: georg.brandl, vmanis1
severity: normal
status: open
title: Sphinx/LaTeX fails on Python 3.0b1 documentation
type: crash
versions: Python 2.5, Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3146>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3548] subprocess.pipe function
Vincent Legoll <[EMAIL PROTECTED]> added the comment: Hello, I was searching for a bug in subprocess module when I saw your patch. I was implementing the exact same functionality and mixed some of your ideas in what I use now, which is attached... Feel free to use it -- nosy: +vincent.legoll Added file: http://bugs.python.org/file11262/toto.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3548> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3548] subprocess.pipe function
Vincent Legoll <[EMAIL PROTECTED]> added the comment: Here's a clean version with doc & test enjoy ! Added file: http://bugs.python.org/file11263/pipeline.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3548> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3687] Popen() object stdout attribute reassignment behaviour
New submission from Vincent Legoll <[EMAIL PROTECTED]>: The subprocess.Popen() object documentation should indicate that the stdout attribute should not be modified after object construction. Because that won't work. Or the attribute may be rendered read-only >>> from subprocess import Popen, PIPE >>> import sys, os >>> p1 = Popen(["echo", "1"], stdout = PIPE) >>> p2 = Popen(["cat"], stdin = p1.stdout, stderr = PIPE, stdout = PIPE) >>> p2.stdout = sys.stdout >>> print p2.communicate() This blocks forever -- assignee: georg.brandl components: Documentation messages: 71983 nosy: georg.brandl, vincent.legoll severity: normal status: open title: Popen() object stdout attribute reassignment behaviour type: behavior versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3687> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3548] subprocess.pipe function
Vincent Legoll <[EMAIL PROTECTED]> added the comment: - Added "shut pylint up" comment for ** keyword expansion - Added Copyright & license header Added file: http://bugs.python.org/file11330/pipeline.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3548> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3548] subprocess.pipe function
Legoll Vincent <[EMAIL PROTECTED]> added the comment: On Mon, Sep 1, 2008 at 5:13 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote: > Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > > Vincent, > GPL licenced code is incompatible with the inclusion into python. > And if I am correct, you should sign a contributor agreement. Then the > licence text is not necessary. This is not a patch against python, this is a standalone script, just implementing the same functionality as the original bug report in a slightly different way... But thanks for the input anyways. If this functionality is really interesting people and agreed to be integrated into upstream subprocess module, I can rework it the right way, or work from the original patch from the bug report. -- nosy: +vlegoll ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3548> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7778] Typo(s) in ``itertools`` documentation reST marker
New submission from Vincent Férotin : In Python 2.6 ``itertools`` library documentation is a small typo in last paragraph (``projects/python/branches/release26-maint/Doc/library/itertools.rst``, rev. [77750]), see it at http://docs.python.org/library/itertools.html#recipes . In the note about how optimizing recipes, ``dotproduct`` example function is not outlined as a code sample. Lines 762-763 should end with double colons (instead of simple), to mark following code as such, in reST format:: (...) For example, the *dotproduct* recipe can be written as:: Note that previous ``*dotproduct*`` ref. could be marked as ``inline literal`` instead of *emphasis*, and then lines become:: (...) For example, the ``dotproduct`` recipe can be written as:: -- assignee: georg.brandl components: Documentation messages: 98286 nosy: fero14041, georg.brandl severity: normal status: open title: Typo(s) in ``itertools`` documentation reST marker versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue7778> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7778] Typo(s) in ``itertools`` documentation reST marker
Vincent Férotin added the comment: Add patch fixing typo for sample code. -- keywords: +patch Added file: http://bugs.python.org/file16000/fix_7778-typo_in_itertools_documentation.diff ___ Python tracker <http://bugs.python.org/issue7778> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7778] Typo(s) in ``itertools`` documentation reST marker
Vincent Férotin added the comment: Add patch fixing typo for sample code, and changing ``dotproduct`` emphasis (``*dotproduct*``) to literal (``\``dotproduct\). -- Added file: http://bugs.python.org/file16001/fix_7778-typo_in_itertools_documentation-literal.diff ___ Python tracker <http://bugs.python.org/issue7778> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7778] Typo(s) in ``itertools`` documentation reST marker
Vincent Férotin added the comment: Ok, thanks for reviewing and fixing! -- ___ Python tracker <http://bugs.python.org/issue7778> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6722] collections.namedtuple: confusing example
Vincent Borghi added the comment: In fact, thanks to the person (Alexey Shamrin) who created this issue (issue found while googling for "namedtuple"), I have understood the namedtuple example in the documentation. I think like him the verbose=True example that cames first is very confusing. (BTW I must say that the Python reference documentation is usually excellent, so my expectations are high!) -- nosy: +Vincent.Borghi ___ Python tracker <http://bugs.python.org/issue6722> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2418] Incorrect LaTeX generated (Python 2.6a1)
Changes by Vincent Manis <[EMAIL PROTECTED]>: -- assignee: georg.brandl components: Documentation tools (Sphinx) nosy: georg.brandl, vmanis1 severity: normal status: open title: Incorrect LaTeX generated (Python 2.6a1) type: behavior versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2418> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2418] Incorrect LaTeX generated (Python 2.6a1)
New submission from Vincent Manis <[EMAIL PROTECTED]>:
The LaTeX code generated by Sphinx in 2.6a1 is incorrect. Some, but not
all, of the \end{Verbatim}'s come at the ends of lines, rather than on
lines of their own. Here is an example, at line 435 of reference.tex.
return r# error: inconsistent
dedent\end{Verbatim}
Each occurrence of this construction results in the `make all-pdf'
failing.
Also, at approximately line 42051 of library.tex, the environment classdescni
is undefined.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2418>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2418] Incorrect LaTeX generated (Python 2.6a1)
Vincent Manis <[EMAIL PROTECTED]> added the comment: On 2008 Mar 19, at 01:00, Georg Brandl wrote: > > > Georg Brandl <[EMAIL PROTECTED]> added the comment: > > Thanks, fixed in r61617. Wow, that was fast :-) -- v __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2418> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27929] asyncio.AbstractEventLoop.sock_connect broken for AF_BLUETOOTH
Change by Vincent Bernat : -- keywords: +patch nosy: +bernat nosy_count: 4.0 -> 5.0 pull_requests: +30211 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/32131 ___ Python tracker <https://bugs.python.org/issue27929> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34747] SSLSocket.context cannot be changed on non-connected sockets
Vincent Pelletier added the comment: Added: affects Python 3.9 This bug is still preventing (...or shall I say "discourages", as the setter is effective but raises) server-side SSL certificate reloading on long-running services. This codepath on listening sockets is necessary for seamless certificate renewal, so the new certificate is used on any accepted connection past the setter call. Is there anything that needs to be changed to the fix I proposed ? Should I open a merge/pull request somewhere ? -- versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue34747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44062] cross: wrong interpreter returned when no python available
New submission from Vincent Fazio : When trying to cross compile python3.9, `configure` attempts to find a strict python 3.9 version match, however if it fails it still attempts to use `python` in PYTHON_FOR_BUILD instead of failing outright like the code implies it should $/python3/targetbuild# which python3.9 python3 python /usr/bin/python3 $/python3/targetbuild# python3 --version Python 3.7.3 $/python3/targetbuild# PYTHON_FOR_REGEN=/python3/hostbuild/python \ ac_cv_file__dev_ptmx=yes \ ac_cv_file__dev_ptc=no \ ac_cv_buggy_getaddrinfo=no \ ../configure --build=x86-linux-gnu \ --host=aarch64-linux-gnu \ --enable-loadable-sqlite-extensions \ --enable-option-checking=fatal \ --enable-shared \ --with-system-expat \ --with-system-ffi \ --without-ensurepip checking build system type... x86-unknown-linux-gnu checking host system type... aarch64-unknown-linux-gnu checking for python3.9... /python3/hostbuild/python checking for python interpreter for cross build... python ... $/python3/targetbuild# grep PYTHON_FOR_BUILD config.log PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) _PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(shell test -f pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:)$(srcdir)/Lib _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_$(ABIFLAGS)_$(MACHDEP)_$(MULTIARCH) python' in configure if test "$cross_compiling" = yes; then AC_MSG_CHECKING([for python interpreter for cross build]) if test -z "$PYTHON_FOR_BUILD"; then for interp in python$PACKAGE_VERSION python3 python; do which $interp >/dev/null 2>&1 || continue if $interp -c "import sys;sys.exit(not '.'.join(str(n) for n in sys.version_info@<:@:2@:>@) == '$PACKAGE_VERSION')"; then break fi interp= done if test x$interp = x; then AC_MSG_ERROR([python$PACKAGE_VERSION interpreter not found]) fi AC_MSG_RESULT($interp) PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) _PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(shell test -f pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:)$(srcdir)/Lib _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_$(ABIFLAGS)_$(MACHDEP)_$(MULTIARCH) '$interp fi elif test "$cross_compiling" = maybe; then AC_MSG_ERROR([Cross compiling required --host=HOST-TUPLE and --build=ARCH]) else PYTHON_FOR_BUILD='./$(BUILDPYTHON) -E' fi AC_SUBST(PYTHON_FOR_BUILD) The issue is a failing edge case here: for interp in python$PACKAGE_VERSION python3 python; do which $interp >/dev/null 2>&1 || continue where interp keeps it's last value doesn't trigger the empty check here: if test x$interp = x; then AC_MSG_ERROR([python$PACKAGE_VERSION interpreter not found]) fi Note that there's an explicit clearing of interp when the python version isn't a match: if $interp -c "import sys;sys.exit(not '.'.join(str(n) for n in sys.version_info@<:@:2@:>@) == '$PACKAGE_VERSION')"; then break fi interp= The fix should be pretty straightforward: for interp in python$PACKAGE_VERSION python3 python ''; do adding '' as the last possible interpreter means one hasn't been found up to that point and allows configure to properly fail $/python3/targetbuild# PYTHON_FOR_REGEN=/python3/hostbuild/python ac_cv_file__dev_ptmx=yes ac_cv_file__dev_ptc=no ac_cv_buggy_getaddrinfo=no ../configure --build=x86-linux-gnu --host=aarch64-linux-gnu --enable-loadable-sqlite-extensions --enable-option-checking=fatal --enable-shared --with-system-expat --with-system-ffi --without-ensurepip checking build system type... x86-unknown-linux-gnu checking host system type... aarch64-unknown-linux-gnu checking for python3.9... /python3/hostbuild/python checking for python interpreter for cross build... configure: error: python3.9 interpreter not found It will continue to work when a proper interpreter is found $/python3/targetbuild# PATH=/python3/hostbuild:$PATH PYTHON_FOR_REGEN=/python3/hostbuild/python ac_cv_file__dev_ptmx=yes ac_cv_file__dev_ptc=no ac_cv_buggy_getaddrinfo=no ../configure --build=x86-linux-gnu --host=aarch64-linux-gnu --enable-loadable-sqlite-extensions --enable-option-checking=fatal --enable-shared --with-system-expat --with-system-ffi --without-ensurepip checking build system type... x86-unknown-linux-gnu checking host system type... aarch64-unknown-linux-gnu checking for python3.9... /python3/hostbuild/python checking for python interpreter for cross build... Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] python This should help
[issue44062] cross: wrong interpreter returned when no python available
Change by Vincent Fazio : -- keywords: +patch pull_requests: +24614 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25951 ___ Python tracker <https://bugs.python.org/issue44062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44665] asyncio.create_task() documentation should mention user needs to keep reference to the task
New submission from Vincent Bernat : asyncio will only keep weak references to alive tasks (in `_all_tasks`). If a user does not keep a reference to a task and the task is not currently executing or sleeping, the user may get "Task was destroyed but it is pending!". I would suggest adding the following paragraph to `create_task()` documentation: Python only keeps weak references to the scheduled tasks. To avoid the task being destroyed by the garbage collector while still pending, a reference to it should be kept until the task is done. And maybe an example in case a user wants something "fire and forget"? ```python running_tasks = set() # [...] task = asyncio.create_task(some_background_function()) running_tasks.add(task) task.add_done_callback(lambda t: running_tasks.remove(t)) ``` The same applies to ensure_future as it now uses create_task, so maybe a "See create_task()". -- assignee: docs@python components: Documentation messages: 397741 nosy: bernat, docs@python priority: normal severity: normal status: open title: asyncio.create_task() documentation should mention user needs to keep reference to the task type: enhancement versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44219] Opening a file holds the GIL when it calls "isatty()"
Vincent Michel added the comment: My team ran into this issue while developing a fuse application too. In an effort to help this issue move forward, I tried to list all occurrences of the `isatty` C function in the cpython code base. I found 14 of them. 9 of them are directly related to stdin/stdout/stderr, so it's probably not crucial to release the GIL for those occurrences: - `main.c:stdin_is_interactive` - `main.c:pymain_import_readline` - `readline.c:setup_readline` - `bltinmodule.c:builtin_input_impl` (x2) - `frozenmain.c:Py_FrozenMain` - `pylifecycle.c:Py_FdIsInteractive` (x2) - `fileobject.c:stdprinter_isatty` (GIL is actually released for this one) Out of the remaining 4, only 1 releases the GIL: - `fileio.c:_io_FileIO_isatty_impl`: used for `FileIO.isatty` Which gives 3 occurrences of non-stdstream specific usage of `isatty` that do not release the GIL: - `posixmodule.c:os_isatty_impl`: used by `os.isatty` - `fileutils.c:_Py_device_encoding`: used `TextIOWrapper.__init__` - `fileutils.c:_Py_write_impl`: windows specific, issue #11395 The first one is used by `os.isatty` which means this call can also deadlock. I did manage to reproduce it with a simple fuse loopback file system: https://github.com/fusepy/fusepy/blob/master/examples/loopback.py The second one is the one found by @smurfix and gets triggered when `io.open()` is used in text mode. The third one only triggers on windows when writing more than 32767 bytes to a file descriptor. A comment points to issue #11395 (https://bugs.python.org/issue11395). Also, it seems from the function signature that this function might be called with or without the GIL held, which might cause the fix to be a bit more complicated than the first two use cases. I hope this helps. -- nosy: +vxgmichel ___ Python tracker <https://bugs.python.org/issue44219> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44219] Opening a file holds the GIL when it calls "isatty()"
Vincent Michel added the comment: Here's a possible patch that fixes the 3 unprotected calls to `isatty` mentioned above. It successfully passes the test suite. I can submit a PR with this patch if necessary. -- keywords: +patch Added file: https://bugs.python.org/file50270/bpo-44219.patch ___ Python tracker <https://bugs.python.org/issue44219> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44129] zipfile: Add descriptive global variables for general purpose bit flags
Change by Vincent Michel : -- nosy: +vxgmichel nosy_count: 2.0 -> 3.0 pull_requests: +26670 pull_request: https://github.com/python/cpython/pull/28250 ___ Python tracker <https://bugs.python.org/issue44129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44219] Opening a file holds the GIL when it calls "isatty()"
Change by Vincent Michel : -- pull_requests: +26671 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28250 ___ Python tracker <https://bugs.python.org/issue44219> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44129] zipfile: Add descriptive global variables for general purpose bit flags
Change by Vincent Michel : -- pull_requests: -26670 ___ Python tracker <https://bugs.python.org/issue44129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44219] Opening a file holds the GIL when it calls "isatty()"
Vincent Michel added the comment: There are a couple of reasons why I did not make changes to the stdstream related functions. The first one is that a PR with many changes is less likely to get reviewed and merged than a PR with fewer changes. The second one is that it's hard for me to make sure that those functions are always called with the GIL already held. Maybe some of them never hold the GIL in the first place, and I'm not familiar enough with the code base to tell. So in the end it will probably be up to the coredev reviewing the PR, but better start small. > Besides, nothing prevents somebody from starting a FUSE file system and then > redirecting stdout to it … I ran some checks and `python -c 'input()' < my-fuse-mountpoint/data_in` does indeed trigger an ioctl call to the corresponding fuse file system. But how would `my-fuse-mountpoint/data_in` be the stdin for the process that itself starts the fuse filesystem? I don't see how to generate this deadlock, apart from setting up interprocess communication between the fuse process and the `my-fuse-mountpoint/data_in`-as-stdin process. -- ___ Python tracker <https://bugs.python.org/issue44219> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45469] lambda issue in for-loop
New submission from Vincent Liang :
Strange behavior is found when lambda is used inside for-loop.
code:(same as attached file)
# begin of CODE
def aa(x):
print("aa")
def bb(x):
print("bb")
namefun = [
("a", aa),
("b", bb),
]
name2fun = {}
for name, fun in namefun:
name2fun[name] = lambda x: fun(x)
# issue happened when calling lambda
name2fun["a"](1)
name2fun["b"](1)
# end of CODE
output:
bb
bb
expected output:
aa
bb
--
components: Interpreter Core
files: test8.py
messages: 403899
nosy: vincent7f
priority: normal
severity: normal
status: open
title: lambda issue in for-loop
type: behavior
versions: Python 3.10, Python 3.9
Added file: https://bugs.python.org/file50357/test8.py
___
Python tracker
<https://bugs.python.org/issue45469>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44665] asyncio.create_task() documentation should mention user needs to keep reference to the task
Vincent Bernat added the comment: Hummm, I have a hard time finding a short example when `__del__` is not called until the task is finished. Sorry. I did run into this several time, for example here: https://github.com/ldo/dbussy/pull/45 (and some internal projects as well). So, it happens from time to time, but it is hard to find a simple reproducer. -- ___ Python tracker <https://bugs.python.org/issue44665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39484] time_ns() and time() cannot be compared on windows
New submission from Vincent Michel : On windows, the timestamps produced by time.time() often end up being equal because of the 15 ms resolution: >>> time.time(), time.time() (1580301469.6875124, 1580301469.6875124) The problem I noticed is that a value produced by time_ns() might end up being higher then a value produced time() even though time_ns() was called before: >>> a, b = time.time_ns(), time.time() >>> a, b (1580301619906185300, 1580301619.9061852) >>> a / 10**9 <= b False This break in causality can lead to very obscure bugs since timestamps are often compared to one another. Note that those timestamps can also come from non-python sources, i.e a C program using `GetSystemTimeAsFileTime`. This problem seems to be related to the conversion `_PyTime_AsSecondsDouble`: https://github.com/python/cpython/blob/f1c19031fd5f4cf6faad539e30796b42954527db/Python/pytime.c#L460-L461 # Float produced by `time.time()` >>> b.hex() '0x1.78c5f4cf9fef0p+30' # Basically what `_PyTime_AsSecondsDouble` does: >>> (float(a) / 10**9).hex() '0x1.78c5f4cf9fef0p+30' # What I would expect from `time.time()` >>> (a / 10**9).hex() '0x1.78c5f4cf9fef1p+30' However I don't know if this would be enough to fix all causality issues since, as Tim Peters noted in another thread: > Just noting for the record that a C double (time.time() result) isn't quite > enough to hold a full-precision Windows time regardless (https://bugs.python.org/issue19738#msg204112) -- components: Library (Lib) messages: 360958 nosy: vxgmichel priority: normal severity: normal status: open title: time_ns() and time() cannot be compared on windows type: behavior versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue39484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39484] time_ns() and time() cannot be compared on windows
Vincent Michel added the comment: I thought about it a bit more and I realized there is no way to recover the time in hundreds of nanoseconds from the float produced by `time.time()` (since the windows time currently takes 54 bits and will take 55 bits in 2028). That means `time()` and `time_ns()` cannot be compared by converting time() to nanoseconds, but it might still make sense to compare them by converting time_ns() to seconds (which is apparently broken at the moment). If that makes sense, a possible roadmap to tackle this problem would be: - fix `_PyTime_AsSecondsDouble` so that `time.time_ns() / 10**9 == time.time()` - add a warning in the documentation that one should be careful when comparing the timestamps produced by `time()` and time_ns()` (in particular, `time()` should not be converted to nanoseconds) -- ___ Python tracker <https://bugs.python.org/issue39484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39484] time_ns() and time() cannot be compared on windows
Change by Vincent Michel : Added file: https://bugs.python.org/file48881/comparing_errors.py ___ Python tracker <https://bugs.python.org/issue39484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39484] time_ns() and time() cannot be compared on windows
Vincent Michel added the comment:
Thanks for your answers, that was very informative!
> >>> a/10**9
> 1580301619.9061854
> >>> a/1e9
> 1580301619.9061852
>
> I'm not sure which one is "correct".
Originally, I thought `a/10**9` was more precise because I ran into the
following case while working with hundreds of nanoseconds (because windows):
```
r = 1580301619906185900
print("Ref :", r)
print("10**7 :", int(r // 100 / 10**7 * 10 ** 7) * 100)
print("1e7 :", int(r // 100 / 1e7 * 10 ** 7) * 100)
print("10**9 :", int(r / 10**9 * 10**9))
print("1e9 :", int(r / 1e9 * 10**9))
[...]
Ref : 1580301619906185900
10**7 : 1580301619906185800
1e7 : 1580301619906186200
10**9 : 1580301619906185984
1e9 : 1580301619906185984
```
I decided to plot the conversion errors for different division methods over a
short period of time. It turns out that:
- `/1e9` is equally or more precise than `/10**9` when working with nanoseconds
- `/10**7` is equally or more precise than `/1e7` when working with hundreds
nanoseconds
This result really surprised me, I have no idea what is the reason behind this.
See the plots and code attached for more information.
In any case, this means there is no reason to change the division in
`_PyTime_AsSecondsDouble`, closing this issue as wontfix sounds fine :)
---
As a side note, the only place I could find something similar mentioned in the
docs is in the `os.stat_result.st_ctime_ns` documentation:
https://docs.python.org/3.8/library/os.html#os.stat_result.st_ctime_ns
> Similarly, although st_atime_ns, st_mtime_ns, and st_ctime_ns are
> always expressed in nanoseconds, many systems do not provide
> nanosecond precision. On systems that do provide nanosecond precision,
> 1the floating-point object used to store st_atime, st_mtime, and
> st_ctime cannot preserve all of it, and as such will be slightly
> inexact. If you need the exact timestamps you should always use
> st_atime_ns, st_mtime_ns, and st_ctime_ns.
Maybe this kind of limitation should also be mentioned in the documentation of
`time.time_ns()`?
--
Added file:
https://bugs.python.org/file48880/Comparing_division_errors_over_10_us.png
___
Python tracker
<https://bugs.python.org/issue39484>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39484] time_ns() and time() cannot be compared on windows
Vincent Michel added the comment: > The problem is that there is a double rounding in [...] Actually `float(x) / 1e9` and `x / 1e9` seems to produce the same results: ``` import time import itertools now = time.time_ns() for x in itertools.count(now): assert float(x) / 1e9 == x / 1e9 ``` > The formula `time = time_ns / 10**9` may be more accurate. Well that seems to not be the case, see the plots and the corresponding code. I might have made a mistake though, please let me know if I got something wrong :) -- ___ Python tracker <https://bugs.python.org/issue39484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39484] time_ns() and time() cannot be compared on windows
Vincent Michel added the comment: @serhiy.storchaka > 1580301619906185300/10**9 is more accurate than 1580301619906185300/1e9. I don't know exactly what `F` represents in your example but here is what I get: >>> r = 1580301619906185300 >>> >>> int(r / 10**9 * 10**9) - r >>> 172 >>> int(r / 1e9 * 10**9) - r >>> -84 @vstinner > I suggest to only document in time.time() is less accurate than > time.time_ns(). Sounds good! -- ___ Python tracker <https://bugs.python.org/issue39484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39484] time_ns() and time() cannot be compared on windows
Vincent Michel added the comment: @mark.dickinson > To be clear: the following is flawed as an accuracy test, because the > *multiplication* by 1e9 introduces additional error. Interesting, I completely missed that! But did you notice that the full conversion might still perform better when using only floats? ``` >>> from fractions import Fraction as F >>> >>> r = 1580301619906185300 >>> >>> abs(int(r / 1e9 * 1e9) - r) >>> 84 >>> abs(round(F(r / 10**9) * 10**9) - r) >>> 89 ``` I wanted to figure out how often that happens so I updated my plotting, you can find the code and plot attached. Notice how both methods seems to perform equally good (the difference of the absolute errors seems to average to zero). I have no idea about why that happens though. -- Added file: https://bugs.python.org/file48882/Comparing_conversions_over_5_us.png ___ Python tracker <https://bugs.python.org/issue39484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39484] time_ns() and time() cannot be compared on windows
Change by Vincent Michel : Added file: https://bugs.python.org/file48883/comparing_conversions.py ___ Python tracker <https://bugs.python.org/issue39484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43379] Pasting multiple lines in the REPL is broken since 3.9
New submission from Romain Vincent :
DISCLAIMER: This is the first time I submit an issue here. In advance, my
humble apologies if I missed something.
Feel free to correct me :)
--
I regularly test snippets of code by pasting them from a code editor to a shell
REPL.
It works perfectly well in python 3.8 or 3.7 but not in python 3.9.
Demonstration:
Try to copy and paste the following simple snippet:
---
def f():
print("hello world")
---
The result in a python 3.8 REPL (same with 3.7):
---
$ python3.8
Python 3.8.6 (default, Nov 20 2020, 18:29:40)
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
print("hello world")
>>> f()
hello world
---
But with python 3.9:
---
$ python3.9
Python 3.9.1 (default, Dec 10 2020, 10:36:35)
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
print("hello world")
File "", line 1
^
SyntaxError: multiple statements found while compiling a single statement
---
This behavior happens with any snippet of code containing at least one indented
line, whether by tabs or spaces and whatever the number of spaces.
Regards.
--
components: IO
messages: 387976
nosy: romainfv
priority: normal
severity: normal
status: open
title: Pasting multiple lines in the REPL is broken since 3.9
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue43379>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43379] Pasting multiple lines in the REPL is broken since 3.9
Romain Vincent added the comment:
The lack of dots was something I noticed.
So from your questions (Ned Deily) I have been testing out several things and
found a "wae"!
But first, to answer your questions:
1. both LF and CRLF and it didn't change anything.
2. Running "import readline;print(readline.__doc__)" prints
"... GNU readline", with python 3.7, 3.8 and 3.9.
3. I am using iTerm2, but the problem also happens on MacOS's native
Terminal.app. Versions of python were installed with **homebrew**.
Maybe worth to mention: if I paste my code in a multi line string to execute
with python -c, then it works properly.
e.g.
---
python3.9 -i -c 'a = 42
if a:
print("hello world")
'
hello world
>>>
---
The example is different because I realized I had the same problem on python3.7
and python3.8 when the 2 first lines were at the same level of indentation
(Note sure if this gives a hint as to what the problem is).
HOWEVER, if I use python versions directly downloaded from
https://www.python.org/, then I don't have the problem at all!
Demonstration:
---
/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7
Python 3.7.2 (v3.7.2:9a3ffc0492, Dec 24 2018, 02:44:43)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline;print(readline.__doc__)
Importing this module enables command line editing using libedit readline.
>>> a = 42
>>> if a:
... print("hello world")
...
hello world
>>>
---
Same for python3.9
--
___
Python tracker
<https://bugs.python.org/issue43379>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41024] doc: Explicitly mention use of 'enum.Enum' as a valid container for 'choices' argument of 'argparse.ArgumentParser.add_argument'
New submission from vincent-ferotin : It is currently not obvious, reading :mod:`argparse` documentation, that :meth:`argparse.ArgumentParser.add_argument` could accept as 'choices' parameter an :class:`enum.Enum`. However, it seems (at least to me) that this 'choices' parameter [1] is the perfect candidat of enums usage (see [2]). So I suggest here to explicitly mention and illustrate such usage in current Python documentation. As far I as could test, such usage works at least with Python 3.5, 3.7, and 3.8. A small patch on 'master' branches is in progress, and should shortly be available as a GitHub pull-request. [1] https://docs.python.org/3/library/argparse.html#choices [2] PEP 435: https://www.python.org/dev/peps/pep-0435/#motivation -- assignee: docs@python components: Documentation messages: 371812 nosy: Vincent Férotin, docs@python priority: normal severity: normal status: open title: doc: Explicitly mention use of 'enum.Enum' as a valid container for 'choices' argument of 'argparse.ArgumentParser.add_argument' type: enhancement versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41024] doc: Explicitly mention use of 'enum.Enum' as a valid container for 'choices' argument of 'argparse.ArgumentParser.add_argument'
Change by vincent-ferotin : -- keywords: +patch pull_requests: +20142 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20964 ___ Python tracker <https://bugs.python.org/issue41024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41024] doc: Explicitly mention use of 'enum.Enum' as a valid container for 'choices' argument of 'argparse.ArgumentParser.add_argument'
Vincent Férotin added the comment: Explicitly add Raymond Hettinger to nosy list, as he reviewed the corresponding PR. -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue41024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41024] doc: Explicitly mention use of 'enum.Enum' as a valid container for 'choices' argument of 'argparse.ArgumentParser.add_argument'
Vincent Férotin added the comment: Unless I am mistaken, merged pull-request was not backported from master to other potential branches (3.5 -> 3.9 included). There was a message from GitHub 'miss-islington' bot (https://github.com/python/cpython/pull/20964#issuecomment-646991186) saying, if I understand correctly, to manually cherry-pick merged commit to other branches. Am I correct? And if so, is there some automatic process for this cherry-picking to re-run, or do someone have to do it manually? -- status: open -> pending ___ Python tracker <https://bugs.python.org/issue41024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1785] "inspect" gets broken by some descriptors
Vincent Pelletier added the comment: This change causes the following behaviour: >>> import inspect >>> class B(object): ... def f(self): ... pass ... >>> inspect.getmembers(B, inspect.ismethod) [] While I would expect the result to contain f: >>> inspect.ismethod(B.f) True Isn't this a regression ? Regards, Vincent Pelletier -- nosy: +vpelletier ___ Python tracker <http://bugs.python.org/issue1785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1785] "inspect" gets broken by some descriptors
Vincent Pelletier added the comment: Sorry, I forgot to mention I'm using python2.7 . -- ___ Python tracker <http://bugs.python.org/issue1785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13840] create_string_buffer rejects str init_or_size parameter
New submission from Vincent Pelletier :
ctypes.create_string_buffer documentation[1] says init_or_size parameter should
accept a string. As of 3.2, it raises:
>>> import ctypes
>>> ctypes.create_string_buffer('foo')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.2/ctypes/__init__.py", line 59, in create_string_buffer
buf.value = init
TypeError: str/bytes expected instead of str instance
It works fine as of 2.7 (and very probably any 2.x up to ctypes introduction):
>>> import ctypes
>>> ctypes.create_string_buffer('foo')
[1] http://docs.python.org/py3k/library/ctypes.html#ctypes.create_string_buffer
Regards,
Vincent Pelletier
--
components: ctypes
messages: 151800
nosy: vpelletier
priority: normal
severity: normal
status: open
title: create_string_buffer rejects str init_or_size parameter
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue13840>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13840] create_string_buffer rejects str init_or_size parameter
Vincent Pelletier added the comment: Thanks for the quick reply. FWIW, in 2.7 doc ctype.create_string_buffer is said to accept unicode objects as parameter. I don't use this personally, so I don't mind 3.x only working on bytes - and already fixed my code accordingly. It's just that I noticed this after your answer. Also, I didn't try to confirm if it actually works. -- ___ Python tracker <http://bugs.python.org/issue13840> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35409] Async generator might re-throw GeneratorExit on aclose()
Change by Vincent Michel : -- pull_requests: +14550 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14755 ___ Python tracker <https://bugs.python.org/issue35409> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31307] ConfigParser.read silently fails if filenames argument is a byte string
New submission from Vincent Michel: Calling `config_parser.read` with `'test'` is equivalent to: config_parser.read(['test']) while calling `config_parser.read` with `b'test'` is treated as: config_parser.read([116, 101, 115, 116]) which means python will try to open the file descriptors 101, 115 and 116. I don't know if byte path should be supported, but this is probably not the expected behavior. The method code: https://github.com/python/cpython/blob/master/Lib/configparser.py#L678-L702 -- components: Library (Lib) messages: 301026 nosy: vxgmichel priority: normal severity: normal status: open title: ConfigParser.read silently fails if filenames argument is a byte string type: behavior versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue31307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31307] ConfigParser.read silently fails if filenames argument is a byte string
Changes by Vincent Michel : -- pull_requests: +3417 ___ Python tracker <http://bugs.python.org/issue31307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29627] configparser.ConfigParser.read() has undocumented/unexpected behaviour when given a bytestring path.
Changes by Vincent Michel : -- pull_requests: +3418 ___ Python tracker <http://bugs.python.org/issue29627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31532] Py_GetPath, Py_SetPath memory corruption due to mixed PyMem_New micex with PyMem_Raw_Free
Changes by Vincent Gatine : -- keywords: +patch pull_requests: +3668 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31532] Py_GetPath, Py_SetPath memory corruption due to mixed PyMem_New micex with PyMem_Raw_Free
Changes by Vincent Gatine : -- nosy: +nurelin ___ Python tracker <https://bugs.python.org/issue31532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31532] Py_GetPath, Py_SetPath memory corruption due to mixed PyMem_New micex with PyMem_Raw_Free
Vincent Gatine added the comment: Tried your suggestion. Nothing is printed and program still crash. -- ___ Python tracker <https://bugs.python.org/issue31532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35409] Async generator might re-throw GeneratorExit on aclose()
New submission from Vincent Michel : As far as I can tell, this issue is different than: https://bugs.python.org/issue34730 I noticed `async_gen.aclose()` raises a GeneratorExit exception if the async generator finalization awaits and silence a failing unfinished future (see example.py). This seems to be related to a bug in `async_gen_athrow_throw`. In fact, `async_gen.aclose().throw(exc)` does not silence GeneratorExit exceptions. This behavior can be reproduced without asyncio (see test.py). Attached is a possible patch, although I'm not too comfortable messing with the python C internals. I can make a PR if necessary. -- components: Interpreter Core files: example.py messages: 331043 nosy: vxgmichel priority: normal severity: normal status: open title: Async generator might re-throw GeneratorExit on aclose() type: behavior versions: Python 3.6, Python 3.7, Python 3.8 Added file: https://bugs.python.org/file47972/example.py ___ Python tracker <https://bugs.python.org/issue35409> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35409] Async generator might re-throw GeneratorExit on aclose()
Change by Vincent Michel : Added file: https://bugs.python.org/file47973/test.py ___ Python tracker <https://bugs.python.org/issue35409> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35409] Async generator might re-throw GeneratorExit on aclose()
Change by Vincent Michel : -- keywords: +patch Added file: https://bugs.python.org/file47974/patch.diff ___ Python tracker <https://bugs.python.org/issue35409> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed.
New submission from Brennan Vincent : To reproduce: (1) build python: `../configure --prefix=$HOME/prefix --with-pydebug --without-pymalloc && make install` (2) run with valgrind: `valgrind --leak-check=full ~/prefix/bin/python3` (3) exit immediately from the interpreter by pressing ^D (4) Note the following output from Valgrind: ``` ==3810071== 40 bytes in 1 blocks are definitely lost in loss record 3 of 527 ==3810071==at 0x4C28B5F: malloc (vg_replace_malloc.c:299) ==3810071==by 0x59ED58: growable_int_array_init (parsetok.c:27) ==3810071==by 0x59EE14: parsetok (parsetok.c:235) ==3810071==by 0x59F697: PyParser_ParseFileObject (parsetok.c:176) ==3810071==by 0x522E85: PyParser_ASTFromFileObject (pythonrun.c:1224) ==3810071==by 0x5231E9: PyRun_InteractiveOneObjectEx (pythonrun.c:238) ==3810071==by 0x5234D0: PyRun_InteractiveLoopFlags (pythonrun.c:120) ==3810071==by 0x523BF2: PyRun_AnyFileExFlags (pythonrun.c:78) ==3810071==by 0x4204FE: pymain_run_stdin (main.c:1185) ==3810071==by 0x42126B: pymain_run_python (main.c:1675) ==3810071==by 0x422EE0: pymain_main (main.c:1820) ==3810071==by 0x422F75: _Py_UnixMain (main.c:1857) ``` Reproduced on git commit hash 522346d792d9013140a3f4ad3534ac10f38d9085 . -- components: Interpreter Core messages: 335274 nosy: umanwizard priority: normal severity: normal status: open title: `growable_int_array type_ignores` in parsetok.c is not always freed. type: resource usage versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue35973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35973] `growable_int_array type_ignores` in parsetok.c is not always freed.
Brennan Vincent added the comment: Hi Guido, I have tried applying your patch. It seems to fix the issue (Valgrind no longer reports memory definitely lost). -- ___ Python tracker <https://bugs.python.org/issue35973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31062] socket.makefile does not handle line buffering
Change by Vincent Michel : -- keywords: +patch pull_requests: +12333 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31062] socket.makefile does not handle line buffering
Vincent Michel added the comment: I ran into this issue too so I went ahead and created a pull request (https://github.com/python/cpython/pull/12370). -- nosy: +vxgmichel versions: +Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue31062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294959] Problems with /usr/lib64 builds.
Change by Bob Vincent : -- nosy: +pillarsdotnet ___ Python tracker <https://bugs.python.org/issue1294959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31922] Can't receive replies from multicast UDP with asyncio
New submission from Vincent Michel : It's currently not possible to receive replies from multicast UDP with asyncio, as reported in the following issue: https://github.com/python/asyncio/issues/480 That's because asyncio connects the UDP socket to the broadcast address, causing all traffic from the receivers to be be dropped, as explained in this comment: https://github.com/python/asyncio/issues/480#issuecomment-278703828 I already submitted a PR on the cpython repository: https://github.com/python/cpython/pull/423 I figured it was better to report the issue here for better tracking. -- components: asyncio messages: 305415 nosy: vxgmichel, yselivanov priority: normal pull_requests: 4196 severity: normal status: open title: Can't receive replies from multicast UDP with asyncio type: behavior versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue31922> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33979] Display type of not JSON serializable object
New submission from Vincent Lefoulon : When we call `json.dumps` on a non JSON serializable object, we obtain an error: ``` TypeError: 4 is not JSON serializable ``` Here, 4 was actually a `numpy.int64` object and not a native int. But it is not explicit in the error message. We should mention the type of the object as well: ``` TypeError: 4 of type numpy.int64 is not JSON serializable ``` -- messages: 320570 nosy: Vayel priority: normal severity: normal status: open title: Display type of not JSON serializable object type: enhancement versions: Python 3.5 ___ Python tracker <https://bugs.python.org/issue33979> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33979] [Exception message] Display type of not JSON serializable object
Change by Vincent Lefoulon : -- title: Display type of not JSON serializable object -> [Exception message] Display type of not JSON serializable object ___ Python tracker <https://bugs.python.org/issue33979> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34747] SSLSocket.context cannot be changed on non-connected sockets
New submission from Vincent Pelletier : >From ssl.py, both on 2.7.15 and 3.6.6: class SSLSocket(...): ... @context.setter def context(self, ctx): self._context = ctx self._sslobj.context = ctx _sslobj is only set when socket is connected. While this is not a big issue for client sockets as user could just wrap the socket with correct context to begin with, and not a big issue for server sockets for the same reason, it is an issue for listening sockets: they are never connected, by definition, and do not care about _sslobj: upon accept() they only use self._context to wrap created socket. Suggested fix: @context.setter def context(self, ctx): self._context = ctx if self._sslobj: self._sslobj.context = ctx (consistently with how _sslobj is evaluated as a boolean elsewhere in the same class) Suggested workaround (ex: if this fix is not backported to 2.7): try: ssl_socket.context = new_context except AttributeError: pass as _context is changed first, and it's all that matters. -- messages: 325847 nosy: vincent-nexedi priority: normal severity: normal status: open title: SSLSocket.context cannot be changed on non-connected sockets type: behavior versions: Python 2.7, Python 3.6 ___ Python tracker <https://bugs.python.org/issue34747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34561] Replace list sorting merge_collapse()?
Vincent Jugé added the comment: Dear all, After me and my colleagues worked on the first paper you mention, I recently created another merge-based sorting algorithm, which I called "Adaptive Shivers Sort". This is a close variant of the Augmented Shivers Sort presented by Buss & Knop in their article https://arxiv.org/abs/1801.04641 Like Munro & Wild's Powersort and Peeksort, this algorithm has an optimal worst-case running time (up to a linear additive constant) when measured with the merge cost model that is used in all the articles you cite in this discussion. It also maintains a stack of size log_2(n). I could not prove such an optimality result for Buss & Knop Augmented Shivers Sort. Custom tests that I had performed suggest that this algorithm is, in practice, as efficient as Munro & Wild's algorithms, and also does not suffer from critically bad cases. Moreover, like Buss & Knop's 2-merge, and unlike Munro & Wild's Powersort and Peeksort, this algorithm has the advantage of having a structure that is very similar to that of Timsort, which may be an advantage in your situation. That is why, upon reading your discussion, I refurbished my notes about Adaptive Shivers Sort, which you may find here: http://igm.univ-mlv.fr/~juge/papers/shivers_arxiv.pdf These notes include a description of the algorithm and a worst-time complexity analysis. If extending my analysis of this algorithm or investigating tuning details were of interest for you, I would be happy to help. Best regards, Vincent Jugé -- nosy: +vincent.juge ___ Python tracker <https://bugs.python.org/issue34561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34561] Replace list sorting merge_collapse()?
Vincent Jugé added the comment: I see... Indeed, my only goal when adapting Shivers Sort was to maintain some invariant that would make the analysis easy, while mimicking the arguments developed by Buss & Knop for their analysis of (plain) Shivers Sort. It is, however, sure that the n(H+4) upper bound I get should be refined when H is small, which more or less amounts to tackling the 3-run case you mention. I am reasonably convinced that the current version of Adaptive Shivers Sort could be adapted to take this problem into account, while keeping its overall simple stricture and complexity analysis. If this first step turns out to be feasible, I will also look at the latest version of runstack.py to investigate other possible improvements on Adaptive Shivers Sort. -- ___ Python tracker <https://bugs.python.org/issue34561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34561] Replace list sorting merge_collapse()?
Vincent Jugé added the comment: After having worked a little bit on improving AdaptiveShiversSort on few-run cases, I designed a new version of the algorithm, called shivers2 in the file runstack.py joined to this message It looks more complicated than the original AdaptiveShiversSort but the spirit, inspired by your comments, is as follows: - we allow the second (bottom-most) element of the stack to be moderately larger than the bottom-most one; if that 2nd element were way larger than the 1st one, merging them, even if not optimal, would not be too painful anyways; - we may force a merge between these 1st and 2nd elements only when the 2nd element is about to be merged with the 3rd one; - similarly, we allow the top-most element of the stack to be moderately larger than the second top-most one; - otherwise, we stick to the behaviour of AdaptiveShiversSort. This variant's performance seems comparable with Powersort's. Reasonable follow-up work that I plan to do in the coming weeks (when I have time to do so) is: - prove that the new algorithm still runs in n H + O(n), - investigate whether we can have guarantees such as "this new sort's merge cost is at most XXX times larger than the optimal merge cost", - investigate improvements for Powersort. Given its excellent overall performance, I think that trying to slightly tweak Powersort in cases it underperforms other sorts might be worth some effort. Best, Vincent -- Added file: https://bugs.python.org/file47839/runstack.py ___ Python tracker <https://bugs.python.org/issue34561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34747] SSLSocket.context cannot be changed on non-connected sockets
Change by Vincent Pelletier : -- assignee: -> christian.heimes components: +Library (Lib), SSL nosy: +christian.heimes ___ Python tracker <https://bugs.python.org/issue34747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34747] SSLSocket.context cannot be changed on non-connected sockets
Vincent Pelletier added the comment: The reason which led me into this is server certificate renewal: my service crashed on that setter 2 months after starting, when it received a new certificate. I toyed with the idea of closing the listening sockets, but without closing would be even better - code changing socket certificate is much simpler than having to stop all worker treads (SocketServer.ThreadingMixIn), close the listening sockets, and start them all again in new threads with a new wrap_socket'ed listening socket. -- ___ Python tracker <https://bugs.python.org/issue34747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35065] Reading received data from a closed TCP stream using `StreamReader.read` might hang forever
New submission from Vincent Michel : I'm not sure whether it is intended or not, but I noticed a change in the behavior of `StreamReader` between version 3.7 and 3.8. Basically, reading some received data from a closed TCP stream using `StreamReader.read` might hang forever, under certain conditions. I'm not sure what those conditions are but I managed to reproduce the issue consistently with the following workflow: - server writes some data - client reads a part of the data - client closes the writer - server closes the writer - client tries to read the remaining data The test attached implements the behavior. It fails on 3.8 but passes on 3.7 -- components: asyncio files: stuck_on_py38.py messages: 328430 nosy: asvetlov, vxgmichel, yselivanov priority: normal severity: normal status: open title: Reading received data from a closed TCP stream using `StreamReader.read` might hang forever versions: Python 3.8 Added file: https://bugs.python.org/file47891/stuck_on_py38.py ___ Python tracker <https://bugs.python.org/issue35065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35065] Reading received data from a closed TCP stream using `StreamReader.read` might hang forever
Vincent Michel added the comment: Hi Andrew! I reverted the commit associated with the following PR, and the hanging issue disappeared: https://github.com/python/cpython/pull/9201 I'll look into it. -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue35065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35065] Reading received data from a closed TCP stream using `StreamReader.read` might hang forever
Vincent Michel added the comment: I found the culprit: https://github.com/python/cpython/blob/a05bef4f5be1bcd0df63ec0eb88b64fdde593a86/Lib/asyncio/streams.py#L350 The call to `_untrack_reader` is performed too soon. Closing the transport causes `protocol.connection_lost()` to be "called soon" but by the time it is actually executed, the stream reader has been "untracked". Since the protocol doesn't know the stream reader anymore, it has not way to feed it the EOF. The fix attached removes the `_untrack_reader` call and definition altogether. I don't really see the point of this method since one has to wait for `connection_lost` to be executed before untracking the reader, but `connection_lost` already gets rid of the reader reference. With this fix, calling `writer.close` then awaiting `writer.wait_closed` (or awaiting `writer.aclose`) should: - close the transport - schedule `protocol.connection_lost` - wait for the protocol to be closed - run `protocol.connection_lost` - feed the EOF to the reader - set the protocol as closed - get rid of the reader reference in the protocol - return (making aclose causal and safe) - the reader can then be safely garbage collected But maybe I'm missing something about `_untrack_reader`? -- keywords: +patch Added file: https://bugs.python.org/file47893/patch-bpo-35065.diff ___ Python tracker <https://bugs.python.org/issue35065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
