[issue22414] I'd like to add you to my professional network on LinkedIn
New submission from VUIUI: Hi, I#39;d like to add you to my professional network on LinkedIn. - Sói Accept: http://www.linkedin.com/blink?simpleRedirect=38RdP0VczsRe3gQd38ScjsNejkZh4BKrSBQonhFtCVF9z5KjmdKiiQJfnBBiShBsC5EsOpQsSlRpRZBt6BSrCAZqSkConhzbmlQqnpKqiRQsSlRpORIrmkZpSVFqSdxsDgCpnhFtCV9pSlipn9Mfm4CsPgJc3ByumkPc6AJcSlKoT4PbjRBfP9SbSkLrmZzbCVFp6lHrCBIbDtTtOYLeDdMt7hEmsgID=I7888360485_1markAsRead= You received an invitation to connect. LinkedIn will use your email address to make suggestions to our members in features like People You May Know. Unsubscribe here: http://www.linkedin.com/blink?simpleRedirect=pT9Lhj8BrCZEt7BMhj8BsStRoz0Q9nhOrT1BszRIqm5JpipQs64MczxGcTdSpP9IcDoZp6Bx9z4Sc30OfmhF9z4JfmhFripPd2QMem9VpjcMqiQPpmVzsjcJfmhFpipQsSlRpRZBt6BSrCAZqSkCkjoPp4l7q5p6sCR6kk4ZrClHrRhAqmQCsSVRfngCsPgJc3ByumkPc6AJcSlKoT4PbjRBfP9SbSkLrmZzbCVFp6lHrCBIbDtTtOYLeDdMt7hEamp;msgID=I7888360485_1amp;markAsRead= Learn why we included this at the following link: http://www.linkedin.com/blink?simpleRedirect=e3wTd3RAimlIoSBQsC4Ct7dBtmtvpnhFtCVFfmJB9CNOlmlzqnpOpldOpmRLt7dRoPRx9DcQbj0VoDBBcP1FbjdBrCdNcOQZpjYOtyZBbSRLoOVKqmhBqSVFr2VTtTsLbPFMt7hEmsgID=I7888360485_1markAsRead= copy; 2014, LinkedIn Corporation. 2029 Stierlin Ct. Mountain View, CA 94043, USA -- messages: 226897 nosy: VUIUI priority: normal severity: normal status: open title: I'd like to add you to my professional network on LinkedIn ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22414 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22414] I'd like to add you to my professional network on LinkedIn
Changes by Georg Brandl ge...@python.org: -- resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22414 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18159] ConfigParser getters not available on SectionProxy
Changes by Łukasz Langa luk...@langa.pl: -- versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22406] uu-codec trailing garbage workaround is Python 2 code
Changes by Martin Panter vadmium...@gmail.com: Added file: http://bugs.python.org/file36619/uu_codec ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22406 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22406] uu-codec trailing garbage workaround is Python 2 code
Martin Panter added the comment: Here are two patches: a test and a fix. I’m not sure if it is okay to add a test for the “codecs” module with the tests for the “uu” module; it was easier that way because I am basically running the same test over the two different APIs. -- Added file: http://bugs.python.org/file36618/test ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22406 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: a new self-pipe should be created in the child process after fork
STINNER Victor added the comment: Is there a use case for sharing an event loop across forking? I don't know if asyncio must have a builtin support for this use case. The minimum is to document the behaviour, or maybe even suggest a recipe to support it. For example, an event loop of asyncio is not thread-safe and we don't want to support this use case. But I wrote a short documentation with code snippets to show how to workaround this issue: https://docs.python.org/dev/library/asyncio-dev.html#concurrency-and-multithreading We need a similar section to explain how to use asyncio with the os.fork() function and the multiprocesing module. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18159] ConfigParser getters not available on SectionProxy
Łukasz Langa added the comment: The reason I didn't commit that patch before was that I wasn't sure whether making this change wouldn't create any unexpected backwards incompatibility. In fact, if I committed the patch as is, it would. I solved this by leaving getint, getfloat and getboolean on the parser class and keeping _get in use. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22412] Towards an asyncio-enabled command line
Martin Teichmann added the comment: Hi Guido, thanks for the quick response, so my response to your post: to 1: thanks! to 2: I am trying to put most of the stuff into a 3rd party module, unfortunately I need changes in the python compiler, and given that monkey patching is not so simple in C, changing the compiler would mean to re-write it, I know that has been done, but I figured that starting a project like PyPy or jython is a bit too much for me right now. to 3: I started with the repo head of friday night... apparently I was not fast enough to submit this patch before someone changes the python code to the point that my patch doesn't apply anymore. I'll try to fix that soon. to 4: I'll write some docs. to 5: well, there is a callback function just some lines up which will call future.set_result(None). Maybe that was a bit too slick, I'm open for comments on how to do that better. to 6: the C code I put into readline.c is mostly a merge of readline_until_enter_or_signal (in readline.c) and builtin_input (in bltinmodule.c). You're definitely right that those functions could do with some refactoring, but I didn't dare to since they are full of complicated special code for special platforms, and I have no chance to test the code on a machine which has a completely outdated version of the readline library, so I picked the code I needed. to 6: I thought about writing the input part of my patch as a 3rd party library, but then I saw the state of builtin.input and thought that it would actually be a good idea to shine some light onto the state of that function, it is actually a horrible mess. Just look at all the awful dirty tricks that the people over at IPython have to do to use it (im)properly (I'm talking about IPython.lib.inputhook*). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22413] Bizarre StringIO(newline=\r\n) translation
Serhiy Storchaka added the comment: See issue20435. -- nosy: +pitrou, serhiy.storchaka versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22413 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22415] Fix re debugging output
New submission from Serhiy Storchaka: Proposed patch fixes some issues in debugging output of the compiling of regular expression with the re.DEBUG flag. 1. Fixed the handling of the GROUPREF_EXISTS opcode. Example: re.compile(r'(ab)(?(1)cd|ef)', re.DEBUG) Before patch (yes and no branches are not separated): subpattern 1 literal 97 literal 98 subpattern None groupref_exists 1 literal 99 literal 100 literal 101 literal 102 After patch: subpattern 1 literal 97 literal 98 subpattern None groupref_exists 1 literal 99 literal 100 or literal 101 literal 102 2. Got rid of trailing spaces in Python 3. 3. Used named opcode constants instead of inlined strings. 4. Simplified and modernized the code. 5. Updated test to cover more code. -- components: Library (Lib), Regular Expressions files: re_debug.patch keywords: patch messages: 226903 nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Fix re debugging output type: behavior versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36620/re_debug.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22415 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22379] Empty exception message of str.join
Yongzhi Pan added the comment: I have updated the test for 3.5. The related tests pass after the patching. Are they OK now? There are two caveats: I did not update test_bytes in 2.7, and I did not add checkraises in test_bytes in 3.5. -- Added file: http://bugs.python.org/file36621/test_for_35-1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22379 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22416] Pickling compiled re patterns
New submission from Serhiy Storchaka: Compiled re._compile() is used to reconstruct compiled regular expression pattern. re._compile() is private function and can be removed in (long-term) future. I propose to use re.compile() instead. -- components: Library (Lib), Regular Expressions keywords: easy messages: 226905 nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Pickling compiled re patterns type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22408] Tkinter doesn't handle Unicode key events on Windows
Drekin added the comment: It seems that it's a problem of dead key combinations rather than modifiers. Unicode characters produced directly (with or without modifiers) work correctly. Only one deadkey on my keyboard doesn't work at all. AltGr + M is a deadkey, but any following key is interpreted as if no deadkey was pressed. On the other hand, other deadkeys including those with modifiers produces the combined characters, however usually returns just ? as if someone applied char = char.encode(mbcs, errors=replace).decode(). E.g. whole Greek alphabet is transformed to question marks but beta is transformed to sharp s and mu to micro sign. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22408 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18159] ConfigParser getters not available on SectionProxy
Łukasz Langa added the comment: The new implementation also automatically covers get*() methods added on subclasses, no need to use converters= in that case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18159] ConfigParser getters not available on SectionProxy
Roundup Robot added the comment: New changeset 2c46a4ded259 by Łukasz Langa in branch 'default': Closes #18159: ConfigParser getters not available on SectionProxy https://hg.python.org/cpython/rev/2c46a4ded259 New changeset 5eb95d41ee43 by Łukasz Langa in branch 'default': Closes #18159: ConfigParser getters not available on SectionProxy https://hg.python.org/cpython/rev/5eb95d41ee43 -- nosy: +python-dev resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22416] Pickling compiled re patterns
Changes by Serhiy Storchaka storch...@gmail.com: -- keywords: +patch stage: - patch review Added file: http://bugs.python.org/file36622/re_pickle.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22253] ConfigParser does not handle files without sections
Łukasz Langa added the comment: I don't like the idea to magically introduce a '' section since this behaviour would be confusing for interpolation and not particularly discoverable by programmers. Let alone bikeshedding if this should rather be a None section. Using DEFAULTSECT for this purpose is equally wrong since it would silently inject default values to every section, which may or may not be desirable. All in all, it comes down to the question whether the programmer expects section-less configuration. If not, the '' section will not be helpful anyway. If yes, then it's desirable to be able to specify a section name for global options at *read time*. Symmetrically, the user could specify which section name to omit during configuration writing. I like that since it's explicit and more composable than a blanket global section. It would also be 100% backwards compatible. I'll prepare a patch for this idea so we can see how good this API looks like in practice. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22253 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22412] Towards an asyncio-enabled command line
Martin Teichmann added the comment: As promised, a new patch now for the current head. Last time I apparently got confused with how hg works, sorry. -- Added file: http://bugs.python.org/file36623/patch2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22166] test_codecs leaks references
Roundup Robot added the comment: New changeset fcf45ec7863e by Nick Coghlan in branch '3.4': Issue #22166: clear codec caches in test_codecs https://hg.python.org/cpython/rev/fcf45ec7863e New changeset 322ee2f2e922 by Nick Coghlan in branch 'default': Merge fix for issue #22166 from 3.4 https://hg.python.org/cpython/rev/322ee2f2e922 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22166 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22166] test_codecs leaks references
Changes by Nick Coghlan ncogh...@gmail.com: -- resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22166 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22417] PEP 476: verify HTTPS certificates by default
New submission from Nick Coghlan: Attached minimal patch updates http.client.HTTPSConnection to validate certs by default and adjusts test.test_httplib accordingly. It doesn't currently include any docs changes, or changes to urllib. The process wide revert to the old behaviour hook is to monkeypatch the ssl module: ssl._create_default_https_context = ssl._create_unverified_context To monkeypatch the stdlib to validate *everything* (this one isn't new, just noting it for the record): ssl._create_stdlib_context = ssl.create_default_context -- files: pep476_minimal_implementation.diff keywords: patch messages: 226912 nosy: alex, larry, ncoghlan priority: high severity: normal status: open title: PEP 476: verify HTTPS certificates by default type: enhancement Added file: http://bugs.python.org/file36624/pep476_minimal_implementation.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22417 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16095] urllib2 failing with squid proxy and digest authentication
Alexander Weidinger added the comment: So, I analyzed the error and I think I found the problem. (urllib.request - Python 3.5.0) It all starts with l. 1079, as the 407 error gets handled, everything ok here, in l. 1081 http_error_auth_reqed(...) gets executed. So next, we are in l. 939, also everything correct here, retry_http_digest_auth gets executed in l. 953. (woops, http_digest_auth?!, nah, let's see what comes next) So we are in l. 953 and follow the code to come to the get_authorization(...) call. Now we are in l. 981, and in that part of the code lies the problem. To get the username and password for the proxy, the function find_user_password(realm, req.full_url) gets executed. An example, if my proxy has the address abc.com:8080 and my request is for xyz.com, the function tries to find a password for the xyz.com url, instead of the abc.com:8080 url. So it can't find a password and the whole auth process stops with the 407 error. But if you just change the line, to use the host, normal http digest auth doesn't work anymore, I would suggest? So it's also obvious why the workaround of toobaz works. To solve the Problem, two auth handler would be needed, one for the proxy and one for normal http auth. Two different handlers were used in the basic auth, so I think it would be an consistent solution? -- nosy: +alexwe ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22166] test_codecs leaks references
STINNER Victor added the comment:
IMO test_codecs_fix1.patch is still needed.
Review of Nick's change:
+interp = PyThreadState_GET()-interp;
+if (interp-codec_search_path == NULL) {
+return -1;
+}
I don't think that this line raises an exception. You should use an assertion
here (or raises an exception, but it would be overkill).
+encodings._cache.pop(self.codec_name, None)
+try:
+_forget_codec(self.codec_name)
+except KeyError:
+pass
You may move these lines to a private encoding._forget() function.
By the way, codecs._forget() should maybe catch and ignore KeyError?
_TEST_CODECS.pop(self.codec_name, None)
This line may be moved to set_codec() using self.addCleanup(). (Well, it's not
directly related to your change.)
--
resolution: fixed -
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22166
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22166] test_codecs leaks references
Marc-Andre Lemburg added the comment:
On 15.09.2014 15:19, STINNER Victor wrote:
STINNER Victor added the comment:
IMO test_codecs_fix1.patch is still needed.
Review of Nick's change:
+interp = PyThreadState_GET()-interp;
+if (interp-codec_search_path == NULL) {
+return -1;
+}
I don't think that this line raises an exception.
Agreed.
Please also add some documentation to the codecs.h file and
perhaps a test for the function itself ;-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22166
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22418] ipaddress.py new IPv6 Method for Solicited Multicast Address
New submission from Jason Nadeau: I found it was useful to me to calculate and return an IPv6Address instance of the solicited multicast address for a particular IPv6Address. So I have created patch to do so. I am pretty new to programming in general so critiques are totally welcome. -- components: Library (Lib) files: solicitedMulticastAddress.patch keywords: patch messages: 226916 nosy: Jason.Nadeau priority: normal severity: normal status: open title: ipaddress.py new IPv6 Method for Solicited Multicast Address type: enhancement versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36625/solicitedMulticastAddress.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22418 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22139] python windows 2.7.8 64-bit did not install
Henning von Bargen added the comment:
Perhaps this issue should be re-opened.
I stumbled across a similar issue today, and made some potentially useful
observations.
On a machine with an existing c:\python27 directory (Python 2.7.5), I installed
Python 2.7.8 with the install just for me option into a new directory
c:\python278.
That's because there are several Python-based applications running; and I want
to restrict the new Python version to one of them.
The application uses a different executable, LisaReportingAgent.exe.
Within the same environment (PATH first entry is c:\python278), calling
python.exe, listing sys.path gives the expected output:
C:\Lisa\Kronos\reporting\test\binc:\python278\python
Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)] on win
32
Type help, copyright, credits or license for more information.
import sys
for f in sys.path: print f
...
C:\Lisa\Kronos\reporting\test
c:\python278\python27.zip
c:\python278\DLLs
c:\python278\lib
c:\python278\lib\plat-win
c:\python278\lib\lib-tk
c:\python278
c:\python278\lib\site-packages
c:\python278\lib\site-packages\win32
c:\python278\lib\site-packages\win32\lib
c:\python278\lib\site-packages\Pythonwin
^Z
Whereas the special executable's output is much different:
C:\Lisa\Kronos\reporting\test\bin..\..\bin\win32-x86\LisaReportingAgent.exe
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win
32
Type help, copyright, credits or license for more information.
import sys
for f in sys.path: print f
...
C:\Lisa\Kronos\reporting\test
C:\WINDOWS\system32\python27.zip
C:\Python278\Lib
C:\Python278\DLLs
C:\Python278\Lib\lib-tk
C:\Python27\Lib
C:\Python27\DLLs
C:\Python27\Lib\lib-tk
C:\Lisa\Kronos\reporting\test\bin
C:\Lisa\Kronos\reporting\bin\win32-x86
C:\Python27
C:\Python27\lib\site-packages
C:\Python27\lib\site-packages\win32
C:\Python27\lib\site-packages\win32\lib
C:\Python27\lib\site-packages\Pythonwin
Note the entries with c:\windows and with the different Python installation
C:\python27. They are pointing to the old Python installation.
The executable is built from the following C code (except for initializing a
SWIG-generated Python wrapper for a PDF library):
int main( int argc, char* argv[] ) {
int rc = 0;
/* ... setup a license key ... */
Py_SetProgramName(argv[0]);
Py_Initialize();
/* ... init PDF library ... */
rc = Py_Main(argc, argv);
Py_Finalize();
/* ... shut down PDF library ... */
return rc;
}
I've read something that Python 2.7 behaves differently on Windows regarding
installation and setup in comparison to 2.6. It seems that the new python.exe
performs registry magic?
--
nosy: +Henning.von.Bargen
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22139
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22139] python windows 2.7.8 64-bit did not install
Henning von Bargen added the comment: The online help says: When Python is hosted in another .exe (different directory, embedded via COM, etc), the “Python Home” will not be deduced, so the core path from the registry is used. Other “application paths” in the registry are always read. and If the environment variable PYTHONHOME is set, it is assumed as “Python Home”. Otherwise, the path of the main Python executable is used to locate a “landmark file” (Lib\os.py) to deduce the “Python Home”. If a Python home is found, the relevant sub-directories added to sys.path (Lib, plat-win, etc) are based on that folder. Otherwise, the core Python path is constructed from the PythonPath stored in the registry. So I set PYTHONHOME=c:\python278, then call LisaReportingServer.exe again. Now the output for sys.path looks OK to me, but import hmac still fails: C:\Lisa\Kronos\reporting\test\bin..\..\bin\win32-x86\LisaReportingAgent.exe Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win 32 Type help, copyright, credits or license for more information. import sys for f in sys.path: print f ... C:\Lisa\Kronos\reporting\test C:\WINDOWS\system32\python27.zip c:\python278\DLLs c:\python278\lib c:\python278\lib\plat-win c:\python278\lib\lib-tk C:\Lisa\Kronos\reporting\bin\win32-x86 c:\python278 c:\python278\lib\site-packages c:\python278\lib\site-packages\win32 c:\python278\lib\site-packages\win32\lib c:\python278\lib\site-packages\Pythonwin import hmac Traceback (most recent call last): File stdin, line 1, in module File c:\python278\lib\hmac.py, line 8, in module from operator import _compare_digest as compare_digest ImportError: cannot import name _compare_digest -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22139 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22139] python windows 2.7.8 64-bit did not install
Henning von Bargen added the comment: Sorry, of course it's NOT OK, because there's still C:\WINDOWS\system32\python27.zip as the second entry. BTW the relevant environment variables: Path=c:\python278;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\lisa\Kronos\reporting\lib\win32-x86\pdfprint PYTHONHOME=c:\python278 PYTHONPATH=C:\Lisa\Kronos\reporting\test\bin\.. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22139 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22139] python windows 2.7.8 64-bit did not install
Henning von Bargen added the comment: I don't see how this sys.path is related to the online help section 3.3.3. Finding modules. Where does c:\windows\python27.zip come from? And why does Python have to install anything in the Windows directory at all? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22139 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22139] python windows 2.7.8 64-bit did not install
Henning von Bargen added the comment: The only solution I could find was to give up running 2.7.8 next to 2.7.5, then uninstall 2.7.8, then install 2.7.8 with the install for all users option selected. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22139 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22377] %Z in strptime doesn't match EST and others
R. David Murray added the comment: I think its existing behavior is because it doesn't have access to a list of recognized timezones. As you say, this could be fixed by PEP 431. It could also be fixed by adopting the email standard timezones (see email/_parseaddr.py), which is a def-facto standard. Regardless of whether something is done to expand the number of timezone it knows about, though, there's a current doc bug that should be fixed. If someone wants to advocate for expanding the timezone list, that should be a separate issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22377 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22379] Empty exception message of str.join
R. David Murray added the comment: The str of the exception will always be nonblank (it will contain the string 'TypeError' at a minimum). So you need to peel off the 'TypeError:' prefix before testing if you want to use str(e). That's why I suggested using args[0], but I suppose that might be a little more fragile. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22379 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22139] python windows 2.7.8 64-bit did not install
Martin v. Löwis added the comment: Henning: if you have installed Python 2.7.5 for all users, then this behavior is expected. Python finds python27.dll in system32, so even if you install 2.7.8 just for me, it will still pick up 2.7.5 from system32. Installing different 2.7 versions on the same machine isn't really supported, although it should work if they are all installed just for me. The operator module comes from python27.dll. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22139 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22139] python windows 2.7.8 64-bit did not install
Henning von Bargen added the comment: Installing different 2.7 versions on the same machine isn't really supported, although it should work if they are all installed just for me. Sigh... I've come to the same conclusion. Nevertheless it seems to me that the actual behavior is different from the online documentation 3.3.3 Finding modules at https://docs.python.org/2/using/windows.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22139 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22417] PEP 476: verify HTTPS certificates by default
Changes by Alex Gaynor alex.gay...@gmail.com: -- nosy: +dstufft ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22417 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21472] Fix wsgiref handling of absolute HTTP Request-URI
Guido van Rossum added the comment: Wow. This is interesting. I thought that absolute URL support was only for proxies, but the spec you quote says clearly it should be supported as a transition towards always specifying the full URL. I guess they want to get rid of the Host: header? In any case I would worry (a bit) that this might cause security issues if implemented as naively as shown in your patch -- the other components of the URL should probably be validated against the configuration of the server. Also I am wondering whether specifying a different port or protocol (e.g. HTTPS) should be allowed or not, and what to do with extraneous parts of the path (in particular the #fragment identifier). You should probably also be careful with path-less domain names -- IIRC some URL parsers produce as the path for e.g. http://python.org;. Finally, AFAIK the HTTP 1.1 standard is full of ideas that few server implementations support, for various reasons, and it's possible that a future standard actually rescinds (or discourages) some features. Have you asked for the status of this particular feature? -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21472 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue672656] securing pydoc server
Devin Cook added the comment: It looks like this bug was reintroduced in a5a3ae9be1fb. -- nosy: +devin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue672656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22416] Pickling compiled re patterns
Guido van Rossum added the comment: But who says this isn't intended? I don't know why it was done this way, but the following reasoning might apply: we want to have a stable API for unpickling compiled regexps, but we want to be able to evolve the re.compile() API. Just the fact that '_compile' starts with an underscore doesn't mean that it may involve -- in fact, the fact that it is used by pickles says the opposite. Therefore I think the patch makes things worse (tying the pickle format to the public re.compile() method). At best we should add a comment to _compile explaining that its API is constrained by pickle backward compatibility. -- nosy: +gvanrossum resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22416 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22418] ipaddress.py new IPv6 Method for Solicited Multicast Address
Changes by Ned Deily n...@acm.org: -- nosy: +ncoghlan, pmoody ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22418 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue672656] securing pydoc server
Ned Deily added the comment: Devin, please open a new issue describing the current problem you see. Comments to long-closed issues will likely be overlooked. -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue672656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22412] Towards an asyncio-enabled command line
Guido van Rossum added the comment: OK. Trying to understand the patch, there seem to be three parts to it: (a) Changes to CPython to add a new flag to the exec/eval flags argument that sets the GENERATOR flag in the resulting code object. This seems the most fundamental, but it also feels the trickiest. It is a change to a built-in function so it must be supported by other Python implementations (esp. PyPy, Jython, IronPython, Cython). It also feels wrong -- it may be the case that you or your colleagues *want* to be able to write yield from XXX at the prompt, but that doesn't make it a good idea. Especially since it will never be supported by the *regular* REPL -- it will only work in your customized REPL, but it isn't particularly obvious why it works there and not elsewhere. Also, I think supporting yield from in the repl() will teach the wrong thing -- people used to this working will attempt to use yield from at the top level in a script or module and be confused why it doesn't work there. I really think that it's must better to give them a helper function such as was sho wn early in the python-ideas thread. (Once imported, it's less typing too!) (b) Changes to the readline module to support some kind of async behavior, so that you can use the readline module's editing behavior from within an asyncio event loop. I can see the advantage of this, and I am not philosophically opposed (as I am for (a)). Without this, your users would either not have the benefit of convenient input editing, or you would have to reimplement the entire set of features of GNU readline afresh, which does sound excessive. However, once you give up on (a), you don't need (b) either. On the pragmatics of the patch, I don't have time to review it in detail, and I don't know if you can easily find anyone who does -- I just want to note that as it stands, there is a bug in the code, at least on OS X, since I get this: import time, readline time.sleep(1); readline._input() asd asd python.exe(67432,0x7fff7d790310) malloc: *** error for object 0x7fc8506046f0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap: 6 (Immediately after the second input line, I quickly typed 'asd' and pressed Return. The 'asd' got echoed, I got a new prompt, and then something crashed.) (c) A new function input() in the asyncio module. If (a) and (b) were accepted in Python, this might as well be part of your third-party module that implements your interactive shell, so there's not strictly a need for this. It also doesn't work on all platforms (e.g. I don't think it will work on Windows). My recommendation to you is to give up on (a) and instead add the suggested helper function to the globals in your own REPL, and tell your users to use that at the top-level. Python doesn't support yield-from at the top level in scripts and modules, and they may as well get used to that idea. You can still, separately, work on (b), but you will have to find someone in the core dev team who is motivated enough to help you make it work properly or fail safely (on platforms where it can't be made to work). For (c), I don't think that's ready for inclusion in the stdlib either (though perhaps we could add some descendant of it to Python 3.5 if you got (b) accepted). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22419] wsgiref request length
New submission from Devin Cook: BaseHTTPRequestHandler limits request length to prevent DoS. WSGIRequestHandler should probably do the same. See: http://bugs.python.org/issue10714 -- components: Library (Lib) files: wsgiref_request_length.patch keywords: patch messages: 226931 nosy: devin priority: normal severity: normal status: open title: wsgiref request length type: security Added file: http://bugs.python.org/file36626/wsgiref_request_length.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22419 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21998] asyncio: a new self-pipe should be created in the child process after fork
Guido van Rossum added the comment: That sounds about right -- it's a doc issue. Let me propose a paragraph: NOTE: It is not safe to share an asyncio event loop between processes that are related by os.fork(). If an event loop exists in a process, and that process is forked, the only safe operation on the loop in the child process is to call its close() method. (I don't want to have to research what the various polling primitives do on fork(), so I don't want to suggest that it's okay to close the loop in the parent and use it in the child.) A similar note should probably be added to the docs for the selectors module. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21998 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: I have found another problem. PyOS_Readline can be called from two different places – from Parser/tokenizer.c:tok_nextc (by REPL), which uses sys.stdin.encoding to encode prompt argument, and from Python/bltinmodule.c:builtin_input_impl (by input() function), which uses sys.stdout.encoding. So readline hook cannot be implemented correctly if sys.stdin and sys.stdout don't have the same encoding. Either the tokenizer should have two encodings – one for input and one for output - or better no encoding at all and should use Python string based alternative to PyOS_Readline, which could be added. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22418] ipaddress.py new IPv6 Method for Solicited Multicast Address
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22418 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22420] Use print(file=sys.stderr) instead of sys.stderr.write() in IDLE
New submission from Serhiy Storchaka: Proposed patch replaces print(file=sys.stderr) by sys.stderr.write() in IDLE for same reason as in issue22384. May be this will eliminate some crashes when IDLE run with pythonw.exe. -- components: IDLE files: idle_print_stderr.patch keywords: patch messages: 226934 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Use print(file=sys.stderr) instead of sys.stderr.write() in IDLE versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36627/idle_print_stderr.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22420 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22420] Use print(file=sys.stderr) instead of sys.stderr.write() in IDLE
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +kbk, roger.serwy, terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22420 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22421] securing pydoc server
New submission from Devin Cook: Several years ago a patch was applied to set the default binding of the pydoc server to localhost instead of 0.0.0.0. It appears that the issue was reintroduced in a5a3ae9be1fb. See previous issue: http://bugs.python.org/issue672656 $ ./python -m pydoc -b Server ready at http://localhost:35593/ Server commands: [b]rowser, [q]uit server --- $ netstat -lnp | grep python tcp0 0 0.0.0.0:35593 0.0.0.0:* LISTEN 2780/python As a sidenote, I'm not sure why the localhost lookup breaks the test case on my linux machine, but it does. -- components: Library (Lib) files: pydoc_server_addr.patch keywords: patch messages: 226935 nosy: devin priority: normal severity: normal status: open title: securing pydoc server type: security Added file: http://bugs.python.org/file36628/pydoc_server_addr.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22421 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22253] ConfigParser does not handle files without sections
Terry J. Reedy added the comment: I read the rsyncd.conf doc at http://linux.die.net/man/5/rsyncd.conf (linked from the StackOverflow question). These files are not .ini files. However, I believe the parsing rules are mostly compatible with RawConfigParser, or could be made so by using existing customization options, including subclassing. The sectionless options are called 'global options' for one of two different reasons. Some, selected from a predefined list of startup options, act as if they were in a [STARTUP] section. Others, selected from a predefined list of module options, act as if they were in a [DEFAULT] section. The latter provide alternate default value for options in the various [module] sections. We clearly should not directly support the specialized rules of rsyncd.conf. But if, as kernc requests, RawConfigParser gathered sectionless options into a '' section, users could probably work with these files. The details would be up to them, or a config_unix module writer. The same comment applies to other files, including .ini files with sectionless options. Łukasz, the only one bikeshedding '' is you. I do not see any need for a new API and I think it just confuses this issue. Reading and writing sectionless options via a '' section should be sufficient to work with .ini files. To me, the remaining question is whether to retain configparser.MissingSectionHeaderError. The problem with piggy-backing its optional use on the 'strict' parameter is that someone might want to reject duplicates while reading sectionless options. But it ia a plausible idea. As an aside, the documentation for MissingSectionHeaderError is currently a bit confused. The docstring correctly says Raised when a key-value pair is found before any section header. The doc incorrectly says Exception raised when attempting to parse a file which has no section headers. I tested and it is indeed raised even when there is a section header after an initial option line. The exception message is also wrong: File contains no section headers. The latter two should really say that the files does not *start* with a section header (ignoring comment lines), or use the wording of the docstring. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22253 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22420] Use print(file=sys.stderr) instead of sys.stderr.write() in IDLE
Terry J. Reedy added the comment: You meant it the other way around 'replace sys.stderr.write() by print(file=sys.stderr)'. In the two cases where Idle exits anyway, this will not make any difference (except possible in the return code). In the other cases where Idle tries to continue, this will. The real fix needed is to replace stderr, at least when None, so that the messages are displayed in a gui widget. However, if I cannot do that this week, before 3.4.2, I will apply this. Thanks for the patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22420 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue672656] securing pydoc server
Devin Cook added the comment: Sure, thanks. New issue: http://bugs.python.org/issue22421 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue672656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21965] Add support for Memory BIO to _ssl
Geert Jansen added the comment: Antoine, sorry for the delay, we just had a new kid and I changed jobs :) Let me try if I can create an updated patch that where SSLObject is a mixin for SSLSocket. I think the argument about writing tests once is important. Be back in a few days.. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21965 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22139] python windows 2.7.8 64-bit did not install
Martin v. Löwis added the comment: How so? Every single sentence in this section is absolutely correct. It just doesn't talk about finding builtin modules at all, only about modules found on the Python path (.py and .pyd files). Builtin modules don't have to be found, because they are, well, built in. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22139 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
