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 3 of 3 — ← Prev page 1 2 [3]

#90465

On Tue, May 12, 2015 at 10:34 AM, zipher <dreamingforward@gmail.com> wrote:
>> The general principle here is of consenting adults: Python allows you to
>> shadow built-ins because sometimes it is useful, and the good outweighs the
>> potential harm.
>
> I think you'll have to give examples, either from the developer community or some significant use cases to be believable.

http://docs.python-guide.org/en/latest/writing/style/#we-are-all-responsible-users
http://stackoverflow.com/questions/14168791/actual-implementation-of-private-variables-in-python-class

I'll leave it for you to rummage around in old Python posts for actual
posts by Guido where he has stated, "we're all adults here".

I did find this interesting blog post about encapsulation and
test-driven development:

https://jasonmbaker.wordpress.com/2009/01/08/enemies-of-test-driven-development-part-i-encapsulation/

I found the author's perspective interesting.

S

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

#90525

On Wednesday 13 May 2015 02:22, Skip Montanaro wrote:

> I did find this interesting blog post about encapsulation and
> test-driven development:
> 
> https://jasonmbaker.wordpress.com/2009/01/08/enemies-of-test-driven-
development-part-i-encapsulation/
> 
> I found the author's perspective interesting.


Very nice!



-- 
Steve

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

#90474

On Tue, May 12, 2015 at 9:34 AM, zipher <dreamingforward@gmail.com> wrote:
>> * when it comes to built-in functions (e.g. sum, map, pow)
>>   and types (e.g. int, str, list) there are significant and
>>   important use-cases for allowing shadowing;
>
> Name one "significant and important" use case for shadowing built-in types.  Functions, I don't have a problem with, but types are more fundamental than functions.

try:
    str = unicode  # Use the Python 3 name.
except NameError:
    pass

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

#90492

On 5/12/2015 9:56 AM, Steven D'Aprano wrote:

> The consensus among the core developers is:
>
> * in general, the harm and inconvenience from accidentally
>    shadowing built-ins is not great, and it usually easy to
>    spot, debug and prevent;
>
> * when it comes to built-in functions (e.g. sum, map, pow)
>    and types (e.g. int, str, list) there are significant and
>    important use-cases for allowing shadowing;
>
>    (e.g. the built-in sum function shouldn't prevent other
>    modules from providing their own sum function)
>
> * but when it comes to None, True and False, there are no
>    significant or important use-cases for shadowing (it is
>    almost always a bug, not a feature, to redefine None).
>
> The general principle here is of consenting adults: Python allows you to
> shadow built-ins because sometimes it is useful, and the good outweighs the
> potential harm. There are a handful of exceptions to that general principle
> (e.g. None, True, False, I can't think of any others) because in those
> cases the harm (as tiny as it is) outweighs the good.

Having followed Python development for 18 years, I think this is a fair 
summary.



-- 
Terry Jan Reedy

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

#90533

Op 12-05-15 om 15:56 schreef Steven D'Aprano:

> On Tue, 12 May 2015 09:55 pm, Antoon Pardon wrote:
>
>> Op 11-05-15 om 16:13 schreef Chris Angelico:
>>
>>> Why does Python have most built-ins as simply looked-up names that can
>>> be overridden? Because otherwise, there would be a veritable ton of
>>> keywords:
>> But that doesn't answer the question why the developers chose "True" to be
>> a keyword and "int" to be a looked-up name.
> No it doesn't. But then, nobody until now has *asked* that question, merely
> commented on it as a fact.

Whether the question was asked or not is unimportant. Somebody felt the
some need for justification, because otherwise there was no need to
mentions this fact. There are thousands of facts about python, so 
why mention this and not an other? Not because he wanted to mention
a fact but because he wanted to make a point and that point was bogus.

> If you go all the way back to Python 1.5, not only did True and False not
> exist as built-ins, but None was not a keyword:

This is completely irrelevant.
 

>> and pretending to justify that choice by stating that the python thought
>> is: We're all adults here, if you want to override a builtin, who are we
>> to stop you. That is disingenuous.
> No, it's quite sensible, given Python's stated position: it's not an
> authoritarian B&D language like Pascal, nor is it a permissive "anything
> goes" language like C.

You are arguing at the wrong level and thus not addressing my point.
I don't think it is useful to continue further.

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

#90507

Antoon Pardon wrote:
> But that doesn't answer the question why the developers chose "True" to be a
> keyword and "int" to be a looked-up name.

Probably because True, False and None are very frequently
used constants. Making them keywords means that things
like 'while True:' don't incur the overhead of a name
lookup every time around the loop.

The same doesn't apply to other built-in names, which
are used much less frequently.

-- 
Greg

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

#90535

Op 13-05-15 om 02:19 schreef Gregory Ewing:
> Antoon Pardon wrote:
>> But that doesn't answer the question why the developers chose "True"
>> to be a
>> keyword and "int" to be a looked-up name.
>
> Probably because True, False and None are very frequently
> used constants.

I don't care about the specific answer. I care about how specific
answers are supported.

-- 
Antoon Pardon.

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

#90463

[Multipart message — attachments visible in raw view] — view raw

On 05/12/2015 04:55 AM, Antoon Pardon wrote:
> Op 11-05-15 om 16:13 schreef Chris Angelico:
>
>> Why does Python have most built-ins as simply looked-up names that can
>> be overridden? Because otherwise, there would be a veritable ton of
>> keywords:
> But that doesn't answer the question why the developers chose "True" to be a
> keyword and "int" to be a looked-up name.
>
> and pretending to justify that choice by stating that the python thought
> is: We're all adults here, if you want to override a builtin, who are we
> to stop you. That is disingenuous.
>

Bull.   Some design decisions were made with the knowledge that

  * they provide a freedom which may be useful but can be misused (e.g.,
    shadowing builtins), versus
  * they would be too disruptive of abusable (e.g. shadowing keywords)

Python tends to use the first category more than C family languages, and 
that's where the "We're all adults" argument applies.  You may argue 
about which category any particular feature ought to fall into, and in 
fact several things (shadowing None, True, and False) have changed 
category during the evolution of Python.  But to imply that the "adult" 
argument should drive *all* decisions is foolish. And disingenuous.

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

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

#90364

On 11/05/2015 12:39, Antoon Pardon wrote:
> 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.
>

If you say so but I disagree and can't be bothered to say anything else.

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

#90372

On Mon, May 11, 2015 at 2:44 AM, Chris Angelico <rosuav@gmail.com> wrote:
> 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.

Thanks, Chris, that helps a lot. It seems that beyond being a
programming language, Python has a well-established culture that
suggests how the language should be used. I am gathering that
understanding the language and embracing the existing culture are
needed to use Python in the way it is meant to be used, though the
language design allows *other* ways, too.

> Hakuna matata, what a wonderful phrase.

Indeed! And a good way to start my Monday morning.


-- 
boB

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

#90374

On Mon, May 11, 2015 at 2:40 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 10/05/2015 20:12, boB Stepp wrote:

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

That's quite a statement! I see I have a looonnnnggg journey ahead!!



-- 
boB

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

#90317

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

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

#90320

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

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

#90321

> 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

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

#90327

On Mon, May 11, 2015 at 11:18 AM, zipher <dreamingforward@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

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

#90329

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

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

#90332

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"

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

#90334

On Mon, May 11, 2015 at 12:12 PM, Rustom Mody <rustompmody@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

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

#90365

On 11/05/2015 02:18, zipher wrote:
>> 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.

Even C allows this:

#define int(a) strlen(a)

(although it doesn't like #define int strlen for some reason.)

-- 
Bartc

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web