Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #90297 > unrolled thread

Re: anomaly

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: anomaly Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-10 10:42 -0600
    Re: anomaly Rustom Mody <rustompmody@gmail.com> - 2015-05-10 09:48 -0700
      Re: anomaly Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-10 18:21 +0100
      Re: anomaly Gary Herron <gherron@digipen.edu> - 2015-05-10 10:28 -0700
        Re: anomaly Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-11 13:19 +1000
      Re: anomaly boB Stepp <robertvstepp@gmail.com> - 2015-05-10 14:12 -0500
        Re: anomaly Mel Wilson <mwilson@the-wire.com> - 2015-05-11 13:37 +0000
          Re: anomaly Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-12 02:35 +1000
            Re: anomaly Mel Wilson <mwilson@the-wire.com> - 2015-05-11 20:48 +0000
              Re: anomaly Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-12 12:18 +1000
      Re: anomaly Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-11 08:40 +0100
      Re: anomaly Chris Angelico <rosuav@gmail.com> - 2015-05-11 17:44 +1000
      Re: anomaly Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-05-11 12:15 +0200
        Re: anomaly John Ladasky <john_ladasky@sbcglobal.net> - 2015-05-12 17:47 -0700
          Re: anomaly Rustom Mody <rustompmody@gmail.com> - 2015-05-12 17:56 -0700
            Re: anomaly Paul Rubin <no.email@nospam.invalid> - 2015-05-12 19:16 -0700
              Re: anomaly Rustom Mody <rustompmody@gmail.com> - 2015-05-12 19:31 -0700
      Re: anomaly Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-11 11:40 +0100
      Re: anomaly Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-05-11 13:39 +0200
        Re: anomaly Marko Rauhamaa <marko@pacujo.net> - 2015-05-11 14:58 +0300
          Re: anomaly Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-05-11 15:27 +0200
            Re: anomaly Marko Rauhamaa <marko@pacujo.net> - 2015-05-11 17:03 +0300
              Re: anomaly zipher <dreamingforward@gmail.com> - 2015-05-11 07:56 -0700
                Re: anomaly Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-05-11 20:32 -0400
              Re: anomaly Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-05-12 13:34 +0200
            Re: anomaly Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-12 01:44 +1000
              Re: anomaly zipher <dreamingforward@gmail.com> - 2015-05-11 09:17 -0700
              Re: anomaly Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-05-11 20:33 -0400
              Re: anomaly Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-05-12 14:31 +0200
        Re: anomaly Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-11 22:34 +1000
          Re: anomaly Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-05-11 15:38 +0200
          Re: anomaly Chris Angelico <rosuav@gmail.com> - 2015-05-12 00:13 +1000
          Re: anomaly Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-05-12 17:37 +1200
          Re: anomaly Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-05-12 13:55 +0200
            Re: anomaly Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-12 23:56 +1000
              Re: anomaly zipher <dreamingforward@gmail.com> - 2015-05-12 08:34 -0700
                Re: anomaly Chris Angelico <rosuav@gmail.com> - 2015-05-13 01:43 +1000
                  Re: anomaly zipher <dreamingforward@gmail.com> - 2015-05-12 20:39 -0700
                Re: anomaly Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-12 17:19 +0100
                  Re: anomaly zipher <dreamingforward@gmail.com> - 2015-05-13 08:19 -0700
                Re: anomaly Skip Montanaro <skip.montanaro@gmail.com> - 2015-05-12 11:22 -0500
                  Re: anomaly Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-13 13:58 +1000
                Re: anomaly Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-12 12:07 -0600
              Re: anomaly Terry Reedy <tjreedy@udel.edu> - 2015-05-12 16:23 -0400
              Re: anomaly Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-05-13 09:07 +0200
            Re: anomaly Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-05-13 12:19 +1200
              Re: anomaly Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-05-13 09:23 +0200
          Re: anomaly Gary Herron <gherron@digipen.edu> - 2015-05-12 09:07 -0700
      Re: anomaly Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-11 12:47 +0100
      Re: anomaly boB Stepp <robertvstepp@gmail.com> - 2015-05-11 07:43 -0500
      Re: anomaly boB Stepp <robertvstepp@gmail.com> - 2015-05-11 07:26 -0500
    Re: anomaly zipher <dreamingforward@gmail.com> - 2015-05-10 17:48 -0700
      Re: anomaly Gary Herron <gherron@digipen.edu> - 2015-05-10 18:07 -0700
        Re: anomaly zipher <dreamingforward@gmail.com> - 2015-05-10 18:18 -0700
          Re: anomaly Chris Angelico <rosuav@gmail.com> - 2015-05-11 11:53 +1000
            Re: anomaly zipher <dreamingforward@gmail.com> - 2015-05-10 19:09 -0700
            Re: anomaly Rustom Mody <rustompmody@gmail.com> - 2015-05-10 19:12 -0700
              Re: anomaly Chris Angelico <rosuav@gmail.com> - 2015-05-11 12:20 +1000
          Re: anomaly BartC <bc@freeuk.com> - 2015-05-11 12:55 +0100

