Fredrik Lundh writes: > > > and in Python, any decent extension writer should write > > > code that works with arbitrary file objects, right? "if it > > > cannot deal with StringIO objects, it's broken"... > > > > I disagree. Given that a lot of people use Python as a glue language > > for interfacing with legacy codes, it is unacceptable for extensions > > to be forced to use some sort of funky non-standard I/O abstraction. > > oh, you're right, of course. should have added that extra smiley > to that last line. cut and paste from this mail if necessary: ;-) > Good. You had me worried there for a second :-). > > yup. I suspect some legacy code may have a hard time running > under CE et al. but of course, with a little macro trickery, no- > thing stops you from recompiling such code so it uses Python's > new "abstract file... okay, okay, I'll stop now ;-) Macro trickery? Oh yes, we could use that too... (one can never have too much macro trickery if you ask me :-) Cheers, Dave
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4