[ python-Bugs-1452174 ] xmlrpclib.py problem solved
Bugs item #1452174, was opened at 2006-03-17 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=1452174&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: Open Resolution: None Priority: 5 Submitted By: varun bhansaly (varun_bhansaly) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib.py problem solved Initial Comment: hi, I have found a solution, to my problem of xmlrpclib.py. regards, -VB -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452174&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1452174 ] xmlrpclib.py problem solved
Bugs item #1452174, was opened at 2006-03-17 10:37 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452174&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: Deleted >Resolution: Invalid Priority: 5 Submitted By: varun bhansaly (varun_bhansaly) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib.py problem solved Initial Comment: hi, I have found a solution, to my problem of xmlrpclib.py. regards, -VB -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452174&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1446690 ] bug with xmlrpclib
Bugs item #1446690, was opened at 2006-03-09 19:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446690&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: XML Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 9 Submitted By: varun bhansaly (varun_bhansaly) Assigned to: Nobody/Anonymous (nobody) Summary: bug with xmlrpclib Initial Comment: I am currently working on a project in which I am required to send some data from OpenOffice.org v2.0.(OOo) I have placed buttons on the spreadsheet, and a python script is to be invoked when the button is clicked. I am required to send the data in the spreadsheet to an app server, hence I am using XML-RPC to get this job done. The version of XML-RPC(xmlrpclib.py) I'm using is v1.36.2.1, The app server requires the connection to be authenticated, whereas the current xmlrpclib.py doesnot come with support for sending requests with basic authentication. In order to extend the capabilities of the xmlrpclib.py with http authentication, I have written code that provides necessary basic authentication.(class BasicAuthTransport in the attached file Project_saveFromOOoCalcAction.py) The actual connection and authentication details have been replaced for security reasons. When the button on the OOo spreadsheet is clicked, the script throws the following error. com.sun.star.uno.RuntimeExceptionexceptions.TypeError: request() got an unexpected keyword argument 'verbose', traceback follows File "usr/lib/python2.4/xmlrpclib.py", in line 1096, in __call__ return self.__send(self.__name,args) File "usr/lib/python2.4/xmlrpclib.py", in line 1383, in __request verbose=self.__verbose When I comment out the line 1383 of the above file, everything runs smoothly, this is a very trivial solution though,as this would require me to comment out the line 1383 of the above file n all the client machines in which the script has to executed. Hence I'm looking for a more viable solution. The files are attached along. Any help or advice in this regard shall be welcome. regards, -VB -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-17 10:59 Message: Logged In: YES user_id=849994 OP indicated that the problem is solved. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446690&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448639 ] asyncore dispatcher.__getattr__() masks self._map
Bugs item #1448639, was opened at 2006-03-13 05:52
Message generated for change (Comment added) made by zseil
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448639&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: Doug White (dwhite)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore dispatcher.__getattr__() masks self._map
Initial Comment:
The abstraction of socket_map in the asyncore module
in Python 2.4 forgets to allow accesses to the
internal attribute self._map in __getattr__(). This
causes any asyncore application to fail in
create_socket(), which pretty much renders asyncore
inoperative in Python 2.4.
This problem was introduced in rev 34469 as a commit
of Bug #758241.
Example backtrace, generated from an application that
uses Medusa servers that don't use the private map
function:
Traceback (most recent call last):
File "/usr/local/qos/qosserver/qos_server.py", line
1576, in ?
m = monitor.monitor_server ('127.0.0.1',
BasePort)
File "/usr/local/qos/qosserver/monitor.py", line
161, in __init__
self.create_socket (socket.AF_INET,
socket.SOCK_STREAM)
File "/usr/local/lib/python2.4/asyncore.py", line
261, in create_socket
self.add_channel()
File "/usr/local/lib/python2.4/asyncore.py", line
244, in add_channel
map = self._map
File "/usr/local/lib/python2.4/asyncore.py", line
366, in __getattr__
return getattr(self.socket, attr)
AttributeError: '_socketobject' object has no
attribute '_map'
__getattr__() should test if the attribute exists in
its own object before passing it on to the underlying
socket object.
--
Comment By: iga Seilnacht (zseil)
Date: 2006-03-17 12:37
Message:
Logged In: YES
user_id=1326842
This is a bug in your code, since you don't call the
base class's __init__() method, and as a consequence
the '_map' attribute really doesn't exist.
__getattr__() doesn't have to check for existance of
an attribute since it is called only when the normal
lookup mechanism fails. See the docs:
http://docs.python.org/ref/attribute-access.html
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448639&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448639 ] asyncore dispatcher.__getattr__() masks self._map
Bugs item #1448639, was opened at 2006-03-13 04:52
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448639&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: Invalid
Priority: 5
Submitted By: Doug White (dwhite)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore dispatcher.__getattr__() masks self._map
Initial Comment:
The abstraction of socket_map in the asyncore module
in Python 2.4 forgets to allow accesses to the
internal attribute self._map in __getattr__(). This
causes any asyncore application to fail in
create_socket(), which pretty much renders asyncore
inoperative in Python 2.4.
This problem was introduced in rev 34469 as a commit
of Bug #758241.
Example backtrace, generated from an application that
uses Medusa servers that don't use the private map
function:
Traceback (most recent call last):
File "/usr/local/qos/qosserver/qos_server.py", line
1576, in ?
m = monitor.monitor_server ('127.0.0.1',
BasePort)
File "/usr/local/qos/qosserver/monitor.py", line
161, in __init__
self.create_socket (socket.AF_INET,
socket.SOCK_STREAM)
File "/usr/local/lib/python2.4/asyncore.py", line
261, in create_socket
self.add_channel()
File "/usr/local/lib/python2.4/asyncore.py", line
244, in add_channel
map = self._map
File "/usr/local/lib/python2.4/asyncore.py", line
366, in __getattr__
return getattr(self.socket, attr)
AttributeError: '_socketobject' object has no
attribute '_map'
__getattr__() should test if the attribute exists in
its own object before passing it on to the underlying
socket object.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-17 11:51
Message:
Logged In: YES
user_id=849994
It seems that zseil is right. Closing as Invalid.
--
Comment By: iga Seilnacht (zseil)
Date: 2006-03-17 11:37
Message:
Logged In: YES
user_id=1326842
This is a bug in your code, since you don't call the
base class's __init__() method, and as a consequence
the '_map' attribute really doesn't exist.
__getattr__() doesn't have to check for existance of
an attribute since it is called only when the normal
lookup mechanism fails. See the docs:
http://docs.python.org/ref/attribute-access.html
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448639&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1452246 ] htmllib doesn't properly substitute entities
Bugs item #1452246, was opened at 2006-03-17 11:57
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=1452246&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: Helmut Grohne (gnarfk)
Assigned to: Nobody/Anonymous (nobody)
Summary: htmllib doesn't properly substitute entities
Initial Comment:
I'd like to illustrate and suggest a fix by showing a
simple python file (which was named htmllib2.py so you
can uncomment the line in the doctest case to see that
my fix works). It's more like a hack than the fix though:
#!/usr/bin/env python2.4
"""
Use this instead of htmllib for having entitydefs
substituted in attributes,too.
Example:
>>> import htmllib
# >>> import htmllib2 as htmllib
>>> import formatter
>>> import StringIO
>>> s = StringIO.StringIO()
>>> p =
htmllib.HTMLParser(formatter.AbstractFormatter(formatter.DumbWriter(s)))
>>> p.feed('')
>>> s.getvalue()
'<>&'
"""
__all__ = ("HTMLParser",)
import htmllib
from htmlentitydefs import name2codepoint as entitytable
entitytable = dict([(k, chr(v)) for k, v in
entitytable.items() if v < 256])
def entitysub(s):
ret = ""
state = ""
for c in s:
if state.startswith('&'):
if c == ';':
ret += entitytable.get(state[1:], '%s;'
% state)
state = ""
else:
state += c
elif c == '&':
state = c
else:
ret += c
return ret
class HTMLParser(htmllib.HTMLParser):
def handle_starttag(self, tag, method, attrs):
"""Repair attribute values."""
attrs = [(k, entitysub(v)) for (k, v) in attrs]
method(attrs)
if __name__ == '__main__':
import doctest
doctest.testmod()
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452246&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1441408 ] svn head compiler fails to spot extended slicing
Bugs item #1441408, was opened at 2006-03-02 11:20
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441408&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: svn head compiler fails to spot extended slicing
Initial Comment:
This is Python SVN HEAD:
>>> dis.dis(compile("x[::]", '', 'single'))
1 0 LOAD_NAME0 (x)
3 SLICE+0
4 PRINT_EXPR
5 LOAD_CONST 0 (None)
8 RETURN_VALUE
This is Python 2.4:
>>> dis.dis(compile("x[::]", '', 'single'))
1 0 LOAD_NAME0 (x)
3 LOAD_CONST 0 (None)
6 LOAD_CONST 0 (None)
9 LOAD_CONST 0 (None)
12 BUILD_SLICE 3
15 BINARY_SUBSCR
16 PRINT_EXPR
17 LOAD_CONST 0 (None)
20 RETURN_VALUE
--
>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-03-17 23:45
Message:
Logged In: YES
user_id=1038590
Alternate patch that doesn't modify the AST posted as 1452332
--
Comment By: Grant Olson (logistix)
Date: 2006-03-10 10:22
Message:
Logged In: YES
user_id=699438
Patch 1446847 Posted.
--
Comment By: Grant Olson (logistix)
Date: 2006-03-06 09:33
Message:
Logged In: YES
user_id=699438
This only happens when you have implicit slice values.
x[1:2:3] works fine. I'm finishing up a patch and will post
to sf shortly.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441408&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1184112 ] Missing trailing newline with comment raises SyntaxError
Bugs item #1184112, was opened at 2005-04-16 11:55
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184112&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing trailing newline with comment raises SyntaxError
Initial Comment:
The following illustrates a problem with the parser
handling the lack of trailing newlines:
>>> parser.suite('def foo():\n\tpass\n\n# comment')
Traceback (most recent call last):
File "", line 1, in ?
File "", line 4
# comment
^
SyntaxError: invalid syntax
>>> parser.suite('def foo():\n\tpass\n\n# comment\n')
This is similar to bug 501622, however, this only seems
to happen when you have an indented block, followed by
a comment line that has no trailing newline.
I traced through tokenizer.c and whittled down the issue
into tok_get(). In the statement where it is processing
the comment character and looking at the tabforms, in
the first case this will end up with 'c' equal to EOF
whereas in the second case "c" will eqaul '\n'. When it
equals EOF, it is unable to do the cleanup necessary to
emit the DEDENT token (it immediately bails out with
ENDMARKER which causes parsetok() to barf because
the indentation level is still 1 inside tok_state).
Attached is a patch of a little hack I made that seems
to fix the problem. Although it seems to be a safe thing
to do, it is definitely a hack.
--
>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-03-17 23:51
Message:
Logged In: YES
user_id=1038590
Confirmed on SVN HEAD using:
exec """
def foo():
pass
#comment"""
(Blows up with a syntax error)
--
Comment By: Eric Huss (ehuss)
Date: 2005-04-16 11:57
Message:
Logged In: YES
user_id=393416
Well, wonderful sourceforge is barfing with the
error "ArtifactFile: Could not open file for writing" when trying
to upload my patch, so I'll just post it in the comment here.
Very sorry. :(
--- tokenizer.c 3 Feb 2004 22:53:59 - 1.2
+++ tokenizer.c 16 Apr 2005 01:45:05 -
@@ -1139,6 +1139,9 @@
}
while (c != EOF && c != '\n')
c = tok_nextc(tok);
+ if (c == EOF) {
+ c = '\n';
+ }
}
/* Check for EOF and errors now */
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184112&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1184112 ] Missing trailing newline with comment raises SyntaxError
Bugs item #1184112, was opened at 2005-04-15 21:55
Message generated for change (Comment added) made by tjreedy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184112&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing trailing newline with comment raises SyntaxError
Initial Comment:
The following illustrates a problem with the parser
handling the lack of trailing newlines:
>>> parser.suite('def foo():\n\tpass\n\n# comment')
Traceback (most recent call last):
File "", line 1, in ?
File "", line 4
# comment
^
SyntaxError: invalid syntax
>>> parser.suite('def foo():\n\tpass\n\n# comment\n')
This is similar to bug 501622, however, this only seems
to happen when you have an indented block, followed by
a comment line that has no trailing newline.
I traced through tokenizer.c and whittled down the issue
into tok_get(). In the statement where it is processing
the comment character and looking at the tabforms, in
the first case this will end up with 'c' equal to EOF
whereas in the second case "c" will eqaul '\n'. When it
equals EOF, it is unable to do the cleanup necessary to
emit the DEDENT token (it immediately bails out with
ENDMARKER which causes parsetok() to barf because
the indentation level is still 1 inside tok_state).
Attached is a patch of a little hack I made that seems
to fix the problem. Although it seems to be a safe thing
to do, it is definitely a hack.
--
>Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-17 11:48
Message:
Logged In: YES
user_id=593130
As noted by F.Lundh on pydev list,
http://docs.python.org/lib/built-in-funcs.html
says "When compiling multi-line statements, two caveats
apply: [...] and the input must be terminated by at least
one newline character" so it appears that doc == behavior.
Should this be closed? or both changed?
--
Comment By: Nick Coghlan (ncoghlan)
Date: 2006-03-17 08:51
Message:
Logged In: YES
user_id=1038590
Confirmed on SVN HEAD using:
exec """
def foo():
pass
#comment"""
(Blows up with a syntax error)
--
Comment By: Eric Huss (ehuss)
Date: 2005-04-15 21:57
Message:
Logged In: YES
user_id=393416
Well, wonderful sourceforge is barfing with the
error "ArtifactFile: Could not open file for writing" when trying
to upload my patch, so I'll just post it in the comment here.
Very sorry. :(
--- tokenizer.c 3 Feb 2004 22:53:59 - 1.2
+++ tokenizer.c 16 Apr 2005 01:45:05 -
@@ -1139,6 +1139,9 @@
}
while (c != EOF && c != '\n')
c = tok_nextc(tok);
+ if (c == EOF) {
+ c = '\n';
+ }
}
/* Check for EOF and errors now */
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1184112&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1441408 ] svn head compiler fails to spot extended slicing
Bugs item #1441408, was opened at 2006-03-02 11:20
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441408&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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: svn head compiler fails to spot extended slicing
Initial Comment:
This is Python SVN HEAD:
>>> dis.dis(compile("x[::]", '', 'single'))
1 0 LOAD_NAME0 (x)
3 SLICE+0
4 PRINT_EXPR
5 LOAD_CONST 0 (None)
8 RETURN_VALUE
This is Python 2.4:
>>> dis.dis(compile("x[::]", '', 'single'))
1 0 LOAD_NAME0 (x)
3 LOAD_CONST 0 (None)
6 LOAD_CONST 0 (None)
9 LOAD_CONST 0 (None)
12 BUILD_SLICE 3
15 BINARY_SUBSCR
16 PRINT_EXPR
17 LOAD_CONST 0 (None)
20 RETURN_VALUE
--
>Comment By: Nick Coghlan (ncoghlan)
Date: 2006-03-18 04:04
Message:
Logged In: YES
user_id=1038590
Applied 1452332 to SVN (generates an explicit None reference
for the step when the second colon is present but no
expressions is supplied for the step)
--
Comment By: Nick Coghlan (ncoghlan)
Date: 2006-03-17 23:45
Message:
Logged In: YES
user_id=1038590
Alternate patch that doesn't modify the AST posted as 1452332
--
Comment By: Grant Olson (logistix)
Date: 2006-03-10 10:22
Message:
Logged In: YES
user_id=699438
Patch 1446847 Posted.
--
Comment By: Grant Olson (logistix)
Date: 2006-03-06 09:33
Message:
Logged In: YES
user_id=699438
This only happens when you have implicit slice values.
x[1:2:3] works fine. I'm finishing up a patch and will post
to sf shortly.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441408&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448639 ] asyncore dispatcher.__getattr__() masks self._map
Bugs item #1448639, was opened at 2006-03-12 20:52
Message generated for change (Comment added) made by dwhite
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448639&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: Invalid
Priority: 5
Submitted By: Doug White (dwhite)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore dispatcher.__getattr__() masks self._map
Initial Comment:
The abstraction of socket_map in the asyncore module
in Python 2.4 forgets to allow accesses to the
internal attribute self._map in __getattr__(). This
causes any asyncore application to fail in
create_socket(), which pretty much renders asyncore
inoperative in Python 2.4.
This problem was introduced in rev 34469 as a commit
of Bug #758241.
Example backtrace, generated from an application that
uses Medusa servers that don't use the private map
function:
Traceback (most recent call last):
File "/usr/local/qos/qosserver/qos_server.py", line
1576, in ?
m = monitor.monitor_server ('127.0.0.1',
BasePort)
File "/usr/local/qos/qosserver/monitor.py", line
161, in __init__
self.create_socket (socket.AF_INET,
socket.SOCK_STREAM)
File "/usr/local/lib/python2.4/asyncore.py", line
261, in create_socket
self.add_channel()
File "/usr/local/lib/python2.4/asyncore.py", line
244, in add_channel
map = self._map
File "/usr/local/lib/python2.4/asyncore.py", line
366, in __getattr__
return getattr(self.socket, attr)
AttributeError: '_socketobject' object has no
attribute '_map'
__getattr__() should test if the attribute exists in
its own object before passing it on to the underlying
socket object.
--
>Comment By: Doug White (dwhite)
Date: 2006-03-17 10:20
Message:
Logged In: YES
user_id=105929
Ugh... this was my fault. I had code checkouts out of sync. So sorry :(
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-17 03:51
Message:
Logged In: YES
user_id=849994
It seems that zseil is right. Closing as Invalid.
--
Comment By: iga Seilnacht (zseil)
Date: 2006-03-17 03:37
Message:
Logged In: YES
user_id=1326842
This is a bug in your code, since you don't call the
base class's __init__() method, and as a consequence
the '_map' attribute really doesn't exist.
__getattr__() doesn't have to check for existance of
an attribute since it is called only when the normal
lookup mechanism fails. See the docs:
http://docs.python.org/ref/attribute-access.html
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448639&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-567972 ] Missing 4 socket object properties
Feature Requests item #567972, was opened at 2002-06-12 11:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&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: Graham Horler (grahamh)
>Assigned to: Georg Brandl (gbrandl)
Summary: Missing 4 socket object properties
Initial Comment:
The C socketmodule has a struct PySocketSockObject,
with family, type and proto members.
These would be terribly helpful to have access to in
Python, when implementing some generic socket helper
functions.
The "blocking" flag could also be made available, but
would require some extra coding.
(I'm using Python 2.1.3 under Linux 2.4.16, so I cannot
extend the socket class itself ((as in py2.2)), and don't
want to slow down sockets with a complete wrapper, as I
use them heavily.)
Thanks, Graham.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-17 19:17
Message:
Logged In: YES
user_id=849994
Committed as rev. 43126.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2005-08-24 20:05
Message:
Logged In: YES
user_id=1188172
Attaching new patch. Following changes:
- getfamily(), gettype(), getproto() functions of
_socketobject which map to
- family, type, proto members of socket._sock
- timeout member of socket._sock
- documentation update
- test suite update
Please review.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-08-24 15:24
Message:
Logged In: YES
user_id=21627
grahamh, I take it that your answer to the question "would
you like to implement a patch?", is "no".
I agree with parts of the review: these things should be
added to the _socketobject. Also, socket objects have one
more attribute, sock_timeout, which might be worth exposing.
I also wonder what style of API should be used. All other
state access goes through get-methods(), which all start
with get except for fileno(). Adding properties would
introduce another API style, so -1.
As for blocking: this sounds like a different feature
request, as this is not a member of struct
PySocketSockObject. So I would close this request as soon as
the three attributes are implemented; if you then still want
the getblocking() method, you should write another feature
request.
In addition, this patch lacks documentation and test suite
changes.
Unassigning myself, as I won't take any further action for
the moment.
--
Comment By: Graham Horler (grahamh)
Date: 2005-07-20 14:47
Message:
Logged In: YES
user_id=543663
The patch applies, compiles, runs OK for me (thanks).
However it does not add access to the blocking flag.
Under Linux I can go:
fcntl.fcntl(fd, fcntl.F_GETFL) & os.O_NDELAY != 0
But this is not portable, and is probably repeating code.
Also the 3 added members are not available from an instance
of the _socketobject wrapper, you have to go
mysock._sock.family.
(The _socketobject wrapper in socket.py is a little bizarre
IMVHO.)
Perhaps they could be added using instances of property().
--
Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-17 13:49
Message:
Logged In: YES
user_id=1188172
Attaching a patch which implements the three members of
_socket.socket.
Please review.
--
Comment By: Martin v. Löwis (loewis)
Date: 2002-06-15 13:21
Message:
Logged In: YES
user_id=21627
Sounds good. Would you like to produce a patch implementing
this feature?
--
Comment By: Graham Horler (grahamh)
Date: 2002-06-12 12:00
Message:
Logged In: YES
user_id=543663
Oh yes, the repr of a socket object includes the missing info,
so to get hold of the family, I go:
int(repr(sock).split(' ')[3].split('=')[1][:-1])
Similar for type and protocol, not nice!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1151968 ] (XMLRPC) multitude of sockets ending up in TIME_WAIT
Bugs item #1151968, was opened at 2005-02-25 18:00
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1151968&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: Platform-specific
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Jonas Widén (jonsv322)
Assigned to: Nobody/Anonymous (nobody)
Summary: (XMLRPC) multitude of sockets ending up in TIME_WAIT
Initial Comment:
A problem with a multitude of sockets ending up in
TIME_WAIT when stressing a system with XML-RPC calls.
This can cause a Windows network to missbehave.
A solution on Windows platform is to set the sockopt
NOLINGER with parameters (1, 0) for the socket before
the socket is closed. This vill cause that Windows will
release the socket direct without going into TIME_WAIT.
The solution in code:
In [EMAIL PROTECTED]:
NOLINGER = struct.pack('HH', 1, 0) # Release the
resource back to the system if socket closed
In [EMAIL PROTECTED]:
self.sock.setsockopt(socket.SOL_SOCKET,
socket.SO_LINGER, NOLINGER)
self.sock.close() # close it manually... there may be
other refs
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-17 19:29
Message:
Logged In: YES
user_id=849994
Seems like Not a Bug.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-02-25 20:53
Message:
Logged In: YES
user_id=21627
Why do you want to avoid the TIME_WAIT state, and why do you
think it is a Python bug that it doesn't? See
http://www.developerweb.net/sock-faq/detail.php?id=13
where Richard Stevens himself explains that SO_LINGER should
*not* be used.
It might be that SO_REUSEADDR is sufficient, see
http://www.developerweb.net/sock-faq/detail.php?id=44
If you want xmlrpclib to use different socket options, you
should subclass httplib.HTTP to redefine either connect() or
close(), and you should subclass xmlrpclib.Transport to use
your subclassed transport.
--
Comment By: Jonas Widén (jonsv322)
Date: 2005-02-25 20:13
Message:
Logged In: YES
user_id=352221
Read section, SO_LINGER at following address:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/wspsetsockopt_2.asp
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1151968&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-739029 ] Constructor for counting things
Feature Requests item #739029, was opened at 2003-05-17 02:22
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=739029&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: Rejected
Priority: 5
Submitted By: David Albert Torpey (dtorp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Constructor for counting things
Initial Comment:
Counting things is very common. May I suggest an
alternate dictionary constructor that works like this:
class BetterDictionary(dict):
def bag(classobject, sequence):
"Fast way to count things"
b = classobject()
for k in sequence:
b[k] = b.get(k,0) + 1
return b
bag = classmethod(bag)
print BetterDictionary.bag("jack and jill went up a
hill ...")
A C implementation could do this very fast.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-17 19:33
Message:
Logged In: YES
user_id=849994
I think this a reasonable use case for defaultdict:
d = defaultdict(int)
for k in seq:
d[k] += 1
--
Comment By: Michael Chermside (mcherm)
Date: 2005-12-28 17:19
Message:
Logged In: YES
user_id=99874
I think I prefer birkenfeld's approach: create a well-tuned
implementation for the collections module rather than adding
yet one MORE use case to the already overburdened (yet very
powerful) dict.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2005-07-17 14:07
Message:
Logged In: YES
user_id=1188172
Perhaps "bag" is a good addition to the "collections" module.
--
Comment By: David Albert Torpey (dtorp)
Date: 2003-08-26 18:07
Message:
Logged In: YES
user_id=681258
Smalltalk has a collection class called Bag that fills the same
role. It is a frequently used class.
The current way of doing things is too slow. Disassembly
shows that the whole process involves loading a constant for
1, loading a constant for zero, loading the local variable 'b',
performing an attribute lookup for 'get', loading the local
variable 'k', calling 'get', running the summation, re-loading
both 'b' and 'k' and doing a subscript store. Along the way,
there are two dictionary lookups for the same key. All of
that is just the inner loop and is wrapped in for-loop with all
of its overhead. Instead, the whole thing could be done in
one step at C speed: b.bag(itemlist).
--
Comment By: Brett Cannon (bcannon)
Date: 2003-08-12 06:12
Message:
Logged In: YES
user_id=357491
I don't know if it is *that* common. Besides, as your code shows,
it isn't that complex. It strikes me as a little too specific to be
made a built-in dict constructor.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=739029&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-872175 ] README build instructions for fpectl
Bugs item #872175, was opened at 2004-01-07 06:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872175&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: Feature Request >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Steve Chaplin (stevech) Assigned to: Nobody/Anonymous (nobody) Summary: README build instructions for fpectl Initial Comment: configure.in supports the option '--with-fpectl' However, the "Configuration options and variables" section in the Python-2.3.3/README file mentions many options, but does not mention --with-fpectl I think the README should contain a few lines saying what the default setting is and why you may want to switch it on or off. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-17 19:49 Message: Logged In: YES user_id=849994 Added the question about fpectl to PEP 356, this will be resolved before 2.5. -- Comment By: Michael Hudson (mwh) Date: 2006-02-20 12:59 Message: Logged In: YES user_id=6656 Waaa, the correct thing to is to remove the --with-fpectl from configure! I've been meaning to post to python-dev for a while now proposing the ripping out of this code. It's just not useful any more. At any rate, I am actively opposed to advertising its existence more widely. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-20 10:24 Message: Logged In: YES user_id=1188172 Added a note in rev. 42512. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872175&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug
Bugs item #1115379, was opened at 2005-02-03 13:11 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&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: 7 Submitted By: Christoph Zwerschke (cito) >Assigned to: Neal Norwitz (nnorwitz) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. -- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 21:37 Message: Logged In: YES user_id=849994 This even aborts the interpreter in 2.5 HEAD with a failing assertion. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-28 05:48 Message: Logged In: YES user_id=21627 If you load the files manually, why is it that you want to decode them to Unicode before compile()ing them? Couldn't you just pass the bytes you read from the file to compile()? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-28 04:29 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-28 04:20 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Martin v. Löwis (loewis) Date: 2005-02-10 00:37 Message: Logged In: YES user_id=21627 There is a bug somewhere, certainly. However, I believe it is in PEP 263, which should point out that unicode strings in compile are only legal if they do *not* contain an encoding declaration, as such strings are implicitly encoded as UTF-8. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1452697 ] broken string on mbcs
Bugs item #1452697, was opened at 2006-03-18 05:07
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=1452697&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: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ocean-city (ocean-city)
Assigned to: M.-A. Lemburg (lemburg)
Summary: broken string on mbcs
Initial Comment:
Hello. I noticed unicode conversion from mbcs was
sometimes broken. This happened when I used
codecs.open("foo", "r", "mbcs") as iterator.
# It's OK if I use "shift_jis" or "cp932".
I'll attach the script and text file to reproduce the
problem. I'm using Win2000SP4(Japanese).
Thank you.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452697&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1443504 ] locale.getpreferredencoding() dies when setlocale fails
Bugs item #1443504, was opened at 2006-03-05 14:50 Message generated for change (Comment added) made by jminka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443504&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: 3 Submitted By: Catherine Devlin (catherinedevlin) Assigned to: Nobody/Anonymous (nobody) Summary: locale.getpreferredencoding() dies when setlocale fails Initial Comment: I'm on Ubuntu 5.10, with Python 2.4.2-0ubuntu2, and when I open a terminal window and run python, I get >>> import locale >>> locale.getpreferredencoding() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 417, in getpreferredencoding setlocale(LC_CTYPE, "") File "/usr/lib/python2.4/locale.py", line 381, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting However, if I su - root - or even su right back to my own account (catherine) ! - then everything works. This is of concern (to me, anyway) because this error crashes bzr. I chose "Esperanto" as my language when setting up Ubuntu. (No, I wasn't trying to be funny - I really do speak Esperanto!) That may be why I found the problem, but I don't think this is simply a problem with flawed Esperanto support in Ubuntu - because the routine works after su is used, and because locale.nl_langinfo(CODESET) works fine (please read on). Anyway, within locale.getpreferredencoding(), line 417 - setlocale(LC_CTYPE, "") - seems to be the problem... >>> locale.setlocale(locale.LC_CTYPE) 'C' >>> locale.setlocale(locale.LC_CTYPE, "") Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 381, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting >>> locale.setlocale(locale.LC_CTYPE, None) 'C' This makes me wonder if setlocale(LC_TYPE, "") is really so very necessary. It seems to be there to prep for the nl_langinfo call, but it doesn't actually seem strictly necessary for that call to work. >>> locale.nl_langinfo(locale.CODESET) 'ANSI_X3.4-1968' ... I get that result whether before or after calling setlocale, and I get it under any account (including root, where setlocale does not raise an exception). Thus, as far as I can tell, it isn't really necessary to set setlocale(LC_CTYPE, "") or die trying, and accepting the nl_langinfo result without a successful setlocale(LC_CTYPE, "") would be preferable to raising an unhandled exception. I suggest that setlocale(LC_TYPE, "") be enclosed in a try block. try: setlocale(LC_CTYPE, "") except: None Since I don't really understand what it's doing in the first place, I don't know if this is really a good patch. Thanks! -- Comment By: jminka (jminka) Date: 2006-03-17 21:27 Message: Logged In: YES user_id=1116964 I've got the same problem with bzr on Gentoo. If LANG or LC_ALL consists '/', then bzr has the problem (e.g. en_US is ok, en_US/ISO8859-1 is wrong). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443504&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451466 ] reading very large files
Bugs item #1451466, was opened at 2006-03-16 09:21
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&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: christen (richardchristen)
Assigned to: Nobody/Anonymous (nobody)
Summary: reading very large files
Initial Comment:
I work on the human genome
I extracted words from chromosomes using a suffix tree
(C compiled for 64 done on a SUN with 300 Go RAM, since
my suffix tree requires 150 Go RAM for chromosome 1,
the largest one)
this gave some >5 Go files, for example with 163763326
lines for chr 4, the one presently analyzed.
Using python 2.4.2 on a windows 32-computer (1.5 Go
RAM), reading this file line by line either
for li in file:
do something
or
while li!='':
li=file.readline()
I got problems seemingly around the 4 Go boundary
(after reading the problematic first line), for some
lines (not all), the li returned the correct content
but with the first word of the next line also within li
(see below)
As a result a simple
file1=open('1')
file2=open('2','w')
li=file1.readline()
while li!='':
file2.write(li)
li=file1.readline()
produced a second file of only
163754385 lines
problem lines were "seemingly random", i.e. not in a
row, with the last line being OK.
The same code on the same file but on my OSX
64-dualcore machine went fine, despite the use of
default Python 2.2.3 and "file Python" showing it is a
Mach-0 executable ppc, i.e. a 32 bit app.
Everything was run from the command line.
the first file looks like that
...
TCAGCCACAGCAGAAAGTGA:\t33240 551212 751185
TCAGCCACAGCAGAAAGTGC:\t131324047
TCAGCCACAGCACTGTGTTA:\t61641912
the second file contains lines like these :
TCAGCCACAGCAGAAAGTGC:\t131324047TCAGCCACAGCAGAAGAAGA:
which is 'first line'+'1rst word of next line'
PS1 : no problem to read the big file with UEdit on the
windows machine. Therefore the OS itself is not the
problem (also I transfered the bigfile from the Windows
to the Mac, if the file had had problems, it would have
been corrupted on the Mac)
PS2 : I tried python 2.3.5 on windows with the same
problem.
PS3: If needed, I can run the same test on a similar
file but for chromosome 8 which is slightly below the 4
Go limit (3.99).
PS4: I think I remember having done a similar parsing
on a Linux Athlon 64 monoCPU a month ago, with no trouble.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-17 16:35
Message:
Logged In: YES
user_id=341410
Sounds like an issue with file objects on certain platforms
not being able to handle offsets of 2**32 or larger. I
personally have read and written files > 4gb on the windows
platform, but I seem to recall having issues on 32 bit linux
some time in the past.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&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-1449496 ] Python should use 3GB Address Space on Windows
Feature Requests item #1449496, was opened at 2006-03-14 03:04 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&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: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: Python should use 3GB Address Space on Windows Initial Comment: Python runs fine using a 3GB address space on 32bit Windows. To take advantage of this feature, Python should be linked using the /LARGEADDRESSAWARE flag of the linker. For details, please refer to: http://msdn.microsoft.com/library/en- us/memory/base/4gt_ram_tuning.asp As most Windows users just use pre-built executables, this would be a worthwhile change. Best regards, Martin Gfeller -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-03-17 16:38 Message: Logged In: YES user_id=341410 Microsoft claims that the switch does not negatively affect users on systems without large amounts of memory, and the extra gig of memory on platforms which could use it would be nice. Can you offer a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451466 ] reading very large files
Bugs item #1451466, was opened at 2006-03-16 12:21
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&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: christen (richardchristen)
Assigned to: Nobody/Anonymous (nobody)
Summary: reading very large files
Initial Comment:
I work on the human genome
I extracted words from chromosomes using a suffix tree
(C compiled for 64 done on a SUN with 300 Go RAM, since
my suffix tree requires 150 Go RAM for chromosome 1,
the largest one)
this gave some >5 Go files, for example with 163763326
lines for chr 4, the one presently analyzed.
Using python 2.4.2 on a windows 32-computer (1.5 Go
RAM), reading this file line by line either
for li in file:
do something
or
while li!='':
li=file.readline()
I got problems seemingly around the 4 Go boundary
(after reading the problematic first line), for some
lines (not all), the li returned the correct content
but with the first word of the next line also within li
(see below)
As a result a simple
file1=open('1')
file2=open('2','w')
li=file1.readline()
while li!='':
file2.write(li)
li=file1.readline()
produced a second file of only
163754385 lines
problem lines were "seemingly random", i.e. not in a
row, with the last line being OK.
The same code on the same file but on my OSX
64-dualcore machine went fine, despite the use of
default Python 2.2.3 and "file Python" showing it is a
Mach-0 executable ppc, i.e. a 32 bit app.
Everything was run from the command line.
the first file looks like that
...
TCAGCCACAGCAGAAAGTGA:\t33240 551212 751185
TCAGCCACAGCAGAAAGTGC:\t131324047
TCAGCCACAGCACTGTGTTA:\t61641912
the second file contains lines like these :
TCAGCCACAGCAGAAAGTGC:\t131324047TCAGCCACAGCAGAAGAAGA:
which is 'first line'+'1rst word of next line'
PS1 : no problem to read the big file with UEdit on the
windows machine. Therefore the OS itself is not the
problem (also I transfered the bigfile from the Windows
to the Mac, if the file had had problems, it would have
been corrupted on the Mac)
PS2 : I tried python 2.3.5 on windows with the same
problem.
PS3: If needed, I can run the same test on a similar
file but for chromosome 8 which is slightly below the 4
Go limit (3.99).
PS4: I think I remember having done a similar parsing
on a Linux Athlon 64 monoCPU a month ago, with no trouble.
--
>Comment By: Tim Peters (tim_one)
Date: 2006-03-17 21:33
Message:
Logged In: YES
user_id=31435
"windows 32-computer" is too vague. Which operating system
(Win95, Win98, WinME, NT, Win2K, WinXP), and which
filesystem (FAT, FAT32, NTFS)?
Are you sure this is a text file? If it's a binary file,
then all sorts of bad things can happen opening it in text
mode (which your sample code does).
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-17 19:35
Message:
Logged In: YES
user_id=341410
Sounds like an issue with file objects on certain platforms
not being able to handle offsets of 2**32 or larger. I
personally have read and written files > 4gb on the windows
platform, but I seem to recall having issues on 32 bit linux
some time in the past.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&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-1449496 ] Python should use 3GB Address Space on Windows
Feature Requests item #1449496, was opened at 2006-03-14 06:04 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&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: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: Python should use 3GB Address Space on Windows Initial Comment: Python runs fine using a 3GB address space on 32bit Windows. To take advantage of this feature, Python should be linked using the /LARGEADDRESSAWARE flag of the linker. For details, please refer to: http://msdn.microsoft.com/library/en- us/memory/base/4gt_ram_tuning.asp As most Windows users just use pre-built executables, this would be a worthwhile change. Best regards, Martin Gfeller -- >Comment By: Tim Peters (tim_one) Date: 2006-03-17 21:38 Message: Logged In: YES user_id=31435 MS also says "However, the file cache, paged pool, and non-paged pool are smaller, which can adversely affect applications with heavy networking or I/O", so the rationale for making this change is clear as mud. That is, it's not a pure win: some apps win at the expense of others. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-03-17 19:38 Message: Logged In: YES user_id=341410 Microsoft claims that the switch does not negatively affect users on systems without large amounts of memory, and the extra gig of memory on platforms which could use it would be nice. Can you offer a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&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
Bugs item #1448042, was opened at 2006-03-11 17:49
Message generated for change (Comment added) made by tjreedy
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: Open
Resolution: None
Priority: 5
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: Terry J. Reedy (tjreedy)
Date: 2006-03-17 22:21
Message:
Logged In: YES
user_id=593130
To me, this falls under the category of 'don't do that'.
http://docs.python.org/ref/id-classes.html
2.3.2 Reserved classes of identifiers
__*__
System-defined names. These names are defined by the
interpreter and its implementation ...
To me, this means to use them in the manner specified or
you get what you get.
http://docs.python.org/ref/types.html#l2h-120
defines the internal usage of '__dict__'. There is, as
far as I know, no specified usage for rebinding '__dict__'.
So unless someone has a better idea that won't slow down
proper usage, I would close this as 'invalid' or 'wont
fix'.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1452697 ] broken string on mbcs
Bugs item #1452697, was opened at 2006-03-18 05:07
Message generated for change (Comment added) made by ocean-city
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452697&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: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ocean-city (ocean-city)
Assigned to: M.-A. Lemburg (lemburg)
Summary: broken string on mbcs
Initial Comment:
Hello. I noticed unicode conversion from mbcs was
sometimes broken. This happened when I used
codecs.open("foo", "r", "mbcs") as iterator.
# It's OK if I use "shift_jis" or "cp932".
I'll attach the script and text file to reproduce the
problem. I'm using Win2000SP4(Japanese).
Thank you.
--
>Comment By: ocean-city (ocean-city)
Date: 2006-03-18 13:17
Message:
Logged In: YES
user_id=1200846
Probably this patch will fix the problem. (for release24-maint)
Cause: MultiByteToWideChar returns non zero value for
incomplete multibyte character. (ex: if buffer terminates
with leading byte, MultiByteToWideChar returns 1 (not 0) for
it. It should return 0, otherwise result will be broken.
Solution: Set flag MB_ERR_INVALID_CHARS to avoid incorrect
handling of trailing incomplete multibyte part. If error
occurs, removes the trailing byte and tries again.
Caution: I have not tested this so intensibly.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452697&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1452697 ] broken string on mbcs
Bugs item #1452697, was opened at 2006-03-18 05:07
Message generated for change (Settings changed) made by ocean-city
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452697&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: Unicode
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 7
Submitted By: ocean-city (ocean-city)
Assigned to: M.-A. Lemburg (lemburg)
Summary: broken string on mbcs
Initial Comment:
Hello. I noticed unicode conversion from mbcs was
sometimes broken. This happened when I used
codecs.open("foo", "r", "mbcs") as iterator.
# It's OK if I use "shift_jis" or "cp932".
I'll attach the script and text file to reproduce the
problem. I'm using Win2000SP4(Japanese).
Thank you.
--
Comment By: ocean-city (ocean-city)
Date: 2006-03-18 13:17
Message:
Logged In: YES
user_id=1200846
Probably this patch will fix the problem. (for release24-maint)
Cause: MultiByteToWideChar returns non zero value for
incomplete multibyte character. (ex: if buffer terminates
with leading byte, MultiByteToWideChar returns 1 (not 0) for
it. It should return 0, otherwise result will be broken.
Solution: Set flag MB_ERR_INVALID_CHARS to avoid incorrect
handling of trailing incomplete multibyte part. If error
occurs, removes the trailing byte and tries again.
Caution: I have not tested this so intensibly.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1452697&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451466 ] reading very large files
Bugs item #1451466, was opened at 2006-03-16 18:21
Message generated for change (Comment added) made by richardchristen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&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: christen (richardchristen)
Assigned to: Nobody/Anonymous (nobody)
Summary: reading very large files
Initial Comment:
I work on the human genome
I extracted words from chromosomes using a suffix tree
(C compiled for 64 done on a SUN with 300 Go RAM, since
my suffix tree requires 150 Go RAM for chromosome 1,
the largest one)
this gave some >5 Go files, for example with 163763326
lines for chr 4, the one presently analyzed.
Using python 2.4.2 on a windows 32-computer (1.5 Go
RAM), reading this file line by line either
for li in file:
do something
or
while li!='':
li=file.readline()
I got problems seemingly around the 4 Go boundary
(after reading the problematic first line), for some
lines (not all), the li returned the correct content
but with the first word of the next line also within li
(see below)
As a result a simple
file1=open('1')
file2=open('2','w')
li=file1.readline()
while li!='':
file2.write(li)
li=file1.readline()
produced a second file of only
163754385 lines
problem lines were "seemingly random", i.e. not in a
row, with the last line being OK.
The same code on the same file but on my OSX
64-dualcore machine went fine, despite the use of
default Python 2.2.3 and "file Python" showing it is a
Mach-0 executable ppc, i.e. a 32 bit app.
Everything was run from the command line.
the first file looks like that
...
TCAGCCACAGCAGAAAGTGA:\t33240 551212 751185
TCAGCCACAGCAGAAAGTGC:\t131324047
TCAGCCACAGCACTGTGTTA:\t61641912
the second file contains lines like these :
TCAGCCACAGCAGAAAGTGC:\t131324047TCAGCCACAGCAGAAGAAGA:
which is 'first line'+'1rst word of next line'
PS1 : no problem to read the big file with UEdit on the
windows machine. Therefore the OS itself is not the
problem (also I transfered the bigfile from the Windows
to the Mac, if the file had had problems, it would have
been corrupted on the Mac)
PS2 : I tried python 2.3.5 on windows with the same
problem.
PS3: If needed, I can run the same test on a similar
file but for chromosome 8 which is slightly below the 4
Go limit (3.99).
PS4: I think I remember having done a similar parsing
on a Linux Athlon 64 monoCPU a month ago, with no trouble.
--
>Comment By: christen (richardchristen)
Date: 2006-03-18 08:29
Message:
Logged In: YES
user_id=1477618
In reply to previous comment
Are you sure this is a text file?
Yes I made it myself.
Besides I transfered it from the UX machine to the windows
one by ftp with change of the end of line character to the
window's kind. I checked with type myfile, that the control
character was indeed changed. Also, I mentioned that I
manually checked with Uedit, both in ASCII and HEX modes for
the akward lines.
"windows 32-computer" is too vague."
I agree, I should have been more specific:
System: Microsoft Windows 2000 Professionnel
Version 5.0.2195 Service Pack 4 version 2195
Mother card : ASUSTek
System Model A7N8X-E
BIOS Phoenix AwardBIOS v6-00PG
Memory 1.5Go
Swap 2.4 Go
File System NTFS
Best Regards
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-18 03:33
Message:
Logged In: YES
user_id=31435
"windows 32-computer" is too vague. Which operating system
(Win95, Win98, WinME, NT, Win2K, WinXP), and which
filesystem (FAT, FAT32, NTFS)?
Are you sure this is a text file? If it's a binary file,
then all sorts of bad things can happen opening it in text
mode (which your sample code does).
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-03-18 01:35
Message:
Logged In: YES
user_id=341410
Sounds like an issue with file objects on certain platforms
not being able to handle offsets of 2**32 or larger. I
personally have read and written files > 4gb on the windows
platform, but I seem to recall having issues on 32 bit linux
some time in the past.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451466&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
