[ python-Bugs-1673757 ] string and unicode formatting are missing a test for "G"

2007-07-12 Thread SourceForge.net 
Bugs item #1673757, was opened at 2007-03-05 02:34
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Eric V. Smith (ericvsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: string and unicode formatting are missing a test for "G"

Initial Comment:
In stringobject.c and unicodeobject.c, the formatting codes for 'e', 'E', 'f', 
'F', 'g', and 'G' all get routed to formatfloat().  formatfloat() is 
essentially identical in stringobject.c and unicodeobject.c.

'F' is mapped to 'f'.  There is a test for excess precision for 'f' and 'g', 
but not one for 'G'.

The "type == 'g'" test should be "(type == 'g' || type == 'G')".

I assume this bug is in 2.5 and 2.6 as well, although I haven't verified that, 
yet.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-12 08:38

Message:
Logged In: YES 
user_id=849994
Originator: NO

Patch was committed.

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2007-03-18 03:58

Message:
Logged In: YES 
user_id=6380
Originator: NO

Changing the group to 2.5; see the patch (http://python.org/sf/1673759)
for an explanation.

--

Comment By: Eric V. Smith (ericvsmith)
Date: 2007-03-06 11:10

Message:
Logged In: YES 
user_id=411198
Originator: YES

The patch was corrected, and tests added.

--

Comment By: Eric V. Smith (ericvsmith)
Date: 2007-03-06 10:57

Message:
Logged In: YES 
user_id=411198
Originator: YES

Yes, my bad on not having tests and the diff being fubar.  I've already
started writing the tests, I should be done in the next 30 minutes.  Expect
a new patch.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2007-03-06 10:55

Message:
Logged In: YES 
user_id=1038590
Originator: NO

Behaviour is definitely present in the current 2.6 trunk, so I expect it
to be present in the 2.5 maintenance branch too.

On platforms which provide a correct implementation of vsnprintf, this
won't cause a buffer overflow (but can give an incorrect result). As far as
I can tell, the limited precision of C doubles saves you on platforms
without vsnprintf (then again, I may not be abusing it correctly after
forcing my dev tree to use the vsnprintf emulation, or else the behaviour
of the emulation may vary with platform vagaries in vsprintf
implementations).

The patch doesn't currently apply cleanly - it needs to be regenerated
using svn diff from the main python directory so that the filenames are
correct.

We also need a test case to make sure the problem never comes back (the
string tests are a little confusing though, since the same tests are used
for str, unicode & UserString).






--

Comment By: Eric V. Smith (ericvsmith)
Date: 2007-03-05 02:47

Message:
Logged In: YES 
user_id=411198
Originator: YES

Patch for 3.0 is at http://python.org/sf/1673759

This should be checked in 2.5 and 2.6, but I don't have an environment to
compile those.

--

Comment By: Eric V. Smith (ericvsmith)
Date: 2007-03-05 02:42

Message:
Logged In: YES 
user_id=411198
Originator: YES

This is the correct behavior:
>>> '%200.200g' % 1.0
Traceback (most recent call last):
  File "", line 1, in ?
OverflowError: formatted float is too long (precision too large?)

But 'G' is handled differently:
>>> '%200.200G' % 1.0
' 
   
 1'

'G' should give the same OverflowError as 'g'.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673757&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Feature Requests-1637365 ] if __name__=='__main__' missing in tutorial

2007-07-12 Thread SourceForge.net 
Feature Requests item #1637365, was opened at 2007-01-17 05:11
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1637365&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Gabriel Genellina (gagenellina)
Assigned to: Nobody/Anonymous (nobody)
Summary: if __name__=='__main__' missing in tutorial

Initial Comment:
I could not find any reference to the big idiom:

if __name__=="__main__":
xxx()

inside the Python tutorial. Of course it is documented in the Library Reference 
and the Reference Manual, but such an important idiom should be on the Tutorial 
for beginners to see.

I can't provide a patch, and English is not my native language, but I think a 
short text like the following would suffice (in section More on Modules, before 
the paragraph "Modules can import other modules..."):


Sometimes it is convenient to invoke a module as it were a script, either for 
testing purposes, or to provide a convenient user interfase to the functions 
contained in the module. But you don't want to run such code when the module is 
imported into another program, only when it's used as a standalone script. The 
way of differentiate both cases is checking the \code{__name__} attribute: as 
seen on the previous section, it usually holds the module name, but when the 
module is invoked directly, it's always \samp{__main__} regardless of the 
script name.

Add this at the end of \file{fibo.py}:

\begin{verbatim}
if __name__=="__main__":
import sys
fib(int(sys.argv[1]))
\end{verbatim}

and then you can execute it using:

\begin{verbatim}
python fibo.py 50
1 1 2 3 5 8 13 21 34
\end{verbatim}



--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-12 09:38

Message:
Logged In: YES 
user_id=849994
Originator: NO

Added a section about this in rev. 56306, 56307 (2.5).

--

Comment By: Bj�rn Lindqvist (sonderblade)
Date: 2007-07-10 11:10

Message:
Logged In: YES 
user_id=51702
Originator: NO

I just ran into this "problem" today, when teaching someone python. It is
definitely a glaring omission and needs to be fixed.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1637365&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1700865 ] PCbuild8/pcbuild.sln is missing "_socket" sub-project