Page 1 of 3  [1] 2 3  Next page →

#90297 — Re: anomaly

On Sun, May 10, 2015 at 10:34 AM, Mark Rosenblitt-Janssen
<dreamingforward@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?

[toc] | [next] | [standalone]

#90298

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

[toc] | [prev] | [next] | [standalone]

#90301

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

[toc] | [prev] | [next] | [standalone]

#90302

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

[toc] | [prev] | [next] | [standalone]

#90338

On Mon, 11 May 2015 03:28 am, Gary Herron 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.

It's not really *bizarre* to expect that standard functions and types are
reserved words. That applies to many languages other than C, and is not
unique to the C family. E.g. it also applies to Fortran, and the Algol
family of languages.

There are advantages and disadvantages to allowing standard names be
redefined, and it should not surprise us that someone coming from another
language may be taken aback by the fact that

str = 23

doesn't give an error.

What is funny is that one might think it is a *bug* rather than a deliberate
feature, or perhaps misfeature. Python is well over 20 years old. If int
was intended to be a keyword, someone would have noticed by now :-)


> 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).

Don't use __builtins__ that is a private implementation detail. The correct
way to access the built-in namespace explicitly is:


import __builtin__ # Python 2
import builtins # Python 3




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#90355

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@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

[toc] | [prev] | [next] | [standalone]

#90379

On Sun, 10 May 2015 14:12:44 -0500, boB Stepp wrote:

> 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.

Read Cory Doctorow lately on the War Against General Purpose Computing, 
where a bunch of people who don't really understand are trying to make it 
impossible for any computer to do something that is The Wrong Thing.  Or 
gently approach the relevant computing theory through Doug Hofstadter's 
_Goedel, Escher, Bach_, or some essays in _Metamagical Themas_.  
Generally speaking, making a computer totally incapable of doing Wrong 
Things leaves it incapable of doing anything at all.

	Mel.

[toc] | [prev] | [next] | [standalone]

#90411

On Mon, 11 May 2015 11:37 pm, Mel Wilson wrote:

> On Sun, 10 May 2015 14:12:44 -0500, boB Stepp wrote:
> 
>> 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.
> 
> Read Cory Doctorow lately on the War Against General Purpose Computing,
> where a bunch of people who don't really understand are trying to make it
> impossible for any computer to do something that is The Wrong Thing.

I think you are conflating two different ideas of "the Wrong Thing".

One is a political view, driven almost entirely by a small subset of the
copyright industry. They are driven by fear of losing control, and greed.

But the other, the one Bob refers to, comes from the technical view that
writing correct code that does what you want is hard, and we need the help
of the compiler and programming language to do it.

Trivial and easy to make mistakes in coding shouldn't mean that your
computer gets taken over by criminals on the other side of the world and
used to send spam at your expense. Buffer overflows, integer overflow,
undefined behaviour in C, cross-site scripting attacks, SQL injection
attacks, the list goes on. Bugs in code are not only inconvenient and
expensive, they can literally kill.

The two ideas are completely unrelated.

The first group wants *outside parties* (the copyright cartels) to control
what you can do with your computer. They want to take away your control.

The second wants to give you tools which you can use to give you the control
you currently lack.

Right now, whatever computer you are running, there are probably anything up
to a couple of dozen ways that the NSA or criminal gangs can use to take
over your computer and use it against you. Some of the people reading this
message have already had their computer subverted and don't know it. (Some
know it, but don't care, out of either apathy, sheer irresponsibility, or
learned helplessness.)

