[ python-Bugs-1479099 ] 'compile' built-in function failures when missing EOL

[SourceForge.net]

Bugs item #1479099, was opened at 2006-04-30 01:00
Message generated for change (Comment added) made by oripel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479099&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: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Ori Peleg (oripel)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'compile' built-in function failures when missing EOL

Initial Comment:
The 'compile' built-in function sometimes fails when
given a source string that doesn't end in an EOL.

The following example crashes Python 2.3, 2.4, and 2.5a1:

prompt> ./python2.5 -c "compile('def foo(x):\n
pass\n#abc', 'blah.py', 'exec')"
Traceback (most recent call last):
  File "", line 1, in 
  File "blah.py", line 3
#abc
  ^
SyntaxError: invalid syntax

Attached is a patch to Lib/test/test_compile.py with a
test for this.

--

>Comment By: Ori Peleg (oripel)
Date: 2006-04-30 01:07

Message:
Logged In: YES 
user_id=1131251

The case that led me to this was calling
'trace.find_executable_linenos' on source files with this
condition.

See also
https://opensvn.csie.org/traccgi/testoob/trac.cgi/ticket/206

--

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

[ python-Bugs-900898 ] urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr

[SourceForge.net]

Bugs item #900898, was opened at 2004-02-20 06:51
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900898&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: Fixed
Priority: 5
Submitted By: James Kruth (jk7)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 AuthHandlers can pass a bad host to HTTPPasswordMgr

