What variable type is returned from Open()?

dcwhatthe at gmail.com dcwhatthe at gmail.com
Thu Apr 16 12:20:16 EDT 2020


On Thursday, April 16, 2020 at 12:09:44 PM UTC-4, Souvik Dutta wrote:
> What are you making?
> 
> Souvik flutter dev
> 
> On Thu, Apr 16, 2020, 9:10 PM <dcwh> wrote:
> 
> > On Wednesday, April 15, 2020 at 9:46:30 PM UTC-4, Michael Torrie wrote:
> > > On 4/15/20 5:47 PM, dcwh wrote:
> > > > So in the case of Python, whenever the type information is available,
> > > > I want to make it explicit rather than inferred.  Whether the A.I. is
> > > > running a simulation of the software in an IDE, or analyzing them as
> > > > text documents, they should be able to glean as much as possible.
> > > > They should also be able to infer the type, via a Hungarian syntax
> > > > variation.
> > >
> > > Hungarian syntax is definitely an acquired taste, and better suited to
> > > statically-typed languages.
> > >
> > > In this specific case of dealing with open(), keep in mind that most
> > > things that work with files (including something like, for example,
> > > csvreader) only require a file-like object. That can be something that
> > > open() returns, or some other object that implements the semantics. This
> > > is important because anything that can work with files can also work
> > > with any other implementation, provided it speaks the same protocol.
> > > For example you could feed it a stream from a zip archive.  Or a network
> > > stream. Or something else of your own design.  No need for "interface"
> > > classes (although Zope does implement and use them for some reason), or
> > > a special class hierarchy.
> > >
> > > In my opinion, the first line of documentation should be decent
> > > docstrings that document the parameters and return values for functions.
> > > I can think of some cases when type hinting would be desired and
> > > recommended.  But storing the result of open() isn't one of them.
> >
> > Thanks DL Neil, Michael Torrie ; and especially Random832 & Souvik Dutta.
> > Although my coding style is still evolving, I'm already clear on how I
> > personally want to name variables, and the question of clarifying their
> > type.
> >
> > The Docstring of course is the first line of defense, but there's still
> > something missing that I haven't fully worked out yet, regarding the
> > purpose of analyzing the code by an artificial entity.
> >
> > Maybe a json or edn file with the same base filename as the source file,
> > which contains details about the intent of the module.
> >
> > Whatever ; it'll take time to brainstorm something.  Nevertheless, thanks
> > for answering the question that was actually asked, which was the type of
> > variable returned from an Open() statement.
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >

The current project is just a utility for checking connectivity, logging, and reporting any failures via email.  But the point of the thread applies to any project or module.

Regards,



More information about the Python-list mailing list