Basically, human beings aren't clever enough to write bug-free code, and
those bugs mean that we lose control of our computers. (Sony once, and
infamously, actually used a Windows root kit to try to copy-protect some
music CDs.) We need better tools which extend our abilities to write
bug-free code, and those tools are new programming languages and code
analysis tools. They put us in control, they don't take it away.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#90421

On Tue, 12 May 2015 02:35:23 +1000, Steven D'Aprano wrote:

> On Mon, 11 May 2015 11:37 pm, Mel Wilson wrote:
> 
>> On Sun, 10 May 2015 14:12:44 -0500, boB Stepp wrote:
>> 
>>> 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.
>> 
>> Read Cory Doctorow lately on the War Against General Purpose Computing,
>> where a bunch of people who don't really understand are trying to make
>> it impossible for any computer to do something that is The Wrong Thing.
> 
> I think you are conflating two different ideas of "the Wrong Thing".

I don't think so.  A formal solution to a problem, i.e. a solution coded 
as a computer program, is limited to the things that can be done using 
formal techniques.  Whether it's people trying to enact their social 
standards in code, or whether it's people trying to nail the door shut 
against everything they "don't expect", or "think is illogical", the 
limits will still be there.

	Mel.

[toc] | [prev] | [next] | [standalone]

#90430

On Tue, 12 May 2015 06:48 am, Mel Wilson wrote:

> On Tue, 12 May 2015 02:35:23 +1000, Steven D'Aprano wrote:
> 
>> On Mon, 11 May 2015 11:37 pm, Mel Wilson wrote:
>> 
>>> On Sun, 10 May 2015 14:12:44 -0500, boB Stepp wrote:
>>> 
>>>> 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.
>>> 
>>> Read Cory Doctorow lately on the War Against General Purpose Computing,
>>> where a bunch of people who don't really understand are trying to make
>>> it impossible for any computer to do something that is The Wrong Thing.
>> 
>> I think you are conflating two different ideas of "the Wrong Thing".
> 
> I don't think so.  A formal solution to a problem, i.e. a solution coded
> as a computer program, is limited to the things that can be done using
> formal techniques.  Whether it's people trying to enact their social
> standards in code, or whether it's people trying to nail the door shut
> against everything they "don't expect", or "think is illogical", the
> limits will still be there.

Do you think that Python is part of Doctorow's war against general purpose
computing because it doesn't have a GOTO command?

Do you think that using Python reduces your control over your computer
because Python code has well-defined integer overflow behaviour?

When you have had a bug in your code, and Python has raised an exception
with a nice traceback and an informative error message, how many times have
you thought "I wish Python would just seg fault"?


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#90356

On 10/05/2015 20:12, boB Stepp wrote:
>
> On Sun, May 10, 2015 at 12:28 PM, Gary Herron <gherron@digipen.edu> wrote:
>
>> 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?
>
>

You need to understand that Python is so powerful that after 14 years I 
still can't wrap my mind around all of the possibilities that it offers.

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

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#90357

On Mon, May 11, 2015 at 5:12 AM, boB Stepp <robertvstepp@gmail.com> wrote:
>> 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?

The Zen of Python is a static document, a historical artifact of a
sort. But in terms of understanding the philosophy of Python, "we're
all adults here" is a big part of it. Once you grok the notion that
nothing can be prevented, you're freed from such considerations as:

* Obfuscating, encrypting, or otherwise hiding your source code
* Private members with restricted access
* Strict type checking, to prevent someone passing in a wrong piece of data
* Prevention of monkey-patching

etc, etc, etc. In actual fact, anyone can bypass any restriction, in
any language; and Python is just more open/honest about it than
languages like C++; for instance, instead of having true private
members where the compiler stops you from looking at or changing them,
Python gives you single-underscore-named attributes, where nobody
stops you from doing anything, but there's a general understanding
that they're not governed by the usual compatibility rules, so
upgrading a library might break your code. Happy with that? Go ahead
then, use the internals.

Hakuna matata, what a wonderful phrase.

ChrisA

[toc] | [prev] | [next] | [standalone]

#90360

Op 10-05-15 om 19:28 schreef Gary Herron:

> 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).

This is a common python myth. That is selectively used when convenient and
ignored when that is convenient.

Try overriding None, True or False in python3 and see what happens.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#90508

On Monday, May 11, 2015 at 3:16:16 AM UTC-7, Antoon Pardon wrote:

