On 4/15/20 5:47 PM, dcwhat...@gmail.com 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. -- https://mail.python.org/mailman/listinfo/python-list