Re: file reading by record separator (not line by line)
Steve Howell wrote: > > > I think itertools.groupby() is usually the key > batteries-included component in elegant solutions to > this problem, but I wonder if the Python community > couldn't help a lot of newbies (or insufficiently > caffeinated non-newbies) by any of the following: > Well, I'm not a newbie, and I always make sure to be thoroughly caffeinated before sitting down for coding. But I think the itertools example in the parent post shows a problem with that package: unless you have intimate knowledge of the package, it is not clear what the code does when reading it. In other words, it is not intuitive. Perhaps a dedicated "block-read" module that wraps any read()-able object would be better. At least it would immediately be clear what the code means. from blockread import BlockReader b = BlockReader(f, boundary='>') for block in b: # whatever -- Regards, Tijs -- http://mail.python.org/mailman/listinfo/python-list
Re: Roundup, smtplib, TLS and MS Exchange
carlistixx wrote: > [EMAIL PROTECTED] tracker]$ roundup-server -p 8081 > roundup=/home/foobar/roundup/tracker > Roundup server started on :8081 > send: 'STARTTLS\r\n' > reply: '503 5.5.2 Send hello first\r\n' > reply: retcode (503); Msg: 5.5.2 Send hello first I think this must be an issue with roundup, issuing commands in the wrong order. The correct order should (according to the rfc and the python docs) be: * ehlo() * starttls() * ehlo() * login() ... -- Regards, Tijs -- http://mail.python.org/mailman/listinfo/python-list
Re: subexpressions
Steve Howell wrote: > FWIW there's the possibility that even without a > subexpression syntax, some Python implementations > would detect the duplication of x*x and optimize that > for you. It would have to know that x*x had no side > effects, which I think is a safe assumption even in a > dynamic language like Python. No, x may be an object that has the __mul__ special method, and it may have side effects. -- Regards, Tijs -- http://mail.python.org/mailman/listinfo/python-list
Re: file reading by record separator (not line by line)
Steve Howell wrote:
>>
>> from blockread import BlockReader
>>
>> b = BlockReader(f, boundary='>')
>> for block in b:
>> # whatever
>>
>
> Yep, I like this idea. You might have a few
> variations:
>
Yes, or a single one that takes a wide range of construction possibilities,
like strings, lambdas or regexes in various keyword parameters.
BlockReader(f, start='>')
BlockReader(f, start=re.compile('>|<'), end='---')
BlockReader(f, start=lambda x: x.startswith('>'))
Maybe make variations for character-based readers and line-based readers.
--
Regards,
Tijs
--
http://mail.python.org/mailman/listinfo/python-list
Re: file reading by record separator (not line by line)
Steve Howell wrote: > Do you have any free time on your hands? Nope. I think Python is a programmer's language, not a whack-something-together script language for text processing (although it is used that way). Any decent programmer has no need of this construct, since the time to lookup how to use it is larger than the time to implement the specialized version for the task at hand. -- Regards, Tijs -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Pop Quiz
[EMAIL PROTECTED] wrote: > 1. Do you like Python? Yes > > 2. Do you think Python is good? Yes > > 3. Do you think Python is real good? No. If it were real good, it would have type inference and (based on that) compile-time type checking and optimized native-code compilation. Of course, type inference is hard to combine with operator overloading and dynamic classes/objects, but duh, if it were real, real good... > > 4. What is your favorite version of Python? The one that comes with Debian stable. > > 5. Because of Python, do you think it will be easier to take over the > world? If so, when? If not, when? Yes. In 2015. > > 7. How many Z80 assembly language programmers does it take to equal > one Python guru? Trick question. A *real* Python guru would be fluent in Z80 assembly as well. > > Essay: "C++ is better than C", agree or disagree? (four word maximum) Agree. Readable interface-based callbacks. (Is that 4 or 5 words?) > > Bonus: A rabbi walks into a bar while nursing a baby goat. He is > closely followed by a priest, and a Perl hacker. Explain. try: pass -- Regards, Tijs -- http://mail.python.org/mailman/listinfo/python-list
Re: How to print this character u'\u20ac' to DOS terminal
??? wrote:
> But the string contained the u'\u20ac' is get from remote host. Is
> there any method to decode it to the local 'mbcs'?
remote_string = u'\u20ac'
try:
local_string = remote_string.encode('mbcs')
except:
# no mbcs equivalent available
print "encoding error"
else:
# local_string is now an 8-bit string
print "result:", local_string
# if console is not mbcs, you should see incorrect result
assert result == '\x80'
Mbcs is windows-only so I couldn't test this.
If your application handles text, it may be easier to just leave everything
in Unicode and encode to utf-8 for storage?
Regards,
Tijs
--
http://mail.python.org/mailman/listinfo/python-list
Re: Scope - import and globals
HMS Surprise wrote: > > In the file snippet below the value for the global hostName is > determined at runtime. Functions imported from the parent baseClass > file such as logon also need access to this variable but cannot see it > the with the implementation I have attempted here. Use a class variable: class baseClass: hostName = None # undefined yet def someFunc(self): assert self.hostName is not None, "hostname not set yet" ... # use hostName here class temp(baseClass): def runTest(self): baseClass.hostName = getHostName() ... or a global variable: baseClass.py: hostName = None class baseClass: def someFunc(self): assert hostName is not None testme.py: import baseClass class temp(baseClass.baseClass): baseClass.hostName = getHostName() although neither solution strikes me as very elegant. I would normally pass the hostname to the constructor of baseClass or use a separate 'settings' module. Global variables are per-module. Use the "global" keyword when assigning a global variable in the 'current' module. Global variables of other modules are properties of the module, use .. > > Also, functions in this file and in the imported parent class need > PyHttpTestCase. Does there need to be an import statement in both > files? Yes. Don't worry, the work is done only once. Regards, Tijs -- http://mail.python.org/mailman/listinfo/python-list
Re: xmlrpclib hangs execution
Arno Stienen wrote:
> Arno Stienen wrote:
>> Perhaps I should be a bit more specific. When using this code to connect
>> to a remote XML-RPC server (C++, xmlrpc++0.7 library):
>>
>>import xmlrpclib
>>server = xmlrpclib.Server("http://10.10.101.62:29500";)
>>print server.Connection_Request("roberto")
>>
>> the Python command line 'hangs' until I kill the server. Then, the
>> correct output is suddenly displayed:
>>
>>{'state': 0, 'id_session': '2Z3EUSLJFA13', 'port': 29501,
>>'str': 'Connection accepted. Session attached.'}
>>
>> Yet a slightly simpler call works flawlessly:
>>
>>import xmlrpclib
>>server = xmlrpclib.Server("http://10.10.101.62:29500";)
>>print server.Info_RT('Master')
>>
>>{'state': 0, 'str': 'Info_RT'}
>>
After having a quick look at your files, I conclude that the problem is in a
combination of two problems:
1. Your server is crap. It answers an HTTP/1.0 request by an HTTP/1.1
response without specifying any Connection header and without closing the
connection. Normally, a simple client that is not HTTP/1.1-aware expects
the connection to close. HTTP/1.1 leaves the connection open by default.
2. The Python implementation of xmlrpc is not very robust. It just waits for
the connection to close. A well-written client (like your Java client)
would detect the presence of a Content-Length header and use that.
The other request is OK because the server closes the connection after
having sent the response. Why the difference? Don't know, but it is
something server-side.
Try to force the server to send HTTP/1.0 responses, or turn off keep-alive,
or something like that. Otherwise, adapt xmlrpclib.py to robustly handle
1.1 responses.
--
Regards,
Tijs
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to print this character u'\u20ac' to DOS terminal
人言落日是天涯，望极天涯不见家 wrote: > Yes, it works, thank you. > But I doubt this way may not work on linux. Maybe I should write some > additional code for supporting both windows and linux OS. Depends on what you want to do. Printing to a DOS terminal is hard in Linux :-) If you write server code, best to keep all text in unicode. -- Regards, Tijs -- http://mail.python.org/mailman/listinfo/python-list
Re: How can an Exception pass over an "except" clause ?
Nebur wrote: > I'm using the contract.py library, running Python 2.4.4. > > Now I'm confronted with the following exception backtrace: > (...) > File "/usr/lib/python2.4/site-packages/contract.py", line 1265, in > _check_preconditions > p = f.__assert_pre > AttributeError: 'function' object has no attribute '__assert_pre' > > For my surprise, I found that the code of contract.py around line 1265 > looks like: > > 1264: try: > 1265: p = f.__assert_pre > 1266: except AttributeError: > 1267: pass > > I'd expect line 1267 to "swallow" the AttributeError siliently. But > the application stops with the above backtrace. > Someone familiar enough with the Python innards ? How can one manage > that an "except" seems to be ignored ? > > Ruben The 'raise' in line 1271 re-raises the last error instead of the exception in whose block it is called. This: try: raise KeyError except: try: raise IndexError except: pass raise raises IndexError, not KeyError. -- Regards, Tijs -- http://mail.python.org/mailman/listinfo/python-list
Re: Anyone else has seen "forrtl: error (200) ..."
Alexander Eisenhuth wrote: > Hello, > > Ctrl+C is not passed to the interpreter (i guess it) while I'm executing a > script. Instead i get: > forrtl: error (200): program aborting due to control-C event > I don't know what forrtl is, but I think it is hijacking your SIGINT signal handler. Python installs an OS-level signal handler that raises the KeyboardInterrupt in the main thread. If a library installs its own handler, Python won't catch it. -- Regards, Tijs -- http://mail.python.org/mailman/listinfo/python-list
Re: c[:]()
Warren Stringer wrote: >>>>c[:]() # i wanna > TypeError: 'tupple' object is not callable > c[:] equals c (in expressions), so c[:]() is equivalent to c() >>>>c[:][0] # huh? > a c[:][0] is c[0] is a >>>> [i() for i in c] # too long and ...huh? > a > b > [None,None] > #-- > [None, None] is the result of the operation. for i in c: i() If that is too long, reconsider what you are doing. -- Regards, Tijs -- http://mail.python.org/mailman/listinfo/python-list
Re: non standard path characters
Robin Becker wrote: > A kind user reports having problems running the reportlab tests because > his path has non-ascii characters in it eg > > .\Mes documents\Mes Téléchargements\Firefox\... > > somewhere in the tests we look at the path and then try and convert to > utf8 for display in pdf. > > Is there a standard way to do these path string conversions? > > Paths appear to come from all sorts of places and given the increasing use > of zip file packaging it doesn't seem appropriate to rely on the current > platform as a single choice for the default encoding. Zip files contain a bit flag for the character encoding (cp430 or utf-8), see the ZipInfo object in module zipfile and the link (on that page) to the file format description. But I think some zip programs just put the path in the zipfile, encoded in the local code page, in which case you have no way of knowing. -- Regards, Tijs -- http://mail.python.org/mailman/listinfo/python-list
Re: file reading by record separator (not line by line)
aspineux wrote:
>
> something like
>
> name=None
> lines=[]
> for line in open('yourfilename.txt'):
> if line.startwith('>'):
> if name!=None:
> print 'Here is the record', name
> print lines
> print
> name=line.stripr('\r')
> lines=[]
> else:
> lines.append(line.stripr('\n'))
>
That would miss the last chunk.
--
Regards,
Tijs
--
http://mail.python.org/mailman/listinfo/python-list
Re: file reading by record separator (not line by line)
Lee Sander wrote: > I wanted to also say that this file is really huge, so I cannot > just do a read() and then split on ">" to get a record > thanks > lee Below is the easy solution. To get even better performance, or if '<' is not always at the start of the line, you would have to implement the buffering that is done by readline() yourself (see _fileobject in socket.py in the standard lib for example). def chunkreader(f): name = None lines = [] while True: line = f.readline() if not line: break if line[0] == '>': if name is not None: yield name, lines name = line[1:].rstrip() lines = [] else: lines.append(line) if name is not None: yield name, lines if __name__ == '__main__': from StringIO import StringIO s = \ """> name1 line1 line2 line3 > name2 line 4 line 5 line 6""" f = StringIO(s) for name, lines in chunkreader(f): print '***', name print ''.join(lines) $ python test.py *** name1 line1 line2 line3 *** name2 line 4 line 5 line 6 -- Regards, Tijs -- http://mail.python.org/mailman/listinfo/python-list
