[Python-ideas] Re: The name Ellipsis should be a constant
On Mon, May 31, 2021 at 11:41 PM Steven D'Aprano
wrote:
> It's pretty standard behaviour for Python. Right now, `eval(repr(...))`
> works unless you have shadowed the name
> Ellipsis.
>
> >>> err = ValueError('something went wrong')
> >>> ValueError = list
> >>> eval(repr(err))
> ['s', 'o', 'm', 'e', 't', 'h', 'i', 'n', 'g', ' ', 'w', 'e', 'n',
> 't', ' ', 'w', 'r', 'o', 'n', 'g']
>
Yeah, my surprise was kind of a "thinko." I think I was thinking of the
eval() separately from the repr(). But nonetheless, the idempotency
question still arises, and I believe is reasonable.
> Unless we make the ellipsis object `...` callable. But that doesn't help
> us if the name Ellipsis has been rebound. Then it will call the rebound
> object.
>
> Let's change the behavior of the Ellipsis object slightly to have either a
> .__call__() or .__getitem__() method that returns itself
That was exactly what I suggested. The three dots themselves, which CANNOT
be bound to any other object, could be callable or indexable. If you
define a class Ellipsis to use that name, it makes no difference to
`repr(...) == "...[Ellipsis]"` Note that I am NOT proposing
`Ellipsis(...)` as the repr for EXACTLY that reason.
> Not every builtin needs a mollyguard to protect against misuse.
>
I'm not likely to rebind `Ellipsis` so that's not really my concern.
Rather, I'm interested in the point André Roberge started the thread with.
The repr of '...' should be more self-explanatory to beginners. It's
basically co-opting the square brackets or parenthesis to mean something
that doesn't really have anything to do with calling or indexing in order
to have a repr—in tracebacks specifically, but elsewhere also—that reminds
users of the connection between `...` and `Ellipsis`.
--
The dead increasingly dominate and strangle both the living and the
not-yet born. Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/USE2ICT6CVRFNINM4S5O3FOWEO3ZSVUP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)
On Sat, May 29, 2021 at 12:46:11PM +0100, Matt del Valle wrote:
> My view is that variable decorators should be legal for:
>
> 1) assignment statements (so that the decorator can modify or replace the
> object that is getting assigned)
Can you explain what benefit a variable decorator in this case would
have over a function call?
@func
var = expression
is, I expect, the same as:
var = func(expression)
or with the assignment target magic:
var = func('var', expression)
> 2) bare type-hints, since these are arguably *a sort of* assignment
> operation that still carries useful info a decorator might want to capture
> (you're not assigning the name and its value to globals(), but rather the
> name and its type to globals()['__annotations__'])
Once we move out of bare type hints into calling a function, it's not a
bare type hint any more.
@func
var: int
if it calls func, is not the same as
var: int
which has no runtime effect.
A note on augmented assignment:
> 3) Augmented assignment gets expanded out to its true meaning before being
> passed to the decorator, so for example:
The true meaning of augmented assignment is not to expand the line of
code out to assignment with the operator, but a method call:
target += expression
# not this
target = target + expression
# but this instead:
target = type(target).__iadd__(target, expression)
Only if `__iadd__` doesn't exist does the interpreter fall back on the
plus operator. This is why classes can implement augmented assignment as
inplace operators:
L = [1, 2, 3]
L += [4] # modifies L in place
L = L + [4] # creates a new list and assigns to L
This is a significant difference as soon as you have multiple references
to the original list.
--
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/S2HUAW5ASQVBKERKHQ6SQLKDRLQPNT4K/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
On Mon, May 31, 2021 at 09:12:42PM -0400, David Mertz wrote:
> >
> > I think you are going against the design of the language here. With only
> >
> a handful of critical exceptional cases (None, True, False are the only
> > ones that come to mind), names can be rebound.
> >
>
> The following genuinely surprised me. I was trying to show something
> different in reply, but I think the actual behavior makes the point even
> more:
[...]
> This is *strange* behavior. I don't expect every sequence of characters to
> round trip `eval(repr())`, but I kinda expect it to be mostly idempotent.
It's pretty standard behaviour for Python.
>>> err = ValueError('something went wrong')
>>> ValueError = list
>>> eval(repr(err))
['s', 'o', 'm', 'e', 't', 'h', 'i', 'n', 'g', ' ', 'w', 'e', 'n',
't', ' ', 'w', 'r', 'o', 'n', 'g']
The repr of an object tells you what the object thinks it is called; but
`eval` evaluates the given source code according to whatever name
bindings happen to exist at the time, which can shadow or monkey-patch
the names that were used to generate the object in the first place.
>>> eval(repr(NotImplemented))
NotImplemented
>>> NotImplemented = len
>>> eval(repr(str.__lt__('', None)))
The lesson here is not to rebind names if you don't want eval to use the
rebound names :-)
Right now, `eval(repr(...))` works unless you have shadowed the name
Ellipsis. If we make the proposed changed, it will call whatever
arbitrary object was bound to Ellipsis, so the best you can hope for is
a TypeError:
>>> eval('Ellipsis (...)')
Traceback (most recent call last):
File "", line 1, in
File "", line 1, in
TypeError: 'ellipsis' object is not callable
Unless we make the ellipsis object `...` callable. But that doesn't help
us if the name Ellipsis has been rebound. Then it will call the rebound
object.
I have to emphasise that this is standard, normal behaviour, and I still
don't know why we are disturbed by Ellipsis behaving like nearly
everything else in Python. The only oddity is that unlike most things,
Ellipsis also has a special symbol `...` that most objects don't have.
[...]
> Let's change the behavior of the Ellipsis object slightly to have either a
> .__call__() or .__getitem__() method that returns itself, no matter what
> argument is passed.
"Errors should never pass silently."
class Ellipse(Shape):
...
myshape = Ellipsis(mysquare) # oops
# much later on...
myshape.draw() # TypeError
Okay, it's a bit of a contrived set of circumstances, but it
demonstrates the idea that functions should not ignore their arguments.
Exceptions should, if possible, occur as close as possible to the actual
error (the use of Ellipsis instead of Ellipse).
If the parameter to a function has no effect, it shouldn't be a
parameter. If you pass an invalid argument to the (hypothetical)
callable Ellipsis, it should raise TypeError immediately, not ignore the
argument.
So we're trying to fix an issue of next to no practical importance, that
doesn't really affect anyone, by building in more complexity and weird
corner cases in the language. I don't think that's a good trade off.
Shadowing and monkey-patching are advanced techniques, and we shouldn't
demand the language protect newbies who accidentally shadow the built-in
Ellipsis and then try to use eval.
Not every builtin needs a mollyguard to protect against misuse.
--
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/QSURXGJCTK6NC2ZBJHLIGT7YHWVICBRE/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
On Mon, May 31, 2021 at 9:12 PM David Mertz wrote: > >>> foo = "bar" > >>> eval(repr(foo)) == eval(repr(eval(repr(foo > True > >>> eval(repr(None)) == eval(repr(eval(repr(None > True > > Let's change the behavior of the Ellipsis object slightly to have either a > .__call__() or .__getitem__() method that returns itself, no matter what > argument is passed. > > >>> repr(...) > ...[Ellipsis] > ...(Ellipsis) > > I don't know which looks better, but neither look terrible to me. That > would produce a more explanatory repr() while also preserving idempotence. > Oh... just in case I wasn't clear, `Ellipsis.__repr__()` would obviously need to be changed slightly as well along with adding .__call__() or .__getitem__() for this to work. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions. ___ 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/JMWS2FRMSMF6S6J2BJZ6ZSRUHSMJIZKK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
> > I think you are going against the design of the language here. With only > a handful of critical exceptional cases (None, True, False are the only > ones that come to mind), names can be rebound. > The following genuinely surprised me. I was trying to show something different in reply, but I think the actual behavior makes the point even more: >>> eval(repr(Ellipsis)) Ellipsis >>> eval(repr(...)) Ellipsis >>> Ellipsis = 42 >>> eval(repr(...)) 42 This is *strange* behavior. I don't expect every sequence of characters to round trip `eval(repr())`, but I kinda expect it to be mostly idempotent. >>> foo = "bar" >>> eval(repr(foo)) 'bar' >>> eval(repr(foo)) == eval(repr(eval(repr(foo True >>> eval(repr(None)) == eval(repr(eval(repr(None True Obviously I know there are some repr()'s that cannot be eval()'d. But this isn't the same concern as e.g. a file handle or a user class. I don't find this issue any huge wart in Python, but it's a funny corner. Here's a proposal I'll throw out: Let's change the behavior of the Ellipsis object slightly to have either a .__call__() or .__getitem__() method that returns itself, no matter what argument is passed. Then we could have this behavior: >>> repr(...) ...[Ellipsis] Or >>> repr(...) ...(Ellipsis) I don't know which looks better, but neither look terrible to me. That would produce a more explanatory repr() while also preserving idempotence. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions. ___ 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/IMODVBMEYBUOUPX7GYCGWQNQDVVAMXVP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
On Mon, 2021-05-31 at 11:37 -0300, André Roberge wrote: > In Python `...` is referred to as `Ellipsis` and cannot be assigned to. > Yet, one can assign any value to the name `Ellipsis`. > > Consider the following: > > ``` > > > > ... > Ellipsis > > > > ... == Ellipsis > True > > > > Ellipsis > Ellipsis > > > > Ellipsis = 3 > > > > Ellipsis > 3 > > > > ... = 4 > File "", line 1 > ... = 4 > ^ > SyntaxError: cannot assign to Ellipsis > > > > # But I just did assign a new value to the name Ellipsis above. > > > > Ellipsis > 3 > > > > ... > Ellipsis > > > > ... == Ellipsis > False > ``` > > For consistency, `Ellipsis` (the name) should **always** refer to the same > object that `...` refers to, so that both could not be assigned a new value. > Perhaps Ellipsis could get the same treatment as None here, but I am not sure if there's enough reasoning to justify that, especially considering that it would be a backwards incompatible change. Do you have any use-cases that would warrant such a thing? I find it incredibly hard to justify this proposal. Cheers, Filipe Laíns signature.asc Description: This is a digitally signed message part ___ 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/EKTS6HI6DQAJUPKQZ4X7ODCBTKQ5PBLJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
On Mon, May 31, 2021 at 10:55:08PM +0100, MRAB wrote: > >>>> a = []; a.append(a); a > >[[...]] > >>>> [[...]] > >[[Ellipsis]] > > > Why is it 3 dots anyway? As we've already ascribed a meaning to 3 dots, > why not use 4 dots in this use? Three dots for ommitted text is standard in English. Four dots is an ellipsis followed by a full stop. We could go against that convention (Python is not English, although it is based closely on many English conventions) but honestly I think that any change in this area is of such little benefit that it's not worth the potential disruption to documentation and doctests. -- 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/7PLNSL6MNRDUWIIYX7O245TIYQADUVGU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
On Mon, May 31, 2021 at 12:36:34PM -0300, André Roberge wrote:
> Thinking some more about it, perhaps the confusion would be sufficiently
> reduced if the repr of '...' would be 'Ellipsis (...)', and use this repr
> to appear in error messages rather than simply the name Ellipsis.
I think you are going against the design of the language here. With only
a handful of critical exceptional cases (None, True, False are the only
ones that come to mind), names can be rebound.
>>> type(4)
>>> int = list
>>> type(4)
>>> int('123')
['1', '2', '3']
Objects are not their name, and their name is not the object. Objects do
not know the name or names they are bound to.
`...` is not a name, it is a syntactic symbol that is hard coded in the
interpreter to the object which we popularly call "Ellipsis". You can't
assign to the symbol any more than you can assign to the symbol `+`.
On the other hand, `Ellipsis` is just a name. Like nearly all names in
Python, you can rebind it or delete it. Rebinding the name doesn't
affect the object `...`. It still knows itself as Ellipsis, no matter
what names happen to be bound to it in some namespace or another.
(Analogy: you would probably still think of yourself as André even if we
all started to call you Bruce.)
We *could* single out Ellipsis for special treatment, like None, True
and False, but what's so special about Ellipsis that we should bother?
The bottom line here is that the *name* "Ellipsis" is not special. It's
just a name, like int, TypeError, and all the rest.
If you want to make Ellipsis a keyword, like None, True and False, you
would need some good reason for it.
--
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/DHT3U2ROYZNTP5QNVOKVZ2UNIQ3ODNRX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
On 2021-05-31 21:19, Serhiy Storchaka wrote: 31.05.21 22:46, Chris Angelico пише: Originally, the notation "..." could only be used inside a subscript, and anywhere else, you'd have to spell it "Ellipsis". Now that you can use "..." anywhere, would it be worth switching the repr to just be that? How would you then distinguish a recursive list from a list containing Ellipsis? >>> a = []; a.append(a); a [[...]] >>> [[...]] [[Ellipsis]] Why is it 3 dots anyway? As we've already ascribed a meaning to 3 dots, why not use 4 dots in this use? ___ 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/IQ25HSKBHWVXXK7M4G73V4FXOEN2F6MZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
On 2021-05-31 12:46, Chris Angelico wrote: On Tue, Jun 1, 2021 at 5:40 AM David Mertz wrote: I think making 'Ellipsis' a reserved word is too much. The analogy with non-reserved words like `int`, `str`, `map`, `print`, and so on, illustrate this, I think. I.e. redefining those is likely to cause bad things to happen, but we're consenting adults, and in the end they are just names. However, I think improving the repr() of the Ellipsis object itself to remind users of the connection with its special literal `...` is a great idea. Originally, the notation "..." could only be used inside a subscript, and anywhere else, you'd have to spell it "Ellipsis". Now that you can use "..." anywhere, would it be worth switching the repr to just be that? I feel like that might be confusing. We do have things like lists where the repr of an empty list is [], but lists are pretty basic and ubiquitous Python objects that people usually learn about quite early. Ellipsis is a more obscure thing so it seems worthwhile to label it somehow rather than just giving a cryptic three dots. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown ___ 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/VLK2PL3EU3GFJRECHHKKNNDWGUSZXIZQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
31.05.21 23:28, Chris Angelico пише: > Although... since that's an arbitrary placeholder, it could be changed > to pretty much anything. Maybe <...> or something? The current repr > may not technically be ambiguous, but it will silently do the wrong > thing if you try to eval it. You can even ast.literal_eval(repr(a)) > and it'll appear to work. It was already discussed in 2015 [1], but the idea of <...> was rejected by Guido [2]. [1] https://mail.python.org/archives/list/python-ideas@python.org/thread/T2T7WR52AYLM7R77G6QMSDSPFYWBEBCL/ [2] https://mail.python.org/archives/list/python-ideas@python.org/thread/RAZMTY2VGVXZYIO7RTA4DVW5C7MCTWOQ/ ___ 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/7IMYWZEUHOTI7ZPPYP2SXC4FDJHIHTFX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
On Tue, Jun 1, 2021 at 6:22 AM Serhiy Storchaka wrote: > > 31.05.21 22:46, Chris Angelico пише: > > Originally, the notation "..." could only be used inside a subscript, > > and anywhere else, you'd have to spell it "Ellipsis". Now that you can > > use "..." anywhere, would it be worth switching the repr to just be > > that? > > How would you then distinguish a recursive list from a list containing > Ellipsis? > >>>> a = []; a.append(a); a >[[...]] >>>> [[...]] >[[Ellipsis]] Good point, didn't think of that. Although... since that's an arbitrary placeholder, it could be changed to pretty much anything. Maybe <...> or something? The current repr may not technically be ambiguous, but it will silently do the wrong thing if you try to eval it. You can even ast.literal_eval(repr(a)) and it'll appear to work. Not a huge deal whichever way, though. The token "..." is used in a variety of non-ellipsis ways, such as doctest, and that isn't inherently a problem. ChrisA ___ 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/XT463HNMCJ5KSLQMN2H2B7V4EMWTW5MX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
31.05.21 22:59, Jelle Zijlstra пише: > Why isn't `repr(...)` just `...`? Because it would confuse with reprs for recursive collections. ___ 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/33JO776U2YVRNL6I6MJA7OFTGZPMY6SI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
31.05.21 22:46, Chris Angelico пише: > Originally, the notation "..." could only be used inside a subscript, > and anywhere else, you'd have to spell it "Ellipsis". Now that you can > use "..." anywhere, would it be worth switching the repr to just be > that? How would you then distinguish a recursive list from a list containing Ellipsis? >>> a = []; a.append(a); a [[...]] >>> [[...]] [[Ellipsis]] ___ 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/44OGXUKQ4XM6PTDMYJAF5S2BH23TD3O6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: symbolic math in Python
On Mon, 31 May 2021 at 13:10, Neil Girdhar wrote:
>
> Have you considered using the JAX library's trick of decorating functions to
> provide automatic symbols?
>
> For example, your problem could be done in current Python with an
> appropriately-coded library:
>
> @symbolic
> def f(x, a, b, c):
> return a * x ** 2 + b * x + c
>
> sentinel = Sentinel()
>
> solve(f(sentinel, 1, 0, -1 / 2), solve_for=sentinel)
>
> The idea is that f(sentinel) would produce the expression graph by
> propagating tracer objects throughout the tree. Then, solve would identify
> the appropriate tracer to be solved.
>
> JAX uses this trick to accomplish three tasks: JIT compilation of
> mathematical expressions, automatic calculation of gradients and related
> functions, and automatic generation of vectorized versions of functions.
>
> To be fair, JAX's design is brilliant. I don't fault the SymPy people for
> not coming up with it, but the problem that you're trying to solved could be
> done with a better-designed SymPy. You don't need new syntax.
Hi Neil,
Thanks for the suggestion but I'm not sure exactly what you mean.
It's not clear to me what problem you think this would solve for
sympy. If the problem is to do with needing to declare symbols then
this solution seems awkward because it only works if the variables are
function parameters so that a decorator can be used on the function.
The current situation is this:
a, b, c, x = symbols('a:c, x')
eq = a*x**2 + b*x + c
Your suggestion seems to require defining an otherwise unnecessary
function like this:
@symbolic
def equation(a, b, c, x):
return a*x**2 + b*x + c
eq = equation()
That doesn't seem like an improvement to me (maybe I've misunderstood...).
Oscar
___
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/2WHU2W5N44MWA63MDBLBHHMHKO7KKV7C/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
+1 On Tue, 2021-06-01 at 05:46 +1000, Chris Angelico wrote: > On Tue, Jun 1, 2021 at 5:40 AM David Mertz wrote: > > > > I think making 'Ellipsis' a reserved word is too much. The analogy > > with non-reserved words like `int`, `str`, `map`, `print`, and so > > on, illustrate this, I think. I.e. redefining those is likely to > > cause bad things to happen, but we're consenting adults, and in the > > end they are just names. > > > > However, I think improving the repr() of the Ellipsis object itself > > to remind users of the connection with its special literal `...` is > > a great idea. > > > > Originally, the notation "..." could only be used inside a subscript, > and anywhere else, you'd have to spell it "Ellipsis". Now that you > can > use "..." anywhere, would it be worth switching the repr to just be > that? > > ChrisA > ___ > 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/EK7DPA4ORNFAE3PVE44KPF7NAYO7B3P7/ > 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/C3QQI3VUZB3MRKTCVERKZHNE4YGUZ52E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
El lun, 31 may 2021 a las 12:40, David Mertz () escribió: > I think making 'Ellipsis' a reserved word is too much. The analogy with > non-reserved words like `int`, `str`, `map`, `print`, and so on, illustrate > this, I think. I.e. redefining those is likely to cause bad things to > happen, but we're consenting adults, and in the end they are just names. > > However, I think improving the repr() of the Ellipsis object itself to > remind users of the connection with its special literal `...` is a great > idea. > > > Why isn't `repr(...)` just `...`? ___ 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/GONLS3TPYQWX5E2CW3D563B4CDLMXBQR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
On Tue, Jun 1, 2021 at 5:40 AM David Mertz wrote: > > I think making 'Ellipsis' a reserved word is too much. The analogy with > non-reserved words like `int`, `str`, `map`, `print`, and so on, illustrate > this, I think. I.e. redefining those is likely to cause bad things to > happen, but we're consenting adults, and in the end they are just names. > > However, I think improving the repr() of the Ellipsis object itself to remind > users of the connection with its special literal `...` is a great idea. > Originally, the notation "..." could only be used inside a subscript, and anywhere else, you'd have to spell it "Ellipsis". Now that you can use "..." anywhere, would it be worth switching the repr to just be that? ChrisA ___ 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/EK7DPA4ORNFAE3PVE44KPF7NAYO7B3P7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
I think making 'Ellipsis' a reserved word is too much. The analogy with non-reserved words like `int`, `str`, `map`, `print`, and so on, illustrate this, I think. I.e. redefining those is likely to cause bad things to happen, but we're consenting adults, and in the end they are just names. However, I think improving the repr() of the Ellipsis object itself to remind users of the connection with its special literal `...` is a great idea. On Mon, May 31, 2021 at 3:27 PM André Roberge wrote: > > > On Mon, May 31, 2021 at 4:17 PM Serhiy Storchaka > wrote: > >> 31.05.21 17:37, André Roberge пише: >> > For consistency, `Ellipsis` (the name) should **always** refer to the >> > same object that `...` refers to, so that both could not be assigned a >> > new value. >> >> Making Ellipsis a keyword will break ast.Ellipsis (and maybe some >> third-party libraries). >> > > I realized that after my initial post which is why I subsequently > suggested that its repr should perhaps be "Ellipsis (...)". But, I admit, > it is a rather obscure corner case that few, if any beginners would > encounter and be confused by the error message. > > > >> >> ___ >> 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/4K47SCZYGHDPV4UUXNUQXSAK374STS43/ >> 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/KYIOVHZQOEKOA5BGZ35DYXBBGBJVDQT3/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions. ___ 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/GMYGP73TM2VFKG4VS7BVFEVFLCR7JP6B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
On Mon, May 31, 2021 at 4:17 PM Serhiy Storchaka wrote: > 31.05.21 17:37, André Roberge пише: > > For consistency, `Ellipsis` (the name) should **always** refer to the > > same object that `...` refers to, so that both could not be assigned a > > new value. > > Making Ellipsis a keyword will break ast.Ellipsis (and maybe some > third-party libraries). > I realized that after my initial post which is why I subsequently suggested that its repr should perhaps be "Ellipsis (...)". But, I admit, it is a rather obscure corner case that few, if any beginners would encounter and be confused by the error message. > > ___ > 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/4K47SCZYGHDPV4UUXNUQXSAK374STS43/ > 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/KYIOVHZQOEKOA5BGZ35DYXBBGBJVDQT3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
31.05.21 17:37, André Roberge пише: > For consistency, `Ellipsis` (the name) should **always** refer to the > same object that `...` refers to, so that both could not be assigned a > new value. Making Ellipsis a keyword will break ast.Ellipsis (and maybe some third-party libraries). ___ 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/4K47SCZYGHDPV4UUXNUQXSAK374STS43/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
On Mon, May 31, 2021 at 2:40 PM Guido van Rossum wrote: > Andre, did you have an experience where something related to Ellipsis/... > confused you? It is not clear to me what exactly prompted you to single out > Ellipsis (or it’s repr()?) > Guido, the reason why I tried is that I am working on a project called friendly (previously named friendly-traceback) which aims to provide "easy to understand" explanations to beginners when they encounter tracebacks.[1] In playing with different cases involving assignments to a constant (__debug__, None, True, False, ... and Ellipsis as '...'), I came across this particular case which I thought was confusing: Python says that we cannot assign to Ellipsis ... and yet we can. I thought that the explanation provided by cPython itself could be made a bit clearer. The specific suggestion I made is based on the explanation *friendly* currently gives, where it specifies that Ellipsis refers to (...). Admittedly, this is rather a corner case. André With friendly, I usually strive to cover more typical cases that are encountered by beginners, such as one example I gave at this year's PyConUS Education summit where, given the following message: AttributeError: partially initialized module 'turtle' has no attribute 'forward' (most likely due to a circular import) friendly adds the following "hint": Did you give your program the same name as a Python module? And, upon being prompted, friendly adds the following: I suspect that you used the name turtle.py for your program and that you also wanted to import a module with the same name from Python's standard library. If so, you should use a different name for your program. (This particular turtle is not hard-coded in friendly; any circular import is similarly analyzed and some further explanation is provided.) [1] Currently, I have at least 150 different cases yielding SyntaxErrors for which friendly can provide help (see https://aroberge.github.io/friendly-traceback-docs/docs/html/syntax_tracebacks_en_3.8.html for cases covered by unit tests) and probably a hundred or so of various types of other errors. Furthermore, friendly is designed so that the explanations can be translated into other languages; currently, every case friendly covers has explanations available in both English and French. > On Mon, May 31, 2021 at 08:37 André Roberge > wrote: > >> >> >> On Mon, May 31, 2021 at 12:20 PM MRAB wrote: >> >>> On 2021-05-31 15:55, Paul Bryan wrote: >>> > If you're proposing prevention of monkey patching Ellipsis, I think >>> > you'll have to go all-in on all builtins. >>> > >>> > For example: >>> > >>> str = int >>> > >>> str >>> > >>> > >>> > >>> str == int >>> > >>> > True >>> > >>> > >>> If you rebind str to int, the repr of str will say , so you >>> can tell that something's happened, but the repr of ... is always >>> 'Ellipsis', even though you've rebound Ellipsis. >>> >> >> Exactly. >> >> Thinking some more about it, perhaps the confusion would be sufficiently >> reduced if the repr of '...' would be 'Ellipsis (...)', and use this repr >> to appear in error messages rather than simply the name Ellipsis. >> >> >> >>> >>> > >>> > On Mon, 2021-05-31 at 11:37 -0300, André Roberge wrote: >>> >> In Python `...` is referred to as `Ellipsis` and cannot be assigned >>> to. >>> >> Yet, one can assign any value to the name `Ellipsis`. >>> >> >>> >> Consider the following: >>> >> >>> >> ``` >>> >> >>> ... >>> >> Ellipsis >>> >> >>> ... == Ellipsis >>> >> True >>> >> >>> Ellipsis >>> >> Ellipsis >>> >> >>> Ellipsis = 3 >>> >> >>> Ellipsis >>> >> 3 >>> >> >>> ... = 4 >>> >> File "", line 1 >>> >> ... = 4 >>> >> ^ >>> >> SyntaxError: cannot assign to Ellipsis >>> >> >>> # But I just did assign a new value to the name Ellipsis above. >>> >> >>> Ellipsis >>> >> 3 >>> >> >>> ... >>> >> Ellipsis >>> >> >>> ... == Ellipsis >>> >> False >>> >> ``` >>> >> >>> >> For consistency, `Ellipsis` (the name) should **always** refer to the >>> >> same object that `...` refers to, so that both could not be assigned >>> a >>> >> new value. >>> >> >>> ___ >>> 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/NE2FAW3XDFYUIMILV4BC2XT6VKLC4P6V/ >>> 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/DIRDIQFK72LFHYJNAD5BWL3L5SPAUMVM/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- >
[Python-ideas] Re: The name Ellipsis should be a constant
Andre, did you have an experience where something related to Ellipsis/... confused you? It is not clear to me what exactly prompted you to single out Ellipsis (or it’s repr()?) On Mon, May 31, 2021 at 08:37 André Roberge wrote: > > > On Mon, May 31, 2021 at 12:20 PM MRAB wrote: > >> On 2021-05-31 15:55, Paul Bryan wrote: >> > If you're proposing prevention of monkey patching Ellipsis, I think >> > you'll have to go all-in on all builtins. >> > >> > For example: >> > >> str = int >> > >> str >> > >> > >> > >> str == int >> > >> > True >> > >> > >> If you rebind str to int, the repr of str will say , so you >> can tell that something's happened, but the repr of ... is always >> 'Ellipsis', even though you've rebound Ellipsis. >> > > Exactly. > > Thinking some more about it, perhaps the confusion would be sufficiently > reduced if the repr of '...' would be 'Ellipsis (...)', and use this repr > to appear in error messages rather than simply the name Ellipsis. > > > >> >> > >> > On Mon, 2021-05-31 at 11:37 -0300, André Roberge wrote: >> >> In Python `...` is referred to as `Ellipsis` and cannot be assigned to. >> >> Yet, one can assign any value to the name `Ellipsis`. >> >> >> >> Consider the following: >> >> >> >> ``` >> >> >>> ... >> >> Ellipsis >> >> >>> ... == Ellipsis >> >> True >> >> >>> Ellipsis >> >> Ellipsis >> >> >>> Ellipsis = 3 >> >> >>> Ellipsis >> >> 3 >> >> >>> ... = 4 >> >> File "", line 1 >> >> ... = 4 >> >> ^ >> >> SyntaxError: cannot assign to Ellipsis >> >> >>> # But I just did assign a new value to the name Ellipsis above. >> >> >>> Ellipsis >> >> 3 >> >> >>> ... >> >> Ellipsis >> >> >>> ... == Ellipsis >> >> False >> >> ``` >> >> >> >> For consistency, `Ellipsis` (the name) should **always** refer to the >> >> same object that `...` refers to, so that both could not be assigned a >> >> new value. >> >> >> ___ >> 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/NE2FAW3XDFYUIMILV4BC2XT6VKLC4P6V/ >> 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/DIRDIQFK72LFHYJNAD5BWL3L5SPAUMVM/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ 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/DWOVJOTJZQGTLVDEQ76XAI5ZD4M3KSCI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
On Mon, May 31, 2021 at 12:20 PM MRAB wrote: > On 2021-05-31 15:55, Paul Bryan wrote: > > If you're proposing prevention of monkey patching Ellipsis, I think > > you'll have to go all-in on all builtins. > > > > For example: > > > str = int > > > str > > > > > > > str == int > > > > True > > > > > If you rebind str to int, the repr of str will say , so you > can tell that something's happened, but the repr of ... is always > 'Ellipsis', even though you've rebound Ellipsis. > Exactly. Thinking some more about it, perhaps the confusion would be sufficiently reduced if the repr of '...' would be 'Ellipsis (...)', and use this repr to appear in error messages rather than simply the name Ellipsis. > > > > > On Mon, 2021-05-31 at 11:37 -0300, André Roberge wrote: > >> In Python `...` is referred to as `Ellipsis` and cannot be assigned to. > >> Yet, one can assign any value to the name `Ellipsis`. > >> > >> Consider the following: > >> > >> ``` > >> >>> ... > >> Ellipsis > >> >>> ... == Ellipsis > >> True > >> >>> Ellipsis > >> Ellipsis > >> >>> Ellipsis = 3 > >> >>> Ellipsis > >> 3 > >> >>> ... = 4 > >> File "", line 1 > >> ... = 4 > >> ^ > >> SyntaxError: cannot assign to Ellipsis > >> >>> # But I just did assign a new value to the name Ellipsis above. > >> >>> Ellipsis > >> 3 > >> >>> ... > >> Ellipsis > >> >>> ... == Ellipsis > >> False > >> ``` > >> > >> For consistency, `Ellipsis` (the name) should **always** refer to the > >> same object that `...` refers to, so that both could not be assigned a > >> new value. > >> > ___ > 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/NE2FAW3XDFYUIMILV4BC2XT6VKLC4P6V/ > 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/DIRDIQFK72LFHYJNAD5BWL3L5SPAUMVM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
Fixing typo: >>> s = str >>> str = int >>> str >>> s On Mon, 2021-05-31 at 08:31 -0700, Paul Bryan wrote: > Because ... is still bound to the original Ellipsis. Just as "s" > below will remain bound to the original str. > > >>> s = str > >>> str = int > >>> int > > >>> s > > > Paul > > On Mon, 2021-05-31 at 16:16 +0100, MRAB wrote: > > On 2021-05-31 15:55, Paul Bryan wrote: > > > If you're proposing prevention of monkey patching Ellipsis, I > > > think > > > you'll have to go all-in on all builtins. > > > > > > For example: > > > > > > > > > str = int > > > > > > > > > str > > > > > > > > > > > > > > > str == int > > > > > > True > > > > > > > > If you rebind str to int, the repr of str will say , > > so you > > can tell that something's happened, but the repr of ... is always > > 'Ellipsis', even though you've rebound Ellipsis. > > > > > > > > On Mon, 2021-05-31 at 11:37 -0300, André Roberge wrote: > > > > In Python `...` is referred to as `Ellipsis` and cannot be > > > > assigned to. > > > > Yet, one can assign any value to the name `Ellipsis`. > > > > > > > > Consider the following: > > > > > > > > ``` > > > > > > > ... > > > > Ellipsis > > > > > > > ... == Ellipsis > > > > True > > > > > > > Ellipsis > > > > Ellipsis > > > > > > > Ellipsis = 3 > > > > > > > Ellipsis > > > > 3 > > > > > > > ... = 4 > > > > File "", line 1 > > > > ... = 4 > > > > ^ > > > > SyntaxError: cannot assign to Ellipsis > > > > > > > # But I just did assign a new value to the name > > > > > > > Ellipsis above. > > > > > > > Ellipsis > > > > 3 > > > > > > > ... > > > > Ellipsis > > > > > > > ... == Ellipsis > > > > False > > > > ``` > > > > > > > > For consistency, `Ellipsis` (the name) should **always** refer > > > > to the > > > > same object that `...` refers to, so that both could not be > > > > assigned a > > > > new value. > > > > > > ___ > > 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/NE2FAW3XDFYUIMILV4BC2XT6VKLC4P6V/ > > 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/UTNK34FPS7OHK5X3OLCYXWFZ4HNUKJDI/ > 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/P4U32JFIIV3FSD4DTPO7XBDIUUIEPYTX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
Because ... is still bound to the original Ellipsis. Just as "s" below will remain bound to the original str. >>> s = str >>> str = int >>> int >>> s Paul On Mon, 2021-05-31 at 16:16 +0100, MRAB wrote: > On 2021-05-31 15:55, Paul Bryan wrote: > > If you're proposing prevention of monkey patching Ellipsis, I think > > you'll have to go all-in on all builtins. > > > > For example: > > > > > > > str = int > > > > > > > str > > > > > > > > > > > str == int > > > > True > > > > > If you rebind str to int, the repr of str will say , so > you > can tell that something's happened, but the repr of ... is always > 'Ellipsis', even though you've rebound Ellipsis. > > > > > On Mon, 2021-05-31 at 11:37 -0300, André Roberge wrote: > > > In Python `...` is referred to as `Ellipsis` and cannot be > > > assigned to. > > > Yet, one can assign any value to the name `Ellipsis`. > > > > > > Consider the following: > > > > > > ``` > > > > > > ... > > > Ellipsis > > > > > > ... == Ellipsis > > > True > > > > > > Ellipsis > > > Ellipsis > > > > > > Ellipsis = 3 > > > > > > Ellipsis > > > 3 > > > > > > ... = 4 > > > File "", line 1 > > > ... = 4 > > > ^ > > > SyntaxError: cannot assign to Ellipsis > > > > > > # But I just did assign a new value to the name Ellipsis > > > > > > above. > > > > > > Ellipsis > > > 3 > > > > > > ... > > > Ellipsis > > > > > > ... == Ellipsis > > > False > > > ``` > > > > > > For consistency, `Ellipsis` (the name) should **always** refer to > > > the > > > same object that `...` refers to, so that both could not be > > > assigned a > > > new value. > > > > ___ > 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/NE2FAW3XDFYUIMILV4BC2XT6VKLC4P6V/ > 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/UTNK34FPS7OHK5X3OLCYXWFZ4HNUKJDI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
On 2021-05-31 16:16:59, MRAB wrote: > If you rebind str to int, the repr of str will say , so you can > tell that something's happened, but the repr of ... is always 'Ellipsis', > even though you've rebound Ellipsis. > >>> Ellipsis is ... > True > >>> Ellipsis = str > >>> Ellipsis is ... > False ___ 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/KOYNZJP3VO4YU3NO4S2JM7WTIA5FPIZ5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
On 2021-05-31 15:55, Paul Bryan wrote: If you're proposing prevention of monkey patching Ellipsis, I think you'll have to go all-in on all builtins. For example: str = int str str == int True If you rebind str to int, the repr of str will say , so you can tell that something's happened, but the repr of ... is always 'Ellipsis', even though you've rebound Ellipsis. On Mon, 2021-05-31 at 11:37 -0300, André Roberge wrote: In Python `...` is referred to as `Ellipsis` and cannot be assigned to. Yet, one can assign any value to the name `Ellipsis`. Consider the following: ``` >>> ... Ellipsis >>> ... == Ellipsis True >>> Ellipsis Ellipsis >>> Ellipsis = 3 >>> Ellipsis 3 >>> ... = 4 File "", line 1 ... = 4 ^ SyntaxError: cannot assign to Ellipsis >>> # But I just did assign a new value to the name Ellipsis above. >>> Ellipsis 3 >>> ... Ellipsis >>> ... == Ellipsis False ``` For consistency, `Ellipsis` (the name) should **always** refer to the same object that `...` refers to, so that both could not be assigned a new value. ___ 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/NE2FAW3XDFYUIMILV4BC2XT6VKLC4P6V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
If you're proposing prevention of monkey patching Ellipsis, I think you'll have to go all-in on all builtins. For example: >>> str = int >>> str >>> str == int True Paul On Mon, 2021-05-31 at 11:37 -0300, André Roberge wrote: > In Python `...` is referred to as `Ellipsis` and cannot be assigned > to. > Yet, one can assign any value to the name `Ellipsis`. > > Consider the following: > > ``` > >>> ... > Ellipsis > >>> ... == Ellipsis > True > >>> Ellipsis > Ellipsis > >>> Ellipsis = 3 > >>> Ellipsis > 3 > >>> ... = 4 > File "", line 1 > ... = 4 > ^ > SyntaxError: cannot assign to Ellipsis > >>> # But I just did assign a new value to the name Ellipsis above. > >>> Ellipsis > 3 > >>> ... > Ellipsis > >>> ... == Ellipsis > False > ``` > > For consistency, `Ellipsis` (the name) should **always** refer to the > same object that `...` refers to, so that both could not be assigned > a new value. > > 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/KDQ3OHALLXVZJIGPC4BMPVS2XH3VFPJV/ > 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/UZCWHAO4YVOKPZ6JA264MRD27QRBSKD4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] The name Ellipsis should be a constant
In Python `...` is referred to as `Ellipsis` and cannot be assigned to. Yet, one can assign any value to the name `Ellipsis`. Consider the following: ``` >>> ... Ellipsis >>> ... == Ellipsis True >>> Ellipsis Ellipsis >>> Ellipsis = 3 >>> Ellipsis 3 >>> ... = 4 File "", line 1 ... = 4 ^ SyntaxError: cannot assign to Ellipsis >>> # But I just did assign a new value to the name Ellipsis above. >>> Ellipsis 3 >>> ... Ellipsis >>> ... == Ellipsis False ``` For consistency, `Ellipsis` (the name) should **always** refer to the same object that `...` refers to, so that both could not be assigned a new value. 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/KDQ3OHALLXVZJIGPC4BMPVS2XH3VFPJV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: symbolic math in Python
Have you considered using the JAX library's trick of decorating functions
to provide automatic symbols?
For example, your problem could be done in current Python with an
appropriately-coded library:
@symbolic
def f(x, a, b, c):
return a * x ** 2 + b * x + c
sentinel = Sentinel()
solve(f(sentinel, 1, 0, -1 / 2), solve_for=sentinel)
The idea is that f(sentinel) would produce the expression graph by
propagating tracer objects throughout the tree. Then, solve would identify
the appropriate tracer to be solved.
JAX uses this trick to accomplish three tasks: JIT compilation of
mathematical expressions, automatic calculation of gradients and related
functions, and automatic generation of vectorized versions of functions.
To be fair, JAX's design is brilliant. I don't fault the SymPy people for
not coming up with it, but the problem that you're trying to solved could
be done with a better-designed SymPy. You don't need new syntax.
Neil
On Wednesday, May 19, 2021 at 2:39:18 AM UTC-4 Martin Teichmann wrote:
> Hi list,
>
> as you might have noticed, I am trying to improve the syntax and semantics
> for symbolic math in Python. Until now, I have to say, my ideas were not
> that well received, but I learned from the discussion and maybe this time I
> come up with something people like.
>
> To frame the problem, let us try to solve the equation x ** 2 == 1/2 using
> sympy:
>
> >>> from sympy import Eq, solve, symbols, S
> >>> x = symbols("x")
> >>> solve(Eq(x**2, S(1)/2))
> [-sqrt(2)/2, sqrt(2)/2]
>
> that worked well, but actually we would like to write the last line simply
> as
>
> >>> solve(x**2 == 1/2)
>
> as you might notice, this is fully legal Python syntax. Unfortunately the
> semantics is such that sympy has no way to determine what is actually going
> on, this is why they invented all those helper functions shown above.
>
> My idea is now to start at the line above, "x = symbols('x')". I propose a
> new syntax, "symbolic x", which tells the parser that x is a symbolic
> variable, and expressions should not be executed, but handed over as such
> to the calling functions. To stay with the example, the code would look
> like this (this is fake, I did not prototype this yet):
>
> >>> from sympy import solve
> >>> symbolic x
> >>> solve(x**2 == 1/2)
> [-sqrt(2)/2, sqrt(2)/2]
>
> Now to the details. The scope that "symbolic" acts on should be the same
> as the scope of "global". Note that "symbolic x" is currently illegal
> syntax, so we would not even need to make "symbolic" a keyword.
>
> Expressions that contain a symbolic variable are not executed, but instead
> the expression should be given to the function as a tuple, so in the
> example above, solve would be given
> ('==', ('**', ('x', 2)), ('/', 1, 2)). If that looks like LISP to you,
> then you are not completely wrong. The boundaries of expressions are
> function calls, assignments, getitems and getattrs, as they can be
> overloaded much easier by other means. To give an example with gory details
> (again, this is fake):
>
> >>> symbolic x
> >>> d = {"a" : 5}
> >>> c = 7 # not symbolic!
> >>> print(c * x + d["a"])
> ('+', ('*', 7, 'x'), 5)
>
> Maybe we would want to have a new class "expressiontuple" which simply
> acts as a pretty-printer, then the last lines would become
>
> >>> print(x + d["a"])
> 7 * x + 5
>
> What sympy does with this tuple would be fully at its discretion.
>
> I think that other libraries could also benefit from this proposal. As an
> example, in a numerics library (numpy? scipy?) one could improve numerical
> integration as in
>
> >>> symbolic x
> >>> integrate(sin(x), x, 0, pi)
>
> then the integrator could even compile the expression to machine code for
> faster integration.
>
> numpy could also compile expressions to machine code, making it even
> faster than it is now, as in
>
> >>> symbolic x
> >>> f = compile(5 * x + 7 * y, (x, y))
> >>> f(matrix_a, matrix_b)
>
> Let's see how well this proposal fares.
>
> Cheers
>
> Martin
> ___
> Python-ideas mailing list -- python...@python.org
> To unsubscribe send an email to python-id...@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/ZMUV4OUDUX3NSROM2KRUIQKSIBUCZOCD/
>
>
