"Schollnick, Benjamin" wrote:
> > Should a file being read be required to have a single line termination
> > type, or could they be mixed and matched? The prototype code allows mix
> > and match, but I'm not married to that idea. If it requires a single
> > terminator, then some performance could be gained by checking the
> > terminator type when opening the file, and using the existing native
> > text file code when it is a native file.
>
> I'm not aware of any type of text file, that supports switching line
> deliminators
> inside of the same file....
I agree that it wouldn't be generated on purpose, but I have seen files
that got edited on different systems get mixed up...that doesn't mean we
have to support it though.
> That would be a interesting idea... I'm not sure how much of a performance
> hit
> we'd see, but that would certainly solve a PC / MAC issue I'm having....
> (Any chance we could see the code?)
I enclosed a Python version of the code with the message. If you didn't
get it, lwt me know and I'll send you one directly.
> Regarding your points on changing the default text file type....
> * Don't have the Universal be the default text file type, instead
> offer it
> as a different class, or as a open('garbage.txt', "r",
> universal), or some
> other optional switch.
Exactly. I proposed adding a "t" flag to open(). I guess I didn't write
that as clearly as I might have liked.
> * Just the opposite, the programmer explicitly tells Python not to
> support
> universal...
Not good, old code coule break
> * Have the programmer subclass the File Type?
too much work
> * Add a global directive?
maybe... but it wouldn't allow mix and match
> * Specifically import a "universal" which will depreciate the
> "standard" text file
> IO routines...
That's an option too.. but would again not allow mix and match. Also.
part of the point of thios is to have Python use it when it imports
code, so it would have to be pretty built in.
> * Actually I think this sounds like the easiest and fastest
> way to deal with it.
> This way, you could add a extension library to speed
> it up, or whatever...
true, and that's exactly what I do with my prototype, which I am using
in a bunch of my code already. Maybe some day I'll get around to writing
it in C, alhough I'd love someone else to do it, I am a pretty lame C
programmer.
-Chris
--
Christopher Barker,
Ph.D.
ChrisHBarker@home.net --- --- ---
http://members.home.net/barkerlohmann ---@@ -----@@ -----@@
------@@@ ------@@@ ------@@@
Oil Spill Modeling ------ @ ------ @ ------ @
Water Resources Engineering ------- --------- --------
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------
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