Re: What variable type is returned from Open()?

[Python]

dcwh...@gmail.com wrote:
> Hi,
>
>
> As much as possible, I make use of optional type hints. So if I know a function returns an integer, then I use
>
>
> this_number_i : int = GetThisNumber()
>
>
> But there's no 'file' type, so I'm not sure what to use as the type for the return value of an Open() function.
>
>
> config_file : file = open(config_file_s, "r")
>
>
> What type of variable should config_file (above) be declared as?

Python 3.7.0 (default, Oct 2 2018, 09:20:07)
[Clang 10.0.0 (clang-1000.11.45.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import _io
>>> _io.TextIOWrapper is type(open('/etc/hosts'))
True
>>> _io.BufferedReader is type(open('/etc/hosts','rb'))
True

[Souvik Dutta]

_io.TextIOWrapper

On Wed, 15 Apr, 2020, 7:30 pm , <dcwh...@gmail.com> wrote:

> Hi,
>
>
> As much as possible, I make use of optional type hints. So if I know a
> function returns an integer, then I use
>
>
> this_number_i : int = GetThisNumber()
>
>
> But there's no 'file' type, so I'm not sure what to use as the type for
> the return value of an Open() function.
>
>
> config_file : file = open(config_file_s, "r")
>
>
> What type of variable should config_file (above) be declared as?
>

> --
> https://mail.python.org/mailman/listinfo/python-list
>

[Chris Angelico]

On Thu, Apr 16, 2020 at 12:01 AM <dcwh...@gmail.com> wrote:
>
> Hi,
>
>
> As much as possible, I make use of optional type hints. So if I know a function returns an integer, then I use
>
>
> this_number_i : int = GetThisNumber()
>
>
> But there's no 'file' type, so I'm not sure what to use as the type for the return value of an Open() function.
>
>
> config_file : file = open(config_file_s, "r")
>
>
> What type of variable should config_file (above) be declared as?
>

It returns a file-like object. Instead of annotating, just let the
type hinting system figure it out - you initialized it with the result
of an open() call, so it should be able to figure that out.

Python is not C, you do not need to declare all your variable types.

If you actually need a way to represent "file-like object" (maybe as a
parameter to some other function), there are tools for that in the
typing module, but just DON'T annotate every variable. Bad idea, will
cause you a maintenance headache and won't help anything.

ChrisA

[Souvik Dutta]

Yes that is the type. You can try using a print(type(<your variable>)) to
verify that.

Souvik flutter dev

On Wed, Apr 15, 2020, 9:45 PM <dcwh...@gmail.com> wrote:

> So you're saying this is a type _io.TextIOWrapper? This type doesn't show
> up, on the hint listbox (I'm using Wing IDE). So if I type var_file : _io,
> it doesn't show anything.
>
> Maybe I don't understand what you're saying.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

[Random832]

On Wed, Apr 15, 2020, at 12:11, dcwh...@gmail.com wrote:
> So you're saying this is a type _io.TextIOWrapper? This type doesn't
> show up, on the hint listbox (I'm using Wing IDE). So if I type
> var_file : _io, it doesn't show anything.

While others have pointed out that you shouldn't need a type hint here at all since it can be inferred, the correct type hint to use would be typing.TextIO.

[DL Neil]

On 16/04/20 1:55 AM, dcwh...@gmail.com wrote:
> As much as possible, I make use of optional type hints. So if I know a function returns an integer, then I use
> this_number_i : int = GetThisNumber()
> But there's no 'file' type, so I'm not sure what to use as the type for the return value of an Open() function.
> config_file : file = open(config_file_s, "r")
> What type of variable should config_file (above) be declared as?

First point (at the risk of teaching you/Grandma how to suck eggs) is
that Python is a "dynamically-typed" language. Thus we may write:

a = "abc"

in one place, and:

a = 123

in another.

Python won't complain. However, such code is a recipe for confusing
people - if not yourself, more 'simple' colleagues, such as me; because
we get used to the idea of "a" as a string of characters, only to be
presented with a number/int. What???

Thus the 'virtue' of typed languages, and adding data-typing features
into one's code!


It is important to remember that the Python docs (see refs, below) refer
to data-typing as "Hints". Indeed Python itself pays little/no attention:

>>> i:int=6
>>> j:int="str"
>>> i
6
>>> j
'str'

Since when has the string of characters: "str" been an integer???

To make good use of typing hints requires a bolt-on checker such as
"mypy". Quoting, the release notes for Python 3.5:
<<<
While these annotations are available at run-time through the usual
__annotations__ attribute, no automatic type checking happens at
run-time. Instead, it is assumed that a separate off-line type checker
(e.g. mypy) will be used for on-demand source code analysis.
>>>

(most IDEs will offer a mechanism to automatically run this, along with
linters, test-runners, etc, every time a source-file is saved)


Coming from other languages, there is a tendency to see typing as at
least helpful, even when it's not 'required'. Similarly, some
languages/conventions encourage the use of prefixes or suffixes in
naming variables, to help one remember the data-type. These are habits
that are difficult to break - and indeed, it is arguable whether
breaking them entirely would make one a 'better programmer'! (IMHO)


Python prefers to be descriptive, and in making a variable's name
meaningful, to imply or to 'carry' well-rounded and sufficient
information. Choosing names is an under-rated skill, and difficult to
master. (again, IMHO)

Now, because you (as above) "know a function returns an integer", Python
does too! However, if you (so kindly) save me hours of work by offering
this function to me, what do I know about it? The answer is that I look
at the function's "signature".

If we totally eschew data-typing it might be:

def find_sentence_length( sentence ):
etc

We can guess the data-type of "sentence" and that of the value to be
returned, but (a) it's a "guess", (b) we have to invest extra effort,
and (c) we might guess wrong[ly]! (although such might/should be
included in the function's docstring!)

You (as I) probably prefer:

def find_sentence_length( sentence:str )->int:
etc

This is readily-understood to describe the taking 'in' of a string of
characters, and the subsequent return of an integer. No muss, no fuss!

Subsequently:

sentence_length = find_sentence_length( my_sentence )

tells both Python and me (and any typing checker), that sentence_length
is an integer.

That said, there is still room for misunderstanding. Guessing again?


Even with such a contrived and simplistic example, there is room for
confusion: is that "length" measured in characters, inches/millimeters,
pixels, or what?

So, typing (or strongly-typed languages) is/are not the
be-all-and-end-all, nor does it offer a 'silver bullet'!

Before anyone asks: when I use "sentence_lengthPX" it produces howls of
complaint from certain ('pythonic') colleagues - notice though, that its
purpose is clear!


My opinion/coding-habits may differ from others (surely (and sadly) it
is 'they' who differ from me!). For each class I like to 'define'
most/all of its data-attributes in the __init__(), and to add typing
information to those definitions - with additional supportive comment,
as appropriate. This is mostly a bid to carry-forward as much
information as possible from the design-docs. (also, if the class
contains 'state' information, it seems to make it easier to write and
generalise __str__() and any other 'general' routines across states. YMMV!)

NB I'm not arguing with @Chris - I wouldn't dare!

I don't see this as an extension of the class's signature - it won't be
read because it's not needed if we treat the class as a 'black box'.
Conversely, it *is* a useful reminder/initiation to my/someone else's
comprehension of the inner-workings of the class itself!


Another thought, relating to the (above) specific example of
"config_file : file = open(config_file_s, "r")", is that once-again, the
'pythonic' approach leads one into a different way of thinking (if we
let ourselves 'go with the flow').

The preferred method of dealing with files, (somewhat newer than
illustrations in many text-books) is to use a "Context Manager", eg

with open(config_file_s, "r") as configurations:
for configuration in configurations:
# bend it to your will

Note the absence of any try...except structure, which we would normally
use to ensure the file is (eventually) closed and garbage-collection
assured! These offer a powerful implementation (actually, a "protocol").

Thus, "configurations" is (still) a "file descriptor" (fd), but its
definition now appears on the right of the open() (ie the open
function-call), because it is part of a "with" (compound) statement.
Auto-magically, "configurations" will only exist within the "context" of
the "with"!

The "with" opens a code-block ("wraps" is the docs' terminology). The
code block/compound[ed] statements (presumably) contain everything
needed to operate on that file's content, eg read a config setting,
update the app's environment class/dict/constant, log the specification,
etc. Hence the terms "context" and "encapsulation".

The fd only exists (its "scope") 'within' and for the 'life' of this
block. If this code-block is kept short - as it should be (fitting on
one screen is a popular definition for max-"short") then you/I/we can
easily track "configurations" during its short, but very-necessary, life
- and being a 'bear of little brain', if/when I forget, the reminder is
still right there on-screen if I but lift mine eyes! So, using
data-typing seems of little benefit (although it is still possible!)

NB clearly this is an argument from cognitive psychology rather than
computer science!


To generalise that point: if one practices 'modular coding', "separation
of concerns", and related philosophies (in recognition of how
encapsulation helps cognition); then considerately-thoughtful
function/method signatures combined with (short) single-objective
code-modules, enable one to comprehend and remember (all?most) data-type
information, as part of understanding the context and purpose of each
unit of code. ("chunking")


Speaking personally, it took me a long time to get used to such ideas as
"dynamic typing" and to focus on what I gained (cf what I 'lost'). Some
might argue that I'm still adapting! However, the 'golden rule' (whether
considering programming languages or human languages!) is not to try to
bend/fold/spindle/mutilate one language, to make it look/sound like
another! It's always worth asking the meta-level question: why am I
wanting to (try to) do this, this way? Aka: is there a better way?


Web-Refs:
PEP 483 -- The Theory of Type Hints:
https://www.python.org/dev/peps/pep-0483/
PEP 484 -- Type Hints: https://www.python.org/dev/peps/pep-0484/
New in Python 3.5: https://docs.python.org/3/whatsnew/3.5.html
Typing: https://docs.python.org/3/library/typing.html?highlight=pep%20typing
Using "with":
https://docs.python.org/3/reference/compound_stmts.html?highlight=context%20manager#the-with-statement
Typing context managers:
https://docs.python.org/3/library/typing.html?highlight=context%20manager#typing.ContextManager
Using context managers:
https://jeffknupp.com/blog/2016/03/07/python-with-context-managers/
--
Regards =dn

[Chris Angelico]

On Thu, Apr 16, 2020 at 9:51 AM <dcwh...@gmail.com> wrote:
>
> On Wednesday, April 15, 2020 at 5:28:55 PM UTC-4, Random832 wrote:

> > On Wed, Apr 15, 2020, at 12:11, dcwhatthe wrote:
> > > So you're saying this is a type _io.TextIOWrapper? This type doesn't
> > > show up, on the hint listbox (I'm using Wing IDE). So if I type
> > > var_file : _io, it doesn't show anything.
> >
> > While others have pointed out that you shouldn't need a type hint here at all since it can be inferred, the correct type hint to use would be typing.TextIO.
>

> Hi Random832,
>
> I understand the advice, and don't want to get into a debate about it. But I decided years ago, before looking at Python relatively recently, that I want to put as much structural & semantic information in my the code as possible.
>
> The primary reason is artificial intelligence. When intelligent software is ready to take over programming, I want to leave it as much information as possible.
>

Uhhh..... okay. Let's start right here.

1) Intelligent software ALREADY writes our code for us. We call them
"optimizing compilers" and stuff like that. A person still has to tell
the software what sort of code to write, and the instructions that
specify the required goal are what constitute a high level programming
language.

2) If you really think that it's going to be one of those
Hollywood-style "computer becomes smart enough to program itself"
situations, why do you think it would care about your preexisting
code? It's able to write its own code anyway.

3) Even if it cares about your code, what would the type hints give
it? It's already capable of running the code without the type hints.

Type hints are a tool for YOU, the human. They're not any sort of
assistance to the computer. People periodically talk about using type
hints to improve performance, and it never works.

> 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.
>

Type hints can be explicitly wrong:
x:float = 1
x += 0.5

Type inference can't:
x = 1
x += 0.5

When the AI is running a simulation of your software - which, by the
way, you can already see happen with tools like pythontutor - it can
manage *just fine* with no type hints. In fact, the best thing to do
is ignore them and follow the well-defined semantics of the rest of
Python.

> Yeah, I know it's a minority opinion, and a little kooky.
>

A little misdirected, perhaps. It's like hearing those
"tick-tick-tick" things at pedestrian crossings and thinking that
they're there for the benefit of seeing eye dogs. :)

ChrisA

[Michael Torrie]

On 4/15/20 5:47 PM, dcwh...@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.

[dcwh...@gmail.com]

On Wednesday, April 15, 2020 at 9:46:30 PM UTC-4, Michael Torrie wrote:

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.

[Souvik Dutta]

What are you making?

Souvik flutter dev

> --
> https://mail.python.org/mailman/listinfo/python-list
>

[Richard Damon]

On 4/15/20 9:55 AM, dcwh...@gmail.com wrote:
> Hi,

>
>
> As much as possible, I make use of optional type hints. So if I know a function returns an integer, then I use
>
>
> this_number_i : int = GetThisNumber()
>
>
> But there's no 'file' type, so I'm not sure what to use as the type for the return value of an Open() function.
>
>
> config_file : file = open(config_file_s, "r")
>
>
> What type of variable should config_file (above) be declared as?
>

Running the simple test program in IDLE:


f = open("TestFile.txt", "w")
print (type(f))

I get the answer: <class '_io.TextIOWrapper'>

So that is the name of the type that is returned, at least for that
call. One key thing to note is that it begins with a _, so that type is
actually an implementation detail, subject to change. This isn't that
strange in Python as normally you don't really need to know the type of
an object, but what capabilities the object supports (most from its
type, but some operations can be just added to the object). This is
largely because Python is based on a concept call 'Duck-Typing', where
it is more important if the object quacks like a duck then if it
technically IS a duck. (And strangely, I believe you can have something
that technically is a duck, but doesn't quack like one, as well as
something totally unrelated to the duck type but quacks just like one).
Files are such an animal, 'fileness' is not based on type, but on
capability.

--
Richard Damon

[dcwh...@gmail.com]

On Thursday, April 16, 2020 at 12:09:44 PM UTC-4, Souvik Dutta wrote:
> What are you making?
>
> Souvik flutter dev
>

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,

[dcwh...@gmail.com]

On Thursday, April 16, 2020 at 12:12:23 PM UTC-4, Richard Damon wrote:

Ok, thanks.

[Chris Angelico]

On Fri, Apr 17, 2020 at 2:13 AM Richard Damon <Ric...@damon-family.org> wrote:
> I get the answer: <class '_io.TextIOWrapper'>
>
> So that is the name of the type that is returned, at least for that
> call. One key thing to note is that it begins with a _, so that type is
> actually an implementation detail, subject to change.

This is somewhat true; but when the *module* begins with an
underscore, it often means it's a C accelerator for a Python module.
You can often find the same thing exposed in a more visible way:

>>> import io
>>> io.TextIOWrapper
<class '_io.TextIOWrapper'>

And in that location, it is fully documented:

https://docs.python.org/3/library/io.html#io.TextIOWrapper

The fact that it comes from the accelerator *is* an internal
implementation detail, but the class itself is a public one.

That said, though: it is still very much incorrect to type hint in
this way. The correct type hint is a generic one:

https://docs.python.org/3/library/typing.html#typing.IO

And the correct way to encode this on a variable is to let type
inference figure it out. You'd use typing.IO or typing.TextIO to
annotate a function parameter, perhaps, but don't annotate your
variables at all.

ChrisA

[dcwh...@gmail.com]

On Thursday, April 16, 2020 at 2:37:42 PM UTC-4, Chris Angelico wrote:

I don't know how many times I have to say this, but I've already decided that the types of variables are going to be part of my code base. Same as every other language I've programmed in, whether statically or dynamically typed.

I don't care if it's 'incorrect' for most purposes. I'm doing it, for my specific purpose.

Thanks everyone else, for their assistance on this, and for actually listening to the point of the thread. I'm done with this one.

[Chris Angelico]

Oh! Okay then. Just annotate it as "int" - it's no more or less wrong
than any other annotation :) Problem solved!

ChrisA

[Souvik Dutta]

Then there is no point of type setting. Type setting is a personal
preferences and should be respected. Sometimes it saves the day. Sometimes
it becomes a headache. Python developers also know and thus have never
deprecated type setting.

On Fri, 17 Apr, 2020, 12:40 am Chris Angelico, <ros...@gmail.com> wrote:

> On Fri, Apr 17, 2020 at 5:06 AM <dcwh...@gmail.com> wrote:
> >

> Oh! Okay then. Just annotate it as "int" - it's no more or less wrong
> than any other annotation :) Problem solved!
>
> ChrisA