> Try overriding None, True or False in python3 and see what happens.

Much fun was able to be had in Python 2, though:

    Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
    [GCC 4.8.2] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> True = False
    >>> True
    False


Every politician's dream!

[toc] | [prev] | [next] | [standalone]

#90509

On Wednesday, May 13, 2015 at 6:17:41 AM UTC+5:30, John Ladasky wrote:
> On Monday, May 11, 2015 at 3:16:16 AM UTC-7, Antoon Pardon wrote:
> 
> > Try overriding None, True or False in python3 and see what happens.
> 
> Much fun was able to be had in Python 2, though:
> 
>     Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
>     [GCC 4.8.2] on linux2
>     Type "help", "copyright", "credits" or "license" for more information.
>     >>> True = False
>     >>> True
>     False
> 
> 
> Every politician's dream!

I actually had a use case for this [Or I am a politician]
Scheme had two True-s #T was the proper true and plain T was the legacy from
Lisp which was deprecated.
To make sure students would use #T and not T I had sneaked in somewhere
[dont exactly remember where/how] a
(set! T nil) 
ie T = nil

As far as I was concerned it was moving from deprecation to all-out error
However 2 decades later and some of those (victims) still remember:
You made TRUE into FALSE!!

[toc] | [prev] | [next] | [standalone]

#90513

Rustom Mody <rustompmody@gmail.com> writes:
> You made TRUE into FALSE!!

The answer is: yes!  Haskell can do that.

   Prelude> let 2+2=5 in 2+2
   5

[toc] | [prev] | [next] | [standalone]

#90516

On Wednesday, May 13, 2015 at 7:47:03 AM UTC+5:30, Paul Rubin wrote:
> Rustom Mody  writes:
> > You made TRUE into FALSE!!
> 
> The answer is: yes!  Haskell can do that.
> 
>    Prelude> let 2+2=5 in 2+2
>    5

:-)

And we come back to the OP.
It *looks* like this is some profound question about OO-philosophy
But name-resolution has happened before that and in an unexpected fashion

Like puzzling over a strange printf behavior in C
And not noticing that the compiler-call was
$ gcc -Dprintf=puts ...

[toc] | [prev] | [next] | [standalone]

#90361

On 11/05/2015 11:15, Antoon Pardon wrote:
> Op 10-05-15 om 19:28 schreef Gary Herron:
>
>> 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).
>
> This is a common python myth. That is selectively used when convenient and
> ignored when that is convenient.
>
> Try overriding None, True or False in python3 and see what happens.
>

According to 
https://docs.python.org/3/reference/lexical_analysis.html#keywords None, 
True and False are all keywords in Python 3, int isn't as I believe has 
already been pointed out.

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

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#90362

Op 11-05-15 om 12:40 schreef Mark Lawrence:
> On 11/05/2015 11:15, Antoon Pardon wrote:
>> Op 10-05-15 om 19:28 schreef Gary Herron:
>>
>>> 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).
>>
>> This is a common python myth. That is selectively used when
>> convenient and
>> ignored when that is convenient.
>>
>> Try overriding None, True or False in python3 and see what happens.
>>
>
> According to
> https://docs.python.org/3/reference/lexical_analysis.html#keywords
> None, True and False are all keywords in Python 3, int isn't as I
> believe has already been pointed out.
>
Which is exactly the point! They were turned into keywords because the
developers didn't want to allow them being overridden. There is no
a priori reason why we should turn "True" into a keyword and allow
"int" in the builtins.

We are only allowed to be adults, for as far as the developers let us.
They allow us to be adults with regards to "int" but they don't allow
us to be adults with regards to "True".

Defending "int" being overridable by declating "We're all adults" is
being selective.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#90367

Antoon Pardon <antoon.pardon@rece.vub.ac.be>:

> Which is exactly the point! They were turned into keywords because the
> developers didn't want to allow them being overridden. There is no a
> priori reason why we should turn "True" into a keyword and allow "int"
> in the builtins.
>
> We are only allowed to be adults, for as far as the developers let us.
> They allow us to be adults with regards to "int" but they don't allow
> us to be adults with regards to "True".
>
> Defending "int" being overridable by declating "We're all adults" is
> being selective.

I'm still failing to see the point. What problem are you having a
difficulty solving?


Marko

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web