2007-07-12 Thread SourceForge.net 
Bugs item #1700865, was opened at 2007-04-15 03:51
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1700865&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.6
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Raghuram Devarakonda (draghuram)
Assigned to: Kristj�n Valur (krisvale)
Summary: PCbuild8/pcbuild.sln is missing "_socket" sub-project

Initial Comment:

As the subject says, PCbuild8/pcbuild.sln is missing entry for "_socket". 
However, _socket.vcproj is present in the directory.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-07-12 10:06

Message:
Logged In: YES 
user_id=849994
Originator: NO

This was fixed with rev. 55024.

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-04-16 04:48

Message:
Logged In: YES 
user_id=21627
Originator: NO

Kristjan, can you take a look?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1700865&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1666952 ] terminalcommand doesn't work under Darwin

2007-07-12 Thread SourceForge.net 
Bugs item #1666952, was opened at 2007-02-23 11:29
Message generated for change (Comment added) made by jneb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666952&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jurjen N.E. Bos (jneb)
Assigned to: Jack Jansen (jackjansen)
Summary: terminalcommand doesn't work under Darwin

Initial Comment:
The "terminalcommand" library doesn't work under Darwin. It raises an obscure 
AppleScript error that I can't figure out.
I made a tiny library that gives roughly the same API, but starts applications 
fine under Darwin (10.2 and up). It works using the osascript command, but Jack 
can probably get it too work using OSA directly :-)
Quotes, spaces and backslashes are handled properly.
I would recommend to extend terminalcommand to incorporate this code in the 
Darwin case, assuming that you still want to support OS9.


--

>Comment By: Jurjen N.E. Bos (jneb)
Date: 2007-07-12 12:29

Message:
Logged In: YES 
user_id=446428
Originator: YES

It is an Intel MacBook Pro. I though I ran 10.4.9 at the time, but I guess
that is not an issue.


--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-12 07:38

Message:
Logged In: YES 
user_id=580910
Originator: NO

Are you using an Intel or PPC mac?

--

Comment By: Jurjen N.E. Bos (jneb)
Date: 2007-02-23 11:31

Message:
Logged In: YES 
user_id=446428
Originator: YES

O yes: forgot to mention:
The bug is for Mac only, any version of Python, OS X and up.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1666952&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1627952 ] plat-mac videoreader.py auido format info

2007-07-12 Thread SourceForge.net 
Bugs item #1627952, was opened at 2007-01-04 17:18
Message generated for change (Settings changed) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627952&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ryan Owen (ryaowe)
>Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: plat-mac videoreader.py auido format info

Initial Comment:
videoreader.py in the plat-mac modules has a small bug that breaks 
reader.GetAudioFormat()

--- videoreader.py  Thu Jan 04 09:05:16 2007
+++ videoreader_fixed.pyThu Jan 04 09:05:11 2007
@@ -13,7 +13,7 @@ from Carbon import Qdoffs
 from Carbon import QDOffscreen
 from Carbon import Res
 try:
-import MediaDescr
+from Carbon import MediaDescr
 except ImportError:
 def _audiodescr(data):
 return None


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627952&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1752539 ] RotatingFileHandler.doRollover behave wrong vs. log4j's

2007-07-12 Thread SourceForge.net 
Bugs item #1752539, was opened at 2007-07-12 18:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1752539&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jin Qing (jinq0123)
Assigned to: Nobody/Anonymous (nobody)
Summary: RotatingFileHandler.doRollover behave wrong vs. log4j's

Initial Comment:
RotatingFileHandler.doRollover() will raise exception on rename() and cause all 
the subsequent log messages lost.

But log4j is better. It ignore the rename() error and reset the log file.

I read "[ 979252 ] Trap OSError when calling RotatingFileHandler.doRollover ( 
https://sourceforge.net/tracker/index.php?func=detail&aid=979252&group_id=5470&atid=105470
 )", and think David London (groodude)'s solution is closer to log4j.

At least, python logging implementation should follow log4j's behavior, or 
improve it, such as only discard the current one message. 

logging should be easy to use.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1752539&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1581906 ] test_sqlite fails on OSX G5 arch if test_ctypes is run

2007-07-12 Thread SourceForge.net 
Bugs item #1581906, was opened at 2006-10-21 20:02
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1581906&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Skip Montanaro (montanaro)
Assigned to: Thomas Heller (theller)
Summary: test_sqlite fails on OSX G5 arch if test_ctypes is run

Initial Comment:
I noticed a test_sqlite test failure on my Mac G5 the other day while trying 
to set up a buildbot for sqlalchemy.  Everything runs fine on my G4 
powerbook.  Both machines run Mac OSX 10.4.8 with Apple's gcc 4.0.0, 
build 5026.

I whittled the problem down to just having test_ctypes and test_sqlite 
enabled, then further whittled it down to just having Lib/ctypes/test/
test_find.py available (all other ctypes tests eliminated).  More detailed 
problem descriptions are in these two postings to python-dev:

