On 3/2/17, Stephan Houben wrote:
> A crucial difference between a set and a type is that you cannot
> explicitly iterate over the elements of a type, so while we could implement
>
> x in int
>
> to do something useful, we cannot make
>
> for x in int:
>print(x)
>
>
-1.
It is already possible to specify what
inst in cls
means by using a metaclass. For example:
class Color(enum.Enum):
RED = 1
GREEN = 2
BLUE = 3
some_var = Color.GREEN
some_var in Color # True
some_var in enum.Enum # False
Containment != isinstance()
--
By itself, I don't see using the ``in`` syntax to check for ``instanceof`` as a
big benefit, given the overhead of learning that new concept. However, given in
the light of a bigger concept, I think it may make more sense.
If we accept that it may be desirable to work with types as set-like
On Fri, Mar 3, 2017 at 12:44 AM, Steven D'Aprano wrote:
> Compare to the OP's suggestion:
>
> 23 in int
>
> This doesn't even make sense unless you have been exposed to a very
> small subset of theoretical computer science which treats classes as
> sets and instances as
On Thu, Mar 02, 2017 at 04:23:08AM +0100, Jürgen A. Erhard wrote:
> > The OP seems to be proposing that we reflect this identity between
> > types and sets in Python by spelling "isinstance(obj, T)" as "obj in
> > T" and "issubclass(S, T)" as "S <= T". This proposal has some solid
> > theory
> On 2017 Mar 2 , at 2:53 a, Stephan Houben wrote:
>
> A crucial difference between a set and a type is that you cannot
> explicitly iterate over the elements of a type, so while we could implement
>
> x in int
>
> to do something useful, we cannot make
>
> for x in
This suggestion is really problematic IMHO.
"isinstance" is a nominal check. I can't ask "isinstance(x, Callable[int,
int])" because that would imply solving the halting problem. so
"isinstance(x, Y)" does not mean "is it true that x is an element of the
type Y" but rather "is it true that x was
A crucial difference between a set and a type is that you cannot
explicitly iterate over the elements of a type, so while we could implement
x in int
to do something useful, we cannot make
for x in int:
print(x)
Because if we could, we could implement Russell's paradox in Python:
R = set(x
On 3/1/17, Steven D'Aprano wrote:
> On Wed, Mar 01, 2017 at 07:02:23AM +0800, 语言破碎处 wrote:
>>
>> where we use types?
>> almost:
>> isinstance(obj, T);
>> # issubclass(S, T);
>>
>> Note that TYPE is SET;
>
> What does that mean? I don't understand.
Maybe
On Tue, Feb 28, 2017 at 03:35:31PM -0800, Jelle Zijlstra wrote:
> 2017-02-28 15:12 GMT-08:00 Steven D'Aprano :
> > On Wed, Mar 01, 2017 at 07:02:23AM +0800, 语言破碎处 wrote:
> >>
> >> where we use types?
> >> almost:
> >> isinstance(obj, T);
> >> #
On 2/28/2017 6:35 PM, Jelle Zijlstra wrote:
2017-02-28 15:12 GMT-08:00 Steven D'Aprano :
On Wed, Mar 01, 2017 at 07:02:23AM +0800, 语言破碎处 wrote:
where we use types?
almost:
isinstance(obj, T);
# issubclass(S, T);
Note that TYPE is SET;
What does that
2017-02-28 15:12 GMT-08:00 Steven D'Aprano :
> On Wed, Mar 01, 2017 at 07:02:23AM +0800, 语言破碎处 wrote:
>>
>> where we use types?
>> almost:
>> isinstance(obj, T);
>> # issubclass(S, T);
>>
>> Note that TYPE is SET;
>
> What does that mean? I don't
where we use types?
almost:
isinstance(obj, T);
# issubclass(S, T);
Note that TYPE is SET;
if we add __contains__ and __le__ into "type",
then things become:
obj in T;
# S <= T; # if only not misleading to a total ordering
example:
def
13 matches
Mail list logo