Initial Comment:
If the Request object being used returns a URI with a
port included (e.g. http://www.mysite.com:/index.html)

If Request.get_full_url() or Request.get_host() returns
a URI or host with a port included (e.g.
http://www.mysite.com:/index.html or
www.mysite.com:, respectively), and authentication
(proxy or http, basic only) is required, then the
respective AuthHandlers (HTTPBasicAuthHandler,
ProxyBasicAuthHandler) end up calling
http_error_auth_reqed with a host looking like
"www.mysite.com:".  http_error_auth_reqed then
precedes to call retry_http_basic_auth with the same
host parameter, which in turn calls
HTTPPasswordMgr.find_user_password.  The problem is
that find_user_password appears to expect a full URI,
and attempts to reduce it to just a host, by calling
reduce_uri.  If a bare host with a port is passed (like
"www.mysite.com:"), then reduce_uri returns just
the port number in the netloc position - which
find_user_password then attempts to compare against the
correct host name you've stored in your HTTPPasswordMgr
object along with your user name and password.  I
believe either find_user_password should not reduce the
host, or the  Auth Handler objects should pass full
hostnames to find_user_password.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 08:22

Message:
Logged In: YES 
user_id=849994

Fixed with commit of patch 1470846.

--

Comment By: John J Lee (jjlee)
Date: 2006-04-15 17:59

Message:
Logged In: YES 
user_id=261020

This is fixed by patch 1470846, which includes tests and doc
fix / update (though I neglected to mention that the patch
fixes this problem in the initial patch comment; I'll
rectify that now).

--

Comment By: Brad Clements (bkc)
Date: 2004-04-06 19:58

Message:
Logged In: YES 
user_id=4631

I ran into this problem today with Python 2.3.3 on RedHat 9.
I'm using port numbers in my URLs, and I found that the Auth
Handler did NOT correctly find the userid and password
registered.

ie:

authinfo = urllib2.HTTPPasswordMgrWithDefaultRealm()
authinfo.add_password(None, host, userid, password)
authHandler = urllib2.HTTPBasicAuthHandler(authinfo)

opener = urllib2.build_opener(authHandler)

where host = "http://localhost:7993";

I've tested the proposed fix shown in urllib2_bug.py at line 31,
to whit, this:

class HTTPBasicAuthHandlerF(AbstractBasicAuthHandler,
BaseHandler):

auth_header = 'Authorization'

def http_error_401(self, req, fp, code, msg, headers):
host = req.get_full_url()
return self.http_error_auth_reqed('www-authenticate',
  host, req, headers)


This appears to have corrected the problem.

test_urllib2.py and test_urllib.py both pass after making
this change. I did not test the ProxyBasicAuthHandler change
(I don't have a proxy)

--

Comment By: James Kruth (jk7)
Date: 2004-02-20 21:25

Message:
Logged In: YES 
user_id=979977

Here's a sample of the problem...

--

Comment By: James Kruth (jk7)
Date: 2004-02-20 14:39

Message:
Logged In: YES 
user_id=979977

I've made up a file with some source code and comments that
will hopefully clarify what I posted.  I will post an
example of the problem a bit later today.

------

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

[ python-Bugs-1479226 ] test_inspect fails on WinXP (2.5a2)

[SourceForge.net]

Bugs item #1479226, was opened at 2006-04-30 11:49
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=1479226&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: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_inspect fails on WinXP (2.5a2)

Initial Comment:
test_inspect fails after installing 2.5a2 on WinXP

Output of 
python -c "from test.test_inspect import test_main;
test_main()"

is attached.


--

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

[ python-Bugs-1473560 ] urllib2.Request constructor to urllib.quote the url given

[SourceForge.net]

Bugs item #1473560, was opened at 2006-04-20 14:02
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&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: Nikos Kouremenos (nkour)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2.Request constructor to urllib.quote the url given

Initial Comment:
urllib2.Request('http://www.google.com/search?client=firefox&q=foo
bar', None)


this fails. it shouldn't

--

Comment By: Nikos Kouremenos (nkour)
Date: 2006-04-29 11:34

Message:
Logged In: YES 
user_id=865368

it's foo bar not foobar. and space should be automatcally
become %20 (urllib.quote()) but it doesn't. please reopen

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 19:19

Message:
Logged In: YES 
user_id=849994

I don't know what your problem is. This works perfectly for me:

>>> r =
urllib2.Request("http://www.google.com/search?client=firefox&q=foobar";,
None)
>>> o = urllib2.HTTPHandler()
>>> u = o.http_open(r)
>>> u.read()
"..."

Closing as "Works for me". If you have another problem,
please reopen

------

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

[ python-Bugs-1473560 ] urllib2.Request constructor to urllib.quote the url given

[SourceForge.net]

Bugs item #1473560, was opened at 2006-04-20 14:02
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473560&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: Wont Fix
Priority: 5
Submitted By: Nikos Kouremenos (nkour)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2.Request constructor to urllib.quote the url given

Initial Comment:
urllib2.Request('http://www.google.com/search?client=firefox&q=foo
bar', None)


this fails. it shouldn't

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 09:25

Message:
Logged In: YES 
user_id=849994

The docs say that the argument to the Request constructor
must be a valid URL. A valid URL doesn't contain spaces, so
the behavior is consistent.

--

Comment By: Nikos Kouremenos (nkour)
Date: 2006-04-29 11:34

Message:
Logged In: YES 
user_id=865368

it's foo bar not foobar. and space should be automatcally
become %20 (urllib.quote()) but it doesn't. please reopen

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 19:19

Message:
Logged In: YES 
user_id=849994

I don't know what your problem is. This works perfectly for me:

>>> r =
urllib2.Request("http://www.google.com/search?client=firefox&q=foobar";,
None)
>>> o = urllib2.HTTPHandler()
>>> u = o.http_open(r)
>>> u.read()
"..."

Closing as "Works for me". If you have another problem,
please reopen

--

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

[ python-Bugs-1281692 ] urllib violates rfc 959

[SourceForge.net]

Bugs item #1281692, was opened at 2005-09-04 17:30
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281692&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: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib violates rfc 959

Initial Comment:
[forwarded from http://bugs.debian.org/324023]

python's urllib does the following things "on the line"
when retrieving
a file by ftp:
send(3, "PASV\r\n", 6, 0)   = 6
send(3, "NLST ftp-master.debian.org\r\n", 28, 0) = 28

But RFC 959 states:
  This command [NLST] causes a directory listing to be
sent from server
  to user site.  The pathname should specify a
directory or other
  system-specific file group descriptor

So, according to the robustness principle, it is wrong
that python
aborts file transfer if the server refuses to support
NLST on files.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 09:28

Message:
Logged In: YES 
user_id=849994

Fixed by applying said patch.

--

Comment By: John J Lee (jjlee)
Date: 2006-04-15 20:06

Message:
Logged In: YES 
user_id=261020

Patch 1470976 fixes this bug.

--

Comment By: John J Lee (jjlee)
Date: 2006-02-06 01:16

Message:
Logged In: YES 
user_id=261020

Bug 1357260 reports the same issue for both urllib and urllib2.

--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-09-08 06:18

Message:
Logged In: YES 
user_id=341410

"The pathname should specify a directory or other
system-specific file group descriptor."

If the system (ftp server) does not support a particular
'file name' as a 'file group descriptor', it seems to me
that the system (ftp server) is braindead.

------

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

[ python-Bugs-1357260 ] urllib/urllib2 cannot ftp files which are not listable.

[SourceForge.net]

Bugs item #1357260, was opened at 2005-11-15 10:35
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&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: Fixed
Priority: 5
Submitted By: Bugs Fly (mozbugbox)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib/urllib2 cannot ftp files which are not listable.

Initial Comment:
For whatever reason (security, privacy), there are ftp
sites which will not allow ftp list command while
normal downloading can be performed "blindly". This
mostly happens on direct linked ftp urls.

In urllib.py, the ftp wrapper first check with
"self.ftp.nlst(file)" before downloading, thus prevent
the above sites from being useful. From the codes
around, I saw no reason this extra step/check was
performed at all. If the file really did not exist,
RETR would return a suitable error anyway as checked by
the code below.



--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 09:28

Message:
Logged In: YES 
user_id=849994

Fixed by applying said patch.

--

Comment By: John J Lee (jjlee)
Date: 2006-04-15 20:06

Message:
Logged In: YES 
user_id=261020

Patch 1470976 fixes this bug.

--

Comment By: John J Lee (jjlee)
Date: 2006-02-06 01:16

Message:
Logged In: YES 
user_id=261020

Bug 1281692 reports the same issue for the urllib case, and
includes a reference to the RFC.

--

Comment By: Bugs Fly (mozbugbox)
Date: 2005-11-17 05:38

Message:
Logged In: YES 
user_id=1033842

  File "/usr/lib/python2.4/ftplib.py", line 241, in sendcmd
return self.getresp()
  File "/usr/lib/python2.4/ftplib.py", line 216, in getresp
raise error_perm, resp
IOError: [Errno ftp error] [Errno ftp error] 550
tompda_685692_Professional.Palm.OS.Programming.part12.rar:
No such file or directory.


--

Comment By: Thomas Lee (krumms)
Date: 2005-11-15 13:34

Message:
Logged In: YES 
user_id=315535

what's the expected response/error code from the FTP server
if the NLST fails?

--

Comment By: Bugs Fly (mozbugbox)
Date: 2005-11-15 11:37

Message:
Logged In: YES 
user_id=1033842

This might be related to bug #635453 but this is a bigger
bug than a directory list is returned. If an existing file
cannot be retrieved, then functionally is totally broken,
there are no work around in this case.





------

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

[ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion

[SourceForge.net]

Bugs item #1478253, was opened at 2006-04-28 08:59
Message generated for change (Comment added) made by balducci
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: balducci (balducci)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes: undefined symbol: XGetExtensionVersion

Initial Comment:
Dear python maintainers,

apologies if I'm wrong or I'm missing some evident point.

Just built 2.5a2 on linux:

 myhost> uname -a
 Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST
2006 i686 unknown


I find that `make test' chokes in test_ctypes.

Running the single test with `./python -E -tt
./Lib/test/regrtest.py 
-l -v -s test_ctypes' gives me the output shown in the
attached file.


As far as I could google around, I seem to understand
that this
problem has already appeared in the past. Basically, it
is due to the
fact that libglut (version 3.7) does not contain the
XGetExtensionVersion function, which is instead defined
in libXi:

myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i
xgetextensionversion
 U XGetExtensionVersion

myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i
xgetextensionversion
3930 T XGetExtensionVersion

I seem to understand that libglut should be dlopen'ed
together with
libXi, in order to have XGetExtensionVersion available.

Unfortunately, I don't speak python, so I'm not in the
position to
suggest any reasonable fix for this.

I send this message in the hope of making something
useful: if this is
not the case, please, accept my apologies.

I thank you very much for your time and effort in
maintaining python.

Ciao
Gabriele



--

>Comment By: balducci (balducci)
Date: 2006-04-30 09:46

Message:
Logged In: YES 
user_id=1452725

Dear Thomas,

I thank you very much for your time and effort.

I think I have solved the problem and, as I suspected,
the problem was on my side and not on python's.
^

I have two shared libglut's installed: one is from
orginal RedHat-7.1 distro and the other was installed
by me some time ago.

Now, if I check dependencies of the two libs, I get:

RedHat's libglut:

myhost>  ldd /usr/lib/libglut.so
linux-gate.so.1 =>  (0xe000)
libSM.so.6 => /usr/local/X11R6/lib/libSM.so.6 (0xb7f1e000)
libICE.so.6 => /usr/local/X11R6/lib/libICE.so.6 (0xb7f06000)
libXmu.so.6 => /usr/local/X11R6/lib/libXmu.so.6 (0xb7ef)
libXext.so.6 => /usr/local/X11R6/lib/libXext.so.6 (0xb7ee2000)
libXi.so.6 => /usr/local/X11R6/lib/libXi.so.6 (0xb7eda000)
libX11.so.6 => /usr/local/X11R6/lib/libX11.so.6 (0xb7e0e000)
libc.so.6 => /usr/local/glibc/lib/libc.so.6 (0xb7cea000)
libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7ce)
libXt.so.6 => /usr/local/X11R6/lib/libXt.so.6 (0xb7c8d000)
libdl.so.2 => /usr/local/glibc/lib/libdl.so.2 (0xb7c89000)
/usr/local/glibc/lib/ld-linux.so.2 (0x8000)


My libglut installation:
---
myhost> ldd /usr/local/X11R6/lib/libglut.so
linux-gate.so.1 =>  (0xe000)
libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7f99000)
libc.so.6 => /usr/local/glibc/lib/libc.so.6 (0xb7e76000)
/usr/local/glibc/lib/ld-linux.so.2 (0x8000)

Things seem to be clear for me now: /usr/lib/libglut.so
contains all the necessary dependencies to resolve any
reference which is not defined in it, while
/usr/local/X11R6/lib/libglut.so does not contain any
dependency from the X11 libs, which instead is NEEDED
(e.g. the XGetExtensionVersion problem shown up).

In fact, if I run `LD_LIBRARY_PATH=/usr/lib make
test', i.e. force runtime loader to use
/usr/lib/libglut.so, everything works nicely, even
without the patch you sent. On the other hand, if
/usr/local/X11R6/lib/libglut.so is picked up, then the
errors occur and your patch does not solve the problem
(and it could not in any case, given the above, I guess).

Going back to my libglut installation notes, I could
verify that no X11 dependencies were compiled in (most
probably due to some misconfiguration by me).

In the end, I think you can close this (which is not
a) bug.

I apologize once again for wasting your time on an
issue which I could have investigated more deeply
before claiming a bug in python.

THANK YOU and
ciao
Gabriele


--

Comment By: Thomas Heller (theller)
Date: 2006-04-28 19:06

Message:
Logged In: YES 
user_id=11105

Gabriele, from the thread you mention I would 

[ python-Bugs-1478253 ] test_ctypes: undefined symbol: XGetExtensionVersion

[SourceForge.net]

Bugs item #1478253, was opened at 2006-04-28 08:59
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478253&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.5
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: balducci (balducci)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes: undefined symbol: XGetExtensionVersion

Initial Comment:
Dear python maintainers,

apologies if I'm wrong or I'm missing some evident point.

Just built 2.5a2 on linux:

 myhost> uname -a
 Linux myhost 2.6.16.5 #1 Thu Apr 13 10:01:54 CEST
2006 i686 unknown


I find that `make test' chokes in test_ctypes.

Running the single test with `./python -E -tt
./Lib/test/regrtest.py 
-l -v -s test_ctypes' gives me the output shown in the
attached file.


As far as I could google around, I seem to understand
that this
problem has already appeared in the past. Basically, it
is due to the
fact that libglut (version 3.7) does not contain the
XGetExtensionVersion function, which is instead defined
in libXi:

myhost> nm /usr/local/X11R6/lib/libglut.so.3|egrep -i
xgetextensionversion
 U XGetExtensionVersion

myhost> nm /usr/local/X11R6/lib/libXi.so|egrep -i
xgetextensionversion
3930 T XGetExtensionVersion

I seem to understand that libglut should be dlopen'ed
together with
libXi, in order to have XGetExtensionVersion available.

Unfortunately, I don't speak python, so I'm not in the
position to
suggest any reasonable fix for this.

I send this message in the hope of making something
useful: if this is
not the case, please, accept my apologies.

I thank you very much for your time and effort in
maintaining python.

Ciao
Gabriele



--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 09:51

Message:
Logged In: YES 
user_id=849994

Closing. Thank you for your thorough investigation.

--

Comment By: balducci (balducci)
Date: 2006-04-30 09:46

Message:
Logged In: YES 
user_id=1452725

Dear Thomas,

I thank you very much for your time and effort.

I think I have solved the problem and, as I suspected,
the problem was on my side and not on python's.
^

I have two shared libglut's installed: one is from
orginal RedHat-7.1 distro and the other was installed
by me some time ago.

Now, if I check dependencies of the two libs, I get:

RedHat's libglut:

myhost>  ldd /usr/lib/libglut.so
linux-gate.so.1 =>  (0xe000)
libSM.so.6 => /usr/local/X11R6/lib/libSM.so.6 (0xb7f1e000)
libICE.so.6 => /usr/local/X11R6/lib/libICE.so.6 (0xb7f06000)
libXmu.so.6 => /usr/local/X11R6/lib/libXmu.so.6 (0xb7ef)
libXext.so.6 => /usr/local/X11R6/lib/libXext.so.6 (0xb7ee2000)
libXi.so.6 => /usr/local/X11R6/lib/libXi.so.6 (0xb7eda000)
libX11.so.6 => /usr/local/X11R6/lib/libX11.so.6 (0xb7e0e000)
libc.so.6 => /usr/local/glibc/lib/libc.so.6 (0xb7cea000)
libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7ce)
libXt.so.6 => /usr/local/X11R6/lib/libXt.so.6 (0xb7c8d000)
libdl.so.2 => /usr/local/glibc/lib/libdl.so.2 (0xb7c89000)
/usr/local/glibc/lib/ld-linux.so.2 (0x8000)


My libglut installation:
---
myhost> ldd /usr/local/X11R6/lib/libglut.so
linux-gate.so.1 =>  (0xe000)
libgcc_s.so.1 => /usr/local/gcc/lib/libgcc_s.so.1 (0xb7f99000)
libc.so.6 => /usr/local/glibc/lib/libc.so.6 (0xb7e76000)
/usr/local/glibc/lib/ld-linux.so.2 (0x8000)

Things seem to be clear for me now: /usr/lib/libglut.so
contains all the necessary dependencies to resolve any
reference which is not defined in it, while
/usr/local/X11R6/lib/libglut.so does not contain any
dependency from the X11 libs, which instead is NEEDED
(e.g. the XGetExtensionVersion problem shown up).

In fact, if I run `LD_LIBRARY_PATH=/usr/lib make
test', i.e. force runtime loader to use
/usr/lib/libglut.so, everything works nicely, even
without the patch you sent. On the other hand, if
/usr/local/X11R6/lib/libglut.so is picked up, then the
errors occur and your patch does not solve the problem
(and it could not in any case, given the above, I guess).

Going back to my libglut installation notes, I could
verify that no X11 dependencies were compiled in (most
probably due to some misconfiguration by me).

In the end, I think you can close this (which is not
a) bug.

I apologize once again for wasting your time on an
issue which I could have investigated more deeply
before claiming a bug in python.

THANK YOU and
ciao
Gabriele


---

[ python-Bugs-1478529 ] size limit exceeded for read() from network drive

[SourceForge.net]

Bugs item #1478529, was opened at 2006-04-28 18:46
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: size limit exceeded for read() from network drive

Initial Comment:
If you've got a network share mounted as a local drive
then Windows has a limit of 67,076,095 (0x03ff7fff)
bytes for a read from an open file on that drive.

Running the python read() method on an open file larger
than this size throws an "IOError: [Errno 22] Invalid
argument" exception.

A fix would be for python to internally use multiple
reads so as to not exceed this limit.


--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-30 12:10

Message:
Logged In: YES 
user_id=21627

What version of Windows are you using? Do you know of any
documentation of this limit? (without actually testing, I
find it hard to believe that this limit exists in Windows)

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-29 15:23

Message:
Logged In: YES 
user_id=849994

How can it be determined whether exactly this restriction
caused the "invalid argument" error? If it can't, there's
nothing that can be done -- restricting all reads just
because of a Windows limitation doesn't seem right.

------

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

[ python-Bugs-1110705 ] list comprehension scope

[SourceForge.net]

Bugs item #1110705, was opened at 2005-01-27 14:27
Message generated for change (Comment added) made by cito
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1110705&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.4
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
Assigned to: Nobody/Anonymous (nobody)
Summary: list comprehension scope

Initial Comment:
The variable used for iteration in list comprehensions
is still in scope after the list comprehension. 

>>>foo = [1, 2, 3]
>>>bar = [dummy + 1 for dummy in foo]
>>>dummy
3

Expected result: NameError: name 'dummy' is not defined

--

Comment By: Christoph Zwerschke (cito)
Date: 2006-04-30 13:52

Message:
Logged In: YES 
user_id=193957

Either this is a bug that should be fixed, or the
documentation that says it is a bug should be fixed
(http://www.python.org/doc/current/ref/lists.html#foot4519).

That fact that an ordinary for loop leaks the control
variables into the containing scope may be a design feature,
but the same behavior for list comprehensions can hardly be
called a design feature. At least not one that is
reasonable. I would rather call it a bug. It definitely
contradicts the principle of least surprise.

--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-01-29 20:54

Message:
Logged In: YES 
user_id=341410

"this behavior is deprecated, and relying on it will not
work once this bug is fixed in a future release"

As we have not yet reached the future release in which this
will happen, and the 'bug' is both known and documented, it
will be 'fixed' when it is fixed.  The reason that it has
not yet been 'fixed' is because there is a nontrivial amount
of code that would break if it was.

I personally would call it a deprecated 'feature'.  Then
again, I use it more often than I should.

--

Comment By: Simon Dahlbacka (sdahlbac)
Date: 2005-01-27 15:11

Message:
Logged In: YES 
user_id=750513

Seemingly (according to:
http://docs.python.org/ref/lists.html) this is indeed a bug
that should be fixed.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-27 14:48

Message:
Logged In: YES 
user_id=80475

This is not a bug.  It is behaving as designed.  The thought
was to emulate the behavior of an equivalent for-loop.

In future versions of Python, Guido would like to change the
design to hide the induction variable.  So, someday, you'll
get your wish.

------

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

[ python-Bugs-1478529 ] size limit exceeded for read() from network drive

[SourceForge.net]

Bugs item #1478529, was opened at 2006-04-28 12:46
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: size limit exceeded for read() from network drive

Initial Comment:
If you've got a network share mounted as a local drive
then Windows has a limit of 67,076,095 (0x03ff7fff)
bytes for a read from an open file on that drive.

Running the python read() method on an open file larger
than this size throws an "IOError: [Errno 22] Invalid
argument" exception.

A fix would be for python to internally use multiple
reads so as to not exceed this limit.


--

>Comment By: Tim Peters (tim_one)
Date: 2006-04-30 12:23

Message:
Logged In: YES 
user_id=31435

Martin, here's an MS article seemingly related to this:

http://support.microsoft.com/default.aspx?scid=kb;en-us;899149

However, it's about writing to a file on a network drive,
not reading from it.  It says that opening the file in 'w+b'
mode, instead of 'wb' mode, is a workaround.

I couldn't find anything documenting the same kind of
problem for reading.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-30 06:10

Message:
Logged In: YES 
user_id=21627

What version of Windows are you using? Do you know of any
documentation of this limit? (without actually testing, I
find it hard to believe that this limit exists in Windows)

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-29 09:23

Message:
Logged In: YES 
user_id=849994

How can it be determined whether exactly this restriction
caused the "invalid argument" error? If it can't, there's
nothing that can be done -- restricting all reads just
because of a Windows limitation doesn't seem right.

------

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

[ python-Bugs-1479226 ] test_inspect fails on WinXP (2.5a2)

[SourceForge.net]

Bugs item #1479226, was opened at 2006-04-30 08:49
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479226&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: Installation
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_inspect fails on WinXP (2.5a2)

Initial Comment:
test_inspect fails after installing 2.5a2 on WinXP

Output of 
python -c "from test.test_inspect import test_main;
test_main()"

is attached.


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 17:43

Message:
Logged In: YES 
user_id=849994

Thanks for reporting! This was caused by a bug in inspect.py
which is was fixed in revisions 45822 and 45824.

--

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

[ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active

[SourceForge.net]

Bugs item #1199282, was opened at 2005-05-10 18:24
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&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: Pending
>Resolution: Fixed
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Peter Åstrand (astrand)
Summary: subprocess _active.remove(self) self not in list _active

Initial Comment:
I start a subprocess in a seperate thread (25 concurrent 
threads)
in some of the threads the following error occurs
 
Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
self.run()
  File "upgrade.py", line 45, in run
returncode = p.wait()
  File "C:\Python24\lib\subprocess.py", line 765, in wait
_active.remove(self)
ValueError: list.remove(x): x not in list
 
this is the code that starts the subprocess and where I 
wait for the result
 
p = subprocess.Popen('command', \
 stdin=None, 
stdout=subprocess.PIPE, \
 stderr=subprocess.STDOUT, 
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 19:52

Message:
Logged In: YES 
user_id=849994

The error causing "_active.remove(self)" call was removed
from wait() with patch 1467770, so I think this is fixed.

--

Comment By: cheops (atila-cheops)
Date: 2006-04-11 20:10

Message:
Logged In: YES 
user_id=1276121

there are 2 definitions of the function poll, one for 
windows and one for POSIX systems
in the windows version _deadlock is not used
in the POSIX version _deadlock is used

see also modification made by loewis in committed version 
45234

--

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-04-11 07:21

Message:
Logged In: YES 
user_id=1434251

I looked at the patch #1467770 you mentioned and 
downloaded the patch.

Is it correct that _deadlock variable is used in the 
definition of poll but it is not in the argument list?


--

Comment By: cheops (atila-cheops)
Date: 2006-04-10 14:57

Message:
Logged In: YES 
user_id=1276121

see patch #1467770

--

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 13:50

Message:
Logged In: YES 
user_id=1488657

> Simply list operations such as remove() and append() are
> thread safe,

OK, my apologies... I did not know.

I did some more tests. On Linux, I found lots of:

  File "./subprocess.py", line 428, in call
return Popen(*args, **kwargs).wait()
  File "./subprocess.py", line 1023, in wait
pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes

The try...except solution does not handle this (since we are
in the "posix" section).

In my opinion, the call to _cleanup() in Popen.__init__() is
useless (it just checks if older processes have stopped when
a new one is started. I cannot see why it could be
mandatory) and it is the root of this bug.

I commented it out (line 506) and retried my tests on Linux
& Windows plateforms: I had no exception at all.



--

Comment By: Peter Åstrand (astrand)
Date: 2006-03-29 05:11

Message:
Logged In: YES 
user_id=344921

>I think accesses to _active should be serialized in a
>thread-safe way. _active could be a Queue (from the Queue
>module) for example

Simply list operations such as remove() and append() are
thread safe, so there should be no need for a Queue. Also, a
Queue cannot be used since the subprocess module needs to be
compatible with Python 2.2. 

--

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-28 23:17

Message:
Logged In: YES 
user_id=1488657

I am running into the same problem on a Windows 2k/XP
plateform with a multi-threaded application. It occurs randomly.

It has never appened (yet) on a Linux plateform.

I think accesses to _active should be serialized in a
thread-safe way. _active could be a Queue (from the Queue
module) for example.


--

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-25 08:10

Message:
Logged In: YES 
user_id=1434251

Wouldn't it be best to completely remove any references 
to "

[ python-Bugs-1385040 ] compiler module does not detect a syntax error

[SourceForge.net]

Bugs item #1385040, was opened at 2005-12-19 09:58
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&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: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler module does not detect a syntax error

Initial Comment:
import compiler 
compiler.parse("def foo(a=1,b): pass") 
 
Gives: 
 
Module(None, Stmt([Function(None, 'foo', ['a', 'b'], 
[Const(1)], 0, None, Stmt([Pass()]))])) 
 
However, the python interpreter itself barks for the 
same code: 
 
SyntaxError: non-default argument follows default 
argument 
 
 
-Harri 
 
 

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 20:20

Message:
Logged In: YES 
user_id=849994

Attaching patch. Please review.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-25 21:59

Message:
Logged In: YES 
user_id=33168

FYI.

------

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

[ python-Bugs-1479586 ] Segmentation fault while using Tkinter

[SourceForge.net]

Bugs item #1479586, was opened at 2006-05-01 09:25
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=1479586&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. Löwis (loewis)
Summary: Segmentation fault while using Tkinter

Initial Comment:
While using Tkinter I encountere segmentation faults
regularly. I ran my program using gdb using python2.4
and Fedora Core 5 and received:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1209063760 (LWP 2024)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1212232800 (LWP 2027)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type  to continue, or q  to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209063760 (LWP 2024)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) 


I ran the same program using python2.5a2 and again
received:

Starting program: /usr/local/bin/python
~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0xa05000
[Thread debugging using libthread_db enabled]
[New Thread -1208899920 (LWP 2415)]
[New Thread -1212068960 (LWP 2418)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899920 (LWP 2415)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb)


Are these information enough for fixing the problem or
should I send my program?

Thanks


--

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

[ python-Bugs-1475162 ] Tkinter hangs in test_tcl

[SourceForge.net]

Bugs item #1475162, was opened at 2006-04-23 23:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1475162&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: Tkinter
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Wouters (twouters)
Assigned to: Martin v. Löwis (loewis)
Summary: Tkinter hangs in test_tcl

Initial Comment:

For a while now, I've noticed test_tcl locking up when
trying to refleaktest it. I was able to reproduce it
quite simply:

import Tkinter, os
if "DISPLAY" in os.environ: del os.environ["DISPLAY"]
tcl = Tkinter.Tcl()
try: tcl.loadtk()
except Exception, e: print e
tcl.loadtk()

Or using _tkinter directly:

import _tkinter, os
if "DISPLAY" in os.environ: del os.environ["DISPLAY"]
tk = _tkinter.create(None, "test", "Tk", 0, 1, 0)
try: tk.loadtk()
except: pass
tk.loadtk()

In either case, the second loadtk never finishes.

It seems that, on my platform at least, Tk_Init()
doesn't like being called twice even when the first
call resulted in an error. That's Tcl and Tk 8.4.12.
Tkapp_Init() (which is the Tkinter part that calls
Tk_Init()) does its best to guard against calling
Tk_Init() twice when the first call was succesful, but
it doesn't remember failure cases. I don't know enough
about Tcl/Tk or Tkinter to know how this is best handled.


--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-05-01 08:30

Message:
Logged In: YES 
user_id=21627

This should now be fixed with r45833 and r45834.

------

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

[ python-Bugs-1479586 ] Segmentation fault while using Tkinter

[SourceForge.net]

Bugs item #1479586, was opened at 2006-05-01 06:55
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. Löwis (loewis)
Summary: Segmentation fault while using Tkinter

Initial Comment:
While using Tkinter I encountere segmentation faults
regularly. I ran my program using gdb using python2.4
and Fedora Core 5 and received:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1209063760 (LWP 2024)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1212232800 (LWP 2027)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type  to continue, or q  to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209063760 (LWP 2024)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) 


I ran the same program using python2.5a2 and again
received:

Starting program: /usr/local/bin/python
~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0xa05000
[Thread debugging using libthread_db enabled]
[New Thread -1208899920 (LWP 2415)]
[New Thread -1212068960 (LWP 2418)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899920 (LWP 2415)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb)


Are these information enough for fixing the problem or
should I send my program?

Thanks


--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-05-01 08:34

Message:
Logged In: YES 
user_id=21627

Please do send your program, or better yet a small test case
that allows to reproduce the problem. It looks like a Tk bug
at first glance, in TkUndoSetDepth.

--

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

[ python-Bugs-1385040 ] compiler module does not detect a syntax error

[SourceForge.net]

Bugs item #1385040, was opened at 2005-12-19 01:58
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&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: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler module does not detect a syntax error

Initial Comment:
import compiler 
compiler.parse("def foo(a=1,b): pass") 
 
Gives: 
 
Module(None, Stmt([Function(None, 'foo', ['a', 'b'], 
[Const(1)], 0, None, Stmt([Pass()]))])) 
 
However, the python interpreter itself barks for the 
same code: 
 
SyntaxError: non-default argument follows default 
argument 
 
 
-Harri 
 
 

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-01 00:21

Message:
Logged In: YES 
user_id=33168

Any reason you do:
  not i >= len(nodelist) 

instead of:
  i < len(nodelist)

?

The patch seems fine if everything passes with -u compiler
test_compiler.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 13:20

Message:
Logged In: YES 
user_id=849994

Attaching patch. Please review.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-25 13:59

Message:
Logged In: YES 
user_id=33168

FYI.

------

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

[ python-Bugs-1479586 ] Segmentation fault while using Tkinter

[SourceForge.net]

Bugs item #1479586, was opened at 2006-04-30 21:55
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. Löwis (loewis)
Summary: Segmentation fault while using Tkinter

Initial Comment:
While using Tkinter I encountere segmentation faults
regularly. I ran my program using gdb using python2.4
and Fedora Core 5 and received:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1209063760 (LWP 2024)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1212232800 (LWP 2027)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type  to continue, or q  to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209063760 (LWP 2024)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) 


I ran the same program using python2.5a2 and again
received:

Starting program: /usr/local/bin/python
~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0xa05000
[Thread debugging using libthread_db enabled]
[New Thread -1208899920 (LWP 2415)]
[New Thread -1212068960 (LWP 2418)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899920 (LWP 2415)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb)


Are these information enough for fixing the problem or
should I send my program?

Thanks


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-01 00:25

Message:
Logged In: YES 
user_id=33168

If you can send a small test case that would be great. 
Also, can you attach the backtrace (bt command in gdb)?

How did you configure python?  Did you use an
--enable-unicode or --enable-threads?  Did you built Tcl/Tk
or are you using the default version with FC5?

When python starts up, what do you see?  It should be
something like:

Python 2.5a2 (trunk:45831M, Apr 30 2006, 23:27:02) 
[GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin


Also, what does this print:  
import sys ; print sys.maxunicode

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-30 23:34

Message:
Logged In: YES 
user_id=21627

Please do send your program, or better yet a small test case
that allows to reproduce the problem. It looks like a Tk bug
at first glance, in TkUndoSetDepth.

--

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

[ python-Bugs-1479626 ] Uninstall does not clearn registry

[SourceForge.net]

Bugs item #1479626, was opened at 2006-05-01 10:48
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=1479626&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: Installation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Uninstall does not clearn registry

Initial Comment:
After uninstalling Python2.5a2 (winXP) the registry key
/HKLM/Software/Python/PythonCore/2.5 is left in the
registry.

--

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

[ python-Bugs-1479776 ] float->str rounding bug

[SourceForge.net]

Bugs item #1479776, was opened at 2006-05-01 10:37
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=1479776&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Nolta (mrnolta)
Assigned to: Nobody/Anonymous (nobody)
Summary: float->str rounding bug

Initial Comment:
Hi,

Here's my problem:

  >>> print "%.2f" % 2.195
  2.19

The output should be "2.20".

It's sensitive to whether the value is greater than 1.
For example, this works:

  >>> print "%.4f" % 2.195e-2
  0.0220

Here's my full version info:

  Python 2.4.1 (#1, May 16 2005, 15:19:29)
  [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2

-Mike

------

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

[ python-Bugs-1479785 ] Quitter object masked

[SourceForge.net]

Bugs item #1479785, was opened at 2006-05-01 11:01
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=1479785&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: IDLE
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: Quitter object masked

Initial Comment:
2.5 introduces a Quitter object (defined in site.py) 
to make the quit/exit message more friendly.

Lines 480-482 of PyShell.py override this, so that 
users of Idle never see the improved feature.

Unfortunately, simply removing those lines isn't quite 
enough to solve the problem, as IDLE catches 
SystemExit exceptions.  Getting around that, I didn't 
have time to track down yet.




--

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

[ python-Bugs-1479776 ] float->str rounding bug

[SourceForge.net]

Bugs item #1479776, was opened at 2006-05-01 10:37
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479776&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: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Michael Nolta (mrnolta)
Assigned to: Nobody/Anonymous (nobody)
Summary: float->str rounding bug

Initial Comment:
Hi,

Here's my problem:

  >>> print "%.2f" % 2.195
  2.19

The output should be "2.20".

It's sensitive to whether the value is greater than 1.
For example, this works:

  >>> print "%.4f" % 2.195e-2
  0.0220

Here's my full version info:

  Python 2.4.1 (#1, May 16 2005, 15:19:29)
  [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2

-Mike

--

>Comment By: Tim Peters (tim_one)
Date: 2006-05-01 11:54

Message:
Logged In: YES 
user_id=31435

This isn't a bug.  You should read the Python Tutorial's
Appendix on floating-point issues.  As you can see from

>>> 2.195
2.1948

the closest representable float is actually a little bit
smaller than the decimal 2.195, so there's no reason for it
to "round up".  Try the same thing in C (or any other
language exposing your hardware's binary floating point),
and you should see the same result.

If you need exact decimal values, use Python's "decimal"
module instead.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479776&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-735515 ] urllib / urllib2 should cache 301 redirections

[SourceForge.net]

Feature Requests item #735515, was opened at 2003-05-10 00:21
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=735515&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: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib / urllib2 should cache 301 redirections

Initial Comment:
urllib / urllib2 should cache the results of 301 
(permanent) redirections.  This shouldn't break 
anything, since it's just an internal optimisation 
from one point of view -- but it's also what the 
RFC (2616, section 10.3.2, first para) says 
SHOULD happen. 
 

--

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

[ python-Bugs-1471407 ] setup.py --help-commands exception

[SourceForge.net]

Bugs item #1471407, was opened at 2006-04-16 19:23
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471407&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: Distutils
Group: Python 2.5
>Status: Pending
Resolution: None
Priority: 5
Submitted By: James William Pye (jwpye)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py --help-commands exception

Initial Comment:
>From a recent trunk build(2.5a1) on FreeBSD 6.1:

[EMAIL PROTECTED]:/src/org/pgfoundry/python/fe/local %
/usr/dev/bin/python ./setup.py --help-commands
Standard commands:
  buildbuild everything needed to install
  build_py "build" pure Python modules (copy to
build directory)
  build_extbuild C/C++ extensions (compile/link
to build directory)
  build_clib   build C/C++ libraries used by Python
extensions
  build_scripts"build" scripts (copy and fixup #! line)
  cleanclean up temporary files from
'build' command
  install  install everything from build directory
  install_lib  install all Python modules
(extensions and pure Python)
  install_headers  install C/C++ header files
  install_scripts  install scripts (Python or otherwise)
  install_data install data files
  sdistcreate a source distribution
(tarball, zip file, etc.)
Traceback (most recent call last):
  File "./setup.py", line 52, in 
setup(defaults)
  File "./setup.py", line 46, in setup
d = distutils.core.setup(**kw)
  File "/usr/dev/lib/python2.5/distutils/core.py", line
137, in setup
ok = dist.parse_command_line()
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
455, in parse_command_line
if self.handle_display_options(option_order):
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
680, in handle_display_options
self.print_commands()
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
758, in print_commands
max_length)
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
720, in print_command_list
klass = self.get_command_class(cmd)
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
851, in get_command_class
raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'register'

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-01 20:25

Message:
Logged In: YES 
user_id=849994

It looks like the "distutils.command.register" module is not
importable. Can you retry with alpha2 and see if the problem
persists?

--

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

[ python-Bugs-1479586 ] Segmentation fault while using Tkinter

[SourceForge.net]

Bugs item #1479586, was opened at 2006-05-01 09:25
Message generated for change (Comment added) made by aligrudi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. Löwis (loewis)
Summary: Segmentation fault while using Tkinter

Initial Comment:
While using Tkinter I encountere segmentation faults
regularly. I ran my program using gdb using python2.4
and Fedora Core 5 and received:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1209063760 (LWP 2024)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1212232800 (LWP 2027)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type  to continue, or q  to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209063760 (LWP 2024)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) 


I ran the same program using python2.5a2 and again
received:

Starting program: /usr/local/bin/python
~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0xa05000
[Thread debugging using libthread_db enabled]
[New Thread -1208899920 (LWP 2415)]
[New Thread -1212068960 (LWP 2418)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899920 (LWP 2415)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb)


Are these information enough for fixing the problem or
should I send my program?

Thanks


--

>Comment By: Ali Gholami Rudi (aligrudi)
Date: 2006-05-02 09:55

Message:
Logged In: YES 
user_id=965314

I don't know when the segmentation fault occurs. So I can't
write
a test case to reproduce it. That is when I work with my
program(which
is attached) after a some time(a few minutes or a few hours)
I receive
SIGSEGV.

I did not compile Tcl/Tk. And I used the default
configuration for
compiling Python2.5a2. The 'import sys; print
sys.maxunicode;' prints
65535 in both Python versions I've used.


Python 2.4.2

Python 2.4.2 (#1, Feb 12 2006, 03:59:46) 
[GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2

<<>>
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no
debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run ~/temp/rope/rope/rope.py 
Starting program: /usr/bin/python2.4 ~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...(no debugging symbols found)...done.
Loaded system supplied DSO at 0x8a8000
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208494416 (LWP 2121)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1211663456 (LWP 2124)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208494416 (LWP 2121)]
0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) bt
#0  0x0099e9ce in TkUndoSetDepth () from /usr/lib/libtk8.4.s

[ python-Bugs-1479586 ] Segmentation fault while using Tkinter

[SourceForge.net]

Bugs item #1479586, was opened at 2006-05-01 06:55
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479586&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ali Gholami Rudi (aligrudi)
Assigned to: Martin v. Löwis (loewis)
Summary: Segmentation fault while using Tkinter

Initial Comment:
While using Tkinter I encountere segmentation faults
regularly. I ran my program using gdb using python2.4
and Fedora Core 5 and received:

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1209063760 (LWP 2024)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread -1212232800 (LWP 2027)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type  to continue, or q  to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209063760 (LWP 2024)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb) 


I ran the same program using python2.5a2 and again
received:

Starting program: /usr/local/bin/python
~/temp/rope/rope/rope.py
Reading symbols from shared object read from target
memory...done.
Loaded system supplied DSO at 0xa05000
[Thread debugging using libthread_db enabled]
[New Thread -1208899920 (LWP 2415)]
[New Thread -1212068960 (LWP 2418)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208899920 (LWP 2415)]
0x001519ce in TkUndoSetDepth () from /usr/lib/libtk8.4.so
(gdb)


Are these information enough for fixing the problem or
should I send my program?

Thanks


--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-05-02 08:27

Message:
Logged In: YES 
user_id=21627

Apparently, this has something to do with the undo mechanism
of the text widget; I would expect the problem to go away if
you disable undo (text["undo"]=0). Other than that, there is
not much I can tell, from either looking at the source or at
the backtrace.

Most likely, it is some bug in Tcl/Tk. It also could be that
Python is corrupting memory somehow, and that this causes Tk
to crash.

If you want to debug this yourself, compile Tcl/Tk (with,
say, --prefix==/var/tmp). Use --disable-shared
--enable-symbols for both Tcl and Tk, then edit
Modules/Setup to statically link _tkinter into the Python
interpreter. Replace the -ltk8.2 line with an explict
/var/tmp/lib/libtk8.4g.a, to be sure that your version of tk
is used.

Then run it in a debugger, and find out why it crashes. Is
it really crashing inside TkUndoSetDepth? If so, what is the
value of stack? What is the value of maxdepth? What is the
Tcl command being executed (if Tcl_Eval is on the stack, go
up several times, and print the value of its string argument).

--

Comment By: Ali Gholami Rudi (aligrudi)
Date: 2006-05-02 07:25

Message:
Logged In: YES 
user_id=965314

I don't know when the segmentation fault occurs. So I can't
write
a test case to reproduce it. That is when I work with my
program(which
is attached) after a some time(a few minutes or a few hours)
I receive
SIGSEGV.

I did not compile Tcl/Tk. And I used the default
configuration for
compiling Python2.5a2. The 'import sys; print
sys.maxunicode;' prints
65535 in both Python versions I've used.


Python 2.4.2

Python 2.4.2 (#1, Feb 12 2006, 03:59:46) 
[GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2

<<>>
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no
debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run ~/temp/rope/rope/rope.py 
Starting program: /usr/bin/python2.4 ~/tem

[ python-Feature Requests-1474577 ] feature requests for logging lib

[SourceForge.net]

Feature Requests item #1474577, was opened at 2006-04-22 09:50
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&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: blaize rhodes (blaize)
Assigned to: Nobody/Anonymous (nobody)
Summary: feature requests for logging lib

Initial Comment:


The logger module interface is a bit broken, I reckon.
 My problems specifically are:
 
i) It's hard to get access to the LogRecord classes
for customization.
ii) the semantics of the debug, log, info, etc calls
is a bit strange/confusing...



Here are my proposed fixes:

a)  Add a method 
   Logger.setLogRecordClass( myLogRecordSubClass )

which sets the class that is instantiated in the
makeRecord() fn/method (yes there are two of them).

This would make customizing the LogRecord easier... 
Otherwise (I believe) in order to subclass the
LogRecord you also have to overload the Logger and
possibly the root makeRecord() function as well?  This
bloke's writen up his approach to this (it's doable but
not as nice as it should be).
 
http://qix.it/~ludoo/archive/2004/05/python_logging_customization.html

Another problem is that LogRecords are instantiated in
Logger._log so it's difficult to customize __init__
behaviour for the LogRecord (and I argue that this is a
useful thing)..  

b) A second problem is that the semantics of the log,
info, debug, etc fns is a bit broken.  Currently the
defn looks like this:

  def debug(self, msg, *args, **kwargs):

this suggests to me that a call like this is OK...

  logger.debug("here we go %(foo)s", foo = 'bar')

but it's not.  This is discussed further here...

http://groups.google.com.au/group/comp.lang.python/browse_thread/thread/322919fcac0113ec/98ceaf6fc0c56881?lnk=st&q=python+logging+keywords&rnum=1#98ceaf6fc0c56881

Instead kwargs are used for customizing the behaviour
of the debug method (e.g. exc_info, and extra).  This
seems i) a bit incongrous with its definition and
therefore confusing, and ii) a bit of a hack (it's not
completely insane though when you think about what's
happening under the hood).  Instead I propose using a
couple of calls along the lines of printf/fprintf.  In
my world we'd have a simple printf-style function... 

  def debug(self, msg, *args):  

and a more complex, more easily customizable
fprintf-style one

  def x_debug(self, log_record, msg, *args):  

In these calls *args is a valid argument for the string
formatting operator %, either a tuple of the right
length or a dictionary.  Any customization of the
behaviour of the system can be done (using keyword args
if you wish) in the log_record initializer (an example
will follow).

(Having said that perhaps we can check whether the
first arg to the new simple debug() is a logrecord and
if it is call the (hidden) extended version - that's
more pythonic I imagine)


c) This is not so much a feature request but a
motivating mode of operation that I'd like to be able
to use...

Currently you can set up log filters.  What you can
filter is largely based on what information appears in
the log record.  It'd be nice to filter messages based
on metadata  that you add at log time (i.e. in the
logger.debug(...) method).  Currently it's quite
painfull to set this up.  This is because we can't
customize the initialization of the log_record.  The
call structure in ii) above allows us to setup nice
filtering mechanisms
eg..

class GUIFilter:
   "A filter that only lets messges with gui tags
through."""
def filter(self, log_record):
return hasattr(log_record, 'gui')

# set up a log, and a handler...
log = logging.getLogger(..)
file_handler = FileHandler(..)
log.addHandler(file_handler)
gui_msg_bar_handler = StreamHandler(..)
log.addHandler(gui_msg_bar_handler)
gui_msg_bar_handler.addFilter(GUIFilter())

# msg only goes to the file_handler
log.debug("here we go %s", "here's an arg")  

# msg goes to the file_handler and to the gui_handler.
log.x_debug(LogRecord(gui=True), "what you just tried
to do didn't work %s", "fool")


Change a) could be made with no backward compatability
problems (I can see), change b) could be made without
probs if you didn't overload the existing logging
methods with the new ones, and then deprecate the
existing ones  (though what you'd call the new fns I
don't know).

That said I quite like the logger lib and I use it. 
It's a lot better than anything I would have thought up.


cheers
blaize



--

[ python-Bugs-1478529 ] size limit exceeded for read() from network drive

[SourceForge.net]

Bugs item #1478529, was opened at 2006-04-28 17:46
Message generated for change (Comment added) made by markshep
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: size limit exceeded for read() from network drive

Initial Comment:
If you've got a network share mounted as a local drive
then Windows has a limit of 67,076,095 (0x03ff7fff)
bytes for a read from an open file on that drive.

Running the python read() method on an open file larger
than this size throws an "IOError: [Errno 22] Invalid
argument" exception.

A fix would be for python to internally use multiple
reads so as to not exceed this limit.


--

>Comment By: Mark Sheppard (markshep)
Date: 2006-05-02 11:48

Message:
Logged In: YES 
user_id=1512331

I'm running Windows XP.  I've been unable to find any
documentation about this exact problem - only that fwrite
thing.  But my testing shows that it works if I do
file.read(67076095), but throws an exception with
file.read(67076096).

I'm not suggesting limiting all reads from Python.  All I'm
suggesting is that under the hood the Windows implementation
of Python's read() call actually uses multiple fread() (or
whatever) calls if more than 67076095 bytes need to be read.
 That's all.  No interface changes.


--

Comment By: Tim Peters (tim_one)
Date: 2006-04-30 17:23

Message:
Logged In: YES 
user_id=31435

Martin, here's an MS article seemingly related to this:

http://support.microsoft.com/default.aspx?scid=kb;en-us;899149

However, it's about writing to a file on a network drive,
not reading from it.  It says that opening the file in 'w+b'
mode, instead of 'wb' mode, is a workaround.

I couldn't find anything documenting the same kind of
problem for reading.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-30 11:10

Message:
Logged In: YES 
user_id=21627

What version of Windows are you using? Do you know of any
documentation of this limit? (without actually testing, I
find it hard to believe that this limit exists in Windows)

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-29 14:23

Message:
Logged In: YES 
user_id=849994

How can it be determined whether exactly this restriction
caused the "invalid argument" error? If it can't, there's
nothing that can be done -- restricting all reads just
because of a Windows limitation doesn't seem right.

--

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

[ python-Bugs-1478529 ] size limit exceeded for read() from network drive

[SourceForge.net]

Bugs item #1478529, was opened at 2006-04-28 18:46
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: size limit exceeded for read() from network drive

Initial Comment:
If you've got a network share mounted as a local drive
then Windows has a limit of 67,076,095 (0x03ff7fff)
bytes for a read from an open file on that drive.

Running the python read() method on an open file larger
than this size throws an "IOError: [Errno 22] Invalid
argument" exception.

A fix would be for python to internally use multiple
reads so as to not exceed this limit.


--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-05-02 21:00

Message:
Logged In: YES 
user_id=21627

I could reproduce the write problem on XPSP2; I get the
Win32 error ERROR_NO_SYSTEM_RESOURCES after fwrite returns
(from GetLastError).

I can't reproduce the fread problem, though: in Python,
f.read(90*2**20) just returns with a 90MiB string. So it
could be a limitation of your machine (e.g. it might not
have enough memory), or of the server machine. I'm hesitant
to add a work-around for that into Python if this isn't a
system limitation. Performing multiple reads is also bad:
what happens if the first read succeeds, and the second one
fails? It might be that the system *really* is out of resources.

--

Comment By: Mark Sheppard (markshep)
Date: 2006-05-02 12:48

Message:
Logged In: YES 
user_id=1512331

I'm running Windows XP.  I've been unable to find any
documentation about this exact problem - only that fwrite
thing.  But my testing shows that it works if I do
file.read(67076095), but throws an exception with
file.read(67076096).

I'm not suggesting limiting all reads from Python.  All I'm
suggesting is that under the hood the Windows implementation
of Python's read() call actually uses multiple fread() (or
whatever) calls if more than 67076095 bytes need to be read.
 That's all.  No interface changes.


--

Comment By: Tim Peters (tim_one)
Date: 2006-04-30 18:23

Message:
Logged In: YES 
user_id=31435

Martin, here's an MS article seemingly related to this:

http://support.microsoft.com/default.aspx?scid=kb;en-us;899149

However, it's about writing to a file on a network drive,
not reading from it.  It says that opening the file in 'w+b'
mode, instead of 'wb' mode, is a workaround.

I couldn't find anything documenting the same kind of
problem for reading.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-30 12:10

Message:
Logged In: YES 
user_id=21627

What version of Windows are you using? Do you know of any
documentation of this limit? (without actually testing, I
find it hard to believe that this limit exists in Windows)

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-29 15:23

Message:
Logged In: YES 
user_id=849994

How can it be determined whether exactly this restriction
caused the "invalid argument" error? If it can't, there's
nothing that can be done -- restricting all reads just
because of a Windows limitation doesn't seem right.

--

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

[ python-Bugs-1051840 ] HTMLParser doesn't treat endtags in

[SourceForge.net]

Bugs item #1051840, was opened at 2004-10-21 19:02
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1051840&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: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Luke Bradley (neptune235)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: HTMLParser doesn't treat endtags in  tags as CDATA

Initial Comment:
HTMLParser.HTMLParser in Python 2.3.4 calls
self.handle_endtag() for end tags within script and
style sections, which it should not, because the
content is supposed to be CDATA, as defined in
CDATA_CONTENT_ELEMENTS within HTMLParser. The following
script will demonstrate this problem:

import HTMLParser

class MyHandler(HTMLParser.HTMLParser):
tags = []
def handle_starttag(self, tag, attr):
self.tags.append(tag)
def handle_endtag(self, tag):
if tag != self.tags[-1]:
#this should never happen in a well formed
document
raise "Not well-formed, endtag '" + tag +
"' doesn't match starttag '" + self.lasttag + "'"
self.tags.pop(-1)

s = """
<html>
<body>
This page is completely well formed
<script language="javascript">
alert("</a></a>");

blah blah


"""

m = MyHandler()
m.feed(s)

This will raise an exception. I fixed the bug by
changing the parse_endtag function on line 318 of
HTMLParser to the following:

def parse_endtag(self, i):
rawdata = self.rawdata
assert rawdata[i:i+2] == "
if not match:
return -1
j = match.end()
match = endtagfind.match(rawdata, i) # 
if not match:
self.error("bad end tag: %s" % `rawdata[i:j]`)
tag = match.group(1)
#START BUGFIX
if self.interesting == interesting_cdata:
#we're in of of the CDATA_CONTENT_ELEMENTS
if tag == self.lasttag and tag in
self.CDATA_CONTENT_ELEMENTS:
#its the end of the CDATA_CONTENT_ELEMENTS
tag we are in.
self.handle_endtag(tag.lower())
self.clear_cdata_mode()#backto normal mode
else:
#we're inside the CDATA_CONTENT_ELEMENTS
tag still. throw the tag to handle_data instead.
self.handle_data(match.group())
else:
#we're not in a CDATA_CONTENT_ELEMENTS tag.
standard ending:
self.handle_endtag(tag.lower())
return j


--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-02 16:15

Message:
Logged In: YES 
user_id=3066

This is a common complaint (because no-one reads the specs),
but since people have lived with it this long, I'm inclined
to leave it alone.  If people want to read every two-bit
piece of broken HTML, they can use BeautifulSoup, which
handles that task quite nicely.

Rejecting as "don't go there."

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-10-23 20:46

Message:
Logged In: YES 
user_id=80475

Fred, what do you think?

--

Comment By: Luke Bradley (neptune235)
Date: 2004-10-22 19:52

Message:
Logged In: YES 
user_id=178561

Although a fix may be worthwhile, as this happens a lot in 
practice, HTMLParser is following the letter of the law in 
throwing exceptions on pages that aren't strictly valid. 

http://www.w3.org/TR/html4/appendix/notes.html#notes-
specifying-data

Well you're right, I'll be damned! 
Hmm. I want to use HTMLParser to access other people's pages
on the net, and I can't fix their bad HTML. The problem here
is I'm not sure how to handle this at the level of my
Handler, without inadvertantly changing thier javascript by
doing something like:
handle_data("")
in the handle_entag event. Which lowercases the tag. Is
there a way to access the literal string of the endtag in my
handler I wonder? If not, it might be useful to add some
functionality to HTMLParser that allows us to handle invalid
HTML at the level of our handler without sacrificing
HTMLParsers commitment to standards compliance. 

--

Comment By: Richard Brodie (leogah)
Date: 2004-10-22 14:02

Message:
Logged In: YES 
user_id=356893

Although a fix may be worthwhile, as this happens a lot in 
practice, HTMLParser is following the letter of the law in 
throwing exceptions on pages that aren't strictly valid. 

http://www.w3.org/TR/html4/appendix/notes.html#

[ python-Bugs-1076070 ] HTMLParser can't handle page with javascript

[SourceForge.net]

Bugs item #1076070, was opened at 2004-11-30 10:22
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076070&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: Wont Fix
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: HTMLParser can't handle page with javascript

Initial Comment:
Perhaps the page is malformed -- I notice at least one
other problem with it -- but I'd like to parse it. 
Relevant excerpts appear to be:


<!--
um.menuCode[i].replace(/<\/(li|ul)>/ig,'</$1>\n');
-->


goahead() identifies the next interesting part of the
page as the  inside the javascript.  It's not
seeing the comment.  Should it?  I changed
interesting_cdata to lookup for Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-02 16:20

Message:
Logged In: YES 
user_id=3066

The "

[ python-Bugs-1055864 ] HTMLParser not compliant to XHTML spec

[SourceForge.net]

Bugs item #1055864, was opened at 2004-10-28 00:59
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1055864&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: Luke Bradley (neptune235)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: HTMLParser not compliant to XHTML spec

Initial Comment:
HTMLParser has a problem related to the fact that is
doesn't seem to comply to the spec for XHTML. What I am
refering to can be read about here:
http://www.w3.org/TR/xhtml1/#h-4.8
In a nutshell, HTMLParser doesn't treat data inside
'script' or 'style' elements as #PCDATA, but rather
behaves like an HTML 4 parser even for XHTML documents,
parsing only end tags. As a result, entity references
in javascript are not converted as they should be.
XHTML authors writing to spec can expect entities in
script sections of XHTML documents to be converted if
the script is not explicitly escaped as a CDATA
section. which brings up problem two, That sections
explicitly escaped as CDATA are also parsed as HTML 4
'script' and 'style' sections...End tags are parsed...
My understanding is that this is bad as well:
http://www.w3.org/TR/2004/REC-xml-20040204/#dt-cdsection
because CDend is the only thing that's supposed to be
parsed in a CDATA section for all XML documents?



--

Comment By: Luke Bradley (neptune235)
Date: 2004-10-28 18:23

Message:
Logged In: YES 
user_id=178561

Sure. I'll attach it as a file: tidytest2.py

btw: I'm no guru so tell me if I'm misinterpretting the w3c.
I'm just trying to use HTMLParser in such a way that it
won't mangle anybodies script sections, and I want to have
all my bases covered.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-10-28 15:41

Message:
Logged In: YES 
user_id=21627

Can you give an example demonstrating this problem, please?
A Python script with a small embedded HTML file, and a
PASS/FAIL condition would be best.

--

Comment By: Luke Bradley (neptune235)
Date: 2004-10-28 04:31

Message:
Logged In: YES 
user_id=178561

I also reported bug 1051840. I discovered this when I was
looking for a universal way to handle all the wierd things
people do with their script sections on HTML/XHTML pages on
the net. I've ended up modifying HTMLParser.py so that the
HTMLParser class has an extra attribute called last_match,
which is the exact string of HTML that whatever handler
event  is being called for...So that putting:
sys.stdout.write(self.last_match) 
or
sys.stdout.write(self.get_last_match())
for every handler event (except handle_data, which can be
directly outputted) will output the page exactly as was
inputted. This allows me to handle all oddities in people's
code at the level of my handler, without changing HTMLParser
in any other way...
Here's the code, attached. Not that you care, but on the off
chance that you guys might want to think about doing
something like this:)

--

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

[ python-Bugs-1480678 ] mmap tries to truncate special files

[SourceForge.net]

Bugs item #1480678, was opened at 2006-05-02 16:56
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=1480678&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: Carl Banks (aerojockey)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap tries to truncate special files

Initial Comment:
One Unix, the resize() method of an mmap object calls
ftruncate to also resize the associated file.  Problem
is, ftruncate fails if the fd refers to a special file.
 This is a problem for someone trying to resize an
anonymous memory map using /dev/zero.

Apparently hasn't been fixed in 2.5 (based on SVN and
changelogs) but I haven't tested it.

--

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

[ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells

[SourceForge.net]

Bugs item #1465014, was opened at 2006-04-05 11:14
Message generated for change (Comment added) made by goodger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&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: 9
Submitted By: David Goodger (goodger)
Assigned to: Nobody/Anonymous (nobody)
Summary: CSV regression in 2.5a1: multi-line cells

Initial Comment:
Running the attached csv_test.py under Python 2.4.2
(Windows XP SP1) produces:

>c:\apps\python24\python.exe ./csv_test.py
['one', '2', 'three (line 1)\n(line 2)']

Note that the third item in the row contains a newline
between "(line 1)" and "(line 2)".

With Python 2.5a1, I get:

>c:\apps\python25\python.exe ./csv_test.py
['one', '2', 'three (line 1)(line 2)']

Notice the missing newline, which is significant.  The
CSV module under 2.5a1 seems to lose data.


--

>Comment By: David Goodger (goodger)
Date: 2006-05-02 16:58

Message:
Logged In: YES 
user_id=7733

Further investigation has revealed that the regression only
affects iterator I/O, not file I/O.  The attached
csv_test.py demonstrates.  Run with Python 2.5 to get:

results from file I/O:
[['one', '2', 'three (line 1)\n(line 2)']]

results from iterator I/O:
[['one', '2', 'three (line 1)(line 2)']]

--

Comment By: David Goodger (goodger)
Date: 2006-04-05 11:44

Message:
Logged In: YES 
user_id=7733

This bug seems to be a side effect of revision 38290 on
Modules/_csv.c, which was prompted by bug 967934
(http://www.python.org/sf/967934).

--

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

[ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells

[SourceForge.net]

Bugs item #1465014, was opened at 2006-04-05 11:14
Message generated for change (Comment added) made by goodger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&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: 9
Submitted By: David Goodger (goodger)
>Assigned to: Andrew McNamara (andrewmcnamara)
Summary: CSV regression in 2.5a1: multi-line cells

Initial Comment:
Running the attached csv_test.py under Python 2.4.2
(Windows XP SP1) produces:

>c:\apps\python24\python.exe ./csv_test.py
['one', '2', 'three (line 1)\n(line 2)']

Note that the third item in the row contains a newline
between "(line 1)" and "(line 2)".

With Python 2.5a1, I get:

>c:\apps\python25\python.exe ./csv_test.py
['one', '2', 'three (line 1)(line 2)']

Notice the missing newline, which is significant.  The
CSV module under 2.5a1 seems to lose data.


--

>Comment By: David Goodger (goodger)
Date: 2006-05-02 17:04

Message:
Logged In: YES 
user_id=7733

Assigned to Andrew McNamara, since his change appears to
have caused this regression (revision 38290 on
Modules/_csv.c).

--

Comment By: David Goodger (goodger)
Date: 2006-05-02 16:58

Message:
Logged In: YES 
user_id=7733

Further investigation has revealed that the regression only
affects iterator I/O, not file I/O.  The attached
csv_test.py demonstrates.  Run with Python 2.5 to get:

results from file I/O:
[['one', '2', 'three (line 1)\n(line 2)']]

results from iterator I/O:
[['one', '2', 'three (line 1)(line 2)']]

--

Comment By: David Goodger (goodger)
Date: 2006-04-05 11:44

Message:
Logged In: YES 
user_id=7733

This bug seems to be a side effect of revision 38290 on
Modules/_csv.c, which was prompted by bug 967934
(http://www.python.org/sf/967934).

--

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

[ python-Bugs-1478529 ] size limit exceeded for read() from network drive

[SourceForge.net]

Bugs item #1478529, was opened at 2006-04-28 12:46
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows
>Group: 3rd Party
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: size limit exceeded for read() from network drive

Initial Comment:
If you've got a network share mounted as a local drive
then Windows has a limit of 67,076,095 (0x03ff7fff)
bytes for a read from an open file on that drive.

Running the python read() method on an open file larger
than this size throws an "IOError: [Errno 22] Invalid
argument" exception.

A fix would be for python to internally use multiple
reads so as to not exceed this limit.


--

>Comment By: Tim Peters (tim_one)
Date: 2006-05-02 21:45

Message:
Logged In: YES 
user_id=31435

Sorry, I'm closing this as "3rd Party, Won't Fix".  It's
certainly not Python's doing that Microsoft's stdio
implementation has peculiar undocumented warts (Python just
calls the platform C's fread() here), so at best this is a
request for enhancement rather than a Python bug.

If there is a bug here, it's Microsoft's bug, and then the
proper source for a fix is also Microsoft.  This is
especially true since the two people who have tried this
here don't see the same behavior -- we don't even know what
"the bug" is.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-05-02 15:00

Message:
Logged In: YES 
user_id=21627

I could reproduce the write problem on XPSP2; I get the
Win32 error ERROR_NO_SYSTEM_RESOURCES after fwrite returns
(from GetLastError).

I can't reproduce the fread problem, though: in Python,
f.read(90*2**20) just returns with a 90MiB string. So it
could be a limitation of your machine (e.g. it might not
have enough memory), or of the server machine. I'm hesitant
to add a work-around for that into Python if this isn't a
system limitation. Performing multiple reads is also bad:
what happens if the first read succeeds, and the second one
fails? It might be that the system *really* is out of resources.

--

Comment By: Mark Sheppard (markshep)
Date: 2006-05-02 06:48

Message:
Logged In: YES 
user_id=1512331

I'm running Windows XP.  I've been unable to find any
documentation about this exact problem - only that fwrite
thing.  But my testing shows that it works if I do
file.read(67076095), but throws an exception with
file.read(67076096).

I'm not suggesting limiting all reads from Python.  All I'm
suggesting is that under the hood the Windows implementation
of Python's read() call actually uses multiple fread() (or
whatever) calls if more than 67076095 bytes need to be read.
 That's all.  No interface changes.


--

Comment By: Tim Peters (tim_one)
Date: 2006-04-30 12:23

Message:
Logged In: YES 
user_id=31435

Martin, here's an MS article seemingly related to this:

http://support.microsoft.com/default.aspx?scid=kb;en-us;899149

However, it's about writing to a file on a network drive,
not reading from it.  It says that opening the file in 'w+b'
mode, instead of 'wb' mode, is a workaround.

I couldn't find anything documenting the same kind of
problem for reading.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-30 06:10

Message:
Logged In: YES 
user_id=21627

What version of Windows are you using? Do you know of any
documentation of this limit? (without actually testing, I
find it hard to believe that this limit exists in Windows)

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-29 09:23

Message:
Logged In: YES 
user_id=849994

How can it be determined whether exactly this restriction
caused the "invalid argument" error? If it can't, there's
nothing that can be done -- restricting all reads just
because of a Windows limitation doesn't seem right.

--

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

[ python-Bugs-616013 ] cPickle documentation incomplete

[SourceForge.net]

Bugs item #616013, was opened at 2002-09-28 21:21
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=616013&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: Guido van Rossum (gvanrossum)
>Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle documentation incomplete

Initial Comment:
Many of the differences between the cPickle module and
the pickle module appear undocumented, despite a claim
in the cPickle module that the pickle docs explain the
differences.

For example, I just found that cPickle.Pickler() can be
called without a file argument, which makes it use an
internal list to store the pickled data; and that in
that case it has a method getvalue() that returns the
contents of that list as a string; and that its dump()
method takes a second argument which, if true, calls
the getvalue() method.  Who knows what else it supports.

Someone should go over the cPickle source and compare
the API *carefully* with the documented pickle API.

--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-05-02 22:14

Message:
Logged In: YES 
user_id=3066

Unassigning myself; clearly, I've not had time for this.

--

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

[ python-Bugs-1471407 ] setup.py --help-commands exception

[SourceForge.net]

Bugs item #1471407, was opened at 2006-04-16 12:23
Message generated for change (Comment added) made by jwpye
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1471407&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: Distutils
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: James William Pye (jwpye)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup.py --help-commands exception

Initial Comment:
>From a recent trunk build(2.5a1) on FreeBSD 6.1:

[EMAIL PROTECTED]:/src/org/pgfoundry/python/fe/local %
/usr/dev/bin/python ./setup.py --help-commands
Standard commands:
  buildbuild everything needed to install
  build_py "build" pure Python modules (copy to
build directory)
  build_extbuild C/C++ extensions (compile/link
to build directory)
  build_clib   build C/C++ libraries used by Python
extensions
  build_scripts"build" scripts (copy and fixup #! line)
  cleanclean up temporary files from
'build' command
  install  install everything from build directory
  install_lib  install all Python modules
(extensions and pure Python)
  install_headers  install C/C++ header files
  install_scripts  install scripts (Python or otherwise)
  install_data install data files
  sdistcreate a source distribution
(tarball, zip file, etc.)
Traceback (most recent call last):
  File "./setup.py", line 52, in 
setup(defaults)
  File "./setup.py", line 46, in setup
d = distutils.core.setup(**kw)
  File "/usr/dev/lib/python2.5/distutils/core.py", line
137, in setup
ok = dist.parse_command_line()
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
455, in parse_command_line
if self.handle_display_options(option_order):
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
680, in handle_display_options
self.print_commands()
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
758, in print_commands
max_length)
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
720, in print_command_list
klass = self.get_command_class(cmd)
  File "/usr/dev/lib/python2.5/distutils/dist.py", line
851, in get_command_class
raise DistutilsModuleError("invalid command '%s'" %
command)
distutils.errors.DistutilsModuleError: invalid command
'register'

--

>Comment By: James William Pye (jwpye)
Date: 2006-05-02 19:59

Message:
Logged In: YES 
user_id=1044177

k, svn update'd and it looks good.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-01 13:25

Message:
Logged In: YES 
user_id=849994

It looks like the "distutils.command.register" module is not
importable. Can you retry with alpha2 and see if the problem
persists?

--

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

[ python-Bugs-1480678 ] mmap tries to truncate special files

[SourceForge.net]

Bugs item #1480678, was opened at 2006-05-02 13:56
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&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: Carl Banks (aerojockey)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap tries to truncate special files

Initial Comment:
One Unix, the resize() method of an mmap object calls
ftruncate to also resize the associated file.  Problem
is, ftruncate fails if the fd refers to a special file.
 This is a problem for someone trying to resize an
anonymous memory map using /dev/zero.

Apparently hasn't been fixed in 2.5 (based on SVN and
changelogs) but I haven't tested it.

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-02 22:21

Message:
Logged In: YES 
user_id=33168

I don't understand what the problem is.  ISTM if you resize
a special file an exception will be raised.  Is that not the
case?  What do you expect to happen?

--

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

[ python-Bugs-680577 ] urllib2 authentication problem

[SourceForge.net]

Bugs item #680577, was opened at 2003-02-05 00:22
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680577&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: Fixed
Priority: 5
Submitted By: GaryD (gazzadee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 authentication problem

Initial Comment:
I've found a problem using the authentication in urllib2.

When matching up host-names in order to find a
password, then putting the protocol in the address
makes it seem like a different address. eg...

I create a HTTPBasicAuthHandler with a
HTTPPasswordMgrWithDefaultRealm, and add the tuple
(None, "http://proxy.blah.com:17828";, "foo", 
"bar") to it.

I then setup the proxy to use
http://proxy.blah.com:17828 (which requires
authentication).

When I connect, the password lookup fails, because it
is trying to find a match for "proxy.blah.com:17828"
rather than "http://proxy.blah.com:17828";

This problem doesn't exist if I pass
"proxy.blah.com:17828" to the password manager.

There seems to be some stuff in HTTPPasswordMgr to deal
with variations on site names, but I guess it's not
working in this case (unless this is intentional).

Version Info:
Python 2.2 (#1, Feb 24 2002, 16:21:58)
[GCC 2.96 2731 (Mandrake Linux 8.2 2.96-0.76mdk)]
on linux-i386


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 05:33

Message:
Logged In: YES 
user_id=849994

Closing accordingly.

--

Comment By: John J Lee (jjlee)
Date: 2006-04-15 18:45

Message:
Logged In: YES 
user_id=261020

This issue is fixed by patch 1470846.


--

Comment By: John J Lee (jjlee)
Date: 2003-12-16 12:49

Message:
Logged In: YES 
user_id=261020

Thanks! 
 
It seems .reduce_uri() tries to cope with hostnames as well as 
absoluteURIs.  I don't understand why it wants to do that, but it 
fails, because it doesn't anticipate what urlparse does when a 
port is present: 
 
>>> urlparse.urlparse("foo.bar.com") 
('', '', 'foo.bar.com', '', '', '') 
>>> urlparse.urlparse("foo.bar.com:80") 
('foo.bar.com', '', '80', '', '', '') 
 
I haven't checked, but I assume it's just incorrect use of 
urlparse to pass it a hostname. 
 
Of course, if it's "fixed" to only accept absoluteURIs, it will 
break existing code, so I guess it must be fixed for 
hostnames. :-(( 
 
Also, I think .is_suburi("/foo/spam", "/foo/eggs") should 
return 
False, but returns True, and .http_error_40x() use 
req.get_host() when they should be using req.get_full_url() 
(from a quick look at RFC 2617). 

--

Comment By: GaryD (gazzadee)
Date: 2003-12-16 03:10

Message:
Logged In: YES 
user_id=693152

Okay, I have attached a file that replicates this problem.

If you run it as is (replacing the proxy name and address
with something suitable), then it will fail (requiring proxy
authentication).

If you uncomment line 23 (which specifies the password
without the scheme), then it will work successfully.

Technical Info:
 * For a proxy, I am using Squid Cache version 2.4.STABLE7
for i586-mandrake-linux-gnu...
 * I have replicated the problem with Python 2.2.2 on Linux,
and Python 2.3.2 on Windows XP.

--

Comment By: GaryD (gazzadee)
Date: 2003-12-16 02:08

Message:
Logged In: YES 
user_id=693152

This was a while ago, and my memory has faded. I'll try to
respond intelligently.

I think the question was with the way the password manager
looks up passwords, rather than anything else.

I am pretty sure that the problem is not to do with the URI
passed to urlopen(). In the code shown below, the problem
was solely dependent on whether I added the line:
(None, "blah.com:17828", "foo", "bar")
...to the HTTPPasswordMgrWithDefaultRealm object.

If that password set was added, then the password lookup for
the proxy was successful, and urlopen() worked. If that
password set was not included, then the password lookup for
the proxy was unsuccessful (despite the inclusion of the
other 2, similar, password sets - "http://blah.com:17828";
and "blah.com"), and urlopen() would fail. Hence my
suspicion that the

[ python-Feature Requests-1448934 ] urllib2+https+proxy not working

[SourceForge.net]

Feature Requests item #1448934, was opened at 2006-03-13 15:55
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1448934&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: Rui Martins (ruibmartins)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2+https+proxy not working

Initial Comment:
Using urllib2 to access an https site using a proxy 
doesn't work. It always returns " "

I've been looking around for bug reports on this and 
code samples, but all that I've got were emails/forum 
posts dating back to 2003 warning that the HTTPS over 
Proxy in urllib2 isn't implemented in Python!

Is this true?

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 05:33

Message:
Logged In: YES 
user_id=849994

Moving to Feature Requests.

--

Comment By: John J Lee (jjlee)
Date: 2006-04-15 17:27

Message:
Logged In: YES 
user_id=261020

Yes, there is no special support for using https proxies
(via the CONNECT method) in httplib or urllib2.

http://python.org/sf/515003 shows how to do it, but the
patch is not good enough to be added to the standard
library.  Feel free to write a better patch!

Please close this, since it's really a feature request, not
a bug.


------

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

[ python-Bugs-1436428 ] urllib has trouble with Windows filenames

[SourceForge.net]

Bugs item #1436428, was opened at 2006-02-22 06:03
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&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: Wont Fix
Priority: 5
Submitted By: Donovan Eastman (dpeastman)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib has trouble with Windows filenames

Initial Comment:
When you pass urllib the name of a local file including
a Windows drive letter (e.g. 'C:\dir\My File.txt')
URLopener.open() incorrectly interprets the drive
letter as the scheme of a URL.  Of course, given that
there is no scheme 'C', this fails.

I have solved this in my own code by putting the
following test before calling urllib.urlopen():

if url[1] == ':' and url[0].isalpha():
url = 'file:' + url

Although this works fine in my particular case, it
seems like urllib should just simply "do the right
thing" without having to worry about it.  Therefore I
propose that urllib should automatically assume that
any URL that begins with a single alpha followed by a
colon is a local file.

The only potential downside would be that it would
preclude the use of single letter scheme names.  I did
a little research on this.  RFC 3986 suggests, but does
not explicitly state that scheme names must be more
than one character.
(http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#scheme)
.  That said, there are no currently recognized single
letter scheme names
(http://www.iana.org/assignments/uri-schemes.html) and
it seems very unlikely that there every would be.

I would gladly write the code for this myself -- but I
suspect that it would take someone longer to review and
integrate my changes than it would to just write the code.

Thanks,
Donovan


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 05:35

Message:
Logged In: YES 
user_id=849994

I agree with zseil.

--

Comment By: Žiga Seilnacht (zseil)
Date: 2006-04-13 00:12

Message:
Logged In: YES 
user_id=1326842

There are already two platform specific functions
in urllib module just for this purpose: pathname2url
and url2pathname. See
http://docs.python.org/lib/module-urllib.html#l2h-3193.
I agree that this should be closed as invalid.

--

Comment By: Andrew Clover (bobince)
Date: 2006-03-20 17:41

Message:
Logged In: YES 
user_id=311085

Filepaths aren't URIs and attempting to hide the difference
in the backend is doomed to fail (as it did for SAX).

Throw filenames with colons in, network paths, Mac paths and
RISC OS paths into the mix, and you've got a situation where
it is all but impossible to handle correctly.

In any case, the docs *don't* say you can pass in a filepath:

  If the URL does not have a scheme identifier, or if
  it has file: as its scheme identifier, this opens a
  local file

This means the string you pass in is unequivocally a URL
*not* a pathname... just that you can leave the scheme
prefix off for file: URLs. Effectively this is a relative URL.

r'C:\spam' is *not* a valid way to refer to a local file
using a relative URL. Pass it through pathname2url and
you'll get '///C|/spam', which is okay; 'C|/spam' and
'/C|span' will also work.

Even on Unix, a filepath won't always work when passed to
urlopen. Filenames can have percent signs in, which have to
be encoded in URLs, for example. Always use pathname2url or
you're going to trip up.

(Suggest setting status INVALID, possible clarification to
docs to warn against passing a filepath to urlopen?)


--

Comment By: Donovan Eastman (dpeastman)
Date: 2006-03-14 02:32

Message:
Logged In: YES 
user_id=757799

OK - Here's my suggested fix:
This can be fixed with a single if statement (and a comment
to explain it to confused unix programmers).

In splittype(), right after the line that reads: 
scheme = match.group(1)
add the following:
#ignore single char schemes to avoid confusion with win32
drive letters
if len(scheme) > 1:

...and indent the next line.

Alternatively, the if statement could read:
if len(scheme) > 1 or sys.platform != 'win32':
...which would allow single letter scheme names on
non-Windows systems.  I would argue that it is better to be
consistent and have it work the same way on all OS's.

--

Comment By: Donovan Eastman (dpeastman)
Dat

[ python-Bugs-1480678 ] mmap tries to truncate special files

[SourceForge.net]

Bugs item #1480678, was opened at 2006-05-02 16:56
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&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: Carl Banks (aerojockey)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap tries to truncate special files

Initial Comment:
One Unix, the resize() method of an mmap object calls
ftruncate to also resize the associated file.  Problem
is, ftruncate fails if the fd refers to a special file.
 This is a problem for someone trying to resize an
anonymous memory map using /dev/zero.

Apparently hasn't been fixed in 2.5 (based on SVN and
changelogs) but I haven't tested it.

--

>Comment By: Tim Peters (tim_one)
Date: 2006-05-03 02:13

Message:
Logged In: YES 
user_id=31435

Ya, this isn't a bug:  resize() is documented as changing
the size of _both_ the map and the file.  If the size of the
file can't be changed, then of course resize() will fail.

aerojockey:  can't you simply close your current map and
create a new map with the size you want?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-03 01:21

Message:
Logged In: YES 
user_id=33168

I don't understand what the problem is.  ISTM if you resize
a special file an exception will be raised.  Is that not the
case?  What do you expect to happen?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&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-1476166 ] Add SeaMonkey to webbrowser.py

[SourceForge.net]

Feature Requests item #1476166, was opened at 2006-04-25 18:32
Message generated for change (Comment added) made by phd
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: Accepted
Priority: 5
Submitted By: Oleg Broytmann (phd)
>Assigned to: Georg Brandl (gbrandl)
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().

--

>Comment By: Oleg Broytmann (phd)
Date: 2006-05-03 13:26

Message:
Logged In: YES 
user_id=4799

Sorry, I should check webbrowser.py more careful. Please add
"seamonkey" after

if sys.platform[:3] == "win":
...

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 20:31

Message:
Logged In: YES 
user_id=849994

Added in rev. 45780.

--

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-1478529 ] size limit exceeded for read() from network drive

[SourceForge.net]

Bugs item #1478529, was opened at 2006-04-28 17:46
Message generated for change (Comment added) made by markshep
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows
Group: 3rd Party
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: size limit exceeded for read() from network drive

Initial Comment:
If you've got a network share mounted as a local drive
then Windows has a limit of 67,076,095 (0x03ff7fff)
bytes for a read from an open file on that drive.

Running the python read() method on an open file larger
than this size throws an "IOError: [Errno 22] Invalid
argument" exception.

A fix would be for python to internally use multiple
reads so as to not exceed this limit.


--

>Comment By: Mark Sheppard (markshep)
Date: 2006-05-03 11:38

Message:
Logged In: YES 
user_id=1512331

Thanks for closing this bug without giving me a chance to
follow up!

The problem isn't caused by a limitation of my machine -
it's got 3 GiB of RAM.

I've done some more testing on this and the problem only
appears when connected to a server running certain SMB
implementations:

  The local Windows XP machine
  A remote Windows XP machine
  Samba 3.0.22 on Linux

When connected to servers running the following SMB
implementations the problem isn't present:

  Windows NT 4.0 Server
  Windows Server 2000
  Windows Server 2003 Standard Edition

As this error is being returned by the underlying fread()
call the proper place for it to be fixed is there, but the
chances of Microsoft doing so for Windows XP are negligible.

As you're trying to provide a cross-platform language then
having to put up with OS's undocumented warts is just part
of the job.  As it's entirely possible for you to implement
a work-around for this problem Python I think you should. 
One of reasons for using a high level language like Python
is to be insulated from system quirks likes this.  If you're
refusing to smooth over these quirks where possible then
you're undermining that reason.

The documentation for Python's read() method on a file
handle already says "Note that this method may call the
underlying C function fread() more than once", so this
possibility is already catered for in the documentation.

As this problem only affects remotely mounted filesystems
the workaround need only be used for such filesystems.  You
can determine whether or not a drive is a network one by
using the GetDriveType() Windows call.


--

Comment By: Tim Peters (tim_one)
Date: 2006-05-03 02:45

Message:
Logged In: YES 
user_id=31435

Sorry, I'm closing this as "3rd Party, Won't Fix".  It's
certainly not Python's doing that Microsoft's stdio
implementation has peculiar undocumented warts (Python just
calls the platform C's fread() here), so at best this is a
request for enhancement rather than a Python bug.

If there is a bug here, it's Microsoft's bug, and then the
proper source for a fix is also Microsoft.  This is
especially true since the two people who have tried this
here don't see the same behavior -- we don't even know what
"the bug" is.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-05-02 20:00

Message:
Logged In: YES 
user_id=21627

I could reproduce the write problem on XPSP2; I get the
Win32 error ERROR_NO_SYSTEM_RESOURCES after fwrite returns
(from GetLastError).

I can't reproduce the fread problem, though: in Python,
f.read(90*2**20) just returns with a 90MiB string. So it
could be a limitation of your machine (e.g. it might not
have enough memory), or of the server machine. I'm hesitant
to add a work-around for that into Python if this isn't a
system limitation. Performing multiple reads is also bad:
what happens if the first read succeeds, and the second one
fails? It might be that the system *really* is out of resources.

--

Comment By: Mark Sheppard (markshep)
Date: 2006-05-02 11:48

Message:
Logged In: YES 
user_id=1512331

I'm running Windows XP.  I've been unable to find any
documentation about this exact problem - only that fwrite
thing.  But my testing shows that it works if I do
file.read(67076095), but throws an exception with
file.read(67076096).

I'm not suggesting limiting all reads from Python.  All I'm
suggesting is that u

[ python-Feature Requests-1481036 ] IOBaseError

[SourceForge.net]

Feature Requests item #1481036, was opened at 2006-05-03 14:04
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=1481036&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: IOBaseError

Initial Comment:
Maybe there should be a common base Exception class
"IOBaseError" for :   EnvironmentError(IOError,
OSError),  EOFError, socket.error, socket.sslerror,
ftplib.all_errors, etc.  

Nice as it and not all IO sublibs have to be imported
to catch such errors.

See a recent need in patch #1481032 . I have this need
very often in mixed IO apps and am forced to except
naked (and being exposed to pythonic AttribError's etc. )

-robert

--

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

[ python-Bugs-1417699 ] float/atof have become locale aware

[SourceForge.net]

Bugs item #1417699, was opened at 2006-01-29 01:04
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Martin v. Löwis (loewis)
Summary: float/atof have become locale aware

Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:

Python 2.4.2 (#1, Nov 29 2005, 16:07:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5


This doesn't match what's specified in pep 331:

- float() and str() stay locale-unaware.

It also doesn't match the documentation for atof:

  Convert a string to a floating point number.
  The string must have the standard syntax for a
  floating point literal in Python, optionally
  preceded by a sign ("+" or "-"). Note that this
  behaves identical to the built-in function float()
  when passed a string.

The documentation for float() doesn't state which
format is accepted by float(), though.

The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:

  This function behaves like the standard strtod() 
  function does in the C locale.




--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 12:19

Message:
Logged In: YES 
user_id=1188172

Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?

--

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

[ python-Bugs-1448042 ] Defining a class with __dict__ brakes attributes assignment

[SourceForge.net]

Bugs item #1448042, was opened at 2006-03-11 22:49
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&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: None
>Status: Closed
>Resolution: Wont Fix
Priority: 6
Submitted By: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defining a class with __dict__ brakes attributes assignment

Initial Comment:
When defining a class with __dict__ attribute, its 
instances can't rebind their __dict__ attributes.

--

class C(object): __dict__ = {}

obj = C()
obj.a = object()

import gc
gc.get_referrers(obj.a) # => [{'a': }]

obj.__dict__ = {} # doesn't really bind new __dict__

vars(obj) # => {}
object.__getattribute__(obj, '__dict__') # => {}
object.__getattribute__(C, '__dict__') # => {..., but 
without "a"}
obj.a  # =>  (no exception
!)

gc.get_referrers(obj.a) # => [{'a': , '__dict__': {}}]

--

Although neither class nor object has an attribute "a", 
it's still accessible. It's also not possible to rebind 
__dict__ in that object, as it gets inside real object 
attributes dictionary.

This behaviour has been tested on Python 2.2, 2.3 and 
2.4, but may as well affect earlier versions.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 17:39

Message:
Logged In: YES 
user_id=849994

Okay, Armin Rigo and zseil convinced me that this is not a bug.

--

Comment By: Žiga Seilnacht (zseil)
Date: 2006-03-19 13:50

Message:
Logged In: YES 
user_id=1326842

Maybe this shows that it is actually a feature?

>>> class C(object):
... pass
...

'__dict__' is not a normal attribute, it's a descriptor
(a "getset_descriptor") generated by object's type.
You can get to this object if you try hard enough:

>>> C_dict_descriptor = C.__dict__['__dict__']
>>> type(C_dict_descriptor).__name__
'getset_descriptor'

This descriptor is automatically created for most of the
python classes (except for those, that have __slots__
without __dict__) by 'type' object.

Since 'type' is an instance of itself, it also has it:

>>> type_dict_descriptor = type.__dict__['__dict__']

And we can see, that it is responsible for creating
the C's __dict__ attribute:

>>> C.__dict__ == type_dict_descriptor.__get__(C, type)
True

As is normal for most of the special named attributes,
this one is looked up in object's type, not in its dict,
and it isn't a normal dict, but a dictproxy:

>>> type(C.__dict__).__name__
'dictproxy'

Now in your case, you create a class attribute '__dict__':

>>> class D(C):
... __dict__ = {'a': 1}
...

Which basically does something like:

>>> name = 'E'
>>> bases = (C,)
>>> E_namespace = {
... '__dict__': {'a': 1},
... '__doc__': "set to None by type if not provided",
... '__module__': "globals()['__name__'] if missing",
... '__weakref__': "another descriptor",
... }
>>> E = type(name, bases, E_namespace)

The '__dict__' attribute of this class is still provided by
its type (type 'type'), and is basicaly just a dictproxy of
the E_namespace:

>>> type(E.__dict__).__name__
'dictproxy'
>>> E.__dict__ == E_namespace
True

What your class definition actually did, is it has
overwritten the __dict__ descriptor that would be
normaly created by type; compare:

>>> C.__dict__['__dict__']

>>> E.__dict__['__dict__']
{'a': 1}

Now watch what happens if you create an instance of E class:
>>> e = E()
>>> e.__dict__
{'a': 1}
>>> e.a = 2
>>> e.__dict__
{'a': 1}

Basically, now the '__dict__' attribute is a normal
attribute, that behaves just as any other attribute,
while you have lost acces to the instance's inner dict:

>>> e.__dict__ = {}
>>> e.__dict__
{}
>>> e.a
2

If you inherit directly from object, which doesn't have
this descriptor:

>>> object.__dict__['__dict__']
Traceback (most recent call last):
  File "", line 1, in ?
KeyError: '__dict__'

there wou

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

[SourceForge.net]

Feature Requests item #1476166, was opened at 2006-04-25 14:32
Message generated for change (Comment added) made by gbrandl
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: Closed
Resolution: Accepted
Priority: 5
Submitted By: Oleg Broytmann (phd)
Assigned to: Georg Brandl (gbrandl)
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().

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 17:46

Message:
Logged In: YES 
user_id=849994

Done in  r45889.

--

Comment By: Oleg Broytmann (phd)
Date: 2006-05-03 09:26

Message:
Logged In: YES 
user_id=4799

Sorry, I should check webbrowser.py more careful. Please add
"seamonkey" after

if sys.platform[:3] == "win":
...

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-28 16:31

Message:
Logged In: YES 
user_id=849994

Added in rev. 45780.

------

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-Feature Requests-1472176 ] "idna" encoding (drawing unicodedata) necessary in httplib?

[SourceForge.net]

Feature Requests item #1472176, was opened at 2006-04-18 09:28
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&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: Accepted
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: "idna" encoding (drawing unicodedata) necessary in httplib?

Initial Comment:
httplib employs the "idna" encoding. that leads to
errors in py2exe/cxfreeze. And if forced into the
installer, it draws the 400kB+ unicodedata.pyd (on Win)
in innocent small apps. Otherwise no normal technical
modules draw the unicodedata.

Is that really necessary?



--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 18:03

Message:
Logged In: YES 
user_id=849994

Slightly reformatted version of patch applied in rev. 45890.

--

Comment By: kxroberto (kxroberto)
Date: 2006-04-19 09:41

Message:
Logged In: YES 
user_id=972995

a patch attached

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-18 09:59

Message:
Logged In: YES 
user_id=38388

I agree - in most cases, ASCII will be used for hostnames
(where the idna encoding is being used in httplib). 

A little helper function to first try .encode('ascii') and
then revert to .encode('idna') would do wonders.

Patches are welcome !

------

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

[ python-Bugs-1472191 ] pdb 'clear' command doesn't clear selected bp's

[SourceForge.net]

Bugs item #1472191, was opened at 2006-04-18 09:49
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472191&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: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Kuba Kończyk (jakamkon)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb 'clear' command doesn't clear selected bp's

Initial Comment:
 Pdb 'clear x' command doesn't clear selected breakpoints
that are already set:

$ ./python -m pdb ../test.py
> /home/xyz/python/test.py(3)()
-> def t(x):
(Pdb) break 5
Breakpoint 1 at /home/xyz/python/test.py:5
(Pdb) break
Num Type Disp Enb Where
1 breakpoint keep yes at /home/xyz/python/test.py:5
(Pdb) clear 1
No breakpoint numbered 1
(Pdb)
...
for i in numberlist:
* if not (0 <= i < len(bdb.Breakpoint.bpbynumber)):
print 'No breakpoint numbered', i
...

Each i is a string and it's compared to 0 and len(...),
so condition * is always True.
The fix is trivial:
* if not (0 <= int(i) < len(bdb.Breakpoint.bpbynumber)):
Fix is in #1472184

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 18:13

Message:
Logged In: YES 
user_id=849994

Thanks for the report. This is fixed in rev. 45891, 45892(2.4).

Additionally, for such small changes please do not file a
bug and a patch report. Opening just one bug and attaching
the patch is fine.

------

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

[ python-Bugs-1385040 ] compiler module does not detect a syntax error

[SourceForge.net]

Bugs item #1385040, was opened at 2005-12-19 09:58
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1385040&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: Parser/Compiler
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler module does not detect a syntax error

Initial Comment:
import compiler 
compiler.parse("def foo(a=1,b): pass") 
 
Gives: 
 
Module(None, Stmt([Function(None, 'foo', ['a', 'b'], 
[Const(1)], 0, None, Stmt([Pass()]))])) 
 
However, the python interpreter itself barks for the 
same code: 
 
SyntaxError: non-default argument follows default 
argument 
 
 
-Harri 
 
 

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-03 18:19

Message:
Logged In: YES 
user_id=849994

Thanks for spotting the quirk.

Applied as rev. 45893. test_compiler passes fine here.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-01 07:21

Message:
Logged In: YES 
user_id=33168

Any reason you do:
  not i >= len(nodelist) 

instead of:
  i < len(nodelist)

?

The patch seems fine if everything passes with -u compiler
test_compiler.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-30 20:20

Message:
Logged In: YES 
user_id=849994

Attaching patch. Please review.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-25 21:59

Message:
Logged In: YES 
user_id=33168

FYI.

------

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

[ python-Bugs-1480678 ] mmap tries to truncate special files

[SourceForge.net]

Bugs item #1480678, was opened at 2006-05-02 16:56
Message generated for change (Comment added) made by aerojockey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&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: Carl Banks (aerojockey)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap tries to truncate special files

Initial Comment:
One Unix, the resize() method of an mmap object calls
ftruncate to also resize the associated file.  Problem
is, ftruncate fails if the fd refers to a special file.
 This is a problem for someone trying to resize an
anonymous memory map using /dev/zero.

Apparently hasn't been fixed in 2.5 (based on SVN and
changelogs) but I haven't tested it.

--

>Comment By: Carl Banks (aerojockey)
Date: 2006-05-03 14:19

Message:
Logged In: YES 
user_id=1515186

Well, since resizing an anonymous array seems a reasonable
thing to do, and because it worked in Python 2.3, I presumed
that the error was an oversight, and not intended behavior.

If it is, in fact, intended behavior, then ok, though I
don't agree with it.  (It's not as if /dev/zero has fixed
size that doesn't change; it's inherently sizeless.)

--

Comment By: Tim Peters (tim_one)
Date: 2006-05-03 02:13

Message:
Logged In: YES 
user_id=31435

Ya, this isn't a bug:  resize() is documented as changing
the size of _both_ the map and the file.  If the size of the
file can't be changed, then of course resize() will fail.

aerojockey:  can't you simply close your current map and
create a new map with the size you want?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-03 01:21

Message:
Logged In: YES 
user_id=33168

I don't understand what the problem is.  ISTM if you resize
a special file an exception will be raised.  Is that not the
case?  What do you expect to happen?

------

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

[ python-Bugs-1481296 ] long(float('nan'))!=0L

[SourceForge.net]

Bugs item #1481296, was opened at 2006-05-03 13:39
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=1481296&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Dahl (edahl)
Assigned to: Nobody/Anonymous (nobody)
Summary: long(float('nan'))!=0L

Initial Comment:
on all platforms I can test long(float('nan'))=0L

But on maxos X intel long(float('nan'))!=0L

it returns:

0L

This is a problem because:

>>> 344 - long(float('nan'))
Objects/longobject.c:1645: failed assertion `borrow == 0'
Abort trap




------

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

[ python-Bugs-1480678 ] mmap tries to truncate special files

[SourceForge.net]

Bugs item #1480678, was opened at 2006-05-02 16:56
Message generated for change (Settings changed) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&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: Not a Bug
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Carl Banks (aerojockey)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap tries to truncate special files

Initial Comment:
One Unix, the resize() method of an mmap object calls
ftruncate to also resize the associated file.  Problem
is, ftruncate fails if the fd refers to a special file.
 This is a problem for someone trying to resize an
anonymous memory map using /dev/zero.

Apparently hasn't been fixed in 2.5 (based on SVN and
changelogs) but I haven't tested it.

--

>Comment By: Tim Peters (tim_one)
Date: 2006-05-03 15:02

Message:
Logged In: YES 
user_id=31435

I have to confess I don't know _why_ resize() changes the
size of the file too, and think that's a debatable design
decision.  But when code is working as intended and as
documented, by definition that's not "a bug".

The reason "it worked" in Python 2.3 is explained in bug 728515:

http://www.python.org/sf/728515

As it says there, it was a bug that resize() resized the
file on Windows, but neglected to do so on Unixish boxes at
the time.  That bug was fixed by making it resize the file
on Unixish boxes too.

Since the intent here is clear (albeit questionable) and
documented, I'm closing this as not-a-bug.

--

Comment By: Carl Banks (aerojockey)
Date: 2006-05-03 14:19

Message:
Logged In: YES 
user_id=1515186

Well, since resizing an anonymous array seems a reasonable
thing to do, and because it worked in Python 2.3, I presumed
that the error was an oversight, and not intended behavior.

If it is, in fact, intended behavior, then ok, though I
don't agree with it.  (It's not as if /dev/zero has fixed
size that doesn't change; it's inherently sizeless.)

--

Comment By: Tim Peters (tim_one)
Date: 2006-05-03 02:13

Message:
Logged In: YES 
user_id=31435

Ya, this isn't a bug:  resize() is documented as changing
the size of _both_ the map and the file.  If the size of the
file can't be changed, then of course resize() will fail.

aerojockey:  can't you simply close your current map and
create a new map with the size you want?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-03 01:21

Message:
Logged In: YES 
user_id=33168

I don't understand what the problem is.  ISTM if you resize
a special file an exception will be raised.  Is that not the
case?  What do you expect to happen?

------

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

[ python-Bugs-1481296 ] long(float('nan'))!=0L

[SourceForge.net]

Bugs item #1481296, was opened at 2006-05-03 14:39
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481296&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Erik Dahl (edahl)
Assigned to: Nobody/Anonymous (nobody)
Summary: long(float('nan'))!=0L

Initial Comment:
on all platforms I can test long(float('nan'))=0L

But on maxos X intel long(float('nan'))!=0L

it returns:

0L

This is a problem because:

>>> 344 - long(float('nan'))
Objects/longobject.c:1645: failed assertion `borrow == 0'
Abort trap




--

>Comment By: Tim Peters (tim_one)
Date: 2006-05-03 15:09

Message:
Logged In: YES 
user_id=31435

Try it on Windows and you'll get:

>>> long(float('nan'))
Traceback (most recent call last):
  File "", line 1, in ?
ValueError: invalid literal for float(): nan

Nothing about the behavior of NaNs, infinities, or signed
zeroes is defined or guaranteed by Python.  You use them at
your own risk, and their behavior does vary wildly in
practice (according to the HW, OS, C compiler, C library,
and even the C compiler flags specified when compiling Python).

------

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

[ python-Bugs-1481347 ] parse_makefile doesn't handle $$ correctly

[SourceForge.net]

Bugs item #1481347, was opened at 2006-05-03 21:16
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=1481347&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: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Han-Wen Nienhuys (hanwen)
Assigned to: Nobody/Anonymous (nobody)
Summary: parse_makefile doesn't handle $$  correctly

Initial Comment:
In Makefiles, a $$ should expand into a literal $ 
distutils.sysconfig doesn't deal with this.

>>> print open('a.make').read ()

FOO = $${bar} bla bla

>>> sysconfig.parse_makefile ('a.make')
{'FOO': '$ bla bla', 'bar': ''}




------

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

[ python-Bugs-1417699 ] float/atof have become locale aware

[SourceForge.net]

Bugs item #1417699, was opened at 2006-01-29 02:04
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Martin v. Löwis (loewis)
Summary: float/atof have become locale aware

Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:

Python 2.4.2 (#1, Nov 29 2005, 16:07:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5


This doesn't match what's specified in pep 331:

- float() and str() stay locale-unaware.

It also doesn't match the documentation for atof:

  Convert a string to a floating point number.
  The string must have the standard syntax for a
  floating point literal in Python, optionally
  preceded by a sign ("+" or "-"). Note that this
  behaves identical to the built-in function float()
  when passed a string.

The documentation for float() doesn't state which
format is accepted by float(), though.

The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:

  This function behaves like the standard strtod() 
  function does in the C locale.




--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-05-04 06:42

Message:
Logged In: YES 
user_id=21627

It's a bug. As bernhard says, it originates from
PyOS_ascii_strtod accepting both forms, which in turn
happens because it just leaves the locale-specific decimal
point in the string, only replacing the . with the
locale-specific point. Then, the platform's strtod will
happily accept the locale-specific version. 

I'd like Gustavo Carneiro to comment.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 13:19

Message:
Logged In: YES 
user_id=1188172

Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?

--

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

[ python-Bugs-1478529 ] size limit exceeded for read() from network drive

[SourceForge.net]

Bugs item #1478529, was opened at 2006-04-28 12:46
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows
Group: 3rd Party
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Mark Sheppard (markshep)
Assigned to: Nobody/Anonymous (nobody)
Summary: size limit exceeded for read() from network drive

Initial Comment:
If you've got a network share mounted as a local drive
then Windows has a limit of 67,076,095 (0x03ff7fff)
bytes for a read from an open file on that drive.

Running the python read() method on an open file larger
than this size throws an "IOError: [Errno 22] Invalid
argument" exception.

A fix would be for python to internally use multiple
reads so as to not exceed this limit.


--

>Comment By: Tim Peters (tim_one)
Date: 2006-05-04 02:18

Message:
Logged In: YES 
user_id=31435

markshep:  As you discovered, closing the report doesn't
stop you from following up.  It just reflects the reality
that I don't consider this to be a Python bug, and am
opposed to trying to worm around it inside Python.

Like many people who have just been burned by a platform
quirk, I think you're over-selling the severity of the
problem while ignoring the costs of worming around it. 
Adding piles of Windows-specific code to what's _currently_
a simple and uniform implementation is an ongoing
maintenance headache, not least because that code will stick
around long after the next version of Windows has removed
the cause for it.  In the meantime it complicates the code
with obscure platform-specific hacks, reducing the
reliability of the code because it also reduces the code's
clarity.  The code can't be sanely tested by Python's
standard test suite either (it apparently requires a Windows
network to provoke, and the test suite assumes no such
thing), and untested hack-code is a horrible idea over time.

While it's true that the docs allow for multiple reads under
the covers, it's talking about cases like file objects
returned by a popen() call or a socket makefile() call when
read() is passed a `size` argument, or when read() is called
with no `size` argument (so it's impossible to know in
advance how large a buffer may be needed to reach EOF).  The
entire reading code for an explicitly-sized read on a
genuine file is a single

return fread(buf, 1, n, stream);

call today, and on all platforms.

It doesn't look like this can end with reading either:  MS
documents a similar problem with writing, and I expect you
want to see that hacked around too (or, if not, you're
pretty selective ;-)).  Pain spreads.

In return, what's the benefit?  The fact that it _is_ so
hard to find anything via Google about this strongly
suggests to me that trying to read more than 64MB in one
gulp across a vulnerable Windows combo is mighty rare.  If
it happens, the failure isn't silent, an explicit exception
is raised letting the programmer know it didn't work.  While
I appreciate that's irritating, it's not a disaster, and a
programmer who cares can worm around it on their own ("so
don't do that -- read < 64MB per gulp yourself").

Obviously, I'm not going to pursue this.  Since I'm one of
the few people who "does" Windows code for the core, that
does cut the chance that anyone will.  If you want to pursue
it, the best chance is to supply a patch implementing it,
and get someone else to review it.  A stronger case could be
made if, e.g., there was evidence that Perl or PHP or Ruby
or VB or C# or ... intend to worm (or have wormed) around it.

--

Comment By: Mark Sheppard (markshep)
Date: 2006-05-03 06:38

Message:
Logged In: YES 
user_id=1512331

Thanks for closing this bug without giving me a chance to
follow up!

The problem isn't caused by a limitation of my machine -
it's got 3 GiB of RAM.

I've done some more testing on this and the problem only
appears when connected to a server running certain SMB
implementations:

  The local Windows XP machine
  A remote Windows XP machine
  Samba 3.0.22 on Linux

When connected to servers running the following SMB
implementations the problem isn't present:

  Windows NT 4.0 Server
  Windows Server 2000
  Windows Server 2003 Standard Edition

As this error is being returned by the underlying fread()
call the proper place for it to be fixed is there, but the
chances of Microsoft doing so for Windows XP are negligible.

As you're trying to provide a cross-platform language then
having

[ python-Bugs-1481650 ] Docs on import of email.MIMExxx classes wrong

[SourceForge.net]

Bugs item #1481650, was opened at 2006-05-04 07:24
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=1481650&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Hugh Gibson (hgibson50)
Assigned to: Nobody/Anonymous (nobody)
Summary: Docs on import of email.MIMExxx classes wrong

Initial Comment:
http://docs.python.org/lib/node588.html says: 

--
Each of these classes should be imported from a module 
with the same name as the class, from within the email 
package. E.g.: 


import email.MIMEImage.MIMEImage

or 

from email.MIMEText import MIMEText
--

However, here is a Python IDLE session showing that 
the first import format doesn't work:

--
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 
32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more 
information.



IDLE 1.1.3  
>>> import email.MIMEImage.MIMEImage

Traceback (most recent call last):
  File "", line 1, in -toplevel-
import email.MIMEImage.MIMEImage
ImportError: No module named MIMEImage
>>> 
--

This method *does* work:

--
>>> import email.MIMEImage
>>> 
--

This got one of my inexperienced programmers tied up 
in knots!

Hugh

------

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

[ python-Bugs-1417699 ] float/atof have become locale aware

[SourceForge.net]

Bugs item #1417699, was opened at 2006-01-29 01:04
Message generated for change (Comment added) made by gustavo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Martin v. Löwis (loewis)
Summary: float/atof have become locale aware

Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:

Python 2.4.2 (#1, Nov 29 2005, 16:07:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5


This doesn't match what's specified in pep 331:

- float() and str() stay locale-unaware.

It also doesn't match the documentation for atof:

  Convert a string to a floating point number.
  The string must have the standard syntax for a
  floating point literal in Python, optionally
  preceded by a sign ("+" or "-"). Note that this
  behaves identical to the built-in function float()
  when passed a string.

The documentation for float() doesn't state which
format is accepted by float(), though.

The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:

  This function behaves like the standard strtod() 
  function does in the C locale.




--

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-04 10:47

Message:
Logged In: YES 
user_id=908

My comment is, is "PyOS_ascii_strtod accepting both forms"
something that is harmful and should be fixed?

I didn't exactly write the PyOS_ascii_strtod code; I only
integrated it with Python.  But if we really need to fix
this, I'll try to figure out how to make it not accept
floating points in locale aware format; if necessary I'll
ask help from  the original author of the code, Alexander
Larsson.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-05-04 05:42

Message:
Logged In: YES 
user_id=21627

It's a bug. As bernhard says, it originates from
PyOS_ascii_strtod accepting both forms, which in turn
happens because it just leaves the locale-specific decimal
point in the string, only replacing the . with the
locale-specific point. Then, the platform's strtod will
happily accept the locale-specific version. 

I'd like Gustavo Carneiro to comment.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 12:19

Message:
Logged In: YES 
user_id=1188172

Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?

--

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

[ python-Bugs-1481650 ] Docs on import of email.MIMExxx classes wrong

[SourceForge.net]

Bugs item #1481650, was opened at 2006-05-04 03:24
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481650&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Hugh Gibson (hgibson50)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Docs on import of email.MIMExxx classes wrong

Initial Comment:
http://docs.python.org/lib/node588.html says: 

--
Each of these classes should be imported from a module 
with the same name as the class, from within the email 
package. E.g.: 


import email.MIMEImage.MIMEImage

or 

from email.MIMEText import MIMEText
--

However, here is a Python IDLE session showing that 
the first import format doesn't work:

--
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 
32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more 
information.



IDLE 1.1.3  
>>> import email.MIMEImage.MIMEImage

Traceback (most recent call last):
  File "", line 1, in -toplevel-
import email.MIMEImage.MIMEImage
ImportError: No module named MIMEImage
>>> 
--

This method *does* work:

--
>>> import email.MIMEImage
>>> 
--

This got one of my inexperienced programmers tied up 
in knots!

Hugh

------

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

[ python-Bugs-1481770 ] hpux ia64 shared lib ext should be ".so"

[SourceForge.net]

Bugs item #1481770, was opened at 2006-05-04 05:43
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=1481770&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: David Everly (deckrider)
Assigned to: Nobody/Anonymous (nobody)
Summary: hpux ia64 shared lib ext should be ".so"

Initial Comment:
On hpux ia64, the shared library extension should be
".so".  This is currently problematic in that other
add-on python modules (such as those for subversion)
correctly detect the host_os/host_cpu and build
_module.so, which is not seen by python built using ".sl".

According to
http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac


"Shared library names

Since dynamic linking APIs operate on shared libraries,
it is also important to note that the shared library
naming scheme on Linux is lib*.so; whereas, on HP-UX
11i Version 1.5 the naming scheme is lib*.sl for PA and
lib*.so on IPF. Also APIs may reside in different
libraries files on Linux and HP-UX, so you may need to
dynamically load a different shared library name on
HP-UX and Linux."

To translate this quote, PA=hppa and IPF=ia64.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&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-1110010 ] 'attrmap' function, attrmap(x)['attname'] == x.attname

[SourceForge.net]

Feature Requests item #1110010, was opened at 2005-01-26 11:28
Message generated for change (Comment added) made by gregsmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&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: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname

Initial Comment:
One of the side effects of the new-style classes is that
objects don't necessarily have __dict__ attached to them.
It used to be possible to write things like

   def __str__(self):
  return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % self.__dict__


... but this doesn't work if the class doesn't have a
__dict__. Even if does, I'm not sure it will always get
members from base classes.

There is a 'vars' function; you could put 'vars(self)'
in the above instead of self.__dict__, but it still
doesn't work if
the class doesn't have a __dict__.

I can see different solutions for this:

(1) change the 'string %' operator so that it allows
 %(.name)s, leading to a getattr() on the right-side
argument
  rather than a getitem. 

  return "Node %(.name)s, %(.nlinks)d links,
active: %(.active)s" % self

(2) Make a builtin like vars, but which works when the
object doesn't have a __dict__ I.e. attrmap(x) would
return a mapping which is bound to x, and reading
attrmap(x)['attname'] is the same as
getattr(x,'attname'). Thus

  return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % attrmap(self)


This attrmap() function can be implemented in pure
python, of course.

I originally thought (1) made a lot of sense, but (2) seems
to work just as well and doesn't require changing much.
Also, (1) allows  cases like "%(name)s %(.name2)s",
which are not very useful, but are very likely to be
created by
accident; whereas in (2) you are deciding on the right
of the '%' whether you are naming attributes or
providing mapping keys. 

I'm not sure it's a good idea change 'vars' to have
this behaviour, since vars(x).keys() currently works in
a predictable way when vars(x) works; whereas
attrmap(x).keys() may not be complete, or possible, 
even when attrmap(x) is useful. I.e. when x has a
__getattr__ defined.
On the other hand, vars(x) doesn't currently do much at
all, so maybe it's possible to enhance it like this
without breaking anything.

The motivation for this came from the "%(name)s" issue,
but the attrmap() function would be useful in other
places e.g.

processdata( infile,  outfile, **attrmap(options))

... where options might be obtained from optparse, e.g.
  
Or, an attrmap can be used with the new Templates:
string.Template('Node $name').substitute( attrmap(node))

Both of these examples will work with vars(), but only
when the object actually has __dict__. This is why
I'm thinking it may make sense to enhance vars: some
code may be broken by the change; but other code,
broken by new-style classes, may be unbroken by this
change.

The proxy could be writable, so that
attrmap(x)['a'] = y
is the same as
 x.a = y
.. which could have more uses.

A possible useful (possibly weird) variation: attrmap
accepts 1 or more parameters, and the resulting
proxy is bound to all of them. when attrmap(x,y,z)['a']
is done, the proxy will try x.a, y.a, z.a until one of
them doesn't raise AttributeError. So it's equivalent
to merging dictionaries. This would be useful
in the %(name)s or Template cases, where you want
information from several objects.





--

>Comment By: Gregory Smith (gregsmith)
Date: 2006-05-04 11:19

Message:
Logged In: YES 
user_id=292741

Josiah, I'm well aware of that, but as I said 10/26 I don't
want to add attribute mapping to a whole set of classes just
so they will all work a certain way in one specific
situation; I want a separate adapter so I can have attribute
mapping for ANY object in that specific situation. I can't
mixin a new base class into every class I might encounter,
since most of them are not under my control; but all of them
have an attribute interface and will all work with attrmap.
There's no reason to mess things up like that when
I can implement attrmap already (and have done) -- and you
have shown how short the code is on your 6/26/'05 post --
I'm just suggesting this is simple, elegant, and generally
useful enough to be included as a standard python gizmo.

[ python-Bugs-1482122 ] Shift+Backspace exhibits odd behavior

[SourceForge.net]

Bugs item #1482122, was opened at 2006-05-04 13:48
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=1482122&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: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: NothingCanFulfill (ncf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Shift+Backspace exhibits odd behavior

Initial Comment:
On Windows, pressing Shift+Backspace while in an editor
window will act just like a regular Backspace will,
however under Linux (Gentoo 2006.0 and
Slackware-current), instead of deleting the caracter
before the cursor, it inserts "^B".

Correct me if I'm wrong, but I don't think it'd be too
hard to fix this little annoyance.

(I would do it myself, but I'm not at all familiar with
IDLE's source layout)

------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482122&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-1110010 ] 'attrmap' function, attrmap(x)['attname'] == x.attname

[SourceForge.net]

Feature Requests item #1110010, was opened at 2005-01-26 08:28
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&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: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname

Initial Comment:
One of the side effects of the new-style classes is that
objects don't necessarily have __dict__ attached to them.
It used to be possible to write things like

   def __str__(self):
  return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % self.__dict__


... but this doesn't work if the class doesn't have a
__dict__. Even if does, I'm not sure it will always get
members from base classes.

There is a 'vars' function; you could put 'vars(self)'
in the above instead of self.__dict__, but it still
doesn't work if
the class doesn't have a __dict__.

I can see different solutions for this:

(1) change the 'string %' operator so that it allows
 %(.name)s, leading to a getattr() on the right-side
argument
  rather than a getitem. 

  return "Node %(.name)s, %(.nlinks)d links,
active: %(.active)s" % self

(2) Make a builtin like vars, but which works when the
object doesn't have a __dict__ I.e. attrmap(x) would
return a mapping which is bound to x, and reading
attrmap(x)['attname'] is the same as
getattr(x,'attname'). Thus

  return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % attrmap(self)


This attrmap() function can be implemented in pure
python, of course.

I originally thought (1) made a lot of sense, but (2) seems
to work just as well and doesn't require changing much.
Also, (1) allows  cases like "%(name)s %(.name2)s",
which are not very useful, but are very likely to be
created by
accident; whereas in (2) you are deciding on the right
of the '%' whether you are naming attributes or
providing mapping keys. 

I'm not sure it's a good idea change 'vars' to have
this behaviour, since vars(x).keys() currently works in
a predictable way when vars(x) works; whereas
attrmap(x).keys() may not be complete, or possible, 
even when attrmap(x) is useful. I.e. when x has a
__getattr__ defined.
On the other hand, vars(x) doesn't currently do much at
all, so maybe it's possible to enhance it like this
without breaking anything.

The motivation for this came from the "%(name)s" issue,
but the attrmap() function would be useful in other
places e.g.

processdata( infile,  outfile, **attrmap(options))

... where options might be obtained from optparse, e.g.
  
Or, an attrmap can be used with the new Templates:
string.Template('Node $name').substitute( attrmap(node))

Both of these examples will work with vars(), but only
when the object actually has __dict__. This is why
I'm thinking it may make sense to enhance vars: some
code may be broken by the change; but other code,
broken by new-style classes, may be unbroken by this
change.

The proxy could be writable, so that
attrmap(x)['a'] = y
is the same as
 x.a = y
.. which could have more uses.

A possible useful (possibly weird) variation: attrmap
accepts 1 or more parameters, and the resulting
proxy is bound to all of them. when attrmap(x,y,z)['a']
is done, the proxy will try x.a, y.a, z.a until one of
them doesn't raise AttributeError. So it's equivalent
to merging dictionaries. This would be useful
in the %(name)s or Template cases, where you want
information from several objects.





--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-04 23:28

Message:
Logged In: YES 
user_id=341410

As I and others have expressed perhaps hundreds of times
over the last few years; not all X line functions/classes
should be built into Python.  This particular object doesn't
have enough general usefulness to make it into Python as a
builtin, so you would need to import something anyways.

If you are going to need to import to get at it, you may as
well put this somewhere, and perhaps monkey-patch
__builtins__ yourself so that you can get at it everywhere
without importing it.  Heck, you could even put it into
site.py .

If this were going to make it into Python, I would suggest
it go into the operator module, where a similar feature
already exists in the operator.attrgetter.  If there is also
desire, one may want to offer mapattr class which does
x.attr -> x[&

[ python-Bugs-1481770 ] hpux ia64 shared lib ext should be ".so"

[SourceForge.net]

Bugs item #1481770, was opened at 2006-05-04 04:43
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: David Everly (deckrider)
Assigned to: Nobody/Anonymous (nobody)
Summary: hpux ia64 shared lib ext should be ".so"

Initial Comment:
On hpux ia64, the shared library extension should be
".so".  This is currently problematic in that other
add-on python modules (such as those for subversion)
correctly detect the host_os/host_cpu and build
_module.so, which is not seen by python built using ".sl".

According to
http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac


"Shared library names

Since dynamic linking APIs operate on shared libraries,
it is also important to note that the shared library
naming scheme on Linux is lib*.so; whereas, on HP-UX
11i Version 1.5 the naming scheme is lib*.sl for PA and
lib*.so on IPF. Also APIs may reside in different
libraries files on Linux and HP-UX, so you may need to
dynamically load a different shared library name on
HP-UX and Linux."

To translate this quote, PA=hppa and IPF=ia64.


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 00:02

Message:
Logged In: YES 
user_id=33168

Do you think you could work on a patch to address this issue?

------

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

[ python-Bugs-1482122 ] Shift+Backspace exhibits odd behavior

[SourceForge.net]

Bugs item #1482122, was opened at 2006-05-04 13:48
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482122&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: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: NothingCanFulfill (ncf)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Shift+Backspace exhibits odd behavior

Initial Comment:
On Windows, pressing Shift+Backspace while in an editor
window will act just like a regular Backspace will,
however under Linux (Gentoo 2006.0 and
Slackware-current), instead of deleting the caracter
before the cursor, it inserts "^B".

Correct me if I'm wrong, but I don't think it'd be too
hard to fix this little annoyance.

(I would do it myself, but I'm not at all familiar with
IDLE's source layout)

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 00:03

Message:
Logged In: YES 
user_id=33168

Right now there aren't a lot of IDLE developers.  It would
be great if you could work on a patch.

------

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

[ python-Bugs-1482328 ] socket.getsockopt bug

[SourceForge.net]

Bugs item #1482328, was opened at 2006-05-05 12:22
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=1482328&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: ganges master (gangesmaster)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.getsockopt bug

Initial Comment:
i tested this on windows xp. the installed python
version is the 2.4.3 from the windows MSI.

when doing socket.getsockopt with buffer_size > 0, for
options like SO_LINGER or SO_SNDTIMEO, i get only 4 bytes. 
although the man pages state these options hold 8
bytes. is this a bug in the pythonic version of
getsockopt or winsock?

-tomer

--

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

[ python-Bugs-1482402 ] Forwarding events and Tk.mainloop problem

[SourceForge.net]

Bugs item #1482402, was opened at 2006-05-05 11:15
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=1482402&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: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Kievernagel (mkiever)
Assigned to: Martin v. Löwis (loewis)
Summary: Forwarding events and Tk.mainloop problem

Initial Comment:
(Python 2.4.1, tcl/tk 8.4 on Linux)

I try to create a widget class (Frame2 in the example)
containing a Listbox.
This should report an event '<>'
when the Listbox produces '<>'
or when the selection changes using the Up/Down keys.
(see example script)

Binding '<>' to the Frame2 widget
produces the following traceback when the
event is generated:

--
listbox select
event generated
Traceback (most recent call last):
  File "testevent.py", line 98, in ?
tk.mainloop ()
  File "/usr/local/lib/python2.4/lib-tk/Tkinter.py", 
line 965, in mainloop
self.tk.mainloop(n)
  File "/usr/local/lib/python2.4/lib-tk/Tkinter.py", 
line 1349, in __call__
self.widget._report_exception()
  File "/usr/local/lib/python2.4/lib-tk/Tkinter.py", 
line 1112, in _report_exception
root = self._root()
AttributeError: Tk instance has no __call__ method
-

So Tkinter tries to report an exception
caused by the event, but fails to do so
by a second exception in _report_exception.
(not quite sure I did understand this)
The first exception may be a problem with
my code or tcl/tk but at least the second
is a problem of Tkinter.

If you bind '<>' to Tk itself
the example works fine.


--

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

[ python-Bugs-1481770 ] hpux ia64 shared lib ext should be ".so"

[SourceForge.net]

Bugs item #1481770, was opened at 2006-05-04 05:43
Message generated for change (Comment added) made by deckrider
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: David Everly (deckrider)
Assigned to: Nobody/Anonymous (nobody)
Summary: hpux ia64 shared lib ext should be ".so"

Initial Comment:
On hpux ia64, the shared library extension should be
".so".  This is currently problematic in that other
add-on python modules (such as those for subversion)
correctly detect the host_os/host_cpu and build
_module.so, which is not seen by python built using ".sl".

According to
http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac


"Shared library names

Since dynamic linking APIs operate on shared libraries,
it is also important to note that the shared library
naming scheme on Linux is lib*.so; whereas, on HP-UX
11i Version 1.5 the naming scheme is lib*.sl for PA and
lib*.so on IPF. Also APIs may reside in different
libraries files on Linux and HP-UX, so you may need to
dynamically load a different shared library name on
HP-UX and Linux."

To translate this quote, PA=hppa and IPF=ia64.


--

>Comment By: David Everly (deckrider)
Date: 2006-05-05 06:07

Message:
Logged In: YES 
user_id=1113403

The patch I'm using now only works on hppa/ia64 and isn't
anything that can coexist nicely in the source package on
other hardware/os combinations.

I've looked at
http://svn.python.org/projects/python/branches/release24-maint/

I'm accustomed to a system using autoconf/libtool/automake
(recent versions) and never committing the output of those
tools, but only running them at source package generation time.

I say this, only to point out that I'm not understanding the
principles behind what I see in subversion.  I see
configure, and also configure.in.  Which should be patched?
 And if I don't patch configure, what is the process for
regenerating it (and with what versions of automake,
autoconf, and libtool?).

Also, the most recent libtool already correctly determines
shared library extension.

So I could probably provide a patch, but would need to
understand the environment better in order to do so.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 01:02

Message:
Logged In: YES 
user_id=33168

Do you think you could work on a patch to address this issue?

------

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

[ python-Bugs-1482328 ] socket.getsockopt bug

[SourceForge.net]

Bugs item #1482328, was opened at 2006-05-05 09:22
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&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: ganges master (gangesmaster)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.getsockopt bug

Initial Comment:
i tested this on windows xp. the installed python
version is the 2.4.3 from the windows MSI.

when doing socket.getsockopt with buffer_size > 0, for
options like SO_LINGER or SO_SNDTIMEO, i get only 4 bytes. 
although the man pages state these options hold 8
bytes. is this a bug in the pythonic version of
getsockopt or winsock?

-tomer

--

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 13:12

Message:
Logged In: YES 
user_id=1126061

According to http://www.sockets.com/winsock.htm#GetSockOpt

"The integer pointed to by optlen should originally contain
the size of this buffer; on return, it will be set to the
size of the value returned. For SO_LINGER, this will be the
size of a struct linger; for all other options it will be
the size of an integer." 

The size of a linger struct is 4 bytes. 

I would agree that the Python documentation for
socket.getsockopt is a little confusing.

"Get a socket option.  See the Unix manual for level and
option. If a nonzero buffersize argument is given, the
return value is a string of that length; otherwise it is an
integer."

Perhaps just refer users to the OSes documentation on its
implementation of sockets?

Matt


--

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

[ python-Bugs-1482328 ] socket.getsockopt bug

[SourceForge.net]

Bugs item #1482328, was opened at 2006-05-05 12:22
Message generated for change (Comment added) made by gangesmaster
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&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: ganges master (gangesmaster)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.getsockopt bug

Initial Comment:
i tested this on windows xp. the installed python
version is the 2.4.3 from the windows MSI.

when doing socket.getsockopt with buffer_size > 0, for
options like SO_LINGER or SO_SNDTIMEO, i get only 4 bytes. 
although the man pages state these options hold 8
bytes. is this a bug in the pythonic version of
getsockopt or winsock?

-tomer

--

>Comment By: ganges master (gangesmaster)
Date: 2006-05-05 16:43

Message:
Logged In: YES 
user_id=1406776

i don't think so:

according to http://www.sockets.com/winsock.htm#GetSockOpt
and
http://www.gnu.org/software/libc/manual/html_node/Socket_002dLevel-Options.html

struct linger is defined this way:

struct linger {
int l_onoff;
int l_linger;
}

which means 8 bytes, and the same goes for struct timeval:

struct timeval {
longtv_sec;
longtv_usec;
};

still, the getsockopt returns only 4. i looked at the python
source but i can't find the bug... perhaps its a bug with
how they use winsock?

-tomer

--

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 16:12

Message:
Logged In: YES 
user_id=1126061

According to http://www.sockets.com/winsock.htm#GetSockOpt

"The integer pointed to by optlen should originally contain
the size of this buffer; on return, it will be set to the
size of the value returned. For SO_LINGER, this will be the
size of a struct linger; for all other options it will be
the size of an integer." 

The size of a linger struct is 4 bytes. 

I would agree that the Python documentation for
socket.getsockopt is a little confusing.

"Get a socket option.  See the Unix manual for level and
option. If a nonzero buffersize argument is given, the
return value is a string of that length; otherwise it is an
integer."

Perhaps just refer users to the OSes documentation on its
implementation of sockets?

Matt


--

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

[ python-Bugs-1482328 ] socket.getsockopt bug

[SourceForge.net]

Bugs item #1482328, was opened at 2006-05-05 09:22
Message generated for change (Comment added) made by splitscreen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&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: ganges master (gangesmaster)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.getsockopt bug

Initial Comment:
i tested this on windows xp. the installed python
version is the 2.4.3 from the windows MSI.

when doing socket.getsockopt with buffer_size > 0, for
options like SO_LINGER or SO_SNDTIMEO, i get only 4 bytes. 
although the man pages state these options hold 8
bytes. is this a bug in the pythonic version of
getsockopt or winsock?

-tomer

--

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 13:51

Message:
Logged In: YES 
user_id=1126061

Visual Studio .NET 2003 comes with WinSock.h and defines the
linger struct as,

struct  linger {
u_short l_onoff;/* option on/off */
u_short l_linger;   /* linger time */
};

However, on my NetBSD machine the linger struct is defined as,

struct  linger {
int l_onoff;/* option on/off */
int l_linger;   /* linger time in
seconds */
};


--

Comment By: ganges master (gangesmaster)
Date: 2006-05-05 13:43

Message:
Logged In: YES 
user_id=1406776

i don't think so:

according to http://www.sockets.com/winsock.htm#GetSockOpt
and
http://www.gnu.org/software/libc/manual/html_node/Socket_002dLevel-Options.html

struct linger is defined this way:

struct linger {
int l_onoff;
int l_linger;
}

which means 8 bytes, and the same goes for struct timeval:

struct timeval {
longtv_sec;
longtv_usec;
};

still, the getsockopt returns only 4. i looked at the python
source but i can't find the bug... perhaps its a bug with
how they use winsock?

-tomer

--

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 13:12

Message:
Logged In: YES 
user_id=1126061

According to http://www.sockets.com/winsock.htm#GetSockOpt

"The integer pointed to by optlen should originally contain
the size of this buffer; on return, it will be set to the
size of the value returned. For SO_LINGER, this will be the
size of a struct linger; for all other options it will be
the size of an integer." 

The size of a linger struct is 4 bytes. 

I would agree that the Python documentation for
socket.getsockopt is a little confusing.

"Get a socket option.  See the Unix manual for level and
option. If a nonzero buffersize argument is given, the
return value is a string of that length; otherwise it is an
integer."

Perhaps just refer users to the OSes documentation on its
implementation of sockets?

Matt


--

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

[ python-Bugs-1482328 ] socket.getsockopt bug

[SourceForge.net]

Bugs item #1482328, was opened at 2006-05-05 12:22
Message generated for change (Comment added) made by gangesmaster
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&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: ganges master (gangesmaster)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.getsockopt bug

Initial Comment:
i tested this on windows xp. the installed python
version is the 2.4.3 from the windows MSI.

when doing socket.getsockopt with buffer_size > 0, for
options like SO_LINGER or SO_SNDTIMEO, i get only 4 bytes. 
although the man pages state these options hold 8
bytes. is this a bug in the pythonic version of
getsockopt or winsock?

-tomer

--

>Comment By: ganges master (gangesmaster)
Date: 2006-05-05 17:26

Message:
Logged In: YES 
user_id=1406776

lovely. i hate windows. i guess it's not a bug then -- it's
a feature. arghh.

and i now found that SNDTIMEO doesn't take a timeval, rather
an integer. just great. so i'll close the bug.

-tomer

--

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 16:51

Message:
Logged In: YES 
user_id=1126061

Visual Studio .NET 2003 comes with WinSock.h and defines the
linger struct as,

struct  linger {
u_short l_onoff;/* option on/off */
u_short l_linger;   /* linger time */
};

However, on my NetBSD machine the linger struct is defined as,

struct  linger {
int l_onoff;/* option on/off */
int l_linger;   /* linger time in
seconds */
};


--

Comment By: ganges master (gangesmaster)
Date: 2006-05-05 16:43

Message:
Logged In: YES 
user_id=1406776

i don't think so:

according to http://www.sockets.com/winsock.htm#GetSockOpt
and
http://www.gnu.org/software/libc/manual/html_node/Socket_002dLevel-Options.html

struct linger is defined this way:

struct linger {
int l_onoff;
int l_linger;
}

which means 8 bytes, and the same goes for struct timeval:

struct timeval {
longtv_sec;
longtv_usec;
};

still, the getsockopt returns only 4. i looked at the python
source but i can't find the bug... perhaps its a bug with
how they use winsock?

-tomer

--

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 16:12

Message:
Logged In: YES 
user_id=1126061

According to http://www.sockets.com/winsock.htm#GetSockOpt

"The integer pointed to by optlen should originally contain
the size of this buffer; on return, it will be set to the
size of the value returned. For SO_LINGER, this will be the
size of a struct linger; for all other options it will be
the size of an integer." 

The size of a linger struct is 4 bytes. 

I would agree that the Python documentation for
socket.getsockopt is a little confusing.

"Get a socket option.  See the Unix manual for level and
option. If a nonzero buffersize argument is given, the
return value is a string of that length; otherwise it is an
integer."

Perhaps just refer users to the OSes documentation on its
implementation of sockets?

Matt


------

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

[ python-Bugs-1482328 ] socket.getsockopt bug

[SourceForge.net]

Bugs item #1482328, was opened at 2006-05-05 12:22
Message generated for change (Settings changed) made by gangesmaster
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482328&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: None
Priority: 5
Submitted By: ganges master (gangesmaster)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.getsockopt bug

Initial Comment:
i tested this on windows xp. the installed python
version is the 2.4.3 from the windows MSI.

when doing socket.getsockopt with buffer_size > 0, for
options like SO_LINGER or SO_SNDTIMEO, i get only 4 bytes. 
although the man pages state these options hold 8
bytes. is this a bug in the pythonic version of
getsockopt or winsock?

-tomer

--

Comment By: ganges master (gangesmaster)
Date: 2006-05-05 17:26

Message:
Logged In: YES 
user_id=1406776

lovely. i hate windows. i guess it's not a bug then -- it's
a feature. arghh.

and i now found that SNDTIMEO doesn't take a timeval, rather
an integer. just great. so i'll close the bug.

-tomer

--

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 16:51

Message:
Logged In: YES 
user_id=1126061

Visual Studio .NET 2003 comes with WinSock.h and defines the
linger struct as,

struct  linger {
u_short l_onoff;/* option on/off */
u_short l_linger;   /* linger time */
};

However, on my NetBSD machine the linger struct is defined as,

struct  linger {
int l_onoff;/* option on/off */
int l_linger;   /* linger time in
seconds */
};


--

Comment By: ganges master (gangesmaster)
Date: 2006-05-05 16:43

Message:
Logged In: YES 
user_id=1406776

i don't think so:

according to http://www.sockets.com/winsock.htm#GetSockOpt
and
http://www.gnu.org/software/libc/manual/html_node/Socket_002dLevel-Options.html

struct linger is defined this way:

struct linger {
int l_onoff;
int l_linger;
}

which means 8 bytes, and the same goes for struct timeval:

struct timeval {
longtv_sec;
longtv_usec;
};

still, the getsockopt returns only 4. i looked at the python
source but i can't find the bug... perhaps its a bug with
how they use winsock?

-tomer

--

Comment By: Matt Fleming (splitscreen)
Date: 2006-05-05 16:12

Message:
Logged In: YES 
user_id=1126061

According to http://www.sockets.com/winsock.htm#GetSockOpt

"The integer pointed to by optlen should originally contain
the size of this buffer; on return, it will be set to the
size of the value returned. For SO_LINGER, this will be the
size of a struct linger; for all other options it will be
the size of an integer." 

The size of a linger struct is 4 bytes. 

I would agree that the Python documentation for
socket.getsockopt is a little confusing.

"Get a socket option.  See the Unix manual for level and
option. If a nonzero buffersize argument is given, the
return value is a string of that length; otherwise it is an
integer."

Perhaps just refer users to the OSes documentation on its
implementation of sockets?

Matt


------

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

[ python-Bugs-1482746 ] asyncore is not listed in test_sundry

[SourceForge.net]

Bugs item #1482746, was opened at 2006-05-05 16:08
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=1482746&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: jackilyn (jackilyn)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore is not listed in test_sundry

Initial Comment:
I was adding logging to asyncore and I noticed asyncore
is not listed in test_sundry.

--

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

[ python-Bugs-1284316 ] Win32: Security problem with default installation directory

[SourceForge.net]

Bugs item #1284316, was opened at 2005-09-08 06:34
Message generated for change (Comment added) made by dsmiller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&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: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 7
Submitted By: Mika Eloranta (mel)
Assigned to: Martin v. Löwis (loewis)
Summary: Win32: Security problem with default installation directory

Initial Comment:
(Sorry, this is a bit long since the issue is not
entirely trivial.)

This problem only exists on Windows operating systems
installed on an NTFS file system. Confirmed on several
Windows 2000, XP and Windows 2003 Server systems. All
Python versions (at least 2.x) are affected.

The default installation target directory where Python
is installation on Windows is directly under the system
drive's root directory (e.g. "C:\python24"). The file
and directory permissions inherited by the
python24-directory from the root directory are not
secure enough for keeping application binaries.

Microsoft has, in their infinite wisdom, decided that
the root directory of the system drive should allow
regular (non-admin) users to create directories and
files there. This set of permissions is inherited by
the python directory when it is created in the default
location (i.e. "C:\python24" or whatever).

This "feature" allows a regular (non-admin) user to
perform a priviledge escalation attack for example in
the following manner:

1. Figure out the name of some DLL python (or some
extension .PYD) loads using LoadLibrary() without an
absolute path.

2. Copy a DLL with the same name into the
python-directory (this should not be allowed, but it
is!) containing some code the attacker wants to run
with escalated priviledges.

3. Wait until python is run by an admin in the same
machine or by the LocalSystem account.

How to view the problematic part of the ACL:
1. Right-click the "C:\python24" directory in Windows
Explorer
2. select Properties... -> Security -> Advanced
3. In the "Permissions" tab you will see an entry for
the "Users" group, it says "Special" in the
"Permissions" column
4. Select the above entry and click "Edit..."
5. Well hidden? I think so, too.

The fix:
The proper (default) location where application
binaries should be installed is under the "c:\program
files\" directory. This directory has properly set
permissions by default.

PS. The same problem exists in ActivePerl, Ruby and
many other tools.


--

Comment By: D. Scott Miller (dsmiller)
Date: 2006-05-06 10:04

Message:
Logged In: YES 
user_id=1517734

Here's a few possible solutions to the permissions problem
that retain the idea of defaulting to an install path with
no spaces without making too many assumptions about what
permissions the installing admin actually wants:
-
Idea #1

Install by default to %systemroot%\PythonXX. Hey, Java
sticks some stuff in there, right? If the idea is "this is
kind of a part-of-the-OS thing, and MS does it this way for
cscript.exe" then this seems to make sense. (We hope any
admins who're using a %systemroot% with spaces in it know
what they're doing.)

Is the default name for %systemroot% different on any
particular localized versions of Windows? I know it's
"WINDOWS" in Japanese versions, anyway.
-
Idea #2

Have two folder select boxes in the installer, one for where
to install Python and one for a folder from which to copy
ACLs. These would default to %systemdrive%\PythonXX and
%programfiles%, respectively. Have a check box to disable
the ACL copying, but have it checked by default.

This is still bad, as it doesn't solve the problem of being
a special separate directory with its own individual ACL to
maintain, but it's somewhat less bad than it is now for
people who click through the installer trusting it to not
open up their system to new flavors of privilege escalation.
-
Idea #3

Do something goofy with NTFS junctions.
-

Regardless of what's done, given that people expect not to
have to worry about spaces these days, it may be a good idea
to include an explanation/warning about the situation in the
installer text.
-

In regards to Martin Löwis' concern about non-admin users
not being able to cause the generation of .pyc files in the
main Python directory tree: It's already like that on most
OS's, correct? So it would just apply in cases where someone
a) writes an add-on specifically targeting the Python
directory tree, specifi

[ python-Bugs-1482746 ] asyncore is not listed in test_sundry

[SourceForge.net]

Bugs item #1482746, was opened at 2006-05-05 21:08
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482746&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: Works For Me
Priority: 5
Submitted By: jackilyn (jackilyn)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore is not listed in test_sundry

Initial Comment:
I was adding logging to asyncore and I noticed asyncore
is not listed in test_sundry.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-06 06:28

Message:
Logged In: YES 
user_id=849994

asyncore is already imported by test_asynchat.

--

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

[ python-Bugs-1482988 ] docs for 'profile' should refer to pstats.Stats

[SourceForge.net]

Bugs item #1482988, was opened at 2006-05-06 15:54
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=1482988&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: Ori Peleg (oripel)
Assigned to: Nobody/Anonymous (nobody)
Summary: docs for 'profile' should refer to pstats.Stats

Initial Comment:
The docs for module 'profile' refer to 'profile.Stats',
which look like:

def Stats(*args):
print 'Report generating functions are in the
"pstats" module\a'

This is true in older Python versions, as well as 2.5a2:

http://docs.python.org/dev/lib/module-profile.html

Suggestion: have the documentation point to
pstats.Stats instead, and possibly remove the
placeholder 'Stats' in module profile, or have it raise
an exception instead of printing an error.


------

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

[ python-Bugs-1482988 ] docs for 'profile' should refer to pstats.Stats

[SourceForge.net]

Bugs item #1482988, was opened at 2006-05-06 15:54
Message generated for change (Comment added) made by oripel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1482988&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: Ori Peleg (oripel)
Assigned to: Nobody/Anonymous (nobody)
Summary: docs for 'profile' should refer to pstats.Stats

Initial Comment:
The docs for module 'profile' refer to 'profile.Stats',
which look like:

def Stats(*args):
print 'Report generating functions are in the
"pstats" module\a'

This is true in older Python versions, as well as 2.5a2:

http://docs.python.org/dev/lib/module-profile.html

Suggestion: have the documentation point to
pstats.Stats instead, and possibly remove the
placeholder 'Stats' in module profile, or have it raise
an exception instead of printing an error.


--

>Comment By: Ori Peleg (oripel)
Date: 2006-05-06 15:57

Message:
Logged In: YES 
user_id=1131251

A correction - the docs do refer to the 'this class from the
pstats module', but this easily missed by someone skipping
carefully reading the preamble text (like me :-/ )

You could say this is PEBKAC (problem exists between
keyboard and chair), but I suggest it's a common phenomenon
meaning the pointer to module 'pstats' should be more prominent.

------

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

[ python-Bugs-1480678 ] mmap tries to truncate special files

[SourceForge.net]

Bugs item #1480678, was opened at 2006-05-02 13:56
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1480678&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: Not a Bug
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Carl Banks (aerojockey)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap tries to truncate special files

Initial Comment:
One Unix, the resize() method of an mmap object calls
ftruncate to also resize the associated file.  Problem
is, ftruncate fails if the fd refers to a special file.
 This is a problem for someone trying to resize an
anonymous memory map using /dev/zero.

Apparently hasn't been fixed in 2.5 (based on SVN and
changelogs) but I haven't tested it.

--

Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-05-06 12:29

Message:
Logged In: YES 
user_id=341410

The user could also os.tempnam() to come up with a file
name, create a 0-lengthed file, mmap it, unlink it, then
resize.  This method will create an anonymous mmap that is
resizable (according to the docs).

--

Comment By: Tim Peters (tim_one)
Date: 2006-05-03 12:02

Message:
Logged In: YES 
user_id=31435

I have to confess I don't know _why_ resize() changes the
size of the file too, and think that's a debatable design
decision.  But when code is working as intended and as
documented, by definition that's not "a bug".

The reason "it worked" in Python 2.3 is explained in bug 728515:

http://www.python.org/sf/728515

As it says there, it was a bug that resize() resized the
file on Windows, but neglected to do so on Unixish boxes at
the time.  That bug was fixed by making it resize the file
on Unixish boxes too.

Since the intent here is clear (albeit questionable) and
documented, I'm closing this as not-a-bug.

--

Comment By: Carl Banks (aerojockey)
Date: 2006-05-03 11:19

Message:
Logged In: YES 
user_id=1515186

Well, since resizing an anonymous array seems a reasonable
thing to do, and because it worked in Python 2.3, I presumed
that the error was an oversight, and not intended behavior.

If it is, in fact, intended behavior, then ok, though I
don't agree with it.  (It's not as if /dev/zero has fixed
size that doesn't change; it's inherently sizeless.)

--

Comment By: Tim Peters (tim_one)
Date: 2006-05-02 23:13

Message:
Logged In: YES 
user_id=31435

Ya, this isn't a bug:  resize() is documented as changing
the size of _both_ the map and the file.  If the size of the
file can't be changed, then of course resize() will fail.

aerojockey:  can't you simply close your current map and
create a new map with the size you want?

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-02 22:21

Message:
Logged In: YES 
user_id=33168

I don't understand what the problem is.  ISTM if you resize
a special file an exception will be raised.  Is that not the
case?  What do you expect to happen?

------

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

[ python-Bugs-1483133 ] Objects/genobject.c:53: gen_iternext: Assertion `f->f_back !

[SourceForge.net]

Bugs item #1483133, was opened at 2006-05-07 00:09
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=1483133&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: svensoho (svensoho)
Assigned to: Nobody/Anonymous (nobody)
Summary: Objects/genobject.c:53: gen_iternext: Assertion `f->f_back !

Initial Comment:
Seems to be similar bug as http://sourceforge.net/
tracker/index.php?
func=detail&aid=1257960&group_id=5470&atid=105470 
(fixed)

Couldn't trigger with same script but with C 
application. Same source modification helps (at 
Objects/genobject.c:53)

--

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

[ python-Bugs-595601 ] file (& socket) I/O are not thread safe

[SourceForge.net]

Bugs item #595601, was opened at 2002-08-15 11:34
Message generated for change (Comment added) made by aegis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595601&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: file (& socket) I/O are not thread safe

Initial Comment:
We recently found an assertion failure in the universal
newline support when running a multithreaded program
where two threads used the same Python file object. 
The assert(stream != NULL) test in 
Py_UniversalNewlineFread() fails once in a blue moon,
where stream is the stdio FILE * that the fileobject
wraps.  Further analysis suggests that there is a race
condition between checking FILE * and using FILE * that
exists in at least Python 2.1 and up.

I'll actually describe the problem as it exists in
Python 2.2, because it is simpler to avoid the
universal newline code.  That code isn't the source of
the problem, although it's assert() uncovers it in a
clear way.

In file_read() (rev 2.141.6.5), the first thing it does
is check if f_fp (the FILE *) is NULL.  If so it raises
an IOError -- operation on closed file object.  Later,
file_read() enters a for loop that calls fread() until
enough bytes have been read.

for (;;) {
Py_BEGIN_ALLOW_THREADS
errno = 0;
chunksize = fread(BUF(v) + bytesread, 1,
  buffersize - bytesread, f->f_fp);
Py_END_ALLOW_THREADS
if (chunksize == 0) {
if (!ferror(f->f_fp))
break;
PyErr_SetFromErrno(PyExc_IOError);
clearerr(f->f_fp);
Py_DECREF(v);
return NULL;
}

The problem is that fread() is called after the global
interpreter lock is released.  Since the lock is
released, another Python thread could run and modify
the file object, changing the value of f->f_fp.  Under
the current interpreter lock scheme, it isn't safe to
use f->f_fp without holding the interpreter lock.

The current file_read() code can fail in a variety of
ways.  It's possible for a second thread to close the
file, which will set f->f_fp to NULL.  Who knows what
fread() will do when NULL is passed.

The universal newline code is squirrels the FILE * in a
local variable, which is worse.  If it happens that
another thread closes the file, at best the local
points to a closed FILE *.  But that memory could get
recycled and then there's no way to know what it points to.

socket I/O has a similar problem with unsafe sharing of
the file descriptor.  However, this problem seems less
severe in general, because we'd just be passing a bogus
file descriptor to a system call.  We don't have to
worry about whether stdio will dump core when passed a
bogus pointer.  There is a chance the a socket will be
closed and its file descriptor used for a different
socket.  So a call to recv() with one socket ends up
using a different socket.  That will be a nightmare to
debug, but it won't cause a segfault.  (And, in
general, files and sockets shouldn't be shared between
application threads unless the application is going to
make sure its safe.)

The solution to this problem is to use a
per-file-object lock to guard access to f->f_fp.  No
thread should read or right f->f_fp without holding the
lock.  To make sure that other threads get a chance to
run when there is contention for the file, the
file-object lock should never be held when the GIL is held.


--

Comment By: Chad Austin (aegis)
Date: 2006-05-07 06:38

Message:
Logged In: YES 
user_id=7212

I'd like to add that this particular problem cost me about a
week of trying to figure out what the heck was going on, a
stack trace thrown from Python is MUCH better than
intermittent last-chance exceptions thrown from our binaries
in the field.  :)

http://aegisknight.livejournal.com/128191.html


--

Comment By: Jeremy Hylton (jhylton)
Date: 2002-08-20 15:49

Message:
Logged In: YES 
user_id=31392

Here's a checkpoint of current progress.  The patch applies
cleanly and even compiles.  It works most of the time, but
it causes a bunch of test failures.  I haven't had time to
debug the errors, two likely errors are incorrect
propagation of errors from across the release lock boundary.
 (The error checking goes on inside so that clearerr() can
be called while the file l

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

[SourceForge.net]

Bugs item #1471427, was opened at 2006-04-16 22:34
Message generated for change (Comment added) made by alexanderweb
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: Fixed
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: Alexander Schremmer (alexanderweb)
Date: 2006-05-07 13:55

Message:
Logged In: YES 
user_id=254738

Thanks, that seems to work. Try to get this into Py 2.5 :)

--

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-1481770 ] hpux ia64 shared lib ext should be ".so"

[SourceForge.net]

Bugs item #1481770, was opened at 2006-05-04 05:43
Message generated for change (Comment added) made by deckrider
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: David Everly (deckrider)
Assigned to: Nobody/Anonymous (nobody)
Summary: hpux ia64 shared lib ext should be ".so"

Initial Comment:
On hpux ia64, the shared library extension should be
".so".  This is currently problematic in that other
add-on python modules (such as those for subversion)
correctly detect the host_os/host_cpu and build
_module.so, which is not seen by python built using ".sl".

According to
http://devresource.hp.com/drc/resources/portguideipf/index.jsp#dynlinkfac


"Shared library names

Since dynamic linking APIs operate on shared libraries,
it is also important to note that the shared library
naming scheme on Linux is lib*.so; whereas, on HP-UX
11i Version 1.5 the naming scheme is lib*.sl for PA and
lib*.so on IPF. Also APIs may reside in different
libraries files on Linux and HP-UX, so you may need to
dynamically load a different shared library name on
HP-UX and Linux."

To translate this quote, PA=hppa and IPF=ia64.


--

>Comment By: David Everly (deckrider)
Date: 2006-05-07 07:22

Message:
Logged In: YES 
user_id=1113403

Here is a patch against
http://svn.python.org/projects/python/branches/release24-maint

I don't have many evironments to test against, and only
Linux right now (will test on HPUX ia64 tomorrow and report
back).

--

Comment By: David Everly (deckrider)
Date: 2006-05-05 06:07

Message:
Logged In: YES 
user_id=1113403

The patch I'm using now only works on hppa/ia64 and isn't
anything that can coexist nicely in the source package on
other hardware/os combinations.

I've looked at
http://svn.python.org/projects/python/branches/release24-maint/

I'm accustomed to a system using autoconf/libtool/automake
(recent versions) and never committing the output of those
tools, but only running them at source package generation time.

I say this, only to point out that I'm not understanding the
principles behind what I see in subversion.  I see
configure, and also configure.in.  Which should be patched?
 And if I don't patch configure, what is the process for
regenerating it (and with what versions of automake,
autoconf, and libtool?).

Also, the most recent libtool already correctly determines
shared library extension.

So I could probably provide a patch, but would need to
understand the environment better in order to do so.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-05-05 01:02

Message:
Logged In: YES 
user_id=33168

Do you think you could work on a patch to address this issue?

------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1481770&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-1110010 ] 'attrmap' function, attrmap(x)['attname'] == x.attname

[SourceForge.net]

Feature Requests item #1110010, was opened at 2005-01-26 11:28
Message generated for change (Comment added) made by gregsmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&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: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname

Initial Comment:
One of the side effects of the new-style classes is that
objects don't necessarily have __dict__ attached to them.
It used to be possible to write things like

   def __str__(self):
  return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % self.__dict__


... but this doesn't work if the class doesn't have a
__dict__. Even if does, I'm not sure it will always get
members from base classes.

There is a 'vars' function; you could put 'vars(self)'
in the above instead of self.__dict__, but it still
doesn't work if
the class doesn't have a __dict__.

I can see different solutions for this:

(1) change the 'string %' operator so that it allows
 %(.name)s, leading to a getattr() on the right-side
argument
  rather than a getitem. 

  return "Node %(.name)s, %(.nlinks)d links,
active: %(.active)s" % self

(2) Make a builtin like vars, but which works when the
object doesn't have a __dict__ I.e. attrmap(x) would
return a mapping which is bound to x, and reading
attrmap(x)['attname'] is the same as
getattr(x,'attname'). Thus

  return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % attrmap(self)


This attrmap() function can be implemented in pure
python, of course.

I originally thought (1) made a lot of sense, but (2) seems
to work just as well and doesn't require changing much.
Also, (1) allows  cases like "%(name)s %(.name2)s",
which are not very useful, but are very likely to be
created by
accident; whereas in (2) you are deciding on the right
of the '%' whether you are naming attributes or
providing mapping keys. 

I'm not sure it's a good idea change 'vars' to have
this behaviour, since vars(x).keys() currently works in
a predictable way when vars(x) works; whereas
attrmap(x).keys() may not be complete, or possible, 
even when attrmap(x) is useful. I.e. when x has a
__getattr__ defined.
On the other hand, vars(x) doesn't currently do much at
all, so maybe it's possible to enhance it like this
without breaking anything.

The motivation for this came from the "%(name)s" issue,
but the attrmap() function would be useful in other
places e.g.

processdata( infile,  outfile, **attrmap(options))

... where options might be obtained from optparse, e.g.
  
Or, an attrmap can be used with the new Templates:
string.Template('Node $name').substitute( attrmap(node))

Both of these examples will work with vars(), but only
when the object actually has __dict__. This is why
I'm thinking it may make sense to enhance vars: some
code may be broken by the change; but other code,
broken by new-style classes, may be unbroken by this
change.

The proxy could be writable, so that
attrmap(x)['a'] = y
is the same as
 x.a = y
.. which could have more uses.

A possible useful (possibly weird) variation: attrmap
accepts 1 or more parameters, and the resulting
proxy is bound to all of them. when attrmap(x,y,z)['a']
is done, the proxy will try x.a, y.a, z.a until one of
them doesn't raise AttributeError. So it's equivalent
to merging dictionaries. This would be useful
in the %(name)s or Template cases, where you want
information from several objects.





--

>Comment By: Gregory Smith (gregsmith)
Date: 2006-05-07 11:27

Message:
Logged In: YES 
user_id=292741

I can't disagree with that -- one of the things I like about
python is that simple funcs I use fairly often can usually
be retyped out of my head in less time than it takes to find
them and copy them from another software project- and more
importantly, there's basically no risk that the fresh one
will be buggy, if it's expression is simple and clear.
So, the overhead of maintaining a zillion 'standard' utility
funcs outweighs the cost of having to recode them instead,
when they are small and simple. This applies as much to the
core library as it does to a site-specific library.

I do prefer if they have the same names each time I use them
though, since it makes it easier to transplant higher-level
chunks of code from one program to another. When I ra

[ python-Bugs-1483384 ] Add set.member() method

[SourceForge.net]

Bugs item #1483384, was opened at 2006-05-07 11:41
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=1483384&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: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Tsai (michaeltsai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add set.member() method

Initial Comment:
Right now, when I check membership in a set, the __in__ method just 
returns True/False if there is an object in the set that's == to the 
argument. I would like to have a member() method that returns the object 
in the set or raises KeyError if the argument is not in the set. This would 
be useful for interning and other cases where right now I'd use a 
degenerate dictionary where the keys and values are equal.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483384&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-1483384 ] Add set.member() method

[SourceForge.net]

Feature Requests item #1483384, was opened at 2006-05-07 15:41
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1483384&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Tsai (michaeltsai)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Add set.member() method

Initial Comment:
Right now, when I check membership in a set, the __in__ method just 
returns True/False if there is an object in the set that's == to the 
argument. I would like to have a member() method that returns the object 
in the set or raises KeyError if the argument is not in the set. This would 
be useful for interning and other cases where right now I'd use a 
degenerate dictionary where the keys and values are equal.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-07 20:36

Message:
Logged In: YES 
user_id=849994

Moving to Feature Requests. Note that I do not think Raymond
will agree to this.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1483384&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-1483384 ] Add set.member() method

[SourceForge.net]

Feature Requests item #1483384, was opened at 2006-05-07 10:41
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1483384&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Tsai (michaeltsai)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Add set.member() method

Initial Comment:
Right now, when I check membership in a set, the __in__ method just 
returns True/False if there is an object in the set that's == to the 
argument. I would like to have a member() method that returns the object 
in the set or raises KeyError if the argument is not in the set. This would 
be useful for interning and other cases where right now I'd use a 
degenerate dictionary where the keys and values are equal.

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-05-08 00:37

Message:
Logged In: YES 
user_id=80475

I'm curious to see some of your dictionary examples that 
do not seem to tranlate cleanly with the existing set API.

In published code, I've not seen people writing anything 
like what is being requested, i.e. I haven't seen 
fragments like:
   if x in s:
  return x
   else:
  raise KeyError



--

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-07 15:36

Message:
Logged In: YES 
user_id=849994

Moving to Feature Requests. Note that I do not think Raymond
will agree to this.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1483384&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-1483384 ] Add set.member() method

[SourceForge.net]

Feature Requests item #1483384, was opened at 2006-05-07 11:41
Message generated for change (Comment added) made by michaeltsai
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1483384&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Tsai (michaeltsai)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Add set.member() method

Initial Comment:
Right now, when I check membership in a set, the __in__ method just 
returns True/False if there is an object in the set that's == to the 
argument. I would like to have a member() method that returns the object 
in the set or raises KeyError if the argument is not in the set. This would 
be useful for interning and other cases where right now I'd use a 
degenerate dictionary where the keys and values are equal.

--

>Comment By: Michael Tsai (michaeltsai)
Date: 2006-05-08 08:07

Message:
Logged In: YES 
user_id=817528

Well, the example you wrote doesn't capture the pattern I was thinking of. I'm 
thinking of cases like:

d = {}
#...
x = d.setDefault(x, x)

where I want to get the canonical x. This might be x itself, or it might be 
another object that's ==. I doubt you've seen set code that does this with 
sets, because I don't think it's possible with the existing set API to do this 
efficiently.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2006-05-08 01:37

Message:
Logged In: YES 
user_id=80475

I'm curious to see some of your dictionary examples that 
do not seem to tranlate cleanly with the existing set API.

In published code, I've not seen people writing anything 
like what is being requested, i.e. I haven't seen 
fragments like:
   if x in s:
  return x
   else:
  raise KeyError



--

Comment By: Georg Brandl (gbrandl)
Date: 2006-05-07 16:36

Message:
Logged In: YES 
user_id=849994

Moving to Feature Requests. Note that I do not think Raymond
will agree to this.

------

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

[ python-Bugs-1483785 ] Doctest bug

[SourceForge.net]

Bugs item #1483785, was opened at 2006-05-08 14:53
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=1483785&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: stnsls (stnsls)
Assigned to: Nobody/Anonymous (nobody)
Summary: Doctest bug

Initial Comment:
When i run doctest on the module, i get that error: 
 
 
 
[EMAIL PROTECTED] Spyca]$ python Spyca.py 
** 
File "Spyca.py", line 840, in 
__main__.City.Select_all 
Failed example: 
print City.Select_all(Country.Get_rowid('')) 
Exception raised: 
Traceback (most recent call last): 
  File "/usr/lib/python2.4/doctest.py", line 
1243, in __run 
compileflags, 1) in test.globs 
  File "", 
line 1, in ? 
print 
City.Select_all(Country.Get_rowid('')) 
  File "Spyca.py", line 846, in Select_all 
return [cls(i) for i in 
Db.Exec(sql).fetchall()] 
  File "Spyca.py", line 760, in __init__ 
elif isinstance(this, tuple) or 
isinstance(this, list): self.Select_seq(this) 
  File "Spyca.py", line 817, in Select_seq 
if not isinstance(seq[3], Latitude): raise 
SpycaException(SpycaInitError, type(seq[3])) 
SpycaException: Instanciation or argument error. 
[] 
** 
1 items had failures: 
   1 of   1 in __main__.City.Select_all 
***Test Failed*** 1 failures. 
 
 
 
Now, when i do all the same in the interpreter: 
 
 
 
 
[EMAIL PROTECTED] Spyca]$ python 
Python 2.4.1 (#2, Aug 25 2005, 18:20:57) 
[GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release 
2006.0)] on linux2 
Type "help", "copyright", "credits" or "license" for 
more information. 
>>> import Spyca as S 
>>> lat = S.Latitude() 
>>> lon = S.Longitude() 
>>> seq = (None, 'myCity', None, lat, lon, 0, '') 
>>> c = S.City(seq) 
>>> print c 
myCity 
>>> repr(c) 
"[None, 'myCity', None, [0, 0 ,0, 0.0], [0, 0 ,0, 
0.0], 0, '']" 
>>> 
 
 
 
As you can see, no error in the interpreter. 
 
 
 
Have a nice day. Thanks for the best scripting 
language ;) 
 

--

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

[ python-Bugs-1483785 ] Doctest bug

[SourceForge.net]

Bugs item #1483785, was opened at 2006-05-08 14:53
Message generated for change (Settings changed) made by stnsls
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483785&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: Deleted
Resolution: None
Priority: 5
Submitted By: stnsls (stnsls)
Assigned to: Nobody/Anonymous (nobody)
Summary: Doctest bug

Initial Comment:
When i run doctest on the module, i get that error: 
 
 
 
[EMAIL PROTECTED] Spyca]$ python Spyca.py 
** 
File "Spyca.py", line 840, in 
__main__.City.Select_all 
Failed example: 
print City.Select_all(Country.Get_rowid('')) 
Exception raised: 
Traceback (most recent call last): 
  File "/usr/lib/python2.4/doctest.py", line 
1243, in __run 
compileflags, 1) in test.globs 
  File "", 
line 1, in ? 
print 
City.Select_all(Country.Get_rowid('')) 
  File "Spyca.py", line 846, in Select_all 
return [cls(i) for i in 
Db.Exec(sql).fetchall()] 
  File "Spyca.py", line 760, in __init__ 
elif isinstance(this, tuple) or 
isinstance(this, list): self.Select_seq(this) 
  File "Spyca.py", line 817, in Select_seq 
if not isinstance(seq[3], Latitude): raise 
SpycaException(SpycaInitError, type(seq[3])) 
SpycaException: Instanciation or argument error. 
[] 
** 
1 items had failures: 
   1 of   1 in __main__.City.Select_all 
***Test Failed*** 1 failures. 
 
 
 
Now, when i do all the same in the interpreter: 
 
 
 
 
[EMAIL PROTECTED] Spyca]$ python 
Python 2.4.1 (#2, Aug 25 2005, 18:20:57) 
[GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release 
2006.0)] on linux2 
Type "help", "copyright", "credits" or "license" for 
more information. 
>>> import Spyca as S 
>>> lat = S.Latitude() 
>>> lon = S.Longitude() 
>>> seq = (None, 'myCity', None, lat, lon, 0, '') 
>>> c = S.City(seq) 
>>> print c 
myCity 
>>> repr(c) 
"[None, 'myCity', None, [0, 0 ,0, 0.0], [0, 0 ,0, 
0.0], 0, '']" 
>>> 
 
 
 
As you can see, no error in the interpreter. 
 
 
 
Have a nice day. Thanks for the best scripting 
language ;) 
 

--

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

[ python-Bugs-1483963 ] struct.unpack problem with @, =, < specifiers

[SourceForge.net]

Bugs item #1483963, was opened at 2006-05-08 13: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=1483963&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: Christian Hudon (chrish42)
Assigned to: Nobody/Anonymous (nobody)
Summary: struct.unpack problem with @, =, < specifiers

Initial Comment:
When using struct to unpack floats, I'm getting
inconsistent results when using the '>> sys.byteorder
'little'

# This is correct...
>>> struct.unpack('@d', s)
(nan,)

# These should be equivalent for unpacking a single 
# double on little-endian arch... but they're not.
>>> struct.unpack('>> struct.unpack('=d', s)
(inf,)


------

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

[ python-Bugs-1483997 ] pydoc doesn't create html-file

[SourceForge.net]

Bugs item #1483997, was opened at 2006-05-08 19:59
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=1483997&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: Gregor Lingl (glingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc doesn't create html-file

Initial Comment:
The call

c:\Python25\Lib\pydoc.py -w testdoc

results in an error-message:

Traceback ...
  File ...
  ...
 
  ...
  File "c:\Python25\Lib\inspect.py",line 564,in walktree
   classes.sort(key=attrgetter('__module__','__name__'))
TypeError: attrgetter expected 1 arguments, got 2

The same call with Python 2.4 works correctly

regards,

Gregor Lingl


------

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

[ python-Bugs-1417699 ] float/atof have become locale aware

[SourceForge.net]

Bugs item #1417699, was opened at 2006-01-29 01:04
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1417699&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: 7
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Martin v. Löwis (loewis)
Summary: float/atof have become locale aware

Initial Comment:
The builtin float and the function string.atof have
become locale aware in Python 2.4:

Python 2.4.2 (#1, Nov 29 2005, 16:07:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import locale
>>> import string
>>> locale.setlocale(locale.LC_ALL, "de_DE")
'de_DE'
>>> float("1,5")
1.5
>>> string.atof("1,5")
1.5


This doesn't match what's specified in pep 331:

- float() and str() stay locale-unaware.

It also doesn't match the documentation for atof:

  Convert a string to a floating point number.
  The string must have the standard syntax for a
  floating point literal in Python, optionally
  preceded by a sign ("+" or "-"). Note that this
  behaves identical to the built-in function float()
  when passed a string.

The documentation for float() doesn't state which
format is accepted by float(), though.

The reason for this behavior is ultimately, that
PyOS_ascii_strtod accepts the locale specific
convention in addition to the "C"-locale/python
convention, even though the comment in the code
preceding its definition states:

  This function behaves like the standard strtod() 
  function does in the C locale.




--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-05-08 18:00

Message:
Logged In: YES 
user_id=849994

I grepped around and found PyOS_ascii_strtod in the
following places:

* stropmodule::atof
* cPickle::load_float (the writing of locale dependent
floats was fixed recently)
* floatobject::PyFloat_FromString
* complexobject::complex_subtype_from_string

In my opinion, all these should not tolerate localized
floats, so Gustavo, please ask the original author how to
achieve this.

--

Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-05-04 09:47

Message:
Logged In: YES 
user_id=908

My comment is, is "PyOS_ascii_strtod accepting both forms"
something that is harmful and should be fixed?

I didn't exactly write the PyOS_ascii_strtod code; I only
integrated it with Python.  But if we really need to fix
this, I'll try to figure out how to make it not accept
floating points in locale aware format; if necessary I'll
ask help from  the original author of the code, Alexander
Larsson.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-05-04 04:42

Message:
Logged In: YES 
user_id=21627

It's a bug. As bernhard says, it originates from
PyOS_ascii_strtod accepting both forms, which in turn
happens because it just leaves the locale-specific decimal
point in the string, only replacing the . with the
locale-specific point. Then, the platform's strtod will
happily accept the locale-specific version. 

I'd like Gustavo Carneiro to comment.

--

Comment By: Georg Brandl (birkenfeld)
Date: 2006-02-17 12:19

Message:
Logged In: YES 
user_id=1188172

Martin, you checked in the patch which is mentioned in PEP
331. Is this correct behavior?

--

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

[ python-Bugs-1484172 ] hyper-threading locks up sleeping threads

[SourceForge.net]

Bugs item #1484172, was opened at 2006-05-08 16:45
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=1484172&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: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Olaf Meding (olafmeding)
Assigned to: Nobody/Anonymous (nobody)
Summary: hyper-threading locks up sleeping threads

Initial Comment:
Below are 2 files.  The first is a Python program that 
demonstrates the problem within less than 1 hour 
(often just a few minutes).  The second is a C++ 
program that shows that the Win32 Sleep() function 
works as expected (the program was started 3 days ago 
and is still running).

Note, I also attached the source code.

Note, the Python programs hangs (stops responding) 
with hyper-threading turned on (a BIOS setting), but 
works as expected with hyper-threading turned off.

This problem happens on Windows only (the below Python 
program ran for 24 hours on Linux without a problem).

Variations of the Python program also lock up:

Tried importing win32api instead of importing time and 
using the win32api.GetTickCount() and win32api.Sleep() 
methods.

Tried using lock = threading.Event() and lock.wait() 
instead of time.sleep().

Tried importing Queue and using q = Queue.Queue() and 
q.get(True, sleepTime).

Note, the Windows task manager shows 2 CPUs on the 
Performance tab with hyper-threading is turned on.

Both Python 2.3.5 and 2.4.3 (downloaded from 
python.org) have this problem.

The operating system is MS Windows XP Professional.

winmsd.exe (Start Menu > Run) shows:
2CPUs: x86 Family 15 Model 4 Stepping 1 GenuineIntel 
~3000 MHz
Version: 5.1.2600 Service Pack 2 Build 2600

Could someone with a hyper-threading (or dual-core or 
multi-processor) CPU please confirm this bug?

Many Thanks

Olaf


Here is the expected output of both programs (the 
progam has locked up if the numbers stop printing 
every 10 seconds or so):
python testsleep.py
thread 1 started, sleep time 0.010
thread 2 started, sleep time 0.003
1 1 1 2 1 1 1 2 1 1 1 2 1 1 1 1 2 1 1 1

# testsleep.py
import threading
import time

class Task(threading.Thread):
def __init__(self, n, t):
threading.Thread.__init__(self)
self.n = n  # thread id
self.t = t  # sleep time
def run(self):
print 'thread %d started, sleep time 
%.3f' % (self.n, self.t)
count = 0
printCount = int(10 / self.t)
while True:
start = time.clock()
time.sleep(self.t)
stop = time.clock()
if stop - start > 1.0:
print 'thread', 
self.n, stop - start

count += 1
if count > printCount:
count = 0
print self.n,  # print 
sign of live

def test():
thread1 = Task(1, 0.01)  # thread 1, sleep 10 
ms
thread2 = Task(2, 0.003) # thread 2, sleep  3 
ms
thread1.start()
thread2.start()

test()

---
---

// testsleep.cpp
// Compiled with Visual C++ version 6 (in debug mode) 
as a Win32 console application.

#include 
#include 
#include 

typedef struct {
int id;
int ms;

} param_s;

DWORD WINAPI threadFunction(LPVOID param)
{
param_s* p = (param_s*)param;
long elapsedTime;
long time1, time2;
long printCount = long(1 / p->ms);  // loop 
iterations in 10 seconds
long count = 0;

printf("thread %d started, sleep time: %d 
ms" "\n", p->id, p->ms);

while(true) {
time1 = GetTickCount();
Sleep(p->ms);
time2 = GetTickCount();

elapsedTime = time2 - time1;
if(elapsedTime > 1000)
printf("thread %d slept for %d ms" "\n", p-
>id, elapsedTime);

count++;
if(count > printCount) {
count = 0;
printf("%d ", p->id);  // print sign of 
live
}
}

return 0;
}

int main(int argc, char* argv[])
{
param_s p1, p2;

p1.id = 1;
p1.ms = 10;

p2.id = 2;
p2.ms = 3;

CreateThread(NULL, 0, threadFunction, (void*)&p1, 
0, NULL);
CreateThread(NULL, 0, threadFunction, (void*)&p2, 
0, NULL);

getchar();  // wait until the user presses the 
enter key.

return 0; 
}

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105

[ python-Bugs-1484172 ] hyper-threading locks up sleeping threads

[SourceForge.net]

Bugs item #1484172, was opened at 2006-05-08 17:45
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1484172&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: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Olaf Meding (olafmeding)
Assigned to: Nobody/Anonymous (nobody)
Summary: hyper-threading locks up sleeping threads

Initial Comment:
Below are 2 files.  The first is a Python program that 
demonstrates the problem within less than 1 hour 
(often just a few minutes).  The second is a C++ 
program that shows that the Win32 Sleep() function 
works as expected (the program was started 3 days ago 
and is still running).

Note, I also attached the source code.

Note, the Python programs hangs (stops responding) 
with hyper-threading turned on (a BIOS setting), but 
works as expected with hyper-threading turned off.

This problem happens on Windows only (the below Python 
program ran for 24 hours on Linux without a problem).

Variations of the Python program also lock up:

Tried importing win32api instead of importing time and 
using the win32api.GetTickCount() and win32api.Sleep() 
methods.

Tried using lock = threading.Event() and lock.wait() 
instead of time.sleep().

Tried importing Queue and using q = Queue.Queue() and 
q.get(True, sleepTime).

Note, the Windows task manager shows 2 CPUs on the 
Performance tab with hyper-threading is turned on.

Both Python 2.3.5 and 2.4.3 (downloaded from 
python.org) have this problem.

The operating system is MS Windows XP Professional.

winmsd.exe (Start Menu > Run) shows:
2CPUs: x86 Family 15 Model 4 Stepping 1 GenuineIntel 
~3000 MHz
Version: 5.1.2600 Service Pack 2 Build 2600

Could someone with a hyper-threading (or dual-core or 
multi-processor) CPU please confirm this bug?

Many Thanks

Olaf


Here is the expected output of both programs (the 
progam has locked up if the numbers stop printing 
every 10 seconds or so):
python testsleep.py
thread 1 started, sleep time 0.010
thread 2 started, sleep time 0.003
1 1 1 2 1 1 1 2 1 1 1 2 1 1 1 1 2 1 1 1

# testsleep.py
import threading
import time

class Task(threading.Thread):
def __init__(self, n, t):
threading.Thread.__init__(self)
self.n = n  # thread id
self.t = t  # sleep time
def run(self):
print 'thread %d started, sleep time 
%.3f' % (self.n, self.t)
count = 0
printCount = int(10 / self.t)
while True:
start = time.clock()
time.sleep(self.t)
stop = time.clock()
if stop - start > 1.0:
print 'thread', 
self.n, stop - start

count += 1
if count > printCount:
count = 0
print self.n,  # print 
sign of live

def test():
thread1 = Task(1, 0.01)  # thread 1, sleep 10 
ms
thread2 = Task(2, 0.003) # thread 2, sleep  3 
ms
thread1.start()
thread2.start()

test()

---
---

// testsleep.cpp
// Compiled with Visual C++ version 6 (in debug mode) 
as a Win32 console application.

#include 
#include 
#include 

typedef struct {
int id;
int ms;

} param_s;

DWORD WINAPI threadFunction(LPVOID param)
{
param_s* p = (param_s*)param;
long elapsedTime;
long time1, time2;
long printCount = long(1 / p->ms);  // loop 
iterations in 10 seconds
long count = 0;

printf("thread %d started, sleep time: %d 
ms" "\n", p->id, p->ms);

while(true) {
time1 = GetTickCount();
Sleep(p->ms);
time2 = GetTickCount();

elapsedTime = time2 - time1;
if(elapsedTime > 1000)
printf("thread %d slept for %d ms" "\n", p-
>id, elapsedTime);

count++;
if(count > printCount) {
count = 0;
printf("%d ", p->id);  // print sign of 
live
}
}

return 0;
}

int main(int argc, char* argv[])
{
param_s p1, p2;

p1.id = 1;
p1.ms = 10;

p2.id = 2;
p2.ms = 3;

CreateThread(NULL, 0, threadFunction, (void*)&p1, 
0, NULL);
CreateThread(NULL, 0, threadFunction, (void*)&p2, 
0, NULL);

getchar();  // wait until the user presses the 
enter key.

return 0; 
}

--

>Comment By: Tim Peters (tim_one)
Date: 2006-05-08 17:58

Message:
Logged In: YES 
user_id=31435

As noted (