http://article.gmane.org/gmane.comp.python.devel/84478
http://article.gmane.org/gmane.comp.python.devel/84481

Skip


--

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-12 12:41

Message:
Logged In: YES 
user_id=580910
Originator: NO

This certainly sounds like someone is fooling around with the
-force_flat_namespace link flag, which could result in picking up the wrong
version of symbols. I haven't checked yet if this is indeed the case here,
and if so who is doing this.

--

Comment By: Skip Montanaro (montanaro)
Date: 2007-07-05 03:31

Message:
Logged In: YES 
user_id=44345
Originator: YES

Certainly the patch is simpler. ;-)  If loading GLUT doesn't add any value
on OSX, would it add any value on other platforms?  Do other tests have to
find libraries successfully to pass?  If so, maybe test_find should be
dispensed with altogether, however if test_find has value we should figure
out a library to load on OSX.

--

Comment By: Thomas Heller (theller)
Date: 2007-07-04 22:01

Message:
Logged In: YES 
user_id=11105
Originator: NO

Skip, thanks for the analysis and test patch.

IMO loading the GLUT library does not add significant value to the ctypes
tests, so wouldn't it be best to skip the GLUT lib on OSX?  See the
attached patch "test_find without GLUT on OSX" (note that I didn't actually
test the patch, and I don't have access to OSX G5 anyway).

Maybe the problem and the analysis should be reported to the PyOpenGL
project...
File Added: test_find-no-osx-glut.diff

--

Comment By: Skip Montanaro (montanaro)
Date: 2007-06-30 15:17

Message:
Logged In: YES 
user_id=44345
Originator: YES

Thomas,

Here's a possible modification to ctypes.test.test_find which appears
to be the only place that OpenGL (and thus CoreData on the Mac?) is
accessed.  On Darwin I replace the GL find stuff with Tcl find stuff.
It's a bit ugly, but it might solve the problem.

Skip

File Added: test_find.diff

--

Comment By: Skip Montanaro (montanaro)
Date: 2007-06-30 13:15

Message:
Logged In: YES 
user_id=44345
Originator: YES

I submitted a bug report to Apple about the problem, though I don't
really expect a response.  (The other bug I filed in 2004 has never
received any response as far as I can tell.)  Maybe a more recent
version of SQLite will be delivered with Leopard...


--

Comment By: Skip Montanaro (montanaro)
Date: 2007-06-30 12:42

Message:
Logged In: YES 
user_id=44345
Originator: YES

I'll be damned...  Based on your last response I ran Python
under ktrace then looked at the kdump output.  As it's
marching along it sees a mention of /usr/lib/libsqlite3.so
in /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
then just a few lines later I see

 20023 python   NAMI  "/usr/lib/libsqlite3.0.dylib"
 20023 python   RET   open 3
 20023 python   CALL  fstat(0x3,0xbfffc770)
 20023 python   RET   fstat 0
 20023 python   CALL  pread(0x3,0xbfffcbd0,0x1000,0)

then a bit later I see what I had wanted to see:

 20023 python   NAMI 
"/Users/skip/local/lib/python2.6/lib-dynload/_sqlite3.so"
 20023 python   RET   open 6
 20023 python   CALL  fstat(0x6,0xbfff9c00)
 20023 python   RET   fstat 0
 20023 python   CALL  pread(0x6,0xbfffa060,0x1000,0)
 ...
 20023 python   NAMI  "/Users/skip/local/lib/libsqlite3.0.dylib"
 20023 python   RET   open 6
 20023 python   CALL  fstat(0x6,0xbfff99b0)
 20023 python   RET   fstat 0
 20023 python   CALL  pread(0x6,0xbfff9

[ python-Bugs-1619130 ] 64-bit Universal Binary build broken

2007-07-12 Thread SourceForge.net 
Bugs item #1619130, was opened at 2006-12-20 00:22
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.6
Status: Open
>Resolution: Accepted
>Priority: 3
Private: No
Submitted By: Thomas Treadway (treadway)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: 64-bit Universal Binary build broken

Initial Comment:
Hi,
I'm running into problem building a 4-way universal binary of python.
The following has cropped up on both python2.5 and python2.4.2

The configure goes OK, but the make bombs.
[2244]$  ./configure --prefix=$VISITPATH/python OPT="-fast -Wall \
-Wstrict-prototypes -fno-common -fPIC \
-isysroot /Developer/SDKs/MacOSX10.4u.sdk \
-arch ppc -arch i386 -arch ppc64 -arch x86_64" \
LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\
-headerpad_max_install_names -arch ppc -arch i386 \
-arch ppc64 -arch x86_64"

. . .
[2245]$ make
gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd 
-DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64  
-I. -I./Include   -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
In file included from ./Include/Python.h:57In file included from 
./Include/Python.h:57,
 from ./Modules/python.c:3:
./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for 
platform (bad gcc/glibc config?)."
,
 from ./Modules/python.c:3:
./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for 
platform (bad gcc/glibc config?)."
lipo: can't figure out the architecture type of: /var/tmp//ccL3Ewl4.out
make: *** [Modules/python.o] Error 1

Comenting out the "#error" statement in pyport.h get me a little further
befor getting:
gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd 
-DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64  
-I. -I./Include   -DPy_BUILD_CORE -o Python/mactoolboxglue.o 
Python/mactoolboxglue.c
In file included from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32,
 from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125,
  . . .
 from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20,
 from ./Include/pymactoolbox.h:10,
 from Python/mactoolboxglue.c:27:
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1338:
 error: 'SIGDIGLEN' undeclared here (not in a function)
lipo: can't figure out the architecture type of: /var/tmp//ccEYbpTz.out
make: *** [Python/mactoolboxglue.o] Error 1

Seem Carbon doesn't support 64-bits!
Is there a solution?
   trt
--
Thomas R. Treadway
Computer Scientist
Lawrence Livermore Nat'l Lab
7000 East Avenue, L-159
Livermore, CA 94550-0611


--

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-12 17:32

Message:
Logged In: YES 
user_id=580910
Originator: NO

I now have a fairly clear strategy for the C bits. I will upload a patch
when I have a complete working solution (including testing). I can't test
right now because I'm at EuroPython and don't have access to a PPC64
machine from here.

An overview of the changes:
- Introduce a new header file: Include/pymacconfig.h

   This header file does compile-time detection of a number of variables
(such a VA_ARG_IS_LIST and SIZEOF_VOID_P) that are no longer configure-time
constants but only compile-time ones. This also surpressed the toolbox glue
feature macro in 64-bit mode.

- Patch setup.py to avoid compiling the Carbon wrappers and the toolbox
glue in 64-bit mode, while still compiling them in 32-bit mode when
building a 32-bit/64-bit hybrid.

- mactoolboxglue.c contains some Carbon code outside of the block that's
guarded by the feature macro. Also disable that.

Python with these patches still builds and passes the test suite, both in
32-bit and 64-bit mode and with --enable-toolboxglue.

I hope to prepare a patch with a full solution when I get back from
Europython. 

NOTE: More work is needed once Leopard is released because the promised
features of that include 64-bit support throughout the systems. Some of
that work is non-trivial (see http://www.python.org/sf/779153).

--

[ python-Bugs-1752723 ] email.message_from_string: initial line gets discarded

2007-07-12 Thread SourceForge.net 
Bugs item #1752723, was opened at 2007-07-12 10:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1752723&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Webster (dwebster99)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.message_from_string: initial line gets discarded

Initial Comment:
If the first line of the string passed to email.message_from_string starts with 
whitespace, the line gets discarded. I believe the problem is in the feed 
parser, but I don't have a test case to prove that. 

The attached file is a short program to illustrate the problem. When I run it I 
get the output shown below. The line count should be unchanged in both cases. 

leading whitespace :
Body changed: lines in: 3  lines out: 2
left justified :
Line count was preserved.

Platform:
  Python 2.5.1
  Windows 2000 SP4



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1752723&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-758565 ] IDE needs to remember status of interactive window

2007-07-12 Thread SourceForge.net 
Bugs item #758565, was opened at 2003-06-22 00:14
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758565&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Jack Jansen (jackjansen)
Assigned to: Just van Rossum (jvr)
Summary: IDE needs to remember status of interactive window

Initial Comment:
the IDE needs to remember the status of the interactive 
window (open/closed) between runs, and when started for 
the very first time it needs to open that window.

--

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-12 17:56

Message:
Logged In: YES 
user_id=580910
Originator: NO

Closing because the IDE that's mentioned here is no longer part of the
python distribution.

--

Comment By: Just van Rossum (jvr)
Date: 2003-06-22 14:31

Message:
Logged In: YES 
user_id=92689

Hm, the IDE always used to do just that. No time right now, will 
investigate later. Feel free to assign to me.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758565&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1724366 ] cPickle module doesn't work with universal line endings

2007-07-12 Thread SourceForge.net 
Bugs item #1724366, was opened at 2007-05-23 18:42
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Geoffrey Bache (gjb1002)
Assigned to: Jack Jansen (jackjansen)
Summary: cPickle module doesn't work with universal line endings

Initial Comment:
On UNIX, I cannot read pickle files created on Windows using the cPickle 
module, even if I open the file with universal line endings.

It works fine with the pickle module but is of course slower (and I have to 
read lots of them)

I attach a test case that pickles and unpickles an smptlib.SMTP object, 
converting the file to DOS format in between. There is nothing special about 
SMTP, you can use any object at all in a different module. 

On my system (RHEL4 with Python 2.4.3) I get the following output:

portmoller : pickletest.py cPickle
unix2dos: converting file dump to DOS format ...
Traceback (most recent call last):
  File "pickletest.py", line 14, in ?
print load(readFile)
ImportError: No module named smtplib
portmoller : pickletest.py pickle
unix2dos: converting file dump to DOS format ...



--

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-12 18:24

Message:
Logged In: YES 
user_id=580910
Originator: NO

I can confirm that this is problem is present in python 2.5 (current svn)
running on osx 10.4.10. Given the code of cPickle it is rather amazing that
this script does work correctly on a linux system, as gagenellina noted
cPickle shortcuts reads from real file objects and completely ignores
universal newlines while doing so.

IMHO Fixing this requires replicating the universal newline code in
cPickle. 

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-05-29 07:14

Message:
Logged In: YES 
user_id=21627
Originator: NO

Jack, can you take a look? If not, please unassign.

--

Comment By: Geoffrey Bache (gjb1002)
Date: 2007-05-25 19:24

Message:
Logged In: YES 
user_id=769182
Originator: YES

Yes, I'm sure Python is trying to import "smtplib\r".

For various reasons I need to use protocol 0: not least because I use the
pickle files as test data and it's much easier to administer a load of text
files than a load of binary files.

I will experiment with reading the files in binary mode on Monday and get
back to you. My current workaround is to do loads(file.read()) instead of
load(file) which I guess is a performance penalty. Any idea whether this is
likely to be slower than just using the pickle module? (I haven't tested
this)


--

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 12:29

Message:
Logged In: YES 
user_id=479790
Originator: NO

The culprit is cPickle.c; it takes certain shortcuts for read() and
readline() depending on which type of file you pass in.
For a true file object, it uses its own implementation for those two
methods, ignoring the file mode.

But it appears that there is NO WAY universal line endings could work if
the pickle contains any unicode object. The pickle format for Unicode
quotes any \n but *not* \r so the unpickler cannot determine, when it sees
a "\r", if it is a MAC end-of-line or an embedded "\r".
So, the only safe end-of-line character for a pickle using protocol 0 is
"\n", and that means that the file must be written in binary mode.
(This may also indicate that you cannot read unicode objects with embedded
\r in a MAC using protocol 0, but I don't have a MAC to test it).

So, until this is fixed (either the module or the documentation), one
should forget about universal line endings and write all pickle files as
binary. (This way ALL lines end in \n and it should work fine on all
platforms)


--

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 11:04

Message:
Logged In: YES 
user_id=479790
Originator: NO

I don't see any "Attach" button...
Just add these lines near the top of the test script:

original__import = __import__
def myimport(name, *args):
  print "import",repr(name)
  return original__import(name,*args)
  #end myimport
__builtins__.__import__ = myimport


--

Comment By: Gabriel Genellina (gagenellina)
Date: 2007-05-25 11:00

Message:
Logged In: YES 
user_id=479790
Originator: NO

Please try again with this modified version. I think you will see that
Python is tr

[ python-Bugs-1619130 ] 64-bit Universal Binary build broken

2007-07-12 Thread SourceForge.net 
Bugs item #1619130, was opened at 2006-12-19 15:22
Message generated for change (Comment added) made by treadway
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.6
Status: Open
Resolution: Accepted
Priority: 3
Private: No
Submitted By: Thomas Treadway (treadway)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: 64-bit Universal Binary build broken

Initial Comment:
Hi,
I'm running into problem building a 4-way universal binary of python.
The following has cropped up on both python2.5 and python2.4.2

The configure goes OK, but the make bombs.
[2244]$  ./configure --prefix=$VISITPATH/python OPT="-fast -Wall \
-Wstrict-prototypes -fno-common -fPIC \
-isysroot /Developer/SDKs/MacOSX10.4u.sdk \
-arch ppc -arch i386 -arch ppc64 -arch x86_64" \
LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\
-headerpad_max_install_names -arch ppc -arch i386 \
-arch ppc64 -arch x86_64"

. . .
[2245]$ make
gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd 
-DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64  
-I. -I./Include   -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
In file included from ./Include/Python.h:57In file included from 
./Include/Python.h:57,
 from ./Modules/python.c:3:
./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for 
platform (bad gcc/glibc config?)."
,
 from ./Modules/python.c:3:
./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for 
platform (bad gcc/glibc config?)."
lipo: can't figure out the architecture type of: /var/tmp//ccL3Ewl4.out
make: *** [Modules/python.o] Error 1

Comenting out the "#error" statement in pyport.h get me a little further
befor getting:
gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd 
-DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64  
-I. -I./Include   -DPy_BUILD_CORE -o Python/mactoolboxglue.o 
Python/mactoolboxglue.c
In file included from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32,
 from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125,
  . . .
 from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20,
 from ./Include/pymactoolbox.h:10,
 from Python/mactoolboxglue.c:27:
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1338:
 error: 'SIGDIGLEN' undeclared here (not in a function)
lipo: can't figure out the architecture type of: /var/tmp//ccEYbpTz.out
make: *** [Python/mactoolboxglue.o] Error 1

Seem Carbon doesn't support 64-bits!
Is there a solution?
   trt
--
Thomas R. Treadway
Computer Scientist
Lawrence Livermore Nat'l Lab
7000 East Avenue, L-159
Livermore, CA 94550-0611


--

>Comment By: Thomas Treadway (treadway)
Date: 2007-07-12 09:25

Message:
Logged In: YES 
user_id=1541276
Originator: YES

Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard.


--

Comment By: Thomas Treadway (treadway)
Date: 2007-07-12 09:24

Message:
Logged In: YES 
user_id=1541276
Originator: YES

Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard.


--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-12 08:32

Message:
Logged In: YES 
user_id=580910
Originator: NO

I now have a fairly clear strategy for the C bits. I will upload a patch
when I have a complete working solution (including testing). I can't test
right now because I'm at EuroPython and don't have access to a PPC64
machine from here.

An overview of the changes:
- Introduce a new header file: Include/pymacconfig.h

   This header file does compile-time detection of a number of variables
(such a VA_ARG_IS_LIST and SIZEOF_VOID_P) that are no longer configure-time
constants but only compile-time ones. This also surpressed the toolbox glue
feature macro in 64-bit mode.

- Patch setup.py to avoid compiling the Carbon wrappers and the toolbox
glue in 64-bit mode, while still compiling them in 32-bit mode when
building a 32-bit/64-bit hybrid.

- mactoolboxglue.c contains some Carbon code outside of the block that's
guarded

[ python-Bugs-1619130 ] 64-bit Universal Binary build broken

2007-07-12 Thread SourceForge.net 
Bugs item #1619130, was opened at 2006-12-19 15:22
Message generated for change (Comment added) made by treadway
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.6
Status: Open
Resolution: Accepted
Priority: 3
Private: No
Submitted By: Thomas Treadway (treadway)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: 64-bit Universal Binary build broken

Initial Comment:
Hi,
I'm running into problem building a 4-way universal binary of python.
The following has cropped up on both python2.5 and python2.4.2

The configure goes OK, but the make bombs.
[2244]$  ./configure --prefix=$VISITPATH/python OPT="-fast -Wall \
-Wstrict-prototypes -fno-common -fPIC \
-isysroot /Developer/SDKs/MacOSX10.4u.sdk \
-arch ppc -arch i386 -arch ppc64 -arch x86_64" \
LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\
-headerpad_max_install_names -arch ppc -arch i386 \
-arch ppc64 -arch x86_64"

. . .
[2245]$ make
gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd 
-DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64  
-I. -I./Include   -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
In file included from ./Include/Python.h:57In file included from 
./Include/Python.h:57,
 from ./Modules/python.c:3:
./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for 
platform (bad gcc/glibc config?)."
,
 from ./Modules/python.c:3:
./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for 
platform (bad gcc/glibc config?)."
lipo: can't figure out the architecture type of: /var/tmp//ccL3Ewl4.out
make: *** [Modules/python.o] Error 1

Comenting out the "#error" statement in pyport.h get me a little further
befor getting:
gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd 
-DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64  
-I. -I./Include   -DPy_BUILD_CORE -o Python/mactoolboxglue.o 
Python/mactoolboxglue.c
In file included from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32,
 from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125,
  . . .
 from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20,
 from ./Include/pymactoolbox.h:10,
 from Python/mactoolboxglue.c:27:
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1338:
 error: 'SIGDIGLEN' undeclared here (not in a function)
lipo: can't figure out the architecture type of: /var/tmp//ccEYbpTz.out
make: *** [Python/mactoolboxglue.o] Error 1

Seem Carbon doesn't support 64-bits!
Is there a solution?
   trt
--
Thomas R. Treadway
Computer Scientist
Lawrence Livermore Nat'l Lab
7000 East Avenue, L-159
Livermore, CA 94550-0611


--

>Comment By: Thomas Treadway (treadway)
Date: 2007-07-12 09:24

Message:
Logged In: YES 
user_id=1541276
Originator: YES

Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard.


--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-12 08:32

Message:
Logged In: YES 
user_id=580910
Originator: NO

I now have a fairly clear strategy for the C bits. I will upload a patch
when I have a complete working solution (including testing). I can't test
right now because I'm at EuroPython and don't have access to a PPC64
machine from here.

An overview of the changes:
- Introduce a new header file: Include/pymacconfig.h

   This header file does compile-time detection of a number of variables
(such a VA_ARG_IS_LIST and SIZEOF_VOID_P) that are no longer configure-time
constants but only compile-time ones. This also surpressed the toolbox glue
feature macro in 64-bit mode.

- Patch setup.py to avoid compiling the Carbon wrappers and the toolbox
glue in 64-bit mode, while still compiling them in 32-bit mode when
building a 32-bit/64-bit hybrid.

- mactoolboxglue.c contains some Carbon code outside of the block that's
guarded by the feature macro. Also disable that.

Python with these patches still builds and passes the test suite, both in
32-bit and 64-bit mode and with --enable-toolboxglue.

I hope to prepare a patch with a full solution when I get back from
Europython. 

NOTE: More

[ python-Bugs-1619130 ] 64-bit Universal Binary build broken

2007-07-12 Thread SourceForge.net 
Bugs item #1619130, was opened at 2006-12-20 00:22
Message generated for change (Comment added) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.6
Status: Open
Resolution: Accepted
Priority: 3
Private: No
Submitted By: Thomas Treadway (treadway)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: 64-bit Universal Binary build broken

Initial Comment:
Hi,
I'm running into problem building a 4-way universal binary of python.
The following has cropped up on both python2.5 and python2.4.2

The configure goes OK, but the make bombs.
[2244]$  ./configure --prefix=$VISITPATH/python OPT="-fast -Wall \
-Wstrict-prototypes -fno-common -fPIC \
-isysroot /Developer/SDKs/MacOSX10.4u.sdk \
-arch ppc -arch i386 -arch ppc64 -arch x86_64" \
LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\
-headerpad_max_install_names -arch ppc -arch i386 \
-arch ppc64 -arch x86_64"

. . .
[2245]$ make
gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd 
-DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64  
-I. -I./Include   -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
In file included from ./Include/Python.h:57In file included from 
./Include/Python.h:57,
 from ./Modules/python.c:3:
./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for 
platform (bad gcc/glibc config?)."
,
 from ./Modules/python.c:3:
./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for 
platform (bad gcc/glibc config?)."
lipo: can't figure out the architecture type of: /var/tmp//ccL3Ewl4.out
make: *** [Modules/python.o] Error 1

Comenting out the "#error" statement in pyport.h get me a little further
befor getting:
gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd 
-DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64  
-I. -I./Include   -DPy_BUILD_CORE -o Python/mactoolboxglue.o 
Python/mactoolboxglue.c
In file included from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32,
 from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125,
  . . .
 from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20,
 from ./Include/pymactoolbox.h:10,
 from Python/mactoolboxglue.c:27:
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1338:
 error: 'SIGDIGLEN' undeclared here (not in a function)
lipo: can't figure out the architecture type of: /var/tmp//ccEYbpTz.out
make: *** [Python/mactoolboxglue.o] Error 1

Seem Carbon doesn't support 64-bits!
Is there a solution?
   trt
--
Thomas R. Treadway
Computer Scientist
Lawrence Livermore Nat'l Lab
7000 East Avenue, L-159
Livermore, CA 94550-0611


--

>Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-12 18:32

Message:
Logged In: YES 
user_id=580910
Originator: NO

treadway: do you have a reference to that?

BTW. I have (legal) access to Leopard prereleases, but these are under
NDA.

Anyway, if you're right that just means I won't have to do more work after
Leopard is released. We'll see...

--

Comment By: Thomas Treadway (treadway)
Date: 2007-07-12 18:25

Message:
Logged In: YES 
user_id=1541276
Originator: YES

Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard.


--

Comment By: Thomas Treadway (treadway)
Date: 2007-07-12 18:24

Message:
Logged In: YES 
user_id=1541276
Originator: YES

Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard.


--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-12 17:32

Message:
Logged In: YES 
user_id=580910
Originator: NO

I now have a fairly clear strategy for the C bits. I will upload a patch
when I have a complete working solution (including testing). I can't test
right now because I'm at EuroPython and don't have access to a PPC64
machine from here.

An overview of the changes:
- Introduce a new header file: Include/pymacconfig.h

   This header file does compile-time detection of a number of variables
(suc

[ python-Bugs-1619130 ] 64-bit Universal Binary build broken

2007-07-12 Thread SourceForge.net 
Bugs item #1619130, was opened at 2006-12-19 15:22
Message generated for change (Comment added) made by treadway
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619130&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.6
Status: Open
Resolution: Accepted
Priority: 3
Private: No
Submitted By: Thomas Treadway (treadway)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: 64-bit Universal Binary build broken

Initial Comment:
Hi,
I'm running into problem building a 4-way universal binary of python.
The following has cropped up on both python2.5 and python2.4.2

The configure goes OK, but the make bombs.
[2244]$  ./configure --prefix=$VISITPATH/python OPT="-fast -Wall \
-Wstrict-prototypes -fno-common -fPIC \
-isysroot /Developer/SDKs/MacOSX10.4u.sdk \
-arch ppc -arch i386 -arch ppc64 -arch x86_64" \
LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk,\
-headerpad_max_install_names -arch ppc -arch i386 \
-arch ppc64 -arch x86_64"

. . .
[2245]$ make
gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd 
-DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64  
-I. -I./Include   -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
In file included from ./Include/Python.h:57In file included from 
./Include/Python.h:57,
 from ./Modules/python.c:3:
./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for 
platform (bad gcc/glibc config?)."
,
 from ./Modules/python.c:3:
./Include/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for 
platform (bad gcc/glibc config?)."
lipo: can't figure out the architecture type of: /var/tmp//ccL3Ewl4.out
make: *** [Modules/python.o] Error 1

Comenting out the "#error" statement in pyport.h get me a little further
befor getting:
gcc -c -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd 
-DNDEBUG -fast -Wall -Wstrict-prototypes -fno-common -fPIC -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64  
-I. -I./Include   -DPy_BUILD_CORE -o Python/mactoolboxglue.o 
Python/mactoolboxglue.c
In file included from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/DriverServices.h:32,
 from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:125,
  . . .
 from 
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:20,
 from ./Include/pymactoolbox.h:10,
 from Python/mactoolboxglue.c:27:
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/fp.h:1338:
 error: 'SIGDIGLEN' undeclared here (not in a function)
lipo: can't figure out the architecture type of: /var/tmp//ccEYbpTz.out
make: *** [Python/mactoolboxglue.o] Error 1

Seem Carbon doesn't support 64-bits!
Is there a solution?
   trt
--
Thomas R. Treadway
Computer Scientist
Lawrence Livermore Nat'l Lab
7000 East Avenue, L-159
Livermore, CA 94550-0611


--

>Comment By: Thomas Treadway (treadway)
Date: 2007-07-12 10:56

Message:
Logged In: YES 
user_id=1541276
Originator: YES

I've seen a few references in mail list.
I believe Apple is keeping it quiet. Cocoa will be the only 64-bit GUI
At WWDC07.
It was alluded to at the Mac OS X State of the Union, then explicitly
stated by engineers in one of the sessions.
The anouncement up set quite a few developers.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2007-07-12 09:32

Message:
Logged In: YES 
user_id=580910
Originator: NO

treadway: do you have a reference to that?

BTW. I have (legal) access to Leopard prereleases, but these are under
NDA.

Anyway, if you're right that just means I won't have to do more work after
Leopard is released. We'll see...

--

Comment By: Thomas Treadway (treadway)
Date: 2007-07-12 09:25

Message:
Logged In: YES 
user_id=1541276
Originator: YES

Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard.


--

Comment By: Thomas Treadway (treadway)
Date: 2007-07-12 09:24

Message:
Logged In: YES 
user_id=1541276
Originator: YES

Heads up, Apple said they WILL NOT port Carbon to 64-bit on Leopard.


--

Comment By: Ronald Oussoren (ronaldoussoren)
Dat

[ python-Bugs-1752919 ] Exception in HTMLParser for special JavaScript code

2007-07-12 Thread SourceForge.net 
Bugs item #1752919, was opened at 2007-07-12 22:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1752919&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Eugine Kosenko (eugine_kosenko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exception in HTMLParser for special JavaScript code

Initial Comment:
import HTMLParser

p = HTMLParser.HTMLParser()
p.feed("""



""")

Traceback (most recent call last):
  File "", line 4, in ?
  File "/usr/lib/python2.4/HTMLParser.py", line 108, in feed
self.goahead(0)
  File "/usr/lib/python2.4/HTMLParser.py", line 150, in goahead
k = self.parse_endtag(i)
  File "/usr/lib/python2.4/HTMLParser.py", line 314, in parse_endtag
self.error("bad end tag: %r" % (rawdata[i:j],))
  File "/usr/lib/python2.4/HTMLParser.py", line 115, in error
raise HTMLParseError(message, self.getpos())
HTMLParser.HTMLParseError: bad end tag: "", at line 4, column 12

The JavaScript code is protected via HTML comment, so HTMLParser must skip it 
entirely, and the parsing must be successfull.

Instead of this, the JavaScript code is parsed as a part of the HTML page, and 
incorrect end tag is detected. If one move the actual end tag  up just 
after start tag

[issue1031] Datetime enhancements

2007-07-12 Thread Fred Flinstone 

New submission from Fred Flinstone:

Copy of issue 1665292

--
components: Library (Lib)
messages: 51803
nosy: FredFlinstone, tiran
severity: normal
status: open
title: Datetime enhancements
type: rfe
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[ python-Bugs-1752539 ] RotatingFileHandler.doRollover behave wrong vs. log4j's

2007-07-12 Thread SourceForge.net 
Bugs item #1752539, was opened at 2007-07-12 03:34
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1752539&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jin Qing (jinq0123)
>Assigned to: Vinay Sajip (vsajip)
Summary: RotatingFileHandler.doRollover behave wrong vs. log4j's

Initial Comment:
RotatingFileHandler.doRollover() will raise exception on rename() and cause all 
the subsequent log messages lost.

But log4j is better. It ignore the rename() error and reset the log file.

I read "[ 979252 ] Trap OSError when calling RotatingFileHandler.doRollover ( 
https://sourceforge.net/tracker/index.php?func=detail&aid=979252&group_id=5470&atid=105470
 )", and think David London (groodude)'s solution is closer to log4j.

At least, python logging implementation should follow log4j's behavior, or 
improve it, such as only discard the current one message. 

logging should be easy to use.

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-07-12 20:47

Message:
Logged In: YES 
user_id=33168
Originator: NO

Vinay, could you take a look?  Thanks.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1752539&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1752723 ] email.message_from_string: initial line gets discarded

2007-07-12 Thread SourceForge.net 
Bugs item #1752723, was opened at 2007-07-12 08:52
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1752723&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Webster (dwebster99)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.message_from_string: initial line gets discarded

Initial Comment:
If the first line of the string passed to email.message_from_string starts with 
whitespace, the line gets discarded. I believe the problem is in the feed 
parser, but I don't have a test case to prove that. 

The attached file is a short program to illustrate the problem. When I run it I 
get the output shown below. The line count should be unchanged in both cases. 

leading whitespace :
Body changed: lines in: 3  lines out: 2
left justified :
Line count was preserved.

Platform:
  Python 2.5.1
  Windows 2000 SP4



--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-07-12 20:48

Message:
Logged In: YES 
user_id=33168
Originator: NO

Barry, could you take a look?  Thanks.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1752723&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com