> --
> https://mail.python.org/mailman/listinfo/python-list
>

[dcwh...@gmail.com]

Yes,personal preference is definitely a factor and a bias, in these matters.

But aside from trying to make it easier for future A.I. to figure out what the heck we humans were doing, it also makes a difference in how the IDE interpets the code.

Maybe it isn't true for all IDE's or all languages. (I know SOMEONE will interject here, to argue for the sake of arguing). But when I worked with Groovy in Intellij about 5 years ago, there were times when the IDE was confused, during a debugging sessions. I don't remember the exact details, but that anomaly happened only with DEFed variables ; it didn't happen when the data type was specified.

[Rhodri James]

On 17/04/2020 17:18, dcwh...@gmail.com wrote:
> Maybe it isn't true for all IDE's or all languages. (I know SOMEONE
> will interject here, to argue for the sake of arguing). But when I
> worked with Groovy in Intellij about 5 years ago, there were times
> when the IDE was confused, during a debugging sessions. I don't
> remember the exact details, but that anomaly happened only with DEFed
> variables ; it didn't happen when the data type was specified.

This is a general problem for IDEs, and type information isn't always
helpful. The number of times I have had to add useless bits of code to
cast something to (uint8_t *) because I want to see the bytes and the
IDE will not give up on trying to interpret them for me.

