[issue13506] IDLE sys.path does not contain Current Working Directory
Roger Serwy roger.se...@gmail.com added the comment: +1 The proposed patch works as described. I do agree with Marco that IDLE does need some more QA. -- nosy: +serwy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13506 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13471] setting access time beyond Jan. 2038 on remote share failes on Win7 x64
Thorsten Simons t...@snomis.de added the comment: Gentlemen, thank you for your contribution - the information about the Samba fix solved the problem! -- resolution: - works for me status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13471 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13471] setting access time beyond Jan. 2038 on remote share failes on Win7 x64
Changes by Petri Lehtinen pe...@digip.org: -- resolution: works for me - invalid stage: - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13471 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13504] Meta-issue for Invent with Python IDLE feedback
Ned Deily n...@acm.org added the comment: #10364 covers point 7 (make .py default added extension on save) -- dependencies: +IDLE: make .py default added extension on save nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13507] Modify OS X installer builds to package liblzma for the new lzma module
New submission from Ned Deily n...@acm.org: Since AFAIK Apple does not currently ship a version of liblzma with Mac OS X, the OS X installer build script should be modified to build and link a version in support of the new lzma module (Issue6715). Mac/BuildScript/build-installer.py http://tukaani.org/xz/ -- assignee: ned.deily components: Build, Macintosh messages: 148646 nosy: nadeem.vawda, ned.deily, ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: Modify OS X installer builds to package liblzma for the new lzma module type: feature request versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13507 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Ned Deily n...@acm.org added the comment: I've opened Issue13507 to track adding liblzma to the OS X installer builds. -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13097] ctypes: segfault with large number of callback arguments
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13097 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13097] ctypes: segfault with large number of callback arguments
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Right, alloca() could be replaced by some malloc(), but is it really useful? After all, when a C function calls back to Python, all arguments needs to be pushed to the stack anyway. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13097 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9116] test_capi.test_no_FatalError_infinite_loop crash on Windows
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
STINNER Victor victor.stin...@haypocalc.com added the comment: Just to clarify, no decision has yet been made on *whether* the cdecimal work should be integrated into py3k; we'll consult python-dev on this once we've got a working branch and performance information. So, what is the status today? _decimal looks to be huge. Does Python really need yet another multiprecision library? There is already gmpy and bigfloat, based on the heavily optimized GMP library, for example. Is it a license issue? Can't we reuse GMP/MPFR to offer a Decimal API? _decimal should maybe first be distributed as a third party library until it is really well tested and its API is really stable, until we can decide to integrate it. The patch adds __setattr__ to the Decimal class. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13493] Import error with embedded python on AIX 6.1
python_hu nari...@163.com added the comment:
Thank Amaury,you are right.
So python2.7 share library compile finished,and python2.7 works,and then
I write a test program,to test libpython2.7.so share library,but it dumped!
code:
---
#include stdio.h^M
#include Python.h^M
#include dlfcn.h ^M
^M
int main( int argc, char **argv )^M
{^M
Py_Initialize();
if(!Py_IsInitialized())
{
printf(py initialized fail!);
return -1;
}
void* handle = dlopen(/usr/local/lib/python2.6/lib-dynload/time.so, 2);
if (handle == NULL) {
const char *error = dlerror();
if (error == NULL)
error = unknown dlopen() error;
printf(erro=%s\n,error);
return NULL;
}
if(!Py_IsInitialized())
{
printf(py initialized fail!);
return -1;
}
printf(hi,python!\n);
PyRun_SimpleString(from time import time,ctime\nprint 'Today
is',ctime(time())\n);
Py_Finalize();
}
This code can compile sucess,but run core dump:
ibm1:mmipytest
hi,python!
Fatal Python error: Interpreter not initialized (version mismatch?)
The core dump file:
-
IOT/Abort trap in pthread_kill at 0x9e23450 ($t1)
0x9e23450 (pthread_kill+0xb0) e8410028 ld r2,0x28(r1)
(dbx) run
hi,python!
Fatal Python error: Interpreter not initialized (version mismatch?)
IOT/Abort trap in pthread_kill at 0x9e23450 ($t1)
0x9e23450 (pthread_kill+0xb0) e8410028 ld r2,0x28(r1)
(dbx) where
pthread_kill(??, ??) at 0x9e23450
_p_raise(??) at 0x9e22cc8
raise.raise(??) at 0x902b10c
abort() at 0x9094544
pythonrun.Py_FatalError(msg = init%.200s), line 1675 in pythonrun.c
modsupport.Py_InitModule4_64(name = (nil), methods = 0x09001000a0b467d8, doc =
(invalid char ptr (0x2f7573722f6c6f63)), passthrough = 0x616c2f6c69622f70,
module_api_version = 0), line 38 in modsupport.c
inittime(), line 825 in timemodule.c
importdl._PyImport_LoadDynamicModule(name = (nil), pathname = , fp =
0x0004), line 53 in importdl.c
import.load_module(name = , fp = 0x0fffd8d8, buf =
^O\377\377\377\377\377\316p^I, type = 150994944, loader =
0x000110016e90), line 1830 in import.c
import.import_submodule(mod = 0x090005d0ebc4, subname = , fullname =
^I), line 2592 in import.c
import.load_next(mod = 0x0005, altmod = (nil), p_name =
0x090005dcba27, buf = , p_buflen = 0x09001000a0b2f9d0), line 2412 in
import.c
import.import_module_level(name = (nil), globals = 0x00011008c328, locals =
0x00011008c328, fromlist = 0x00011013d608, level = -1), line 2133 in
import.c
import.PyImport_ImportModuleLevel(name = , globals = (nil), locals =
0x090005dcba20, fromlist = 0x09001000a0b2f9d0, level = 268435455), line
2185 in import.c
bltinmodule.builtin___import__(self = 0x0fffd970, args =
0x0060, kwds = 0x0fffd980), line 48 in bltinmodule.c
methodobject.PyCFunction_Call(func = 0x0fffd9f0, arg =
0x09001000a0b467d8, kw = 0x0fffda00), line 85 in methodobject.c
abstract.PyObject_Call(func = 0x090005cb9ae4, arg = 0x09001000a0b467d8, kw
= 0x0fffda90), line 2492 in abstract.c
ceval.PyEval_CallObjectWithKeywords(func = 0x0004, arg =
0x0001100992d0, kw = 0x00011008c328), line 3619 in ceval.c
ceval.PyEval_EvalFrameEx(f = 0x0fffdda0, throwflag = 0), line 2159 in
ceval.c
ceval.PyEval_EvalCodeEx(co = (nil), globals = 0x00011000ca50, locals =
0x0fffdee4, args = 0x00011019a740, argcount = 1, kws =
0x09001000a0075420, kwcount = -1159983106, defs = 0xbadc0ffee0ddf00d, defcount
= 0, closure = (nil)), line 3000 in ceval.c
ceval.PyEval_EvalCode(co = 0x090005d578cc, globals = 0x488842281006e148,
locals = (nil)), line 541 in ceval.c
pythonrun.run_mod(mod = 0x0fffdff0, filename = ^I\377\377\377\360,
globals = 0x09028c20, locals = 0x09001000a0b467d8, flags =
0xbadc0ffee0ddf00d, arena = 0x09001000a0075420), line 1351 in pythonrun.c
pythonrun.PyRun_StringFlags(str = \350A, start = -1159983106, globals =
0xbadc0ffee0ddf00d, locals = 0xbadc0ffee0ddf00d, flags = 0xbadc0ffee0ddf00d),
line 1314 in pythonrun.c
pythonrun.PyRun_SimpleStringFlags(command = sucess!, flags =
0x0001), line 967 in pythonrun.c
main.main(argc = 1, argv = 0x0fffe190), line 42 in main.cpp
(dbx)
---
the line 38 in modsupport.c:
if (!Py_IsInitialized())
Py_FatalError(Interpreter not initialized (version mismatch?));
it looks like Py_IsInitialized() is false,but in my main(),the
Py_IsInitialized() return true.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13493
___
___
Python-bugs-list mailing list
Unsubscribe:
[issue13504] Meta-issue for Invent with Python IDLE feedback
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +berkerpeksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13493] Import error with embedded python on AIX 6.1
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: dlopen(/usr/local/lib/python2.6/lib-dynload/time.so, 2); You are trying to open a .so from another Python installation. It won't work: it is certainly linked to another Python VM, which is not initialized. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13493 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Mark Dickinson dicki...@gmail.com added the comment: Does Python really need yet another multiprecision library? It's not really another library: it's a reimplementation of the existing decimal library in C. The decimal library is *hugely* valuable to the financial world, but its slowness is a major concern. _decimal would help to address that concern. Can't we reuse GMP/MPFR to offer a Decimal API? Nope: those are for binary floating-point. Shoehorning decimal semantics on top of a binary floating-point library is a really bad idea. (Actually, that's a part of why decimal.py is slow---it's using Python's *binary* integers to store *decimal* coefficients, so that even simple addition is now a quadratic operation, thanks to the binary - decimal conversions involved.) _decimal should maybe first be distributed as a third party library until it is really well tested and its API is really stable. My take is that this has already happened. The only problem from my perspective is getting someone to find time to review such a massive patch. I've been wondering whether we could get away with some kind of 'statistical' review: do a large-scale review, and then instead of having someone go through every line of C code, pick a few representative sections at random and review those. If those code portions make it through the review unscathed, declare the code good and merge it in. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11732] Skip decorator for tests requiring manual intervention on Windows
Changes by Sébastien Sablé sa...@users.sourceforge.net: -- nosy: +sable ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11732 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Per Øyvind Karlsen peroyv...@mandriva.org added the comment: Ah, I thought that he had reused most of the original C code in _lzmamodule.c not replaced by python code, but I see that not being the case now (only slight fragments;). Oh well, I thought that I'd still earned a note with some slight credit at least, but I guess I won't go postal or anything in lack of either.. :p -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch
Changes by Sébastien Sablé sa...@users.sourceforge.net: -- nosy: +sable ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7833 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Oh well, I thought that I'd still earned a note with some slight credit at least I completely agree. Sometimes people get credit for simple bug fixes (count me among them) so the author of the first working implementation deserves some recognition IMO. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13504] Meta-issue for Invent with Python IDLE feedback
Roger Serwy roger.se...@gmail.com added the comment: #2704 covers point 1 (In the shell window, if you click anywhere but on the current line and move the cursor there, the window stops handling key strokes.) #3851 covers point 1.1) Pressing the Home key moves the cursor before the prompt, which then makes the keyboard unresponsive. #7136 covers point 5) Opening a file editor window or a shell window isn’t clear. #6804 and #6858 are also related to point 7 It’s too easy to forget the .py extension when saving a file. #694339 covers point 13) The Indent Region and Dedent Region lines use the keyboard shortcut Ctrl-] and Ctrl-[, even though nobody uses that because you can indent the region by pressing tab. #5150 is related to point 14) Get rid of the Format “Strip trailing whitespace” option from the menu #10747 covers point 16) The Windows shortcuts for IDLE don’t have the version in their name. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13508] ctypes' find_library breaks with ARM ABIs
New submission from Loïc Minier l...@dooz.org:
Hi,
This bug was originally reported at
https://bugs.launchpad.net/bugs/898172
ctypes/utils.py provides a find_library function which amongst other things
will scan the ldconfig -p output on linux to find libraries by name. It
applies some logic to filter out incompatible libraries, however the logic is
mainly based on uname output which is incorrect.
We noticed because the new Debian/Ubuntu armhf ports have a slightly different
ldconfig -p output than the armel ports; one gets ,hard-float in the output,
e.g.:
ld-linux.so.3 (libc6,hard-float) =
/lib/arm-linux-gnueabihf/ld-linux.so.3
there's provision in find_library to allow for certain strings when uname
returns certain names:
mach_map = {
'x86_64-64': 'libc6,x86-64',
'ppc64-64': 'libc6,64bit',
'sparc64-64': 'libc6,64bit',
's390x-64': 'libc6,64bit',
'ia64-64': 'libc6,IA-64',
but this is incorrect for multiple reasons:
a) this requires setting utsname properly before running a 32-bits python on a
64-bits kernel (e.g. linux32 ./foo.py instead of just ./foo.py); this
shouldn't be needed and breaks 32-bits userspace installations with a 64-bits
kernel
b) uname output can be anything really, e.g. i486, i586, i686 etc. on 32-bits
x86, or armv5l, armv6l, armv7l etc. on ARM
c) uname output doesn't indicate userspace ABI, a single kernel can support
multiple ABIs; for instance ARM kernels can support EABI and OABI (old ABI)
syscall ABIs at the same time, and even with the same syscall ABI like EABI the
userspace calling conventions might allow for multiple ABIs to be present on
the filesystem -- for instance soft-float and hard-float userspace calling
conventions
I've attached a patch to ctypes/utils.py in the Launchpad bug which I'll also
attach here. It will work for either soft-float or hard-float, but not if
ldconfig -p lists both types of libraries (as will be the case with biarch or
multiarch systems).
It is extremely hard to reproduce correct glibc semantics in find_library, and
a linux implementation would necessarily become extremely glibc and linux
specific. One possible way is to look at /proc/$pid/maps output to find
information about the ABI of the currently running program, and then ask the
runtime linker (ld.so) to check whether a given library is compatible or not
(--verify). Another way would be to run ldd on sys.executable to find the
runtime linker or libc. This is all extremely fragile and linux andglibc
specific, and will likely fail in special cases.
Finally, one needs to wonder whether offering find_library as an API isn't
calling for trouble; dlopen() requires one to state which SOVER should be used,
e.g. dlopen(libmagic.so.1), not dlopen(magic). Allowing the first SOVER to
be used means that the behavior is not determinstic and also means that people
wont think of binary compatibility when implementing ctypes-based bindings. I
would personally prefer if this API was deprecated and if we recommended for
upstreams to use ctypes.cdll.LoadLibrary(libmagic.so.1) constructs.
Cheers,
--
components: ctypes
messages: 148656
nosy: lool
priority: normal
severity: normal
status: open
title: ctypes' find_library breaks with ARM ABIs
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13508
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13508] ctypes' find_library breaks with ARM ABIs
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13508 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13508] ctypes' find_library breaks with ARM ABIs
Changes by Loïc Minier l...@dooz.org: -- keywords: +patch Added file: http://bugs.python.org/file23817/ctypes-arm.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13508 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13508] ctypes' find_library breaks with ARM ABIs
Loïc Minier l...@dooz.org added the comment: While I'm at it, find_library also tries creating temp files when running gcc and other issues mention trouble running gcc or propose running ld: http://bugs.python.org/issue9998 http://bugs.python.org/issue5289 IMHO, calling binutils/gcc is troublesome, it's not necessarily installed on production systems and creating tempfiles when running a program just to locate a library is fragile at best. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13508 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Éric Araujo mer...@netwok.org added the comment: Nadeem: Instead of duplicating the list of archiving/compression modules in each doc, what about only linking to the shutil doc for archives and the archiving.rst file? (I can make the patch, just wanted feedback first) -- ___ Python tracker rep...@bugs.python.org 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
Nadeem Vawda nadeem.va...@gmail.com added the comment: Not meaning to sound petty, but wouldn't it be common etiquette to retain some original copyright notice from original code intact..? It seemed to me that Nadeem had rewritten everything from scratch. Is there any code of yours in the current module? That is correct. Based on my experience with the bz2 module, rewriting from scratch seemed to make more sense. Oh well, I thought that I'd still earned a note with some slight credit at least I completely agree. Sometimes people get credit for simple bug fixes (count me among them) so the author of the first working implementation deserves some recognition IMO. Of course. How does this look? diff --git a/Misc/ACKS b/Misc/ACKS --- a/Misc/ACKS +++ b/Misc/ACKS @@ -502,6 +502,7 @@ Peter van Kampen Rafe Kaplan Jacob Kaplan-Moss +Per Øyvind Karlsen Lou Kates Hiroaki Kawai Sebastien Keim diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -400,6 +400,7 @@ --- - Issue #6715: Add a module 'lzma' for compression using the LZMA algorithm. + Thanks to Per Øyvind Karlsen for the initial implementation. - Issue #13487: Make inspect.getmodule robust against changes done to sys.modules while it is iterating over it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5411] add xz compression support to shutil
Éric Araujo mer...@netwok.org added the comment: distutils2/packaging now just uses the shutil functions. I’ll make a patch for shutil after tarfile is updated. -- assignee: tarek - eric.araujo components: +Library (Lib) -Distutils2 title: add xz compression support to distutils - add xz compression support to shutil versions: +Python 3.3 -3rd party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5411 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5689] Support xz compression in tarfile module
Éric Araujo mer...@netwok.org added the comment: Python now has an lzma module. Lars, do you have the time to update your patch or should I do it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5689 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Nadeem Vawda nadeem.va...@gmail.com added the comment: Instead of duplicating the list of archiving/compression modules in each doc, what about only linking to the shutil doc for archives and the archiving.rst file? Sure, go ahead. I actually hadn't realized that each section of the library docs had a sub-index page like that until now... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5411] add xz compression support to shutil
Changes by Nadeem Vawda nadeem.va...@gmail.com: -- nosy: +nadeem.vawda ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5411 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12832] The documentation for the print function should explain/point to how to control the sys.stdout encoding
Éric Araujo mer...@netwok.org added the comment: Thanks. Here’s another take: I think the wording is better, but it’s longer. I removed the reference to sys.stdin, which you don’t print to: I haven’t checked if the doc for the input function should talk about the encoding too. -- assignee: docs@python - eric.araujo Added file: http://bugs.python.org/file23818/print-encoding.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12832 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13210] Support Visual Studio 2010
Brian Curtin br...@python.org added the comment: Again, rather than work off of the default branch and duplicate effort, can you work off of the vs2010 branch on http://hg.python.org/sandbox/vs2010port/? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13210] Support Visual Studio 2010
Sébastien Sablé sa...@users.sourceforge.net added the comment: I have started working on python default branch. My patch queue is available here: https://bitbucket.org/sablefr/py3kvs2010/ The result is the following so far: 323 tests OK. 8 tests failed: test_distutils test_fileio test_gettext test_io test_os test_packaging test_pep3151 test_support 4 tests altered the execution environment: test_multiprocessing test_site test_subprocess test_sysconfig 27 tests skipped: test_crypt test_curses test_dbm_gnu test_dbm_ndbm test_devpoll test_epoll test_fcntl test_fork1 test_gdb test_grp test_ioctl test_kqueue test_nis test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_readline test_resource test_syslog test_threadsignals test_wait3 test_wait4 test_zipfile64 2 skips unexpected on win32: test_gdb test_readline Most errors seem related to errno. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improved support for abstract base classes with descriptors
Darren Dale dsdal...@gmail.com added the comment: Here is a new patch addressing comments raised in review. It supersedes previous patch submissions. -- Added file: http://bugs.python.org/file23819/abc_descriptor.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12014] str.format parses replacement field incorrectly
Ben Wolfson wolf...@gmail.com added the comment: All three patches look different to me. Yeah, I verified that later; I'm not sure what made me think otherwise except that I eyeballed them sloppily. (It's still true that they'd need to target a different file for 3.3 now.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12014 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Éric Araujo mer...@netwok.org added the comment: --- a/Misc/NEWS +++ b/Misc/NEWS @@ -400,6 +400,7 @@ --- - Issue #6715: Add a module 'lzma' for compression using the LZMA algorithm. + Thanks to Per Øyvind Karlsen for the initial implementation. The entry in Misc/ACKS, Doc/whatsnew/3.3.rst and the commit message should be enough. Lately I’ve noticed some attributions in NEWS, but it’s usually not done (as redundant). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Stefan Krah stefan-use...@bytereef.org added the comment: Binary versus decimal - There is already gmpy and bigfloat, based on the heavily optimized GMP library, for example. Is it a license issue? Can't we reuse GMP/MPFR to offer a Decimal API? _decimal is a PEP-399 compliant C implementation of decimal.py. The underlying standard is Cowlishaw/IBM's General Decimal Arithmetic Specification. decimal.py is used for standard-conforming financial calculations. There is no way to implement this in a reasonable manner using a binary floating point library. Additionally, _decimal is also heavily optimized. In fact, for small precisions the module has the same speed as gmpy! Soundness and code size --- _decimal should maybe first be distributed as a third party library until it is really well tested and its API is really stable, until we can decide to integrate it. Except for a different directory structure, the cdecimal module is identical to this patch. cdecimal has been distributed for almost two years now and has been on pypi for a year. There have been many downloads from financial institutions, stock exchanges and also research institutes. I know for a fact from a private email correspondence that libmpdec is used in a billing application of a large national NIC. cdecimal *appears* to be huge because it has a test suite that actually provides 100% code coverage. Indeed this means that even every possible malloc failure is simulated together with an assertion that the result of the function is (NaN, Malloc_error). The test suite now tests against both decimal.py and decNumber. It has found several small issues in decimal.py, a bug in netlib's dtoa.c, a bug in gmp and a bug in CompCert. The latest tests against decNumber have found 18 issues in decNumber (that I haven't reported yet). In the past 8 months, regression tests for cdecimal-2.3 have been running trillions of test cases both with and without Valgrind. Review -- The patch could be audited by focusing on basearith.c, cdecimal.c and mpdecimal.c. cdecimal.c is a long but simple wrapper around libmpdec. mpdecimal.c contains all functions of the specification. I contend that for a C programmer mpdecimal.c is not significantly harder to read than decimal.py. The tricky algorithms (newtondiv, invroot, sqrt-via-invroot and ln) have mechanical proofs in ACL2. An initial audit could certainly disregard convolute.c, crt.c, difradix2.c, fnt.c, numbertheory.c, transpose.c and umodarith.h. These are only needed for the number theoretic transform that kicks in at around 22000 digits. Context type safety --- The patch adds __setattr__ to the Decimal class. Making the context more strictly typed has instantly found a bug in one of decimal.py's docstring tests: # This doctest has always passed: c = Context(ExtendedContext) # But the operation is meaningless: c Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.7/decimal.py, line 3708, in __repr__ % vars(self)) TypeError: %d format: a number is required, not Context What is the concern about __setattr__? For *setting* contexts, speed is not so important (for reading contexts it is). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: what about a mention in lzmamodule.c? -- ___ Python tracker rep...@bugs.python.org 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
Éric Araujo mer...@netwok.org added the comment: I actually hadn't realized that each section of the library docs had a sub-index page like that That’s multiple-entry navigation :) You can jump to a module page, or use the index, or use the search, or browse and see the sub-indexes. As the docs for zlib, gzip, bz2, lzma, zipfile and tarfile are in the archiving subsection, there’s already a link to the subsection index, so I just removed the “See also zlib, etc.” lines (except for the link from zlib to gzip). I added a link from archiving.rst to shutil and more links and reST targets in shutil. -- Added file: http://bugs.python.org/file23820/archiving-modules-links.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13509] On uninstallation, distutils bdist_wininst fails to run post install script
New submission from Jason Roberts jason.robe...@duke.edu: Historically (i.e. Python 2.6.1 and earlier) bdist_wininst would run the post install script at both installation and uninstallation. The script would be invoked with a -install argument on installation and a -remove argument on uninstallation. This stopped working in Python 2.6.2 and has not worked since. This regression appears to have been introduced in r69094. That checkin rewrote Run_RemoveScript and associated functions in PC/bdist_wininst/install.c. The rewrite changed how the Python DLL was loaded during the remove scenario. Previously Run_RemoveScript itself called Win32 LoadLibrary on the DLL name parsed from the wininst log file. Now Run_RemoveScript calls run_installscript instead, which ultimately calls LoadPythonDll, which calls LoadLibrary on the pythondll global variable. But nothing initializes that variable during the remove scenario and LoadLibrary fails. Ultimately run_installscript silently fails and the removal proceeds to uninstall files and registry keys, with no notification to the user that the post install script was not run. A possible solution is to initialize pythondll in Run_RemoveScript to the DLL name parsed from the wininst log file, e.g. by inserting the following code prior to the call to run_installscript: strncpy(pythondll, dllname, scriptname - 1 - dllname); pythondll[scriptname - 1 - dllname] = '\0'; I tested this and it seemed to work fine. I believe this problem affects all Python releases following and including 2.6.2. The version history seems to show that r69094 was propagated to all of those releases. Presumably nobody found it because post install scripts on removal are not widely used. They are, however, critical for my application (at least if I want it to clean up properly on removal) so I would appreciate this being fixed. As it stands, I have to build a private patched copy of wininst-9.0.exe to work around this problem. -- assignee: tarek components: Distutils messages: 148672 nosy: eric.araujo, jasonjroberts, mhammond, tarek priority: normal severity: normal status: open title: On uninstallation, distutils bdist_wininst fails to run post install script type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13509] On uninstallation, distutils bdist_wininst fails to run post install script
Changes by Brian Curtin br...@python.org: -- components: +Windows nosy: +brian.curtin stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13276] distutils bdist_wininst created installer does not run the postinstallation script on uninstalling
Changes by Éric Araujo mer...@netwok.org: -- nosy: +brian.curtin, jasonjroberts stage: - test needed versions: +Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13276 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13509] On uninstallation, distutils bdist_wininst fails to run post install script
Éric Araujo mer...@netwok.org added the comment: Thanks for the diagnosis. Please contribute to the existing bug report. -- resolution: - duplicate stage: needs patch - committed/rejected status: open - closed superseder: - distutils bdist_wininst created installer does not run the postinstallation script on uninstalling ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13276] distutils bdist_wininst created installer does not run the postinstallation script on uninstalling
Jason Roberts jason.robe...@duke.edu added the comment: Sorry, I opened issue13509 after somehow not finding this one. Here is my text from issue13509. Thanks for looking at this problem... Historically (i.e. Python 2.6.1 and earlier) bdist_wininst would run the post install script at both installation and uninstallation. The script would be invoked with a -install argument on installation and a -remove argument on uninstallation. This stopped working in Python 2.6.2 and has not worked since. This regression appears to have been introduced in r69094. That checkin rewrote Run_RemoveScript and associated functions in PC/bdist_wininst/install.c. The rewrite changed how the Python DLL was loaded during the remove scenario. Previously Run_RemoveScript itself called Win32 LoadLibrary on the DLL name parsed from the wininst log file. Now Run_RemoveScript calls run_installscript instead, which ultimately calls LoadPythonDll, which calls LoadLibrary on the pythondll global variable. But nothing initializes that variable during the remove scenario and LoadLibrary fails. Ultimately run_installscript silently fails and the removal proceeds to uninstall files and registry keys, with no notification to the user that the post install script was not run. A possible solution is to initialize pythondll in Run_RemoveScript to the DLL name parsed from the wininst log file, e.g. by inserting the following code prior to the call to run_installscript: strncpy(pythondll, dllname, scriptname - 1 - dllname); pythondll[scriptname - 1 - dllname] = '\0'; I tested this and it seemed to work fine. I believe this problem affects all Python releases following and including 2.6.2. The version history seems to show that r69094 was propagated to all of those releases. Presumably nobody found it because post install scripts on removal are not widely used. They are, however, critical for my application (at least if I want it to clean up properly on removal) so I would appreciate this being fixed. As it stands, I have to build a private patched copy of wininst-9.0.exe to work around this problem. -- versions: +Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13276 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Antoine Pitrou pit...@free.fr added the comment: The entry in Misc/ACKS, Doc/whatsnew/3.3.rst and the commit message should be enough. Lately I’ve noticed some attributions in NEWS, but it’s usually not done (as redundant). I generally add attributions in NEWS since that's where most people learn about changes (for changes which aren't in whatsnew). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13276] bdist_wininst-created installer does not run the postinstallation script when uninstalling
Éric Araujo mer...@netwok.org added the comment: (2.6 and 3.1 don’t get bug fixes anymore.) -- title: distutils bdist_wininst created installer does not run the postinstallation script on uninstalling - bdist_wininst-created installer does not run the postinstallation script when uninstalling versions: -Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13276 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Stefan Krah stefan-use...@bytereef.org added the comment: Mark Dickinson rep...@bugs.python.org wrote: The only problem from my perspective is getting someone to find time to review such a massive patch. I've been wondering whether we could get away with some kind of 'statistical' review: do a large-scale review, and then instead of having someone go through every line of C code, pick a few representative sections at random and review those. If those code portions make it through the review unscathed, declare the code good and merge it in. The regex module is in a somewhat similar situation. If I'm interpreting this http://mail.python.org/pipermail/python-dev/2011-August/113240.html dialogue correctly, a complete audit down to the last line isn't always necessary. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Antoine Pitrou pit...@free.fr added the comment: If I'm interpreting this http://mail.python.org/pipermail/python-dev/2011-August/113240.html dialogue correctly, a complete audit down to the last line isn't always necessary. It is also helped by the fact you are a core developer and we trust you to be here to do maintenance :) I'd add that decimal is a fairly specialized module and the implications of a new engine are not as wide-reaching as a new regex engine. Especially if the pure Python version is still there. I think it's still probably a good idea to probe python-dev, if that hasn't already happened. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13510] Clarify that readlines() is not needed to iterate over a file
New submission from Peter Otten __pete...@web.de: I've been looking at code on the tutor mailing list for some time, and for line in file.readlines(): ... is a common idiom there. I suppose this is because the readlines() method is easily discoverable while the proper way (iterate over the file object directly) is not. A note added to the readlines() documentation might help: You don't need the readlines() method to loop over the lines of a file. for line in file: process(line) consumes less memory and is often faster. -- assignee: docs@python components: Documentation messages: 148679 nosy: docs@python, potten priority: normal severity: normal status: open title: Clarify that readlines() is not needed to iterate over a file type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13510] Clarify that readlines() is not needed to iterate over a file
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +eric.araujo, ezio.melotti stage: - needs patch versions: +Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Raymond Hettinger raymond.hettin...@gmail.com added the comment: We've been wanting this for a long time. Strong +1 from me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13511] ./configure --includedir, --libdir accept multiple
New submission from Ray rpq...@hotmail.com: For ./configure, --includedir and --libdir both cannot handle multiple packages. e.g. /configure --includedir=/home/user/.local/sqlite3-3.7.9/include --includedir=/home/user/.local/readline-6.2/include --libdir=/home/user/.local/sqlite3-3.7.9/lib --libdir=/home/user/.local/readline-6.2/lib and /configure --includedir=/home/user/.local/sqlite3-3.7.9/include /home/user/.local/readline-6.2/include --libdir=/home/user/.local/sqlite3-3.7.9/lib /home/user/.local/readline-6.2/lib The only way I could get the desired functionality was to set CFLAGS and LDFLAGS: export CFLAGS=-I/home/user/.local/readline-6.2/include/ -I/home/user/.local/sqlite3-3.7.9/include/ export LDFLAGS=-L/home/user/.local/readline-6.2/lib/ -L/home/user/.local/sqlite3-3.7.9/lib/ -- assignee: ronaldoussoren components: Build, Installation, Macintosh messages: 148681 nosy: ronaldoussoren, rpq priority: normal severity: normal status: open title: ./configure --includedir, --libdir accept multiple type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: I can help with the review. Is http://bugs.python.org/review/7652/show a good starting point? I already have some comments. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13511] ./configure --includedir, --libdir accept multiple
Ray rpq...@hotmail.com added the comment: I should mention, I had to modify setup.py in order for the export line in my original post to work on my linux machine. -- keywords: +patch Added file: http://bugs.python.org/file23821/setup.py.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040439] Missing documentation on how to link with libpython
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 2c05b8a6cdd1 by Antoine Pitrou in branch '3.2': Issue #1040439: better document how to compile and link an embedded Python interpreter. http://hg.python.org/cpython/rev/2c05b8a6cdd1 New changeset 528abe272856 by Antoine Pitrou in branch 'default': Issue #1040439: better document how to compile and link an embedded Python interpreter. http://hg.python.org/cpython/rev/528abe272856 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1040439 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040439] Missing documentation on how to link with libpython
Ray rpq...@hotmail.com added the comment: I think mentioning that you can export CFLAGS and LDFLAGS would be particularly useful. I was able to compile some of the missing packages that were deemed 'missing' at the end of 'make' by updating setup.py and having CFLAGS and LDFLAGS point to the desired packages' directories... Unfortunately for linux, the ability to specify *multiple* lib/ and include/ paths using this method is currently not available unless you modify setup.py. I opened a ticket in relation to this: Issue13511 if anyone cares. -- nosy: +rpq ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1040439 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040439] Missing documentation on how to link with libpython
Antoine Pitrou pit...@free.fr added the comment: I think mentioning that you can export CFLAGS and LDFLAGS would be particularly useful. I was able to compile some of the missing packages that were deemed 'missing' at the end of 'make' by updating setup.py and having CFLAGS and LDFLAGS point to the desired packages' directories... Unless I'm missing something, this is slightly off-topic for this issue, which is about using Python as an embedded interpreter, not compiling it. Embedding Python assumes it has already been built. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1040439 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Stefan Krah stefan-use...@bytereef.org added the comment: Antoine Pitrou rep...@bugs.python.org wrote: It is also helped by the fact you are a core developer and we trust you to be here to do maintenance :) Sure. The specification doesn't really change, so the work will hopefully be limited. :) I think it's still probably a good idea to probe python-dev, if that hasn't already happened. Yes, I'm planning to do that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Stefan Krah stefan-use...@bytereef.org added the comment: Raymond Hettinger rep...@bugs.python.org wrote: We've been wanting this for a long time. Strong +1 from me. Thank you, Raymond! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
STINNER Victor victor.stin...@haypocalc.com added the comment: (Actually, that's a part of why decimal.py is slow---it's using Python's *binary* integers to store *decimal* coefficients, so that even simple addition is now a quadratic operation, thanks to the binary - decimal conversions involved.) Oh, I forgot this minor detail (base 2 vs base 10). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Stefan Krah stefan-use...@bytereef.org added the comment: Amaury Forgeot d'Arc rep...@bugs.python.org wrote: I can help with the review. Is http://bugs.python.org/review/7652/show a good starting point? I already have some comments. Yes, that would be great. Apart from two or three changes that I still need to push patch set 4 is the latest version. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Changes by Stefan Krah stefan-use...@bytereef.org: Added file: http://bugs.python.org/file23822/bba956250186.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7652] Merge C version of decimal into py3k.
Stefan Krah stefan-use...@bytereef.org added the comment: Stefan Krah rep...@bugs.python.org wrote: Yes, that would be great. Apart from two or three changes that I still need to push patch set 4 is the latest version. Hmm, no. I'll create a slightly newer patch from Oct. 1st. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13504] Meta-issue for Invent with Python IDLE feedback
Changes by Nebelhom nebel...@googlemail.com: -- nosy: +Nebelhom ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13505] Bytes objects pickled in 3.x with protocol =2 are unpickled incorrectly in 2.x
Antoine Pitrou pit...@free.fr added the comment: After a bit of testing, my idea was flawed, as str() doesn't accept an encoding parameter in 2.x: `str(u'foo', 'latin1')` simply raises a TypeError. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13505 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13510] Clarify that readlines() is not needed to iterate over a file
Terry J. Reedy tjre...@udel.edu added the comment: This current line is Read and return a list of lines from the stream. hint can be specified to control the number of lines read: no more lines will be read if the total size (in bytes/characters) of all lines so far exceeds hint. I would like to see added Since a file is a line iterator, file.readlines() == list(file). To save time and space, iterate over lines of a file with for line in file: process(line). (with code markup for the two snippets). -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13455] Reorganize tracker docs in the devguide
Nick Coghlan ncogh...@gmail.com added the comment: Something else such docs could cover is how to manage remote Hg repos such that the Create Patch button does the right thing. Basically, you need to make sure an appropriate CPython version is found in the ancestors of the tip your working branch. This is most easily achieved either by working directly on the default branch in your remote repo, or else by merging directly from default to your feature branch (i.e. not via another feature branch). If you don't follow this rule, the generated patch will occasionally incorrectly revert changes in CPython that you didn't intend to affect. (see http://psf.upfronthosting.co.za/roundup/meta/issue428 for some background) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13455 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13491] Fixes for sqlite3 doc
Changes by Nebelhom nebel...@googlemail.com: Added file: http://bugs.python.org/file23823/sqlite_code_update.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13491 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 6cde416ef03b by Nadeem Vawda in branch 'default': Credit Per Øyvind Karlsen for the initial implementation of the lzma module (issue #6715). http://hg.python.org/cpython/rev/6cde416ef03b -- ___ Python tracker rep...@bugs.python.org 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
Nadeem Vawda nadeem.va...@gmail.com added the comment: As the docs for zlib, gzip, bz2, lzma, zipfile and tarfile are in the archiving subsection, there’s already a link to the subsection index, so I just removed the “See also zlib, etc.” lines (except for the link from zlib to gzip). I added a link from archiving.rst to shutil and more links and reST targets in shutil. Looks good to me. The entry in Misc/ACKS, Doc/whatsnew/3.3.rst and the commit message should be enough. Lately I’ve noticed some attributions in NEWS, but it’s usually not done (as redundant). According to Doc/whatsnew/3.3.rst: The maintainer will go through Misc/NEWS periodically and add changes; it's therefore more important to add your changes to Misc/NEWS than to this file. what about a mention in lzmamodule.c? Done and committed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13512] ~/.pypirc created insecurely
New submission from Vincent Danen vda...@linsec.ca: A bug was reported in python's distutils in that ~/.pypirc was created insecurely by first creating and writing user/password information to the file, then chmod'ing it to 0600. Perhaps the file should be created (empty), chmod'd, and then written to or perhaps tempfile.mkstemp() could be used to create the file and then move it in-place. On systems where /home/user is 0700 by default this isn't a problem, but there is a race condition that could possibly (although the window would be small) to expose credentials in a home directory that is 0755, for instance. I searched and couldn't find a similar report here, so decided to make upstream aware of the bug reported to Debian. References: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650555 https://bugzilla.redhat.com/show_bug.cgi?id=758905 -- assignee: tarek components: Distutils messages: 148697 nosy: Vincent.Danen, eric.araujo, tarek priority: normal severity: normal status: open title: ~/.pypirc created insecurely type: security versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10364] IDLE: make .py default added extension on save
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10364 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11870] test_3_join_in_forked_from_thread() of test_threading hangs 1 hour on x86 Ubuntu Shared 3.x
STINNER Victor victor.stin...@haypocalc.com added the comment: Gregory's patches to sanitize threading's lock should have fixed this The subprocess hang still occurs something, it just happened: http://www.python.org/dev/buildbot/all/builders/x86%20Ubuntu%20Shared%203.x/builds/4898/steps/test/logs/stdio [110/363] test_threading Timeout (1:00:00)! Thread 0x404888c0: File /srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py, line 1513 in _communicate_with_poll File /srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py, line 1438 in _communicate File /srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py, line 850 in communicate File /srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/script_helper.py, line 32 in _assert_python File /srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/script_helper.py, line 50 in assert_python_ok File /srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py, line 441 in _run_and_join File /srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_threading.py, line 497 in test_3_join_in_forked_from_thread ... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13512] ~/.pypirc created insecurely
Philip Jenvey pjen...@underboss.org added the comment: Something along these lines (untested) should do it. 2.6 and 3.x need the fix as well -- keywords: +patch nosy: +pjenvey Added file: http://bugs.python.org/file23824/pypirc-secure.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13512] ~/.pypirc created insecurely
Philip Jenvey pjen...@underboss.org added the comment: It probably still needs to catch OSErrors which my patch doesn't do -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13097] ctypes: segfault with large number of callback arguments
Meador Inge mead...@gmail.com added the comment: On Wed, Nov 30, 2011 at 6:20 AM, Amaury Forgeot d'Arc rep...@bugs.python.org wrote: Right, alloca() could be replaced by some malloc(), but is it really useful? After all, when a C function calls back to Python, all arguments needs to be pushed to the stack anyway. The case is somewhat pathological. However, there are *four* 'alloca' calls in '_ctypes_callproc', three of which are proportional to 'argcount'. And as you point out there is an additional stack allocation inside of 'libffi' when the callback is actually called (also using 'alloca'). I see two reasons switching to 'malloc' might be beneficial: (1) by shifting some of the allocation to dynamic allocation we may reduce the chance that we blow the stack at all. Keep in mind that this gets more likely if the C ffi function is called from a deep in a call tree and *not* necessarily with just a huge number of parameters. (2) if resources are exhausted, then we can exit more gracefully. Out of dynamic memory errors can actually be handled as opposed to an 'alloca' call that ends up allocating more than is left. That being said, if this does get changed it is low priority. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13097 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13097] ctypes: segfault with large number of callback arguments
Changes by Meador Inge mead...@gmail.com: -- priority: normal - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13097 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13513] IOBase docs incorrectly link to the GNU readline module
New submission from Meador Inge mead...@gmail.com: The current IOBase documentation [1] reads: IOBase (and its subclasses) support the iterator protocol, meaning that an IOBase object can be iterated over yielding the lines in a stream. Lines are defined slightly differently depending on whether the stream is a binary stream (yielding bytes), or a text stream (yielding character strings). See readline() below. Currently the 'readline' link in the last sentence is linking to the GNU readline interface, which is wrong. Patch attached. [1] http://docs.python.org/dev/library/io.html?highlight=readlines#io.IOBase -- assignee: docs@python components: Documentation files: IOBase.readline-doc.patch keywords: patch messages: 148702 nosy: docs@python, meador.inge priority: normal severity: normal stage: patch review status: open title: IOBase docs incorrectly link to the GNU readline module type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file23825/IOBase.readline-doc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13513 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13510] Clarify that readlines() is not needed to iterate over a file
Meador Inge mead...@gmail.com added the comment: I am skeptical that such a note will help. The iterator behavior is clearly pointed out in the Python Tutorial [1] and in the IOBase documentation [2]. I suspect this bad code pattern is just being copied and pasted from other sources without folks ever even looking at the Python documentation. [1] http://docs.python.org/dev/tutorial/inputoutput.html?highlight=readlines#methods-of-file-objects [2] http://docs.python.org/dev/library/io.html#io.IOBase -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13510] Clarify that readlines() is not needed to iterate over a file
Ezio Melotti ezio.melo...@gmail.com added the comment: FWIW I've seen several persons using for line in file.readlines(): ... or even while 1: line = file.readline(). IMHO it's a good idea to document that without sizehint, it's equivalent to list(file) and that for line in file: ... can be used directly. Even if some people don't read the doc, the ones who do will benefit from this. The same note might also be added to the docstring (I think it's somewhat common to learn about readlines() through dir(file) + help(file.readlines)). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13120] Default nosigint option to pdb.Pdb() prevents use in non-main thread
Meador Inge mead...@gmail.com added the comment: Ilya, I agree. Thanks for the test patch. These two patches look OK to me. Georg OK with you? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13514] PIL does not support iTXt PNG chunks [patch]
New submission from Paul Sladen pyt...@paul.sladen.org: The Python Imaging Library does not support handling of UTF-8 'iTXt' key:value chunks in PNG files: http://www.w3.org/TR/PNG/#11iTXt Such support is necessary for successful extraction of key:value pairs of UTF-8 encoded data, stored in an PNG 'iTXt' comment chunk. The following example file (from British GCHQ) demonstrates such a record in a PNG file. Based on this evidence, it is highly likely that GCHQ hide all of their important secrets using this kind of steganography, and likely necessary that spies from the rest of the world are requiring similar access to GCHQ secrets. Inclusion of a working chunk_iTXt() PIL/PNG support function will enable more harmonious and effective eavesdropping. Example image: http://www.canyoucrackit.co.uk/images/cyber.png (The attached .py file is not a directly apply-able patch, but contains a working implementation for chunk_iTXt() and a demonstrative test function for inserting it). -- components: Installation files: chunk_iTXt.py messages: 148706 nosy: sladen priority: normal severity: normal status: open title: PIL does not support iTXt PNG chunks [patch] type: feature request Added file: http://bugs.python.org/file23826/chunk_iTXt.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13514 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13514] PIL does not support iTXt PNG chunks [patch]
Ezio Melotti ezio.melo...@gmail.com added the comment: You should report this to the PIL bug tracker. PIL is not part of the Python standard library. -- nosy: +ezio.melotti resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13514 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13514] PIL does not support iTXt PNG chunks [patch]
Paul Sladen pyt...@paul.sladen.org added the comment: Thank you Ezio. I could not see a separate bug tracker listed on: http://www.pythonware.com/products/pil/ could you help me by providing a link to where it /should/ be filed correctly for PIL itself. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13514 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13514] PIL does not support iTXt PNG chunks [patch]
Ezio Melotti ezio.melo...@gmail.com added the comment: You could try submitting your patch to the image-sig ML (http://mail.python.org/mailman/listinfo/image-sig). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13514 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13515] Consistent documentation practices for security concerns and considerations
New submission from Nick Coghlan ncogh...@gmail.com: This issue proposes that we adopt and apply some standard practices when documenting modules that have potential security implications and other cross-cutting errors that may affect multiple interfaces within the module. Accordingly, the main target is the Documenting Python meta-docs, proposing the addition of a new subsection to the Style Guide, with an update to the subprocess module documentation serving as the exemplar of a new recommended style: == 2.6 Security Considerations (and Other Concerns) Some modules provided with Python are inherently exposed to security issues (e.g. shell injection vulnerabilities) due to the purpose of the module (e.g. subprocess invocation). Littering the documentation of these modules with red warning boxes for problems that are due to the task at hand, rather than specifically to Python's support for that task, doesn't make for a good reading experience. Instead, these security concerns should be gathered into a dedicated Security Considerations section within the module's documentation, and cross-referenced from the documentation of affected interfaces with in-line text similar to Please refer to the :ref:`security-considerations` section for important information on how to avoid common mistakes. Similarly, if there is a common error that affects many interfaces in a module (e.g. OS level pipe buffers filling up and stalling child processes), these can be documented in a Common Errors section and cross-referenced rather than repeated for every affected interface. == (based on the thread at http://mail.python.org/pipermail/python-dev/2011-December/114717.html) -- assignee: docs@python components: Documentation messages: 148710 nosy: docs@python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Consistent documentation practices for security concerns and considerations ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
