Re: [Python-Dev] Simplify the file-like-object interface
On 9/6/05, Antoine Pitrou [EMAIL PROTECTED] wrote: One could use class decorators. For example if you want to define the method foo() in a file-like class, you could use code like: I like the sound of this. Suppose there were a function textstream() that decorated a file-like object (supporting read() and write()), so as to add all of __iter__(), next(), readline(), readlines(), and writeline() that it did not already implement. Then you could wrap any file-like object easily to give it convenient text-handling: mytextsocketstream = textstream(mysocketstream) for line in mytextsocketstream: print line Another area where I think this approach can help is with the text/binary file distinction. file() could always open files as binary, and there could be a convenience function textfile(name, mode) which would simply return textstream(file(name, mode)). This would remove the need for a or b in the mode parameter, and make it easier to keep text- and binary-file access separate in one's mind: tf = textfile(log.txt, w) tf.writelines(loglist) bf = file(img.jpg, r) process_image_file(bf) Finally, I think this could nicely tie into the print statement/function/method debate, as the print() method could be defined by the textstream() wrapper, allowing any text stream to support the convenient print() behaviour, but not requiring it for binary streams, for which such a function makes little sense anyway. And then textstream() could be used (in the sys module, preferably) to ensure that sys.stdout and sys.stderr both support print(). So you'd have the builtin: # Actual signature depending on which variant proposal is taken up def print(*args, **kwargs): sys.stdout.print(*args, **kwargs) And using print() could be a simple as: print(Hello, World) sys.stdout.print(This is normal output) sys.stderr.print(This is an error message) I have a vague idea that a wrapper like this (or another similar wrapper) could provide for convenient, transparent handling of Unicode text files also, but I don't know Unicode well enough to be certain. Andrew. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify the file-like-object interface
On 9/13/05, Andrew Durdin [EMAIL PROTECTED] wrote: On 9/6/05, Antoine Pitrou [EMAIL PROTECTED] wrote: One could use class decorators. For example if you want to define the method foo() in a file-like class, you could use code like: I like the sound of this. Suppose there were a function textstream() that decorated a file-like object (supporting read() and write()), so as to add all of __iter__(), next(), readline(), readlines(), and writeline() that it did not already implement. Then you could wrap any file-like object easily to give it convenient text-handling: Yes, this isn't perl and text, although still important, is not worth its wait in gold these days. And, have you even tried to weigh digital content to begin with? Not much there anyway. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify the file-like-object interface
Andrew Durdin writes: Another area where I think this approach can help is with the text/binary file distinction. file() could always open files as binary, and there could be a convenience function textfile(name, mode) which would simply return textstream(file(name, mode)). This would remove the need for a or b in the mode parameter, and make it easier to keep text- and binary-file access separate in one's mind: I think you are suffering from the (rather common) misconception that all files are binary, and the definition of text file is a binary file which should be interpreted as containing characters in some encoding. In unix, the above is true. One of the fundamental decisions in Unix was to treat all files (and lots of other vaguely file-like things) as undiferentiated streams of bytes. But this is NOT true on many other operating systems. It is not, for example, true on Windows. Many operating systems make a distinction between two basic types of files... text files which are line-oriented and contain text, and binary files which contain streams of bytes. This distinction is supported by the basic file operations in the C library. To open a text file in binary mode is technically an error (although in many OSs you'll get away with it). -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify the file-like-object interface
On 9/13/05, Michael Chermside [EMAIL PROTECTED] wrote: In unix, the above is true. One of the fundamental decisions in Unix was to treat all files (and lots of other vaguely file-like things) as undiferentiated streams of bytes. But this is NOT true on many other operating systems. It is not, for example, true on Windows. nitpick Actually, on Windows, it *is* true. At the OS API level, all files are streams of bytes (it's not as uniform as Unix - many things that Unix forces into a file-like mould don't look exactly like OS-level files on Windows, consoles and sockets being particular examples). However, at the C library level, text files are special insofar as the C stdio routines handle CRLF issues and the like differently. The problem is twofold: (1) that Python works with the C runtime, so stdio behaviour gets involved, and (2) on Windows, the familiar Unix/C conventions of \n for newline don't work without translation - so if you write text to a binary file, your output doesn't conform to the *conventions* used by other applications (notably notepad - it's surprising how many Windows programs actually work fine with LF-delimited lines in text files...) /nitpick Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify the file-like-object interface
This [text/binary] distinction is supported by the basic file operations in the C library. To open a text file in binary mode is technically an error (although in many OSs you'll get away with it). It's one of those technical errors that really isn't an error (from Python). On the other hand, opening a file in text mode will cause real data damage to binary files on Windows. Let some platform-specific library for that platform preserve it, if it cares to. I see no point in keeping this distinction in Python, even for those platforms bone-headed enough to preserve it. And the default certainly shouldn't be to the mode which loses data. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify the file-like-object interface (Replacement for print in Python 3.0)
On 9/6/05, Steven Bethard [EMAIL PROTECTED] wrote: I'd also prefer something along the lines of Fredrik's suggestion, but I don't write enough C code to understand Paul's last point. Could someone briefly explain why mixins wouldn't work in C code? I had in mind it would be complicated and messy, and probably no easier than just implementing all of the extra methods by hand rather than it's impossible. Sorry for being unclear. I haven't written many C extensions, either, so I may be misremembering. Also, the biggest extension I wrote, which does implement a file-like object, was written when Python 1.4/1.5 was current, and (still) uses the C API from then. (BTW, that's a great tribute to the backward-compatibility that Python provides!) Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Simplify the file-like-object interface (Replacement for print in Python 3.0)
Fredrik Lundh wrote: (you completely missed the point -- today's print mechanism works on *any* object that implements a write method, no just file objects. saying that oh, all you need is to add a method or here's a nice mixin doesn't give you a print replacement) While we're on the subject, in Py3k I'd like to see readline(), readlines(), etc. removed from file objects and made builtin functions instead. It should only be necessary to implement read() and write() to get a file-like object having equal status with all others. Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify the file-like-object interface (Replacement for print in Python 3.0)
Greg Ewing wrote: (you completely missed the point -- today's print mechanism works on *any* object that implements a write method, no just file objects. saying that oh, all you need is to add a method or here's a nice mixin doesn't give you a print replacement) While we're on the subject, in Py3k I'd like to see readline(), readlines(), etc. removed from file objects and made builtin functions instead. It should only be necessary to implement read() and write() to get a file-like object having equal status with all others. maybe some variation of http://www.python.org/peps/pep-0246.html combined with default adapters could come in handy here ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify the file-like-object interface (Replacement for print in Python 3.0)
On 9/6/05, Fredrik Lundh [EMAIL PROTECTED] wrote: Greg Ewing wrote: While we're on the subject, in Py3k I'd like to see readline(), readlines(), etc. removed from file objects and made builtin functions instead. It should only be necessary to implement read() and write() to get a file-like object having equal status with all others. maybe some variation of http://www.python.org/peps/pep-0246.html combined with default adapters could come in handy here ? That sounds like a good idea. I'm certainly getting concerned about the proliferation of methods that people should add to file-like objects, where read/write are the only fundamental ones needed. I can't see mixins working, as too many file-like objects are written in C... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify the file-like-object interface (Replacement for print in Python 3.0)
Fredrik Lundh wrote: maybe some variation of http://www.python.org/peps/pep-0246.html combined with default adapters could come in handy here ? I really hope we can get by with something much less heavyweight than that. I'm far from convinced that something like PEP 246 proposes is necessary or desirable. Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify the file-like-object interface
That sounds like a good idea. I'm certainly getting concerned about the proliferation of methods that people should add to file-like objects, where read/write are the only fundamental ones needed. I can't see mixins working, as too many file-like objects are written in C... One could use class decorators. For example if you want to define the method foo() in a file-like class, you could use code like: def FooExtender(cls): class wrapper(cls): pass try: # Don't do anything if foo already defined wrapper.foo except AttributeError: def foo(self): Automatically generated foo method. self.write(foo\n) wrapper.foo = foo return wrapper MyFileClass = FooExtender(MyCFileClass) This is for classes, but the construct can be adapted to work on objects instead. The advantage of using a decorator-like function is that you can do some complex processing in the function (you could for example automatically define __ne__ if only __eq__ is defined, and conversely). And it could probably plug, as an useful convenience or even an automatic mechanism, into a more sophisticated adaptor system. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify the file-like-object interface (Replacement for print in Python 3.0)
[Greg Ewing] While we're on the subject, in Py3k I'd like to see readline(), readlines(), etc. removed from file objects and made builtin functions instead. It should only be necessary to implement read() and write() to get a file-like object having equal status with all others. [Fredrik Lundh] maybe some variation of http://www.python.org/peps/pep-0246.html combined with default adapters could come in handy here ? [Paul Moore] That sounds like a good idea. I'm certainly getting concerned about the proliferation of methods that people should add to file-like objects, where read/write are the only fundamental ones needed. I can't see mixins working, as too many file-like objects are written in C... I'd also prefer something along the lines of Fredrik's suggestion, but I don't write enough C code to understand Paul's last point. Could someone briefly explain why mixins wouldn't work in C code? I scanned the Python/C API Reference Manual, but all I could find was that, for tp_base only single inheritance is supported; multiple inheritance require dynamically creating a type object by calling the metatype.[1] [1] http://docs.python.org/api/type-structs.html#l2h-983 STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify the file-like-object interface (Replacement for print in Python 3.0)
Steven Bethard wrote: Could someone briefly explain why mixins wouldn't work in C code? Depends on what you mean by work in C code. It's only possible for a type object to inherit C struct members from one base class, since the struct has to be an extension of the base C struct. Dynamic attributes and methods can be inherited from multiple base classes, however, if you're willing to write the necessary C code to create the type object dynamically, as would happen if it were being defined with Python code. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
