[ python-Bugs-1476111 ] SystemError in socket sendto

2006-04-25 Thread SourceForge.net 
Bugs item #1476111, was opened at 2006-04-25 15:02
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=1476111&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
Submitted By: CyDefect (cydefect)
Assigned to: Nobody/Anonymous (nobody)
Summary: SystemError in socket sendto

Initial Comment:
A socket's sendto method can be tricked into a
SystemError exception. This happens with:

Linux special 2.4.29 #19 Thu Jan 27 20:51:25 CET 2005
i686 unknown
and
Python 2.4.2 (#2, Dec 27 2005, 11:06:14)

but:
Linux vesuv6 2.4.20-4GB #1 Mon Mar 17 17:54:44 UTC 2003
i686 unknown unknown GNU/Linux
Python 2.3.3 (#1, Jun 29 2004, 14:43:40)
[GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.

shows the same behaviour.

These 4 lines demonstrate the failure:
import socket
s = socket.socket( socket.PF_PACKET, socket.SOCK_RAW,
 socket.htons(
0x0003 ) )
s.sendto( "abc", 0, range( 6 ) )

yields:

Traceback (most recent call last):
  File "serr.py", line 7, in ?
s.sendto( "abc", 0, range( 6 ) )
SystemError: new style getargs format but argument is
not a tuple


HTH,
Gerald

--

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

[ python-Bugs-1433877 ] string parameter to ioctl not null terminated, includes fix

2006-04-25 Thread SourceForge.net 
Bugs item #1433877, was opened at 2006-02-17 23:29
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&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: Extension Modules
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Quentin Barnes (qbarnes)
>Assigned to: Thomas Wouters (twouters)
Summary: string parameter to ioctl not null terminated, includes fix

Initial Comment:
I ran across this problem in Python 2.3.3 and see it is
still there in 2.4.2.

When running the test_pty.py test case, I would get
intermittant failures depending on how the test was
invoked or the compiler flags used on Solaris. 
Trussing the interpreter while running the test revealed:
ioctl(4, I_PUSH, "ptem\xff^T^F^H")  Err#22 EINVAL

There was garbage on the end of the string when it
would fail.

I tracked the problem back to fcntl_ioctl() in
fcntlmodule.c.  The string was not being NULL
terminated, but relied on having zeroed gargage on the
stack to work.

I checked the source for 2.4.2 and noticed the same
problem.  Patch to fix the problem is attached.


--

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-25 15:59

Message:
Logged In: YES 
user_id=34209

Checked this in before 2.5 alpha2, after more contemplation.
Undid the circumventing of the test_pty problems, too.
Decided to explicitly set the terminating NUL after all,
instead of relying on the given buffer to have one (even
though it really should), and terminated the array in the
writable-buffer case, too (it may not matter, but it
certainly doesn't hurt, since we didn't end up copying any
data there in any case.) Thanks for figuring it out, Quentin.


--

Comment By: Thomas Wouters (twouters)
Date: 2006-04-12 16:52

Message:
Logged In: YES 
user_id=34209

Hrm. After giving this some thought, perhaps we should do

 memcpy(buf, str, len+1)

instead of

 memcpy(buf, str, len)
 buf[len] = '\0'

(And do this in the writable-buffer case as well, when we
use memcpy.) Other than that, I think this is the right fix.
Assigning to mwh for second (third? fourth?) opinion.


--

Comment By: Thomas Wouters (twouters)
Date: 2006-03-20 22:22

Message:
Logged In: YES 
user_id=34209

Huh, I never even saw this patch, in spite of the high
priority and it being assigned to me. 

We didn't discuss it at PyCon (at least, I wasn't party to
the discussion) but I guess this patch doesn't really hurt,
and does fix actual problems. I'm wary of fudging
fcntl/ioctl too much; I'd _much_ rather try and come up with
a decent interface for Py3k, with mutable bytestrings and
all that, maybe some nice automatic argument-type-conversion
or higher-level interface for common features (like advisory
locks) -- and only keep 2.x's fcntl working as well as it does.

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-20 21:52

Message:
Logged In: YES 
user_id=6380

mwh: Sorry about the docstring gripe -- I read the fcntl()
docstring which is right above the ioctl() implementation
and never realized that this particular C module places the
doc strings *after* the functions. (I think that's bad style
but there it is.)

I think the priority was set to 9 by Neal to get Thomas'
attention.

gbarnes: We'll decide this one at PyCon.

--

Comment By: Quentin Barnes (qbarnes)
Date: 2006-02-20 19:00

Message:
Logged In: YES 
user_id=288734

I didn't write new code that causes this problem by calling
ioctl with a string that needed to be null terminated.  It
was already in Python code itself.  See Lib/pty.py for the
code.

I reworked the patch as discussed below and retested it.
All built-in tests passed.

I've attached it.  I hae no idea of Python coding
conventions or style.  Hopefully I didn't violate them
too badly.

(This was weird.  SF rejected the text above when I
submitted it, but it took the patch file.  The patch
file shows up as "nobody".  Resubmitting this text.)

--

Comment By: Michael Hudson (mwh)
Date: 2006-02-20 11:54

Message:
Logged In: YES 
user_id=6656

Seeing as some of this is my code...

Guido, the ioctl docstring *does* mention mutate_arg.  I agree that the 
documentation should have been updated for 2.4 and 2.5... and the situation 
is a mess, yes, but one that I couldn't see a better way around when the 
feature was added (it was much discussed in the bug report at the time).

It certainly never occurred to me that y

[ python-Feature Requests-1476166 ] Add SeaMonkey to webbrowser.py

2006-04-25 Thread SourceForge.net 
Feature Requests item #1476166, was opened at 2006-04-25 18:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1476166&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Oleg Broytmann (phd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add SeaMonkey to webbrowser.py

Initial Comment:
Add SeaMonkey to webbrowser.py as yet another Mozilla
family browser. Just prepend "seamonkey" to the list
("mozilla-firefox", "firefox",
"mozilla-firebird",
"firebird",   
"mozilla", "netscape") in the
register_X_browsers().

--

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

[ python-Bugs-1476111 ] SystemError in socket sendto

2006-04-25 Thread SourceForge.net 
Bugs item #1476111, was opened at 2006-04-25 15:02
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476111&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: CyDefect (cydefect)
>Assigned to: Thomas Wouters (twouters)
Summary: SystemError in socket sendto

Initial Comment:
A socket's sendto method can be tricked into a
SystemError exception. This happens with:

Linux special 2.4.29 #19 Thu Jan 27 20:51:25 CET 2005
i686 unknown
and
Python 2.4.2 (#2, Dec 27 2005, 11:06:14)

but:
Linux vesuv6 2.4.20-4GB #1 Mon Mar 17 17:54:44 UTC 2003
i686 unknown unknown GNU/Linux
Python 2.3.3 (#1, Jun 29 2004, 14:43:40)
[GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.

shows the same behaviour.

These 4 lines demonstrate the failure:
import socket
s = socket.socket( socket.PF_PACKET, socket.SOCK_RAW,
 socket.htons(
0x0003 ) )
s.sendto( "abc", 0, range( 6 ) )

yields:

Traceback (most recent call last):
  File "serr.py", line 7, in ?
s.sendto( "abc", 0, range( 6 ) )
SystemError: new style getargs format but argument is
not a tuple


HTH,
Gerald

--

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-25 17:08

Message:
Logged In: YES 
user_id=34209

Well, 'tricked' is a bit of a big word; it just means you
passed the wrong type of address; AF_PACKET expects a tuple
(of string+int or int+int+string), and not a list. It didn't
have any ill effects (other than confusing the programmer.)
I fixed the errormessage for AF_PACKET (and AF_INET6, which
was also missing) in trunk revision 45714 (so it'll be in
2.5 alpha 2.) Thanks!





--

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

[ python-Bugs-1476216 ] Documentation date stuck on "5th April 2006"

2006-04-25 Thread SourceForge.net 
Bugs item #1476216, was opened at 2006-04-25 09:05
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=1476216&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: Open
Resolution: None
Priority: 5
Submitted By: Mat Martineau (martineau)
Assigned to: Nobody/Anonymous (nobody)
Summary: Documentation date stuck on "5th April 2006"

Initial Comment:
My builds of the python documentation from the SVN
trunk have been stuck on "5th April 2006" for several
weeks now.

I've traced this to r43589, which hard-coded the date
in boilerplate.tex - this seems unusual, because
boilerplate.tex was not modified in this way for any
previous releases.

Seems like "\date{5th April 2006}" should be changed
back to "\date{\today}".

For some reason, the documentation at
http://docs.python.org/dev/ shows the correct date.


Mat


--

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

[ python-Bugs-1437614 ] can't send files via ftp on my MacOS X 10.3.9

2006-04-25 Thread SourceForge.net 
Bugs item #1437614, was opened at 2006-02-23 13:48
Message generated for change (Settings changed) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437614&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.3
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Li Quid (liquid333)
Assigned to: Nobody/Anonymous (nobody)
Summary: can't send files via ftp on my MacOS X 10.3.9

Initial Comment:

When trying to do a simple ftp upload using Python
2.3's ftplib, it fails and I get a socket error.  The
exact error is (61, 'Connection refused').  This
happens to me in all my scripts that use the ftplib on
MacOS 10.3.9, but not in scripts on my Windows box. 
I've attached the small, simple source code.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-02 15:28

Message:
Logged In: YES 
user_id=580910

I use ftplib on OSX and don't see problems (both python 2.3 and 2.4 on OSX 
10.3 and 10.4). I agree with tjreedy that this is most likely a problem with 
the 
environment of the user.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-05 21:26

Message:
Logged In: YES 
user_id=593130

This could be a problem in your specific machine and its 
setup, the specific OS version, the specific target (maybe 
nyx doesn't like MACs), or the specific Python version.

I would start by installing 2.4.2 and see if there have 
maybe been helpful changes to its socket code.  And try to 
find another Mac box.  And then ask on python-
list/comp.lang.python for other experiences with Max, OSX, 
sockets, and maybe ftp.  Since the error message comes 
from the OS blaming nyx, I think more likely than not that 
this is not a Python bug.

--

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

[ python-Bugs-1476356 ] StringIO should implement __str__()

2006-04-25 Thread SourceForge.net 
Bugs item #1476356, was opened at 2006-04-25 16:11
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=1476356&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dom Lachowicz (cinamod)
Assigned to: Nobody/Anonymous (nobody)
Summary: StringIO should implement __str__()

Initial Comment:
I was a bit surprised when I discovered that StringIO
didn't have a __str__() method, equivalent to
getvalue(). Calling str(stringio_object) gives the
following:

>>> import StringIO
>>> s = StringIO.StringIO("hello world")
>>> print "%s" % (str(s))


I had some (perhaps dodgy code) code that did:

if isinstance(data, types.FileType):
  return data.read()
else:
  return str(data)

Since StringIO doesn't subclass any file type and
doesn't implement a __str__() method, I was getting
seemingly bogus results. This was trivially worked
around by adding another "isinstance(data,
StringIO.StringIO)" case, but it was surprising
nonetheless. Thanks.

--

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

[ python-Bugs-1471427 ] tarfile.py chokes on long names

2006-04-25 Thread SourceForge.net 
Bugs item #1471427, was opened at 2006-04-16 22:34
Message generated for change (Comment added) made by gustaebel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471427&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
Submitted By: Alexander Schremmer (alexanderweb)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.py chokes on long names

Initial Comment:
The following bug is reproducible on Py 2.4.3 and 2.5. 
It was tested on Windows. You need a tarfile with a 
long file name that triggers the GNU LONGNAME 
extension.

Extracting such a file gives me an IO error because it 
tries to create a file with a slash at the end. This is 
because 

# Some old tar programs represent a directory 
as a regular
# file with a trailing slash.
if tarinfo.isreg() and tarinfo.name.endswith("/
"):
tarinfo.type = DIRTYPE

sets the type incorrectly after it was called from the 
callback proc which has no possiblity to set the name 
of the intermediary tarinfo class because it is 
instantiated in the next-method.

So this yields a directory which should be a file which 
is obviously wrong. Might be related to commit 41340 
"Patch #1338314, Bug #1336623". (At least the code 
changed there is causing this bug).

--

Comment By: Lars Gustäbel (gustaebel)
Date: 2006-04-25 22:59

Message:
Logged In: YES 
user_id=642936

Fixing this issue is not quite as simple as I hoped it to
be. It would be possible to implement a quick fix that
solves the problem, but that would be too ugly for a stdlib
module. Instead, I have been busy writing a preliminary fix
for my development version of tarfile.py which is available
at http://www.gustaebel.de/lars/tarfile/.
It would be nice of you, if you'd download the 0.8.0 version
there and give it a try. Thank you.


--

Comment By: Alexander Schremmer (alexanderweb)
Date: 2006-04-16 22:34

Message:
Logged In: YES 
user_id=254738

Hmm, I just want to clarify that tarfile doesn't give the IO 
error (it passes silently) but my code that expects a file 
instead of a directory ;-)

--

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

[ python-Bugs-1476356 ] StringIO should implement __str__()

2006-04-25 Thread SourceForge.net 
Bugs item #1476356, was opened at 2006-04-25 15:11
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476356&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: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Dom Lachowicz (cinamod)
Assigned to: Nobody/Anonymous (nobody)
Summary: StringIO should implement __str__()

Initial Comment:
I was a bit surprised when I discovered that StringIO
didn't have a __str__() method, equivalent to
getvalue(). Calling str(stringio_object) gives the
following:

>>> import StringIO
>>> s = StringIO.StringIO("hello world")
>>> print "%s" % (str(s))


I had some (perhaps dodgy code) code that did:

if isinstance(data, types.FileType):
  return data.read()
else:
  return str(data)

Since StringIO doesn't subclass any file type and
doesn't implement a __str__() method, I was getting
seemingly bogus results. This was trivially worked
around by adding another "isinstance(data,
StringIO.StringIO)" case, but it was surprising
nonetheless. Thanks.

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-04-25 17:58

Message:
Logged In: YES 
user_id=80475

This isn't a bug.  The module is correctly emulating the API
for file objects.

I recommend replacing your isintance() test with a try/except:

try:
 return data.read()
except AttributeError:
 return str(data)



--

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

[ python-Bugs-1472695 ] 32/64bit pickled Random incompatiblity

2006-04-25 Thread SourceForge.net 
Bugs item #1472695, was opened at 2006-04-18 20:10
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&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
Submitted By: Peter Maxwell (pm67nz)
>Assigned to: Tim Peters (tim_one)
Summary: 32/64bit pickled Random incompatiblity

Initial Comment:
The unsigned long integers which make up the state of a Random 
instance are converted to Python integers via a cast to long in 
_randommodule.c's random_getstate function, so on a 32bit platform 
Random.getstate() returns a mix of postitive and negative integers, while 
on a 64bit platform the negative numbers are replaced by larger positive 
numbers, their 32bit-2s-complement equivalents.

As a result, unpicking a Random instance from a 64bit machine on a 32bit 
platform produces the error "OverflowError: long int too large to convert 
to int".  Unpickling a 32bit Random on a 64bit machine succeeds, but the 
resulting object is in a slightly confused state:

>>> r32 = cPickle.load(open('r32_3.pickle'))
>>> for i in range(3):
... print r64.random(), r32.random()
... 
0.237964627092 4292886520.32
0.544229225296 0.544229225296
0.369955166548 4292886520.19



--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-04-25 18:00

Message:
Logged In: YES 
user_id=80475

Tim, do you think we should require that the world not
change for 32-bit pickles?  

--

Comment By: Peter Maxwell (pm67nz)
Date: 2006-04-21 01:03

Message:
Logged In: YES 
user_id=320286

OK, here is a candidate patch, though I don't know if it is the best way to do 
it 
or meets the style guidelines etc.  It makes Random pickles interchangable 
between 32bit and 64bit machines by encoding their states as Python long 
integers.  An old pre-patch 32bit pickle loaded on a 64bit machine still fails 
(OverflowError: can't convert negative value to unsigned long) but I hope that 
combination is rare enough to ignore.  Also on a 32bit machine new Random 
pickles can't be unpickled by a pre-patch python, but again there are limits to 
sane backward compatability.


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 02:02

Message:
Logged In: YES 
user_id=33168

Peter, thanks for the report.  Do you think you could work
up a patch to correct this problem?

--

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

[ python-Bugs-1472695 ] 32/64bit pickled Random incompatiblity

2006-04-25 Thread SourceForge.net 
Bugs item #1472695, was opened at 2006-04-18 21:10
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&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
Submitted By: Peter Maxwell (pm67nz)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: 32/64bit pickled Random incompatiblity

Initial Comment:
The unsigned long integers which make up the state of a Random 
instance are converted to Python integers via a cast to long in 
_randommodule.c's random_getstate function, so on a 32bit platform 
Random.getstate() returns a mix of postitive and negative integers, while 
on a 64bit platform the negative numbers are replaced by larger positive 
numbers, their 32bit-2s-complement equivalents.

As a result, unpicking a Random instance from a 64bit machine on a 32bit 
platform produces the error "OverflowError: long int too large to convert 
to int".  Unpickling a 32bit Random on a 64bit machine succeeds, but the 
resulting object is in a slightly confused state:

>>> r32 = cPickle.load(open('r32_3.pickle'))
>>> for i in range(3):
... print r64.random(), r32.random()
... 
0.237964627092 4292886520.32
0.544229225296 0.544229225296
0.369955166548 4292886520.19



--

>Comment By: Tim Peters (tim_one)
Date: 2006-04-25 20:26

Message:
Logged In: YES 
user_id=31435

> do you think we should require that the world not
> change for 32-bit pickles?

I don't understand the question.  If a pre-2.5 pickle here
can be read in 2.5, where both producer & consumer are the
same 32-vs-64 bit choice; and a 2.5+ pickle here is portable
between 32- and 64- boxes, I'd say "good enough".

While desirable, it's not really critical that a 2.5 pickle
here be readable by an older Python.  While that's critical
for pickle in general, and critical too for
everyone-uses-'em types (ints, strings, lists, ...), when
fixing a bug in a specific rarely-used type's pickling
strategy some slop is OK.  IOW, it's just not worth heroic
efforts to hide all pain.  The docs should mention
incompatibilities, though.

Does that answer the question?

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-04-25 19:00

Message:
Logged In: YES 
user_id=80475

Tim, do you think we should require that the world not
change for 32-bit pickles?  

--

Comment By: Peter Maxwell (pm67nz)
Date: 2006-04-21 02:03

Message:
Logged In: YES 
user_id=320286

OK, here is a candidate patch, though I don't know if it is the best way to do 
it 
or meets the style guidelines etc.  It makes Random pickles interchangable 
between 32bit and 64bit machines by encoding their states as Python long 
integers.  An old pre-patch 32bit pickle loaded on a 64bit machine still fails 
(OverflowError: can't convert negative value to unsigned long) but I hope that 
combination is rare enough to ignore.  Also on a 32bit machine new Random 
pickles can't be unpickled by a pre-patch python, but again there are limits to 
sane backward compatability.


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 03:02

Message:
Logged In: YES 
user_id=33168

Peter, thanks for the report.  Do you think you could work
up a patch to correct this problem?

--

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

[ python-Bugs-1476356 ] StringIO should implement __str__()

2006-04-25 Thread SourceForge.net 
Bugs item #1476356, was opened at 2006-04-25 16:11
Message generated for change (Comment added) made by cinamod
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476356&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: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Dom Lachowicz (cinamod)
Assigned to: Nobody/Anonymous (nobody)
Summary: StringIO should implement __str__()

Initial Comment:
I was a bit surprised when I discovered that StringIO
didn't have a __str__() method, equivalent to
getvalue(). Calling str(stringio_object) gives the
following:

>>> import StringIO
>>> s = StringIO.StringIO("hello world")
>>> print "%s" % (str(s))


I had some (perhaps dodgy code) code that did:

if isinstance(data, types.FileType):
  return data.read()
else:
  return str(data)

Since StringIO doesn't subclass any file type and
doesn't implement a __str__() method, I was getting
seemingly bogus results. This was trivially worked
around by adding another "isinstance(data,
StringIO.StringIO)" case, but it was surprising
nonetheless. Thanks.

--

>Comment By: Dom Lachowicz (cinamod)
Date: 2006-04-25 22:53

Message:
Logged In: YES 
user_id=69417

The StringIO API diverges from the file API already. It adds
API (getvalue()) doesn't implement the encoding, mode, name,
newlines, or softspace attributes, and implements isatty()
in violation of the section 2.3.9 docs.

In some contexts, it may look like a file, but it isn't a
file. And I don't see how implementing __str__() changes
that. It's equivalent to saying that Java's StringBuffer
class shouldn't override toString()...

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-04-25 18:58

Message:
Logged In: YES 
user_id=80475

This isn't a bug.  The module is correctly emulating the API
for file objects.

I recommend replacing your isintance() test with a try/except:

try:
 return data.read()
except AttributeError:
 return str(data)



--

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

[ python-Bugs-1476356 ] StringIO should implement __str__()

2006-04-25 Thread SourceForge.net 
Bugs item #1476356, was opened at 2006-04-25 16:11
Message generated for change (Comment added) made by cinamod
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1476356&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: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Dom Lachowicz (cinamod)
Assigned to: Nobody/Anonymous (nobody)
Summary: StringIO should implement __str__()

Initial Comment:
I was a bit surprised when I discovered that StringIO
didn't have a __str__() method, equivalent to
getvalue(). Calling str(stringio_object) gives the
following:

>>> import StringIO
>>> s = StringIO.StringIO("hello world")
>>> print "%s" % (str(s))


I had some (perhaps dodgy code) code that did:

if isinstance(data, types.FileType):
  return data.read()
else:
  return str(data)

Since StringIO doesn't subclass any file type and
doesn't implement a __str__() method, I was getting
seemingly bogus results. This was trivially worked
around by adding another "isinstance(data,
StringIO.StringIO)" case, but it was surprising
nonetheless. Thanks.

--

>Comment By: Dom Lachowicz (cinamod)
Date: 2006-04-25 22:54

Message:
Logged In: YES 
user_id=69417

The StringIO API diverges from the file API already. It adds
API (getvalue()) doesn't implement the encoding, mode, name,
newlines, or softspace attributes, and implements isatty()
in violation of the section 2.3.9 docs.

In some contexts, it may look like a file, but it isn't a
file. And I don't see how implementing __str__() changes
that. It's equivalent to saying that Java's StringBuffer
class shouldn't override toString()...

--

Comment By: Dom Lachowicz (cinamod)
Date: 2006-04-25 22:53

Message:
Logged In: YES 
user_id=69417

The StringIO API diverges from the file API already. It adds
API (getvalue()) doesn't implement the encoding, mode, name,
newlines, or softspace attributes, and implements isatty()
in violation of the section 2.3.9 docs.

In some contexts, it may look like a file, but it isn't a
file. And I don't see how implementing __str__() changes
that. It's equivalent to saying that Java's StringBuffer
class shouldn't override toString()...

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-04-25 18:58

Message:
Logged In: YES 
user_id=80475

This isn't a bug.  The module is correctly emulating the API
for file objects.

I recommend replacing your isintance() test with a try/except:

try:
 return data.read()
except AttributeError:
 return str(data)



--

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

[ python-Bugs-1475080 ] example code in what's new/sqlite3 docs

2006-04-25 Thread SourceForge.net 
Bugs item #1475080, was opened at 2006-04-23 09:51
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475080&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: James Pryor (jpryor68)
>Assigned to: A.M. Kuchling (akuchling)
Summary: example code in what's new/sqlite3 docs

Initial Comment:
The documentation at


contains the following example code:


# Never do this -- insecure!
symbol = 'IBM'
c.execute("... where symbol = '%s'" % symbol)

# Do this instead
t = (symbol,)
c.execute('select * from stocks where symbol=?', ('IBM',))


The second block should instead read:


# Do this instead
t = ('IBM',)
c.execute('select * from stocks where symbol=?', t)



--

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