[Python-ideas] Re: Make for/while loops nameable.
David Mertz writes: > It's cute. Cute is for bunnies and Ghibli anime. :-) > And really quite readable. But it's not writeable. Heh. They look like misplaced apostrophes on my screen in my English buffers. I'd have to go to a 1.3x (maybe 1.5x) font to be sure what I'm looking at. And I'm an Emacs user, so if I wanted to use this feature (I don't though, I think it's ugly), I'd rebind Ctrl- to the superscripts. (I have a little sympathy for non-Emacs users, but really, America, wake up. Characters are good, use more!) So my reaction is the opposite of yours. I prefer the arbitrary tag, where I read for i in iterable as breakable: as "with (for i in iterable) as breakable" in my head. Although I'm basically -0.0 on the whole idea, in my experience anyway it's YAGNI. Steve -- What are those straight lines? "Diversity rules." ___ 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/W6XUXDOMPKNBG3LYXYP5FSLB7ZNWTRQ3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Typed Python execution mode
On Sun, Dec 06, 2020 at 11:25:32AM -, redrad...@gmail.com wrote: > It would be good to have direct support from python to run script in > typed mode or not ... Python can support other type checker with some > option `--type-checker= or ` of module that will > type-check You already have direct support from python to run a type checker: python3 -m script.py Your bash script is an excellent example of the Unix philosophy of chaining together tools to do what you want. Just alias "python" to your bash script. Or use an IDE or editor that supports it as a plugin. All the type-checkers that I listed are big, complex, specialised projects, with their own schedules for new development. Bringing them into the CPython code base would basically kill them. It would dump a huge amount of work on the CPython developers, increase the size of the Python standard installation for everybody whether they want to use a type-checker or not, and for no real benefit. If type-checking was small and easily maintained, like the -b and -W options, then it could be integrated with the interpreter. But it isn't. Keeping them as separate projects is the right strategy. -- Steve ___ 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/3WZUIPIYFF55VXHMEYAECJ63Q7577KZO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Typed Python execution mode
Steven D'Aprano wrote: > On Sun, Dec 06, 2020 at 10:22:53AM -, redrad...@gmail.com wrote: > > It would be nice to have "Typed Python" mode that > > will look like this: > > #!/usr/bin/env bash > > > > set -e > > python -m mypy $1 > > python $1 > > > > What does that mean? Why is it a bash script? It is only example how I use what I call "Typed Python" The same can happens under-hood, python in this "typed" mode can first run type-checker and then if there are no errors run script itself > > It could be achieved by adding special flag like > > -t (typed) > > What does "typed" mode do? > Why would it be "nice"? If all you want is to run mypy, you can run > mypy. Or any alternative type-checker, such as Pytype, Pyright, Pyre or > Jedi: > https://google.github.io/pytype/ > https://github.com/Microsoft/pyright > https://pyre-check.org/ > https://pypi.org/project/jedi > (Jedi does a lot more than just type checking.) It would be good to have direct support from python to run script in typed mode or not ... Python can support other type checker with some option `--type-checker= or ` of module that will type-check ___ 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/7MXWASAAEBCIQ2TIB6HA6ZDAZCIG6X3F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Typed Python execution mode
On Sun, Dec 06, 2020 at 10:22:53AM -, redrad...@gmail.com wrote: > It would be nice to have "Typed Python" mode that will look like this: > > ```bash > #!/usr/bin/env bash > > set -e > python -m mypy $1 > python $1 > ``` What does that mean? Why is it a bash script? > It could be achieved by adding special flag like `-t` (typed) What does "typed" mode do? Why would it be "nice"? If all you want is to run mypy, you can run mypy. Or any alternative type-checker, such as Pytype, Pyright, Pyre or Jedi: https://google.github.io/pytype/ https://github.com/Microsoft/pyright https://pyre-check.org/ https://pypi.org/project/jedi (Jedi does a lot more than just type checking.) -- Steve ___ 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/KELJUEOVPIRCH4C6FHQARAGVXUG3LBID/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Typed Python execution mode
Also if such mode would exsist, it would be nice to have special keywords for such mode like `protocol` Instead of writing: ```python class MathType(Protocol): def reduce(self, *args) -> int: ... ``` it woulb be nicer to have special syntax: ```python-mypy protocol MathType: def reduce(self, *args) -> int: ... def sum(self, *args) -> int: ... ``` It will make code more readable as for me ___ 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/NYVCXKF7Y62F443OXIYMEPF2GZS3NOG6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Typed Python execution mode
It would be nice to have "Typed Python" mode that will look like this: ```bash #!/usr/bin/env bash set -e python -m mypy $1 python $1 ``` https://gist.github.com/redradist/dd7253a55081a4dc13fdf3f1549f43b5 It could be achieved by adding special flag like `-t` (typed) ___ 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/2F2HAI63XHMSIZYJ7CKKRQDVVQQZVRZ4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)
Hello, On Sat, 05 Dec 2020 21:48:53 -0800 Brendan Barnwell wrote: > On 2020-12-05 05:49, Paul Sokolovsky wrote: > > For that I would need to use RPython. I considered that circa 5 > > years ago, and of course explored it. I "liked" what I saw, sure. > > But I "wasn't happy" with what I saw. > > > > There seem to be hints that I may be making this "strict mode" > > thingy because I wasn't aware of PyPy/RPython. But actually it's > > the opposite: being aware of RPython and knowing enough about it is > > what causes me to explore a different direction. > > The main thing I don't understand is what you expect to be > the result of this proposal; or, in other words, what you expect > anyone besides you to do with your idea. You say we shouldn't think > in terms of CPython, that this is separate from CPython. You say > you're also not interested in existing alternative Pythons or > quasi-Pythons like Cython. So what is it you want? Some people here > to say "Yes, I'll join you and work on a totally new restricted > version of Python from scratch just to see what happens"? Roughly, I expect it to be about the same as for e.g. https://www.python.org/dev/peps/pep-0509/ . The background motivation of the two is the same: look for ways to optimize name lookups. My however reaches "above surface" and requires some restructuring on the side of the Python programs, so potentially "affects" (as in: can elicit response) from wider audience than PEP509, which is clearly targeted at Python internals enthusiasts. Generally, as any human being, I'm interested to communicate, and potentially, even cooperate, with other alike-minded human beings. I don't pledge for the latter. I will understand even if nobody is truly interested in my idea. But it's my strong belief that there should be more people interested in this stuff (not just my particular proposal, but stuff related to conceptual, "meta", and on the hand of spectrum, implementation, matters in Python). So, I post to whoever may be lurking around, or who wanted to look at that stuff for a long, and bringing it up may be the "last straw" for them to actually dig into it. Receiving criticism from not-really-interested people is also helpful, but such a discussion quickly derails, as the experience shows. So, coming to specifics, some points which *could* be discussed: 1. The proposal makes claims that some of the restrictions imposed are already oftentimes imposed by codebases caring about their hygiene. It would be helpful to get (detailed enough, not low-effort) aye's or nay's. 2. For restrictions where the proposal goes beyond something which can be called "existing practices", how harsh are those, and what can be done about them? There's literally one (YMMV) "grave" thing in the proposal - prohibition of runtime imports. It's also outlined how to address them. So, if we get past Chris Angelico's "no no no no" for a curious walk, what do we see? As an example of possible p.1 discussion point, a case of global variable definition/declaration matter was brought up in another message. So, do you define your global variables at the module's top level? How do you feel about it? Is it: a) Are you nuts? How else can it be done? b) I do it. c) I don't do it. d) Defining the global variables at the global scope? Only over my dead body! -- Best regards, Paul mailto:pmis...@gmail.com ___ 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/LSM4YQMDTGZBJ62ABPQ7DMTSUDPBOEEA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)
Hello, On Wed, 2 Dec 2020 21:15:22 +1100 Steven D'Aprano wrote: [First part was answered previously.] > > > Is monkey-patching disallowed because `mod.func1` is defined as a > > > constant? > > > > What "disallowed" do you mean? The example above clearly says > > "Leads to a warning". At "run-time" (i.e. eventually, after you've > > done the monkey-patching), it's disallowed, yes. > > What disallowed do I mean? Exactly the same disallowed you just > agreed with. What's allowed and what's disallowed depends on whether a program just "loads" or "actually starts to run". While it loads, it can do all the tricks Python can do now. When it starts to run, then the actual "strict" restrictions are applied. That's the crucial part of the proposal, required to understand other aspects of the proposal. > > > Or are all functions automatically considered to be > > > constants? > > > > That's the case, right. > > Okay, so all functions are automatically constants. Yes, that's the whole idea. [] > [...] > > > Occasionally I find that decorator syntax is not sufficient, and > > > I've used the explicit "define-decorate-replace" form. That won't > > > work either. > > > > You'll get a warning, and if you're smarter than the strict mode in > > that case, you can disable it (in the same sense that you can > > disable any warning in Python). > > So "strict mode" isn't actually strict, it's just a built-in linter. It's strict. And it has many (more than one for sure) uses. One of the uses is to improve code structure (or understanding of it) of the existing codebases. > -- > Steve -- Best regards, Paul mailto:pmis...@gmail.com ___ 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/KDHWSDFD2YNSHB76TWUJJ6TC6LMY4MOZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: [RFC] "Strict execution mode" (TL;DR version)
Hello, (As the thread continues, and goes from "why did you do that" to actual technical details/implication, I have little choice (if to maintain coherent discussion) but go thru existing posts looking into technical aspects of the proposal.) On Wed, 2 Dec 2020 10:42:25 +1100 Steven D'Aprano wrote: [First part was answered previously.] > > # Way to define a constant. > > my_cnst: const = 1 > > That clashes with type annotations. "const" is a *type annotation*. > Constantness is not a type of the > value, it's a statement about the name binding. Your interpretation, my interpretation: 'const is a type annotation like any other'. This poses a question of type annotation composability. Outside the scope of this discussion (a solution exists). All this was mentioned already in previous discussions. [] > It would be better to introduce an independent syntax for constants. > Let's say `const`: > > const x: int = some_expression Yes, and that was mentioned already. But we'll do that only when we play enough with "const" as an annotation and see that it's so useful that is worth being promoted to a keyword. (I'm sure we'll end up there; but the current state is that not everyone is convinced of useful of "const" at all. So, no hurry, step by step.) [] > > # Leads to a warning: replacing (monkey-patching) a constant slot. > > my_cnst: const = 2 > > A warning? What's the use of that? A use of warning in programming language? A generic question outside the scope of the current discussion. > Are your constants *actually constant* or are they just advisory? I already answered how my proposal works in this thread. And it's fully described in the proposal. So, please refer to it. > If > they're just advisory, then we might as well stick with the > convention to use UPPERCASE names and use a linter that warns if you > re-bind a "constant". Maybe you can stick with UPPERCASE names. I'd prefer something more generic. > If you can rebind constants by just suppressing or ignoring the > warning, then people will rebind constants. If they no what they're doing, let them do that (while they can, until the "run-time" phase starts.) > Relevant: > > Sometimes I run GUI applications from the command line. Invariably > they generate a flood of runtime warnings. Clearly developers are > paying no attention to warnings. Outside the scope of the discussion. E.g. C compilers have -Werror for that. > > def fun(): > > # Imports are not allowed at run-time > > import mod2 > > # But you can re-import module previously imported at > > import-time. import mod > > That seems like a pointless complication. > > If mod is already imported, why would I need to import it again from > inside the function? You missed the point, it's the opposite situation: "mod" is imported inside the function to start with. The rest of the discussion is how to accommodate that in the strict mode, given that "on the surface", that's prohibited in the strict mode. [] > > # RuntimeError > > my_cnst = 3 > > `my_cnst` is inside a function, so it should create a local variable, > not attempt to rebind a global constant. Good catch. "global my_cnst" was clearly missing before that. Fixed in https://github.com/pycopy/PycoEPs/blob/master/StrictModeTLDR.md > > # RuntimeError > > mod.func2 = lambda x: 1 > > Yes you already make it clear that rebinding functions is not allowed. No, you missed the critical part of the proposal: that there're 2 phases of the execution of a Python program: "import-time" and "run-time". Things at the global scope of that sample show rules for import-time (lax, even const's can be redefined), while code inside function executes at "run-time" (strict in all its full glory). The information about 2 distinct execution phases is presented clearly even in the TLDR version. Thanks for missing it. > > global glb1, new > > # RuntimeError: Cannot create new global nameslots at runtime. > > new = 1 > > # Nor can delete existing > > del glb1 > > I know "global variables considered harmful", but this looks to me > like punishing users of globals for being bad by restricting what > they can do to make their use of globals *worse* rather than better. They won't be punished much more than the already existing "considered harmful" background establishes ;-). > > - all globals must be pre-declared and initialised before use; Already the best practice. > - functions cannot clean-up after themselves by deleting their > unneeded globals. Modules can. Functions? Never saw that, and that's clearly "not Pythonic". (But one of "dirty Python tricks".) [] > > # Cheats don't work > > globals()["new"] = 1 > > That seems like it will probably break a lot of code, assuming you > can even enforce it. The code which will be broken - it won't be able to run in the strict mode. It either will need to be fixed to "not do dirty Python tricks", or be
