[issue22373] PyArray_FromAny tries to deallocate double: 12 (d)
New submission from Riccardo: Hi, I found this strange behaviour of PyArray_FromAny that manifest only inside a parallel region of openmp. I am using python 2.7.4 and numpy 1.8.0 *** Reference count error detected an attempt was made to deallocate 12 (d) *** and this is due to the PyArray_FromAny function that apparently does something also to the reference of NPY_DOUBLE or invisibly uses some kind of global variable generating race condition in a parallel implementation? If i insert PyArray_FromAny in a critical region the error never pops up. Best Regards, Riccardo P.s. i tried to send you more details and a piece of code but some characters are not accepted by your e-mail, ask me if you want more details -- messages: 226655 nosy: Il_Fox priority: normal severity: normal status: open title: PyArray_FromAny tries to deallocate double: 12 (d) ___ Python tracker <http://bugs.python.org/issue22373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22373] PyArray_FromAny tries to deallocate double: 12 (d)
Riccardo added the comment: Great, i solved trying to avoid calls to python code in parallel regions. Thanks for pointing me in right direction, i wasn’t thinking at all to the GIL, i was convinced i had tryed everything and that it was a bug.. Regards On 10 Sep 2014, at 05:50, Stefan Behnel wrote: > > Stefan Behnel added the comment: > > Agreed that it's not a bug in CPython, but my guess is that it's not a bug in > NumPy either. The C function you call (which IIRC creates a new NumPy array) > almost certainly needs the GIL to protect it against race conditions, and > since you mentioned OpenMP, you most likely released the GIL. So, just > re-acquire the GIL around the call (and make sure you don't have any other > threading problems in your code). > > -- > nosy: +scoder > > ___ > Python tracker > <http://bugs.python.org/issue22373> > ___ -- ___ Python tracker <http://bugs.python.org/issue22373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8115] Pyojbc on Snow Leopard
New submission from Riccardo Rotondo : Hello, I'm having trouble with pyobj since I have installed Python 2.6.4 by official dmg download here. Befor I used python pre-installed in Snow Leopard and everything worked ok. Now I can't import pyobjc. I tried to perform easy_install pyobjc but I can't still import objc. The strangest thing is that it works for previos version! Here some log: rmacbpro:~ riccardorotondo$ python Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32) http://GCC 4.0.1 (Apple Inc. build 5493) on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import Foundation Traceback (most recent call last): File "", line 1, in ImportError: No module named Foundation >>> exit() rrmacbpro:~ riccardorotondo$ python2.5 Python 2.5.4 (r254:67916, Jul 7 2009, 23:51:24) http://GCC 4.2.1 (Apple Inc. build 5646) on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import Foundation >>> exit() Thanks for help Bye Riccardo -- assignee: ronaldoussoren components: Macintosh messages: 100823 nosy: RiccardoR, ronaldoussoren severity: normal status: open title: Pyojbc on Snow Leopard type: resource usage versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8115> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)
Riccardo Schirone added the comment: Will the flaw outlined in https://bugs.python.org/issue30458#msg347282 be fixed in python itself? If so, I think a CVE for python should be requested to MITRE (I can request one, in that case). Moreover, does it make sense to create a new bug to track the new issue? This bug already references 3 CVEs and it would probably just create more confusion to reference a 4th. What do you think? -- ___ Python tracker <https://bugs.python.org/issue30458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34155] email.utils.parseaddr mistakenly parse an email
Riccardo Schirone added the comment: CVE-2019-16056 has been assigned to this issue. See https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16056 . -- nosy: +rschiron ___ Python tracker <https://bugs.python.org/issue34155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)
Riccardo Schirone added the comment: CVE-2019-18348 has been assigned to the issue explained in https://bugs.python.org/issue30458#msg347282 . Maybe a separate bug for it would be better though. CVE-2019-18348 is about injecting CRLF in HTTP requests through the *host* part of a URL. -- ___ Python tracker <https://bugs.python.org/issue30458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38576] CVE-2019-18348 CRLF injection via the host part of the url passed to urlopen()
New submission from Riccardo Schirone :
Copy-pasted from https://bugs.python.org/issue30458#msg347282
The commit b7378d77289c911ca6a0c0afaf513879002df7d5 is incomplete: it doesn't
seem to check for control characters in the "host" part of the URL, only in the
"path" part of the URL. Example:
---
try:
from urllib import request as urllib_request
except ImportError:
import urllib2 as urllib_request
import socket
def bug(*args):
raise Exception(args)
# urlopen() must not call create_connection()
socket.create_connection = bug
urllib_request.urlopen('http://127.0.0.1\r\n\x20hihi\r\n :11211')
---
The URL comes from the first message of this issue:
https://bugs.python.org/issue30458#msg294360
Development branches 2.7 and master produce a similar output:
---
Traceback (most recent call last):
...
Exception: (('127.0.0.1\r\n hihi\r\n ', 11211), ..., None)
---
So urllib2/urllib.request actually does a real network connection (DNS query),
whereas it should reject control characters in the "host" part of the URL.
***
A second problem comes into the game. Some C libraries like glibc strip the end
of the hostname (strip at the first newline character) and so HTTP Header
injection is still possible is this case:
https://bugzilla.redhat.com/show_bug.cgi?id=1673465
***
According to the RFC 3986, the "host" grammar doesn't allow any control
character, it looks like:
host = IP-literal / IPv4address / reg-name
ALPHA (letters)
DIGIT (decimal digits)
unreserved= ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
reg-name = *( unreserved / pct-encoded / sub-delims )
IP-literal= "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
IPv6address =6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::"h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IPv4address
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
CVE-2019-18348 was assigned to this flaw, which is similar to CVE-2019-9947 and
CVE-2019-9740 but it is about the *host* part of a url.
--
messages: 355294
nosy: rschiron
priority: normal
severity: normal
status: open
title: CVE-2019-18348 CRLF injection via the host part of the url passed to
urlopen()
type: security
___
Python tracker
<https://bugs.python.org/issue38576>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)
Riccardo Schirone added the comment: I have created https://bugs.python.org/issue38576 to address CVE-2019-18348. @gregory.p.smith if you have particular complains about these CVEs feel free to let me know (even privately). I think the security impact of these flaws is: an application that relies on urlopen/HTTPConnection/etc. where either the query part, the path part or the host part are user-controlled, could be exploited to send unintended HTTP headers to other hosts (maybe services that would not be directly reachable by the user). FYI, there were some good replies to that CVE talk, one of which is https://grsecurity.net/reports_of_cves_death_greatly_exaggerated . -- ___ Python tracker <https://bugs.python.org/issue30458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38576] CVE-2019-18348: CRLF injection via the host part of the url passed to urlopen()
Riccardo Schirone added the comment: The glibc issue mentioned in the first comment is CVE-2016-10739 . -- ___ Python tracker <https://bugs.python.org/issue38576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38671] pathlib.Path.resolve(strict=False) returns relative path on Windows if the entry does not exist
Change by Riccardo Polignieri : -- nosy: +ricpol ___ Python tracker <https://bugs.python.org/issue38671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28686] py.exe ignored PATH when using python3 shebang
Riccardo Polignieri added the comment: Three years later, this problem seems on the way to fix itself (https://xkcd.com/1822/). Versioned shebangs (and versioned "/env" shebangs) used to be a more prominent issue when you needed a way to tell Python 2 / Python 3 scripts apart. With the sunset of Python 2.7-3.3 almost completed, now we have a reasonably homogeneous block of inter-compatible Pythons. True, py.exe won't cope very well with versioned shebangs, but this seems to become less and less annoying by the day. As for the other problem from issue 39785, ie Python 2 still being selected as "default" in deference to some arcane Linux convention that we have been dragging for ten years (even on Windows!)... it would be nice to finally have *that* fixed. But then again, having Python 2 installed on your Windows box is becoming increasingly rare. Most users are likely never hitting this weirdness any more. In the meantime, now we have yet another way of installing Python on Windows... versioned executables from the Store! With no py.exe! So, who knows, maybe py.exe is the past, versioned executable are the future... To sum up, while I would certainly add a note to the docs, to clarify that py.exe does not support versioned "/env" shebangs, IMO today the work needed to specify a behaviour for all possible cases, possibly even extending/modifying Linux conventions, is just too much to be worth the effort. -- ___ Python tracker <https://bugs.python.org/issue28686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40338] [Security] urllib and anti-slash (\) in the hostname
Riccardo Schirone added the comment: I agree I don't see a clear vulnerability here. -- nosy: +rschiron ___ Python tracker <https://bugs.python.org/issue40338> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42967] [CVE-2021-23336] urllib.parse.parse_qsl(): Web cache poisoning - `; ` as a query args separator
Riccardo Schirone added the comment: This CVE was reported against Python, however it does not seem to be Python's fault for supporting the `;` separator, which was a valid separator for older standards. @AdamGold for this issue to become a real security problem, it seems that the proxy has to be configured to ignore certain parameters in the query. For NGINX and Varnish proxies mentioned in the article it seems that by default they use the entire request path, host included, and other things as cache key. For NGINX in particular I could find some snippets online to manipulate the query arguments and split them in arguments, so to remove the "utm_*" arguments, however this does not seem a standard(or at least default) behaviour, nor something easily supported. I think that if that is the case and a user has to go out of his way to configure the (wrong) splitting of arguments in the proxy, it is not fair to blame python for accepting `;` as separator and assigning a CVE against it may cause confusion. For distributions this is problematic as they have 2 choices: 1) "fix" python but with the risk of breaking user's programs/scripts relying on the previous API 2) keep older version/unpatched python so that user's programs still work, but with a python version "vulnerable" to this CVE. None of these options is really ideal, especially if the problem is somewhere else. @AdamGold Could you elaborate a bit more on how common it is and how much configuration is required for proxies to make `;` a problem in python? -- nosy: +rschiron ___ Python tracker <https://bugs.python.org/issue42967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42967] [CVE-2021-23336] urllib.parse.parse_qsl(): Web cache poisoning - `; ` as a query args separator
Riccardo Schirone added the comment: > So far, we at openSUSE had to package at least SQLAlchemy, Twisted, yarl and > furl. The author of the first one acknowledged use of semicolon as a bug. I > don't think it was so bad. Did you upstream fixes for those packages? Asking because if this is considered a vulnerability in Python, it should be considered a vulnerability for every other tool/library that accept `;` as separator. For example, Twisted seems to have a parse_qs method in web/http.py file that splits by both `;` and `&`. Again, I feel like we are blaming the wrong piece of the stack, unless proxies are usually ignoring some arguments (e.g. utm_*) as part of the cache key, by default or in a very easy way. -- ___ Python tracker <https://bugs.python.org/issue42967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38805] locale.getlocale() returns a non RFC1766 language code
Riccardo Polignieri added the comment:
> `locale.getlocale()` is now returning strange results
Not really "strange results" - fact is, now "getlocale()" returns the locale
name *as if* it were already set from the beginnning (because it is, at least
in part).
Before:
>>> import locale # Python 3.7, new shell
>>> locale.getlocale()
(None, None)
>>> locale.setlocale(locale.LC_ALL, '') # say Hi from Italy
'Italian_Italy.1252'
>>> locale.getlocale()
('Italian_Italy', '1252')
now:
>>> import locale # Python 3.8, new shell
>>> locale.getlocale()
('Italian_Italy', '1252')
As for why returned locale names are "a little different" in Windows, I found
no better explanation that Eryk Sun's essays in
https://bugs.python.org/issue37945. Long story short, it's not even a bug
anymore... it's a hot mess and it won't be solved anytime soon.
But it's not the problem at hand, here. Returned locale names have not changed
between 3.7 and 3.8.
What *is* changed, though, is that now Python on Windows appears to set the
locale, implicitly, right from the start.
Except - maybe it does not, really:
>>> import locale # Python 3.8, new shell
>>> locale.getlocale()
('Italian_Italy', '1252')
>>> locale.localeconv()
{'int_curr_symbol': '', 'currency_symbol': '', 'mon_decimal_point': '',
'mon_thousands_sep': '', 'mon_grouping': [], 'positive_sign': '',
'negative_sign': '', 'int_frac_digits': 127, 'frac_digits': 127,
'p_cs_precedes': 127, 'p_sep_by_space': 127, 'n_cs_precedes': 127,
'n_sep_by_space': 127, 'p_sign_posn': 127, 'n_sign_posn': 127, 'decimal_point':
'.', 'thousands_sep': '', 'grouping': []}
As you can see, we have an Italian locale only in the name: the conventions are
still those of the default C locale.
If we explicitly set the locale, on the other hand...
>>> locale.setlocale(locale.LC_ALL, '')
'Italian_Italy.1252'
>>> locale.localeconv()
{'int_curr_symbol': 'EUR', 'currency_symbol': '€', ... ... }
... now we enjoy a real Italian locale - pizza, pasta, gelato and all.
What happened?
Unfortunately, this change of behaviour is NOT documented, except for a passing
note here: https://docs.python.org/3/whatsnew/changelog.html#id144. It's buried
*very* deep:
"""
bpo-34485: On Windows, the LC_CTYPE is now set to the user preferred locale at
startup. Previously, the LC_CTYPE locale was “C” at startup, but changed when
calling setlocale(LC_CTYPE, “”) or setlocale(LC_ALL, “”).
"""
This explains... something. Python now pre-sets *only* the LC_CTYPE category,
and that's why the other conventions remain unchanged.
Unfortunately, setting *that* one category changes the result yielded by
locale.getlocale(). But this is not a bug either, because it's the same
behaviour you would have in Python 3.7:
>>> locale.setlocale(locale.LC_CTYPE, '') # Python 3.7
'Italian_Italy.1252'
>>> locale.getlocale()
('Italian_Italy', '1252')
...and that's because locale.getlocale() with no arguments default, wait for
it, to getlocale(category=LC_CTYPE), as documented!
So, why Python 3.8 now pre-sets LC_CTYPE on Windows? Apparently, bpo-34485 is
part of the ongoing shakespearian feud between Victor Stinner and the Python
locale code. If you squint hard enough, you will see the answer here:
https://vstinner.github.io/locale-bugfixes-python3.html but at this point, I
don't know if anyone still keeps the score.
To sum up:
- there's nothing new about locale names - still the same mess;
- if locale names as returned by locale.getlocale() bother you, you should
follow Victor's advice here: https://bugs.python.org/issue37945#msg361806. Use
locale.setlocale(category, None) instead;
- if you relied on getlocale() with no arguments to test your locale, assuming
that either a locale is unset or it is "fully set", then you should stop now. A
locale can also be "partially set", and in fact it's just what happens now on
Windows by default. You should test for a specific category instead;
- changing the way the locale is set by default on Windows can be... rather
surprising and can lead to misunderstandings. I would certainly add a note in
the locale documentation to explain this new behaviour.
--
nosy: +ricpol
___
Python tracker
<https://bugs.python.org/issue38805>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42011] Documentation for logging.Filter.filter reports the wrong return type
New submission from Riccardo Coccioli : The documentation for the logging.Filter().filter() method states: #- Is the specified record to be logged? Returns 0 for no, nonzero for yes. If deemed appropriate, the record may be modified in-place. #- While its implementation returns a boolean in Lib/logging/__init__.py. Moreover the most recent version of mypy (0.790) reports it as an error if a custom class inherit from logging.Filter and implement a filter() method that returns an int as specified in the documentation: #- error: Return type "int" of "filter" incompatible with return type "bool" in supertype "Filter" [override] #- P.S. As a side note, the API for filter() is quite counter-intuitive as it requires the filter() method to return False to filter out the record and True to include it. -- assignee: docs@python components: Documentation messages: 378480 nosy: Riccardo Coccioli, docs@python priority: normal severity: normal status: open title: Documentation for logging.Filter.filter reports the wrong return type type: behavior 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/issue42011> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36742] CVE-2019-10160: urlsplit NFKD normalization vulnerability in user:password@
Riccardo Schirone added the comment: The fix for python-2.7 (https://github.com/python/cpython/pull/13815/files#diff-b577545d73dd0cdb2c337a4c5f89e1d7R183) causes errors when netloc contains characters that can't be encoded by 'ascii' codec. You can see it by doing: >>> netloc = u'example.com\uf...@bing.com' >>> raise ValueError(u"netloc '" + netloc + u"' contains invalid characters >>> under NFKC normalization") Traceback (most recent call last): File "", line 1, in ValueError: >>> str(netloc) Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'ascii' codec can't encode character u'\uff03' in position 11: ordinal not in range(128) I suggest we use `repr(netloc)` instead of `netloc` in the ValueError message. -- nosy: +rschiron ___ Python tracker <https://bugs.python.org/issue36742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36742] CVE-2019-10160: urlsplit NFKD normalization vulnerability in user:password@
Riccardo Schirone added the comment: > CVE-2019-10160 has been assigned by Red Hat to this flaw. For clarity, CVE-2019-10160 has been assigned to the bug introduced with the fix for the functional regression mentioned in this bug, and not to the bug itself explained in the first comment. See https://bugzilla.redhat.com/show_bug.cgi?id=1718388 for more details about it. -- ___ Python tracker <https://bugs.python.org/issue36742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35121] Cookie domain check returns incorrect results
Riccardo Schirone added the comment: Did anybody request a CVE for this issue? I think it deserves one as it is a security issue and it may leak cookies to wrong domains. Does anybody have anything against assigning a CVE to this issue? If not, I would try to get one from MITRE. -- nosy: +rschiron ___ Python tracker <https://bugs.python.org/issue35121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37463] socket.inet_aton IP parsing issue in ssl.match_hostname
Riccardo Schirone added the comment: As far as I know you can't request a hostname with spaces in it (which seems to be a precondition to trigger this bug) so I think an attacker cannot even create a malicious CA that would be mistakenly accepted by match_hostname. -- nosy: +rschiron ___ Python tracker <https://bugs.python.org/issue37463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699)
Riccardo Schirone added the comment: > > A second problem comes into the game. Some C libraries like glibc strip the > > end of the hostname (strip at the first newline character) and so HTTP > > Header injection is still possible is this case: > > https://bugzilla.redhat.com/show_bug.cgi?id=1673465 > The bug link raises permission error. Does fixing the host part fix this > issue too since there won't be any socket connection made? Is it possible to > have a Python reproducer of this issue? I think this was supposed to refer to CVE-2016-10739 (https://bugzilla.redhat.com/show_bug.cgi?id=1347549) -- nosy: +rschiron ___ Python tracker <https://bugs.python.org/issue30458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35121] Cookie domain check returns incorrect results
Riccardo Schirone added the comment: CVE-2018-20852 has been assigned to this flaw. -- ___ Python tracker <https://bugs.python.org/issue35121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10141] SocketCan support
Riccardo Magliocchetti added the comment: I have an issue related to this while trying to compile statically Python 3.6.1 against a static musl. The problem is that i have AF_CAN defined because it's defined in linux/socket.h but by not having HAVE_LINUX_CAN_H defined in pyconfig.h the header which contains the definition of struct sockaddr_can is not included. So i think (at least for linux) using AF_CAN for the conditionals is wrong and the HAVE_LINUX_CAN_H should be used instead. I think the same applies for CAN_RAW and CAN_BCM because they are defined in the generic linux/can.h and not in a feature specific header. -- nosy: +Riccardo Magliocchetti ___ Python tracker <http://bugs.python.org/issue10141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30864] Compile failure for linux socket CAN support
New submission from Riccardo Magliocchetti: I have an issue related to this while trying to compile statically Python 3.6.1 (but latest master looks the same) against a static musl. The problem is that i have AF_CAN defined because it's defined in linux/socket.h but by not having HAVE_LINUX_CAN_H defined in pyconfig.h the header which contains the definition of struct sockaddr_can is not included. I think (at least for linux) using AF_CAN for the conditionals is wrong and the HAVE_LINUX_CAN_H should be used instead. I think the same applies for CAN_RAW and CAN_BCM because they are defined in the generic linux/can.h and not in a feature specific header. Reference: http://bugs.python.org/issue10141 -- components: IO messages: 297816 nosy: Riccardo Magliocchetti priority: normal severity: normal status: open title: Compile failure for linux socket CAN support versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue30864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31334] select.poll.poll fails on BSDs with arbitrary negative timeouts
New submission from Riccardo Coccioli:
According to the Python documentation for the 'poll.poll([timeout])' method in
the 'select' module, any negative value for the 'timeout' parameter is valid
and should have the same behaviour [1]:
"If timeout is omitted, negative, or None, the call will block until there
is an event for this poll object."
Unfortunately, unlike the Linux, on many other OSes, including, but not limited
to, macOS and {Free,Open,Net}BSD, the 'poll()' system call requires that the
'timeout' parameter is a non-negative integer or exactly -1 (sometimes defined
as INFTIM). Any other negative value throws an error, see [2], [3], [4] and [5].
This is a snippet of code to reproduce the error:
#-
import select
p = select.poll()
p.poll(-100)
#-
Expected behaviour: block until there is an event for the poll object, in this
case block indefinitely
Current behaviour on macOS and FreeBSD: OSError: [Errno 22] Invalid argument
I was able to reproduce the error on:
- macOS Sierra 10.12.6 with those Python versions: 3.3.6, 3.4.6, 3.5.3, 3.6.2,
3.7.0a0 (heads/master:2ef37607b7)
- FreeBSD 11.1 with Python 3.7.0a0 (heads/master:2ef37607b7)
On Linux this doesn't happen because the 'poll()' system call accept any
negative value to wait indefinitely, see [6].
To adhere with the Python documentation described behaviour, I'm sending a pull
request to propose to force the 'timeout' value passed to the 'poll()' system
call to be exactly -1 (or INFTIM where defined) when a negative value is given.
This will not change the current behaviour on Linux and will have the behaviour
described in the documentation on other OSes where is currently failing with an
error.
[1] https://docs.python.org/3/library/select.html#poll-objects
[2] https://www.freebsd.org/cgi/man.cgi?poll
[3] https://man.openbsd.org/poll.2
[4] http://netbsd.gw.com/cgi-bin/man-cgi/man?poll
[5] From macOS 'man poll': "If timeout is greater than zero, it specifies a
maximum interval (in milliseconds) to wait for any file descriptor to become
ready. If timeout is zero, then poll() will return without blocking. If the
value of timeout is -1, the poll blocks indefinitely."
[6] http://man7.org/linux/man-pages/man2/poll.2.html
--
components: Extension Modules, FreeBSD, macOS
messages: 301202
nosy: Riccardo Coccioli, koobs, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: select.poll.poll fails on BSDs with arbitrary negative timeouts
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue31334>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31334] select.poll.poll fails on BSDs with arbitrary negative timeouts
Changes by Riccardo Coccioli : -- pull_requests: +3320 ___ Python tracker <http://bugs.python.org/issue31334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31334] select.poll.poll fails on BSDs with arbitrary negative timeouts
Riccardo Coccioli added the comment: This can actually be reproduced with Python 2.7 too (thanks @thiell to let me know). At first I thought that it was not because it doesn't repro with the stock macOS-shipped Python 2.7.10 on macOS Sierra 10.12.6, where the select.poll() is not available at all, see below. Updated list of version where I was able to reproduce the error: - macOS Sierra 10.12.6 with those Python versions: 2.7.10, 2.7.13, 3.3.6, 3.4.6, 3.5.3, 3.6.2, 3.7.0a0 (heads/master:2ef37607b7) - FreeBSD 11.1 with those Python versions: 2.7.13, 3.7.0a0 (heads/master:2ef37607b7) For reference, the repro code executed with the stock macOS-shipped Python: #-- $ /usr/bin/python Python 2.7.10 (default, Feb 7 2017, 00:08:15) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import select >>> p = select.poll() Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'poll' #-- If the PR 3277 that I've sent against the master branch with the fix will be accepted, I'm ready to send additional PRs to backport the fix in all affected versions. -- versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue31334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36015] streamhandler canont represent streams with an integer as name
New submission from Riccardo Magliocchetti :
When debugging uwsgi logging issues with python3.7 i got this on python 3.7.2:
Traceback (most recent call last):
File "/usr/lib/python3.7/logging/__init__.py", line 269, in
_after_at_fork_weak_calls
_at_fork_weak_calls('release')
File "/usr/lib/python3.7/logging/__init__.py", line 261, in
_at_fork_weak_calls
method_name, "method:", err, file=sys.stderr)
File "/usr/lib/python3.7/logging/__init__.py", line 1066, in __repr__
name = name + ' '
TypeError: unsupported operand type(s) for +: 'int' and 'str'
AFAICS uwsgi creates sys.stderr as an unbuffered file with PyFile_FromFd() and
sets it to sys dict.
--
components: Library (Lib)
messages: 335784
nosy: Riccardo Magliocchetti
priority: normal
severity: normal
status: open
title: streamhandler canont represent streams with an integer as name
type: crash
versions: Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue36015>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36015] streamhandler canont represent streams with an integer as name
Change by Riccardo Magliocchetti : -- keywords: +patch pull_requests: +11933 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36015] streamhandler canont represent streams with an integer as name
Riccardo Magliocchetti added the comment: Yeah, I'm not sure the pr is just papering over the real issue :) Need to check what io.open sets on name. IF it setting the fd as name instead of creating a string that would be still be a bug in Python to me. Could you please wait a bit for me to check that before closing? -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue36015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36015] streamhandler cannot represent streams with an integer as name
Riccardo Magliocchetti added the comment: Looking at Modules/_io/fileio.c::_io_FileIO___init___impl it seems an int for nameobj is just fine. Not sure I am looking at the right code though :) -- ___ Python tracker <https://bugs.python.org/issue36015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28686] py.exe ignored PATH when using python3 shebang
Riccardo Polignieri added the comment: @Jens Lindgren I know, pretty annoying right? But see previous answer by Paul here http://bugs.python.org/issue28686#msg287181 > The Unix ability to have 2 different versions of Python on PATH > and select which you use based on executable name doesn't exist > on Windows, and so there's no equivalent of the > Unix "#!/usr/bin/env pythonX[.Y]" Now if you ask me, I would expect py.exe to handle all common types of shebang you may find in the wild. But I assume that the correct answer instead is that "#!/usr/bin/env pythonX[.Y]" is not a portable shebang, and you just should stop using it. If you happen to find such a shebang in someone else's script, file a bug report there. -- ___ Python tracker <http://bugs.python.org/issue28686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36015] streamhandler cannot represent streams with an integer as name
Riccardo Magliocchetti added the comment: @Vinay Do you have any update on this? thanks -- ___ Python tracker <https://bugs.python.org/issue36015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36284] importlib.import_module() not thread safe if Exception is raised (3.4, 3.5)
New submission from Riccardo Coccioli :
It seems that importlib.import_module() is not thread-safe if the loaded module
raises an Exception on Python 3.4 and 3.5. I didn't find any thread-unsafe
related information in Python's documentation.
The frequency of the failure appears to be random.
This is the setup to reproduce the issue:
#- FILES STRUCTURE
├── fail.py
└── test.py
#-
#- CONTENT OF fail.py
ACCESSIBLE = 'accessible'
import nonexistent # raise RuntimeError('failed') is basically the same
NOT_ACCESSIBLE = 'not accessible'
#-
#- CONTENT OF test.py
import importlib
import concurrent.futures
def f():
try:
mod = importlib.import_module('fail')
# importlib.reload(mod) # WORKAROUND
try:
val = mod.NOT_ACCESSIBLE
except AttributeError as e:
val = str(e)
return (mod.__name__, type(mod), mod.ACCESSIBLE, val)
except ImportError as e:
return str(e)
with concurrent.futures.ThreadPoolExecutor(max_workers=3) as executor:
futures = [executor.submit(f) for i in range(5)]
for future in concurrent.futures.as_completed(futures):
print(future.result())
#-
Expected result:
#-
No module named 'nonexistent'
No module named 'nonexistent'
No module named 'nonexistent'
No module named 'nonexistent'
No module named 'nonexistent'
#-
Actual result:
#-
No module named 'nonexistent'
No module named 'nonexistent'
No module named 'nonexistent'
('fail', , 'accessible', "'module' object has no attribute
'NOT_ACCESSIBLE'")
('fail', , 'accessible', "'module' object has no attribute
'NOT_ACCESSIBLE'")
#-
In the unexpected output lines, the module has been "partially" imported. The
'mod' object contains a module object, and trying to access an attribute
defined before the import that raises Exception works fine, but trying to
access an attribute defined after the failing import, fails.
It seems like the Exception was not properly raised at module load time, but at
the same time the module is only partially loaded up to the failing import.
The actual number of half-imported modules varies between runs and picking
different values for max_workers and range() and can also be zero (normal
behaviour). Also the frequency of the issue varies.
Using multiprocessing.pool.ThreadPool() and apply_async() instead of
concurrent.futures.ThreadPoolExecutor has the same effect.
I was able to reproduce the issue with the following Python versions and
platforms:
- 3.4.2 and 3.5.3 on Linux Debian
- 3.4.9 and 3.5.6 on macOS High Sierra 10.13.6
While the issue doesn't show up at the best of my knowledge on:
- 3.6.7 and 3.7.2 on macOS High Sierra 10.13.6
Thanks to a colleague suggestion I also found a hacky workaround. Uncommenting
the line in test.py marked as 'WORKAROUND' a reload of the module is forced.
With that modification the actual result is:
#-
No module named 'nonexistent'
No module named 'nonexistent'
No module named 'nonexistent'
module fail not in sys.modules
module fail not in sys.modules
#-
While this doesn't solve the issue per se, it actually raises the same
ImportError that the module was supposed to raise in the first place, just with
a different message, allowing the code to continue it's normal execution.
--
components: Library (Lib)
messages: 337887
nosy: Riccardo Coccioli
priority: normal
severity: normal
status: open
title: importlib.import_module() not thread safe if Exception is raised (3.4,
3.5)
type: behavior
versions: Python 3.4, Python 3.5
___
Python tracker
<https://bugs.python.org/issue36284>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36422] tempfile.TemporaryDirectory() removes entire directory tree even if it's a mount-point
New submission from Riccardo Murri :
The behavior of `tempfile.TemporaryDirectory()` is to delete the
temporary directory when done; this behavior cannot be turned off
(there's no `delete=False`like `NamedTemporaryFile` has instead).
However, in case a filesystem has been mounted on the temporary
directory, this can lead to the entire filesystem being removed.
While I agree that it would be responsibility of the programmer to
ensure that anything that has been mounted on the temp dir is
unmounted, the current behavior makes it quite easy to shoot oneself
in the foot. Consider the following code::
@contextmanager
def mount_sshfs(localdir, remote):
subprocess.run(f"sshfs {remote} {localdir}")
yield
subprocess.run(f"fusermount -u {localdir}", check=True)
with TemporaryDirectory() as tmpdir:
with mount_sshfs(tmpdir, remote):
# ... do stuff ...
Now, even if the `fusermount` call fails, cleanup of
`TemporaryDirectory()` will be performed and the remote filesystem
will be erased!
Is there a way this pattern can be prevented or at least mitigated?
Two options that come to mind:
* add a `delete=True/False` option to `TemporaryDirectory` like
`NamedTemporaryFile` already has
* add a `delete_on_error` option to avoid performing cleanup during error exit
from a `with:` block
I have seen this happen with Py 3.6 but it's likely there in the entire 3.x
series since `TemporaryDirectory` was added to stdlib.
Thanks,
Riccardo
--
components: Library (Lib)
messages: 338795
nosy: riccardomurri
priority: normal
severity: normal
status: open
title: tempfile.TemporaryDirectory() removes entire directory tree even if it's
a mount-point
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue36422>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36422] tempfile.TemporaryDirectory() removes entire directory tree even if it's a mount-point
Riccardo Murri added the comment:
> you should be handling errors properly in the first place,
> e.g. by changing your mount_sshfs manager to:
>
> @contextmanager
> def mount_sshfs(localdir, remote):
> subprocess.run(f"sshfs {remote} {localdir}")
> try:
> yield
> finally:
> subprocess.run(f"fusermount -u {localdir}", check=True)
>
> so it actually performed the guaranteed cleanup you expected from it.
This would fix the case where errors occur in the "yield" part of the
`mount_sshfs` context manager, but would not protect from errors *in
the `fusermount -u` call itself*: if `fusermount -u` fails and throws
an exception, the entire mounted filesystem will be erased.
I would contend that, in general, `TemporaryDirectory.cleanup()`
should stop at filesystem boundaries and not descend filesystems
mounted in the temporary directory tree (whether the mount has been
done via a context manager as in the example above or by any other
means is irrelevant).
--
___
Python tracker
<https://bugs.python.org/issue36422>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36015] streamhandler cannot represent streams with an integer as name
Riccardo Magliocchetti added the comment: Friendly ping, would be helpful to get this resolved for 3.8.0. Thanks! -- ___ Python tracker <https://bugs.python.org/issue36015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33189] pygettext doesn't work with f-strings
New submission from Riccardo Polignieri :
Tested (on windows) with python 3.6, but I guess it's the same in py3.7:
# test.py
def hello(x):
print(_(f'hello {x}'))
> py pygettext.py test.py
Traceback (most recent call last):
File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 623, in
if __name__ == '__main__':
File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 597, in main
for _token in tokens:
File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 328, in
__call__
## 'tstring:', tstring
File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 382, in
__openseen
elif ttype == tokenize.STRING:
File "C:\Program Files\Python36\Tools\i18n\pygettext.py", line 236, in
safe_eval
# unwrap quotes, safely
File "", line 1, in
NameError: name 'x' is not defined
--
components: Demos and Tools
messages: 314712
nosy: Riccardo Polignieri
priority: normal
severity: normal
status: open
title: pygettext doesn't work with f-strings
type: behavior
versions: Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue33189>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33189] pygettext doesn't work with f-strings
Riccardo Polignieri added the comment:
> the error should be better
Yes, that's what I maeant - sorry I should have phrased better.
I marked by mistake a couple of f-strings for translation and totally forgot
about it for a while... it took me some time to figure out what was going on
with this NameError popping out of nowhere.
Curiously, xgettext handles this thing better (...or, far worse actually): it
just parses the f-string as a regular one, producing something like
msgid "hello {x}"
msgstr ""
But then of course Python will fail *silently* at runtime, never picking up the
translated version of the string...
--
___
Python tracker
<https://bugs.python.org/issue33189>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31334] select.poll.poll fails on BSDs with arbitrary negative timeouts
Riccardo Coccioli added the comment: Although it's documented as -1 in Linux man page [1], from my quick tests I was not able to get any error with negative values different from -1 and it seems to wait indefinitely as expected. Looking also at its implementation in [2], it doesn't seem to differentiate between negative values. It could be argued that is implementation dependent at the moment and the behaviour might change in the future. But, on a related note, the Python documentation doesn't say much either as what are acceptable values for the timeout parameter, see [3]. So at the moment there isn't any discrepancy between the Python documentation and the current behaviour IMHO, but I'm happy to open a separate task and send a PR if you think this should be improved/fixed too. [1] http://man7.org/linux/man-pages/man2/epoll_wait.2.html [2] http://elixir.free-electrons.com/linux/latest/source/fs/eventpoll.c#L1754 [3] https://docs.python.org/3.7/library/select.html -- ___ Python tracker <https://bugs.python.org/issue31334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31786] In select.poll.poll() ms can be 0 if timeout < 0
Change by Riccardo Coccioli : -- nosy: +Riccardo Coccioli ___ Python tracker <https://bugs.python.org/issue31786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31334] select.poll.poll fails on BSDs with arbitrary negative timeouts
Change by Riccardo Coccioli : -- pull_requests: +4008 ___ Python tracker <https://bugs.python.org/issue31334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34560] Backport of uuid1() failure fix
New submission from Riccardo Mottola : Backport proposal of fix for closed issue 32502 The patch was directly adapted from https://github.com/python/cpython/commit/d69794f4df81de731cc66dc82136e28bee691e1e applied to 2.7 and tested working for me. Discussion ongoing MacPorts requested to share said patch upstream https://github.com/macports/macports-ports/pull/2456 -- components: Library (Lib) files: uuid-64bit.patch keywords: patch messages: 324449 nosy: Riccardo Mottola priority: normal severity: normal status: open title: Backport of uuid1() failure fix type: crash versions: Python 2.7 Added file: https://bugs.python.org/file47776/uuid-64bit.patch ___ Python tracker <https://bugs.python.org/issue34560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34560] Backport of uuid1() failure fix
Riccardo Mottola added the comment: https://github.com/python/cpython/pull/9125 should close it -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15832] argparse: typechecks default value too early
New submission from Riccardo Murri:
The `argparse` module (tested with 2.7, but other versions might be
affected) checks the `default` value of an option too early: if the
default value raises an exception, then command-line parsing stops.
Consider for example the following code:
### begin sample #
import os
import argparse
def existing_filename(path):
if not os.access(path, os.F_OK | os.R_OK):
raise argparse.ArgumentTypeError("File '%s' does not exist or cannot be
read." % path)
return path
parser = argparse.ArgumentParser(description='Process a file.')
parser.add_argument('file', type=existing_filename,
default='/some/weird/default',
help='A file to process.')
args = parser.parse_args()
print ("Will process file '%s' ..." % args.file)
### end sample #
The intention here is that the default value should be used *if and
only if* the script users do not provide their own file to process.
It may happen that the default is invalid, but that should be reported
as an error only if the default is used, i.e., users did not provide
any file name to the script.
What happens instead is that the argparse errors out in any case, even
when `--help` is requested or when a valid file name is passed, as the
following two examples show:
rmurri@xenia:/tmp$ ./argparse-processes-defaults-too-early.py --help
Traceback (most recent call last):
File "./argparse-processes-defaults-too-early.py", line 18, in
args = parser.parse_args()
File "/usr/lib/python2.7/argparse.py", line 1688, in parse_args
args, argv = self.parse_known_args(args, namespace)
File "/usr/lib/python2.7/argparse.py", line 1710, in parse_known_args
default = self._get_value(action, default)
File "/usr/lib/python2.7/argparse.py", line 2239, in _get_value
raise ArgumentError(action, msg)
argparse.ArgumentError: argument file: File '/some/weird/default' does not
exist or cannot be read.
rmurri@xenia:/tmp$ ./argparse-processes-defaults-too-early.py /tmp/xxx.py
Traceback (most recent call last):
File "./argparse-processes-defaults-too-early.py", line 18, in
args = parser.parse_args()
File "/usr/lib/python2.7/argparse.py", line 1688, in parse_args
args, argv = self.parse_known_args(args, namespace)
File "/usr/lib/python2.7/argparse.py", line 1710, in parse_known_args
default = self._get_value(action, default)
File "/usr/lib/python2.7/argparse.py", line 2239, in _get_value
raise ArgumentError(action, msg)
argparse.ArgumentError: argument file: File '/some/weird/default' does not
exist or cannot be read.
Thanks!
--
components: Library (Lib)
messages: 169548
nosy: riccardomurri
priority: normal
severity: normal
status: open
title: argparse: typechecks default value too early
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue15832>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28686] py.exe ignored PATH when using python3 shebang
Riccardo Polignieri added the comment: > I'm inclined to say YAGNI, and we simply leave "/usr/bin/env python3" > undefined. I can't say I'm really happy with this answer. Fact is, 1) you almost always have to work from within a virtual env these days, 2) you really want to have meaningful shebangs (ie, version-specific) in your scripts because, well, 2017 and the world is still split between py2 and py3, 3) the py.exe launcher is the new shiny thing and we all just want to use it. So, it *could* annoy some people to find out that py.exe just can't handle both venvs and shebangs in a meaningful way, and you must give up on either venvs, or shebangs, or py.exe. As far as I know (3.6.0 and 2.7.13), you have 3 ways to invoke a script: 1) "version-specific" launcher (eg "py -3 foo.py"): this will always pick the system interpreter, never abides neither venvs nor shebangs. A perfectly defined, utterly useless behavior. 2) invoke interpreter (eg "python foo.py", the good old way): this will always be venvs-complaint, will never parse shebangs. And yet at the moment, it's probably your best option *when* inside a venv - and the worst when outside, of course. 3) "version-agnostic" launcher (eg "py foo.py"). Outside a venv, this will always abide version-specific shebangs (ie, "#!python3"); the only quirk being that when facing a generic shebang instead, it will pick Python 2 (because, 2017 and Linux...). Oh well, I can live with that. But when you are inside a venv, then - if it finds a "not-env" shebang (ie "python" or "/usr/bin/python"), then it will NOT abide the venv - frustrating, yet correct I suppose; - if it finds any kind of version-specific shebang (EVEN a "env"-type of shebang!), then again it will follow the shebang but NOT the venv, and will pick up the system interpreter. That, even when you are inside a venv that perfectly matches the shebang prescription. Now, this can be very frustrating because a useless "/usr/bin/env python" shebang triggers the correct behavior both inside and outside a venv, BUT a much more useful "usr/bin/env python3" will fail even if we are inside a matching venv. I feel that all it needs to be perfect is some kind of behavior like this: dear py.exe, - when you are invoked in a version-agnostic way, and - when you find an "env"-and-version-specific shebang in the script, then please, - just look at my %path% before doing anything else. It could be that the first interpreter you find there will just match the requirement from the shebang (that is, because on occasion I just know what I'm doing, and I've just activated a matching venv, you see). If so, just give me that Python and I will be ok; - otherwise, my bad: feel free to resume any other search strategy you find appropriate, and I will humbly accept whatever interpreter you may fetch, even a php one. I think this would be just reasonable enough. What I'm missing here? -- nosy: +ricpol ___ Python tracker <http://bugs.python.org/issue28686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28686] py.exe ignored PATH when using python3 shebang
Riccardo Polignieri added the comment: Paul: > it's not possible to tell by inspection the version of a Python interpreter. True, but it's an implementation detail. Couldn't be solved? Versioned interpreters a la Linux, of course, or maybe how about including some kind of manifest file? Steve: > including versioned executables wouldn't that resolve this issue naturally? Definitely. Paul: > 1. Use the Python executable that's first on PATH: "py" Except, that's currently *almost never* true when I'm inside a venv! (For this to be true, I must give up on versioned shebangs). Now, if only 'py' could *always* look at the PATH *only*, ignoring shebangs - well this would be at least consistent behavior. Now, the absolute worst scenario here is when you have a prompt like "(myenv) $>" screaming to your face that you are inside a venv, and you go "py foo.py" expecting the venv interpreter to execute foo.py, because you are inside a venv, right? But wait!, foo.py was actually written by some Linux hacker, therefore *versioned* shebang, therefore 'py' fetches the wrong (system) Python, therefore no dependencies found, therefore crash. How I'm supposed to solve this? Paul: > The only change I'd consider reasonable here would be a doc change Thanks, it would really help, because I'm afraid I can't make it work for me. Most of all, I would really appreciate some sort of "best practice" suggestion on how to put together 'py', venvs and shebang. At the moment, I'm afraid my provisional policy is as follows: - when outside a venv (almost never) it's ok to 'py'; - when inside a venv (almost always) go 'python' the old way, because 'py' is unreliable here, *unless* you manually check the shebang of your scripts before you execute them. Which practically means - almost never use 'py'. Is this the correct way to go? -- ___ Python tracker <http://bugs.python.org/issue28686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28686] py.exe ignored PATH when using python3 shebang
Riccardo Polignieri added the comment: Paul: > When inside a venv: - If you want to execute a script, use a shebang of #!/usr/bin/env python and then use `py myscript.py` Yes, I'm totally on board with this - that is, as far as I run my own scripts. I just wonder, what if one day I pip install someone else's work, and then bang!, 'py' is just working differently now, for a non-local reason, and without alerting me. It's true that all major libraries use the "right" kind of shebang these days... Still, I find it a bit disturbing nevertheless. But thanks for the clarifications, anyways - now 'py' expected behavior is much more clear to me. Eryk: > it's far simpler to just support versioned executable names Keeping my fingers crossed about this. > Even if we don't install links/copies with these names, I don't see the harm > in allowing the launcher to look for them. Users can create the links manually True, but It would allow for yet another possible source of confusion I'm afraid. No, if py were to look for versioned executables, then versioned executable should be supplied imo. -- ___ Python tracker <http://bugs.python.org/issue28686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4923] time.strftime documentation needs update
New submission from Riccardo Attilio Galli : there are discrepancies in the online documentation of strftime in time.strftime http://docs.python.org/library/time.html and datetime.strftime (http://docs.python.org/library/datetime.html) In particular, seems like datetime.strftime is the one up to date, having format codes %f and %z documented, and possibly others -- assignee: georg.brandl components: Documentation messages: 79667 nosy: georg.brandl, riquito severity: normal status: open title: time.strftime documentation needs update type: feature request versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue4923> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38968] int method works improperly
Change by Riccardo La Marca : -- files: Schermata 2019-12-04 alle 12.09.36.png nosy: Riccardo La Marca priority: normal severity: normal status: open title: int method works improperly versions: Python 3.8 Added file: https://bugs.python.org/file48755/Schermata 2019-12-04 alle 12.09.36.png ___ Python tracker <https://bugs.python.org/issue38968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38968] int method works improperly
Change by Riccardo La Marca : Removed file: https://bugs.python.org/file48755/Schermata 2019-12-04 alle 12.09.36.png ___ Python tracker <https://bugs.python.org/issue38968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38968] int method works improperly
Change by Riccardo La Marca : Added file: https://bugs.python.org/file48756/Code.png ___ Python tracker <https://bugs.python.org/issue38968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38969] The "int" method doesn't work correctly for long numbers with some decimal places.
New submission from Riccardo La Marca : PyDev console: starting. Python 3.8.0 (v3.8.0:fa919fdf25, Oct 14 2019, 10:23:27) [Clang 6.0 (clang-600.0.57)] on darwin >>> int(123456789012345678901234567890) 123456789012345678901234567890 >>> int(123456789012345678901234567890.76) 123456789012345677877719597056 -- messages: 357803 nosy: Riccardo La Marca priority: normal severity: normal status: open title: The "int" method doesn't work correctly for long numbers with some decimal places. type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38969> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43061] subprocess: feature request: Get only the stdout of the last shell command
New submission from Riccardo La Marca : This is a link with some examples of the required functionality: https://stackoverflow.com/questions/65952314 -- messages: 385909 nosy: Riccardo La Marca priority: normal severity: normal status: open title: subprocess: feature request: Get only the stdout of the last shell command type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue43061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43061] subprocess: feature request: Get only the stdout of the last shell command
Change by Riccardo La Marca : -- nosy: +monkeyman79, paul.j3, r.david.murray, v+python ___ Python tracker <https://bugs.python.org/issue43061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43061] subprocess: feature request: Get only the stdout of the last shell command
Change by Riccardo La Marca : -- nosy: +altendky, paul.moore, serhiy.storchaka, steve.dower, tim.golden, vstinner, zach.ware ___ Python tracker <https://bugs.python.org/issue43061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
