anomaly

classic Classic list List threaded Threaded
84 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

anomaly

zipher
Here's something that might be wrong in Python (tried on v2.7):

>>> class int(str): pass

>>> int(3)
'3'

Mark


Reply | Threaded
Open this post in threaded view
|

anomaly

Ian Kelly-2
On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen
<dreamingforward at gmail.com> wrote:
> Here's something that might be wrong in Python (tried on v2.7):
>
>>>> class int(str): pass

This defines a new class named "int" that is a subclass of str. It has
no relation to the builtin class int.

>>>> int(3)
> '3'

This creates an instance of the above "int" class, which is basically
equivalent to calling "str(3)".

Were you expecting a different result?


Reply | Threaded
Open this post in threaded view
|

anomaly

Rustom Mody
In reply to this post by zipher
On Sunday, May 10, 2015 at 10:14:36 PM UTC+5:30, Ian wrote:

> On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen wrote:
> > Here's something that might be wrong in Python (tried on v2.7):
> >
> >>>> class int(str): pass
>
> This defines a new class named "int" that is a subclass of str. It has
> no relation to the builtin class int.
>
> >>>> int(3)
> > '3'
>
> This creates an instance of the above "int" class, which is basically
> equivalent to calling "str(3)".
>
> Were you expecting a different result?

In C (family) languages int is a keyword
>From that pov this is completely bizarre


Reply | Threaded
Open this post in threaded view
|

anomaly

Terry Reedy
In reply to this post by zipher
On 5/10/2015 12:34 PM, Mark Rosenblitt-Janssen wrote:
> Here's something that might be wrong in Python (tried on v2.7):

You are being hypnotized by the fact the 'int' is a builtin name.
Builtin names are not keywords and can intentionally be rebound.  If you
rebind randomly, the result may seem strange, but is predictable.  This
is why be recommend not randomly reusing names of builtins.

>>>> class int(str): pass

This in effect rebinds 'int' to the str class.  The work 'int' no longer
has any connect to the builtin integer class.

>>>> int(3)

Equivalent to str(3)

> '3'

No surprise that str(3) == '3'.

Replace 'int' with anything else, such as 'zyz' or 'Mark' in both
statements and the result is the same.

--
Terry Jan Reedy



Reply | Threaded
Open this post in threaded view
|

anomaly

Mark Lawrence
In reply to this post by Rustom Mody
On 10/05/2015 17:48, Rustom Mody wrote:

> On Sunday, May 10, 2015 at 10:14:36 PM UTC+5:30, Ian wrote:
>> On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen wrote:
>>> Here's something that might be wrong in Python (tried on v2.7):
>>>
>>>>>> class int(str): pass
>>
>> This defines a new class named "int" that is a subclass of str. It has
>> no relation to the builtin class int.
>>
>>>>>> int(3)
>>> '3'
>>
>> This creates an instance of the above "int" class, which is basically
>> equivalent to calling "str(3)".
>>
>> Were you expecting a different result?
>
> In C (family) languages int is a keyword
>  From that pov this is completely bizarre
>

This is a news group for a language called Python.  Why do people keep
coming here expecting it to behave in the same way that (say) CORAL
66/250 does?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence



Reply | Threaded
Open this post in threaded view
|

anomaly

Gary Herron-2
In reply to this post by Rustom Mody
On 05/10/2015 09:48 AM, Rustom Mody wrote:

> On Sunday, May 10, 2015 at 10:14:36 PM UTC+5:30, Ian wrote:
>> On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen wrote:
>>> Here's something that might be wrong in Python (tried on v2.7):
>>>
>>>>>> class int(str): pass
>> This defines a new class named "int" that is a subclass of str. It has
>> no relation to the builtin class int.
>>
>>>>>> int(3)
>>> '3'
>> This creates an instance of the above "int" class, which is basically
>> equivalent to calling "str(3)".
>>
>> Were you expecting a different result?
> In C (family) languages int is a keyword
>  From that pov this is completely bizarre

Not really.  Expecting Python to act like C family languages *is* bizarre.

Common Python thought::  "We're all adults here."    If you want to
override a builtin within your own namespace, who are we to stop you?
Besides, it's still available as __builtins__.int  (unless you've also
overridden that).

--
Dr. Gary Herron
Department of Computer Science
DigiPen Institute of Technology
(425) 895-4418



Reply | Threaded
Open this post in threaded view
|

anomaly

