What variable type is returned from Open()?

[DL Neil]

On 18/04/20 4:18 AM, dcwhatthe at gmail.com wrote:
> 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.


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