And people wonder why I stick to gdb when at all possible :-)

--
Rhodri James *-* Kynesim Ltd

[dcwh...@gmail.com]

On Friday, April 17, 2020 at 2:11:17 PM UTC-4, Rhodri James wrote:

Never worked with it. Is it a debugger for compiled code, i.e. it steps through the executable while displaying the source? Or interpreted code?

[Rhodri James]

On 17/04/2020 22:27, dcwh...@gmail.com wrote:
> On Friday, April 17, 2020 at 2:11:17 PM UTC-4, Rhodri James wrote:
>> And people wonder why I stick to gdb when at all possible :-)

> Never worked with it. Is it a debugger for compiled code, i.e. it steps through the executable while displaying the source? Or interpreted code?

The GNU project debugger has been around for quite a few decades now.
It's a debugger for compiled code, covering about a dozen source
languages (I can't be bothered to count at this time of night). It is
ridiculously flexible, command-line driven, and most importantly it does
what you tell it to do.

[Souvik Dutta]

_io.TextIOWrapper

On Wed, 15 Apr, 2020, 7:30 pm , <dcwh...@gmail.com> wrote:

> Hi,
>
>
> As much as possible, I make use of optional type hints. So if I know a
> function returns an integer, then I use
>
>
> this_number_i : int = GetThisNumber()
>
>
> But there's no 'file' type, so I'm not sure what to use as the type for
> the return value of an Open() function.
>
>
> config_file : file = open(config_file_s, "r")
>
>
> What type of variable should config_file (above) be declared as?
>

> --
> https://mail.python.org/mailman/listinfo/python-list
>

[Chris Angelico]

On Thu, Apr 16, 2020 at 12:01 AM <dcwh...@gmail.com> wrote:
>
> Hi,
>
>
> As much as possible, I make use of optional type hints. So if I know a
function returns an integer, then I use
>
>
> this_number_i : int = GetThisNumber()
>
>
> But there's no 'file' type, so I'm not sure what to use as the type for the
return value of an Open() function.
>
>
> config_file : file = open(config_file_s, "r")
>
>
> What type of variable should config_file (above) be declared as?
>

[Chris Angelico]

> 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.
>

[dcwhatthe]

On Wednesday, April 15, 2020 at 5:28:55 PM UTC-4, Random832 wrote:
> On Wed, Apr 15, 2020, at 12:11, dcwhatthe wrote:
> > So you're saying this is a type _io.TextIOWrapper? This type doesn't
> > show up, on the hint listbox (I'm using Wing IDE). So if I type
> > var_file : _io, it doesn't show anything.
>
> While others have pointed out that you shouldn't need a type hint here at all
since it can be inferred, the correct type hint to use would be typing.TextIO.

Hi Random832,

I understand the advice, and don't want to get into a debate about it. But I
decided years ago, before looking at Python relatively recently, that I want to
put as much structural & semantic information in my the code as possible.

The primary reason is artificial intelligence. When intelligent software is
ready to take over programming, I want to leave it as much information as
possible.

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.

Yeah, I know it's a minority opinion, and a little kooky.

Thanks for the advice, I'll try typing.TextIO tomorrow.

[Michael Torrie]

On 4/15/20 5:47 PM, dcwh...@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.

[Random832]

[dcwhatthe]

On Wednesday, April 15, 2020 at 10:10:31 AM UTC-4, Souvik Dutta wrote:
> _io.TextIOWrapper
>

> On Wed, 15 Apr, 2020, 7:30 pm , <dcwhatthe> wrote:
>
> > Hi,
> >
> >
> > As much as possible, I make use of optional type hints. So if I know a
> > function returns an integer, then I use
> >
> >
> > this_number_i : int = GetThisNumber()
> >
> >
> > But there's no 'file' type, so I'm not sure what to use as the type for
> > the return value of an Open() function.
> >
> >
> > config_file : file = open(config_file_s, "r")
> >
> >
> > What type of variable should config_file (above) be declared as?
> >
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >

So you're saying this is a type _io.TextIOWrapper? This type doesn't show up,
on the hint listbox (I'm using Wing IDE). So if I type var_file : _io, it
doesn't show anything.

Maybe I don't understand what you're saying.

[dcwhatthe]

[Souvik Dutta]

Yes that is the type. You can try using a print(type(<your variable>)) to
verify that.

Souvik flutter dev

On Wed, Apr 15, 2020, 9:45 PM <dcwh...@gmail.com> wrote:

> On Wednesday, April 15, 2020 at 10:10:31 AM UTC-4, Souvik Dutta wrote:
> > _io.TextIOWrapper
> >
> > On Wed, 15 Apr, 2020, 7:30 pm , <dcwhatthe> wrote:
> >

> > > --
> > > https://mail.python.org/mailman/listinfo/python-list
> > >
>
> So you're saying this is a type _io.TextIOWrapper? This type doesn't show
> up, on the hint listbox (I'm using Wing IDE). So if I type var_file : _io,
> it doesn't show anything.
>
> Maybe I don't understand what you're saying.

> --
> https://mail.python.org/mailman/listinfo/python-list
>

[DL Neil]

On 16/04/20 1:55 AM, dcwh...@gmail.com wrote:
> As much as possible, I make use of optional type hints. So if I know a
function returns an integer, then I use
> this_number_i : int = GetThisNumber()
> But there's no 'file' type, so I'm not sure what to use as the type for the
return value of an Open() function.
> config_file : file = open(config_file_s, "r")
> What type of variable should config_file (above) be declared as?

First point (at the risk of teaching you/Grandma how to suck eggs) is that
Python is a "dynamically-typed" language. Thus we may write:

a = "abc"

in one place, and:

a = 123

in another.

Python won't complain. However, such code is a recipe for confusing people - if
not yourself, more 'simple' colleagues, such as me; because we get used to the
idea of "a" as a string of characters, only to be presented with a number/int.
What???

Thus the 'virtue' of typed languages, and adding data-typing features into
one's code!


It is important to remember that the Python docs (see refs, below) refer to
data-typing as "Hints". Indeed Python itself pays little/no attention:

>>> i:int=6
>>> j:int="str"
>>> i
6
>>> j
'str'

Since when has the string of characters: "str" been an integer???

To make good use of typing hints requires a bolt-on checker such as "mypy".
Quoting, the release notes for Python 3.5:
<<<
While these annotations are available at run-time through the usual
__annotations__ attribute, no automatic type checking happens at run-time.
Instead, it is assumed that a separate off-line type checker (e.g. mypy) will
be used for on-demand source code analysis.
>>>

(most IDEs will offer a mechanism to automatically run this, along with
linters, test-runners, etc, every time a source-file is saved)


Coming from other languages, there is a tendency to see typing as at least
helpful, even when it's not 'required'. Similarly, some languages/conventions
encourage the use of prefixes or suffixes in naming variables, to help one
remember the data-type. These are habits that are difficult to break - and
indeed, it is arguable whether breaking them entirely would make one a 'better
programmer'! (IMHO)


Python prefers to be descriptive, and in making a variable's name meaningful,
to imply or to 'carry' well-rounded and sufficient information. Choosing names
is an under-rated skill, and difficult to master. (again, IMHO)

Now, because you (as above) "know a function returns an integer", Python does
too! However, if you (so kindly) save me hours of work by offering this
function to me, what do I know about it? The answer is that I look at the
function's "signature".

If we totally eschew data-typing it might be:

def find_sentence_length( sentence ):
etc

We can guess the data-type of "sentence" and that of the value to be returned,
but (a) it's a "guess", (b) we have to invest extra effort, and (c) we might
guess wrong[ly]! (although such might/should be included in the function's
docstring!)

You (as I) probably prefer:

def find_sentence_length( sentence:str )->int:
etc

This is readily-understood to describe the taking 'in' of a string of
characters, and the subsequent return of an integer. No muss, no fuss!

Subsequently:

sentence_length = find_sentence_length( my_sentence )

tells both Python and me (and any typing checker), that sentence_length is an
integer.

That said, there is still room for misunderstanding. Guessing again?


Even with such a contrived and simplistic example, there is room for confusion:
is that "length" measured in characters, inches/millimeters, pixels, or what?

So, typing (or strongly-typed languages) is/are not the be-all-and-end-all, nor
does it offer a 'silver bullet'!

Before anyone asks: when I use "sentence_lengthPX" it produces howls of
complaint from certain ('pythonic') colleagues - notice though, that its
purpose is clear!


My opinion/coding-habits may differ from others (surely (and sadly) it is
'they' who differ from me!). For each class I like to 'define' most/all of its
data-attributes in the __init__(), and to add typing information to those
definitions - with additional supportive comment, as appropriate. This is
mostly a bid to carry-forward as much information as possible from the
design-docs. (also, if the class contains 'state' information, it seems to make
it easier to write and generalise __str__() and any other 'general' routines
across states. YMMV!)

NB I'm not arguing with @Chris - I wouldn't dare!

I don't see this as an extension of the class's signature - it won't be read
because it's not needed if we treat the class as a 'black box'. Conversely, it
*is* a useful reminder/initiation to my/someone else's comprehension of the
inner-workings of the class itself!


Another thought, relating to the (above) specific example of "config_file :
file = open(config_file_s, "r")", is that once-again, the
'pythonic' approach leads one into a different way of thinking (if we
let ourselves 'go with the flow').

The preferred method of dealing with files, (somewhat newer than illustrations
in many text-books) is to use a "Context Manager", eg

with open(config_file_s, "r") as configurations:
for configuration in configurations:
# bend it to your will

Note the absence of any try...except structure, which we would normally use to
ensure the file is (eventually) closed and garbage-collection assured! These
offer a powerful implementation (actually, a "protocol").

Thus, "configurations" is (still) a "file descriptor" (fd), but its definition
now appears on the right of the open() (ie the open function-call), because it
is part of a "with" (compound) statement. Auto-magically, "configurations" will
only exist within the "context" of the "with"!

The "with" opens a code-block ("wraps" is the docs' terminology). The code
block/compound[ed] statements (presumably) contain everything needed to operate
on that file's content, eg read a config setting, update the app's environment
class/dict/constant, log the specification, etc. Hence the terms "context" and
"encapsulation".

The fd only exists (its "scope") 'within' and for the 'life' of this block. If
this code-block is kept short - as it should be (fitting on one screen is a
popular definition for max-"short") then you/I/we can easily track
"configurations" during its short, but very-necessary, life
- and being a 'bear of little brain', if/when I forget, the reminder is
still right there on-screen if I but lift mine eyes! So, using data-typing
seems of little benefit (although it is still possible!)

NB clearly this is an argument from cognitive psychology rather than computer
science!


To generalise that point: if one practices 'modular coding', "separation of
concerns", and related philosophies (in recognition of how encapsulation helps
cognition); then considerately-thoughtful function/method signatures combined
with (short) single-objective code-modules, enable one to comprehend and
remember (all?most) data-type information, as part of understanding the context
and purpose of each unit of code. ("chunking")


Speaking personally, it took me a long time to get used to such ideas as
"dynamic typing" and to focus on what I gained (cf what I 'lost'). Some might
argue that I'm still adapting! However, the 'golden rule' (whether considering
programming languages or human languages!) is not to try to
bend/fold/spindle/mutilate one language, to make it look/sound like another!
It's always worth asking the meta-level question: why am I wanting to (try to)
do this, this way? Aka: is there a better way?


Web-Refs:
PEP 483 -- The Theory of Type Hints:
https://www.python.org/dev/peps/pep-0483/
PEP 484 -- Type Hints: https://www.python.org/dev/peps/pep-0484/
New in Python 3.5: https://docs.python.org/3/whatsnew/3.5.html Typing:
https://docs.python.org/3/library/typing.html?highlight=pep%20typing Using
"with":
https://docs.python.org/3/reference/compound_stmts.html?highlight=context%20man
ager#the-with-statement
Typing context managers:
https://docs.python.org/3/library/typing.html?highlight=context%20manager#typin
g.ContextManager
Using context managers:
https://jeffknupp.com/blog/2016/03/07/python-with-context-managers/
--
Regards =dn

[dcwhatthe]

On Wednesday, April 15, 2020 at 1:09:26 PM UTC-4, Souvik Dutta wrote:
> Yes that is the type. You can try using a print(type(<your variable>)) to
> verify that.
>
> Souvik flutter dev
>

> On Wed, Apr 15, 2020, 9:45 PM <dcwhatthe> wrote:
>
> > On Wednesday, April 15, 2020 at 10:10:31 AM UTC-4, Souvik Dutta wrote:
> > > _io.TextIOWrapper
> > >
> > > On Wed, 15 Apr, 2020, 7:30 pm , <dcwhatthe> wrote:
> > >
> > > > Hi,
> > > >
> > > >
> > > > As much as possible, I make use of optional type hints. So if I know a
> > > > function returns an integer, then I use
> > > >
> > > >
> > > > this_number_i : int = GetThisNumber()
> > > >
> > > >
> > > > But there's no 'file' type, so I'm not sure what to use as the type for
> > > > the return value of an Open() function.
> > > >
> > > >
> > > > config_file : file = open(config_file_s, "r")
> > > >
> > > >
> > > > What type of variable should config_file (above) be declared as?
> > > >
> > > > --
> > > > https://mail.python.org/mailman/listinfo/python-list
> > > >
> >
> > So you're saying this is a type _io.TextIOWrapper? This type doesn't show
> > up, on the hint listbox (I'm using Wing IDE). So if I type var_file : _io,
> > it doesn't show anything.
> >
> > Maybe I don't understand what you're saying.
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >

Ok, thanks. It's not showing up in the variable type picklist, so I'll just
type it in manually, and see what happens, thanks.

[Python]

Python 3.7.0 (default, Oct 2 2018, 09:20:07) [Clang 10.0.0
(clang-1000.11.45.2)] on darwin Type "help", "copyright", "credits" or
"license" for more information.
>>> import _io
>>> _io.TextIOWrapper is type(open('/etc/hosts'))
True
>>> _io.BufferedReader is type(open('/etc/hosts','rb'))
True

[DL Neil]

I am going to interject here - and because there is arguing!

1 the above description seems to suggest that the coder's objectives are
now to be split: firstly to make Python understand his/her instruction,
and secondly to ensure that the IDE knows what's going-on.

Does the IDE serve you, or do you serve the tool?
- collaboration notwithstanding
- similarly, without considering UX (users what users?), etc!


2 AI's creative processes may initially, in a macro sense, be modeled on
human cognition; but when it comes to operation, their methodologies are
quite different. Why would a computer, programming a(nother) computer,
use a language/tool developed for human-computer communication?


3 The core-point seems to be, that without increased detail in the
Python code, an IDE or AI will have difficulty understanding (my/our)
human-intent. This is a feature/failing* of all "communication" (a
component of "transmission" and/or "noise").

For example, please review the original post. Can you show me where it
even hints that a response should consider anything other than *human*
understanding? (ie your own)

* 'trickery' aside, how many students/trainees have you heard utter
phrases such as, "you didn't tell [me|us] that"?


4 As previously mentioned: [typing, hints, PEP, Python, ...]. If you'd
care to build a tool which makes use of typing, that is the current
philosophy/invitation (per earlier comment and refs). Pending such a
tool, should we (all) start writing Python-with-typing in the
expectation of the requirements of some future hopes, or 'vapor-ware'?
(see also mypy)


5 I like the idea (any idea) of something that will make (my) life
easier (I've had to work very hard to be this lazy!). Thus, a tool (IDE
or whatever) that will do 'stuff' for me, or save me time, eg by saving
me from my own coding-mistakes; is bound to attract my attention.
Similarly: speed of coding, improved readability for others, ...

One of the joys of Python is "for". We (still) tend to call it a
"for...loop", but to be correct it should be something like a
"for-all...loop"! The traditional for...loop goes right back to early
"high-level programming languages", eg FORTRAN's DO-loop. The reason
Python has its (different) approach is because so many
programming-errors relate to "pointers" and their oft-related
"out-by-one errors", ie

for pointer from 1 to 10 # this is NOT Python!
print( array[ pointer ], array[ pointer } ^ 2 )

What if the "1" or the "10" is a variable, and the programmer fails to
keep them related/limited to the size of the array? What if the array
was populated from a zero-th element? ...

Instead, Python says:

for element in listNM:
print( ...

Easy - doesn't matter how long/short the list may be!

What's the point here (for you)?

Much analysis has been performed on programming, algorithms, code
structures, the psychology of computer programming, etc. Certainly, our
BDEVIL did when designing Python! Rather than (apparently!) starting at
the syntactic-level (with data-typing), might your research benefit from
looking at such meta-observations, and working from there? .

Alternately, perhaps Python does not lend itself to this sort of
research? Might another programming language might be a better choice?
The designers of the Rust programming language appeared to take a quite
different approach from Guido Van Rossum. A (rather shabby) comparison
between the two languages shows one taking the line 'we are all adults
here', but the other attempts to be 'secure' (in several definitions of
the word).


Web.Refs:
http://mypy-lang.org/
https://www.python.org/dev/peps/pep-0401/
--
Regards =dn

[DL Neil]

[Rhodri James]

[dcwhatthe]

On Friday, April 17, 2020 at 2:11:17 PM UTC-4, Rhodri James wrote:

> On 17/04/2020 17:18, dc wrote:

> > Maybe it isn't true for all IDE's or all languages. (I know SOMEONE
> > will interject here, to argue for the sake of arguing). But when I
> > worked with Groovy in Intellij about 5 years ago, there were times
> > when the IDE was confused, during a debugging sessions. I don't
> > remember the exact details, but that anomaly happened only with DEFed
> > variables ; it didn't happen when the data type was specified.
>

> This is a general problem for IDEs, and type information isn't always
> helpful. The number of times I have had to add useless bits of code to
> cast something to (uint8_t *) because I want to see the bytes and the
> IDE will not give up on trying to interpret them for me.
>

> And people wonder why I stick to gdb when at all possible :-)
>

> --
> Rhodri James *-* Kynesim Ltd

[boB Stepp]

On Wed, Apr 15, 2020 at 11:27 AM Chris Angelico <ros...@gmail.com> wrote:
>
> On Thu, Apr 16, 2020 at 12:01 AM <dcwh...@gmail.com> wrote:

> > config_file : file = open(config_file_s, "r")
> >
> >
> > What type of variable should config_file (above) be declared as?

> It returns a file-like object. Instead of annotating, just let the
> type hinting system figure it out - you initialized it with the result
> of an open() call, so it should be able to figure that out.
>
> Python is not C, you do not need to declare all your variable types.
>
> If you actually need a way to represent "file-like object" (maybe as a
> parameter to some other function), there are tools for that in the
> typing module, but just DON'T annotate every variable. Bad idea, will
> cause you a maintenance headache and won't help anything.

I have just started playing around with type annotations and mypy. I
have still much to learn. I take your point about "...cause you a
maintenance headache..." I am guessing that part of what you are
saying is that if mypy (or whatever is actually being used) can
properly infer the type of an object then there is no point in
annotating it. Can you give guidelines or point to a good article how
to best and most efficiently use type annotation without
over-annotating? Bear in mind that I have yet to fully grasp all of
what mypy (What I am currently using.) can correctly infer from the
code.

--
boB

[Chris Angelico]

On Sun, Apr 19, 2020 at 7:48 AM boB Stepp <robert...@gmail.com> wrote:
> Can you give guidelines or point to a good article how
> to best and most efficiently use type annotation without
> over-annotating? Bear in mind that I have yet to fully grasp all of
> what mypy (What I am currently using.) can correctly infer from the
> code.
>

Like with most things, the best way is to start by doing as little as
you possibly can, and then work your way up from there. Try using mypy
on your code absolutely as-is, without any type hints at all. If it
seems to be quite useless, add some hints, try again. Continue until
it's able to help you with your goals. Oh, I forgot to mention. Start
with a goal. Why are you using mypy? Is it to help you detect
misspelled variable/parameter names? Is it to save you the hassle of
writing unit tests? Is it to improve IDE features (tab completion
etc)?

The one specific thing I'll say is: function signatures are usually
the lowest-hanging fruit. For equivalent effort, they'll usually give
you the best results, since you can create "knowledge boundaries" of a
sort, where the type inference doesn't need to search the entire
codebase for everything. But other than that, just explore your own
codebase to try to find where it'd be useful.

ChrisA

[boB Stepp]

On Wed, Apr 15, 2020 at 11:27 AM Chris Angelico <ros...@gmail.com> wrote:
>
> On Thu, Apr 16, 2020 at 12:01 AM <dcwh...@gmail.com> wrote:

> > config_file : file = open(config_file_s, "r")
> >
> >
> > What type of variable should config_file (above) be declared as?

> It returns a file-like object. Instead of annotating, just let the
> type hinting system figure it out - you initialized it with the result
> of an open() call, so it should be able to figure that out.
>
> Python is not C, you do not need to declare all your variable types.
>
> If you actually need a way to represent "file-like object" (maybe as a
> parameter to some other function), there are tools for that in the
> typing module, but just DON'T annotate every variable. Bad idea, will
> cause you a maintenance headache and won't help anything.

I have just started playing around with type annotations and mypy. I have
still much to learn. I take your point about "...cause you a maintenance
headache..." I am guessing that part of what you are saying is that if mypy
(or whatever is actually being used) can properly infer the type of an object

then there is no point in annotating it. Can you give guidelines or point to a

good article how to best and most efficiently use type annotation without
over-annotating? Bear in mind that I have yet to fully grasp all of what mypy
(What I am currently using.) can correctly infer from the code.

--
boB

[Chris Angelico]

On Sun, Apr 19, 2020 at 7:48 AM boB Stepp <robert...@gmail.com> wrote:

> Can you give guidelines or point to a good article how
> to best and most efficiently use type annotation without
> over-annotating? Bear in mind that I have yet to fully grasp all of
> what mypy (What I am currently using.) can correctly infer from the
> code.
>