[Python-ideas] Re: Comparison operator support (>= and <=) for type

[Andrew Barnert via Python-ideas]

On Jun 17, 2019, at 13:09, Guido van Rossum  wrote:
> 
>> On Mon, Jun 17, 2019 at 12:54 PM Andrew Barnert  wrote:
>>> On Jun 17, 2019, at 07:47, Guido van Rossum  wrote:
>>> 
 On Mon, Jun 17, 2019 at 7:23 AM Rhodri James  wrote:
 On 16/06/2019 03:34, Guido van Rossum wrote:
 > I don't actually know how viable this proposal is, but given that it's
 > being debated at some length, I'd like to put in my  opinion that *if*
 > we're going to define an operator that's (roughly) synonymous with
 > issubclass(), it should be '<:', which is used in other languages (e.g.
 > Scala) and notational systems (https://en.wikipedia.org/wiki/Subtyping).
 > Overloading '<=' would be easier to implement, but would also cause 
 > enough
 > confusion that I think we should avoid it at all cost.
 
 I rather strongly disagree.  We are describing a fairly standard 
 incomplete ordering, which makes the comparison operators completely 
 appropriate.  Adding new syntax for something that doesn't need it is 
 the thing likely to cause confusion.
>>> 
>>> 
>>> Indeed it would work the same way as set comparison does, if you interpret 
>>> a type as the set of its instances.
>>> 
>>> But I imagine that many Python users are not so familiar with this 
>>> abstraction level (even if they use isinstance() and issubclass() all day 
>>> long). Sometimes using a *different* operator is helpful to send a signal 
>>> to the reader that a *different* kind of thing is being manipulated -- sort 
>>> of like how you can tell that a collection is a list or a set by noticing 
>>> whether values are added using append() or add().
>>> 
>>> Type theorists apparently have chosen to use the <: notation, and 
>>> presumably for the same reason.
>> 
>> Theoretical, and Scala (and Haskell, C++, etc.), types are a different kind 
>> of thing from objects, meta-objects that can only be used in special 
>> meta-level computation, so using a different operator makes sense. It’s like 
>> using |- rather than -> in proofs in basic logic.
> 
> I'm not sure I agree. You can't compare numbers and strings in Python 3, but 
> we happily use + and <= for both. So the argument that different kinds of 
> objects need different operators feels like it doesn't get to the heart of 
> the matter here.

In Python, Integers, strings, and types are different _types_ of object, but 
they’re all the same _kind_. There’s just one syntax and one set of evaluation 
rules that apply to all types of values, including types themselves.

That’s what’s different from Scala, etc., where types are not the same kind of 
thing as values, and <: isn’t an operator on values that can be overloaded by 
the type, but a piece of special syntax used in completely different parts of 
the language grammar that only operate on types.

Sure, completely different syntax doesn’t absolutely require different spelling 
(see [] for indexing and specialization in Scala, or : in dict displays and 
compound statements in Python), but it usually implies it, at least as a 
default.

And sure, you can always add new operators as syntactic sugar even when they 
aren’t necessary, but it’s only occasionally a good idea.

>> In short, the key is that isinstance(type, type) is not even well-formed in 
>> type theory, but in Python, it’s guaranteed true.[1]
> 
> Is this any more bizarre than that s[0] == s[0][0] for any non-empty Python 
> string?

Lots of things are different between Python and Scala, and most of them are not 
bizarre. But that doesn’t mean they don’t have natural consequences. Variables 
not being lvalues isn’t bizarre, but it does imply, e.g., no equivalent to C++ 
operator=. And type being a type isn’t bizarre, but it does imply no need for 
separate syntax for type computation.

>> Sure, most people who want to write type-computation expressions often 
>> enough that they need operators, and who are familiar with the abstraction 
>> of types as sets, will be people who are familiar with type theory or Scala 
>> or Rank-N Haskell or whatever, and are likely to be more comfortable with <: 
>> syntax. And there’s already some special syntax for type-level computation 
>> (the class statement), so it’s not like it would be unprecedented. But most 
>> such people will also be sophisticated enough to avoid confusion when using 
>> <. And to write their own metaclass that defines __lt__ if they need it (or 
>> at least fetch one from PyPI and use it). Also. I think we’re talking about 
>> something only a smallish number of people will ever want to do, and then 
>> only pretty rarely, in the first place.
>> 
>> So I don’t think anything needs to be changed at all.
> 
> That's where I started. I also provided an argument that *if* something needs 
> to be changed it should *not* be to introduce <= for types.

I agree that <= is not as good a spelling as <: for subclass. But I don’t think 
it’s that bad; it’s more than good enough for the rare cas

[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?

[James Lu]

There is probably some existing python API you can hijack to make custom 
locals() and globals() work everywhere. Perhaps pdb and inspect.stack are good 
places to start; maybe there’s a PDB API to break on every new stack frame and 
maybe you can use inspect to do the proper assignment overrides. 

Python is a very layered language.

Sent from my iPhone

> On May 25, 2019, at 4:53 AM, Yanghao Hua  wrote:
> 
>> On Fri, May 24, 2019 at 10:34 PM Ricky Teachey  wrote:
>> 
>> You can do things like this with exec():
>> 
>> class SafeDict(dict):
>>curated_keys = {"a", "b", "c"}
>>def __setitem__(self, k, v):
>>if k not i self.curated_keys:
>>raise Exception(f"{k!r} key not allowed")
>>super().__setitem__(k, v)
>> 
>> locals_dict = SafeDict()
>> globals_dict = SafeDict()
>> 
>> exec("d=1", locals_dict, globals_dict)  # Exception: 'd' key not allowed
>> 
>> You can do all sorts of things using that technique, including the way 
>> assignment to variables is handled.
> 
> I see your point now. In this case user will need to write HDLs
> probably in below fashion:
> 
> class my_module:
>def __init__(self, input, output, ...):
>...
>def process(self):
>exec("signal = 5", locals, globals)
># compare this with: signal <== 5
> 
> I fully agree this can work, but also it doesn't seem to be any better
> looking than signal.next = 5. I think there are two important point
> here, first is to make HDL design feels as natural as possible and as
> pythonic as possible as well as leaving very little room for mistakes,
> second is to make HDL design at least as easy and as intuitive as in
> traditional HDLs. And when I see this can actually be achieved easily
> with less than 100 lines of CPython code changes I am tempted to give
> it a try (I am so in love with python ...).
> 
> The other thing I was thinking about is PEP572 assignment expression
> (a := b), if it could be modified to allow user override (e.g. via
> __assign__()), and allow it to be used without bracket like "y :=
> f(x)" if __assign__ is present in y. Then this is even aligned with
> Chisel's assignment operation and I'd be completely happy with it.
> ___
> 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
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/QBX47WW5PDA4G77MJ7HPSRMAHIRVXQRW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?

[James Lu]

Perhaps you should take a look at Dlang. Using opDispatch and a with statement 
and compile time code generation, you may be able to accomplish what you’re 
trying to do entirely in D.

> On May 24, 2019, at 4:05 AM, Yanghao Hua  wrote:
> 
>> On Fri, May 24, 2019 at 1:59 AM Steven D'Aprano  wrote:
>> 
>>> On Thu, May 23, 2019 at 06:23:31PM +0200, Yanghao Hua wrote:
>>> 
>>> Is this (<== and ==>) something can be made into CPython?
>> 
>> If it goes into CPython, eventually every other Python needs to do the
>> same.
>> 
>> Of course it *could* be put into Python, but you haven't given
>> sufficient justification for why it *should* be put into Python.
>> 
>> Why does your DSL need a seperate assignment operator? How is it
>> different from regular assignment?
>> 
>> Could you use __setitem__ instead?
>> 
>> Instead of this:
>> 
>>variable <== thing  # magic happens here
>> 
>> can you write this?
>> 
>>obj.variable = thing  # magic happens here
>> 
>> 
>> If your DSL is so different from Python that it needs new operators,
>> perhaps you should write an interpreter for your language and run that
>> seperately.
>> 
>>code = """
>>any syntax you like <- thing
>>"""
>>result = interpret(code)
> 
> Well, if python is not envisioned to be able to represent almost
> everything elegantly maybe I should indeed walk away from this idea.
> (This is sad for me ... I have been saying and believing python is
> envisioned that way for more than 20 years now). Your argument could
> be applied on PEP465 as well, where the only justification is to make
> matrix operation prettier. I have explained the problem of use
> descriptors in previous replies, where you cannot have a local signal,
> e.g. obj.signal = thing # works, but local_signal = thing # doesn't
> work.
> ___
> 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
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/5XE3WSGBJN6CTDNG55D3WUJD2BH2PUAC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Comparison operator support (>= and <=) for type

[Guido van Rossum]

On Mon, Jun 17, 2019 at 12:54 PM Andrew Barnert  wrote:

> On Jun 17, 2019, at 07:47, Guido van Rossum  wrote:
>
> On Mon, Jun 17, 2019 at 7:23 AM Rhodri James  wrote:
>
>> On 16/06/2019 03:34, Guido van Rossum wrote:
>> > I don't actually know how viable this proposal is, but given that it's
>> > being debated at some length, I'd like to put in my  opinion that *if*
>> > we're going to define an operator that's (roughly) synonymous with
>> > issubclass(), it should be '<:', which is used in other languages (e.g.
>> > Scala) and notational systems (https://en.wikipedia.org/wiki/Subtyping
>> ).
>> > Overloading '<=' would be easier to implement, but would also cause
>> enough
>> > confusion that I think we should avoid it at all cost.
>>
>> I rather strongly disagree.  We are describing a fairly standard
>> incomplete ordering, which makes the comparison operators completely
>> appropriate.  Adding new syntax for something that doesn't need it is
>> the thing likely to cause confusion.
>>
>
> Indeed it would work the same way as set comparison does, if you interpret
> a type as the set of its instances.
>
>
> But I imagine that many Python users are not so familiar with this
> abstraction level (even if they use isinstance() and issubclass() all day
> long). Sometimes using a *different* operator is helpful to send a signal
> to the reader that a *different* kind of thing is being manipulated -- sort
> of like how you can tell that a collection is a list or a set by noticing
> whether values are added using append() or add().
>
>
> Type theorists apparently have chosen to use the <: notation, and
> presumably for the same reason.
>
>
> Theoretical, and Scala (and Haskell, C++, etc.), types are a different
> kind of thing from objects, meta-objects that can only be used in special
> meta-level computation, so using a different operator makes sense. It’s
> like using |- rather than -> in proofs in basic logic.
>

I'm not sure I agree. You can't compare numbers and strings in Python 3,
but we happily use + and <= for both. So the argument that different kinds
of objects need different operators feels like it doesn't get to the heart
of the matter here.


> Python makes types first-class objects, and then uses normal value-level
> computation for everything. Conceptually, there’s no good reason not to
> extend that uniform syntax to uniform operators.
>

I just gave a good reason (signaling to the reader that we're in meta-land).


> In short, the key is that isinstance(type, type) is not even well-formed
> in type theory, but in Python, it’s guaranteed true.[1]
>

Is this any more bizarre than that s[0] == s[0][0] for any non-empty Python
string?


> Sure, most people who want to write type-computation expressions often
> enough that they need operators, and who are familiar with the abstraction
> of types as sets, will be people who are familiar with type theory or Scala
> or Rank-N Haskell or whatever, and are likely to be more comfortable with
> <: syntax. And there’s already some special syntax for type-level
> computation (the class statement), so it’s not like it would be
> unprecedented. But most such people will also be sophisticated enough to
> avoid confusion when using <. And to write their own metaclass that defines
> __lt__ if they need it (or at least fetch one from PyPI and use it). Also.
> I think we’re talking about something only a smallish number of people will
> ever want to do, and then only pretty rarely, in the first place.
>
> So I don’t think anything needs to be changed at all.
>

That's where I started. I also provided an argument that *if* something
needs to be changed it should *not* be to introduce <= for types.


> [1] Technically, this means Python’s type type isn’t a typed set, or even
> a well-founded set. This raises all kinds of interesting complications;
> someone could probably write a whole thesis on how to integrate
> anti-foundation and types. But practically, when programming in Python,
> it makes a lot of things simpler to think about, and the confusion almost
> never comes up and isn’t that hard to deal with when it does. It goes along
> with, e.g., types being their own constructor functions. And if lists can
> contain themselves, and so can sets (you have to subclass set or frozenset,
> but the result is a perfectly valid subtype), why not types?
>

Right. This seems immaterial to the discussion (looks like you've been
nerd-sniped :-).

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*

___
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/K6IMKQ4IAO3ATMANKR5OJ5BBY7VWZUK

[Python-ideas] Re: Comparison operator support (>= and <=) for type

[Andrew Barnert via Python-ideas]

On Jun 17, 2019, at 07:47, Guido van Rossum  wrote:
> 
>> On Mon, Jun 17, 2019 at 7:23 AM Rhodri James  wrote:
>> On 16/06/2019 03:34, Guido van Rossum wrote:
>> > I don't actually know how viable this proposal is, but given that it's
>> > being debated at some length, I'd like to put in my  opinion that *if*
>> > we're going to define an operator that's (roughly) synonymous with
>> > issubclass(), it should be '<:', which is used in other languages (e.g.
>> > Scala) and notational systems (https://en.wikipedia.org/wiki/Subtyping).
>> > Overloading '<=' would be easier to implement, but would also cause enough
>> > confusion that I think we should avoid it at all cost.
>> 
>> I rather strongly disagree.  We are describing a fairly standard 
>> incomplete ordering, which makes the comparison operators completely 
>> appropriate.  Adding new syntax for something that doesn't need it is 
>> the thing likely to cause confusion.
> 
> 
> Indeed it would work the same way as set comparison does, if you interpret a 
> type as the set of its instances.
> 
> But I imagine that many Python users are not so familiar with this 
> abstraction level (even if they use isinstance() and issubclass() all day 
> long). Sometimes using a *different* operator is helpful to send a signal to 
> the reader that a *different* kind of thing is being manipulated -- sort of 
> like how you can tell that a collection is a list or a set by noticing 
> whether values are added using append() or add().
> 
> Type theorists apparently have chosen to use the <: notation, and presumably 
> for the same reason.

Theoretical, and Scala (and Haskell, C++, etc.), types are a different kind of 
thing from objects, meta-objects that can only be used in special meta-level 
computation, so using a different operator makes sense. It’s like using |- 
rather than -> in proofs in basic logic.

Python makes types first-class objects, and then uses normal value-level 
computation for everything. Conceptually, there’s no good reason not to extend 
that uniform syntax to uniform operators.

In short, the key is that isinstance(type, type) is not even well-formed in 
type theory, but in Python, it’s guaranteed true.[1]

Sure, most people who want to write type-computation expressions often enough 
that they need operators, and who are familiar with the abstraction of types as 
sets, will be people who are familiar with type theory or Scala or Rank-N 
Haskell or whatever, and are likely to be more comfortable with <: syntax. And 
there’s already some special syntax for type-level computation (the class 
statement), so it’s not like it would be unprecedented. But most such people 
will also be sophisticated enough to avoid confusion when using <. And to write 
their own metaclass that defines __lt__ if they need it (or at least fetch one 
from PyPI and use it). Also. I think we’re talking about something only a 
smallish number of people will ever want to do, and then only pretty rarely, in 
the first place.

So I don’t think anything needs to be changed at all.


[1] Technically, this means Python’s type type isn’t a typed set, or even a 
well-founded set. This raises all kinds of interesting complications; someone 
could probably write a whole thesis on how to integrate anti-foundation and 
types. But practically, when programming in Python, it makes a lot of things 
simpler to think about, and the confusion almost never comes up and isn’t that 
hard to deal with when it does. It goes along with, e.g., types being their own 
constructor functions. And if lists can contain themselves, and so can sets 
(you have to subclass set or frozenset, but the result is a perfectly valid 
subtype), why not types?___
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/FRVWS7OBK42CXRGW7NC4ZW4JCX36W3BA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?

[Caleb Donovick]

> It's because Python doesn't actually have assignment to variables, it
> has binding to names.  So there's no "there" there to provide a
> definition of assignment.  In a class definition, the "local
> variables" are actually attributes of the class object.  That class
> object provides the "there", which in turn allows redefinition via a
> metaclass.

I understand this and while I would love to have metamodules and
metafunctions to provide me a 'there' that is for another thread.

I don't really want to change the semantic of =.  What Yanghao and I are
asking for is an in-place update/assign operator which isn't burdened with
numeric meaning.

Caleb Donovick

On Thu, Jun 13, 2019 at 1:42 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Caleb Donovick writes:
>
>  > In class bodies it is easy to redefine what assignment means, in
>  > every other context its very annoying, I don't see why that must be
>  > the case.
>
> It's because Python doesn't actually have assignment to variables, it
> has binding to names.  So there's no "there" there to provide a
> definition of assignment.  In a class definition, the "local
> variables" are actually attributes of the class object.  That class
> object provides the "there", which in turn allows redefinition via a
> metaclass.
>
> Of course this doesn't *have* to be the case.  But in Python it is.
> AFAICS making assignment user-definable would require the compiler to
> be able to determine the type of the LHS in every assignment statement
> in order to determine whether name binding is meant or the name refers
> to an object which knows how to assign to itself.  I don't see how to
> do that without giving up a lot of the properties that make Python
> Python, such as duck-typing.
>
> 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/GCICN3H22DB4JNK23ZX4TMGYESNBTVS4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Comparison operator support (>= and <=) for type

[Guido van Rossum]

On Mon, Jun 17, 2019 at 7:23 AM Rhodri James  wrote:

> On 16/06/2019 03:34, Guido van Rossum wrote:
> > I don't actually know how viable this proposal is, but given that it's
> > being debated at some length, I'd like to put in my  opinion that *if*
> > we're going to define an operator that's (roughly) synonymous with
> > issubclass(), it should be '<:', which is used in other languages (e.g.
> > Scala) and notational systems (https://en.wikipedia.org/wiki/Subtyping).
> > Overloading '<=' would be easier to implement, but would also cause
> enough
> > confusion that I think we should avoid it at all cost.
>
> I rather strongly disagree.  We are describing a fairly standard
> incomplete ordering, which makes the comparison operators completely
> appropriate.  Adding new syntax for something that doesn't need it is
> the thing likely to cause confusion.
>

Indeed it would work the same way as set comparison does, if you interpret
a type as the set of its instances.

But I imagine that many Python users are not so familiar with this
abstraction level (even if they use isinstance() and issubclass() all day
long). Sometimes using a *different* operator is helpful to send a signal
to the reader that a *different* kind of thing is being manipulated -- sort
of like how you can tell that a collection is a list or a set by noticing
whether values are added using append() or add().

Type theorists apparently have chosen to use the <: notation, and
presumably for the same reason.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*

___
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/GWA6ZF6FR3EAILVWYWEYDC5E5RCUUQTP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Comparison operator support (>= and <=) for type

[Rhodri James]

On 16/06/2019 03:34, Guido van Rossum wrote:

I don't actually know how viable this proposal is, but given that it's
being debated at some length, I'd like to put in my  opinion that *if*
we're going to define an operator that's (roughly) synonymous with
issubclass(), it should be '<:', which is used in other languages (e.g.
Scala) and notational systems (https://en.wikipedia.org/wiki/Subtyping).
Overloading '<=' would be easier to implement, but would also cause enough
confusion that I think we should avoid it at all cost.


I rather strongly disagree.  We are describing a fairly standard 
incomplete ordering, which makes the comparison operators completely 
appropriate.  Adding new syntax for something that doesn't need it is 
the thing likely to cause confusion.


--
Rhodri James *-* Kynesim Ltd
___
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/6RNW2SFNKGF53CIZGQXJ2LQG7OHD4WLO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add «iterate non-blocking» wrapper to prevent blocking loop too long

[Nikita Melentev]

What is the difference between your code and OP code?
___
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/B4YWBJBWL6FZKSEFADWBVFMCJMOZFZU7/
Code of Conduct: http://python.org/psf/codeofconduct/