Re: Strong typing implementation for Python
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
Re: Strong typing implementation for Python
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
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
