[issue39577] venv --prompt argument is ignored
New submission from Andrea : In creating a new virtual environment, the help suggest a --prompt argument to specify a different name by the time the environment is active. https://docs.python.org/3/library/venv.html The argument is apparently ignored as the folder name always appears instead to whatever is specified in the prompt. Checking at the config file content there nothing written inside, thought I'm not sure this should be the case. -- messages: 361548 nosy: andream priority: normal severity: normal status: open title: venv --prompt argument is ignored versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue39577> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39577] venv --prompt argument is ignored
Andrea added the comment: Operative system is OS X 10.15.3 (19D76) Catalina Python 3.7.4 installed via HomeBrew If I do this python -m venv ciao --prompt NewOne by the time I activate the environment, the prompt looks like (ciao) andreamoro@MacBookAir:~/Python Am I misunderstanding the behaviour of the prompt argument? Thanks Andrea -- ___ Python tracker <https://bugs.python.org/issue39577> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39577] venv --prompt argument is ignored
Andrea added the comment:
Hi,
Apologies for the delays in returning to you.
I have been using ZSH and Oh My ZSH on top. The prompt variable, which I have
customised, looks like the following:
%
$(virtualenv_info)$fg[magenta]%}%n%{$reset_color%}@%{$fg[yellow]%}$(box_name)%{$reset_color%}:%{$fg_bold[green]%}${PWD/#$HOME/~}%{$reset_color%}$(git_prompt_info)
%(?,,%{${fg_bold[white]}%}[%?]%{$reset_color%} )$ '
Judging from the documentation, I have the correct variable in place, so I'm
not sure what's the problem as of now.
What should be the right value in a standard bash or zsh shell?
Thanks
Andrea
--
___
Python tracker
<https://bugs.python.org/issue39577>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39577] venv --prompt argument is ignored
Andrea added the comment:
Actually, the virtual_info appears to be a function within the theme, that does
the following
function virtualenv_info {
[ $VIRTUAL_ENV ] && echo '('%F{blue}`basename $VIRTUAL_ENV`%f') '
}
So, eventually the problems is in the function that retrieves the wrong
variable.
My question at this stage is, where is this "Prompt" variable set?
Thanks
--
___
Python tracker
<https://bugs.python.org/issue39577>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13034] Python does not read Alternative Subject Names from SSL certificates larger than 1024 bits
New submission from Andrea Trasatti :
We found a problem with SSL certificates, when they are larger than 1024 bits
and you need to check Alternative Subject Names.
In our case we have a 2048 bit certificate, issued by Verisign for the domain
developer.nokia.com. The certificate also covers other sub-domains, once of
which is projects.developer.nokia.com. We found the issue using the mercurial
client, but we dug down to SSLSocket.getpeercert. It looks like when the
openSSL library reads the certificate it does not return any Alternative
Subject Name, even though they are there. Using the standard openssl binary we
could read the certificate with no problems and the alternative domain names
are all there, including the one we need.
See below two examples, the first is our 2048 bit certificate and what Python
returns. Then there is Google's code.google.com SSL certificate, 1024 bits and
as you can see Python returns the other names correctly.
This was tested with Python 2.7.2.
Binary for projects.developer.nokia.com
'0\x82\x06\xb10\x82\x05\x99\xa0\x03\x02\x01\x02\x02\x10\x0e\xf6_f@\xe4\xd1gtU\x9e39Rn80\r\x06\t*\x86H\x86\xf7\r\x01\x01\x05\x05\x000\x81\xbc1\x0b0\t\x06\x03U\x04\x06\x13\x02US1\x170\x15\x06\x03U\x04\n\x13\x0eVeriSign,
Inc.1\x1f0\x1d\x06\x03U\x04\x0b\x13\x16VeriSign Trust
Network1;09\x06\x03U\x04\x0b\x132Terms of use at https://www.verisign.com/rpa
(c)101604\x06\x03U\x04\x03\x13-VeriSign Class 3 International Server CA -
G30\x1e\x17\r11060800Z\x17\r120607235959Z0h1\x0b0\t\x06\x03U\x04\x06\x13\x02FI1\x0e0\x0c\x06\x03U\x04\x08\x13\x05Espoo1\x0e0\x0c\x06\x03U\x04\x07\x14\x05Espoo1\x0e0\x0c\x06\x03U\x04\n\x14\x05Nokia1\x0b0\t\x06\x03U\x04\x0b\x14\x02IT1\x1c0\x1a\x06\x03U\x04\x03\x14\x13developer.nokia.com0\x82\x01"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\x82\x01\x0f\x000\x82\x01\n\x02\x82\x01\x01\x00\xf8\xdeL"\x8az\xbb\xa6\xddj\x14\x89X\xeeh\x87\x07\xbd\xb3\xc5=!
\xb9\x80\xe8\xe6v"*\xec6w\x82\r\xb6b\x10\xb8\xe5\x06\x88w\xfd\x03\xa9\x82\x9d\xdf\xdb\xbft\xdb\x06\xc5\'\xdd\x83\x0e\
xf1GdM\x9a\x14\xefyO\x8e\x9dO,
\x92\xf8\xcf\xd3\xb3\xa8m\xc3@^\xa5\x0e\xfb$ddn\xc0\x1cV\xe4\xeaE\xce\x1eoG\xca\xf3\x01\xab\x08V\xd2<\x91\x7f7\xbc\x90\x16\xd6b\xdb\x83(ySA\xccH\x1b\x80"7)^\xe9\x1c\xcaZ&r-\xc6\xf0\xe0\xb6\xde\x16c
W\x0b\xf4\xd24ei[E\xbaY\xc9[;
\xbbs\nQ\xfc\x1b_TiM\x8e\xb6\x9c9\x7f}\xa3\xfe\x96\xab\xa9\xb4\x8dn\\S\xfc\x08\xd5\x1a71
\xd3\x14\xaaF\xd0\xe4\xcf\x0f-\xf9\x10\xa7U\xf6\x92\xafQa\x8b\x02x\xc7V;
\xe2F\xf5 L\xe4\xc1\r\x1f\xec|
\x02\xee\xda\x9ej\xb3\xda\xda\x9b\xf8\xaf\xb5\xa2=\x1e\n\x14qf\xe7\xef\xbd\x8av\xe7l\x9d7\x93\xea\x11\x02\x03\x01\x00\x01\xa3\x82\x03\x000\x82\x02\xfc0\x82\x01I\x06\x03U\x1d\x11\x04\x82\x01@0\x82\x01<\x82\x13developer.nokia.com\x82\x17www.developer.nokia.com\x82\x17aux.developer.nokia.com\x82\x16cc.developer.nokia.com\x82\x1cprojects.developer.nokia.com\x82\x17sso.developer.nokia.com\x82\x19stage.developer.nokia.com\x82\x17ejb.developer.nokia.com\x82\x16cm.developer.nokia.com\x82\x17dav.developer.nokia.com\x82\x1fdav.sandbox.developer.nokia.com\x
82\x1ect.sandbox.developer.nokia.com0\t\x06\x03U\x1d\x13\x04\x020\x000\x0b\x06\x03U\x1d\x0f\x04\x04\x03\x02\x05\xa00A\x06\x03U\x1d\x1f\x04:0806\xa04\xa02\x860http://SVRIntl-
G3-crl.verisign.com/SVRIntlG3.crl0D\x06\x03U\x1d
\x04=0;09\x06\x0b`\x86H\x01\x86\xf8E\x01\x07\x17\x030*0(\x06\x08+\x06\x01\x05\x05\x07\x02\x01\x16\x1chttps://www.verisign.com/rpa0(\x06\x03U\x1d%\x04!
0\x1f\x06\t`\x86H\x01\x86\xf8B\x04\x01\x06\x08+\x06\x01\x05\x05\x07\x03\x01\x06\x08+\x06\x01\x05\x05\x07\x03\x020r\x06\x08+\x06\x01\x05\x05\x07\x01\x01\x04f0d0$\x06\x08+\x06\x01\x05\x05\x070\x01\x86\x18http://ocsp.verisign.com0<\x06\x08+\x06\x01\x05\x05\x070\x02\x860http://SVRIntl-
G3-
aia.verisign.com/SVRIntlG3.cer0n\x06\x08+\x06\x01\x05\x05\x07\x01\x0c\x04b0`\xa1^\xa0\\0Z0X0V\x16\timage/gif0!
0\x1f0\x07\x06\x05+\x0e\x03\x02\x1a\x04\x14Kk\xb9(\x96\x06\x0c\xbb\xd0R8\x9b)\xacK\x07\x8b!
\x05\x180&\x16$http://logo.verisign.com/vslogo1.gif0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x05\x05\x00\x03\x82\x01\x01\x006N\x97\x1e\xba\x85\xcb\x1e
\xddO6\xf9\xf3\x16-\xb6\x05\x13"\xec*\x00\x0f\xde\x89\xc1\xb7\xc1^\xf0\x8b0=C\x87\xf3|
zI\xe4\r\xedmD1\xc1\x06[GqMuV\xd9\x03\xdd\xa6\xbd2Z!
\x0c\xdf\x93\x9c\xc6\xba\x12\xd1\xaa\xd08\x1c\x82\x02\xd1\xb3\xeeK\xca\xcaEK\x07\xffR\xcfW\xae\xa0\x85\xeb\xc1h\xeb\r\xad\xd5\x92d\x82\xac\x03(\x07\xa1F\x82\x93\xdep\xe9\x9a\xf8O\xb1\xfc\xe0&\xfat\xf4d\xa3q&`\x05J\xb9\xdb\x9a\xb5o;
\xb7O\xaa/\xac\xba\xab\xc9\xd9)m\xf2c\xe8=\xc4\x95\xef\xe9\x92\xee\tlx\xe2\xfc>\x87\xab\xbe\xde\xd4[\xc3\x85>X\x8f\xf3\xe3\x89\xc9,
\\\xb2:\x9f\xf3\xe2\xf3\x81;
\xdbk\x9f\x1e\xbc\x00\xc7\x87@\xb3\xac\xdf\xe09\xfe:
\xef\n\xcf\xdaCZ\xc7\x07X\xd0\x0f\xf2nBKe\x1f\xd8\xcc\xb4\xa2%\x01<\x0eE\nt{G\r\x9a\xfd\xaf\x97\xaf\xba\xb8\x983\xc5~\xd2\x1d\xdd\x04\x13*\xd3\xf3VK:'
Python dictionary extracted
{'notAfter': 'Jun 7 23:59:59 2012 GMT', 'subject': ((('
[issue13670] Increase test coverage for pstats.py
New submission from andrea crotti : This patch increases test coverage for pstats.py from 25 to 36%. It's my first proposed patch so sorry in advance if there are problems. Much more can be done for pstats.py (which is also not much commented) but I want to get some feedback on this first.. -- components: Tests files: test_pstats.diff keywords: patch messages: 150290 nosy: andrea.crotti priority: normal severity: normal status: open title: Increase test coverage for pstats.py type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file24098/test_pstats.diff ___ Python tracker <http://bugs.python.org/issue13670> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13670] Increase test coverage for pstats.py
andrea crotti added the comment: It's really hard to understand true, and if should not go in the patch in general of course. The sense was that the only test I added is trivial, but I haven't produced something better yet. And ok I will remove the docstrings, I was actually doing it on purpose thinking about the unittest feature, but if the name is clear enough than is better to leave the docstring out... Another thing, I didn't want to use tempfile.mktemp to generate a temporary file, but dump_stats doesn't accept anything else, is it in general safe to use it in this case? -- ___ Python tracker <http://bugs.python.org/issue13670> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2216] Problems using logging module with idle
New submission from Andrea Griffini:
I'm not a user of idle, but when asked about a strange behaviour of the
logging module I digged a bit and found what I think is indeed a problem
in the module itself.
The problem is visible if the module is used from idle (or any other IDE
that keeps the same python instance running for multiple execution of
user code); if you call basicConfig(filename="foo.txt"), do some logging
and call shutdown() the handler is closed (correctly closing the file)
but remains attached to the root logger, and gets called again at next
run (giving an error for invalid I/O on a closed file).
This can also be reproduced in a single run with
import logging
logging.basicConfig(filename="logtest.txt")
logging.warning("This is a test")
logging.shutdown()
logging.basicConfig(filename="logtest2.txt")
logging.warning("This is a test (2)")
logging.shutdown()
I think that it is not correct to close the handler but leave it in
place, so I tried patching the module so that every handler keeps a list
of all loggers it is attached to, and removes itself from loggers at
close() time. This way the above code runs correctly (creating two
files) and the logging module still passes the test suite.
I must however admit that logging logic is a bit beyond my grasp
(including a close() call commented out, some uses of lock/release I
don't understand) so may be the attached patch is not correct even if
passes the test.
--
components: Library (Lib)
files: logging.patch
keywords: patch
messages: 63179
nosy: ag6502
severity: normal
status: open
title: Problems using logging module with idle
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9583/logging.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2216>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2216] Problems using logging module with idle
Andrea Griffini added the comment: I thougt it was a bug because when calling close() handlers are removed from some data structure (the global dictionary and the global list) but they're left inside the loggers they're attached to. Now I understand that this is a responsibility of who attached the handler; probably my patch would break or just behave differently with code that already managed to remove logging handlers from loggers explicitly or that relied on the fact that even a "closed" handler can still be notified. Having the logging module to work correctly in IDLE and other environments that keep a running instance of the interpreter provided that shutdown is called would have been just a lucky nice side effect of "fixing" handler.close (of course those IDEs will still have potential problems with any module that keeps an internal state). __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2216> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5082] Let frameworks to register attributes as builtins
New submission from Andrea Corbellini : Most of the Python frameworks have some functions and classes that are widely used. For example a 'log.debug' function will be used in almost all modules. It is inconvenient to write 'import log' every time. It would be useful to have a special place (a dict or a special module) where you can declare attributes that can be used everywhere without importing anything. Currently, the only way to do this is: >>> import __builtin__ >>> __builtin__.debug = log.debug However, I think that this shouldn't be the better solution. Using something like '__framework__' would be really better, in my opinion. -- components: Interpreter Core messages: 80656 nosy: andrea-bs severity: normal status: open title: Let frameworks to register attributes as builtins ___ Python tracker <http://bugs.python.org/issue5082> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5082] Let frameworks to register attributes as builtins
Changes by Andrea Corbellini : -- type: -> feature request ___ Python tracker <http://bugs.python.org/issue5082> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5082] Let frameworks to register attributes as builtins
Andrea Corbellini added the comment: Well, writing every time 'from X import Y' looks to me uncomfortable. But of course what I'm asking is not essential :-) ___ Python tracker <http://bugs.python.org/issue5082> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38246] pathlib.resolve and .absolute leave trailing tilde in home expansion
Change by Andrea Bergonzo : -- nosy: +andybergon ___ Python tracker <https://bugs.python.org/issue38246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41928] ZipFile does not supports Unicode Path Extra Field (0x7075) zip header field
Change by Andrea Giudiceandrea : -- nosy: +andreaerdna ___ Python tracker <https://bugs.python.org/issue41928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41928] ZipFile does not supports Unicode Path Extra Field (0x7075) zip header field
Change by Andrea Giudiceandrea : -- keywords: +patch pull_requests: +22595 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23736 ___ Python tracker <https://bugs.python.org/issue41928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41928] ZipFile does not supports Unicode Path Extra Field (0x7075) zip header field
Andrea Giudiceandrea added the comment: I submitted more than a month ago a PR that adds support for Unicode Path Extra Field in ZipFile. The PR https://github.com/python/cpython/pull/23736 is awaiting a review in order to be merged. -- ___ Python tracker <https://bugs.python.org/issue41928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42148] floating point representation issues
New submission from Andrea Tuccia : I'm noticing some floating point representation precision issues that occurs on all versions and platforms: >>> 277*0.1 27.703 >>> 1.2-1.0 0.19996 >>> import numpy as np >>> np.double(277*0.1) 27.703 >>> np.double(1.2-1.0) 0.19996 >>> np.longdouble(277*0.1) 27.702842 >>> np.longdouble(1.2-1.0) 0.19995559 Verified with python 2.7 to 3.8. On x86 (i386 and amd64) and ARM (32 and 64 bits). It does not occur in C, LUA, Perl, ... -- components: Interpreter Core, Library (Lib) messages: 379589 nosy: atuccia priority: normal severity: normal status: open title: floating point representation issues type: behavior ___ Python tracker <https://bugs.python.org/issue42148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13991] namespace packages depending on order
New submission from andrea crotti :
I am not really sure that it is a bug, but for me it's at least not the
expected behaviour.
In short supposing I have two namespace packages ab and ac (as seen in the tar
file), this works perfectly:
import sys
from os import path
sys.path.append(path.abspath('ab'))
sys.path.append(path.abspath('ac'))
from a.b import api as api_ab
from a.c import api as api_ac
But this doesn't:
import sys
from os import path
sys.path.append(path.abspath('ab'))
from a.b import api as api_ab
sys.path.append(path.abspath('ac'))
from a.c import api as api_ac
And raises an ImportError
from a.c import api as api_ac
ImportError: No module named c
Which means that if you actually append all the paths containing package
resources before trying to import something it works, but if you interleave the
path mangling, it won't..
Is this a bug or maybe I'm doing something wrong?
--
assignee: tarek
components: Distutils
files: namespace.tar.gz
messages: 153076
nosy: andrea.crotti, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: namespace packages depending on order
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file24478/namespace.tar.gz
___
Python tracker
<http://bugs.python.org/issue13991>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13991] namespace packages depending on order
andrea crotti added the comment:
There is nothing binary in the archive, just a simple example of namespace
packages, which was the minimal example that I could create to make things fail.
I use the standard pkg_resources way to do things:
__import__('pkg_resources').declare_namespace(__name__)
--
___
Python tracker
<http://bugs.python.org/issue13991>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13991] namespace packages depending on order
andrea crotti added the comment: About the binary file, in theory I agree with you, but that archive contains 5 or 6 subdirectories with a few almost empty files. Of course I can write a script that recreates that situation, but does it make sense when I can just tar and untar it? And what should be the security threat in a tar.gz file? Anyway it doesn't matter and sure I will try to use plain text in the future.. About the bug, for what I can understand the bug comes from pkg_resources: /usr/lib/python2.7/site-packages/pkg_resources.py is owned by python2-distribute 0.6.24-1 and/or from how the import mechanism works on namespace packages, not from setuptools.. Should I still move the bug report to somewhere else? -- ___ Python tracker <http://bugs.python.org/issue13991> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13991] namespace packages depending on order
andrea crotti added the comment: I reopen the ticket because I'm still not convinced.. I tried to substitute the setuptools namespace declaration with the more standard python: from pkgutil import extend_path __path__ = extend_path(__path__, __name__) It behaves exactly in the same way, which makes me think that is more a problem in the importer, that doesn't behave as it should in case of namespace packages.. -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue13991> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13991] namespace packages depending on order
Changes by andrea crotti : -- resolution: invalid -> ___ Python tracker <http://bugs.python.org/issue13991> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37255] Pathlib: Add an expandUserPath method or argument
New submission from Andrea Moro : Assuming the given path contains a '~' character, it would be nice to have a function to expand the given path so any further calls to an .exists doesn't fail. A prototype of the function could be # Expand the home path in *ix based systems if any if '~' in s: x = [x for x in Path(s).parts if x not in '~'] p = Path.home() for item in x: p = p.joinpath(item) -- components: Library (Lib) messages: 345379 nosy: Andrea Moro priority: normal severity: normal status: open title: Pathlib: Add an expandUserPath method or argument type: enhancement ___ Python tracker <https://bugs.python.org/issue37255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37255] Pathlib: Add an expandUserPath method or argument
Andrea Moro added the comment: I have completely missed it. Thanks for flagging it. -- ___ Python tracker <https://bugs.python.org/issue37255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37255] Pathlib: Add an expandUserPath method or argument
Change by Andrea Moro : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29744] memmap behavior changed
New submission from Andrea Giovannucci: The previous version 2.7.12 was returning a memmap file when slicing with a list of integers, now it returns an array. This affects the behaviour of several functions in my package. Is that an aware choice or a side product of some other change? -- components: Demos and Tools messages: 289146 nosy: agiovannucci priority: normal severity: normal status: open title: memmap behavior changed type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue29744> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29744] memmap behavior changed
Changes by Andrea Giovannucci : -- resolution: -> not a bug ___ Python tracker <http://bugs.python.org/issue29744> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13670] Increase test coverage for pstats.py
andrea crotti added the comment: It has been a long time but if it's still useful sure. I can see some tests have been added in commit 863b1e4d0e95036bca4e97c1b8b2ca72c19790fb but if these are still relevant I'm happy to go ahead. -- ___ Python tracker <https://bugs.python.org/issue13670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32990] Supporting extensible format(PCM) for wave.open(read-mode)
New submission from Andrea Celletti : The wave.Wave_read class currently supports 8, 16, 24, and 32 bit PCM files. Wave files are only supported if the wFormatTag in the format chunk matches the flag WAVE_FORMAT_PCM, which is correct but incomplete for 24 bit files. According to the specification the WAVE_FORMAT_EXTENSIBLE format should be used whenever the actual number of bits/sample is not equal to the container size. Based on this specification, most applications export 24 bit PCM with the WAVE_FORMAT_EXTENSIBLE flag since 24 is stored in container size 32. Importing these files causes wave.open to raise an exception. The specification also explains how to detect 24PCM exported in this fashion as "The first two bytes of the GUID form the sub-code specifying the data format code, e.g. WAVE_FORMAT_PCM.". In essence, we have to look at the first two bytes of the SubFormat tag and that will tell us if this file is PCM. Based on this premise, it appears to me that there is no reason for not adding support for both format specification as the rest of the file is exactly the same for both. I am attaching a file that can be used to test the exception being raised. Source: http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html -- components: Library (Lib) files: pluck-pcm24-ext.wav messages: 313183 nosy: acelletti priority: normal severity: normal status: open title: Supporting extensible format(PCM) for wave.open(read-mode) type: enhancement Added file: https://bugs.python.org/file47467/pluck-pcm24-ext.wav ___ Python tracker <https://bugs.python.org/issue32990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32990] Supporting extensible format(PCM) for wave.open(read-mode)
Andrea Celletti added the comment: I am currently working on a patch for this. When done can I try pushing this in 3.7 rather than 3.8? It is not much of an enhancement but rather fixing the code that raises an error for a perfectly valid PCM wave file (bugfix). -- versions: -Python 3.8 ___ Python tracker <https://bugs.python.org/issue32990> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18156] Add an 'attr' attribute to AttributeError
Andrea Griffini added the comment: Even porting to the new wonderful 'attr' field is not going to make the code correct... (the exception could be bubbling up from code down ten frames about a different unrelated attribute that happens to have the same name in a different object). BTW cpython has a lot of those "except AttributeError" fragments coded in C with PyErr_ExceptionMatches. -- ___ Python tracker <http://bugs.python.org/issue18156> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16547] IDLE raises an exception in tkinter after fresh file's text has been rendered
Andrea Griffini added the comment: The error cannot be reproduced on 2.7, 3.3 or 3.4 because the problem has been fixed with 1e5e497ee33b (issue 17614) -- nosy: +ag6502 ___ Python tracker <http://bugs.python.org/issue16547> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18807] Allow venv to create copies, even when symlinks are supported
New submission from Andrea Corbellini: I'd really appreciate if `venv` could create environments without symlinks. Working on many Python projects, each one with different requirements, I prefer to keep everything I need in a single virtualenv directory, rather than two (one for the virtualenv and one for the built Python). So I'd like to have a --copies option that lets me force venv not to create symlinks. I can work on a patch if this issue is accepted. -- components: Library (Lib) messages: 195883 nosy: candrea priority: normal severity: normal status: open title: Allow venv to create copies, even when symlinks are supported versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue18807> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18454] distutils crashes when uploading to PyPI having only the username (no pw) defined
Changes by Andrea Corbellini : -- versions: +Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue18454> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15274] Patch for issue 5765: stack overflow evaluating eval("()" * 30000)
New submission from Andrea Griffini :
This is a fix for issue #5765: stack overflow evaluating eval("()" * 3)
The solution was to add two fields (recursion_depth and
recursion_limit) to the symbol table object and just increment and
check the depth in symtable_visit_expr raising a RuntimeError in case
the limit is exceeded.
The test case added also covers other similar cases (a.b.b.b.b.b...
and a[0][0][0][0])
There is no depth check in when visiting statement because I cannot
think to a way to nesting statements too much without getting other
errors before. If there is a way to do it, it would be trivial to also
cover that part.
The patch uses the current depth and current recursion limit but
multiplies them for a factor because I suppose that the amount of C
stack used by the compiler per recursion is smaller than the amount
used by the interpreter; the constant in the patch is 4. Using a
constant of 1 (i.e. just using the normal recursion limit) doesn't
allow a previously existing test about big expressions to pass.
--
files: compiler_recursion_limit_check.patch
keywords: patch
messages: 164839
nosy: ag6502
priority: normal
severity: normal
status: open
title: Patch for issue 5765: stack overflow evaluating eval("()" * 3)
Added file:
http://bugs.python.org/file26292/compiler_recursion_limit_check.patch
___
Python tracker
<http://bugs.python.org/issue15274>
___diff -r d9c98730e2e8 Include/symtable.h
--- a/Include/symtable.hSat Jul 07 13:34:50 2012 +1000
+++ b/Include/symtable.hSat Jul 07 14:39:38 2012 +0200
@@ -30,6 +30,8 @@
PyObject *st_private; /* name of current class or NULL */
PyFutureFeatures *st_future;/* module's future features that affect
the symbol table */
+int recursion_depth;/* current recursion depth */
+int recursion_limit;/* recursion limit */
};
typedef struct _symtable_entry {
diff -r d9c98730e2e8 Lib/test/test_compile.py
--- a/Lib/test/test_compile.py Sat Jul 07 13:34:50 2012 +1000
+++ b/Lib/test/test_compile.py Sat Jul 07 14:39:38 2012 +0200
@@ -474,6 +474,14 @@
self.assertInvalidSingle('f()\nxy # blah\nblah()')
self.assertInvalidSingle('x = 5 # comment\nx = 6\n')
+def test_compiler_recursion_limit(self):
+self.assertRaises(RuntimeError, self.compile_single, "()" * 10)
+self.assertRaises(RuntimeError, self.compile_single, "a" + ".b" *
10)
+self.assertRaises(RuntimeError, self.compile_single, "a" + "[0]" *
10)
+self.compile_single("()" * 2000)
+self.compile_single("a" + ".b" * 2000)
+self.compile_single("a" + "[0]" * 2000)
+
def test_main():
support.run_unittest(TestSpecifics)
diff -r d9c98730e2e8 Python/symtable.c
--- a/Python/symtable.c Sat Jul 07 13:34:50 2012 +1000
+++ b/Python/symtable.c Sat Jul 07 14:39:38 2012 +0200
@@ -218,17 +218,37 @@
return NULL;
}
+/* When compiling the use of C stack is probably going to be a lot
+ lighter than when executing Python code but still can overflow
+ and causing a Python crash if not checked (e.g. eval("()"*30)).
+ Using the current recursion limit for the compiler too seems
+ overconstraining so a factor is used to allow deeper recursion
+ when compiling an expression.
+*/
+#define COMPILER_STACK_FRAME_SCALE 4
+
struct symtable *
PySymtable_Build(mod_ty mod, const char *filename, PyFutureFeatures *future)
{
struct symtable *st = symtable_new();
asdl_seq *seq;
int i;
+PyThreadState *tstate;
if (st == NULL)
return st;
st->st_filename = filename;
st->st_future = future;
+
+/* Setup recursion depth check counters */
+tstate = PyThreadState_GET();
+if (!tstate) {
+PySymtable_Free(st);
+return NULL;
+}
+st->recursion_depth = tstate->recursion_depth * COMPILER_STACK_FRAME_SCALE;
+st->recursion_limit = Py_GetRecursionLimit() * COMPILER_STACK_FRAME_SCALE;
+
/* Make the initial symbol information gathering pass */
if (!GET_IDENTIFIER(top) ||
!symtable_enter_block(st, top, ModuleBlock, (void *)mod, 0, 0)) {
@@ -1268,6 +1288,12 @@
static int
symtable_visit_expr(struct symtable *st, expr_ty e)
{
+if (++st->recursion_depth > st->recursion_limit) {
+PyErr_SetString(PyExc_RuntimeError,
+"maximum recursion depth exceeded while compiling an
expression");
+--st->recursion_depth;
+return 0;
+}
switch (e->kind) {
case BoolOp_kind:
VISIT_SEQ(st, expr, e->v.BoolOp.values);
@@ -1280,8 +1306,10 @@
VISIT(st, expr, e->v.UnaryOp.o
[issue5765] stack overflow evaluating eval("()" * 30000)
Andrea Griffini added the comment: This is a fix for this issue. The solution was to add two fields (recursion_depth and recursion_limit) to the symbol table object and just increment and check the depth in symtable_visit_expr raising a RuntimeError in case the limit is exceeded. The test case added also covers other similar cases (a.b.b.b.b.b... and a[0][0][0][0]) There is no depth check in when visiting statement because I cannot think to a way to nesting statements too much without getting other errors before. If there is a way to do it, it would be trivial to also cover that part. The patch uses the current depth and current recursion limit but multiplies them for a factor because I suppose that the amount of C stack used by the compiler per recursion is smaller than the amount used by the interpreter; the constant in the patch is 4. Using a constant of 1 (i.e. just using the normal recursion limit) doesn't allow a previously existing test about big expressions to pass. -- keywords: +patch nosy: +ag6502 Added file: http://bugs.python.org/file26293/compiler_recursion_limit_check.patch ___ Python tracker <http://bugs.python.org/issue5765> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15274] Patch for issue 5765: stack overflow evaluating eval("()" * 30000)
Andrea Griffini added the comment: I sent an email because I was not able to log in. The patch has been submitted to the correct issue (6765). -- resolution: -> duplicate status: open -> closed ___ Python tracker <http://bugs.python.org/issue15274> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1616125] Cached globals+builtins lookup optimization
Andrea Griffini added the comment: Closing as it was a partial implementation of a bad idea with questionable gains. -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue1616125> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15438] Incredible issue in math.pow
New submission from andrea bergamini : math.pow(43, 10) gives the wrong result: 21611482313284248.0 Instead, the build-in function 43**10 and pow(43, 10) give the correct result: 21611482313284249L. This bug has been seen on ActivePython 2.5.1.1. Sorry no tests on recent versions. -- components: Library (Lib) messages: 166275 nosy: andrea.bergamini priority: normal severity: normal status: open title: Incredible issue in math.pow type: behavior ___ Python tracker <http://bugs.python.org/issue15438> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15438] Incredible issue in math.pow
andrea bergamini added the comment: Ok, but math.pow IMPO has to be aligned to pow and built-in pow (**), otherwise this kind of "inaccuracies" can compromise the application behavior. I was using this funcion in a cryptographic mechanisms, and this issue resulted in a failure. Generally speaking, integer numbers should not be affected by inaccuracies. I mean, there's no floating point. -- ___ Python tracker <http://bugs.python.org/issue15438> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15438] Incredible issue in math.pow
andrea bergamini added the comment: Well, from a library I'm used to expect a good result or an exception. Not a value that differs from the correct of one unit! I agree with Antoine, the doc should warn about this behavior. I've lost a lot of time before discovering my application issue came from the py math library... -- ___ Python tracker <http://bugs.python.org/issue15438> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15438] Incredible issue in math.pow
andrea bergamini added the comment: Ok guys, ticket closed, but I'm still confused: I'm not a Python expert, I've understood that math is a sort of wrapper of C math.h or something like this, but: - I can't find any reason in using math.pow if I can get errors like the one explained. - I've used math.h in my C++ code without having experienced any problem in that pow operation. I'm surely missing something but I'm a bit confused... -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue15438> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5765] stack overflow evaluating eval("()" * 30000)
Andrea Griffini added the comment:
I missed all the macrology present :-( ... the following is a patch that takes
it into account (also defines a VISIT_QUIT macro to make more visible the exit
points). The handling has been also extended to visit_stmt because the macros
are shared.
Of course all this makes sense assuming that a cleanup in case of error is
indeed desired...
BTW: shouldn't be all those statement macros of the "do{...}while(0)" form
instead of just being wrapped in "{}" ? I see potential problems with if/else...
--
Added file:
http://bugs.python.org/file26913/compiler_recursion_limit_check_2.patch
___
Python tracker
<http://bugs.python.org/issue5765>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5765] stack overflow evaluating eval("()" * 30000)
Andrea Griffini added the comment: On Mon, Aug 20, 2012 at 12:27 AM, Antoine Pitrou wrote: > Indeed I don't like the introduction of COMPILER_STACK_FRAME_SCALE. > Re-using the existing infrastructure would be much easier to maintain. > The default recursion limit is 1000, which should cover any non-pathological > code, IMHO. I submitted a new version with the scale lowered to 3. Using a lower value (e.g. 1) however makes "test_extended_args" fail (the test tries to compile an expression with 2500+ terms). If it's ok to make that test to throw instead then the whole scaling could be removed. -- ___ Python tracker <http://bugs.python.org/issue5765> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20567] test_idle causes test_ttk_guionly 'can't invoke "event" command: application has been destroyed' messages from Tk
Andrea Torre added the comment: Ubuntu 12.04 64-bit Python 2.7.3 (virtualenv) Hi, just adding a few info, hope not completely useless, that seem related to the issue. I got the same message when running nosetests against my source. It's an application using Tkinter as frontend. All tests pass, though. Besides, I always destroy root in tearDown(). I noticed that the the issue only comes up when i run tests without specifying any path, like in nosetests -vs. If i enter nosetests -vs tests/unit/ tests/integration/ everything runs smooth. -- nosy: +andtorg versions: -Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue20567> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9417] Declaring a class creates circular references
New submission from Andrea Corbellini : Creating a class (either using the 'class' statement or using type()) creates a circular reference. I've attached a script that simply demonstrates this. The problem is caused by the fact that MyClass.__dict__['__dict__'].__objclass__ is MyClass. Although most of the times classes are never deleted when the interpreted exits, some programs (like the popular Django framework) create temporary classes. And this is a pain because you can't disable the garbage collector. -- components: Interpreter Core files: test.py messages: 111935 nosy: candrea priority: normal severity: normal status: open title: Declaring a class creates circular references type: resource usage versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file18251/test.py ___ Python tracker <http://bugs.python.org/issue9417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9417] Declaring a class creates circular references
Andrea Corbellini added the comment: Disabling the GC can increase performances (although not significantly). But this bug is the cause of other problems too: what if the metaclass contains a __del__() method? An another issue that I've found is that debugging is harder. I always try to avoid to create ref cycles in my code, also if my objects are collectable. In this way, I'm sure that I'll always be able to add a __del__ method in the future without problems. However, I can't easily check ref cycles without manually inspecting `gc.garbage`. And also, specifying DEBUG_SAVEALL will put all the deleted classes and their attributes in the garbage, which makes debugging *very* hard in case of a leaking program. -- ___ Python tracker <http://bugs.python.org/issue9417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9417] Declaring a class creates circular references
Andrea Corbellini added the comment: Having a __del__ inside a metaclass is strange, I know... but probably there are situations where you need to do so. Why shouldn't a developer be able to add a __del__ to a metaclass without creating uncollectable objects? I don't think this behavior is by design. Also, doing random contributions to various projects I've seen many odd things. However I don't think that the bug tracker is the right place to discuss development practices. A bug that causes problems in unusual situations is still a bug. :-) -- ___ Python tracker <http://bugs.python.org/issue9417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9417] Declaring a class creates circular references
Andrea Corbellini added the comment: This is an unwanted an unexpected behavior, so this is a bug by definition. If it's not easy to fix, it's a different matter. However here's a proposed solution: * for the __mro__: instead of using a tuple, use a new object that inherits from it. This new object should use weak reference for the first item and should return the real object (if available) only in __getitem__(). * __objclass__ can should become a property based on weak references. -- ___ Python tracker <http://bugs.python.org/issue9417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue812369] module shutdown procedure based on GC
Changes by Andrea Corbellini : -- nosy: +candrea ___ Python tracker <http://bugs.python.org/issue812369> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9417] Declaring a class creates circular references
Andrea Colangelo added the comment: I can confirm this bug should be addressed some way. On my high-traffic server, keeping GC enabled causes performance issues due to this bug, and disabling it causes an out-of-memory within hours. -- nosy: +warp10 ___ Python tracker <http://bugs.python.org/issue9417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28695] Add SSL_CTX_set_client_cert_engine
Andrea Grandi added the comment: What about using OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CONFIG, NULL) instead of OPENSSL_config()? -- nosy: +Andrea Grandi ___ Python tracker <http://bugs.python.org/issue28695> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27010] email library could "recover" from bad mime boundary like (some?) email clients do
Andrea De Pasquale added the comment: Hello, did you have a chance to look at my patch? -- ___ Python tracker <http://bugs.python.org/issue27010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27010] email library could "recover" from bad mime boundary like (some?) email clients do
Andrea De Pasquale added the comment: Ok thanks, please kindly let me know. -- ___ Python tracker <http://bugs.python.org/issue27010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27010] email library could "recover" from bad mime boundary like (some?) email clients do
Changes by Andrea De Pasquale : -- nosy: +adepasquale ___ Python tracker <http://bugs.python.org/issue27010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27010] email library could "recover" from bad mime boundary like (some?) email clients do
Andrea De Pasquale added the comment: Isn't this covered by the following test case? Lib/test/test_email/test_defect_handling.py:18 -- ___ Python tracker <http://bugs.python.org/issue27010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27010] email library could "recover" from bad mime boundary like (some?) email clients do
Andrea De Pasquale added the comment: How about the following patch? If it's different from what you had in mind, please let me know. -- keywords: +patch Added file: http://bugs.python.org/file43016/issue27010-notuniqueboundary.patch ___ Python tracker <http://bugs.python.org/issue27010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27010] email library could "recover" from bad mime boundary like (some?) email clients do
Andrea De Pasquale added the comment: Yes you are right, my patch produces an RFC2046-compliant output and also registers the "not-unique-boundary" defect. -- ___ Python tracker <http://bugs.python.org/issue27010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27010] email library could "recover" from bad mime boundary like (some?) email clients do
Andrea De Pasquale added the comment: To provide additional context, Microsoft has patched his Outlook client to be RFC2046-compliant. More details below: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3366 https://technet.microsoft.com/library/security/MS16-107 http://www.certego.net/en/news/badepilogue-the-perfect-evasion/ -- ___ Python tracker <http://bugs.python.org/issue27010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
