[Python-ideas] Re: PEP's shouldn't require a sponsor
On Thu, Jul 25, 2019 at 9:32 AM Batuhan Taskaya wrote: > What i see is when you post the ideas channel and it is something that > doesnt change much on the frontside people dont care. And when people dont > care, they forgot. PEP reviewing process is way better than posting to > ideas and try to convince people. > >> >> You are proposing a change to the content of PEP 1 ( https://www.python.org/dev/peps/pep-0001/). If you look at the history of that PEP, you will see that its content has changed over time. It used to be that non-core developers could write PEPs that were accepted: I know this very well since I've never been a core developer and have written a PEP that was accepted (https://www.python.org/dev/peps/pep-3111/) some thirteen years ago. This was then; now, I personally do see the need to have PEPs sponsored by core developers - you obviously have a different opinion. At the very least, you should go over the history of PEP 1, and find out the discussions (on python-ideas and python-dev, as well as possibly other sources) that led to the change which you wish to revert. You might want to provide a rationale as to what such a reversion is warranted, including a summary of the arguments that led to the current situation (sponsorship required) and how the entire process would be improved by not requiring this sponsorship. Following the practice for discussions that lead to PEPs, you should also include the arguments offered by others on this list who do not appear to support such a change and explain why and how the alternative you propose is better. I assume that your underlying motivation is that you have in mind some changes to the Python language or its libraries, and that you would wish to submit a PEP without requiring a sponsor. Since core developers are responsible for implementing and supporting such changes, your suggestion to change PEP 1 should include an explanation as to how core developers would benefit from the change you propose and how allowing anyone, no matter how familiar they are with the Python code and standard library, to be able to submit PEP that would require the core developers to spend valuable time considering them seriously without the ideas included in the PEP having been discussed more casually on some public forums such as this one. André Roberge ___ 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/HOSFLAOUA4PRO6YC7ISXJKTN5Y2C7LZF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?
On Wed, Jun 12, 2019 at 7:56 PM Yanghao Hua wrote: > On Wed, Jun 12, 2019 at 11:27 PM Chris Angelico wrote: > > Yes, you would need some sort of syntactic parser. There are a couple > > of ways to go about it. One is to make use of Python's own tools, like > > the ast module; the other is to mandate that your specific syntax be > > "tidier" than the rest of the Python code, which would permit you to > > use a more naive and simplistic parser (even a regex). > > Yep ... I just tried to use MacroPy3 to handle this but failed, seems > MacroPy3 does expect valid Python syntax in the first place for > anything else to happen. I also tried the raw ast module which seems > also the case. So it means if one want to use python ast module to > parse user input, the user input has to be valid python syntax (e.g. > no <==) at the first place. Seems this is a chicken-egg problem. > As I mentioned very early on in this seemingly-never-ending discussion, there is a way to do things similar to what you want to do, by doing transformations on the source code prior to execution (prior to constructing an AST). Here's the link to the set of examples which I have done as demonstrations of this technique: https://github.com/aroberge/experimental/tree/master/experimental/transformers André Roberge > ___ > 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/Z3FVILBIN7NZGDZP2ROUMEOPT3SSKWWB/ > 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/XQAU4A4QTDBD5FFEGRTM64SOIKVWIUAJ/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?
On Wed, May 22, 2019 at 9:57 AM Yanghao Hua wrote: > > > And this is something I have in mind for a Python DSL for HDL: > Perhaps you might be able to do what you want using an import hook. I have done some experiments with introducing some new operators that way: https://github.com/aroberge/experimental/blob/master/experimental/transformers/readme.md > > > > > > def combinational_or_sequential_logic(in: Signal, out: Signal): > > > local_signal = Signal() > > > local_signal <- in << 10 # read as: local_signal <- (in << 10) > > > out <- local_signal + 5 # read as out <- (local_signal + 5) > > > # new_signal <- 3 will raise exception, as <- does not create new > object. > > > > > > And the arrow operators could also be used for bulk connections of a > > > chain of hardware modules like this: > > > module_instance1 -> instance2 -> instance3->... to naturally form a > > > hardware pipeline ... this looks very elegant. > > > > > > I think the largest problem with this idea has to do with where the new > > operator would be defined, and then where would it be used. At first > > blush, it seems like you'd want to define the operator in one file > > (let's call it hdl.py), then import that into another file (circuit.py), > > which could use the new operator. > > > > But Python compiles circuit.py without reading hdl.py at all. It merely > > compiles "import hdl" to some bytecode to import hdl.py. So how would > > the operator's definition be used during the compilation of circuit.py? > > The compiler has no idea that new operators have been defined. > > The scala implementation purely relies on the object to provide the > operator definition, e.g. "a b c" would be interpreted as "a.b(c)". > With the current implementation of the arrow operators I have, "<-" > and "->" are part of of the basic python operators pretty much like > "+" and "-". Where it relies on the object to provide the special > method "__arrow__". so, this operation could be defined in a separate > file with a base class e.g. Signal or Module, where other python > module has to import it to use it or inherit it. > > In this case, essentially when python compiler reads circuit.py, it > reads hdl.py too as it is imported in circuit.py. This is exactly how > __matmult__ special method works too in PEP465. > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Enabling / disabling optional type hinting
On Sat, Mar 23, 2019 at 6:26 PM Ned Batchelder wrote: > On 3/23/19 1:37 PM, Gregory P. Smith wrote: > > Sure, someone is going to typo and omit the = from a := assignment in > > 3.8 but the walrus is unlikely to be used outside of an conditional or > > loop test context so this seems like a made up problem. > My original message was referring to someone writing ":" instead of "=" by mistake -- nothing to do with the walrus assignment, but rather using the same notation to assign a value to a key as they would when defining a dict. André Roberge > > Walruses aren't allowed as a top-level expression anyway: > > Python 3.8.0a2 (default, Feb 25 2019, 17:15:37) > [Clang 10.0.0 (clang-1000.10.44.4)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> d["answer"] := 42 >File "", line 1 > d["answer"] := 42 > ^ > SyntaxError: invalid syntax > > > --Ned. > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Enabling / disabling optional type hinting
Consider the following example [1]:
Python 3.7.0 (v3.7.0:1bf9cc5093...
>>> d = {
... "injury": "flesh wound"
... }
>>> d["answer"]: 42
>>> if "answer" in d:
... print("Don't panic!")
... else:
... print("Sorry, I can't help you.")
...
Sorry, I can't help you.
= =
No SyntaxError raised (which would have been the case before version 3.5?)
and yet what could be a very unexpected result occurred.
Of course, the problem is with the line
d["answer"]: 42
which is not an assignment but is an "optional" type hint.
I think it would be very useful to have a way to turn off completely type
hinting and flag any use of code like the above as a SyntaxError.
My preference would be if type hinting would be something that is enabled
per file with a top-level comment pragma, something like
# type: enable
Failing that, having a to-level comment pragma like
# type: disable
might be acceptable as it would not require any change to any existing
file. However, the other option would be more inline with type hinting
being "optional" and something that should not trip beginners who are not
aware of its existence.
André Roberge
[1] This example was inspired by a blog post I read yesterday and which I
cannot find; I apologize to the author of that blog post.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP: Dict addition and subtraction
On Fri, Mar 15, 2019 at 11:42 AM Steven D'Aprano wrote: > [snip] > > I still remember being told in no uncertain terms by the core devs that > adding a clear() method to lists was a waste of time because there was > already a perfectly good way to spell it with slicing. And then ABCs > came along and now lists have a clear method. So opinions change too. > > I agree with the opinions expressed in the (partially) quoted message but I don't think that this is how this particular change happened. https://mail.python.org/pipermail/python-ideas/2009-April/003897.html ;-) ;-) André Roberge ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Make Python 2.7’s online docs optionally redirect to Python 3 online docs
On Thu, Mar 7, 2019 at 9:10 AM James Lu wrote: > Rationale: When I use a search engine to google a Python question, I > frequently get a link to a page of the Python 2.7 documentation that shows > before the Python 3 documentation link. > There exists browser extensions that do this: https://addons.mozilla.org/en-US/firefox/addon/py3direct/ https://chrome.google.com/webstore/detail/py3redirect/codfjigcljdnlklcaopdciclmmdandig?hl=en André Roberge > > This is annoying and slows down my programming. > > I propose: That we add a setting to Python’s online documentation that > will optionally given that certain conditions are met, we redirect the user > to the corresponding Python 3 documentation entry. The conditions: > - The Referer header is set to a URL of a major search engine (the Referer > is the URL of the last page that whose link was clicked on to reach the > documentation) > - The user has opted-in to this behavior. > > (Conceptually this should be user script, but for the collective > conscience of all python developers, a doc option would be better. ) > > I understand that some core devs might just have documentation downloaded > and just use that, but a large portion of Python users primarily use > online documentation > > James Lu > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A GUI for beginners and experts alike
On Fri, Aug 24, 2018 at 12:42 PM Barry Scott wrote: > > > On 23 Aug 2018, at 19:49, Mike Barnett wrote: > > Python has dropped the GUI ball, at least for beginners (in my opinion) > > > snip > > I think that this is a very interesting project. Having a simple way to do > GUI's is great for beginners and experienced people. > > What I'd suggest is that this would be better if you could extent beyond > the simple using the underlying toolkit. > But I'd not use tk as the base I'd use PyQt, IMHO, its the best toolkit > for building GUIs with python. > While I agree that PyQt is better than tkinter, and I even wrote a simple interface for it (https://github.com/aroberge/easygui_qt), I think that any "single install, easy to use" GUI toolkit should be based on what's in the standard library and, for better or for worse, that is tkinter. So I think that the right choice was made for PySimpleGUI. André > > I'd love to start with the simple and build on top the complex stuff only > when I need it. > > Barry > > > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] With expressions
On Thu, Aug 2, 2018 at 7:24 AM Thomas Nyberg via Python-ideas <
python-ideas@python.org> wrote:
> Is it true that Path('file').read_text() cl
> oses the file after the read?
> I think that is the sort of functionality that Ken is asking for.
> It's not clear to me by your linked documentation that it does. If it
> does, maybe that should be made more clear in that linked documentation?
>
Agreed. Then again, the documentation includes a link to the source at the
top and we find (
https://github.com/python/cpython/blob/3.7/Lib/pathlib.py#L1174)
docstring: Open the file in text mode, read it, and close the file.
Or ...
>>> import pathlib >>> help(pathlib.Path.read_text) Help on function
read_text in module pathlib: read_text(self, encoding=None, errors=None)
Open the file in text mode, read it, and close the file.
The documentation would be improved if it used the text from the docstring
instead of its own one-line description.
André Roberge
> (Of course, maybe it's written there somewhere and I'm just blind...)
>
> Cheers,
> Thomas
>
> On 08/02/2018 11:53 AM, Paul Moore wrote:
> > On Thu, 2 Aug 2018 at 10:39, Ken Hilton wrote:
> >
> >> With expressions allow using the enter/exit semantics of the with
> statement inside an expression context. Examples:
> >>
> >> contents = f.read() with open('file') as f #the most obvious one
> >> multiplecontents = [f.read() with open(name) as f for name in
> names] #reading multiple files
> >>
> >> I don't know if it's worth making the "as NAME" part of the with
> mandatory in an expression - is this a valid use case?
> >>
> >> data = database.selectrows() with threadlock
> >>
> >> Where this would benefit: I think the major use case is `f.read() with
> open('file') as f`. Previous documentation has suggested
> `open('file').read()` and rely on garbage collection; as the disadvantages
> of that became obvious, it transitioned to a method that couldn't be done
> in an expression:
> >
> > That use case is satisfied by pathlib:
> >
> > Path('file').read_text()
> >
> > see
> https://docs.python.org/3.7/library/pathlib.html#pathlib.Path.read_text
> >
> > Are there any other use cases? I don't see any real advantage here
> > other than the non-advantage of being able to write one-liners.
> > Paul
> > ___
> > Python-ideas mailing list
> > Python-ideas@python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 505: None-aware operators
On Mon, Jul 23, 2018 at 6:52 AM Steve Dower wrote:
> Responding to a few more ideas that have come up here.
>
Thank you for the clarifications.
I'm trying to wrap my head around the various facets of None aware
operators proposal after reading the whole discussion - as well as having
read the PEP a few times. Below is a
summary of what I gathered from the discussion, with a few added other
points that I have not seen addressed.
1. It is an operator present in other languages (e.g. C#, Dart), that uses
the same notation
a) This demonstrates that such an operator has been found to be useful and
is
definitely worth considering.
b) The fact that it uses the same notation is a plus for people that know
these other languages but it does not mean that the notation is necessarily
the best choice for Python. To wit, Python does not use the combination of
? and
: for ternary operator; instead it reuses existing keywords.
c) Some people use languages (e.g. Ruby) that allow ? to be part of an
identifier,
which means that one could, in principle, write something like
a = b?.c
in Ruby with a completely different meaning than what it would mean in C#
or Dart,
or as proposed for Python.Thus, I don't think that that language X uses
this operator written this way is,
**on its own**, a valid justification for using the exact same syntax for
Python.
d) Dart is given as an example. Reading from the link mentioned in the PEP,
I was lead to https://www.dartlang.org/guides/language/language-tour#classes
where the only mention of ?. was the following:
===
// If p is non-null, set its y value to 4.
p?.y = 4;
===
However, PEP 505 mentions that something like the above would raise a
SyntaxError.
Given that Dart's operator has a different semantics than that proposed for
Python,
I do not think that mentioning Dart in this context without any qualifier
is a valid supportive justification for this proposal.
2. On the specific choices of ??, ??=, ?., ?[]
a) Trying to find what Csharp ?? means by doing a quick internet search is
not exactly
productive. By comparison, if one were to use a new keyword (say ifnone
instead
of ??) or keywords, it would make it easier to find their meaning. The
problem with new
keywords is that they may introduce some backwards incompatibility.
b) Admitedly, there are very few remaining symbols in Python that can be
used for defining new operators. Introducing operators using ? does not
cause problems with existing code.
c) While using a new keyword for ?? and ??= might work, it is less clear,
at least to me, how this could extend to ?. and ?[]
d) ? and ?? are already used by IPython with a totally different meaning.
I almost never use IPython I have no idea what problems this might cause
for IPython users.
3. On some examples given
PEP 505 gives these examples from Request:
data = [] if data is None else data
files = [] if files is None else files
headers = {} if headers is None else headers
params = {} if params is None else params
hooks = {} if hooks is None else hooks
It then argues that this is undesirable and that it could have been written
instead
as
data = data if data is not None else []
files = files if files is not None else []
headers = headers if headers is not None else {}
params = params if params is not None else {}
hooks = hooks if hooks is not None else {}
which, as written in PEP 505, is deemed to be "more intuitive" - but longer.
Having looked at the code in the Request module, I would argue that it
could have been written instead as
if data is None: data = []
if files is None: files = []
if headers is None: headers = {}
if params is None: params = {}
if hooks is None: hooks = {}
which gives the same result and is shorter than the original - but
admittedly longer than
the proposed notation. I do not think that this specific example as
currently written
in PEP 505 gives a fair picture of what is currently possible with Python.
4) On comparisons with other "domain specific operators", like @ and
the bitwise operators.
I do not remember the exact words that were used in the discussions, but
I seem to recall people saying that operators like ??, ?., etc. are no
more "mysterious" than @ or the bitwise operators might be: users should
not be surprised to have to learn new operators.
Anyone that does numerical work knows that matrix multiplications do not
obey the same rules as multiplications of numbers. If you don't do numerical
work, you are almost certain not to encounter @ as an operator (but only
as a symbol for decorator), so there won't be any mystery to solve.
A similar situation exists for bitwise operators.
Having dedicated operators to represent special methods on these types of
objects makes the code easier to read for people working in these fields.
I also note that these operators have corresponding dunder methods.
By contrast, code like
if a is None:
a = []
can occur in pretty much any type of program and is, arguably, already very
[Python-ideas] Including the unparse module in the standard library
In the cPython repository, there is an unparse module in the Tools section. https://github.com/python/cpython/blob/master/Tools/parser/unparse.py However, as it is not part of the standard library, it cannot be easily used; to do so, one needs to make a local copy in a place from where it can be imported. This module can be useful for people using the ast module to create and parse trees, modify them ... and who want to convert the result back into source code. Since it is obviously maintained to be compatible with the current Python version, would it be possible to include the unparse module in the standard library? André Roberge ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Approximately equal operator
I have a suggestion to make inspired by the current discussion about trigonometric functions in degrees, and the desire to have them show "exact" values in some special cases. I suggest that it would be useful to have operators for performing **approximate** comparisons. I believe that such operators would be useful both for students learning using Python as well as experts doing numerical computations. For discussion purpose, I will use ~= as representing an operator testing for approximate equality. (I will show some sample usage below). When teaching students, the availability of both == and ~= would give the opportunity to discuss the fact that numerical computations using floats are approximate, while having the possibility to write code that is readable using the approximate equality operator instead of the strict equality operator when needed. Before I started writing this email, I had noticed that numpy includes at least two functions (isclose and allclose) whose purpose is to perform such approximate comparisons. [1] I had completely missed the fact that Python added the function isclose() in the math module in version 3.5, as described in PEP 485 [0]. I would suggest that the possibility of using operators instead of explicit function calls could make programs easier to write and read, both for beginners and experts alike. I note that PEP 485 makes no mention of introducing operators as a possibility. In addition to an approximate equality operator, it would be natural to include two additional operators, greater than or approximately equal, and lesser than or approximately equal. These could be written respectively as >~= and <~=. I did consider using some relevant utf-8 symbol instead of combination of ascii characters, but I think that it would be easier to write programs if one does not require characters nor found on any normal keyboard. Some time ago, I created a toy module [2] to enable easy experiments with some syntactic additions to Python. Using this module, I created a very poor and limited implementation that shows what using these proposed o[erators might look like [3] ... My current implementation is slightly different from either Numpy or Python's math.isclose() function [This may no longer be the case soon as I plan to change it to use Python's version instead.] . As is the case for isclose(), there are two paramaters to be set to determine if the values are close enough to be considered approximately equal: an absolute tolerance and a relative one. Given that one cannot pass parameters to an operator, my implementation includes a function which can change the values of these parameters for a given session. If these new operators were to be added to Python, such a function would either have to be added as a builtin or as a special function in the math module. Here's a sample session for demonstration purpose... $ python -m experimental experimental console version 0.9.5. [Python version: 3.6.1] ~~> 0.1 + 0.2 0.30004 ~~> 0.1 + 0.2 == 0.3 False ~~> from __experimental__ import approx ~~> 0.1 + 0.2 ~= 0.3# use approximately equal operator True ~~> 0.1 + 0.2 <~= 0.3 True ~~> 0.1 + 0.2 >~= 0.3 True ~~> 2 ** 0.5 1.4142135623730951 ~~> 2**0.5 ~= 1.414 False ~~> set_tols(0.001, 0.001) ~~> 2**0.5 ~= 1.414 True André Roberge [0] https://www.python.org/dev/peps/pep-0485/ [1] See for example https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.isclose.html [2] https://github.com/aroberge/experimental [3] https://github.com/aroberge/experimental/blob/master/experimental/transformers/readme.md#approxpy ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] "given" vs ":=" in list comprehensions
Sorry for chiming in so late; I was lurking using google groups and had to subscribe to post - hence this new thread. I gather that *where* has been discarded as a possible new keywords given its use as a function in numpy ( https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.where.html) ... Still, I will include it below for completeness (and as I think it reads better than the other choices) Here are two sets of two examples illustrating a situation that I have not seen before, and which read (to me) much better when using a keyword (given or where) than a symbol (:=). Furthermore, the position of the temporary assignment can, in my opinion, be done differently and help in making the code clearer. First example: single temporary assignment, done four different ways. 1) using := real_roots = [ (-b/(2*a) + (D:= sqrt( (b/(2*a))**2 - c/a), -b/(2*a) - D) for a in range(10) for b in range(10) for c in range(10) if D >= 0] 2) using *given* at the very end real_roots = [ (-b/(2*a) + D, -b/(2*a) - D) for a in range(10) for b in range(10) for c in range(10) if D >= 0 given D= sqrt( (b/(2*a))**2 - c/a)] 3) using *given* before the iterations real_roots = [ (-b/(2*a) + D, -b/(2*a) - D) given D= sqrt( (b/(2*a))**2 - c/a) for a in range(10) for b in range(10) for c in range(10) if D >= 0] 4) using *where* before the iterations (which would be my preferred choice if it were available) real_roots = [ (-b/(2*a) + D, -b/(2*a) - D) where D= sqrt( (b/(2*a))**2 - c/a) for a in range(10) for b in range(10) for c in range(10) if D >= 0] Second example: multiple assignments. When we have multiple temporary assignments, the situation can be more complicated. In the following series of examples, I will start in reverse order compared to above. 5) using *where* before the iterations real_roots2 = [ (-b/(2*a) + D, -b/(2*a) - D) where D= sqrt( (b/(2*a))**2 - c/a) where c = c_values/100 for c_values in range(1000) if D >= 0] 6) using *given* before the iterations real_roots2 = [ (-b/(2*a) + D, -b/(2*a) - D) given D= sqrt( (b/(2*a))**2 - c/a) given c = c_values/100 for c_values in range(1000) if D >= 0] 7) using *given* at the very end real_roots2 = [ (-b/(2*a) + D, -b/(2*a) - D) for c_values in range(1000) if D >= 0 given D= sqrt( (b/(2*a))**2 - c/a) given c = c_values/100] 8) Using := real_roots2 = [ ( -b/(2*a) + (D:= sqrt( (b/(2*a))**2 - (c:=c_values/100)/a), -b/(2*a) - D) for c_values in range(1000) if D >= 0] I find this last version extremely difficult to understand compared with the others where a keyword is used. Perhaps it is because I do not fully understand how := should be used... Finally ... if "where" cannot be used, given the very special status of such temporary assignments, could "where_" (with a trailing underscore) be considered? I would argue that any word followed by an underscore would be more readable than a compound symbol such as ":=". André ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
