[issue6855] ihooks support for relative imports

New submission from Neil Schemenauer : ihooks in 2.6 does not support relative imports. The attached patch was impired by Brett's "import in Python" code. -- assignee: brett.cannon components: Library (Lib) files: ihooks_relimport.txt messages: 92345 nosy: brett.cannon, nascheme priorit

[issue6802] build fails on Snow Leopard

Bryan Blackburn added the comment: The patch has one issue in the added AC_TRY_RUN ( http://svn.python.org/view/python/trunk/configure.in? annotate=74672&pathrev=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, In

[issue6854] UnicodeDecodeError when retrieving binary data from cgi.FieldStorage()

New submission from loveminix : 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", ""

[issue6853] system proxy not used for https (on windows)

New submission from lplatypus : 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

[issue6852] Unicode IO not working in cgi applet

New submission from loveminix : 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 "...", right before the Unicode string "中文". #! /usr/bin/pyt

[issue6851] urllib.urlopen crashes in a thread on Snow Leopard

New submission from jweber : 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

[issue6850] decimal.py: format_dict['type'] not initialized

Changes by Benjamin Peterson : -- assignee: -> marketdickinson nosy: +marketdickinson ___ Python tracker ___ ___ Python-bugs-list mail

[issue6845] ftplib rest support for storbinary

Changes by Pablo Mouzo : -- nosy: +facundobatista ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue6849] Tutorial changes

Michael Foord 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 ___

[issue6849] Tutorial changes

Michael Foord 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) an

[issue6850] decimal.py: format_dict['type'] not initialized

New submission from Stefan Krah : 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 "", line 1, in File "/usr/lib/python3.1/decimal.py", line 3611, in __format__ sp

[issue6848] curses module build failure (ncurses 5.7)

Mark Dickinson 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

[issue6839] zipfile can't extract file

Alan McIntyre 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

[issue1584] Mac OS X: building with X11 Tkinter

Changes by Ronald Oussoren : -- stage: -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue6075] Patch for IDLE/OS X to work with Tk-Cocoa

Kevin Walzer 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 beh

[issue6441] Tkinter cannot find *64 bit* Tcl/Tk on Mac OS X

Ronald Oussoren 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 f

[issue6075] Patch for IDLE/OS X to work with Tk-Cocoa

Ronald Oussoren 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 /

[issue6848] curses module build failure (ncurses 5.7)

Brett Cannon added the comment: On Sun, Sep 6, 2009 at 13:35, Mark Dickinson wrote: > > Mark Dickinson 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

[issue6839] zipfile can't extract file

Ronald Oussoren 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 wou

[issue6848] curses module build failure (ncurses 5.7)

Mark Dickinson 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_O

[issue6848] curses module build failure (ncurses 5.7)

Changes by Brett Cannon : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Marcin Stepnicki 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

[issue6836] Mismatching use of memory APIs

Kristján Valur Jónsson 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

[issue6839] zipfile can't extract file

Alan McIntyre 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 i

[issue1739648] zipfile.testzip() using progressive file reads

Alan McIntyre 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 ma

[issue6849] Tutorial changes

New submission from Michael Foord : 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 ma

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

Changes by Ronald Oussoren : -- nosy: -ronaldoussoren ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue1502517] crash in expat when compiling with --enable-profiling

Ronald Oussoren 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. -- __

[issue1445781] install fails on hard link

Changes by Ronald Oussoren : -- nosy: -ronaldoussoren ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue6393] OS X: python3 from python-3.1.dmg crashes at startup

Ronald Oussoren 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 ___

[issue734115] Packaging without disturbing an existing installation

Ronald Oussoren 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

[issue1467201] size_t warnings on OSX 10.3

Ronald Oussoren 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

[issue2276] distutils out-of-date for runtime_library_dirs flag on OS X

Ronald Oussoren 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 t

[issue6802] build fails on Snow Leopard

Joshua Root added the comment: It works now. Thanks! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue1738250] Universal MacPython 2.5.1 installation fails

Ronald Oussoren 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

[issue2740] Cmd module doesn't support readline completion on OSX Leopard

Ronald Oussoren 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 -

[issue6802] build fails on Snow Leopard

Ronald Oussoren added the comment: You're right. I've fixed this in r74686. -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue6802] build fails on Snow Leopard

Mark Dickinson 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

[issue6802] build fails on Snow Leopard

Joshua Root added the comment: Should line 110 of Lib/plat-mac/macresource.py say 'isinstance' rather than 'instance'? -- ___ Python tracker ___

[issue6848] curses module build failure (ncurses 5.7)

New submission from Mark Dickinson : 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

[issue6802] build fails on Snow Leopard

Joshua Root added the comment: Tried again after ensuring that ~/test was completely empty; no difference. -- ___ Python tracker ___

[issue6802] build fails on Snow Leopard

Ronald Oussoren 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

[issue6839] zipfile can't extract file

Ronald Oussoren 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 nam

[issue6802] build fails on Snow Leopard

Joshua Root 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

[issue4937] Mac DMG install missing version.plist required by bundlebuilder.py

Ronald Oussoren 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: -> committ

[issue6441] Tkinter cannot find *64 bit* Tcl/Tk on Mac OS X

Ronald Oussoren added the comment: I found an easier way to test with a 64-bit Tcl/Tk: run Snow Leopard ;-) -- ___ Python tracker ___

[issue6552] Build Applet.app

Ronald Oussoren 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 n

[issue5514] Darwin framework libpython3.0.a is not a normal static library

Ronald Oussoren 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

[issue6812] Snow Leopard python program fails because _PyType_Modified is missing from python framework

Ronald Oussoren 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

[issue6245] Add "intel" universal architecture on OSX

Ronald Oussoren 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

[issue6802] build fails on Snow Leopard

Ronald Oussoren 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/

[issue6847] Exception strings for bytearray say "bytes"

Mark Dickinson added the comment: Thanks. Fixed in revisions r74677 through r74680. -- nosy: +marketdickinson resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker _

[issue6846] bytearray.pop() returns negative ints

Mark Dickinson 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

[issue6836] Mismatching use of memory APIs

Tim Peters 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 t