boB Stepp
I am in process learning Python and normally hang out on the Tutor
list, but monitor this one hoping to learn what I can. This thread is
of interest to me from the standpoint of trying to understand the
Python way of doing things.

On Sun, May 10, 2015 at 12:28 PM, Gary Herron <gherron at digipen.edu> wrote:

> On 05/10/2015 09:48 AM, Rustom Mody wrote:
>>
>> On Sunday, May 10, 2015 at 10:14:36 PM UTC+5:30, Ian wrote:
>>>
>>> On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen wrote:
>>>>
>>>> Here's something that might be wrong in Python (tried on v2.7):
>>>>
>>>>>>> class int(str): pass
>>>
>>> This defines a new class named "int" that is a subclass of str. It has
>>> no relation to the builtin class int.
>>>
>>>>>>> int(3)
>>>>
>>>> '3'
>>>
>>> This creates an instance of the above "int" class, which is basically
>>> equivalent to calling "str(3)".
>>>
>>> Were you expecting a different result?
>>
>> In C (family) languages int is a keyword
>>  From that pov this is completely bizarre
>
>
> Not really.  Expecting Python to act like C family languages *is* bizarre.

I have to admit being surprised by this, too. I am just now studying
on how to write my own classes in Python, and have come to realize
that doing this is *possible*, but the *surprise* to me is why the
language design allowed this to actually be done.

> Common Python thought::  "We're all adults here."    If you want to override
> a builtin within your own namespace, who are we to stop you?

I'm surprised that this thought has not been added to the "Zen Of
Python", as I see it as more and more recurrent as I continue my
studies. What I would like to comprehend is what is the essential
mindset of Python? That is, what do I need to understand, so that I am
no longer likely to be surprised by discovering new possibilities in
Python such as what the current thread is discussing?


--
boB


Reply | Threaded
Open this post in threaded view
|

anomaly

zipher
In reply to this post by zipher
Here's where this exploration came from.  I've (once again) been
contemplating the OO nature.

It's clear to me that there needs to be a distinction between
specialization of an object vs. expansion of an object (a new term I'm
proposing to the OOP lexicon).  The latter *adds* more functionality
(like what everyone does with the Object class), while the former
changes the behavior of some class for more specific behavior that was
not programmed in the original class.

It's a difference between, for example, concrete base types and ABCs.
Python artificially tried to make int inherit from object, just
because it can, but this is wrong.  It`s messed with the Zen-thing.
"Purity has hammered practicality [like the fact that we actually have
to work on concrete types in the CPU] into the ground. " (addition
mine).

Sorry I can't spend more time clarifying.  I hope that there's at
least one person who sees the issue.

Mark



On 5/10/15, Mark Rosenblitt-Janssen <dreamingforward at gmail.com> wrote:
> Here's something that might be wrong in Python (tried on v2.7):
>
>>>> class int(str): pass
>
>>>> int(3)
> '3'
>
> Mark
>


Reply | Threaded
Open this post in threaded view
|

anomaly

zipher
Along those lines, it makes no sense for mix-in classes to inherit
from Object at all -- they're neither expanding on object nor
specializing it.

For example, I'm refactoring my python Graph class so that people can
have different Vertex behaviors by using different composition of
mix-in classes.  But instead of letting them figure out the object
inheritence order (so there's no conflicts), I'm going to make some
classes that pre-specify the right ordering for different
combiniations of behaviors.

class Vertex(object):
    """Basic Vertex base class, giving a dictionary of edges.""""

class WVertex(Vertex, weighted_mixin):  #the weighted_mixin will
override some of the methods in Vertex.
    """Use this when initializing a Graph class for weighted edges."""

class RWVertex(WVertex, reverse_edge_mixin):
    """Use this class for O(1) access to the edges coming into Vertices."""

class Graph(dict):

    def __init__(self, init={}, VertexType=Vertex):
        """Creates a Graph with the specified behaviors within VertexType."""

-----
No one has to see the mix-in classes.

I'm inventing a new term for this kind of inheritence:  expansion.
I've enclosed one class inside of another, but yet it's not quite
"encapsulation" (in the C++ sense).

Cheers,

Mark J
----
http://wiki.hackerspaces.org/Hacking_with_the_Tao


On 5/10/15, Mark Rosenblitt-Janssen <dreamingforward at gmail.com> wrote:

> Here's where this exploration came from.  I've (once again) been
> contemplating the OO nature.
>
> It's clear to me that there needs to be a distinction between
> specialization of an object vs. expansion of an object (a new term I'm
> proposing to the OOP lexicon).  The latter *adds* more functionality
> (like what everyone does with the Object class), while the former
> changes the behavior of some class for more specific behavior that was
> not programmed in the original class.
>
> It's a difference between, for example, concrete base types and ABCs.
> Python artificially tried to make int inherit from object, just
> because it can, but this is wrong.  It`s messed with the Zen-thing.
> "Purity has hammered practicality [like the fact that we actually have
> to work on concrete types in the CPU] into the ground. " (addition
> mine).
>
> Sorry I can't spend more time clarifying.  I hope that there's at
> least one person who sees the issue.
>
> Mark
>
>
>
> On 5/10/15, Mark Rosenblitt-Janssen <dreamingforward at gmail.com> wrote:
>> Here's something that might be wrong in Python (tried on v2.7):
>>
>>>>> class int(str): pass
>>
>>>>> int(3)
>> '3'
>>
>> Mark
>>
>


