Mailman 3 December 2021 - Python-ideas

PEP 671 (late-bound arg defaults), next round of discussion!
by Chris Angelico July 23, 2023

July 23, 2023

I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/ with some additional information about the reference implementation, and some clarifications elsewhere. *PEP 671: Syntax for late-bound function argument defaults* Questions, for you all: 1) If this feature existed in Python 3.11 exactly as described, would you use it? 2) Independently: Is the syntactic distinction between "=" and "=>" a cognitive burden? (It's absolutely valid to say "yes" and "yes", and feel free to … [View More]

43 364

zip(x, y, z, strict=True)
by Ram Rachum Dec. 1, 2022

Dec. 1, 2022

Here's something that would have saved me some debugging yesterday: >>> zipped = zip(x, y, z, strict=True) I suggest that `strict=True` would ensure that all the iterables have been exhausted, raising an exception otherwise. This is useful in cases where you're assuming that the iterables all have the same lengths. When your assumption is wrong, you currently just get a shorter result, and it could take you a while to figure out why it's happening. What do you think?

27 179

disallow assignment to unknown ssl.SSLContext attributes
by Thomas Grainger June 10, 2022

June 10, 2022

I was debugging some code that was using TLSv1.2 when I expected it to only support TLSv1.3, I tracked it down to a call to: context.miunimum_version = ssl.TLSVersion.TLSv1_3 it should have been: context.minimum_version = ssl.TLSVersion.TLSv1_3 I'd like invalid attribute assignment to be prevented at runtime

13 32

Bringing the print statement back
by Guido van Rossum March 2, 2022

March 2, 2022

In Python 3.10 we will no longer be burdened by the old parser (though 3rd party tooling needs to catch up). One thing that the PEG parser makes possible in about 20 lines of code is something not entirely different from the old print statement. I have a prototype: Python 3.10.0a0 (heads/print-statement-dirty:5ed19fcc1a, Jun 9 2020, 16:31:17) [Clang 11.0.0 (clang-1100.0.33.8)] on darwin Type "help", "copyright", "credits" or "license" for more information. Cannot read termcap database; using … [View More]dumb terminal settings. >>> print 2+2 4 >>> print "hello world" hello world >>> print "hello", input("Name:") Name:Guido hello Guido >>> print 1, 2, 3, sep=", " 1, 2, 3 >>> But wait, there's more! The same syntax will make it possible to call *any* function: >>> len "abc" 3 >>> Or any method: >>> import sys >>> sys.getrefcount "abc" 24 >>> Really, *any* method: >>> class C: ... def foo(self, arg): print arg ... >>> C().foo 2+2 4 >>> There are downsides too, though. For example, you can't call a method without arguments: >>> print <built-in function print> >>> Worse, the first argument cannot start with a parenthesis or bracket: >>> print (1, 2, 3) 1 2 3 >>> C().foo (1, 2, 3) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: C.foo() takes 2 positional arguments but 4 were given >>> print (2+2), 42 4 (None, 42) >>> C().foo [0] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'method' object is not subscriptable >>> No, it's not April 1st. I am seriously proposing this (but I'll withdraw it if the response is a resounding "boo, hiss"). After all, we currently have a bunch of complexity in the parser just to give a helpful error message to people used to Python 2's print statement: >>> print 1, 2, 3 File "<stdin>", line 1 print 1, 2, 3 ^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1, 2, 3)? >>> And IIRC there have been a number of aborted attempts at syntactic hacks to allow people to call functions (like print) without parentheses, although (I think) none of them made it into a PEP. The PEG parser makes this much simpler, because it can simply backtrack -- by placing the grammar rule for this syntax (tentatively called "call statement") last in the list of alternatives for "small statement" we ensure that everything that's a valid expression statement (including print() calls) is still an expression statement with exactly the same meaning, while still allowing parameter-less function calls, without lexical hacks. (There is no code in my prototype that checks for a space after 'print' -- it just checks that there's a name, number or string following a name, which is never legal syntax.) One possible extension I didn't pursue (yet -- dare me!) is to allow parameter-less calls inside other expressions. For example, my prototype does not support things like this: >>> a = (len "abc") File "<stdin>", line 1 a = (len "abc") ^ SyntaxError: invalid syntax >>> I think that strikes a reasonable balance between usability and reduced detection of common errors. I could also dial it back a bit, e.g. maybe it's too much to allow 'C().foo x' and we should only allow dotted names (sufficient to access functions in imported modules and method calls on variables). Or maybe we should only allow simple names (allowing 'len x' but disallowing 'sys.getrefcount x'. Or maybe we should really only bring back print statements. I believe there are some other languages that support a similar grammar (Ruby? R? Raku?) but I haven't investigated. Thoughts? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…> [View Less]

42 66

Adding a thin wrapper class around the functions in stdlib.heapq
by bunslow Feb. 18, 2022

Feb. 18, 2022

Nothing so bombastic this time. The heapq functions are basically all named "heapsomething", and basically all take a "heap" for their first argument, with supplementary args coming after. It's a textbook example of the (hypothetical) Object Oriented Manifesto™ where defining a class increases type safety and programmers' conceptual clarity. There're practically no drawbacks, and the code to be added would be very simple. Updating the tests and docs would probably be harder. In pure Python, … [View More]

17 32

Allow syntax "func(arg=x if condition)"
by Peter O'Connor Jan. 19, 2022

Jan. 19, 2022

I often find that python lacks a nice way to say "only pass an argument under this condition". (See previous python-list email in "Idea: Deferred Default Arguments?") Example 1: Defining a list with conditional elements include_bd = True current_way = ['a'] + (['b'] if include_bd else [])+['c']+(['d'] if include_bd else []) new_way = ['a', 'b' if include_bd, 'c', 'd' if include_bd] also_new_way = list('a', 'b' if include_bd, 'c', 'd' if include_bd) Example 2: Deferring to … [View More]

6 9

Add a decorators called @staticproperty
by me＠chenjt.com Jan. 6, 2022

Jan. 6, 2022

In the following situations: class Data(object): @staticmethod @property def imagesTotal(): return 10 print(Data.imagesTotal) The "print(Data.imagesTotal)" can't print "10", it print "<property object at 0x...>". It might be a good idea to use "@staticproperty" to solve this problem. "@staticproperty" is a decorators, it mix the @staticmethod and @property. Then the static property has getter and setter.

9 12

Enhancing iterator objects with map, filter, reduce methods
by Remy Dec. 30, 2021

Dec. 30, 2021

Hi, I'd like to revive this thread after what seemed like a decade and see where this might take us 😃 I like this idea that the OP suggested but I'd like to extend this to all iterator objects (range_iterators, list_iterators etc.). 📌Idea Iterables to expose the .__iter__() method in iterable as .iter(). Iterators to implement 'transformational' functions like map, filter, flat_map, 'reductional' functions like reduce, sum, join, and 'evaluate' functions like to_list and to_set. ( [1,2,… [View More]

15 94

Add a `count` argument to `list.remove`
by Jeremiah Vivian Dec. 26, 2021

Dec. 26, 2021

I expect some sort of "there's no benefit in this, just write the current implementation", indirectly or directly. Currently, this is the way to remove `num` occurrences of an element from a list: > idx = 0 > while idx < len(the_list) and num: > if the_list[idx] == element_to_remove: > del the_list[idx] > num -= 1 > else: > idx += 1 With a `count` argument to `list.remove`, this is how it would be done: > the_list.remove(… [View More]

6 12

Add set.intersects method
by Stefan Pochmann Dec. 25, 2021

Dec. 25, 2021

Multiple times I wished that sets had an `intersects` method. Simply the negation of the `set.isdisjoint` method. Sometimes I can write `not a.isdisjoint(b)`, but: 1) Together with the "dis", that's a double negation. Saying "a.intersects(b)" is the correct and much clearer way to express my intent. 2) I sometimes want to pass a set's bound method, for example as the first argument to `filter`, and then I can't pass that `not` along with it. The isdisjoint method is great. Takes any … [View More]

2 1

set arbitrary hash random seed to ensure reproducible results
by Hao Hu Dec. 23, 2021

Dec. 23, 2021

Hi, I am wondering if it would be good to add an additional keyword `seed` to the builtin function *hash* to allow us to set arbitrary seed to ensure reproducible results. As far as I know, there exists already the environment variable PYTHONHASHSEED that allows us to set arbitrary seed or disable the seed globally for the python interpreter. However, it looks like that it would be too bold to use that environment variable to change the default behavior because the random seed generation helps … [View More]

4 13

Re: Applications user/system directories functions
by Christopher Barker Dec. 16, 2021

Dec. 16, 2021

On Wed, Dec 15, 2021 at 4:29 PM Christopher Barker <pythonchb(a)gmail.com> wrote: > On Wed, Dec 15, 2021 at 2:57 PM Neil Girdhar <mistersheik(a)gmail.com> > wrote: > >> +1 for appdirs. It's a shame that more projects don't yet use it. >> > I agree -- I've wanted something like that for years in the stdlib. wxPython has wx.StandardPaths -- and it's really handy. But a wrapper around a C++ version, so not useful outside of wx. -CHB > >> On … [View More]Wednesday, December 15, 2021 at 9:03:07 AM UTC-5 Matt del Valle wrote: >> >>> There is appdirs which does precisely what you're looking for: >>> >>> https://pypi.org/project/appdirs/ >>> >>> That said, it does seem to be a core bit of functionality that would be >>> nice to have in the os and pathlib modules without needing an external >>> dependency. I'm not going to weigh in on the pros/cons of adding it to the >>> stdlib, I'll leave that to others who I'm sure will have strong opinions on >>> the matter :) >>> >>> On Wed, Dec 15, 2021 at 1:47 PM JGoutin via Python-ideas < >>> python...(a)python.org> wrote: >>> >>>> Hello, >>>> >>>> The idea is to add 3 functions to get "config", "data" and "cache" >>>> directories that are commonly used to store application files in user home >>>> / system. >>>> >>>> This look very straightforward to get theses directories path, but in >>>> practices it depends on many factors like OS, environnement variables, user >>>> or system dir. >>>> >>>> For instance, with the "config" directory: >>>> * Linux, user: os.path.join(os.getenv("XDG_CONFIG_HOME", >>>> os.path.expanduser("~/.config")), app_name) >>>> * Linux, system: os.path.join("/etc", app_name) >>>> * Windows, user: os.path.join(os.path.expandvars("%APPDATA%"), app_name) >>>> * Windows, system: >>>> os.path.join(os.path.expandvars("%CSIDL_COMMON_APPDATA%"), app_name) >>>> >>>> For linux, the full spec is here: >>>> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html >>>> >>>> I see many applications that just use "~/.app_name" to not have to >>>> handle theses cases. >>>> >>>> >>>> The functions prototypes may look like and may be added to "shutil" (or >>>> "os.path" ?): >>>> >>>> def getcachedir(app_name: str=None, system: bool=False): >>>> >>>> With >>>> * app_name: The application name >>>> * system: If the required directory is the systemd directory or user >>>> direcotry. >>>> >>>> >>>> This may also be implemented as an external library, but I am not sure >>>> I would like add add a dependency to my projects "just for this". >>>> >>>> >>>> I can implement this if people are interested with this feature. >>>> _______________________________________________ >>>> Python-ideas mailing list -- python...(a)python.org >>>> To unsubscribe send an email to python-id...(a)python.org >>>> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >>>> Message archived at >>>> https://mail.python.org/archives/list/python...@python.org/message/MHEWO4U6… >>>> <https://mail.python.org/archives/list/python-ideas@python.org/message/MHEWO…> >>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>> >>> _______________________________________________ >> Python-ideas mailing list -- python-ideas(a)python.org >> To unsubscribe send an email to python-ideas-leave(a)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/IV3W2… >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Christopher Barker, PhD (Chris) > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython [View Less]

2 3

Applications user/system directories functions
by JGoutin Dec. 15, 2021

Dec. 15, 2021

Hello, The idea is to add 3 functions to get "config", "data" and "cache" directories that are commonly used to store application files in user home / system. This look very straightforward to get theses directories path, but in practices it depends on many factors like OS, environnement variables, user or system dir. For instance, with the "config" directory: * Linux, user: os.path.join(os.getenv("XDG_CONFIG_HOME", os.path.expanduser("~/.config")), app_name) * Linux, system: os.path.join("/… [View More]

6 6

Runtime-accessible attribute docstrings – take 2
by tmkehrenberg＠gmail.com Dec. 15, 2021

Dec. 15, 2021

A few weeks ago, I proposed on this mailing list to write docstrings for class attributes like this: @dataclass class A: x: int """Docstring for x.""" The main criticism, I think, was that it is weird to have the docstring *below* the attribute. To solve this problem, I propose to introduce a new kind of string: a d-string ('d' for 'docstring'; alternatively also 'v' because it looks a bit like a downward arrow, or 'a' for 'attribute docstring'). A d-string is a normal string, except … [View More]

11 69

List comprehension operators
by a.kolpakov2010＠mail.ru Dec. 15, 2021

Dec. 15, 2021

It would be awesome to be able to create a list with just: li = [1—100] or li = [1 .. 100]

5 4

Re: List comprehension operators
by Matt D Dec. 14, 2021

Dec. 14, 2021

Seems like a lot of work to just make list(range(1,100)) Insignificantly easier to write

1 0

Python standard library TOML module
by Martin Reboredo Dec. 13, 2021

Dec. 13, 2021

Title: Python standard library TOML module Hello everyone, ITT I propose the idea of a TOML module in the standard library for general TOML operations. The main motivator of this is the growing adoption of PEP 517. Recently I've been following its developments and I've noticed some situations that could make things a bit harder at the moment of working with build systems based on it. Namely I saw that dependency problems like cycles or complicated dependency graphs. For instance, we have a … [View More]

7 6

Re: PEP 671 (late-bound arg defaults), next round of discussion
by Jon Kiparsky Dec. 13, 2021

Dec. 13, 2021

I've been holding off commenting on this because frankly y'all talk a hell of a lot and I'm still about five days back trying to keep up with all the back-and-forth. So probably some of this repeats something that's been said and I apologize for that, but I did want to put my two cents' worth in. > 1) If this feature existed in python as described, would you use it? I wouldn't want to say no, in an absolute way, but right now I don't see any place where I'd want to use it in preference to … [View More]

1 0

Re: PEP 671 (late-bound arg defaults), next round of discussion!
by Christopher Barker Dec. 12, 2021

Dec. 12, 2021

On Fri, Dec 10, 2021 at 7:54 PM Eric V. Smith <eric(a)trueblade.com> wrote: > Not sure if you meant this to go to the list or not. > I did — ( I know it seems to be the consensus, but I really think respond to list should be the default…) Moving on… On 12/10/2021 7:50 PM, Christopher Barker wrote: > > Thanks Eric, this is a great example, thanks. > > It does raise some questions. Though. > > If we could use any expression as a deferred expression, then we still … [View More]> have the two key questions: > > When does it get evaluated, and what namespaces does it use? > > I agree those are good questions. I think, like PEP 671, it would get > evaluated at the start of the function (in this case, __init__). It's > easier for dataclasses, because I could just force the evaluation there. > But for normal function arguments, maybe we'd have to say that before the > function starts executing, any arguments which are deferred objects > automatically are evaluated. And I think the namespace would be where it's > defined. > Ahh, then that would make them less useful for default parameters— even for the dataclass case. It would work fine if you used only builtins (or literals) but that’s about it. So Chris’ canonical example of n => len(input_list) wouldn’t work. Which is why I think that if there were a general purpose deferred object, we’d need special syntax or rules for when used as late-bound defaults. I'll admit I haven't thought all of this through in enough detail to > implement it. I'm just trying to point out that we could use the general > concept in other places. > Which is exactly what I asked for — thanks! I think this is a really interesting use case, not so much as it’s a general purpose deferred object, but because it’s about how to do/use late-bound defaults in meta programming. > def fun(n): > return `len(n)` > > @dataclasses.dataclass > class A: > length: n = fun() > > What would that put in the signature? What namespace would the express e > evaluated in? > > I think it should be evaluated in the context of "fun". Clearly it would > need to create a closure. > Which would be a potentially useful deferred object, but not a good one for late-bound defaults. Here’s a new (not well thought out) idea: @dataclasses.dataclass class A: Input_list: list length: int => len(input_list) So length gets set to a “late bound default expression” that Is an actual value. It would have to store the expression itself, probably as a string, and it would get evaluated in the namespace of the function, when the function was called. So the generated __init__ would be the same as: def __init__(self, input_list, length=>len(input_list): And you could also do: get_length => len(input_list) @dataclasses.dataclass class A: Input_list: list length: int = get_length Not that that would be a good idea. This suggestion would mean that “=>” would create a deferred expression, but it would not be a general purpose one. Though maybe there could be a way to evaluate it in a more general way, kind of like eval — where you can control the namespaces used. I guess what I’m suggesting is that we could create a very specific kind of deferred object, and in the future expand it to more general use. Rather than the general case rendering the late-bound default concept. -CHB > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython [View Less]

4 3

inline Python functions and methods
by TobiasHT Dec. 12, 2021

Dec. 12, 2021

The Python community has a 5 year plan to push the limit of speed in Python. One of the things that reduces Python execution speed is calling methods or functions that are not in the nearest scope. My suggestion is to introduce inline functions just as they are in C. They can be defined as global functions or class methods but are created in the scope of the function that is calling it at parsetime. I also don’t think it’ll be hard to adapt. inline functions might look something like: inline … [View More]

3 7

Make it easier to set function globals
by Steven D'Aprano Dec. 12, 2021

Dec. 12, 2021

TL;DR: it is hard, but not impossible, to set function `__globals__` dunder to a ChainMap. Let's make it easier! Background: (1) Comprehensions skip class scope, leading to bug reports like these: https://bugs.python.org/issue3692 https://bugs.python.org/issue26951 Note Guido's comment in the first: "perhaps __globals__ could be set to a chainmap referencing the class dict and the globals?" (2) I want to experiment with namespaces, similar to the C++ feature. The details don't matter,… [View More]

2 1

Re: PEP 671 (late-bound arg defaults), next round of discussion!
by Christopher Barker Dec. 11, 2021

Dec. 11, 2021

Sorry, accidentally off-list. Here it is again. On Fri, Dec 10, 2021 at 4:50 PM Christopher Barker <pythonchb(a)gmail.com> wrote: > Thanks Eric, this is a great example, thanks. > > It does raise some questions. Though. > > If we could use any expression as a deferred expression, then we still > have the two key questions: > > When does it get evaluated, and what namespaces does it use? > > @dataclasses.dataclass >> class A: >> my_list: list … [View More]= dataclasses.field(default_factory=list) >> >> What I'd like to be able to say: >> >> @dataclasses.dataclass >> class A: >> my_list: list = `[]` >> >> I think in the data classes case, you could clearly define both of those. > But in the general case? > > def fun(n): > return `len(n)` > > @dataclasses.dataclass > class A: > length: n = fun() > > What would that put in the signature? What namespace would the express e > evaluated in? > > Yes, that is completely contrived, but it does bring up the complications > of a “general” solution. > > Maybe we could solve the dataclass problem with late bound class > attributes: > > @dataclasses.dataclass > class A: > length: n => len(n) > > Though I suppose that would still get evaluated before the dataclass > decorator would see it :-( > > Side note: I wonder if dataclasses could be a bit smarter for the common. > case: if the type is a callable, and the value is a particular Sentinel, > the. Call it to get the default: > > @dataclasses.dataclass > class A: > my_list: list = dataclasses.Empty > > That would work for most of the cases where I need to use field explicitly. > > - CHB > > > > > In the class A, before @dataclass is called, I want A.my_list to be a >> "deferred object" that I could then use when @dataclass is generating >> __init__(). Exactly how and when the "deferred object" would get evaluated >> is debatable, but not so important for the sake of this discussion. Suffice >> it to say that it would either be explicitly or implicitly evaluated at the >> start of __init__. >> >> I think you can see that this would benefit from similar functionality to >> late-bound parameters, and that if we had this more general mechanism that >> late-bound parameters could use the same underlying mechanism. >> >> And in case I wasn't clear: to get the late-bound parameter functionality >> using this syntax, you'd use: >> >> def foo(my_list = `[]`): >> >> That's why I think we should have a larger concept that just late-bound >> parameters: I think there's a general concept here that can be extended >> beyond parameters. And that's why I thing not restricting it to a >> function-definition-only syntax is important: we should produce a syntax >> that can be used in more places than just functions. This is why I think we >> need to decide on this larger scope before accepting the narrow >> function-definition-only syntax: if we decide to add "deferred objects" >> later, we'd have two ways to specify late-bound parameters [0]. >> >> Eric >> >> [0]: Or arguments, I can never remember which is which: someone needs to >> invent a memorable mnemonic device. >> >> Had these "deferred objects" existed when I designed dataclasses, I would >> have used them instead of the clunky default_factory. PEP 671 does not help >> with this use case, where a late-bound parameter isn't specified in a >> function definition. I need the late-bound parameter to be stored in an >> object I can refer to later. >> >> Eric >> >> _______________________________________________ >> Python-ideas mailing list -- python-ideas(a)python.org >> To unsubscribe send an email to python-ideas-leave(a)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/T62V6… >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > Christopher Barker, PhD (Chris) > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython [View Less]

2 1

Should Python enforce Type-checking in the future?
by deavid Dec. 10, 2021

Dec. 10, 2021

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 … [View More]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 [View Less]

9 11

Re: Should Python enforce Type-checking in the future?
by Steven D'Aprano Dec. 10, 2021

Dec. 10, 2021

On Fri, Dec 10, 2021 at 08:32:27AM -0800, Christopher Barker wrote: > On Fri, Dec 10, 2021 at 4:07 AM Steven D'Aprano <steve(a)pearwood.info> wrote: > > > > 1) On really big codebases and complex projects, it's very easy to lose > > > track of what things do. Types help detecting bugs early. > > > > Static types help detecting *some* kinds of bugs early. > > > Exactly. I’ve been advocating for Python for decades — and I think that > … [View More]

5 4

Re: [issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
by Steven D'Aprano Dec. 10, 2021

Dec. 10, 2021

On Fri, Dec 10, 2021 at 12:03:15AM +0000, Gabriele N Tornetta wrote: > class Side(object): > def __getattribute__(self, name): > ValueError(name) You forgot to actually *raise* the exception. That will just instantiate the ValueError instance, and then immediately garbage collect it. In any case, type() and isinsance() do not work the same way. type() does not inspect the `__class__` attribute.

1 0