[issue6836] Mismatching use of memory APIs

[Tim Peters]

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

___
___
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]

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 tracker 

___
___
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]

Mark Dickinson  added the comment:

Thanks.  Fixed in revisions r74677 through r74680.

--
nosy: +marketdickinson
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
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]

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/rejected
status: open -> closed

___
Python tracker 

___
___
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]

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_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 

___
___
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]

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

___
___
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]

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 

___
___
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]

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 not ported to Python 3 yet.

--
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
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]

Ronald Oussoren  added the comment:

I found an easier way to test with a 64-bit Tcl/Tk: run Snow Leopard ;-)

--

___
Python tracker 

___
___
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]

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:  -> committed/rejected
status: open -> closed
versions: +Python 2.7

___
Python tracker 

___
___
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]

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 

___
___
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]

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

___
___
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]

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 

___
___
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]

Joshua Root  added the comment:

Tried again after ensuring that ~/test was completely empty; no 
difference.

--

___
Python tracker 

___
___
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]

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

___
___
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]

Joshua Root  added the comment:

Should line 110 of Lib/plat-mac/macresource.py say 'isinstance' rather 
than 'instance'?

--

___
Python tracker 

___
___
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]

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 

___
___
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]

Ronald Oussoren  added the comment:

You're right. I've fixed this in r74686.

--

___
Python tracker 

___
___
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]

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 -> closed

___
Python tracker 

___
___
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]

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 

___
___
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]

Joshua Root  added the comment:

It works now. Thanks!

--

___
Python tracker 

___
___
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]

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

___
___
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]

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 

___
___
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]

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 

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

[Ronald Oussoren]

Changes by Ronald Oussoren :


--
nosy:  -ronaldoussoren

___
Python tracker 

___
___
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]

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.

--

___
Python tracker 

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

[Ronald Oussoren]

Changes by Ronald Oussoren :


--
nosy:  -ronaldoussoren

___
Python tracker 

___
___
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]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6849] Tutorial changes

[Michael Foord]

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

___
___
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 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 machine; I'm not
sure if that's too much.

--
Added file: http://bugs.python.org/file14847/testzip-patch2.diff

___
Python tracker 

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

___
___
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]

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

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

___
___
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]

Changes by Brett Cannon :


--
nosy: +brett.cannon

___
Python tracker 

___
___
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]

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_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 

___
___
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]

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 /Library/Frameworks

* Tk-Cocoa

--

___
Python tracker 

___
___
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]

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

___
___
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]

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 for Python and the architectures supported 
by Tk.framework.

--
keywords: +patch
Added file: http://bugs.python.org/file14848/setup-tk-archs.patch

___
Python tracker 

___
___
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]

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

___
___
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]

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 behavior of Tk-Carbon if a Cocoa 
build is not detected.

--

___
Python tracker 

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

[Ronald Oussoren]

Changes by Ronald Oussoren :


--
stage:  -> needs patch

___
Python tracker 

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

___
___
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]

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 

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

[Stefan Krah]

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__
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 ' 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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6849] Tutorial changes

[Michael Foord]

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) 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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6849] Tutorial changes

[Michael Foord]

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 

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

[Pablo Mouzo]

Changes by Pablo Mouzo :


--
nosy: +facundobatista

___
Python tracker 

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

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee:  -> marketdickinson
nosy: +marketdickinson

___
Python tracker 

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

[jweber]

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

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

[loveminix]

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/python3
# -*- coding: utf-8 -*-

print(
"""\
Content-type: text/html
"""
);

print(
"""\
http://www.w3.org/TR/html4/strict.dtd";>




\
"""
);

print("");
print("中文");
print("");

print(
"""\

\
"""
);

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

___
___
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)

[lplatypus]

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

___
___
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()

[loveminix]

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", "");
serverName = os.environ.get("SERVER_NAME", "");
scriptName = os.environ.get("SCRIPT_NAME", "");

if pathInfo == "":
print(
"""\
Content-type: text/html
"""
);
print(
"""\
http://www.w3.org/TR/html4/strict.dtd";>






http://{0}{1}/upload";
enctype="multipart/form-data" method="post">







\
""".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(
"""\
http://www.w3.org/TR/html4/strict.dtd";>






Success


\
"""
);

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

___
___
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]

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, 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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6855] ihooks support for relative imports

[Neil Schemenauer]

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
priority: normal
severity: normal
stage: patch review
status: open
title: ihooks support for relative imports
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14852/ihooks_relimport.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com