[issue7817] Pythonw.exe fails to start
New submission from Dan <10equa...@gmail.com>: Pythonw.exe refuses to start on my Windows 7 x64 computer. I don't get any kind of error message (i.e. "pythonw.exe has stopped working"), it simply doesn't open. python.exe works fine. Attached is a Windows Debugger analysis log, I can also provide a Process Monitor log if it would be helpful (shows all the file registry access attempts by the program). -- components: Build files: windbg-python.txt messages: 98587 nosy: ZDan severity: normal status: open title: Pythonw.exe fails to start type: crash versions: Python 3.1 Added file: http://bugs.python.org/file16062/windbg-python.txt ___ Python tracker <http://bugs.python.org/issue7817> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7817] Pythonw.exe fails to start
Dan <10equa...@gmail.com> added the comment: I forgot to mention that this is with a brand new install of Python 3.1.1, and a complete uninstall / reinstall did nothing. -- ___ Python tracker <http://bugs.python.org/issue7817> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7817] Pythonw.exe fails to start
Dan <10equa...@gmail.com> added the comment: Well now I feel really dumb. I was under the impression that pythonw.exe was a GUI version of python.exe, which I though was console-only since up until now I had only tried running it from the command prompt. Problem solved, thanks for your help. -- ___ Python tracker <http://bugs.python.org/issue7817> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6541] SpooledTemporaryFile breakages
Changes by Dan : -- nosy: +danohuiginn ___ Python tracker <http://bugs.python.org/issue6541> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname?
Dan added the comment: Reasonable idea, Daniel, but changing self.retried makes no difference. What does solve Chris' problem (which I can reproduce, btw) is preventing the nonce_count from incrementing. i.e. comment out the line : self.nonce_count += 1 in AbstractDigestAuthHandler.get_authorization This makes me wonder if all this is being caused by LJ, intentionally or not, rejecting repeated requests. -- nosy: +danohuiginn ___ Python tracker <http://bugs.python.org/issue4683> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname?
Dan added the comment: Actually, this does look more like an urllib2 bug. According to RFC 2617, the nonce count should represent the number of requests sent with a particular nonce. But we don't reset the nonce count when we start using a new nonce. That discrepancy in nonce counts causes LJ to reject the connection. Why does it fail the third time, rather than the second? See the LJ code from http://code.sixapart.com/svn/livejournal/trunk/cgi-bin/ljlib.pl (which I *think* applies here, but could easily be wrong): # check the nonce count # be lenient, allowing for error of magnitude 1 ___ Python tracker <http://bugs.python.org/issue4683> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33125] Windows 10 ARM64 platform support
Dan added the comment: Hi, I've just noticed this but a couple of months ago I managed to compile Python 2.7 on win32 ARM64 including the said ssl, tk, ctypes modules. You can download from here and test - https://mega.nz/#F!PclhDIRB!-yhBZ6UM7S596ijNU3dx0A You will need to install the MSVC 2015 runtime first and if you want ssl to work then also download the OpenSSL package from the same link. For ctypes I used the (then most) latest version of libffi. There's an msvc_build directory in the master branch which allows ARM64 builds. With the library working the ctypes module builds just fine (BTW from looking at the libffi code it seems that the code is a straightforward port from the Linux ARM64 code, which is generally fine since Windows on ARM seems to use the standard ARMv8 ABI but who knows what end cases may occur). For SSL, I managed to compile OpenSSL with a lot of headache. Also as noted I had to give-up on ASM optimizations so the ssl module may not be as fast as the native i686, however it will probably still be way faster than x86 emulation mode. For TCL/TK I compiled the TCL/TK libraries from source as well. There's an issue with compiling that on MSVC 2015 because apparently the source uses some names which are now reserved keywords on the newer compiler so some search & replace is needed but once the module is built the Python modules compile just fine. Overall this is a pretty much complete Python 2.7 package as it has all modules usually shipped built-in compiled and seemingly working (as far as I tested). The whole thing took several days but if you want to port it to Python 3.8 it shouldn't be too difficult and I'll gladly share my (very slightly) modified sources with you if you wish. -- nosy: +dan ___ Python tracker <https://bugs.python.org/issue33125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33125] Windows 10 ARM64 platform support
Dan added the comment: Steve, the 2.7 build I've posted includes native tk, do you need the necessary patches? -- ___ Python tracker <https://bugs.python.org/issue33125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33125] Windows 10 ARM64 platform support
Dan added the comment: According to this - https://wiki.tcl-lang.org/page/Building+with+Visual+Studio+2017 the issue will be fixed in the next version (8.6.10). TLDR explanation: Tcl/Tk has variables with names that are now reserved keywords in VS2017, meaning that it can't be build with recent compilers and since VS2017 is the first compiler that has official ARM64 support it means that it currently can't be built for that target. Anyway when version 8.6.10 is eventually released then it should (hopefully) build fine with the current scripts. Maybe we can add it later when that happens? -- ___ Python tracker <https://bugs.python.org/issue33125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41956] Regression in HTMLParser on malformed tags
New submission from Dan : The attached HTML document (pulled from a Samsung printer web interface) contains the following invalid HTML tag: (invalid because of ,="") In Python 3.x completely stops the HTML parser, preventing any further tags from being parsed. This does not happen in Python 2.x See the attached Python script, which counts the number of "input" tags. When executed using Python 2.7, it correctly counts 4 such tags. When executed using Python 3.8 it only finds 1. -- components: Library (Lib) files: testhtmlparse.zip messages: 378101 nosy: dan priority: normal severity: normal status: open title: Regression in HTMLParser on malformed tags type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file49497/testhtmlparse.zip ___ Python tracker <https://bugs.python.org/issue41956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35390] ctypes not possible to pass NULL c_void_p in structure by reference
New submission from Dan :
I have a C struct
typedef struct Effect {
void* ptr;
} Effect;
where when I allocate the memory, the void* gets initialized to NULL, and pass
back a pointer:
Effect* get_effect(){
Effect* pEffect = malloc(sizeof(*pEffect));
pEffect->ptr = NULL;
return pEffect;
}
In Python, I need to call the C function to initialize, and then pass a
REFERENCE to the pointer to another C function:
from ctypes import cdll, Structure, c_int, c_void_p, addressof, pointer,
POINTER, c_double, byref
clibptr = cdll.LoadLibrary("libpointers.so")
class Effect(Structure):
_fields_ = [("ptr", POINTER(c_double))]
clibptr.get_effect.restype = POINTER(Effect)
pEffect = clibptr.get_effect()
effect = pEffect.contents
clibptr.print_ptraddress(byref(effect.ptr))
But this prints an error, because effect.ptr is None, so byref(None) fails.
Below is full working code in the case where ptr is instead a double*, where
there is no problem.
As far as I can tell, there is no way to pass a c_void_p field by reference,
which would be very useful!
#include
#include
#define PRINT_MSG_2SX(ARG0, ARG1) printf("From C - [%s] (%d) - [%s]: ARG0:
[%s], ARG1: 0x%016llX\n", __FILE__, __LINE__, __FUNCTION__, ARG0, (unsigned
long long)ARG1)
typedef struct Effect {
double* ptr;
} Effect;
void print_ptraddress(double** ptraddress){
PRINT_MSG_2SX("Address of Pointer:", ptraddress);
}
Effect* get_effect(){
Effect* pEffect = malloc(sizeof(*pEffect));
pEffect->ptr = NULL;
print_ptraddress(&pEffect->ptr);
return pEffect;
}
Python:
from ctypes import cdll, Structure, c_int, c_void_p, addressof, pointer,
POINTER, c_double, byref
clibptr = cdll.LoadLibrary("libpointers.so")
class Effect(Structure):
_fields_ = [("ptr", POINTER(c_double))]
clibptr.get_effect.restype = POINTER(Effect)
pEffect = clibptr.get_effect()
effect = pEffect.contents
clibptr.print_ptraddress(byref(effect.ptr))
gives matching addresses:
>From C - [pointers.c] (11) - [print_ptraddress]: ARG0: [Address of Pointer:],
>ARG1: 0x7FC2E1AD3770 From C - [pointers.c] (11) - [print_ptraddress]:
>ARG0: [Address of Pointer:], ARG1: 0x7FC2E1AD3770
--
components: ctypes
messages: 330961
nosy: dtamayo
priority: normal
severity: normal
status: open
title: ctypes not possible to pass NULL c_void_p in structure by reference
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue35390>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35390] ctypes not possible to pass NULL c_void_p in structure by reference
Dan added the comment: Thank you both, that's really helpful. Yes, I agree eryksun, I was saying that pointers to c_double and other normal pointer objects work fine, but that if you change to void* and c_void_p in my example it doesn't work. The private field seems like a reasonable solution, and I agree it would be useful for the offset attribute and perhaps that pattern to be documented. Thanks again for the quick responses. -- ___ Python tracker <https://bugs.python.org/issue35390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35390] ctypes not possible to pass NULL c_void_p in structure by reference
Change by Dan : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32223] distutils doesn't correctly read UTF-8 content from config files
New submission from Dan : On Windows, distutils doesn't correctly read UTF-8 content from config files (setup.cfg). Seems like the issue is located on the line reading the files via the ConfigParser; simply adding 'encoding="UTF-8"' as argument fixes the problem for me: https://github.com/python/cpython/pull/4727 On Linux it seems to be working fine. -- components: Distutils, Library (Lib), Windows messages: 307668 nosy: delivrance, dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, zach.ware priority: normal pull_requests: 4633 severity: normal status: open title: distutils doesn't correctly read UTF-8 content from config files type: behavior versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue32223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32223] distutils doesn't correctly read UTF-8 content from config files
Change by Dan : Added file: https://bugs.python.org/file47320/setup.py ___ Python tracker <https://bugs.python.org/issue32223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32223] distutils doesn't correctly read UTF-8 content from config files
Dan added the comment: I've attached the files. Run using 'python setup.py sdist'. The resulting PKG-INFO will contain incorrect data: Summary: délivrance Author: Dan Tès The expected output is: Summary: délivrance Author: Dan Tès -- ___ Python tracker <https://bugs.python.org/issue32223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32223] distutils doesn't correctly read UTF-8 content from config files
Change by Dan : Added file: https://bugs.python.org/file47319/setup.cfg ___ Python tracker <https://bugs.python.org/issue32223> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4683] urllib2.HTTPDigestAuthHandler fails on third hostname?
Dan added the comment: Attaching a patch. I don't have a test to go with it, except for the one submitted with the bug report. -- keywords: +patch Added file: http://bugs.python.org/file14815/nonce_count.diff ___ Python tracker <http://bugs.python.org/issue4683> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1662581] the re module can perform poorly: O(2**n) versus O(n**2)
Dan added the comment: Here's an easy way to trigger the poor performance. Tested with 2.5, 2.6, and 2.7: re.compile( '(\s+.*)*x' ).search( 'a ' * 30 ) -- nosy: +witten ___ Python tracker <http://bugs.python.org/issue1662581> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Dan added the comment: Guys, this looks really bad and inconveniences a lot of users. You install the latest MinGW and Distutils from their default location, try using them on **anything that requires compilation**, and get the cryptic gcc -mno-cygwin error (after having to edit the obscure distutils.cfg, of course). Aren't Python / distutils supposed to be cross-platform? It's already hard enough to find distutils / pip setup instructions for Windows, shouldn't they at least **work**? After removing -mno-cygwin from cygwincompiler.py, I get another obscure -mdll error. This is ridiculous. If you can't agree on a patch that detects both new and old compilers, can't you split cygwincompiler.py into several versions, or somehow provide separate mingw32-old and mingw32-new options? -- nosy: +danmbox ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Dan added the comment: Nice partial work-around. I think it's quite clear that the decision makers for this bug have not been making rational decisions for a year and a half, so we can't really expect change. This being the open-source world, the only recourse is publicizing the issue (or is there some bounty system for python?). So I suggest you blog about it. -- ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Dan added the comment: That's bull, Eric. This is not about a corner case in cygwin. This is about mingw, which is the **main free software that builds executables on Windows**. You know, for when you don't want to require your users to install Visual Studio. Additionally, both you and Matthias imposed artificial conditions that made it unlikely for patches to be created (search for "will insist"). Now, I have to agree that the larger python community (and not an under-resourced team like your good selves) should be involved in distutils (or choose and **support** a different package manager). But I'm not sure where I could file a bug for that (again, blogging may be the best choice). -- ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Dan added the comment: There's an additional aspect. Even though I don't use Windows as a development platform, I care about being able to propose Python to clients as a cross-platform technology (instead of, say, Java). Having an essential piece of Python infrastructure fail miserably on Windows impacts Python's appeal / credentials. To clarify another point, I think that Python should pick and support an "official" package manager (be it distutils, pip or whatever) not eventually, but ASAP. For the time being it looks like distutils is a keystone, therefore it needs to work. -- ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23031] pdb crashes when jumping over "with" statement
New submission from Dan: -> print(1) (Pdb) jump 6 Segmentation fault -- components: Library (Lib) files: pdb_segfault.py messages: 232481 nosy: DSP priority: normal severity: normal status: open title: pdb crashes when jumping over "with" statement type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file37416/pdb_segfault.py ___ Python tracker <http://bugs.python.org/issue23031> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23031] pdb crashes when jumping over "with" statement
Dan added the comment: Sorry, it happens in: 2.7.3 |EPD 7.3-2 (64-bit)| (default, Apr 11 2012, 17:52:16) \n[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] Works as expected in 2.7.8 and 3.3.2 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)] 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] -- ___ Python tracker <http://bugs.python.org/issue23031> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23031] pdb crashes when jumping over "with" statement
Changes by Dan : -- resolution: -> out of date status: open -> closed ___ Python tracker <http://bugs.python.org/issue23031> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23833] email.header.Header folding modifies headers that include semi-colons
New submission from Dan: When adding or replacing a header with email.header.Header, folding of long lines will add a space after any semi-colon encountered in the string. Setting maxlinelen to something longer than the string (no folding required), no spaces are added after semi-colons. -- components: email messages: 239755 nosy: barry, dseg, r.david.murray priority: normal severity: normal status: open title: email.header.Header folding modifies headers that include semi-colons type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue23833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46350] re.sub, re.Match.expand, etc doesn't allow x, u, U, or N escapes in the template
New submission from Dan Snider :
The docs use the phrase "unknown escapes of ASCII letters are reserved for
future use and treated as errors". That seems ambiguous enough to question why
"\x", "\u", "\U", and "\N{}" escapes aren't expanded in the template parameter
like they are in patterns.
Since I didn't get a response to the security report I submitted a few weeks
ago about \N{} escapes, I'm cautiously assuming it's safe to bring it up here
that the "unicode-escape" encoding and re and probably everything else that
uses it ignores two obvious clues that a name lookup will fail: length and the
presence of invalid characters. I didn't look very hard for a definite length
cap in the spec, but 255 seems more than sufficient, based on longest name at
present with its 82 characters. Even something as absurd as 65535 would be
preferable to the current implementations, which will keep going to the end as
in:
>>> r"\N{%s}" % ("\ufb03"*2**30)
searching or a terminating "}" and still perform a lookup of the 2**30
character name.
Another tangentially related "bug" (which probably deserves its own issue) is
the inconsistency between group names and standard Python identifiers. The
following example shows how the python compiler decomposes a ligature 'ffi' in
source code to the ASCII string "ffi", while re merely checks if it could be
converted to an identifier:
>>> ffi = re.search("(?P<ffi>.)", "xxx")
>>> ffi.groupdict()
{'ffi': 'x'}
>>> "\ufb03" in vars(), "\ufb03" in _
(False, True)
--
messages: 410337
nosy: bup
priority: normal
severity: normal
status: open
title: re.sub, re.Match.expand, etc doesn't allow x, u, U, or N escapes in the
template
type: behavior
___
Python tracker
<https://bugs.python.org/issue46350>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46752] Introduce task groups to asyncio and change task cancellation semantics
Dan Halbert added the comment: For your TODO list (not sure how else to communicate this): I agree with the de-emphasis of gather(). I think adding another version of gather() that cancels all the remaining tasks if one fails would also be good, unless you think it is completely redundant due to TaskGroups. This idea was originally mentioned in https://bugs.python.org/issue31452 as a bug, and determined to be "works as designed". So now making an all-cancel() version of gather() is an idiom that people keep recoding, e.g. https://stackoverflow.com/questions/59073556/how-to-cancel-all-remaining-tasks-in-gather-if-one-fails. -- nosy: +dhalbert ___ Python tracker <https://bugs.python.org/issue46752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46791] Allow os.remove to defer to rmdir
New submission from Dan Snider : It appears sometime recently-ish that POSIX updated remove to the following: #include int remove(const char *path); If path does not name a directory, remove(path) shall be equivalent to unlink(path). If path names a directory, remove(path) shall be equivalent to rmdir(path). -- messages: 413499 nosy: bup priority: normal severity: normal status: open title: Allow os.remove to defer to rmdir type: enhancement ___ Python tracker <https://bugs.python.org/issue46791> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46872] Odd handling of signal raised if an illegal syscall is attempted on Android
New submission from Dan Snider :
On Android, the following calls generate a SIGSYS signal that is neither
blocked by pthread_sigmask(SIG_BLOCK, {SIGSYS}) nor ignored after its handler
is set to SIG_IGN:
(os.chroot(path))
os.setgid(rgid)
os.setuid(ruid)
(os.setegid(gid))
os.setregid(rgid, egid)
os.setreuid(ruid, euid)
os.setresgid(rgid, egid, sgid)
time.clock_settime(clock, time)
time.clock_settime_ns(clock, time)
(socket.sethostname(name))
On the other hand, signal(SIGSYS, lambda s, p: None) will catch the signal, but
based on frame it receives (None), I suspect this is a coincidence. Also, the
functions with parenthesized names in that list raise the equivalent of
OSError(0, "Error", "%s"%args[0]).
--
components: C API
messages: 414148
nosy: bup
priority: normal
severity: normal
status: open
title: Odd handling of signal raised if an illegal syscall is attempted on
Android
type: behavior
___
Python tracker
<https://bugs.python.org/issue46872>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1103] Typo in dummy_threading documentation
New submission from Dan Thomasset: I believe that "thread" be "threading" in the line "...imported when the thread module is not provided..."? >From http://docs.python.org/lib/module-dummythreading.html -- components: Documentation messages: 55645 nosy: dthomasset severity: normal status: open title: Typo in dummy_threading documentation __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1103> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1103] Typo in dummy_threading documentation
Dan Thomasset added the comment: Ahh, my mistake then. I misunderstood what was going on. Thanks, Dan On 9/4/07, Martin v. Löwis <[EMAIL PROTECTED]> wrote: > > > Martin v. Löwis added the comment: > > Why do you think so? The documentation is correct as it stands; > dummy_threading should be used when thread is not present, not when > threading is not present (as threading will always be present, it just > won't import when thread is not present). > > -- > nosy: +loewis > resolution: -> invalid > status: open -> closed > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1103> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1103> __Ahh, my mistake then. I misunderstood what was going on.Thanks, DanOn 9/4/07, Martin v. Löwis <mailto:[EMAIL PROTECTED]"> [EMAIL PROTECTED]> wrote:Martin v. Löwis added the comment:Why do you think so? The documentation is correct as it stands; dummy_threading should be used when thread is not present, not whenthreading is not present (as threading will always be present, it justwon't import when thread is not present).--nosy: +loewis resolution: -> invalidstatus: open -> closed__Tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]><http://bugs.python.org/issue1103";> http://bugs.python.org/issue1103>__ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1362] Simple mistake in http://docs.python.org/tut/node6.html
New submission from Dan M: In section 4.6 it says: Writing the value None is normally suppressed by the interpreter if it would be the only value written. When it should say: Writing the value None is normally displayed by the interpreter if it would be the only value written. Or less wordy: The value None is (normally) displayed by the interpreter when it would be the only value written. -- components: Documentation messages: 56948 nosy: dmazz severity: minor status: open title: Simple mistake in http://docs.python.org/tut/node6.html __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1362> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1362] Simple mistake in http://docs.python.org/tut/node6.html
Dan M added the comment: Yes, it is normally suppressed. The problem is the condition when it is suppressed. The documentation states that it's suppressed when it's the only value to be written. It is suppressed when it's *not* the only value to be written. -or- (removing the double negative of suppressed(not displayed) and not) It is displayed when it would be the only value written. The example immediately following this mistake is correct, which makes the actual behavior obvious even if this particular statement is wrong. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1362> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4147] xml.dom.minidom toprettyxml: omit whitespace for text-only elements
Dan Kenigsberg added the comment: Here's another take on fixing this bug, with an accompanying unit test. Personally, I'm monkey-patching xml.dom.minidom in order to avoid it, but please consider fixing it properly upstream. -- Added file: http://bugs.python.org/file23286/minidom-Text-toprettyxml.patch ___ Python tracker <http://bugs.python.org/issue4147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4147] xml.dom.minidom toprettyxml: omit whitespace for text-only elements
Dan Kenigsberg added the comment: Oh dear. Thanks, Enzio, for pointing out that former patch is wrong. It is also quite naive, since the whole NATURE of toprettyprint() is to add whitespace to Text nodes. Tomas Lee's http://bugs.python.org/file11832/minidom-toprettyxml-01.patch made an effort to touch only "simple" Text nodes, that are confined within a single . I did not expect http://bugs.python.org/file23286/minidom-Text-toprettyxml.patch to get in so quickly, after the former one spent several years on queue. However now is time to fix it, possible by my second patch. -- Added file: http://bugs.python.org/file23294/minidom-Text-toprettyxml-02.patch ___ Python tracker <http://bugs.python.org/issue4147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4147] xml.dom.minidom toprettyxml: omit whitespace for text-only elements
Dan Kenigsberg added the comment: btw, http://www.w3.org/TR/xml/#sec-white-space is a bit vague on how should a parser deal with whitespace, and seems to allow non-preservation of text nodes. Preserving "simple" text nodes is allowed, too, and is more polite to applications reading the prettyxml. -- ___ Python tracker <http://bugs.python.org/issue4147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Dan Stromberg added the comment: On Sun, Oct 2, 2011 at 3:49 PM, Nadeem Vawda wrote: > > Nadeem Vawda added the comment: > > Thanks for investigating the Windows situation. > > > - liblzma can't be compiled by Visual Studio: too many C99 isms, mostly > > variables declared in the middle of a block. It's doable for sure, but > it's a > > lot of work. > > I don't think that creating our own MSVC-friendly fork of liblzma is really > an > option. Over and above the work of porting it in the first place (and all > the > opportunities for bugs to creep in along the way), we'd also have to worry > about > keeping up to date with upstream changes. I believe we currently do > something > similar with libffi (for ctypes), and the impression I've gotten is that > it's > caused a lot of trouble. It's much better to contribute patches upstream. > > - The way recommended by XZ is to use a precompiled liblzma.dll; Then it > > should be easy to build an extension module, but its would be the first > time > > that we distribute an extension module which needs a non-system DLL. Is > it > > enough to copy it next to _lzma.pyd? Is there some work to do in the > > installer? > > I would guess that this is sufficient, but my knowledge of how Windows DLLs > work > is minimal. Could someone with more platform knowledge weigh in on whether > this > would work (and if there are any problems it might cause)? I've not done much with windows dll's, but I've heard they're pretty similar to AIX shared libraries which I've done some work with. AIX shared libraries don't deal with versioning well - if you have two version of the same library on a system, you have to pop them into two different loader domains, or suffer unresolved externals at runtime. Then your applications are in of the two loader domains, and if they're in the wrong one, you again suffer unresolved externals at runtime. -- Added file: http://bugs.python.org/file23300/unnamed ___ Python tracker <http://bugs.python.org/issue6715> ___On Sun, Oct 2, 2011 at 3:49 PM, Nadeem Vawda <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Nadeem Vawda <mailto:nadeem.va...@gmail.com";>nadeem.va...@gmail.com> added the comment: Thanks for investigating the Windows situation. > - liblzma can't be compiled by Visual Studio: too many C99 isms, mostly > variables declared in the middle of a block.  It's doable for sure, but it's a > lot of work. I don't think that creating our own MSVC-friendly fork of liblzma is really an option. Over and above the work of porting it in the first place (and all the opportunities for bugs to creep in along the way), we'd also have to worry about keeping up to date with upstream changes. I believe we currently do something similar with libffi (for ctypes), and the impression I've gotten is that it's caused a lot of trouble.It's much better to contribute patches upstream. > - The way recommended by XZ is to use a precompiled liblzma.dll; Then it > should be easy to build an extension module, but its would be the first time > that we distribute an extension module which needs a non-system DLL.  Is it > enough to copy it next to _lzma.pyd?  Is there some work to do in the > installer? I would guess that this is sufficient, but my knowledge of how Windows DLLs work is minimal. Could someone with more platform knowledge weigh in on whether this would work (and if there are any problems it might cause)?I've not done much with windows dll's, but I've heard they're pretty similar to AIX shared libraries which I've done some work with.  AIX shared libraries don't deal with versioning well - if you have two version of the same library on a system, you have to pop them into two different loader domains, or suffer unresolved externals at runtime.  Then your applications are in of the two loader domains, and if they're in the wrong one, you again suffer unresolved externals at runtime.  -- Dan Stromberg ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4147] xml.dom.minidom toprettyxml: omit whitespace for text-only elements
Dan Kenigsberg added the comment: Technically, adjacent Text nodes are not illegal, but preserving this oddity in pretty-print is impossible. It is perfectly fine to pretty-print only the simple case of len()==1. -- ___ Python tracker <http://bugs.python.org/issue4147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1521950] shlex.split() does not tokenize like the shell
Dan Christian added the comment: Of course, that's how it's used. That's all it can do right now. I was was splitting and combining commands (using ;, &&, and ||) and then running the resulting (mega) one liners over ssh. It still gets run by a shell, but I was specifying the control flow. 0 It's kind of like a makefile command block. You want to be able to specify if a failure aborts the sequence, or is ignored (&& vs ;). Sometimes there are fallback commands (via ||). Of course, you can also group using (). Once things are split properly, then understanding the shell control characters is straight forward. I my mind, shlex.split() should either be as close to shell syntax as possible, or have a clear explanation of what is different (and why). I ended up doing my own parsing. I'm not actually at that company anymore, so I can't pull up the code. I'll see if I can come up with a reference case and maybe a unittest this weekend (that's really the only time I'll have to dig into it). -Dan On Thu, Nov 24, 2011 at 9:20 AM, Éric Araujo wrote: > > Éric Araujo added the comment: > > Thanks for the comments. > >> There are really two cases in one bug. >> The first part is that the shell will split tokens at characters that shlex >> doesn't. The handling >> of &, |, ;, >, and < could be done by adjusting the definition of >> shlex.wordchars. The shell may >> also understands things like: &&, ||, |&, and >&. The exact definition of >> these depends on the >> shell, so maybe it's best to just split them out as separate tokens and let >> the user figure out the >> compound meanings. > Yes. I think that the main use of shlex is really to parse a line into > chunks with a way to embed spaces; it’s intended to parse a program command > line (“prog --blah "value stillthesamevalue" "arg samearg"”), but not > necessarily a full shell line (with & and | and whatnot). When people have a > line containing & and |, then they need a shell to execute it, so they would > not call shlex.split but just pass the full line to os.system or > subprocess.Popen. Do you remember what use cases you had when you opened > this report? > >> The proper handling of quotes/escapes requires some kind of new interface. >> You need to distinguish >> between tokens that were modified by the quote/escape rules and those that >> were not. > I don’t see why I would care about quotes in the result of shlex.split. > > See also #7611. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue1521950> > ___ > -- ___ Python tracker <http://bugs.python.org/issue1521950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1521950] shlex.split() does not tokenize like the shell
Dan Christian added the comment: I've attached a diff to test_shlex.py and a script that I used to verify what the shells actually do. Both are relative to Python-3.2.2/Lib/test I'm completely ignoring the quotes issue for now. That should probably be an enhancement. I don't think it really matters until the parsing issues are resolved. ref_shlex is python 2 syntax. python -3 shows that it should convert cleanly. ./ref_shlex.py It will run by default against /bin/*sh If you don't want that, do something like: export SHELLS='/bin/sh,/bin/csh' It runs as a unittest. So you will only see dots if all shells do what it expects. Some shells are flaky (e.g. zsh, tcsh), so you may need to run it multiple times. Getting this into the mainline will be interesting. I would think it would take some community discussion. I may be able to convince people that the current behaviour is wrong, but I can't tell you what will break if it is "fixed". And should the fix be the default? As you mentioned, it depends on what people expect it to do and how it is currently being used. I see the first step as presenting a clear case of how it should work. -Dan On Fri, Nov 25, 2011 at 10:01 AM, Éric Araujo wrote: > > Éric Araujo added the comment: > >> Of course, that's how it's used. That's all it can do right now. > :) What I meant is that it is *meant* to be used in this way. > >> I was was splitting and combining commands (using ;, &&, and ||) and then >> running the resulting >> (mega) one liners over ssh. It still gets run by a shell, but I was >> specifying the control flow. > Thank you for the reply. It is indeed a valuable use case to pass a command > line as one string to ssh, and the split/quote combo should round-trip and be > useful for this usage. > >> I'll see if I can come up with a reference case and maybe a unittest this >> weekend > Great! A new argument (with a default value which gets us the previous > behavior) will probably be needed, to preserve backward compatibility. > > -- > nosy: +niemeyer > versions: +Python 3.3 -Python 3.2 > > ___ > Python tracker > <http://bugs.python.org/issue1521950> > ___ > -- keywords: +patch Added file: http://bugs.python.org/file23778/ref_shlex.py Added file: http://bugs.python.org/file23779/test_shlex.diff ___ Python tracker <http://bugs.python.org/issue1521950> ___#!/usr/bin/env python """Test how various shells parse syntax. This is only expected to work on Unix based systems. We use the unittest infrastructure, but this isn't a normal test. Usage: ref_shelex.py [options] shells... """ # Written by: Dan Christian for issue1521950 import glob import re import os, sys import optparse import subprocess import unittest TempDir = '/tmp' # where we will write temp files Shells = ['/bin/sh', '/bin/bash'] # list of shells to test against class ShellTest(unittest.TestCase): bgRe = re.compile(r'\[\d+\]\s+(\d+|\+ Done)$') # backgrounded command output def Run(self, shell, # shell to use command, # command to run filepath=None): # any files that are expected """Carefully run a shell command. Capture stdout, stderr, and exit status. Returns: (ret, out, err) ret is the return status out is the list of lines to stdout err is the list of lines to stderr """ start_cwd = os.getcwd() call = [shell, '-c', command] #print "Running: %s -c '%s'" % (shell, command) outpath = 'stdout.txt' errpath = 'stderr.txt' ret = -1 out = None err = None fileout = None try: os.chdir(TempDir) outfp = open(outpath, 'w') errfp = open(errpath, 'w') if filepath and os.path.isfile(filepath): os.remove(filepath) ret = subprocess.call(call, stdout=outfp, stderr = errfp) #print "Returned: %d" % ret outfp = open(outpath, 'r') out = outfp.readlines() os.remove(outpath) errfp = open(errpath, 'r') err = errfp.readlines() os.remove(errpath) if filepath: ffp = open(filepath) fileout = ffp.readlines() os.remove(filepath) except OSError as msg: print "Exception!", msg
[issue1521950] shlex.split() does not tokenize like the shell
Dan Christian added the comment: I just realized that I left out a major case. The shell will also split (). I think this is now complete. If you do "man bash" and skip down to DEFINITONS it lists all the control characters. I've attached updated versions of ref_shlex.py and test_shlex.diff. They replace the previous ones. -Dan On Fri, Nov 25, 2011 at 12:25 PM, Dan Christian wrote: > > Dan Christian added the comment: > > I've attached a diff to test_shlex.py and a script that I used to > verify what the shells actually do. > Both are relative to Python-3.2.2/Lib/test > > I'm completely ignoring the quotes issue for now. That should > probably be an enhancement. I don't think it really matters until the > parsing issues are resolved. > > ref_shlex is python 2 syntax. python -3 shows that it should convert cleanly. > ./ref_shlex.py > It will run by default against /bin/*sh > If you don't want that, do something like: export SHELLS='/bin/sh,/bin/csh' > It runs as a unittest. So you will only see dots if all shells do > what it expects. Some shells are flaky (e.g. zsh, tcsh), so you may > need to run it multiple times. > > Getting this into the mainline will be interesting. I would think it > would take some community discussion. I may be able to convince > people that the current behaviour is wrong, but I can't tell you what > will break if it is "fixed". And should the fix be the default? As > you mentioned, it depends on what people expect it to do and how it is > currently being used. I see the first step as presenting a clear case > of how it should work. > > -Dan -- Added file: http://bugs.python.org/file23780/ref_shlex.py Added file: http://bugs.python.org/file23781/test_shlex.diff ___ Python tracker <http://bugs.python.org/issue1521950> ___#!/usr/bin/env python """Test how various shells parse syntax. This is only expected to work on Unix based systems. We use the unittest infrastructure, but this isn't a normal test. Usage: ref_shelex.py [options] shells... """ # Written by: Dan Christian for issue1521950 # References: man bash # look at DEFINITIONS and SHELL GRAMMAR import glob import re import os, sys import subprocess import unittest TempDir = '/tmp' # where we will write temp files Shells = ['/bin/sh', '/bin/bash'] # list of shells to test against class ShellTest(unittest.TestCase): bgRe = re.compile(r'\[\d+\]\s+(\d+|\+ Done)$') # backgrounded command output def Run(self, shell, # shell to use command, # command to run filepath=None): # any files that are expected """Carefully run a shell command. Capture stdout, stderr, and exit status. Returns: (ret, out, err) ret is the return status out is the list of lines to stdout err is the list of lines to stderr """ start_cwd = os.getcwd() call = [shell, '-c', command] #print "Running: %s -c '%s'" % (shell, command) outpath = 'stdout.txt' errpath = 'stderr.txt' ret = -1 out = None err = None fileout = None try: os.chdir(TempDir) outfp = open(outpath, 'w') errfp = open(errpath, 'w') if filepath and os.path.isfile(filepath): os.remove(filepath) ret = subprocess.call(call, stdout=outfp, stderr = errfp) #print "Returned: %d" % ret outfp = open(outpath, 'r') out = outfp.readlines() os.remove(outpath) errfp = open(errpath, 'r') err = errfp.readlines() os.remove(errpath) if filepath: ffp = open(filepath) fileout = ffp.readlines() os.remove(filepath) except OSError as msg: print "Exception!", msg os.chdir(start_cwd) # leave files behind for debugging self.assertTrue(0, "Hit an exception running: " % ( ' '.join(call))) return (ret, out, err, fileout) def testTrue(self): """ Trivial case to test execution. """ for shell in Shells: cmd = '/bin/true' (ret, out, err, fout) = self.Run(shell, cmd) self.assertEquals( 0, ret, "Expected %s -c '%s' to return 0, not %d" % (shell, cmd, ret)) self.assertEq
[issue1521950] shlex.split() does not tokenize like the shell
Dan Christian added the comment: On Sat, Nov 26, 2011 at 7:12 AM, Éric Araujo wrote: > Your script passes with dash, which is probably the most POSIX-compliant > shell we can find. (bash has extensions, zsh/csh don’t use the POSIX shell > language, so I think the behavior of dash should be our reference, not the > bash man page.) I was just looking for a reference where I didn't have to sift through tons of documentation. Most systems have bash. Before that I was just working from experience (I've done a lot of shell scripting). > there is code out there that depends on the current behavior of shlex and > does not need to support && || ; ( ), if we add support for these tokens we > should not break the existing code. Here's a thought on how that might work (just brainstorming). shlex uses a series of character strings to drive it's parsing: whitespace, escape, quotes. Add another one: control = '();<>|&'. If it is unset (by default?), then the behavior is as before. If it is set, then shlex will output any character in control as a separate token. There might be a shell specific script (or maybe it's left to the user) that decides that certain tokens can be recombined: '&&', '||', '|&', '>>', etc. This code is pretty simple: walk the token sequence, if you see a two token pair, pop the second and combine it into the first. -Dan -- ___ Python tracker <http://bugs.python.org/issue1521950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1521950] shlex.split() does not tokenize like the shell
Dan Christian added the comment:
> Sure :) That’s why I suggest using dash for quick tests and rely on the work
> of other people who did read the POSIX spec. I’ll have to check it too
> before committing a patch.
The point of ref_shlex.py is that all shells act the same for common
cases and shlex doesn't match any of them. The only real split it
that csh based shells do some things differently that sh based shells
('2>' vs '&>').
>> shlex uses a series of character strings to drive it's parsing: whitespace,
>> escape, quotes.
>> Add another one: control = '();<>|&'. If it is unset (by default?), then
>> the behavior is as
>> before.
> So we would need to add a Shlex subclass to the module to provide the new
> behavior. I think I prefer a new argument, because we can just extend the
> existing class and functions instead of adding subtly differing duplicates.
You don't have to do a subclass (although that might have some
advantages). You could do something like:
def shlex(s, comments=False, posix=True, control=False):
...
if control:
if control is True:
self.control = '();<>|&'
else:
self.control = control # let user specify their own control set
>> If it is set, then shlex will output any character in control as a separate
>> token.
> Unless it is part of a quoted segment, right? (See #7611 for 'foo#bar' vs.
> 'foo #bar').
Correct, quotes wouldn't change.
>> There might be a shell specific script (or maybe it's left to the user)
>> that decides that certain tokens can be recombined:
> Seems to much complexity. I really prefer if we agree on one command parsing
> behavior (POSIX, i.e. dash) and improve shlex to support that. People
> wanting zsh rules can write their own subclass.
shlex is a pretty simple lexer (as lexers go), and I wouldn't want it
to get complicated. It's easier in the current code structure to
split everything and then re-join as needed. This also allows you to
select sh vs csh joining rules (e.g. '|&' means different things in sh
vs csh). Every shell that I've seen follows one of those two flavors
for syntax.
>> '&&', '||', '|&', '>>', etc.
> Wouldn’t it be more correct to consider them different tokens? I don’t have
> a format training in CS or programming, so I’m not sure that my definition is
> correct at all, but in my mind a token is a unit, and thus & and && are two
> different things.
Ideally, the final tokens have exact meanings. It easier to write
handler code for '&&' than ('&', '&'). This is just a case of whether
the parse joins them together or it's done in a second step. The
current code doesn't do much look ahead, so it's hard for the lexer to
produce things like '&&' directly.
-Dan
--
___
Python tracker
<http://bugs.python.org/issue1521950>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13647] Python SSL stack doesn't securely validate certificate (as client)
Dan Kaminsky added the comment: >> There is a new "match_hostname" that doesn't implement all the >> required, standard SSL/TLS Client security checks that should be done. >Indeed, as the name indicates, it just checks the hostname. >Please detail what the other security checks are (bonus points if you >provide >a patch + tests). You need to check expiration date of the cert in question, and I suppose invocation date as well. You need to look at each of the CNs in the subject name, as well as each of the DNSname types in the SAN extension. You *absolutely must* make sure that each of the intermediate certificates has Basic Constraints: CA set to True. Otherwise a certificate for foo.com can sign for bar.com (this keeps happening). You should support the Name Constraints extension, that allows certificates to sign for a subset of names. Nobody really uses this, because reliability is so low though. > > It has been noticed by the well known security researcher Dan Kaminsky > What's the URL for this? I'll see your URL and raise you a submitted bug report with recommendations. It seems to get better results than posting random whining on a web page somewhere :) > > A) Integrate the Mozilla CA pack into Python, updating it with each > > security release. > I suggest you discuss this on python-dev: > http://mail.python.org/mailman/listinfo/python-dev It's an ugly dependency, I know. X.509 suffers from a "false coherence" design, in which a couple of parties actively work to make it look like it has a coherent trust model. The best you can do is try to borrow/leverage the work of one of those parties. -- nosy: +Dan.Kaminsky ___ Python tracker <http://bugs.python.org/issue13647> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13647] Python SSL stack doesn't securely validate certificate (as client)
Dan Kaminsky added the comment: On Fri, Dec 23, 2011 at 4:14 AM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > > You need to check expiration date of the cert in question, and I > > suppose invocation date as well. > > You need to look at each of the CNs in the subject name, as well as > > each of the DNSname types in the SAN extension. > > You *absolutely must* make sure that each of the intermediate > > certificates has Basic Constraints: CA set to True. Otherwise a > > certificate for foo.com can sign for bar.com (this keeps happening). > > I'm confident this is already done by OpenSSL (if requested by user, > which means using CERT_REQUIRED or CERT_OPTIONAL in Python's ssl module > - these map to OpenSSL's SSL_VERIFY_PEER). > > I guess it would be easy to check this by providing an outdated > certificate - perhaps I'll give it a try. > Be sure to support SAN. People forget that, and the API makes it a pain in the butt (the validator doesn't even know who you're validating for). > > > > > A) Integrate the Mozilla CA pack into Python, updating it with each > > > > security release. > > > > > I suggest you discuss this on python-dev: > > > http://mail.python.org/mailman/listinfo/python-dev > > > > It's an ugly dependency, I know. X.509 suffers from a "false > > coherence" design, in which a couple of parties actively work to make > > it look like it has a coherent trust model. The best you can do is > > try to borrow/leverage the work of one of those parties. > > I suppose distributing CA certificates is a practical solution for the > user, *if* we are dedicated enough (e.g. release managers would have to > agree with the burden of tracking changes, and possibly making emergency > releases when a cert must be removed). That's the reason I suggest > asking on python-dev; I don't feel like making that decision alone. > The CA set doesn't change *often*, but it does shift from time to time. The right thing would be to use the in-built cert set if and only if the system certs couldn't be checked. > > That said, system OpenSSL builds on Linux (and perhaps OS X) should have > been compiled against a well-known system location of CA certificates > maintained by the OS vendor. In this case, you can simply use > SSLContext.set_default_verify_paths > ( > http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.set_default_verify_paths) > That doesn't help under Windows, though (where we build OpenSSL > ourselves so that the ssl module can be bundled in installers). > Whatever you've got right now isn't good enough to either be on by default, or warn by default. I wouldn't even recommend warning if you didn't ship with certs. Technically, you could check the Windows certificate stores too, if you wanted to write that code. Before going to python-dev, what do you think is feasible, implementation-wise? -- ___ Python tracker <http://bugs.python.org/issue13647> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11449] tarfile tries to file_.tell() even when creating a new archive
Dan Stromberg added the comment: Yes, I just needed to use 'w|' instead of 'w'. Thanks! -- resolution: -> works for me status: open -> closed ___ Python tracker <http://bugs.python.org/issue11449> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10527] multiprocessing.Pipe problem: "handle out of range in select()"
Dan Kenigsberg added the comment: I would rate this issue as a performance bug, not a mere feature request. If the python process has more than 1023 open file descriptors, multiprocessing.Pipe.poll() becomes unusable. This is a serious barrier to using multiprocessing in a complex server. -- nosy: +danken type: feature request -> performance ___ Python tracker <http://bugs.python.org/issue10527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9253] argparse: optional subparsers
Changes by Dan Sully : -- nosy: +dsully ___ Python tracker <http://bugs.python.org/issue9253> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602133] non-framework python fails to define os.environ properly
Dan Colish added the comment: I can also confirm this patch is required to build py2cairo on OSX with Python2.7.2 when --enable-framework is not used. -- nosy: +dcolish ___ Python tracker <http://bugs.python.org/issue1602133> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1521950] shlex.split() does not tokenize like the shell
Dan Christian added the comment: It's been a while since I looked at this. I'm not really in a position to contribute code/tests right now; but I can comment. I don't think POSIX mode existed when I first reported this, but that's where it makes sense. I think all POSIX shells (borne, C, korne), will behave the same way for the issues mentioned. There are really two cases in one bug. The first part is that the shell will split tokens at characters that shlex doesn't. The handling of &, |, ;, >, and < could be done by adjusting the definition of shlex.wordchars. The shell may also understands things like: &&, ||, |&, and >&. The exact definition of these depends on the shell, so maybe it's best to just split them out as separate tokens and let the user figure out the compound meanings. The proper handling of quotes/escapes requires some kind of new interface. You need to distinguish between tokens that were modified by the quote/escape rules and those that were not. One suggestion is to add a new method as such: shlex.get_token2() Return a tuple of the token and the original text of the token (including quotes and escapes). Otherwise, this is the same as shlex.get_token(). Comparing the two values for equality (or maybe identity) would tell you if something special was going on. You can always pass the second value to a reconstructed command line without losing any of the original parsing information. -Dan On Fri, Sep 3, 2010 at 10:27 AM, Éric Araujo wrote: > > Éric Araujo added the comment: > > Thanks for the report. Would you like to work on a patch, or translate your > examples into unit tests? > > The docs do not mention “&” at all, and platform discrepancies have to be > taken into account too, so I really don’t know if this is a bug fix for the > normal mode, the POSIX mode, or a feature request requiring a new argument to > the shlex function to preserve compatibility. > > -- > nosy: +eric.araujo, eric.smith > > ___ > Python tracker > <http://bugs.python.org/issue1521950> > ___ > -- ___ Python tracker <http://bugs.python.org/issue1521950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4661] email.parser: impossible to read messages encoded in a different encoding
Changes by Dan Buch : -- nosy: +meatballhat ___ Python tracker <http://bugs.python.org/issue4661> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9954] include sqlite3.exe in PythonXX/Scripts
New submission from Dan L : since sqlite3 is included in the standard library, it would be useful to have access to the command line tool that's part of sqlite. Including the command-line binary for each respective OS in the respective Scripts or bin folder would allow python users to create a connection in order to examine their sqlite databases and perform some manual operations easily. While the tool isn't in python, it's not that big of a file and such a tool is a pretty fundamental part of having a database(miniaturized or not). -- components: Library (Lib) messages: 117418 nosy: jdan priority: normal severity: normal status: open title: include sqlite3.exe in PythonXX/Scripts type: feature request versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue9954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9997] function named 'top' gets unexpected namespace/scope behaviour
Changes by Dan Uznanski : -- nosy: +dan.uznanski ___ Python tracker <http://bugs.python.org/issue9997> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10369] tarfile requires an actual file on disc; a file-like object is insufficient
New submission from Dan Stromberg :
The tarfile module's gettarinfo callable insists on stat'ing the file in
question, preventing one from dynamically generating file content by passing a
file-like object for addfile's fileobj argument.
I believe the attached patch fixes this issue. I generated the patch against
2.7 and tested it with 2.7, but it applies cleanly against 3.1 and "feels
innocuous". I've also included my test code at the bottom of this comment.
Why would you want to do this? Imagine you've stored a file in three smaller
files (perhaps to save the pieces on small external media, or as part of a
deduplication system), with the content divided up into thirds. To
subsequently put this file as a whole into a tar archive, it'd be nice if you
could just create a file-like object to emit the catenation, rather than having
to create a temporary file holding that catenation.
It's occurred to me that this should be done in a more object oriented style,
but that feels a bit inconsistent given that fstat is in the os module, and not
provided as an attribute of a file(-like) object. Comments?
Here's the test code:
#!/usr/local/cpython-2.7/bin/python
import os
import sys
import copy
import array
import stat_tarfile
def my_stat(filename):
class mutable_stat:
pass
readonly_statobj = os.lstat(filename)
mutable_statobj = mutable_stat()
for attribute in dir(readonly_statobj):
if not attribute.startswith('_'):
value = getattr(readonly_statobj, attribute)
setattr(mutable_statobj, attribute, value)
return mutable_statobj
class generate_file_content:
def __init__(self, number):
self._multiplier = 100
self._multipleno = 0
self._number = str(number)
self._buffer = ''
def read(self, length):
while self._multipleno < self._multiplier and len(self._buffer)
< length:
self._buffer += self._number
self._multipleno += 1
if self._buffer == '':
return ''
else:
result = self._buffer[:length]
self._buffer = self._buffer[length:]
return result
def main():
with stat_tarfile.open(fileobj = sys.stdout, mode = "w|") as tar:
for number in xrange(100):
#string = str(number) * 100
fileobj = generate_file_content(number)
statobj = my_stat('/etc/passwd')
statobj.st_size = len(str(number)) * 100
filename = 'file-%d.txt' % number
tarinfo = tar.gettarinfo(filename, statobj = statobj)
tarinfo.uid = 1000
tarinfo.gid = 1000
tarinfo.uname = "dstromberg"
tarinfo.gname = "dstromberg"
tar.addfile(tarinfo, fileobj)
main()
--
components: Library (Lib)
files: tarfile.diff
keywords: patch
messages: 120822
nosy: strombrg
priority: normal
severity: normal
status: open
title: tarfile requires an actual file on disc; a file-like object is
insufficient
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19549/tarfile.diff
___
Python tracker
<http://bugs.python.org/issue10369>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11449] tarfile tries to file_.tell() even when creating a new archive
New submission from Dan Stromberg : The attached file demonstrates the problem in 2.5, 2.5, 2.7, 3.0, 3.1 and 3.2. In short, I believe when you're creating a new tar archive (say, to a pipe), there should be no need for a file_.tell() (which blows up when it's a pipe). I have a workaround, as demonstrated in the file, but probably others shouldn't have to work around this also in the future. Suggested fix: Only do the tell when you're appending or performing other operations that require subsequent seek's. -- components: Extension Modules files: tar-test messages: 130422 nosy: strombrg priority: normal severity: normal status: open title: tarfile tries to file_.tell() even when creating a new archive type: crash versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file21059/tar-test ___ Python tracker <http://bugs.python.org/issue11449> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Dan Stromberg added the comment: I don't know that much about compression, but I wonder if a threadsafe compression module would enable parallel forms of compression? If yes, then multithreaded might be a big benefit, in light of multicore taking off. EG: http://www.compression.ca/pbzip2/ It might be worthwhile to check with the authors (of bzip2 and pyliblzma modules) about why they went with thread safety. -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Dan Stromberg added the comment: Interesting thing to consider: maybe it'd be better to add support for libarchive, which includes xz support among other things. http://code.google.com/p/libarchive/ -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10471] include documentation in python docs and under python -h for other commandline options
New submission from Dan L : there are options such as 'python -tt -bb' that are undocumented at http://docs.python.org/using/cmdline and that don't show up when you type python -h. ( Doubling t and b turns tabs or bytes warnings into errors. ) I don't know if they show up or not when you type 'man python', but for windows devs, it'd be best if it were included in the '-h' text excerpt in addition to being in the online docs. It could also be nice to have an example for the W arg option, e.g. for Wd. -- assignee: d...@python components: Documentation, Interpreter Core messages: 121746 nosy: d...@python, jdan priority: normal severity: normal status: open title: include documentation in python docs and under python -h for other commandline options type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue10471> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Dan Stromberg added the comment: While I realize Python extension modules are pretty much the norm in CPython, it'd be pretty cool if xz support could be written overtop of ctypes. ctypes seems to be emerging as the way of doing FFI across different python implementations. I've been working on a backup engine in my spare time, and I'd very much like to use a Python xz module in it. However, the code I have so far runs about 4x faster on pypy than CPython, even if I turn on psyco in CPython. IOW, I'd be pretty pleased to see an xz module that works equally well on CPython, pypy (seems to have pretty good ctypes), jython (has the beginnings of ctypes in 2.5.2rc*), iron python (supposedly included recently)... -- nosy: +strombrg ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Dan Stromberg added the comment: I agree that ctypes is a bit more brittle - both ctypes and c extension modules can yield segfaults, but at least the c extension module is likely to give an error or warning when you rebuild it. However, I'm getting the impression that: 1) In pypy, the C extension module layer isn't a complete emulation 2) In pypy, the C extension module is a bit disfavored compared to ctypes 3) In pypy, there's a performance expense for CPyExt compared to ctypes 3) (less important) In pypy, the C extension module layer is still too young to do much with at this time I've been wondering if maybe there should be a way to check ctypes use against .h's at build time. That way, the brittleness should be about the same. -- ___ Python tracker <http://bugs.python.org/issue6715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11166] No exit when daemon thread is running.
New submission from Dan Mahn : I have a python-based test script that creates a daemon thread. The foreground basically runs a loop of commands, while the daemon thread sends some UDP data on the network. To stop the script, I use Control-C. This is running under 64-bit Windows (Vista) with 64-bit Python. This script was developed under Python version 3.0, and has been running fine with 3.1. I downloaded 3.2RC1 and noticed that the script does not exit with the typical Ctrl-C. I also tried 3.2RC2, which had the same effect. If I do not start the background thread, the test exits normally. If I use Python 3.1, but I don't set the daemon attribute on the background thread, the operation duplicates the problem. Therefore, I believe there is a problem with 3.2 handling of daemon threads. -- components: None messages: 128260 nosy: dmahn priority: normal severity: normal status: open title: No exit when daemon thread is running. type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue11166> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11166] No exit when daemon thread is running.
Dan Mahn added the comment: Seems to be fixed in RC3 -- ___ Python tracker <http://bugs.python.org/issue11166> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11247] e
Changes by Dan Mahn : -- nosy: dmahn priority: normal severity: normal status: open title: e ___ Python tracker <http://bugs.python.org/issue11247> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11247] Error sending packets to multicast IPV4 address
New submission from Dan Mahn :
Can't send UDP packet to multicast address. See traceback.
s.sendto( bytearray, ("227.5.6.7", 6543))
socket.error: [Errno 10065] A socket operation was attempted to an unreachable
host
--
components: +None
title: e -> Error sending packets to multicast IPV4 address
type: -> behavior
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue11247>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11247] Error sending packets to multicast IPV4 address
Dan Mahn added the comment: This has occurred in RC3 -- ___ Python tracker <http://bugs.python.org/issue11247> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3374] Bisect upgrades: key/cmp/reverse, parameterized handedness
New submission from Dan Uznanski <[EMAIL PROTECTED]>: Attached find a unified diff that upgrades the bisect module in two important ways: 1. bisect and friends now understand cmp, key, and reverse, the same way that list.sort does. 2. bisect and insort now have parameterized handedness: instead of using two different functions depending on whether you want new items to show up before or after existing ones, bisect and insort now take a flag called 'right' which can change the handedness on the fly. Currently this code fails two existing regression tests: test_backcompatibility, because bisect is no longer the same as bisect_right; and test_non_sequence, because insort now raises AttributeError instead of TypeError when called on an int. Still to do, in order of priority as perceived by me: 1. A C version of the code needs to be written. 2. The error handling should be worked over by somebody with more knowledge than I - the regression tests assume that particular failures (len-only, get-only, and non-sequence) will happen with one of TypeError or AttributeError when in reality they may raise the other. 3. The tests for new functionality should be made more exhaustive. 4. The in-module documentation probably needs cleaning; the rst documentation needs my name added to it (a good deal of the existing writing is still Fred L Drake's, so I won't replace) and needs to have the "section 3.6.4" part linked to Mutable Sequence Types; I couldn't find an actual example of that linkage. 5. The godawful conditions in bisect should probably get cleaned up. -- components: Library (Lib) files: bisect-2.7.diff keywords: patch messages: 69773 nosy: dan.uznanski severity: normal status: open title: Bisect upgrades: key/cmp/reverse, parameterized handedness versions: Python 2.7 Added file: http://bugs.python.org/file10904/bisect-2.7.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3374> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3774] tkinter Menu.delete bug
Dan OD <[EMAIL PROTECTED]> added the comment: Please forgive my rookie bug filing: I'm getting this bug / crash sometimes when Menu.delete() is called too It seems to be because self.index( ) sometimes returns None which is of course un-iterable and delete() tries to iterate through it: for i in range(self.index(index1), self.index(index2)+1): As a fix the previous (simpler) delete works for me, but I don't understand the purpose of the extra self.deletecommand() code appended so I'm probably missing something. My crash: File "C:\CCPN\ccpn\python\memops\gui\Menu.py", line 127, in deleteMenuItems self.delete(0, Tkinter.END) File "C:\Python26\lib\lib-tk\Tkinter.py", line 2665, in delete for i in range(self.index(index1), self.index(index2)+1): TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' -- nosy: +indiedan ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3774] tkinter Menu.delete bug
Dan OD <[EMAIL PROTECTED]> added the comment: Thanks guys - I was running an old build. revision 65971 fixed this as Hirokazu mentioned. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3774] tkinter Menu.delete bug
Dan OD <[EMAIL PROTECTED]> added the comment: It may be because I'm calling delete incorrectly (I don't think so - see below) but I'm getting an error File "C:\CCPN\ccpn\python\memops\gui\Menu.py", line 127, in deleteMenuItems self.delete(0, Tkinter.END) File "C:\Python-2.6_svn\lib\lib-tk\Tkinter.py", line 2670, in delete if c in self._tclCommands: TypeError: argument of type 'NoneType' is not iterable Which can easily be fixed with - if c in self._tclCommands: + if c and c in self._tclCommands: line 2670 Tkinter.py Should I create a patch or have I missed something? Thanks. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3774] tkinter Menu.delete bug
Dan OD <[EMAIL PROTECTED]> added the comment: gpolo's patch issue3774_2.diff does seem to fix this bug, but it's not in the SVN trunk - could this be done before 2.6 final? Thanks! ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3774> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4076] Cannot build non-framework tkinter Python on Mac OS X.5
New submission from Dan OD <[EMAIL PROTECTED]>: On a Mac running OS X 10.5: As per previous releases, I have set up _tkinter in Modules/Setup.dist with a unix X11 Tcl/Tk build variables. I then run ./configure && make This builds _tkinter with (wrongly) the Mac Tcl framework (ie not X11) building '_tkinter' extension gcc-4.2 -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict- prototypes -DWITH_APPINIT=1 - I/System/Library/Frameworks/Tcl.framework/Headers - I/System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeader s -I/System/Library/Frameworks/Tk.framework/Headers - I/System/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/include -I. -I/Users/djo35/src/Python-3.0rc1/./Include -I. -IInclude -I./Include -I/usr/local/include -I/Users/djo35/src/Python- 3.0rc1/Include -I/Users/djo35/src/Python-3.0rc1 -c /Users/djo35/src/Python-3.0rc1/Modules/_tkinter.c -o build/temp.macosx- 10.3-i386-3.0/Users/djo35/src/Python-3.0rc1/Modules/_tkinter.o - framework Tk I would like this to build a unix tkinter.so - is this possible? I can't find a reference in the 3k documentation. Thanks, Dan -- components: Build messages: 74528 nosy: indiedan severity: normal status: open title: Cannot build non-framework tkinter Python on Mac OS X.5 type: behavior versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4076] Cannot build non-framework tkinter Python on Mac OS X.5
Dan OD <[EMAIL PROTECTED]> added the comment: Confusion - apologies - please remove this report. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7758] cPickle segfault on invalid data
New submission from Dan Helfman : The following code causes Python to segfault: >>> import cPickle >>> import cStringIO as io >>> cPickle.load( io.StringIO( '0' ) ) Note that if the string is changed from '0' to '1', then the crash does not occur and an UnpicklingError is properly raised. This is in MSYS on Windows XP with Python 2.6.4 from python.org: $ gdb python GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-mingw32"...(no debugging symbols found)... (gdb) r -c "import cPickle; import cStringIO as io; cPickle.load( io.StringIO( '0' ) )" Starting program: c:\python26/python.exe -c "import cPickle; import cStringIO as io; cPickle.load( io.StringIO( '0' ) )" Program received signal SIGSEGV, Segmentation fault. 0x1e09ada3 in ?? () (gdb) bt #0 0x1e09ada3 in ?? () #1 0x1e0e1fd5 in ?? () #2 0x00a4e290 in ?? () #3 0x1e1d1d30 in ?? () Cannot access memory at address 0x3 And this is on Mac OS X 10.5 with Python 2.6.4 from python.org: $ gdb python GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries .. done (gdb) r -c "import cPickle; import cStringIO as io; cPickle.load( io.StringIO( '0' ) )" Starting program: /System/Library/Frameworks/Python.framework/Versions/2.6/bin/python -c "import cPickle; import cStringIO as io; cPickle.load( io.StringIO( '0' ) )" Reading symbols for shared libraries +. done Program received signal SIGTRAP, Trace/breakpoint trap. 0x8fe01010 in __dyld__dyld_start () (gdb) bt #0 0x8fe01010 in __dyld__dyld_start () Cannot access memory at address 0x4 The same crash occurs on the Mac when using Apple's Python 2.5.1. However, on Linux with Debian stable's Python 2.5.2, I just get an UnpicklingError (stack underflow) exception without a crash. -- components: None messages: 98157 nosy: dhelfman severity: normal status: open title: cPickle segfault on invalid data type: crash versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue7758> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7758] cPickle.load() segfault on invalid data
Changes by Dan Helfman : -- title: cPickle segfault on invalid data -> cPickle.load() segfault on invalid data ___ Python tracker <http://bugs.python.org/issue7758> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7803] setup hangs on disk space requirements
New submission from Dan Simmons : I tried to install windows binary and the setup hanged up on 'determining disk space requirements' I waited over two hours for this to finish, and the light blinked in a syncrinised pattern that led me to believe something was wrong. So I have since restarted it and the light is blinking differently this time. Hope it works. -- messages: 98503 nosy: abilify severity: normal status: open title: setup hangs on disk space requirements versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue7803> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7803] setup hangs on disk space requirements
Dan Simmons added the comment: I think the beginers guide needs to be updated to let us know what type of download to use. x86-64 or binary. 64 bit works so is that the right one for me. I'm trying to get this graphics.py to work that came with a book. It stops working when I run a module with it. -- ___ Python tracker <http://bugs.python.org/issue7803> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7803] setup hangs on disk space requirements
Changes by Dan Simmons : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue7803> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7803] setup hangs on disk space requirements
Dan Simmons added the comment: It seemed to work after I restarted it. It was stuck on the process of getting disk space requirements, the computer was processing something but the light on the console that tells you something is being processed was blinking once every second in a obvious loop, When I started over it just processed through it in less than a second. So there was something wrong. I don't know if it was my computer or not. --- On Fri, 1/29/10, Brian Curtin wrote: From: Brian Curtin Subject: [issue7803] setup hangs on disk space requirements To: sentai...@yahoo.com Date: Friday, January 29, 2010, 3:37 PM Brian Curtin added the comment: Dan, there seem to be a number of possible issues in your last two messages. It's not clear to me what the blinking light is. What type of computer do you have and what is the specific installer and version you tried to run? Also, what do you mean when you say that it stops working when you run a module? Does the interpreter crash or is there an unhandled exception which causes the application to exit? -- nosy: +brian.curtin status: closed -> open ___ Python tracker <http://bugs.python.org/issue7803> ___ -- Added file: http://bugs.python.org/file16036/unnamed ___ Python tracker <http://bugs.python.org/issue7803> ___It seemed to work after I restarted it. It was stuck on the process of getting disk space requirements, the computer was processing something but the light on the console that tells you something is being processed was blinking once every second in a obvious loop, When I started over it just processed through it in less than a second. So there was something wrong. I don't know if it was my computer or not.--- On Fri, 1/29/10, Brian Curtin <rep...@bugs.python.org> wrote: From: Brian Curtin <rep...@bugs.python.org>Subject: [issue7803] setup hangs on disk space requirementsTo: sentai...@yahoo.comDate: Friday, January 29, 2010, 3:37 PM Brian Curtin <http://us.mc1101.mail.yahoo.com/mc/compose?to=cur...@acm.org"; ymailto="mailto:cur...@acm.org";>cur...@acm.org> added the comment:Dan, there seem to be a number of possible issues in your last two messages.It's not clear to me what the blinking light is. What type of computer do you have and what is the specific installer and version you tried to run?Also, what do you mean when you say that it stops working when you run a module? Does the interpreter crash or is there an unhandled exception which causes the application to exit?--nosy: +brian.curtinstatus: closed -> open___Python tracker <http://us.mc1101.mail.yahoo.com/mc/compose?to=rep...@bugs.python.org"; ymailto="mailto:rep...@bugs.python.org";>rep...@bugs.python.org><http://bugs.python.org/issue7803"; target=_blank>http://bugs.python.org/issue7803>___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5712] tkinter - askopenfilenames returns string instead of tuple in windows 2.6.1 release
Changes by Dan Halbert : -- nosy: +dhalbert ___ Python tracker <http://bugs.python.org/issue5712> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7885] test_distutils fails if Python built in separate directory
Dan Dever added the comment: Adding version 2.6 This fails for me with 2.6.5 in the same way. -- nosy: +dedded versions: +Python 2.6 ___ Python tracker <http://bugs.python.org/issue7885> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8349] os.environ.get returns incorrect data
New submission from Dan Brandow :
I have a Windows 7 64 bit machine, which means it has a few different
environment variables concerning the program files location:
PROGRAMFILES=C:\Program Files (x86)
ProgramFiles(x86)=C:\Program Files (x86)
Note that both env variables have "(x86)" at the end.
When I do an os.environ.get I get the following results:
Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on
win32
>>> import os
>>> print os.environ.get('ProgramFiles(x86)')
C:\Program Files (x86)
>>> print os.environ.get('PROGRAMFILES')
C:\Program Files
>>> print os.environ.get('ProgramFiles')
C:\Program Files
>>>
Note the missing "(x86)" on the last two test cases.
I tried it on the 64-bit version of 2.5.4 as well:
Python 2.5.4 (r254:67916, Dec 23 2008, 15:19:34) [MSC v.1400 64 bit (AMD64)] on
win32
>>> import os
>>> print os.environ.get('ProgramFiles(x86)')
C:\Program Files (x86)
>>> print os.environ.get('PROGRAMFILES')
C:\Program Files
>>> print os.environ.get('ProgramFiles')
C:\Program Files
>>>
Same result. So I tried the 32-bit version of 2.5.4:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
>>> import os
>>> print os.environ.get('ProgramFiles(x86)')
C:\Program Files (x86)
>>> print os.environ.get('PROGRAMFILES')
C:\Program Files (x86)
>>> print os.environ.get('ProgramFiles')
C:\Program Files (x86)
>>>
...which gave the correct strings...
--
components: Extension Modules
messages: 102646
nosy: dbrandow
severity: normal
status: open
title: os.environ.get returns incorrect data
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue8349>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4147] xml.dom.minidom toprettyxml: omit whitespace for text-only elements
Changes by Dan Kenigsberg : -- nosy: +danken ___ Python tracker <http://bugs.python.org/issue4147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4908] Implement PEP 376
Changes by Dan Buch : -- nosy: +meatballhat ___ Python tracker <http://bugs.python.org/issue4908> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8312] Add post/pre hooks for distutils commands
Changes by Dan Buch : -- nosy: +meatballhat ___ Python tracker <http://bugs.python.org/issue8312> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8324] add a distutils test command
Changes by Dan Buch : -- nosy: +meatballhat ___ Python tracker <http://bugs.python.org/issue8324> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8255] step-by-step tutorial
Changes by Dan Buch : -- nosy: +meatballhat ___ Python tracker <http://bugs.python.org/issue8255> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8254] write a configure command
Changes by Dan Buch : -- nosy: +meatballhat ___ Python tracker <http://bugs.python.org/issue8254> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8252] add a metadata section in setup.cfg
Changes by Dan Buch : -- nosy: +meatballhat ___ Python tracker <http://bugs.python.org/issue8252> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8250] Implement pkgutil APIs as described in PEP 376
New submission from Dan Buch : is this a dupe of 4908? -- nosy: +meatballhat ___ Python tracker <http://bugs.python.org/issue8250> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5302] Allow package_data globs match directories
Changes by Dan Buch : -- nosy: +meatballhat ___ Python tracker <http://bugs.python.org/issue5302> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8253] add a resource+files section in setup.cfg
Changes by Dan Buch : -- nosy: +meatballhat ___ Python tracker <http://bugs.python.org/issue8253> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8357] Add a --show-installation-paths in the install command
Changes by Dan Buch : -- nosy: +meatballhat ___ Python tracker <http://bugs.python.org/issue8357> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8591] update mkpkg to latest coding standards
New submission from Dan Buch : On first glance, `distutils2.mkpkg` does not reflect the latest and greatest in Python coding standards. I'd like to take a stab at PEP-(7|8)'ing the whole thing, although I know there are other issues open to add features to the module, so I don't want to cause unnecessary merge pains. Thoughts? -- assignee: tarek components: Distutils2 messages: 104726 nosy: meatballhat, tarek priority: normal severity: normal status: open title: update mkpkg to latest coding standards type: behavior versions: 3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue8591> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8591] update mkpkg to latest coding standards
Dan Buch added the comment: I probably shouldn't have dropped the PEP8 bomb so much as stated that I feel the module could use some updating. It's my (very much potentially wrong) understanding that `distutils2.mkpkg` isn't considered library code so much as the guts of a script. The reason for my concern about `distutils2.mkpkg` goes something like this: - it is a new addition to the distutils toolkit - if any kind of walkthrough is to be written for using distutils, there's a good chance the `mkpkg` script will be mentioned - curious folks like myself may look at the source code for the script - said curious folks may either be new to Python or new to programming in general - I don't want newcomers getting the wrong idea about Python coding standards I should also mention that I have the same concern(s) about everything in the `Demo` tree of CPython :) Even if `setup.py` files aren't the eventual goal, if they're around for even another 2 years I think the effort is justified. -- ___ Python tracker <http://bugs.python.org/issue8591> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8604] Alias for distutils.file_util.write_file in e.g. shutils
Changes by Dan Buch : -- nosy: +meatballhat ___ Python tracker <http://bugs.python.org/issue8604> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8591] update mkpkg to latest coding standards
Dan Buch added the comment: bump. Would it be more helpful if I were to submit a patch, too, or is doing so prior to guidance from the driver (Tarek) frowned upon? -- ___ Python tracker <http://bugs.python.org/issue8591> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8638] Remove suggestion for name mangling from the tutorial
Changes by Dan Buch : -- nosy: +meatballhat ___ Python tracker <http://bugs.python.org/issue8638> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8653] urlparse.urlparse/urlsplit doc missing
Changes by Dan Buch : -- nosy: +meatballhat ___ Python tracker <http://bugs.python.org/issue8653> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