Reply | Threaded
Open this post in threaded view
|

anomaly

Mark Lawrence
In reply to this post by zipher
On 10/05/2015 23:59, Mark Rosenblitt-Janssen wrote:

> On 5/10/15, Mark Rosenblitt-Janssen <dreamingforward at gmail.com> wrote:
>> Here's something that might be wrong in Python (tried on v2.7):
>>
>>>>> class int(str): pass
>>
>>>>> int(3)
>> '3'
>>
>> Mark
>>
> Here's where this exploration came from.  I've (once again) been
> contemplating the OO nature.
>
> It's clear to me that there needs to be a distinction between
> specialization of an object vs. expansion of an object (a new term I'm
> proposing to the OOP lexicon).  The latter *adds* more functionality
> (like what everyone does with the Object class), while the former
> changes the behavior of some class for more specific behavior that was
> not programmed in the original class.
>
> It's a difference between, for example, concrete base types and ABCs.
> Python artificially tried to make int inherit from object, just
> because it can, but this is wrong.  It`s messed with the Zen-thing.
> "Purity has hammered practicality [like the fact that we actually have
> to work on concrete types in the CPU] into the ground. " (addition
> mine).
>
> Sorry I can't spend more time clarifying.  I hope that there's at
> least one person who sees the issue.
>
> Mark
>

It strikes me that you haven't a clue about Python and worse still
you're top posting, please don't.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence



Reply | Threaded
Open this post in threaded view
|

anomaly

zipher
In reply to this post by zipher
In case the example given at the start of the thread wasn't
interesting enough, it also works in the other direction:

>>> class str(int):  pass

>>> str('2')
2  #<----- an integer!!!

Mark


Reply | Threaded
Open this post in threaded view
|

anomaly

Mark Lawrence
On 11/05/2015 01:14, Mark Rosenblitt-Janssen wrote:

> In case the example given at the start of the thread wasn't
> interesting enough, it also works in the other direction:
>
>>>> class str(int):  pass
>
>>>> str('2')
> 2  #<----- an integer!!!
>
> Mark
>

Thanks for this, I've not found anybody new for my dream team in months.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence



Reply | Threaded
Open this post in threaded view
|

anomaly

zipher
In reply to this post by zipher
On Sunday, May 10, 2015 at 11:44:36 AM UTC-5, Ian wrote:

> On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen
> <dreamingforward at gmail.com> wrote:
> > Here's something that might be wrong in Python (tried on v2.7):
> >
> >>>> class int(str): pass
>
> This defines a new class named "int" that is a subclass of str. It has
> no relation to the builtin class int.
>
> >>>> int(3)
> > '3'
>
> This creates an instance of the above "int" class, which is basically
> equivalent to calling "str(3)".
>
> Were you expecting a different result?

Sorry, yes.  If you're going to define a concept called "keywords", I don't think you should allow them to be shadowed by a class definition.

Mark


Reply | Threaded
Open this post in threaded view
|

anomaly

zipher
In reply to this post by zipher
On Sunday, May 10, 2015 at 7:20:13 PM UTC-5, Mark Lawrence wrote:

> On 11/05/2015 01:14, Mark Rosenblitt-Janssen wrote:
> > In case the example given at the start of the thread wasn't
> > interesting enough, it also works in the other direction:
> >
> >>>> class str(int):  pass
> >
> >>>> str('2')
> > 2  #<----- an integer!!!
> >
> > Mark
> >
>
> Thanks for this, I've not found anybody new for my dream team in months.

Sorry, I forgot I unsubscribed from the mailing list and didn't see any replies and deduced that no one had noticed anything unexpected about the idea.

I guess everyone expects this behavior since Python implemented this idea of "everything is an object", but I think this branch of OOP (on the branch of the Tree of Programming Languages) has to be chopped off.  The idea of everything is an object is backwards (unless your in a LISP machine).  Like I say, it's trying to be too pure and not practical.

Whatever,

Mark


Reply | Threaded
Open this post in threaded view
|

anomaly

Gary Herron-2
In reply to this post by zipher
On 05/10/2015 05:48 PM, zipher wrote:

> On Sunday, May 10, 2015 at 11:44:36 AM UTC-5, Ian wrote:
>> On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen
>> <dreamingforward at gmail.com> wrote:
>>> Here's something that might be wrong in Python (tried on v2.7):
>>>
>>>>>> class int(str): pass
>> This defines a new class named "int" that is a subclass of str. It has
>> no relation to the builtin class int.
>>
>>>>>> int(3)
>>> '3'
>> This creates an instance of the above "int" class, which is basically
>> equivalent to calling "str(3)".
>>
>> Were you expecting a different result?
> Sorry, yes.  If you're going to define a concept called "keywords", I don't think you should allow them to be shadowed by a class definition.
>
> Mark

Huh?   Python has plenty of keywords, and indeed, none of them can be
redefined or shadowed.    But you would gain nothing (and lose a bit or
dynamic-language freedom) by making int a keyword.

--
Dr. Gary Herron
Department of Computer Science
DigiPen Institute of Technology
(425) 895-4418



Reply | Threaded
Open this post in threaded view
|

anomaly

zipher
In reply to this post by zipher
> Huh?   Python has plenty of keywords, and indeed, none of them can be
> redefined or shadowed.    But you would gain nothing (and lose a bit or
> dynamic-language freedom) by making int a keyword.

Okay.  I apologize for thinking in C and believing "int" was a keyword.  It isn't in Python as you remind me.  However, this is where I'm arguing the purity has hammered practicality into the ground.

Python is trying to be as elegant as LISP in trying to make everything an Object.  It's not necessary, and it's trying to put lipstick on a pig instead of making BBQ.  Python will be as elegant, but in a different direction of the axis.

That difference is exactly like how Philosophy is different from Math -- both require logic, but go in different directions with it.  Python makes classes, when LISP tries to make classes to try to be like C++ it also looks equally stupid.  So don't do it.  Let them be different specializations.

mark


Reply | Threaded
Open this post in threaded view
|

anomaly

Chris Angelico
On Mon, May 11, 2015 at 11:18 AM, zipher <dreamingforward at gmail.com> wrote:
> Okay.  I apologize for thinking in C and believing "int" was a keyword.  It isn't in Python as you remind me.  However, this is where I'm arguing the purity has hammered practicality into the ground.
>
> Python is trying to be as elegant as LISP in trying to make everything an Object.  It's not necessary, and it's trying to put lipstick on a pig instead of making BBQ.  Python will be as elegant, but in a different direction of the axis.
>

How is it a problem for an integer to be an object? In Python, I can
put together a generic handler for a generic list and depend on
everything being an object:

lst = ["asdf", 2, lambda x: x+1, re.compile("q[a-tv-z]"), 3.14159]

In Java, I would have to box up that integer 2 and that float 3.14159
(and maybe the string too?) to make it possible to put them into a
generic collection, because integers and objects are fundamentally
different things. In Python, ints and floats and strings all follow
the same rules as other objects: they can be passed around, stored in
collections, turned into strings with str() or repr(), etc, etc, etc.
They have methods, they react to operators, everything is done
according to a simple set of rules. This does not harm practicality -
it's extremely helpful in a number of situations.

And I still don't see how this has anything to do with your confusion
about shadowing the name 'int'. As I see it, attempting to redefine
int to be a null subclass of str should have one of two results:
either it's a straight-up error, or it does exactly what happens in
Python - calling 'int' now calls a subclass of 'str'.

ChrisA


Reply | Threaded
Open this post in threaded view
|

anomaly

zipher
In reply to this post by zipher
> > Okay.  I apologize for thinking in C and believing "int" was a keyword.  It isn't in Python as you remind me.  However, this is where I'm arguing the purity has hammered practicality into the ground.
> >
> > Python is trying to be as elegant as LISP in trying to make everything an Object.  It's not necessary, and it's trying to put lipstick on a pig instead of making BBQ.  Python will be as elegant, but in a different direction of the axis.
>
> How is it a problem for an integer to be an object?

It's not any more of a problem than trying to put lipstick on a pig, but at some point the pig might complain.  In this case, it has to be faced that an integer is a very concrete type -- because we're not running on a Symbolics Machine.  

Once again, Church's Thesis is misinforming people -- it doesn't matter that you can do everything on everything -- at some point the rubber has to hit the road and in Python, when I use an int, I expect some guarantee of O(log n) behavior, because I assume the dev team hasn't done something stupid, like implement bigints in LISP.

> In Python, I can
> put together a generic handler for a generic list and depend on
> everything being an object:
>
> lst = ["asdf", 2, lambda x: x+1, re.compile("q[a-tv-z]"), 3.14159]

Okay, Chris, now you've made a pig out of lipstick.  The lipstick is lambda expressions.  We already know the BDFL opinion of them.  The pig is whatever that toy problem you just concocted is supposed to do.

> In Java, I would have to box up that integer 2 and that float 3.14159
> (and maybe the string too?) to make it possible to put them into a
> generic collection, because integers and objects are fundamentally
> different things.

No. Yes!? I mean no!  They are different, but it's a type, even though (in this thought experiment) it's not an object.  And types can be put into collections (hey just like C++!).

> In Python, ints and floats and strings all follow
> the same rules as other objects: they can be passed around, stored in
> collections, turned into strings with str() or repr(), etc, etc, etc.

But Chris, you are forgetting:  Python could do all this before the type/class unification.

> They have methods, they react to operators, everything is done
> according to a simple set of rules. This does not harm practicality -
> it's extremely helpful in a number of situations.

But you are infected with script-mind.  Scriptmind is a disease, where no one worries about the underlying architecture or the effects on machine performance.  This is fine for the web, but not for CPython.  Many lost souls have gone the way of Javascript and been infected.  Perhaps you are one of them.
 
> And I still don't see how this has anything to do with your confusion
> about shadowing the name 'int'. As I see it, attempting to redefine
> int to be a null subclass of str should have one of two results:
> either it's a straight-up error, or it does exactly what happens in
> Python - calling 'int' now calls a subclass of 'str'.

It just blurs conceptual boundaries, something I call "SeparabilityOfDomains".

Mark


Reply | Threaded
Open this post in threaded view
|

anomaly

Rustom Mody
In reply to this post by zipher
On Monday, May 11, 2015 at 7:23:44 AM UTC+5:30, Chris Angelico wrote:
> And I still don't see how this has anything to do with your confusion
> about shadowing the name 'int'.

Speaking as a compiler-writer -- everything :-)

In C 'int' is tagged off as different from 'myvar' earlier than say
'myvar' is different from 'printf'. The "define" in "#define" even earlier

Python sure has different rules of such 'tagging-off'
However all programming languages are the same in that you cant 'do semantics'
until you have finished 'doing syntax'
And name resolution is in a fuzzy area between the two --
Ask a theoretician about 'type-checking' and you will  hear: "This is just
context-sensitive syntax"
Ask a compiler-writer and you get: "Part of the semantic analysis module"


Reply | Threaded
Open this post in threaded view
|

anomaly

Chris Angelico
On Mon, May 11, 2015 at 12:12 PM, Rustom Mody <rustompmody at gmail.com> wrote:

> On Monday, May 11, 2015 at 7:23:44 AM UTC+5:30, Chris Angelico wrote:
>> And I still don't see how this has anything to do with your confusion
>> about shadowing the name 'int'.
>
> Speaking as a compiler-writer -- everything :-)
>
> In C 'int' is tagged off as different from 'myvar' earlier than say
> 'myvar' is different from 'printf'. The "define" in "#define" even earlier
>
> Python sure has different rules of such 'tagging-off'
> However all programming languages are the same in that you cant 'do semantics'
> until you have finished 'doing syntax'
> And name resolution is in a fuzzy area between the two --
> Ask a theoretician about 'type-checking' and you will  hear: "This is just
> context-sensitive syntax"
> Ask a compiler-writer and you get: "Part of the semantic analysis module"

Right, I understand that 'int' may be a keyword... but that would mean
it's impossible to run the OP's code anyway. If "class int(str): pass"
works, it can't really do anything other than redefine the name "int"
to indicate a null subclass of "str" - or is there something else I've
missed?

ChrisA


12345