[issue6836] Mismatching use of memory APIs
Tim Peters tim.pet...@gmail.com added the comment: Yup, it's a good idea. In fact, storing info in the debug malloc blocks to identify the API family used was part of the plan, but got dropped when time ran out. serialno should not be abused for this purpose, though. On a 32-bit box, a 24-bit real serialno is too small. Mucking with serialno also breaks the current straightforward use of data breakpoints (under systems that support those) to rerun a deterministic program until a specific value for serialno is reached. The original intent was to use one of forbidden pad bytes for this purpose, either the last one following the block or the first one preceding the block. That wouldn't interfere with anything, and the code would be substantially simpler (no endless shifting and masking needed when a byte's worth of data is stored /in/ a byte). In any case, internal comments must document the possible values for the id and their meanings. It's just plain cruel to make the code reader leap all over the code trying to reverse-engineer the intent ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6836 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6846] bytearray.pop() returns negative ints
Mark Dickinson dicki...@gmail.com added the comment: Fixed in r74673 (trunk), r74674 (release26-maint), r74675 (py3k) and r74676 (release31-maint). Thanks! -- nosy: +marketdickinson resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6847] Exception strings for bytearray say bytes
Mark Dickinson dicki...@gmail.com added the comment: Thanks. Fixed in revisions r74677 through r74680. -- nosy: +marketdickinson resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6802] build fails on Snow Leopard
Ronald Oussoren ronaldousso...@mac.com added the comment: Fixed in r74672 (trunk), r74681 (2.6), r74682 (3.x) and r74683 (3.1) With the default configure flags you'll end up with a 64-bit build of Python on Snow Leopard, including a 64-bit copy of IDLE. -- resolution: accepted - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6245] Add intel universal architecture on OSX
Ronald Oussoren ronaldousso...@mac.com added the comment: I've attached a new patch arch-intel-v2.patch that relects my current thinking about this patch. This adds two new options to the --with-univeral-archs option for configure: intel and 3-way. The former builds a universal binary with the i386 and x86_64 architectures, the latter builds one with the i386, x86_64 and ppc architectures. The intel build is most useful when your code only needs to run on modernish systems, the latter allows you to run scripts on PPC systems as well. Both can be build on Snow Leopard systems. The current options all and 64-bit cannot be used when you perform your build and target the default SDK because the system doesn't ship with PPC64 suppport anymore. I intend to apply this patch for 2.7 and 3.2 unless there is serious opposition against this. The patch will not be backported to earlier versions. -- Added file: http://bugs.python.org/file14845/arch-intel-v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6812] Snow Leopard python program fails because _PyType_Modified is missing from python framework
Ronald Oussoren ronaldousso...@mac.com added the comment: This seems to be a problem with Apple's copy of Python or with your machine. Could you try the following: * In terminal.app run /usr/bin/python * Then use 'import objc' from Python's prompt. * Does this work or does it give the same traceback (it works for me BTW). If importing objc from Python's prompt works: Try to do a clean build of the application in Xcode (use Clean All and then perform a build). -- resolution: - invalid ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5514] Darwin framework libpython3.0.a is not a normal static library
Ronald Oussoren ronaldousso...@mac.com added the comment: I'm closing this issue because the user does not respond to my questions and because I don't agree there is a problem. -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5514 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6552] Build Applet.app
Ronald Oussoren ronaldousso...@mac.com added the comment: Build Applet is not present in Python 3 because the implementation uses Python modules that aren't present in Python 3 (in particular the long deprecated Carbon bindings). The best alternative to the Build Applet functionality is py2app, but that is sadly not ported to Python 3 yet. -- resolution: - wont fix stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6552 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6441] Tkinter cannot find *64 bit* Tcl/Tk on Mac OS X
Ronald Oussoren ronaldousso...@mac.com added the comment: I found an easier way to test with a 64-bit Tcl/Tk: run Snow Leopard ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4937] Mac DMG install missing version.plist required by bundlebuilder.py
Ronald Oussoren ronaldousso...@mac.com added the comment: This will be fixed in the next release of 2.6 and 2.7: bundlebuilder shouldn't have tried to copy version.plist in the first place. The actual revisions in which this was fixed: r74684 (trunk), r74685 (2.6) -- resolution: - fixed stage: - committed/rejected status: open - closed versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4937 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6802] build fails on Snow Leopard
Joshua Root josh+pyt...@root.id.au added the comment: I tried release26-maint just now (r74683) and it errored out during make install. New log attached. -- Added file: http://bugs.python.org/file14846/release26-maint.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6839] zipfile can't extract file
Ronald Oussoren ronaldousso...@mac.com added the comment: The zipfile is technically incorrect, the zipfile specification prescribes that all filenames use '/' as the directory separator. Even without that caveat the file is corrupt because the zipfile directory header and the per-file header don't agree on the name of the file. That said: IMHO the current code in zipfile.ZipFile.open is too strict, it shouldn't raise an error when the two names aren't exactly the same because there are valid reasons for them to be different (such as renaming a file in the zipfile without rewriting the entire zipfile). -- nosy: +ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6802] build fails on Snow Leopard
Ronald Oussoren ronaldousso...@mac.com added the comment: Could you retry the build after cleaning the target directory? I've seem simular failures in the past and haven't been able to find the root cause of that problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6802] build fails on Snow Leopard
Joshua Root josh+pyt...@root.id.au added the comment: Tried again after ensuring that ~/test was completely empty; no difference. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6848] curses module build failure (ncurses 5.7)
New submission from Mark Dickinson dicki...@gmail.com: There seems to be a problem building the curses module on systems with ncurses 5.7. The following output was produced on OS X 10.6, on a trunk build; I'm not sure whether this problem is Mac-specific (or 64-bit specific). building '_curses' extension gcc -fno-strict-aliasing -g -Wall -Wstrict-prototypes - I/Users/dickinsm/python/svn/trunk/Mac/Include -I. -I./Include -IInclude -I/Users/dickinsm/python/svn/trunk -c /Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c -o build/temp.macosx-10.4-i386-2.7- pydebug/Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.o /Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function ‘PyCursesWindow_EchoChar’: /Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:805: error: dereferencing pointer to incomplete type /Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:812: warning: control reaches end of non-void function /Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function ‘PyCursesWindow_NoOutRefresh’: /Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1230: error: dereferencing pointer to incomplete type /Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1261: warning: control reaches end of non-void function /Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function ‘PyCursesWindow_Refresh’: /Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1372: error: dereferencing pointer to incomplete type /Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1402: warning: control reaches end of non-void function /Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c: In function ‘PyCursesWindow_SubWin’: /Users/dickinsm/python/svn/trunk/Modules/_cursesmodule.c:1438: error: dereferencing pointer to incomplete type Here's a relevant excerpt from _cursesmodule.c (lines 804--811) #ifdef WINDOW_HAS_FLAGS if (self-win-_flags _ISPAD) return PyCursesCheckERR(pechochar(self-win, ch | attr), echochar); else #endif return PyCursesCheckERR(wechochar(self-win, ch | attr), echochar); Here self-win has type WINDOW; the problem is that as of ncurses 5.7, the internals of the WINDOW type (and much else besides) are deliberately hidden (by default) from users of the library; there's a preprocessor constant NCURSES_OPAQUE that controls this. So an obvious workaround is to set NCURSES_OPAQUE=0 somewhere in the Python build process; however, that may be the wrong thing to do if the ncurses developers are planning to mess with the ncurses internals in the near future (which would explain the NCURSES_OPAQUE business). I don't know whether there's some alternative 'official' way to distinguish between ncurses windows and pads. -- components: Build messages: 92312 nosy: marketdickinson severity: normal status: open title: curses module build failure (ncurses 5.7) versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6848 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6802] build fails on Snow Leopard
Joshua Root josh+pyt...@root.id.au added the comment: Should line 110 of Lib/plat-mac/macresource.py say 'isinstance' rather than 'instance'? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6802] build fails on Snow Leopard
Mark Dickinson dicki...@gmail.com added the comment: Looks like there's a spurious comma in line 110 of lib/plat- mac/macresource.py in the release26-maint branch: if instance(arg, AttributeError), or arg[0] in (-37, -39): -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6802] build fails on Snow Leopard
Ronald Oussoren ronaldousso...@mac.com added the comment: You're right. I've fixed this in r74686. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2740] Cmd module doesn't support readline completion on OSX Leopard
Ronald Oussoren ronaldousso...@mac.com added the comment: As mentioned before I'm closing this as won't fix because this is an issue with Apple's copy of Python, not the one shipped by us (the generic Python tree doesn't even compile correctly when using libedit) -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2740 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738250] Universal MacPython 2.5.1 installation fails
Ronald Oussoren ronaldousso...@mac.com added the comment: Closing this bug as it is for an old version of Python and I cannot reproduce this issue. -- resolution: - works for me status: open - closed versions: +Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1738250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6802] build fails on Snow Leopard
Joshua Root josh+pyt...@root.id.au added the comment: It works now. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2276] distutils out-of-date for runtime_library_dirs flag on OS X
Ronald Oussoren ronaldousso...@mac.com added the comment: Could you provide an example that shows why adding support for the -rpath option on OSX would be useful? (As in a set of source files that shows how this support would be used). As I mentioned before the OSX support for -rpath behaves completely different than that on Linux, and I'd expect that adding runline_library_dirs_option support for OSX would cause confusion because of that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2276 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1467201] size_t warnings on OSX 10.3
Ronald Oussoren ronaldousso...@mac.com added the comment: The warning does not occur on recent versions of OSX (10.5, 10.6), therefore closing the issue. -- nosy: +ronaldoussoren resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1467201 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue734115] Packaging without disturbing an existing installation
Ronald Oussoren ronaldousso...@mac.com added the comment: Closing this issue, the patch is no longer needed because the current Makefiles already have DESTDIR support. -- resolution: - out of date stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue734115 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1445781] install fails on hard link
Changes by Ronald Oussoren ronaldousso...@mac.com: -- nosy: -ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1445781 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1502517] crash in expat when compiling with --enable-profiling
Ronald Oussoren ronaldousso...@mac.com added the comment: This is no longer a problem with 2.6.x from SVN and Xcode 3.2 (on OSX 10.6). I haven't tested if the problem is still present on other versions of OSX, but I'd say it is pretty safe to assume that this was a toolchain problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1502517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1677] Ctrl-C will exit out of Python interpreter in Windows
Changes by Ronald Oussoren ronaldousso...@mac.com: -- nosy: -ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1677 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6393] OS X: python3 from python-3.1.dmg crashes at startup
Ronald Oussoren ronaldousso...@mac.com added the comment: I've applied the fixed version of my patch in r74687 (3.x) and r74688 (3.1). -- resolution: - fixed stage: - committed/rejected status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6849] Tutorial changes
New submission from Michael Foord mich...@voidspace.org.uk: There are a couple of minor changes I'd like to make to the tutorial. Section 6.1 introduces the import * syntax without noting that it is bad practise. I'd like to add the following text: The import * form is generally considered to be bad practise as it makes it hard to tell where the names you use in your code come from, *and* you can accidentally overwrite names if you import something that is already defined elsewhere. It can still be useful when working in the console. Section 6.4.1 uses Windows 95 and DOS 8+3 as the reason that importing from packages doesn't automatically import all sub-packages. This is out of date and not the most compelling reasoning anyway. I'd like to replace that text with: Perhaps this should go out to the filesystem, find which submodules are present in the package, and import them all. This could take a long time and importing sub-modules might have unwanted side-effects that should only happen when the sub-module is explicitly imported. -- assignee: michael.foord components: Documentation keywords: easy messages: 92324 nosy: michael.foord severity: normal status: open title: Tutorial changes versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6849 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1739648] zipfile.testzip() using progressive file reads
Alan McIntyre alan.mcint...@gmail.com added the comment: Attached is a patch that makes the zipfile module check the result of testzip when run as __main__ as well as in test_zipfile.py, and adds some tests in test_zipfile64.py. The changes to test_zipfile64.py increased its runtime from ~671 sec to ~1060 sec on my machine; I'm not sure if that's too much. -- Added file: http://bugs.python.org/file14847/testzip-patch2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1739648 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6839] zipfile can't extract file
Alan McIntyre alan.mcint...@gmail.com added the comment: FileRoller doesn't complain about the mismatched slashes either. Where did the ZIP come from, by the way? I seem to recall that there have been other instances in which ZIP applications were more forgiving than the zipfile module. How far should zipfile go in bending the interpretation of the ZIP standard? As far as the renaming goes, it seems the standard says the header name should be used if the two names are different. If nobody else has time to make a patch and tests I can take a stab at it in the next few days. -- nosy: +alanmcintyre ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6836] Mismatching use of memory APIs
Kristján Valur Jónsson krist...@ccpgames.com added the comment: Good point, Tim. I'll rework it so that one of the border bytes is used, since it needs to be a known value anyway. That should make things less messy. Although resoning about the breakpoint is probably incorrect since you would put the breakpoint on the serialno global variable, and not on the location in each memory block. Meanwhile, does anyone have anything to say about my suggested bugfix? I'm not familiar enough with the parser to know if there may be a performance penaltly in copying the string here, or whether we ought to try to widen the use of the PyObject_ api to skirt the issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6836 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked
Marcin Stepnicki marcin.stepni...@haibane.pl added the comment: I have just got bitten by this bug - I usually run my software under Linux/Windows, this was the first time that my customer requested specifically FreeBSD platform and I was *really* surprised. Not to mention the fact that bug in Python came as the last thing to my mind - I was blaming my code of course :-). Anyway, I can confirm the patch works for me and I'd like to see it included in future versions. Can I do something to make it happen? Regards, Marcin -- nosy: +mstepnicki ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1975 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6848] curses module build failure (ncurses 5.7)
Changes by Brett Cannon br...@python.org: -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6848 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6848] curses module build failure (ncurses 5.7)
Mark Dickinson dicki...@gmail.com added the comment: I asked on the ncurses-bugs mailing list about this problem, and got an immediate and helpful reply from the ncurses maintainer (Thomas Dickey). It turns out that this *is* a Mac-specific problem: in Snow Leopard the Apple-supplied ncurses.h defines NCURSES_OPAQUE to 1 (if it isn't already defined) by default, while a standard ncurses install defines NCURSES_OPAQUE to be 0 by default. Furthermore, Thomas Dickey has said that he'll add an is_pad function for later use, so if the WINDOW flags do disappear or move in a future version of ncurses then there should be an easy workaround available at that time. So just #defining NCURSES_OPAQUE to 0 for OS X = 10.6 seems a reasonable way to fix this for now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6848 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
Ronald Oussoren ronaldousso...@mac.com added the comment: The patches look acceptable on first glance. Which configurations of Tk have you tested? IMHO IDLE should work with the following configurations: * Tk.framework as supplied with OSX 10.4, 10.5 and 10.6 * The current releases of Tk 8.4 and 8.5 installed in /Library/Frameworks * Tk-Cocoa -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6848] curses module build failure (ncurses 5.7)
Brett Cannon br...@python.org added the comment: On Sun, Sep 6, 2009 at 13:35, Mark Dickinsonrep...@bugs.python.org wrote: Mark Dickinson dicki...@gmail.com added the comment: I asked on the ncurses-bugs mailing list about this problem, and got an immediate and helpful reply from the ncurses maintainer (Thomas Dickey). It turns out that this *is* a Mac-specific problem: in Snow Leopard the Apple-supplied ncurses.h defines NCURSES_OPAQUE to 1 (if it isn't already defined) by default, while a standard ncurses install defines NCURSES_OPAQUE to be 0 by default. Furthermore, Thomas Dickey has said that he'll add an is_pad function for later use, so if the WINDOW flags do disappear or move in a future version of ncurses then there should be an easy workaround available at that time. So just #defining NCURSES_OPAQUE to 0 for OS X = 10.6 seems a reasonable way to fix this for now. Seems reasonable to me as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6848 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6441] Tkinter cannot find *64 bit* Tcl/Tk on Mac OS X
Ronald Oussoren ronaldousso...@mac.com added the comment: The (untested) attached patch (setup-tk-archs.patch) updates the code in setup.py to automaticly detect the architectures that are supported by the Tk framework and passes '-arch' flags to the compiler for the intersection of the configured architectures for Python and the architectures supported by Tk.framework. -- keywords: +patch Added file: http://bugs.python.org/file14848/setup-tk-archs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6839] zipfile can't extract file
Ronald Oussoren ronaldousso...@mac.com added the comment: alan: I don't quite understand which filename you want to use when the name in the per-file header and the central directory don't match. Where in the standard is this prescribed? I couldn't find anything in the PKWare zipfile appnote [1] My preference would be to use the central directory as the canonical value because scanning the entire zipfile to read the per-file header would give a significant overhead. This might not be very noticable with small zipfiles, but I regularly use zipfiles with over 100K files in them in those files a scan of the zipfile is prohibitively expensive. Furthermore, when the two are different the most reasonably explaination is that an in-place edit of the zipfile changed the directory without rewriting the entire zipfile (just like you can delete files from a zipfile by dumping them from the directory rather than completely rewriting the entire archive) [1] APPNOTE.TXT - .ZIP File Format Specification Version: 6.3.2 Revised: September 28, 2007 Copyright (c) 1989 - 2007 PKWARE Inc., All Rights Reserved. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6075] Patch for IDLE/OS X to work with Tk-Cocoa
Kevin Walzer wordt...@users.sourceforge.net added the comment: Tested against Tk-Cocoa (the build of Tk-8.5 that comes with Snow Leopard; I also have my own build on Leopard) and Tk-Carbon 8.5 on Leopard/10.5, and it works as expected. I no longer have any builds of 8.4 to test against. The code defaults to the current behavior of Tk-Carbon if a Cocoa build is not detected. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1584] Mac OS X: building with X11 Tkinter
Changes by Ronald Oussoren ronaldousso...@mac.com: -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1584 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6839] zipfile can't extract file
Alan McIntyre alan.mcint...@gmail.com added the comment: Sorry about the confusion--I think I confused myself by looking at the bit about CRC checksums in the Info-ZIP Unicode Path Extra Field section before I posted. I meant to say that the central directory name looks preferred over the per-file header. n section J, under file name (Variable) there's a bit that says: If input came from standard input, there is no file name field. If encrypting the central directory and general purpose bit flag 13 is set indicating masking, the file name stored in the Local Header will not be the actual file name. A masking value consisting of a unique hexadecimal value will be stored. So in these cases the central directory name has to be used. And, as you pointed out, some operations like deleting a member from the archive are implemented by editing the central directory, so it would seem that the central directory should be used if there's a conflict. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6848] curses module build failure (ncurses 5.7)
Mark Dickinson dicki...@gmail.com added the comment: Fixed in r74693, r74694, r74696, r74697. -- resolution: - fixed stage: - committed/rejected status: open - closed versions: +Python 2.6, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6848 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6850] decimal.py: format_dict['type'] not initialized
New submission from Stefan Krah stefan-use...@bytereef.org: Hi, it looks like format_dict['type'] is not always initialized: from decimal import * format(Decimal(0.12345), a=-7.0) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python3.1/decimal.py, line 3611, in __format__ spec = _parse_format_specifier(specifier, _localeconv=_localeconv) File /usr/lib/python3.1/decimal.py, line 5595, in _parse_format_specifier if format_dict['type'] in 'gG' or format_dict['type'] is None: TypeError: 'in string' requires string as left operand, not NoneType Inserting these two lines somewhere in _parse_format_specifier fixes the problem. (float() uses 'g' as the default, but I got the impression that decimal.py uses uppercase as the default.) if format_dict['type'] is None: format_dict['type'] = 'G' -- messages: 92337 nosy: skrah severity: normal status: open title: decimal.py: format_dict['type'] not initialized versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6849] Tutorial changes
Michael Foord mich...@voidspace.org.uk added the comment: In addition section 8.3 of the tutorial references the .message attribute which is now deprecated. But use of .args is discouraged. Instead, the preferred use is to pass a single argument to an exception (which can be a tuple if multiple arguments are needed) and have it bound to the message attribute. One may also instantiate an exception first before raising it and add any attributes to it as desired. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6849 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6849] Tutorial changes
Michael Foord mich...@voidspace.org.uk added the comment: The TransitionError defined in section 8.5 of the tutorial has a 'message' argument / attribute that will raise a DeprecationWarning in Python 2.6. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6849 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6845] ftplib rest support for storbinary
Changes by Pablo Mouzo pablomo...@gmail.com: -- nosy: +facundobatista ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6850] decimal.py: format_dict['type'] not initialized
Changes by Benjamin Peterson benja...@python.org: -- assignee: - marketdickinson nosy: +marketdickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6851] urllib.urlopen crashes in a thread on Snow Leopard
New submission from jweber ja...@jacobweber.com: The following program works fine under Mac OS 10.5.x. But in 10.6, it crashes Python, and displays Apple's crash reporter dialog. I've tried it on Python 2.6 and 2.5, both the 64-bit and 32-bit versions. The crash seems to happen any time urllib.urlopen is done in a thread. The same thing happens if I do it in a BaseHTTPServer.HTTPServer, using SocketServer.ThreadingMixIn. #!/usr/bin/python import threading, urllib class MyThread (threading.Thread): def run(self): c = urllib.urlopen(http://www.google.com;) MyThread().start() -- assignee: ronaldoussoren components: Macintosh files: crash_log.txt messages: 92340 nosy: jweber, ronaldoussoren severity: normal status: open title: urllib.urlopen crashes in a thread on Snow Leopard type: crash versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file14849/crash_log.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6851 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6852] Unicode IO not working in cgi applet
New submission from loveminix lovemi...@yahoo.com.cn: The following cgi applet does output Unicode string correctly in an Ubuntu terminal, but when invoked from a web browser (IE or Firefox) by a client, it doesn't output the Unicode string. Output stops at ...divp, right before the Unicode string 中文. #! /usr/bin/python3 # -*- coding: utf-8 -*- print( \ Content-type: text/html ); print( \ !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd; html head meta http-equiv=Content-type content=text/html;charset=UTF-8 /head body\ ); print(divp); print(中文); print(/p/div); print( \ /body /html\ ); -- components: Unicode messages: 92341 nosy: loveminix severity: normal status: open title: Unicode IO not working in cgi applet type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6852 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6853] system proxy not used for https (on windows)
New submission from lplatypus l...@deller.id.au: On Windows, the urllib2 module (renamed to urllib.request in python 3) does not use the system web proxy for https URLs in the case where Use the same proxy for all protocols is selected in the Internet Explorer proxy settings. Attached is a patch against urllib/request.py in python 3.1.1 -- components: Library (Lib) files: urllib-httpsproxy.patch keywords: patch messages: 92342 nosy: ldeller severity: normal status: open title: system proxy not used for https (on windows) type: behavior versions: Python 2.6, Python 3.1 Added file: http://bugs.python.org/file14850/urllib-httpsproxy.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6853 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6854] UnicodeDecodeError when retrieving binary data from cgi.FieldStorage()
New submission from loveminix lovemi...@yahoo.com.cn:
The following cgi applet uploads a binary file to the server. It gets a
UnicodeDecodeError inside cgi.FieldStorage(). The same code works in
python 2.6.
#! /usr/bin/python3
import os, cgi;
import cgitb; cgitb.enable();
pathInfo = os.environ.get(PATH_INFO, );
serverName = os.environ.get(SERVER_NAME, );
scriptName = os.environ.get(SCRIPT_NAME, );
if pathInfo == :
print(
\
Content-type: text/html
);
print(
\
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN
http://www.w3.org/TR/html4/strict.dtd;
html
head
meta http-equiv=Content-type content=text/html;charset=UTF-8
/head
body
div
form action=http://{0}{1}/upload;
enctype=multipart/form-data method=post
p
input type=file name=filebr
input type=submit value=Upload
/p
/form
/div
/body
/html\
.format(serverName, scriptName)
);
elif pathInfo == /upload:
fieldStorage = cgi.FieldStorage();
fileItem = fieldStorage[file];
if fileItem.filename != :
file = open(/tmp/test.txt, mode=wb);
file.write(fileItem.file.read());
file.close();
print(
\
Content-type: text/html
);
print(
\
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN
http://www.w3.org/TR/html4/strict.dtd;
html
head
meta http-equiv=Content-type content=text/html;charset=UTF-8
/head
body
div
pSuccess/p
/div
/body
/html\
);
--
components: Library (Lib)
messages: 92343
nosy: loveminix
severity: normal
status: open
title: UnicodeDecodeError when retrieving binary data from cgi.FieldStorage()
type: behavior
versions: Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6854
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6802] build fails on Snow Leopard
Bryan Blackburn b...@users.sourceforge.net added the comment: The patch has one issue in the added AC_TRY_RUN ( http://svn.python.org/view/python/trunk/configure.in? annotate=74672pathrev=74672#l1542 ): it doesn't like the two [[...]] and main() needs a closing brace, }. Otherwise, it fails on 10.5.8 (Xcode 3.1.3, Intel) to properly detect 32bit vs 64bit (and if you look at config.log you should see complaints from around line 7065). Attaching a patch which fixes it here. -- Added file: http://bugs.python.org/file14851/configure.in.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6802 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
