Re: Strong typing implementation for Python

[m]

W dniu 13.10.2015 o 03:35, Michael Torrie pisze:
> On 10/12/2015 06:07 PM, Steven D'Aprano wrote:
>> > Where is the "vast amounts of noise" added to the code?
> Well in Java code for one.  No wonder they require auto-completion.
> Java class-based namespaces must be a nightmare to work with. 

IMHO mainly because their naming convention. They just love typing long
names. If they used named like in python, that "vast amount of noise
added to code" would be just "a bit noise added to code"

r. m.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[Laura Creighton]

In a message of Mon, 12 Oct 2015 19:35:57 -0600, Michael Torrie writes:
>On 10/12/2015 06:07 PM, Steven D'Aprano wrote:
>> Where is the "vast amounts of noise" added to the code?
>
>Well in Java code for one.  No wonder they require auto-completion.
>Java class-based namespaces must be a nightmare to work with.  That and
>all the over-use of design patterns that Java libraries love to do,
>though in fairness Java requires a certain amount of boilerplate to do
>things like singletons and factories, whereas Python can often just use
>a module.

When Design Patterns were new, the 2 of the first books to come out were
'Design Patterns'[1995] which was C++ focused, and the 'Design Patterns
Smalltalk Companion'[1998].  If you read the two of them, side by
side (as DPSTC asks you to) you will be struct by how little of the
C++ code is about 'here is the pattern I want to implement' and how
much is 'here is what to do to bash the C++ type system into
submission' -- to the point where a couple of DP are files, in the
Smalltalk version as 'for Smalltalk this is only a few lines of code,
not enough to really be a pattern (and I bet you do this all the time
without thinking that you were using a Design pattern, don't you?)'.
The Smalltalk versions are all so much sorter.  And Smalltalk, like
Python is a strongly and dynamically typed langauge.

Thus it is no wonder that the DP get used more than they need to in
the java world.  No matter what you write you will have to write the
'and then get it past the type checking' part, and grabbing a
well-tested one of those saves you from a lot of bugs, even if
you have to take and overly-heavy and complicated DP to go along
with it.

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

Re: Strong typing implementation for Python

[Todd]

On Oct 13, 2015 2:11 AM, "Steven D'Aprano"  wrote:
>
> On Tue, 13 Oct 2015 04:20 am, Marko Rauhamaa wrote:
>
> > As for managing complexity, many people believe static typing is a
> > crucial tool. I disagree. Static typing adds vast amounts of noise to
> > the code.
>
> Only if you are stuck in the 1970s. And even then, it is not always noise,
> type declarations or annotations often make useful documentation.
>
> Consider the following piece of code:
>
> def addone(x):
> return x + 1
>
>
> The human programmer reading that can trivially infer that x must be a
> number (or at least something which supports numeric addition). So can the
> compiler. In a strongly typed language with no numeric promotion, the
> compiler can infer that x must be an int. In a language with numeric
> promotion, it can infer that x must be an int or float.

Or a decimal, complex number, numpy array, any one of a dozen or so pandas
classes, any one of the dozen or so units classes, sympy variable, etc...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[Marko Rauhamaa]

Laura Creighton :

> When Design Patterns were new, the 2 of the first books to come out
> were 'Design Patterns'[1995] which was C++ focused, and the 'Design
> Patterns Smalltalk Companion'[1998]. If you read the two of them, side
> by side (as DPSTC asks you to) you will be struct by how little of the
> C++ code is about 'here is the pattern I want to implement' and how
> much is 'here is what to do to bash the C++ type system into
> submission' -- to the point where a couple of DP are files, in the
> Smalltalk version as 'for Smalltalk this is only a few lines of code,
> not enough to really be a pattern (and I bet you do this all the time
> without thinking that you were using a Design pattern, don't you?)'.
> The Smalltalk versions are all so much sorter. And Smalltalk, like
> Python is a strongly and dynamically typed langauge.
>
> Thus it is no wonder that the DP get used more than they need to in
> the java world. No matter what you write you will have to write the
> 'and then get it past the type checking' part, and grabbing a
> well-tested one of those saves you from a lot of bugs, even if you
> have to take and overly-heavy and complicated DP to go along with it.

Great post!

A few years back I programmed in Java. I literally had to write (or
generate) 2,000 lines of code to satisfy the structural requirements
(interfaces, method stubs, javadocs, ...) before the code actually did
anything.


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

Re: Strong typing implementation for Python

[Steven D'Aprano]

On Tue, 13 Oct 2015 06:55 pm, Todd wrote:

> On Oct 13, 2015 2:11 AM, "Steven D'Aprano"  wrote:

>> Consider the following piece of code:
>>
>> def addone(x):
>> return x + 1
>>
>>
>> The human programmer reading that can trivially infer that x must be a
>> number (or at least something which supports numeric addition). So can
>> the compiler. In a strongly typed language with no numeric promotion, the
>> compiler can infer that x must be an int. In a language with numeric
>> promotion, it can infer that x must be an int or float.
> 
> Or a decimal, complex number, numpy array, any one of a dozen or so pandas
> classes, any one of the dozen or so units classes, sympy variable, etc...

I knew my over-simplification would get me in trouble...

Firstly, if we're talking about Python specifically, the compiler won't
actually infer anything (see PEP 484, which "assumes the existence of a
separate off-line type checker which users can run over their source code
voluntarily"). It is up to the external type checker (or linter, IDE,
documentation generator, refactoring tool, etc) to perform any type checks.

Secondly, what the tool actually infers will depend on the tool. I would
expect that a basic type checker (say, in a text editor) will infer that x
is an int or float only. A more powerful checker might infer the Number ABC
(Abstract Base Class). A specialist checker might even know about numpy,
pandas, units and sympy, but I wouldn't expect a general-purpose type
checker to infer them.

If the programmer cares about such specialist types, then she can easily add
type hints to supplement the checker's type inference, or the checker
itself may be configurable. That's a *quality of implementation* detail.

The beauty of *gradual typing* is that you don't have to care about every
possible class in the entire universe of Python code, only about the
classes you actually care about in the parts of your code you choose to
type check.

http://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typing/

Because the Python interpreter itself doesn't care about the compile-time
type checking, if the checker gets in your way, you can just *not run it*.
I also expect that good checkers will include directives to skip sections
of code, so you can include annotations as documentation while still
silencing over-strict or incorrect compile-time type errors. (Runtime type
errors will still occur as normal.)



-- 
Steven

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

Re: Strong typing implementation for Python

[Laura Creighton]

In a message of Tue, 13 Oct 2015 13:31:56 +0100, Bartc writes:
>On 13/10/2015 11:42, Marko Rauhamaa wrote:
>
>> A few years back I programmed in Java. I literally had to write (or
>> generate) 2,000 lines of code to satisfy the structural requirements
>> (interfaces, method stubs, javadocs, ...) before the code actually did
>> anything.
>
>And this is the recommended language if you want to code apps for 
>Android. (Actually I don't think it's that easy to use another language 
>of your choice.)
>
>Who decides these things?
>-- 
>Bartc

Start using kivy and vote with your feet!
http://kivy.org/#home

Laura

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

Re: Strong typing implementation for Python

[Bartc]

On 13/10/2015 11:42, Marko Rauhamaa wrote:


A few years back I programmed in Java. I literally had to write (or
generate) 2,000 lines of code to satisfy the structural requirements
(interfaces, method stubs, javadocs, ...) before the code actually did
anything.


And this is the recommended language if you want to code apps for 
Android. (Actually I don't think it's that easy to use another language 
of your choice.)


Who decides these things?

--
Bartc


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

Re: Strong typing implementation for Python

[Sibylle Koczian]

Am 13.10.2015 um 00:10 schrieb Ben Finney:

Sibylle Koczian  writes:


Am 12.10.2015 um 13:39 schrieb Steven D'Aprano:

Auto-complete is a fine and useful tool. But if you are crippled as a
programmer without it, well, then you can hardly claim to understand the
language or framework you are programming in if you cannot use it without
an IDE doing half the work for you.



Well ... you're certainly quite right as far as Python and its
standard library is concerned. But I don't know who would really want
to use .NET without auto-complete and for all I know Java may be just
as awful.


Yes, and that is quite compatible with Steven's assertion. The two
assertions:

* A programmer who feels crippled without auto-complete cannot claim to
   understand the language or framework they're programming in.
   (assertion made by Steven)

* The overwhelming majority of .NET and Java programmers would feel
   crippled without auto-complete. (assertion made by Sibylle)

Not really wanting to do without x isn't the same as feeling crippled 
without it.



can both be true. An obvious resolution is to conclude that the
overwhelming majority of Java and .NET programmers cannot claim to
understand those technologies.

I don't think you can measure understanding by the ability and 
willingness (!) to type those overlong and yet similar names again and 
again in full.



Python, on the other hand, has the huge advantage that programming in
even a bare minimal editor is feasible, and editor features that make
the programmer's life easier are conveniences, not essential to be
competent in Python.

Only one of its huge advantages. As long as no GUI is necessary ... but 
that's another story.


Sibylle


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

Re: Strong typing implementation for Python

[Josef Pktd]

On Tuesday, October 13, 2015 at 9:40:56 AM UTC-4, Steven D'Aprano wrote:
> On Tue, 13 Oct 2015 06:55 pm, Todd wrote:
> 
> > On Oct 13, 2015 2:11 AM, "Steven D'Aprano" <...> wrote:
> 
> >> Consider the following piece of code:
> >>
> >> def addone(x):
> >> return x + 1
> >>
> >>
> >> The human programmer reading that can trivially infer that x must be a
> >> number (or at least something which supports numeric addition). So can
> >> the compiler. In a strongly typed language with no numeric promotion, the
> >> compiler can infer that x must be an int. In a language with numeric
> >> promotion, it can infer that x must be an int or float.
> > 
> > Or a decimal, complex number, numpy array, any one of a dozen or so pandas
> > classes, any one of the dozen or so units classes, sympy variable, etc...

A good example is `y = x * 2` followed by long calculations with y.

I have no idea what this does if I don't know the type of x.
(list and tuples get duplicated, arrays as in numpy or pandas multiply 
elementwise, matrix packages use dot (@) product. Two out of three will give us 
the wrong result but don't raise a runtime exception.)

The flip side of the flexibility with dynamic typing is that we spend a lot of 
time and effort in asserting or converting types.

There are cases when being able to quack is not enough, it needs to have the 
right quack. And when we allow for different sounds created by the duck 
look-a-likes, then code can get complicated and avoiding subtle mistakes will 
become very difficult.

Annotations might help the editors, but doesn't enforce the right behavior.
Also, in some cases we don't want to restrict ducktyping in the function or 
method arguments but we need to protect our calculations. Function annotations 
won't help her.

One common pattern then guarantees fixed types within a function:

def calculate_something(x):


x = numpy.asarray(x, numpy.float64)  # convert anything array_like to array

do calculations that only use numpy arrays


return result

In the center we have static types (as far as numpy arrays are static), and we 
don't have to guess on what methods are actually doing, and code inspection 
could infer this.

Outside we still have all the flexibility of duck typing.

I guess it's gradual typing but not through unenforced function annotations.

Josef


> 
> I knew my over-simplification would get me in trouble...
> 
> Firstly, if we're talking about Python specifically, the compiler won't
> actually infer anything (see PEP 484, which "assumes the existence of a
> separate off-line type checker which users can run over their source code
> voluntarily"). It is up to the external type checker (or linter, IDE,
> documentation generator, refactoring tool, etc) to perform any type checks.
> 
> Secondly, what the tool actually infers will depend on the tool. I would
> expect that a basic type checker (say, in a text editor) will infer that x
> is an int or float only. A more powerful checker might infer the Number ABC
> (Abstract Base Class). A specialist checker might even know about numpy,
> pandas, units and sympy, but I wouldn't expect a general-purpose type
> checker to infer them.
> 
> If the programmer cares about such specialist types, then she can easily add
> type hints to supplement the checker's type inference, or the checker
> itself may be configurable. That's a *quality of implementation* detail.
> 
> The beauty of *gradual typing* is that you don't have to care about every
> possible class in the entire universe of Python code, only about the
> classes you actually care about in the parts of your code you choose to
> type check.
> 
> http://wphomes.soic.indiana.edu/jsiek/what-is-gradual-typing/
> 
> Because the Python interpreter itself doesn't care about the compile-time
> type checking, if the checker gets in your way, you can just *not run it*.
> I also expect that good checkers will include directives to skip sections
> of code, so you can include annotations as documentation while still
> silencing over-strict or incorrect compile-time type errors. (Runtime type
> errors will still occur as normal.)
> 
> 
> 
> -- 
> Steven

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

Re: Strong typing implementation for Python

[Gregory Ewing]

m wrote:

W dniu 13.10.2015 o 03:35, Michael Torrie pisze:


Well in Java code for one.  No wonder they require auto-completion.
Java class-based namespaces must be a nightmare to work with. 


IMHO mainly because their naming convention. They just love typing long
names.


The biggest verbosity problems in Java stem from the
inability to define short aliases for fully-qualified
class names and complicated type expressions.

Ever since generic types were added, omitting such a
feature has been obviously insane, yet somehow nothing
has been done about it.

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

Re: Strong typing implementation for Python

[Gregory Ewing]

Bartc wrote:
I've surprised Basic needs it. The last time I looked, $A was a string, 
%B an integer, and C a number.


A$ and B%, actually.

Although if you didn't like the type suffixes, you
could say DEFINT I-N and pretend you were writing
Fortran code. :-)

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

Re: Strong typing implementation for Python

[Gregory Ewing]

Ben Finney wrote:


* The overwhelming majority of .NET and Java programmers would feel
  crippled without auto-complete. (assertion made by Sibylle)

An obvious resolution is to conclude that the
overwhelming majority of Java and .NET programmers cannot claim to
understand those technologies.


As a data point, I've been doing some fairly intensive
Java programming recently, and doing it in a very plain
text editor with no auto-completion at all.

While I do make a lot of use of docs during the process,
it's not so much to find out how a name is spelled, but
for higher-level things like which methods a class has,
or even which class I should be using in the first
place, and how to go about using it.

Also, once I've got the information needed for a
particular session paged into my brain, it usually stays
there at least for the rest of the session, so I'm not
having to constantly consult the docs for every little
thing.

So at least for me, it *is* possible to be productive
in Java without special editor support. In Python it's
even easier, due to the general smallness and consistency
of everything.

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

Re: Strong typing implementation for Python

[Josef Pktd]

On Tuesday, October 13, 2015 at 2:52:32 PM UTC-4, Sibylle Koczian wrote:
> Am 13.10.2015 um 00:10 schrieb Ben Finney:
> > Sibylle Koczian <> writes:
> >
> >> Am 12.10.2015 um 13:39 schrieb Steven D'Aprano:
> >>> Auto-complete is a fine and useful tool. But if you are crippled as a
> >>> programmer without it, well, then you can hardly claim to understand the
> >>> language or framework you are programming in if you cannot use it without
> >>> an IDE doing half the work for you.
> >>>
> >>
> >> Well ... you're certainly quite right as far as Python and its
> >> standard library is concerned. But I don't know who would really want
> >> to use .NET without auto-complete and for all I know Java may be just
> >> as awful.
> >
> > Yes, and that is quite compatible with Steven's assertion. The two
> > assertions:
> >
> > * A programmer who feels crippled without auto-complete cannot claim to
> >understand the language or framework they're programming in.
> >(assertion made by Steven)
> >
> > * The overwhelming majority of .NET and Java programmers would feel
> >crippled without auto-complete. (assertion made by Sibylle)
> >
> Not really wanting to do without x isn't the same as feeling crippled 
> without it.

To support this

I have been writing numpy/scipy based code in python for many years, and still 
I make a lot more mistakes without autocompletion and having pyflakes or 
similar run in the editor in the background.

I know roughly where everything is in a large class hierarchy with more 
information hidden in attached classes (instances). But it's easy to figure out 
the details with code completion and standard inspection.
It works pretty well maybe 90 % of the time (except in chained expressions).
I also memorize only the main arguments in the signatures, and rely for the 
rest on the pop-up hints.

> 
> > can both be true. An obvious resolution is to conclude that the
> > overwhelming majority of Java and .NET programmers cannot claim to
> > understand those technologies.
> >
> I don't think you can measure understanding by the ability and 
> willingness (!) to type those overlong and yet similar names again and 
> again in full.
> 
> > Python, on the other hand, has the huge advantage that programming in
> > even a bare minimal editor is feasible, and editor features that make
> > the programmer's life easier are conveniences, not essential to be
> > competent in Python.
> >
> Only one of its huge advantages. As long as no GUI is necessary ... but 
> that's another story.

I don't know about GUI programming, but even though it's not part of the 
language there are packages for example for asserting and maintaining types and 
restriction on values like traits and traitlets.

Josef


> 
> Sibylle

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

Re: Strong typing implementation for Python

[John Michael Lafayette]

Now that Python has static type checking and support for IDE auto-complete
(PEP 484?), I beg you to please use it. In your standard library, in your
production code, in everywhere. I cannot type without auto-complete.

I know that sounds ridiculous, but I have been coding on a daily basis for
the last four years and I cannot recall the last time I actually typed out
a variable or function name without auto-complete typing it for me. To me,
java.net.DatagramSocket isn't "DatagramSocket". It is "Da" + Ctrl + Space +
Enter (auto complete). I literally memorized the number of characters I
have to type for auto-complete to guess the variable name and then I only
type that many characters. For me, typing without auto-complete is like
doing surgery with a kitchen knife. It's messy and error prone and I make
lots of mistakes and have to try twice as hard to remember the actual names
of variables instead of just whatever they start with.

You don't understand because you actually know what all the function names
are and you don't have to constantly hover over them in auto-complete and
pull up their documentation to figure out how to use them. But I do. And
for me, without auto-complete, the learning process goes from actively
querying the IDE for one documentation after another to having to minimize
the IDE and Google search for each and every function and module that I"m
not familiar with. Auto-complete literally cuts the learning time by more
than half.

So please please please use PEP 484 to document all your standard library
functions. Not for static compilation. Not even for catching mistakes
caused by bad function input (although I like that). For Christ's sake, do
it for the auto-complete. I gave up on JavaScript in favor of TypeScript
for a reason god dammit.
On Oct 11, 2015 3:45 PM, "Matt Wheeler"  wrote:

> On 9 October 2015 at 17:26, John Michael Lafayette
>  wrote:
> > I would like Python to have a strong typing feature that can co-exist
> with
> > the current dynamic typing system. Currently Python is like this:
> >
> > var animal = Factory.make("dog")  # okay.
> > var dog = Factory.make("dog")   # okay.
> > var cat = Factory.make("dog")# are you sure?
> >
> > I would like Python to also be able to also do this:
> >
> > Animal a = Factory.make("dog")# okay. Dog is Animal.
> > Dog d = Factory.make("dog") # okay. Dog is Dog.
> > Cat c = Factory.make("cat")   # Runtime error. Dog is not
> Cat.
>
> Though it's intended for performance optimisation rather than simply
> static typing for static typing's sake, you could probably use Cython
> to achieve what you want...
>
> ...but then you might start to see the benefits of dynamic typing :)
>
>
> --
> Matt Wheeler
> http://funkyh.at
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[John Michael Lafayette]

No. Python now has static type checking and IDE auto-complete support. All
you have to do is put the type name in the function declaration.
On Oct 11, 2015 3:45 PM, "Matt Wheeler"  wrote:

> On 9 October 2015 at 17:26, John Michael Lafayette
>  wrote:
> > I would like Python to have a strong typing feature that can co-exist
> with
> > the current dynamic typing system. Currently Python is like this:
> >
> > var animal = Factory.make("dog")  # okay.
> > var dog = Factory.make("dog")   # okay.
> > var cat = Factory.make("dog")# are you sure?
> >
> > I would like Python to also be able to also do this:
> >
> > Animal a = Factory.make("dog")# okay. Dog is Animal.
> > Dog d = Factory.make("dog") # okay. Dog is Dog.
> > Cat c = Factory.make("cat")   # Runtime error. Dog is not
> Cat.
>
> Though it's intended for performance optimisation rather than simply
> static typing for static typing's sake, you could probably use Cython
> to achieve what you want...
>
> ...but then you might start to see the benefits of dynamic typing :)
>
>
> --
> Matt Wheeler
> http://funkyh.at
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[Marko Rauhamaa]

John Michael Lafayette :

> Now that Python has static type checking and support for IDE
> auto-complete (PEP 484?), I beg you to please use it. In your standard
> library, in your production code, in everywhere. I cannot type without
> auto-complete.
>
> I know that sounds ridiculous,

It sure does. Ducktyping is the essence of Python. You are asking Python
to become Java.

> You don't understand because you actually know what all the function
> names are and you don't have to constantly hover over them in
> auto-complete and pull up their documentation to figure out how to use
> them.

I barely remember any of them. That's why I keep Python Standard Library
reference in a browser window whenever I program in Python.

> But I do. And for me, without auto-complete, the learning process goes
> from actively querying the IDE for one documentation after another to
> having to minimize the IDE and Google search for each and every
> function and module that I"m not familiar with. Auto-complete
> literally cuts the learning time by more than half.

Many modern windowing systems let you have more than one window on the
screen at once. My Python editor window occupies 25% of the screen. The
rest of the space goes to a browser, a couple of terminals etc.

You don't need Google to see Python's documentation. Just bookmark

   https://docs.python.org/3/library/

> So please please please use PEP 484 to document all your standard
> library functions. Not for static compilation. Not even for catching
> mistakes caused by bad function input (although I like that). For
> Christ's sake, do it for the auto-complete. I gave up on JavaScript in
> favor of TypeScript for a reason god dammit.

It would appear Python is too small a programming language for the two
of us.


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

Re: Strong typing implementation for Python

[Michael Torrie]

On 10/12/2015 07:30 AM, Bartc wrote:
> On 12/10/2015 03:45, Michael Torrie wrote:
>> On 10/11/2015 06:34 PM, Steven D'Aprano wrote:
>>> That's called type inference, and there's nothing innovative about Swift to
>>> include that as a feature. Type inference is *old*. The theory behind type
>>> inference goes back to 1958, and languages such as ML and OCaml have
>>> included it for decades, and yet here we are in 2015 and people think that
>>> it's something cool and new :-(
>>
>> C++ introduced it a while ago (C++11), and D has had it from the
>> beginning.  Even lowly FreeBasic has it.
> 
> I've surprised Basic needs it. The last time I looked, $A was a string, 
> %B an integer, and C a number. Type inference wasn't hard!

Back in the day this was certainly true.  Most modern Basic dialects are
more C-like in their declarations.

> (And trying Freebasic, it insists on variables being declared anyway. 
> It's rather like C but with Basic syntax.)

FB could be considered C-like with a Basic syntax, yes, but with dynamic
strings and dynamic arrays.  This idea of being c-like makes FB kind of
interesting but uninteresting at the same time.  Kind of hard to come up
with a good reason to use it for something, especially when a dynamic
language like Python, combined with C, is so flexible.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[Ian Kelly]

On Mon, Oct 12, 2015 at 2:47 AM, John Michael Lafayette
 wrote:
> Now that Python has static type checking and support for IDE auto-complete
> (PEP 484?), I beg you to please use it. In your standard library, in your
> production code, in everywhere. I cannot type without auto-complete.

*Decent* Python IDEs have had auto-complete for years -- at least for
the past decade. You don't need PEP 484 for that.

If the IDE that you're using doesn't support it well, then find
another one that does.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[edmondo . giovannozzi]

Il giorno lunedì 12 ottobre 2015 10:51:50 UTC+2, John Michael Lafayette ha 
scritto:
> Now that Python has static type checking and support for IDE auto-complete 
> (PEP 484?), I beg you to please use it. In your standard library, in your 
> production code, in everywhere. I cannot type without auto-complete. 
> 
> I know that sounds ridiculous, but I have been coding on a daily basis for 
> the last four years and I cannot recall the last time I actually typed out a 
> variable or function name without auto-complete typing it for me. To me, 
> java.net.DatagramSocket isn't "DatagramSocket". It is "Da" + Ctrl + Space + 
> Enter (auto complete). I literally memorized the number of characters I have 
> to type for auto-complete to guess the variable name and then I only type 
> that many characters. For me, typing without auto-complete is like doing 
> surgery with a kitchen knife. It's messy and error prone and I make lots of 
> mistakes and have to try twice as hard to remember the actual names of 
> variables instead of just whatever they start with. 
> 
> You don't understand because you actually know what all the function names 
> are and you don't have to constantly hover over them in auto-complete and 
> pull up their documentation to figure out how to use them. But I do. And for 
> me, without auto-complete, the learning process goes from actively querying 
> the IDE for one documentation after another to having to minimize the IDE and 
> Google search for each and every function and module that I"m not familiar 
> with. Auto-complete literally cuts the learning time by more than half. 
> 
> So please please please use PEP 484 to document all your standard library 
> functions. Not for static compilation. Not even for catching mistakes caused 
> by bad function input (although I like that). For Christ's sake, do it for 
> the auto-complete. I gave up on JavaScript in favor of TypeScript for a 
> reason god dammit.
> 
> On Oct 11, 2015 3:45 PM, "Matt Wheeler"  wrote:
> On 9 October 2015 at 17:26, John Michael Lafayette
> 
>  wrote:
> 
> > I would like Python to have a strong typing feature that can co-exist with
> 
> > the current dynamic typing system. Currently Python is like this:
> 
> >
> 
> >     var animal = Factory.make("dog")  # okay.
> 
> >     var dog = Factory.make("dog")       # okay.
> 
> >     var cat = Factory.make("dog")        # are you sure?
> 
> >
> 
> > I would like Python to also be able to also do this:
> 
> >
> 
> >     Animal a = Factory.make("dog")    # okay. Dog is Animal.
> 
> >     Dog d = Factory.make("dog")         # okay. Dog is Dog.
> 
> >     Cat c = Factory.make("cat")           # Runtime error. Dog is not Cat.
> 
> 
> 
> Though it's intended for performance optimisation rather than simply
> 
> static typing for static typing's sake, you could probably use Cython
> 
> to achieve what you want...
> 
> 
> 
> ...but then you might start to see the benefits of dynamic typing :)
> 
> 
> 
> 
> 
> --
> 
> Matt Wheeler
> 
> http://funkyh.at

As far as I know the shell (if I can call it a shell) IPython has a sort of 
autocomplete. Given an object, after a dot if you type a tab it will give you 
the list of all the method that it can retrieve from the function dir(). 

geany, and spyder have also a sort of autocomplete.

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

Re: Strong typing implementation for Python

[Michael Torrie]

On 10/12/2015 02:47 AM, John Michael Lafayette wrote:
> Now that Python has static type checking and support for IDE auto-complete
> (PEP 484?), I beg you to please use it. In your standard library, in your
> production code, in everywhere. I cannot type without auto-complete.
> 
> I know that sounds ridiculous, but I have been coding on a daily basis for
> the last four years and I cannot recall the last time I actually typed out
> a variable or function name without auto-complete typing it for me. To me,
> java.net.DatagramSocket isn't "DatagramSocket". It is "Da" + Ctrl + Space +
> Enter (auto complete). I literally memorized the number of characters I
> have to type for auto-complete to guess the variable name and then I only
> type that many characters. For me, typing without auto-complete is like
> doing surgery with a kitchen knife. It's messy and error prone and I make
> lots of mistakes and have to try twice as hard to remember the actual names
> of variables instead of just whatever they start with.

I haven't used Java in many years now, but it sounds like it's an awful
experience to use if auto-complete is such a requirement to get anything
done.

> You don't understand because you actually know what all the function
> names are and you don't have to constantly hover over them in
> auto-complete and pull up their documentation to figure out how to
> use them. But I do. And for me, without auto-complete, the learning
> process goes from actively querying the IDE for one documentation
> after another to having to minimize the IDE and Google search for
> each and every function and module that I"m not familiar with.
> Auto-complete literally cuts the learning time by more than half.

Of course I don't know all the function names by heart.  But in several
years I haven't had to either.  A few that I use regularly are easy to
memorize.

Not sure what you mean about having to minimize anything.  If an IDE has
to be kept full-screen all the time then I would find them to be a
significant handicap.  I have a windowing system for a reason!  I can
count on one hand the number of times I've maximized a window in the
last few years.

As others have said the standard library docs are quite good, and it's
not hard to keep them up next to my programming window.  Also Python can
help document itself.  A vital tool for any Python programmer is an
interactive Python session.  It's often easier to query the object I'm
working with directly to find what methods it supports and the
parameters it expects.  Get familiar with the Python interactive mode
and with basic calls like dir() and help().

Also many Python editing environments do support basic completion.
However completion is actually very difficult to implement in a static
manner because Python is so dynamic.  I can import any standard library
module and rename it as needed.  Since some modules have longer names
that I don't want to always type and since importing all of a module's
symbols into the global namespace is really not a good idea, I might do
something like

import BeautifulSoup as bs

Now I can refer to any BeautifulSoup symbols using the prefix bs.  That
isn't impossible for an IDE to track, but it is harder.

If you can set aside your prejudices (static typing) and learn idiomatic
python I think you'll have a great amount of fun and you'll find that
even without the same level of auto completion that you'll be able to
develop quite a bit faster than with Java.  There's a good book called
Fluent Python that can show you how idiomatic Python can really benefit
you.  Another good one is "Effective Python."
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[Bartc]

On 12/10/2015 03:45, Michael Torrie wrote:

On 10/11/2015 06:34 PM, Steven D'Aprano wrote:

That's called type inference, and there's nothing innovative about Swift to
include that as a feature. Type inference is *old*. The theory behind type
inference goes back to 1958, and languages such as ML and OCaml have
included it for decades, and yet here we are in 2015 and people think that
it's something cool and new :-(


C++ introduced it a while ago (C++11), and D has had it from the
beginning.  Even lowly FreeBasic has it.


I've surprised Basic needs it. The last time I looked, $A was a string, 
%B an integer, and C a number. Type inference wasn't hard!


(And trying Freebasic, it insists on variables being declared anyway. 
It's rather like C but with Basic syntax.)


--
Bartc


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

Re: Strong typing implementation for Python

[Steven D'Aprano]

On Mon, 12 Oct 2015 07:47 pm, John Michael Lafayette wrote:

> Now that Python has static type checking 

It certainly does not. It appears you have misunderstood the purpose and
meaning of PEP 484.

PEP 484 provides a *standard meaning for function annotations* as
type-hints, which may be useful for third-party type-checking,
documentation generators, runtime inspection, editor auto-completion, and
other tools. It doesn't add static type checking to Python.


> and support for IDE auto-complete (PEP 484?), 

PEP 484 isn't needed for IDE auto-completion, although it can be used for
that.

Using IDLE and Pyton 2.7, I can type "l" (without the quotes) and TAB, and
IDLE will pop up a menu with "len" highlighted. And IDLE is a pretty basic
IDE: its auto-complete only works on built-in names, which makes it quite
limited. More powerful IDEs have better auto-complete features.


> I beg you to please use it. In your standard library, in your 
> production code, in everywhere. I cannot type without auto-complete.

I'm sorry for your disability, but for most programmers, auto-complete is a
convenience, not a necessity.


> I know that sounds ridiculous, but I have been coding on a daily basis for
> the last four years and I cannot recall the last time I actually typed out
> a variable or function name without auto-complete typing it for me. To me,
> java.net.DatagramSocket isn't "DatagramSocket". It is "Da" + Ctrl + Space
> + Enter (auto complete). I literally memorized the number of characters I
> have to type for auto-complete to guess the variable name and then I only
> type that many characters.

I cannot imagine filling my mind with such useless information as "the
number of characters I have to type for auto-complete to guess the variable
name". I *especially* cannot fathom why I would prefer to learn "two
characters, starts with Da" by rote instead of something *meaningful*
like "DatagramSocket". What does "Da" stand for? Daddy, dabbling,
dandelion, dandruff, daguerreotype?


> For me, typing without auto-complete is like 
> doing surgery with a kitchen knife. It's messy and error prone and I make
> lots of mistakes and have to try twice as hard to remember the actual
> names of variables instead of just whatever they start with.
> 
> You don't understand because you actually know what all the function names
> are and you don't have to constantly hover over them in auto-complete and
> pull up their documentation to figure out how to use them. 

Hardly.


> But I do. And 
> for me, without auto-complete, the learning process goes from actively
> querying the IDE for one documentation after another to having to minimize
> the IDE and Google search for each and every function and module that I"m
> not familiar with. Auto-complete literally cuts the learning time by more
> than half.

No, it just eliminates learning. The end result is that you are reliant on
the auto-complete because you haven't actually learned.


> So please please please use PEP 484 to document all your standard library
> functions. Not for static compilation. Not even for catching mistakes
> caused by bad function input (although I like that). For Christ's sake, do
> it for the auto-complete. I gave up on JavaScript in favor of TypeScript
> for a reason god dammit.

As I said, you don't need PEP 484 to implement auto-complete.

Auto-complete is a fine and useful tool. But if you are crippled as a
programmer without it, well, then you can hardly claim to understand the
language or framework you are programming in if you cannot use it without
an IDE doing half the work for you.



-- 
Steven

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

Re: Strong typing implementation for Python

[Sibylle Koczian]

Am 12.10.2015 um 13:39 schrieb Steven D'Aprano:

Auto-complete is a fine and useful tool. But if you are crippled as a
programmer without it, well, then you can hardly claim to understand the
language or framework you are programming in if you cannot use it without
an IDE doing half the work for you.



Well ... you're certainly quite right as far as Python and its standard 
library is concerned. But I don't know who would really want to use .NET 
without auto-complete and for all I know Java may be just as awful.


Sibylle



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

Re: Strong typing implementation for Python

[Bartc]

On 12/10/2015 16:47, Michael Torrie wrote:

On 10/12/2015 07:30 AM, Bartc wrote:

On 12/10/2015 03:45, Michael Torrie wrote:



C++ introduced it a while ago (C++11), and D has had it from the
beginning.  Even lowly FreeBasic has it.


[I'm] surprised Basic needs it. The last time I looked, $A was a string,
%B an integer, and C a number. Type inference wasn't hard!


Back in the day this was certainly true.  Most modern Basic dialects are
more C-like in their declarations.


(And trying Freebasic, it insists on variables being declared anyway.
It's rather like C but with Basic syntax.)


FB could be considered C-like with a Basic syntax, yes, but with dynamic
strings and dynamic arrays.  This idea of being c-like makes FB kind of
interesting but uninteresting at the same time.  Kind of hard to come up
with a good reason to use it for something, especially when a dynamic
language like Python, combined with C, is so flexible.


I suppose one reason is that it is easy to get up to speed with little 
effort, with something that is friendlier and a little higher level than 
C. Actually, I was pleasantly surprised at its capabilities.


(Example, calling fib(40) on the example below took 90 seconds on Python 
3.4, 11 seconds with PyPy, but only 1.8 seconds running the equivalent 
with FreeBasic:


 def fib(n):
   if n<2:
 return n
   else:
 return fib(n-2)+fib(n-1)

There are doubtless all sorts of ways of getting that sort of speed in 
Python, but it's something extra to be researched and to do and could 
require using an auxiliary language. Maybe there are too many possible 
ways which is another problem.)



--
Bartc


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

Re: Strong typing implementation for Python

[Marko Rauhamaa]

Bartc :

> (Example, calling fib(40) on the example below took 90 seconds on
> Python 3.4, 11 seconds with PyPy, but only 1.8 seconds running the
> equivalent with FreeBasic:

I don't know what you need fibonacci numbers for, but speed is not the
essence of most programming tasks. Rather, the key issue is managing
complexity.

As for managing complexity, many people believe static typing is a
crucial tool. I disagree. Static typing adds vast amounts of noise to
the code. A dynamic programming language like Python allows you to
express powerful abstractions concisely, understandably and likely
correctly.


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

Re: Strong typing implementation for Python

[Bartc]

On 12/10/2015 18:20, Marko Rauhamaa wrote:

Bartc :


(Example, calling fib(40) on the example below took 90 seconds on
Python 3.4, 11 seconds with PyPy, but only 1.8 seconds running the
equivalent with FreeBasic:


I don't know what you need fibonacci numbers for,


It's a benchmark that gives you an idea of how efficient an 
implementation is at doing function calls.



but speed is not the
essence of most programming tasks.


They've been wasting their time with PyPy then! Everyone likes a bit 
more speed. It can mean being able to have a solution all within the 
same language.



Rather, the key issue is managing
complexity.


(Yes, I've seen gal kauffman's post in this thread. That will need some 
managing for sure!)



As for managing complexity, many people believe static typing is a
crucial tool. I disagree. Static typing adds vast amounts of noise to
the code. A dynamic programming language like Python allows you to
express powerful abstractions concisely, understandably and likely
correctly.


Static typing gives advantages but it's also nice not to have to bother. 
That's why type inference can be useful.


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

Re: Strong typing implementation for Python

[Terry Reedy]

On 10/12/2015 12:08 PM, Michael Torrie wrote:


Also many Python editing environments do support basic completion.
However completion is actually very difficult to implement in a static
manner because Python is so dynamic.  I can import any standard library
module and rename it as needed.  Since some modules have longer names
that I don't want to always type and since importing all of a module's
symbols into the global namespace is really not a good idea, I might do
something like

import BeautifulSoup as bs

Now I can refer to any BeautifulSoup symbols using the prefix bs.  That
isn't impossible for an IDE to track, but it is harder.


That depends on whether autocompletion is name or object based.  IDLE's 
is object based, so the following displays the contents of itertools the 
same as without the abbreviation.


>>> import itertools as it
>>> it.

Object-based in turn means that autocompletion does not work as well in 
the editor until the code *is* executed.


--
Terry Jan Reedy

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

Re: Strong typing implementation for Python

[Jason Swails]

On Mon, Oct 12, 2015 at 1:50 PM, Bartc  wrote:

> On 12/10/2015 18:20, Marko Rauhamaa wrote:
>
>> Bartc :
>>
>> (Example, calling fib(40) on the example below took 90 seconds on
>>> Python 3.4, 11 seconds with PyPy, but only 1.8 seconds running the
>>> equivalent with FreeBasic:
>>>
>>
>> I don't know what you need fibonacci numbers for,
>>
>
> It's a benchmark that gives you an idea of how efficient an implementation
> is at doing function calls.
>
> but speed is not the
>> essence of most programming tasks.
>>
>
> They've been wasting their time with PyPy then! Everyone likes a bit more
> speed. It can mean being able to have a solution all within the same
> language.


​Marko said most.  Not all.  And I would agree with that (I'm a
computational scientist, where we put more emphasis on performance than
almost anywhere else).  A lot of our tools need to be hand-optimized using
either assembler or compiler intrinsics to get the most performance
possible out of the machine, but the *vast* majority of our daily
programming does not require this.  Only the most computationally intensive
kernels do (which themselves are small portions of the main simulation
engines!).

Performance only matters when it allows you to do something that you
otherwise couldn't.  pypy makes some things possible that otherwise wasn't,
but there's a reason why CPython is still used overwhelmingly more than
pypy for scientific computing.​

​All the best,
Jason
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[Ben Finney]

Sibylle Koczian  writes:

> Am 12.10.2015 um 13:39 schrieb Steven D'Aprano:
> > Auto-complete is a fine and useful tool. But if you are crippled as a
> > programmer without it, well, then you can hardly claim to understand the
> > language or framework you are programming in if you cannot use it without
> > an IDE doing half the work for you.
> >
>
> Well ... you're certainly quite right as far as Python and its
> standard library is concerned. But I don't know who would really want
> to use .NET without auto-complete and for all I know Java may be just
> as awful.

Yes, and that is quite compatible with Steven's assertion. The two
assertions:

* A programmer who feels crippled without auto-complete cannot claim to
  understand the language or framework they're programming in.
  (assertion made by Steven)

* The overwhelming majority of .NET and Java programmers would feel
  crippled without auto-complete. (assertion made by Sibylle)

can both be true. An obvious resolution is to conclude that the
overwhelming majority of Java and .NET programmers cannot claim to
understand those technologies.

Python, on the other hand, has the huge advantage that programming in
even a bare minimal editor is feasible, and editor features that make
the programmer's life easier are conveniences, not essential to be
competent in Python.

-- 
 \   “Free thought is a necessary, but not a sufficient, condition |
  `\   for democracy.” —Carl Sagan |
_o__)  |
Ben Finney

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

Re: Strong typing implementation for Python

[Steven D'Aprano]

On Tue, 13 Oct 2015 04:20 am, Marko Rauhamaa wrote:

> As for managing complexity, many people believe static typing is a
> crucial tool. I disagree. Static typing adds vast amounts of noise to
> the code.

Only if you are stuck in the 1970s. And even then, it is not always noise,
type declarations or annotations often make useful documentation.

Consider the following piece of code:

def addone(x):
return x + 1


The human programmer reading that can trivially infer that x must be a
number (or at least something which supports numeric addition). So can the
compiler. In a strongly typed language with no numeric promotion, the
compiler can infer that x must be an int. In a language with numeric
promotion, it can infer that x must be an int or float.

Where is the "vast amounts of noise" added to the code?



-- 
Steven

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

Re: Strong typing implementation for Python

[Bartc]

On 13/10/2015 01:07, Steven D'Aprano wrote:

On Tue, 13 Oct 2015 04:20 am, Marko Rauhamaa wrote:


As for managing complexity, many people believe static typing is a
crucial tool. I disagree. Static typing adds vast amounts of noise to
the code.


Only if you are stuck in the 1970s. And even then, it is not always noise,
type declarations or annotations often make useful documentation.

Consider the following piece of code:

def addone(x):
 return x + 1


The human programmer reading that can trivially infer that x must be a
number (or at least something which supports numeric addition). So can the
compiler. In a strongly typed language with no numeric promotion, the
compiler can infer that x must be an int. In a language with numeric
promotion, it can infer that x must be an int or float.


That's type inference. And is harder than it looks. In Python, x could 
be almost anything, and still be legal, if X has type T and "+" has been 
defined between T and integer. (It would need to analyse an entire 
program and it still can't always be sure.)



Where is the "vast amounts of noise" added to the code?


It comes from writing this:

 def addone(int x)int:

And not all types are as compact as 'int' (have a look at some C or C++ 
header files).


--
Bartc



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

Re: Strong typing implementation for Python

[Michael Torrie]

On 10/12/2015 06:07 PM, Steven D'Aprano wrote:
> Where is the "vast amounts of noise" added to the code?

Well in Java code for one.  No wonder they require auto-completion.
Java class-based namespaces must be a nightmare to work with.  That and
all the over-use of design patterns that Java libraries love to do,
though in fairness Java requires a certain amount of boilerplate to do
things like singletons and factories, whereas Python can often just use
a module.

Also in C and C++ the static type declarations do sometimes make things
look a lot more noisy.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[Matt Wheeler]

On 9 October 2015 at 17:26, John Michael Lafayette
 wrote:
> I would like Python to have a strong typing feature that can co-exist with
> the current dynamic typing system. Currently Python is like this:
>
> var animal = Factory.make("dog")  # okay.
> var dog = Factory.make("dog")   # okay.
> var cat = Factory.make("dog")# are you sure?
>
> I would like Python to also be able to also do this:
>
> Animal a = Factory.make("dog")# okay. Dog is Animal.
> Dog d = Factory.make("dog") # okay. Dog is Dog.
> Cat c = Factory.make("cat")   # Runtime error. Dog is not Cat.

Though it's intended for performance optimisation rather than simply
static typing for static typing's sake, you could probably use Cython
to achieve what you want...

...but then you might start to see the benefits of dynamic typing :)


-- 
Matt Wheeler
http://funkyh.at
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[gal kauffman]

> You can run your code inside a class definition, abuse metaclassing to
replace the namespace with yourown dict and override the __setitem__
function. Then you can implement a var function so it inspect into it's
caller namespace, and inserts the given key into it.
This hack doesn't apply on any sub scope, is not scaleable, and is generaly
bad.

import inspect

# Implement how you see right
class VarError(NameError):
pass
class MissingVarError(VarError):
pass
class ExisitngVarError(VarError):
pass

def namespacemeta(namespace):
class _(type):
@classmethod
def __prepare__(metacls, name, bases):
return namespace()
return _

class staticnamespace(dict):
PRE_USER_SETTED_ITENS = 2

def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
self.items_setted = 0

def var_setitem(self, key, typ):
# Use descriptor object for better control
# Implement type-checking yourself
return super().__setitem__(key, typ)

def __setitem__(self, key, value):
if self.items_setted >= staticnamespace.PRE_USER_SETTED_ITENS: # Ugly hack,
probably won't work IRL
if key not in self:
raise MissingVarError(key)

self.items_setted += 1
return super().__setitem__(key, value)

def var(key, typ):
calling_namespace = inspect.currentframe().f_back.f_locals
if key in calling_namespace:
raise ExisitngVarError(key)

calling_namespace.var_setitem(key, typ)

class _(object, metaclass=namespacemeta(staticnamespace)):
if __name__ == '__main__':
try:
a = 13
except MissingVarError:
print("Couldn't set 'a'")

var('a', int)
a = 37
print(a)

try:
var('a', str)
except ExisitngVarError:
print ("Can't call var twice with the same variable name")
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[Gregory Ewing]

On 9 October 2015 at 17:26, John Michael Lafayette
 wrote:


I would like Python to also be able to also do this:

   Animal a = Factory.make("dog")# okay. Dog is Animal.
   Dog d = Factory.make("dog") # okay. Dog is Dog.
   Cat c = Factory.make("cat")   # Runtime error. Dog is not Cat.


You might like to investigate Boo, which is a .NET-based
language with a Python-like syntax:

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

Re: Strong typing implementation for Python

[Vladimir Ignatov]

Hi,

> You might like to investigate Boo, which is a .NET-based
> language with a Python-like syntax:

AFAIK Unity just dropped Boo support from version 5.0 because
virtually nobody used it. Those little known niche languages are
destined to extinct.

Interesting language is Apple's Swift. While it's statically typed
language, type specification is optional as far as compiler can figure
out type. That gives an interesting feeling because you don't need to
type types all over but in the same time you have all type checking we
normally expect from statically typed language. The syntax is not
pythonic but overall it looks like language got some influence from
Python.

Vladimir


http://itunes.apple.com/us/app/python-code-samples/id1025613117
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Strong typing implementation for Python

[Steven D'Aprano]

On Mon, 12 Oct 2015 10:24 am, Vladimir Ignatov wrote:

> Hi,
> 
>> You might like to investigate Boo, which is a .NET-based
>> language with a Python-like syntax:
> 
> AFAIK Unity just dropped Boo support from version 5.0 because
> virtually nobody used it.

What's Unity? I've never heard of it. Why should Boo users care about it?


> Those little known niche languages are
> destined to extinct.

Yes, you are correct, and sadly while rubbish languages like PHP, Java,
Javascript and C continue in popularity for decades, amazingly good,
powerful, safe, rich languages like D, Eiffel and others languish in
obscurity as niche languages for just as long, and innovative languages
like Boo are almost certain to die off.

Network effects have a dark side, and the IT community as a whole is not
just conservative, but *stupidly* conservative to the point of pain. And
becoming *more* conservative and scared of change, not less.


> Interesting language is Apple's Swift. While it's statically typed
> language, type specification is optional as far as compiler can figure
> out type. 

That's called type inference, and there's nothing innovative about Swift to
include that as a feature. Type inference is *old*. The theory behind type
inference goes back to 1958, and languages such as ML and OCaml have
included it for decades, and yet here we are in 2015 and people think that
it's something cool and new :-(




-- 
Steven

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

Re: Strong typing implementation for Python

[Michael Torrie]

On 10/11/2015 06:34 PM, Steven D'Aprano wrote:
> That's called type inference, and there's nothing innovative about Swift to
> include that as a feature. Type inference is *old*. The theory behind type
> inference goes back to 1958, and languages such as ML and OCaml have
> included it for decades, and yet here we are in 2015 and people think that
> it's something cool and new :-(

C++ introduced it a while ago (C++11), and D has had it from the
beginning.  Even lowly FreeBasic has it.  It's certainly nice and it can
be a time saver. Though it's only useful in certain places, such as when
declaring a variable and an initializer.  While it can be used for the
return type of a function, in practice I've found it to not be that
useful when you are making a function that is going to be called by
someone else.  You can't just stick an automatic reference in a .h file,
for example.

Anyway, I guess our OP is another example of a drive-by poster who took
a brief look at Python then came here to try make a point of some kind,
and then disappeared, perhaps realizing that he probably should have
gained a bit more understanding of Python before trying to make said point.

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

Re: Strong typing implementation for Python

[Mark Lawrence]

On 09/10/2015 17:03, John Michael Lafayette wrote:

I would like Python to have a strong typing feature that can co-exist
with the current dynamic typing system. Currently Python is like this:

var animal = Factory.make("dog") #okay
var dog = Factory.make("dog") #okay



As Ben Finney has all ready pointed out elsewhere Python is strongly typed.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Strong typing implementation for Python

[Bartc]

On 09/10/2015 17:26, John Michael Lafayette wrote:

I would like Python to have a strong typing feature that can co-exist
with the current dynamic typing system. Currently Python is like this:

 var animal = Factory.make("dog")  # okay.
 var dog = Factory.make("dog")   # okay.
 var cat = Factory.make("dog")# are you sure?


AFAIK (I'm not an expert) that isn't Python. And you wouldn't expect 
Python to know about the names of animals and their relationships to 
each other so that it can give that sort of warning.



I would like Python to also be able to also do this:

 Animal a = Factory.make("dog")# okay. Dog is Animal.
 Dog d = Factory.make("dog") # okay. Dog is Dog.
 Cat c = Factory.make("cat")   # Runtime error. Dog is not Cat.


It seems you're looking for a radically different language (statically 
typed amongst other things).


But I think you can define Animal, Dog and Cat such that you can write this:

a = Factory.make(Animal,"dog")
d = Factory.make(Dog,"dog")
c = Factory.make(Cat,"cat")

and program it so that it behaves the way you want. That doesn't need 
any language changes.



With a strong typing option that performs runtime type checking, the
reader can be certain that the program is running the type they expect.
Also, the IDE can be more helpful. Example:

 var dog = Factory.make("dog")  # okay
 dog. (Ctr+Space)   # Auto-complete lists only
Animal methods.


Even as a non-expert, I know that is not possible unless it is 
completely transformed (or you are running it interactively).


Neither the IDE nor the Python bytecode compile can know what Factory or 
make are going to be until runtime, and even then, not until it's about 
to execute that line (and perhaps not even by that point sometimes, if 
the evaluation of the line can change the meaning of Factory).



This feature can be completely optional and could be integrated without
anyone noticing. If it is integrated, only the people who want this type
safety would have to use it. If there is a performance penalty, it would
mainly affect the people who use this feature. Given that a lot of
people transition from C/C++/Java to Python, I think that this feature
would be intuitive to many users and a good addition for people who like
type safety.


Remember that Python allows this:

  if randombit():   # 1 or 0
 import A
  else:
 import B

A defines Factory as that complex class or whatever you had in mind. 
While B defines Factory as:


  Factory = 42

--
bartc

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

Re: Strong typing implementation for Python

[Michael Torrie]

On 10/09/2015 10:26 AM, John Michael Lafayette wrote:
> I would like Python to have a strong typing feature that can co-exist with
> the current dynamic typing system. Currently Python is like this:
> 
> var animal = Factory.make("dog")  # okay.
> var dog = Factory.make("dog")   # okay.
> var cat = Factory.make("dog")# are you sure?

No actually it's not like that at all.  Python's variables are not like
C where they are little boxes you can write values to.  Python's
variables are names that are attached to various objects.  Once a name
is assigned to an object, unless that object permits mutation to itself,
the actual value can never change, until the name is reused by rebinding
it.  On other words, Python's variables are very strongly typed.

Python does have type annotations, but those really only are meaningful
for function calls where the function can recommend some types of
variables to pass to it. And type annotations certainly have their place

Also, the nicest and most powerful feature of python is that as long as
my object supports a particular interface, I can pass it to a function
that knows nothing about my particular type and it works.  Called duck
typing.

Looks to me like you want Python to be Java.  Instead I suggest you
learn more idiomatic ways of doing things and let Python work for you
instead of against you.  But it sounds like you don't want Python
anyway.  If you want a static language, use a static language.  There
are many compiled languages available these days with vaguely
python-like syntaxes.  One is Nim.  There's the D language too for
bringing some of the expressiveness of Python to a language that's more
similar to C in syntax.  There's certainly room in the world for using a
variety of programming languages to suit your purpose.  For mine right
now Python fits the bill rather wonderfully.


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