[ python-Bugs-1446690 ] bug with xmlrpclib
Bugs item #1446690, was opened at 2006-03-09 19:22 Message generated for change (Settings changed) made by varun_bhansaly 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: Open Resolution: None >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 -- 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-1448325 ] re search infinite loop
Bugs item #1448325, was opened at 2006-03-12 09:46
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=1448325&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: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Don Allen (donallen)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re search infinite loop
Initial Comment:
Given the attached test.csv file, the following program
loops forever (can't even ^c):
import re
orig = open('test.csv')
file_contents = orig.read()
orig.close()
find_line = re.compile(r'^(".*")?(,(".*")?)*\n')
search_result = find_line.search(file_contents)
print search_result.span()
The corresponding tcl program works correctly:
set orig [open test.csv r]
set file_contents [read $orig]
close $orig
regexp -indices {^(".*")?(,(".*")?)*\n} $file_contents
\ indices
puts "Indices were $indices"
Both tests were run on a TP G41 running Gentoo Linux.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448325&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448325 ] re search infinite loop
Bugs item #1448325, was opened at 2006-03-12 09:46
Message generated for change (Comment added) made by donallen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448325&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: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Don Allen (donallen)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: re search infinite loop
Initial Comment:
Given the attached test.csv file, the following program
loops forever (can't even ^c):
import re
orig = open('test.csv')
file_contents = orig.read()
orig.close()
find_line = re.compile(r'^(".*")?(,(".*")?)*\n')
search_result = find_line.search(file_contents)
print search_result.span()
The corresponding tcl program works correctly:
set orig [open test.csv r]
set file_contents [read $orig]
close $orig
regexp -indices {^(".*")?(,(".*")?)*\n} $file_contents
\ indices
puts "Indices were $indices"
Both tests were run on a TP G41 running Gentoo Linux.
--
>Comment By: Don Allen (donallen)
Date: 2006-03-12 10:22
Message:
Logged In: YES
user_id=1474165
If you eliminate the \n at the end of the regular
expression, the python program works correctly (for this
example; I am trying to use regular expressions to parse the
.csv files generated by Microsoft Outlook, which contain
eols inside fields, so I'm trying to find the eols *not*
inside fields with this regexp, so I need the \n; I'll have
to go to Plan B, I suppose).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448325&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448490 ] Convertion error for latin1 characters with iso-2022-jp-2
Bugs item #1448490, was opened at 2006-03-12 16: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=1448490&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: Francois Duranleau (duranlef) Assigned to: Nobody/Anonymous (nobody) Summary: Convertion error for latin1 characters with iso-2022-jp-2 Initial Comment: It seems like there are some errors while reading a text file encoded with ISO-2022-JP-2 using the codecs module. In all my test cases, all latin1 characters with an accent (e.g. e acute) do not appear in the output string. However, if I convert the file manually using iconv, I get everything right. Here is a simple script that will illustrate the problem: ### import codecs import pygtk import gtk f = codecs.open( "test.iso-2022-jp-2" , "r" , \ "iso-2022-jp-2" ) s1 = f.readline().strip() f.close() f = open( "test.utf-8" , "r" ) s2 = f.readline().strip() pack = gtk.VBox() pack.pack_start( gtk.Label( s1 ) ) pack.pack_start( gtk.Label( s2 ) ) window = gtk.Window( gtk.WINDOW_TOPLEVEL ) window.add( pack ) window.show_all() def event_destroy( widget , event , data ) : gtk.main_quit() return 0 window.connect( "delete_event" , \ lambda w,e,d: False , None ) window.connect( "destroy" , event_destroy , None ) gtk.main() ### I put the file "test.iso-2022-jp-2" in attachment. To create the UTF-8 version of the file, I used the following shell command: iconv -f ISO-2022-JP-2 -t UTF-8 \ test.iso-2022-jp-2 > test.utf-8 When running this script, I would actually expect a window with two times the same label. However, the first one is missing the e acute. -- Francois -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448490&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 (Tracker Item Submitted) made by Item Submitter
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.
--
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-1448640 ] datetime.__init__ cannot be overridden
Bugs item #1448640, was opened at 2006-03-13 04: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=1448640&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: Martin Blais (blais) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.__init__ cannot be overridden Initial Comment: Hi The following code does not work properly: #!/usr/bin/env python """ Test overriding constructor of datetime classes. """ import sys, datetime class MyDate(datetime.date): def __init__( self, year, month, day ): print >> sys.stderr, 'lose data' d = MyDate(2006, 11, 29) print d class MyDate(datetime.date): def __new__( self, year, month, day ): print 'lose data' def __init__( self, year, month, day ): print 'lose data again' d = MyDate(2006, 11, 29) print d The output is: lose data 2006-11-29 lose data None The problem is that the initialization of the object is done in its time_new() method which is registered for __new__ rather than using an __init__ method. This prevent one from overriding the date/datetime/time constructors. cheers, -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448640&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
