[issue11820] idle3 shell os.system swallows shell command output
New submission from kent :
attempting to run an os.system command under the idle 3 shell swallows the out
put.
Idle 3 is running on a 32 bit kde mandriva linux.
>>> import os
>>> os.system('ls')
0
>>> os.system('pwd')
0
as you can see it returns a 0 indicating successful completion, but no output.
However os.getcwd works perfectly.
>>> os.getcwd()
'/home/kent/Documents'
running the same code from python in an xwindow terminal works fine.
apparently the idle shell does not echo the the standard output or error output
as the python interpreter does.
--
components: IDLE
messages: 133452
nosy: Thekent
priority: normal
severity: normal
status: open
title: idle3 shell os.system swallows shell command output
type: behavior
versions: Python 3.1
___
Python tracker
<http://bugs.python.org/issue11820>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11820] idle3 shell os.system swallows shell command output
kent added the comment:
running it as a file from idle gives the same result.
import os
print (os.system('pwd'))
0
--
___
Python tracker
<http://bugs.python.org/issue11820>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11820] idle3 shell os.system swallows shell command output
kent added the comment: When starting idle from a terminal the output from the command is sent to the terminal. When starting idle from the desktop, the output disappears except for the exit status. Same behavior with 2.65 -- ___ Python tracker <http://bugs.python.org/issue11820> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11820] idle3 shell os.system swallows shell command output
kent added the comment:
I tried using subprocess.Popen and subprocess.call, both of which did the same
behavior. Under the interpreter I get the desired string output:
>>> subprocess.call('ls')
bin Documents eclipse local Pictures tmp workspace
Desktop Downloads hamlib Music Templates Videos
0
Under Idle:
>>> subprocess.call('ls')
0
Thus the subprocess.call method provides the string output. Why should I have
to use the subprocess.check_output('command').decode() when subprocess.call()
gives me what I want?
Thus it does not seem to be an os.system issue, but a failure of Idle to
capture the sysoutput string as the interpreter does The xterminal example
highlights this. The sysoutput is echoed at the xterminal not in idle.
You are correct there are other ways to get the specific information for ls. I
was using that as test command. I was experimenting with the commands in order
to a write a program which will run an executable under either windows or
linux. I wanted to see the output in the interpreter in order to test it. I
was using Idle for the testing. It does NOT work the same as the interpreter.
If Idle is to be useful as an IDE, shouldn't it's shell work the same as the
interpreter? If it doesn't why use Idle ?
--
___
Python tracker
<http://bugs.python.org/issue11820>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11820] idle3 shell os.system swallows shell command output
kent added the comment:
I had kind of figured it might be something like this. I ran the following
code in the xterm interpreter:
>>> x=subprocess.call('ls')
bin Documents eclipse local Pictures tmp workspace
Desktop Downloads hamlib Music Templates Videos
>>> print(x)
0
It does not capture the output.
--
components: +Interpreter Core
___
Python tracker
<http://bugs.python.org/issue11820>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11820] idle3 shell os.system swallows shell command output
kent added the comment:
The getoutput and getstatusoutput provide the expect output which can be
captured
>>> x=subprocess.getoutput('ls')
>>> print(x)
hs_err_pid28274.log
LP4E-examples
mydir.pth
mydir.pth~
PP4E-Examples-1.2
ProgMan
Python_dir
Would it be a good thing to have the interpreter capture the sysout of all
child processes automatically?
--
___
Python tracker
<http://bugs.python.org/issue11820>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16754] Incorrect shared library extension on linux
Changes by kent : -- nosy: +Thekent ___ Python tracker <http://bugs.python.org/issue16754> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1462] About this document refers to SourceForge tracker
New submission from Kent Johnson: "About this document" http://docs.python.org/lib/about.html still refers to "the Python Bug Tracker at SourceForge". The bug tracker link is incorrect (should be the new tracker) and the SF reference is obsolete. -- components: Documentation messages: 57635 nosy: kjohnson severity: normal status: open title: About this document refers to SourceForge tracker __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1462> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1463] Minor error in mimetypes docs
New submission from Kent Johnson: In the mimetypes module docs http://docs.python.org/lib/module-mimetypes.html the section on add_type() should read "When strict is *true (the default)* the mapping". -- components: Documentation messages: 57636 nosy: kjohnson severity: minor status: open title: Minor error in mimetypes docs __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1463> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10303] small inconsistency in tutorial
Kent Johnson added the comment: Attached patch deletes the referenced sentence. -- keywords: +patch nosy: +kjohnson Added file: http://bugs.python.org/file19536/issue10303.diff ___ Python tracker <http://bugs.python.org/issue10303> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11508] Virtual Interfaces cause uuid._find_mac to raise a ValueError under Linux
New submission from Kent Frazier : If a virtual interface is present in the system, such as if the user is connected to a VPN, then there may be entries in ifconfig that do not conform to the expected `HWAddr 01:23:45:67:89:ab` MAC address format expected by uuid._find_mac. For instance, under Ubuntu 10.10 on my Acer Eee 1005HA, using Cisco's AnyConnect VPN client, I have the following entry in ifconfig: cscotun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 Not only is this more than 6 bytes long, it also uses dashes as a delimiter rather than the colons used by MAC address. After reading the relevant parts of RFC4122's definition of the algorithm for UUID1, I think we probably should be ignoring these virtual interfaces, since I doubt they are guaranteed to be unique. The attached patch assumes that it is correct to ignore these entries. If this is not appropriate, it might be better to strip all colons and dashes before the int conversion. I tried to write a test to demonstrate this issue, but had difficulty figuring out how to make it work. The import of `os` is at the function level rather than at the top of the uuid module, so mocking out the module didn't seem feasible. I also tried replacing the call to ifconfig with a call to echo with the appropriate strings to emulate this result, but echo is typically not within any of the hard-coded list of directories that _find_mac looks in. If anyone has a good idea of how to write a test for this issue, I would be happy to write one with some guidance, but I was stumped. This is my first patch submission to CPython, so if I did anything incorrectly, please let me know and I will try to correct my error. -- components: Library (Lib) files: uuid_ValueError_fix.diff keywords: patch messages: 130892 nosy: kfrazier priority: normal severity: normal status: open title: Virtual Interfaces cause uuid._find_mac to raise a ValueError under Linux type: crash versions: Python 3.3 Added file: http://bugs.python.org/file21136/uuid_ValueError_fix.diff ___ Python tracker <http://bugs.python.org/issue11508> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11508] Virtual Interfaces cause uuid._find_mac to raise a ValueError under Linux
Changes by Kent Frazier : Removed file: http://bugs.python.org/file21136/uuid_ValueError_fix.diff ___ Python tracker <http://bugs.python.org/issue11508> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11508] Virtual Interfaces cause uuid._find_mac to raise a ValueError under Linux
Kent Frazier added the comment: I was mistaken about the issues with mocking. I am submitting a new patch with a test included. -- Added file: http://bugs.python.org/file21143/uuid_ValueError_fix.diff ___ Python tracker <http://bugs.python.org/issue11508> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3619] A more informative message for ImportError
New submission from Kent Tenney <[EMAIL PROTECTED]>: from foo import bar ImportError: cannot import name bar The error may be due to the wrong 'foo' being found, some investigation is required. If the the ImportError message included the filename for 'foo', the problem would be obvious. ImportError cannot import name bar from /usr/lib//foo.pyc A c.l.p. thread on this is at http://groups.google.com/group/comp.lang.python/browse_thread/thread/88474a32877026fc/ a patch from Wojtek Walczak is here and attached http://www.stud.umk.pl/~wojtekwa/patches/from-import-py2.5.1.patch a thread about it on python-dev is here http://mail.python.org/pipermail/python-dev/2008-August/081889.html including a comment on the patch http://mail.python.org/pipermail/python-dev/2008-August/081897.html -- components: None files: from-import-py2.5.1.patch keywords: patch messages: 71542 nosy: ktenney severity: normal status: open title: A more informative message for ImportError type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file11173/from-import-py2.5.1.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3619> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3670] Reporting bugs - no such sections
New submission from Kent Johnson <[EMAIL PROTECTED]>: The "Reporting Bugs" section of the Python 2.6b3 docs http://docs.python.org/dev/bugs.html says, please use either the “Add a comment” or the “Suggest a change” features of the relevant page in the most recent online documentation at http://docs.python.org/. I don't see either of these features in the 2.6 docs or the 2.5 docs at the link. -- assignee: georg.brandl components: Documentation messages: 71885 nosy: georg.brandl, kjohnson severity: normal status: open title: Reporting bugs - no such sections versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3670> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3671] What's New in 2.6 - corrections
New submission from Kent Johnson <[EMAIL PROTECTED]>: These are minor corrections to the What's New in Python 2.6[b3] doc. Note: the PEP references are to the headers in What's New, not the actual PEPs - PEP 371: The multiprocessing Package - "apply() or apply_async, adding a single request, and map() or map_async()" All four function names should link to the Pool docs. Currently apply and map link to the docs for the builtins of the same name; the other two don't link. - PEP 3101: Advanced String Formatting - In the first example, "uid = 'root'" is not needed - PEP 3112: Byte Literals - In the second example, the value of b should not have a space in the middle, i.e. bytearray(b'\xe2\x87\xaf\xe3\x89\x84') instead of bytearray(b'\xe2\x87\xaf \xe3\x89\x84') - Other Language Changes - next(*iterator*, [*default*]) - the asterisks are not needed - "letting complex(repr(cmplx)) will now round-trip values" -> so complex(repr(cmplx)) will now round-trip values - Interpreter Changes - "**encoding** or **encoding**:**errorhandler**" - Are the ** truly part of the syntax? - New, Improved, and Deprecated Modules - heapq.merge() returns a generator; the example should be list(heapq.merge([1, 3, 5, 9], [2, 8, 16])) - All the new itertools functions return iterators, not lists; their examples should also be wrapped in list() - itertools.product([1,2], repeat=3)) <- extra ) - shutil - "ignore_patterns() takes an arbitrary number of glob-style patterns and will ignore any files and directories that match this pattern." -> ignore_patterns() takes an arbitrary number of glob-style patterns and returns a callable which will ignore any files and directories that match this pattern. - The future_builtins module - I think all the ** are extraneous. -- assignee: georg.brandl components: Documentation messages: 71888 nosy: georg.brandl, kjohnson severity: normal status: open title: What's New in 2.6 - corrections versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3671> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3670] Reporting bugs - no such sections
Kent Johnson <[EMAIL PROTECTED]> added the comment: You should add something like the old "About this document" footer. AFAICT there is no information in the new docs about how to report a problem with the docs. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3670> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3671] What's New in 2.6 - corrections
Kent Johnson <[EMAIL PROTECTED]> added the comment: For the itertools examples, perhaps you could remove the [ ] from the result text so it doesn't look like a list. For example: itertools.izip_longest([1,2,3], [1,2,3,4,5]) -> (1, 1), (2, 2), (3, 3), (None, 4), (None, 5) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3671> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3866] int() doesn't 'guess'
New submission from Kent Johnson <[EMAIL PROTECTED]>: The library reference for int() says, "If radix is zero, the proper radix is guessed based on the contents of string; the interpretation is the same as for integer literals." The use of the word 'guess' implies that there is some heuristic used here, that somehow the function will look at an arbitrary number and figure out the correct radix. This can confuse newbies: http://mail.python.org/pipermail/tutor/2008-September/064268.html 'determined' might be a better word. For bonus points link to the Language Reference page on integer literals: http://docs.python.org/ref/integers.html -- assignee: georg.brandl components: Documentation messages: 73214 nosy: georg.brandl, kjohnson severity: normal status: open title: int() doesn't 'guess' versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3866> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4012] Minor errors in multiprocessing docs
New submission from Kent Johnson <[EMAIL PROTECTED]>: In the docs for AsyncResult http://docs.python.org/dev/library/multiprocessing.html#multiprocessing.pool.AsyncResult "get([timeout)" is missing a ] In the example following, it refers to pool.applyAsync() in two places; the docs spell this apply_async(), one of them must be wrong :-) -- assignee: georg.brandl components: Documentation messages: 74150 nosy: georg.brandl, kjohnson severity: normal status: open title: Minor errors in multiprocessing docs versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4012> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4012] Minor errors in multiprocessing docs
Kent Johnson <[EMAIL PROTECTED]> added the comment: On Thu, Oct 2, 2008 at 1:07 PM, Jesse Noller <[EMAIL PROTECTED]> wrote: > > Jesse Noller <[EMAIL PROTECTED]> added the comment: > > Which examples are you talking about Georg? I think you mean me, not Georg...I was referring to the example that immediately follows http://docs.python.org/library/multiprocessing.html#multiprocessing.pool.AsyncResult.successful ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4012> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4017] IDLE 2.6 broken on OSX (Leopard)
Changes by Kent Johnson <[EMAIL PROTECTED]>: -- nosy: +kjohnson ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4017> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7738] IDLE hang when tooltip comes up in Linux
New submission from Kent Yip : IDLE will hang when a tooltip shows in a Linux system (Ubuntu). do this: t = (1,2,3) len(t) it will hang after the closing ')', when you press return nothing will happen or when you press any keys, it won't show up. However, you can work around this hangup by clicking on the IDLE menus on top or clicking on a different application on your desktop and return to IDLE and press Enter will work again tested on python2.5, python2.6, python3.0 on linux machine however in windows vista with python3.1 the tooltip hangup doesn't exist. Only in Linux does it behave like that. -- components: IDLE messages: 98048 nosy: yesk13 severity: normal status: open title: IDLE hang when tooltip comes up in Linux type: behavior versions: Python 2.5, Python 2.6, Python 3.1 ___ Python tracker <http://bugs.python.org/issue7738> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7935] Cross-reference ast.literal_eval() from eval() docs
New submission from Kent Johnson : eval() is a known security hole. Since Python 2.6 ast.literal_eval() provides a better alternative in many cases. literal_eval() is not as well known as eval() and not easy to find even if you know it exists (but don't remember the name). eval() comes up over and over in the Python-tutor list and the attendant warnings are repeated ad nauseum; literal_eval() is rarely mentioned as an alternative. Suggestion: in the docs for eval(), put a warning about security risks and a cross-reference to literal_eval(). For example: Warning: eval() executes any expression and should be used only with trusted input. ast.literal_eval() is a safe alternative for evaluating expressions containing only Python literals. Thanks! -- assignee: georg.brandl components: Documentation messages: 99363 nosy: georg.brandl, kjohnson severity: normal status: open title: Cross-reference ast.literal_eval() from eval() docs type: feature request versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue7935> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8267] Tutorial secion on dictionary keys recommends sort instead of sorted
New submission from Kent Engström : The 2.[567] documentation recommends the use of the sort() method to get a sorted list of dictionary keys. If would be less confusing to new users if we recommended the sorted() functions instead. The corresponding piece of Python 3 documentation already uses the sorted() function. -- assignee: georg.brandl components: Documentation files: dict.patch keywords: patch messages: 101953 nosy: georg.brandl, kent severity: normal status: open title: Tutorial secion on dictionary keys recommends sort instead of sorted versions: Python 2.5, Python 2.6, Python 2.7 Added file: http://bugs.python.org/file16699/dict.patch ___ Python tracker <http://bugs.python.org/issue8267> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8267] Tutorial section on dictionary keys recommends sort instead of sorted
Changes by Kent Engström : -- title: Tutorial secion on dictionary keys recommends sort instead of sorted -> Tutorial section on dictionary keys recommends sort instead of sorted ___ Python tracker <http://bugs.python.org/issue8267> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8267] Tutorial section on dictionary keys recommends sort instead of sorted
Kent Engström added the comment: Is should have mentioned that we're discussion a section of the tutorial concerned with dictionaries. It is not a section on lists, sequences or sorting as such. My colleague, who asked me for help after getting confused by sort, was trying to loop over the keys in the dictionary in sorted order. In that context, sorted is superior to sort. -- ___ Python tracker <http://bugs.python.org/issue8267> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8329] select.select() can return lists with identical id()'s
New submission from Mike Kent : If select.select() returns two or more empty lists, these empty lists will all refer to the same list; that is, they will have identical id()'s. If you then have reason to alter one of the returned empty lists, you are altering all of the returned empty lists. This can result in some significant debugging time spent, and curse words uttered. I encountered this in Python 2.5.4, but have not yet verified it on a more recent version. Searching through the Issue Tracker showed nothing similar. -- components: Library (Lib) messages: 102496 nosy: mrmakent severity: normal status: open title: select.select() can return lists with identical id()'s versions: Python 2.5 ___ Python tracker <http://bugs.python.org/issue8329> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8329] select.select() can return lists with identical id()'s
Changes by Mike Kent : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue8329> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1163367] correct/clarify documentation for super
Kent Johnson <[EMAIL PROTECTED]> added the comment: This issue seems to have foundered on finding an explanation for the finer points of super(). Perhaps the glaring errors could at least be corrected, or the fine points could be omitted or glossed over? For example change the first sentence of the docs to "Returns a proxy for the type following 'type' in the method resolution order of 'object-or-type'." Perhaps link to these? http://chandlerproject.org/bin/view/Projects/UsingSuper http://fuhm.net/super-harmful/ -- nosy: +kjohnson _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1163367> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4156] Docs for BaseHandler.protocol_xxx methods are unclear
New submission from Kent Johnson <[EMAIL PROTECTED]>: In the docs for urllib2.BaseHandler previous to Python 2.6, the names of the protocol_xxx() methods were spelled with 'protocol' in italics to indicate that it is a placeholder; the actual method name is e.g. http_opener(). http://www.python.org/doc/2.5.2/lib/base-handler-objects.html In the Python 2.6 docs this typographic distinction has been lost http://docs.python.org/library/urllib2.html#basehandler-objects so it is not so clear that e.g. protocol_open() is not an actual method. I suggest either restoring the italics or using a spelling such as _open() for the method names. If this is difficult then the body of the descriptions should be rewritten to make it clear that the 'given protocol' is indicated by the name of the method. -- assignee: georg.brandl components: Documentation messages: 75023 nosy: georg.brandl, kjohnson severity: normal status: open title: Docs for BaseHandler.protocol_xxx methods are unclear versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4156> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31242] Add SSLContext.set_verify_callback()
Change by Kent Watsen : -- nosy: +kwatsen ___ Python tracker <https://bugs.python.org/issue31242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31242] Add SSLContext.set_verify_callback()
Kent Watsen added the comment: Very much needing this! My situation is a mutli-tenant asynchio-based server whereby each tenant is able to configure other clients that can connect. The current strategy requires all certs to be known up-front that, for now, necessitates a painful restart whenever new auth for a client-certificate is configured. -- ___ Python tracker <https://bugs.python.org/issue31242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18233] SSLSocket.getpeercertchain()
Kent Watsen added the comment: I don't understand the concern issues being raised for this patch, and also may have a use-case not mentioned yet. For the concern issue, as I understand it, the ability to call getpeercert() or the proposed getpeercertchain() is only after the TLS session has been established. As such, the SSL socket already established that there exists a valid chain of trust. Thus these methods are primarily to provide visibility into what the peer passed *after* it had been authenticated, right? That said, the reason I want to access the entire certificate chain passed by the client (i.e., client cert auth) is in order to validate that the client's cert (which may include some intermediates) authenticates to a specific trust anchor, rather than the bag of trust anchors loaded into the SSLContext (via load_verify_locations()) in order to authenticate a multiplicity of clients, each potentially leading to a different trust anchor. Not having getpeercertchain() means that all no client cert may contain a chain, i.e., the clients only ever transmit the end-entity cert itself. This is unfortunate because the underlying SSL socket actually allows clients to send chains, it's just the lack being able to access the peercertchain in my code that seems to limit the solution. -- nosy: +kwatsen ___ Python tracker <https://bugs.python.org/issue18233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18233] SSLSocket.getpeercertchain()
Kent Watsen added the comment: It seems that we're talking about the same thing, but I want the cert-chain the peer sent without any smarts, exactly how OpenSSL's SSL_get_peer_cert_chain() works and, importantly, without stapling any root chain certs the client did not send itself (though it's okay if the client did, in which case those certs should be included). I'm not following your "I pass the chain [A, leaf cert]" comment, if leaf-cert is signed by B, then this should obviously fail. Maybe you meant to say that A and B are loaded into a bag and that validation test is [bag, leaf-cert]? Regardless, I don't think Python should coddle developers. Assuming the docs are accurate, competent developers with crypto-clue will be fine. Many crypto library docs encourage tourists to stay away. That said, if smarts are wanted, let's choose a name that doesn't overlap with the existing OpenSSL name...get_authed_cert_chain() ? But, please, can a "peer_cert_chain()" wrapping the OpenSSL call be release ASAP, buying time to ponder the merits of smart calls for another day? -- ___ Python tracker <https://bugs.python.org/issue18233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18233] SSLSocket.getpeercertchain()
Kent Watsen added the comment: I agree that having both would be best, but there is a world of difference between a must-have (peer_cert_chain) and what seems to be a nice-to-have (authed_peer_cert_chain). My request for clarification was not that I don't understand bags, etc. (see my first message), but that I don't understand the concrete use case in mind. That is, when is it that the app-logic would differ because the EE cert validated using one path versus another? To explain the 'must-have' better, imagine one peer sending [A, B, C], where 'A' is the EE cert, and the other peer having TA [F, E, D], where 'F' is the self-signed root TA and 'D' is the Issuer that signed 'C'. The complete chain is [A-F] and this is what the SSL-level code will use during the handshake. But post-handshake, without peer_chain_cert(), there is NO WAY for the app-logic to create a valid chain. This is broken, for the reason mentioned in my first message. -- ___ Python tracker <https://bugs.python.org/issue18233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42628] binascii doesn't work on some base64
New submission from Kent Watsen :
[Tested on 3.8.2 and 3.9.0, bug may manifest in other versions too]
The IETF sometimes uses the dummy base64 value "base64encodedvalue==" in
specifications in lieu of a block of otherwise meaningless b64.
Even though it is a dummy value, the value should be convertible to binary and
back again. This works using the built-in command `base64` as well as OpenSSL
command line, but binascii is unable to do it. See below:
$ echo "base64encodedvalue==" | base64 | base64 -d
base64encodedvalue==
$ echo "base64encodedvalue==" | openssl enc -base64 -A | openssl enc -d base64
-A
base64encodedvalue==
$ printf "import
binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('base64encodedvalue=='),
newline=False).decode('ascii'))" | python -
base64encodedvaluQ==
After some investigation, it appears that almost any valid base64 matching the
pattern "??==" fails. For instance:
$ printf "import
binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('ue=='),
newline=False).decode('ascii'))" | python -
uQ==
$ printf "import
binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('aa=='),
newline=False).decode('ascii'))" | python -
aQ==
$ printf "import
binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('a0=='),
newline=False).decode('ascii'))" | python -
aw==
Is this a bug?
--
messages: 382922
nosy: kwatsen2
priority: normal
severity: normal
status: open
title: binascii doesn't work on some base64
type: behavior
versions: Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42628>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42628] binascii doesn't work on some base64
Kent Watsen added the comment: No activity in 3 weeks. Selecting a couple components to give it a bump. -- components: +C API, Library (Lib) nosy: +kwatsen ___ Python tracker <https://bugs.python.org/issue42628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42628] binascii doesn't work on some base64
Change by Kent Watsen : -- nosy: -kwatsen2 ___ Python tracker <https://bugs.python.org/issue42628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42628] binascii doesn't work on some base64
Kent Watsen added the comment: I see. There are two issues: 1) my `base64` and `openssl` CLI commands were flipped, as you point out, giving a false positive - oops ;) 2) more importantly, the base64 value "ue==" is invalid (there is no binary input that could possibly generate it) and none of the implementations issued a warning or error, which is reasonable IMO. Thank you for your help. Please close this issue. -- ___ Python tracker <https://bugs.python.org/issue42628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42252] Embeddable Python indicates that it uses PYTHONPATH
New submission from Tom Kent :
According to the documentation
https://docs.python.org/3/using/windows.html#windows-embeddable
> When extracted, the embedded distribution is (almost) fully isolated
> from the user’s system, including environment variables, system registry
> settings, and installed packages
The embedded distribution should ignore the environment variables.
This is echoed in this prior issue that thought `PYTHONPATH` not being
respected was a bug:
https://bugs.python.org/issue28245
Regardless of the decision to respect environment variables, the message that
is displayed when running the distribution's `python --help` needs to indicate
how it will act.
Currently, for the embedded distribution, which doesn't respect the env
variables, there is a section in the output from running `python -help` that
indicates:
```
Other environment variables:
PYTHONSTARTUP: file executed on interactive startup (no default)
PYTHONPATH : ';'-separated list of directories prefixed to the
default module search path. The result is sys.path.
PYTHONHOME : alternate directory (or ;).
The default module search path uses
\python{major}{minor}.
PYTHONPLATLIBDIR : override sys.platlibdir.
PYTHONCASEOK : ignore case in 'import' statements (Windows).
PYTHONUTF8: if set to 1, enable the UTF-8 mode.
PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr.
PYTHONFAULTHANDLER: dump the Python traceback on fatal errors.
PYTHONHASHSEED: if this variable is set to 'random', a random value is used
to seed the hashes of str and bytes objects. It can also be set to an
integer in the range [0,4294967295] to get hash values with a
predictable seed.
PYTHONMALLOC: set the Python memory allocators and/or install debug hooks
on Python memory allocators. Use PYTHONMALLOC=debug to install debug
hooks.
PYTHONCOERCECLOCALE: if this variable is set to 0, it disables the locale
coercion behavior. Use PYTHONCOERCECLOCALE=warn to request display of
locale coercion and locale compatibility warnings on stderr.
PYTHONBREAKPOINT: if this variable is set to 0, it disables the default
debugger. It can be set to the callable of your debugger of choice.
PYTHONDEVMODE: enable the development mode.
PYTHONPYCACHEPREFIX: root directory for bytecode cache (pyc) files.
```
This may lead users (it did lead this one) to assume that they are doing
something wrong when for example the output of `sys.path` doesn't included
items in `os.environ["PYTHONPATH"]`.
Realizing that it may be difficult to achieve, the help output should match the
state of what the interpreter will actually do if run.
--
components: Windows
messages: 380274
nosy: paul.moore, steve.dower, teeks99, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Embeddable Python indicates that it uses PYTHONPATH
versions: Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42252>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42252] Embeddable Python indicates that it uses PYTHONPATH
Tom Kent added the comment: I'm not sure I agree with that. One possible use-case is to package it along with another program to use the interpreter. In this case they could use the other program's native language features (e.g. .Net's Process.Start(), Win32 API's CreateProcess(), Even Python's subprocess but why?, etc) to run `python.exe myscript.py`. In this case, the user may assume that adding something to the `PYTHONPATH` env variable, as most of the launching methods allow, would take hold. When this fails, the first attempt at debugging would be to try it interactively with the same command, then promptly look at python --help when that fails. Maybe a better question is why should the embeddable distribution's python.exe ignore env variables? Wouldn't it make more sense to depend on the user to add a `-E` if that is what they desire? -- ___ Python tracker <https://bugs.python.org/issue42252> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42252] Embeddable Python indicates that it uses PYTHONPATH
Tom Kent added the comment: A couple things... >> One possible use-case is to package it along with another program to use the >> interpreter. > This is the primary use case. If you're doing something else with it, you're > probably misusing it :) Interesting, I'd been expecting this was commonly used as the way to give access to python3X.dll. We actually do (or are trying to do) both from our installation. I've been mostly focusing on `PYTHONPATH` because that's where I encountered the issue. Which if any of the other env variables are respected? Would there be an argument to add additional command line options that could be used as a more secure alternative to the env variables? A command line argument `-e` that is the opposite of `-E` and enables the usage of PYTHON* env? Maybe this doesn't make sense since you said it is the ._pth that causes this...just thinking aloud. The two options you mention (modify ._pth and append to sys.path) aren't great because we 1) would prefer to use the un-modified python distro 2) don't own the scripts that we are embedding, they are from a 3rd party so modifications are complicated. -- ___ Python tracker <https://bugs.python.org/issue42252> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36011] ssl - tls verify on Windows fails
Tom Kent added the comment: Christian's message indicated that a workaround was possible by adding mozilla's certs to windows cert store. I'm sure there are sysadmins who will really hate this idea, but I've successfully implemented it in a windows docker image, and wanted to document here. Powershell commands, requires OpenSSL to be installed on the system: ``` cd $env:USERPROFILE; Invoke-WebRequest https://curl.haxx.se/ca/cacert.pem -OutFile $env:USERPROFILE\cacert.pem; $plaintext_pw = 'PASSWORD'; $secure_pw = ConvertTo-SecureString $plaintext_pw -AsPlainText -Force; & 'C:\Program Files\OpenSSL-Win64\bin\openssl.exe' pkcs12 -export -nokeys -out certs.pfx -in cacert.pem -passout pass:$plaintext_pw; Import-PfxCertificate -Password $secure_pw -CertStoreLocation Cert:\LocalMachine\Root -FilePath certs.pfx; ``` Once mozilla's store is imported into the microsoft trusted root store, python has everything it needs to access files directly. -- nosy: +teeks99 ___ Python tracker <https://bugs.python.org/issue36011> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 > alledged missing X509_VERIFY_PARAM_set1_host() support
Kent Scheidegger added the comment: I was unable to get it working even with all the suggestions in this thread. I have a shared account on a system with only Python 2.7 and an old version of openssl. I have write access only to my user directory. I installed a new openssl in a local directory and pointed to it with both --with-openssl and LDFLAGS, as suggested. The configure step seems to work, but on make the libssl.so.1.1 still isn't found. I fell back to Python 3.6. Same result. I fell back to 3.4. It finally worked. -- nosy: +kscheidegger ___ Python tracker <https://bugs.python.org/issue34028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21244] distutils fails to build C extensions with XCode 5.1 and OS X 10.9 (Mavericks)
New submission from Kent Frazier: Using the stock Python shipped by Apple with OS X 10.9 Mavericks and XCode 5.1, Mercurial (and other Python extensions) encounter an error like: cc -fno-strict-aliasing -fno-common -dynamic -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -mno-fused-madd -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -pipe -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c mercurial/base85.c -o /private/var/folders/qv/tv81r5_9119bs3jwj3g2rp54gn/T/hgtests._a6HZj/build/temp.macosx-10.9-intel-2.7/mercurial/base85.o clang: error: unknown argument: '-mno-fused-madd' [-Wunused-command-line-argument-hard-error-in-future] clang: note: this will be a hard error (cannot be downgraded to a warning) in the future error: command 'cc' failed with exit status 1 make: *** [tests] Error 1 This can be worked around with: export CFLAGS=-Qunused-arguments On my machine, Python was build with clang-500.0.68 and the XCode 5.1 updates it to clang-503.0.40. I will include a simple setup.py that can be run against Mercurial's head to demonstrate the issue. -- components: Distutils files: toysetup.py messages: 216363 nosy: dstufft, eric.araujo, jason.coombs, kfrazier priority: normal severity: normal status: open title: distutils fails to build C extensions with XCode 5.1 and OS X 10.9 (Mavericks) type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file34889/toysetup.py ___ Python tracker <http://bugs.python.org/issue21244> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17390] display python version on idle title bar
Changes by Kent Johnson : -- nosy: -kjohnson ___ Python tracker <http://bugs.python.org/issue17390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11508] Virtual Interfaces cause uuid._find_mac to raise a ValueError under Linux
Kent Frazier added the comment: Serhiy, I signed the form. Let me know if you need anything else. -- ___ Python tracker <http://bugs.python.org/issue11508> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7310] Unhelpful __repr__() in os.environ
New submission from Kent Johnson : In Python 2.x, os.environ extends UserDict.IterableUserDict and therefore os.environ.__repr__() shows the environment. This makes it easy and intuitive to view the entire environment in the interactive interpreter. In Python 3.1, os.environ extends _abcoll.MutableMapping and uses object.__repr__(). This is a much less useful representation. I suggest adding this __repr__() method to class os._Environ (os.py line 380): def __repr__(self): return repr(self.data) -- components: Library (Lib) messages: 95160 nosy: kjohnson severity: normal status: open title: Unhelpful __repr__() in os.environ type: behavior versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue7310> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17390] display python version on idle title bar
Kent Johnson added the comment: issue17390_editor_title.patch is not correct, it changes the title on any window that inherits from EditorWindow, including the shell window. Here is a new patch that changes short_title() instead of saved_change_hook(), so it can be overridden by derived classes. This is the same method used to change the title of the shell window. Derived classes of EditorWindow are PyShellEditorWindow and OutputWindow. OutputWindow overrides short_title() and IIUC PyShellEditorWindow should use the same title as a normal editor window. -- nosy: +kjohnson Added file: http://bugs.python.org/file29804/issue17390_editor_title_rev2.patch ___ Python tracker <http://bugs.python.org/issue17390> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17719] IDLE help text refers to incorrect Python version
New submission from Kent Johnson: The IDLE help text says, "Running without a subprocess: (DEPRECATED in Python 3.5 see Issue 16123)." According to the referenced issue, this feature is scheduled to be deprecated in *3.4* and *removed* in 3.5. The attached patch corrects the help text. -- assignee: docs@python components: Documentation files: deprecated_in_3.4.patch keywords: patch messages: 186769 nosy: docs@python, kjohnson priority: normal severity: normal status: open title: IDLE help text refers to incorrect Python version type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file29808/deprecated_in_3.4.patch ___ Python tracker <http://bugs.python.org/issue17719> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17719] IDLE help text refers to incorrect Python version
Kent Johnson added the comment: Note: this text does not appear in Doc/library/idle.rst so it does not have to be corrected there. -- ___ Python tracker <http://bugs.python.org/issue17719> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31884] subprocess set priority on windows
Change by Mr JG Kent : -- components: Library (Lib) nosy: JamesGKent priority: normal severity: normal status: open title: subprocess set priority on windows type: enhancement ___ Python tracker <https://bugs.python.org/issue31884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31884] subprocess set priority on windows
Change by Mr JG Kent : -- keywords: +patch pull_requests: +4117 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22168] Turtle Graphics RawTurtle problem
New submission from Kent D. Lee:
This is either a turtle graphics or tkinter problem.
In Python 3.4 it appears that something in Turtle Graphics broke or at least
changed. I get the following error when trying to run a program that works in
Python 3.1 and 3.2.
Kent's Mac> python3.4 c4.py
Traceback (most recent call last):
File "c4.py", line 283, in
main()
File "c4.py", line 277, in main
animApp = Connect4Application(root)
File "c4.py", line 110, in __init__
self.buildWindow()
File "c4.py", line 129, in buildWindow
theTurtle = turtle.RawTurtle(canvas)
File
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/turtle.py",
line 2534, in __init__
self.screen = TurtleScreen(canvas)
File
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/turtle.py",
line 1000, in __init__
cv._rootwindow.call('wm', 'attributes', '.', '-topmost', '1')
AttributeError: 'Canvas' object has no attribute '_rootwindow'
Kent's Mac>
The code is attached. The error occurs on line 129 when trying to create a
RawTurtle and provide it with a Canvas.
--
components: Tkinter
files: c4.py
messages: 225049
nosy: Kent.D..Lee
priority: normal
severity: normal
status: open
title: Turtle Graphics RawTurtle problem
versions: Python 3.4
Added file: http://bugs.python.org/file36307/c4.py
___
Python tracker
<http://bugs.python.org/issue22168>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
