[Chicago] What to do about File Like Object methods I don't need...

Carl Karsten carl at personnelware.com
Sun Dec 21 19:50:35 CET 2008


Steven Githens wrote:
> Hi all,
> 
> I'm curious what the correct Pythonic way to deal with the following 
> issue is (since I still spend more time in Java than Python unfortunately)
> 
> I am implementing 2 versions of the File-Like Object signatures ( 
> http://www.python.org/doc/2.5.2/lib/bltin-file-objects.html ).  One will 
> be mapping to our projects archaic content repository interface, and 
> another one will be adapting to a generic JSR-170 repository 
> (consequently, these are both being implemented using Jython 2.5 ).
> 
> My question is, when I see methods in the docs like these two:
> 
> fileno(      )
>    Return the integer ``file descriptor'' that is used by the underlying 
> implementation to request I/O operations from the operating system. This 
> can be useful for other, lower level interfaces that use file 
> descriptors, such as the fcntl module or os.read() and friends. Note: 
> File-like objects which do not have a real file descriptor should not 
> provide this method!
> 
> isatty(     )
>    Return True if the file is connected to a tty(-like) device, else 
> False. Note: If a file-like object is not associated with a real file, 
> this method should not be implemented.
> 
> 
> 
> Should I...
> 
> - really just flat out not implement them

my vote.  The docs kinda hint at that, in a round about way.  :)

> - or should I stub them in and throw a standard Python not implemented 
> sort of exception

The only time that code will get run is when something calls it, and it should 
never call it, right?  so don't write the code, and if the "never should happen" 
case happens, let the normal error happen.

> - or stub them in and just 'pass'
I will hunt you down and make you fix my apps.

If I write bad code, I want it to blow up close to where the badness is.  not 
1000's of bytes later which causes me to burn time looking somewhere else for 
the error, expanding the scope of my search until I finely hit the "call/pass" 
that should have blown up.

Carl K



More information about the Chicago mailing list