Oops sorry accidentally sent mid typing:
```
class Array:
def __class_getitem__(cls, size):
# I know this usage is discouraged
if hasattr(cls, 'size'):
raise TypeError('cannot resive type')
return type(cls)(f'Array[{size}]', (), {'size': size})
def __new__(cls, *args, **kwargs):
if not hasattr(cls, 'size'):
raise TypeError('cannot instance unsized array')
return super().__new__(cls, *args, **kwargs)
# The rest of the implementation is left
# as an execersize for the reader
def concat(a: Array, b: Array) -> Array:
return Array[a.size + b.size](...)
def make_zeros(i: int) -> Array:
return Array[i](0 for _ in range(i))
# Both of these functions are typed incorrectly.
# Array[i] is not a subtype of Array
# Granted we could change the construction of Array[i]
# to use bases=(cls,) instead of bases=()
```
It also possible to write a function that costructs an entirely new class:
```
def make_new() -> Any :
class A: pass
return A()
```
there is no possible to way to type it more specifically than returning
Any (or object).
Now if libraries are going to be forced to just throw Any everywhere what's
the point?
-- Caleb Donovick
On Thu, Dec 9, 2021 at 3:58 PM Caleb Donovick <donov...@cs.stanford.edu>
wrote:
> First off I love types. They, as you point out, are a great tool for
> finding bugs. However, there are reasons why requiring types would either
> require the use of meaningless types e.g. marking everything as the Any
> type or require python to solve the halting problem.
>
> Consider the following code example:
>
> ```
> class ArrayMeta(type):
>
>
>
> On Thu, Dec 9, 2021 at 12:52 PM deavid <deavidsed...@gmail.com> wrote:
>
>> Hi, I would like to hear the opinion of Python's community on enforcing
>> types in the future for the language. I've been using Python as my main
>> language for everything for around 10 years, until I started moving to Rust
>> 2 years ago; one of the main factors was types.
>>
>> Just before moving to Rust I started to use mypy heavily, which I liked a
>> lot and uncovered tons of potential problems. Now (2 years later), it seems
>> the situation hasn't changed much; I might be wrong, so let me know what
>> improvements you think landed in this area in the last 2-3 years.
>>
>> I feel it's possible this topic might cause a lot of passionate answers,
>> but I just want to hear honest opinions on this.
>>
>> I firmly believe that Python's future would be better if types were
>> enforced by default at "compile time" (whatever this means in Python), with
>> an option/flag to disable this, and integrate MyPy or similar into the
>> interpreter. I'm fully aware that a transition like this would be very hard
>> and long, but I don't think it's impossible.
>>
>> Here's a list of my reasons to think that Python is better if it was
>> typed:
>>
>> 1) On really big codebases and complex projects, it's very easy to lose
>> track of what things do. Types help detecting bugs early. (Ask anyone that
>> has used Rust + Clippy, the amount of errors that are catched is amazing,
>> programs tend to work on the first try)
>> 2) Libraries are currently the top bottleneck for any team to start using
>> MyPy/Pytype. Making types mandatory would ensure all libraries have type
>> support. (If anyone has any other proposal to enforce this, I would like to
>> hear)
>> 3) IDE integration is way simpler and better with types.
>> 4) The interpreter could take further optimizations if it can prove that
>> a function or piece of code is guaranteed to have a limited set of types.
>> This could be used by libraries to have great speed ups that currently are
>> not possible.
>> 5) Static analysis tools could also benefit from types to gain more
>> insight on what the code is trying to do.
>>
>> Of course, types have their own set of drawbacks; for example it could
>> make Python look harder to code for newcomers, or it might get in the way
>> for things like Jupyter notebooks, ML, and similar stuff. Because of this,
>> an escape hatch must always exist. (maybe there are even more problems I am
>> not aware about, I'd love to hear)
>>
>> If it were for me, I would like to have a Python 4 that is exactly a
>> Python 3 but with mypy bundled and strictly enforced by default; with a
>> flag to convert errors into warnings or disable entirely. Then every
>> release, say a Py3.11, would also get a Py4.11-beta (the beta would be to
>> avoid people migrating until it's ready).
>>
>> In this way, for a library to say it has Py4 compatibility it would need
>> to be type-ready. Jupyter notebooks and such would be stuck at Py3, but of
>> course, getting all the releases; and enterprises would be trying to use
>> Py4 whenever it were ready.
>>
>> Typescript is also basically Javascript with types (well, not only that,
>> but anyway) and the result is quite good. In this fashion, another
>> alternative is having a second binary called TPython or MPython, and
>> include it on the regular Python distribution; this would cause less push
>> to go for types, but it could do the trick too.
>>
>> So well, my question here is: why is this not a thing? Has anyone
>> proposed something like this before? I feel I must have missed something
>> important.
>>
>> Thanks,
>> David
>>
>> _______________________________________________
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/QBWYBXYK7NHSLQYWPV6PXAGIR4JB4FWU/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/AWZSA4G34XXDUIKKJZ3J2GXUUMFH6YTN/
Code of Conduct: http://python.org/psf/codeofconduct/
