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

#90377

Op 11-05-15 om 13:58 schreef Marko Rauhamaa:
> 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?

The point is that all too often someone wants to defend a specific choice
the developers have made and cites some general rule or principle in support,
ignoring the fact that python breaks that rule/principle in other area's.

"We are all adults, we give you the freedom to break things or write
confusing code" and variantions is such a rule/principle, because often
enough changes in the language are introduced to make it easier to eliminate
bugs or are refused because they would be too bug prone.

-- 
Antoon Pardon

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

#90380

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

> The point is that all too often someone wants to defend a specific
> choice the developers have made and cites some general rule or
> principle in support, ignoring the fact that python breaks that
> rule/principle in other area's.

Granted, but you have set the trap for them by demanding a justification
when no justification was required. Every language has their cute
idiosyncrasies and arbitrary design choices.

Still, I have seen some glitches in the matrix as well:

   >>> setattr(3, "__str__", lambda: "hello")
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   AttributeError: 'int' object attribute '__str__' is read-only
   >>> setattr(3, "hello", lambda: "hello")
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   AttributeError: 'int' object has no attribute 'hello'


Bottom line, though, is that these corner cases in no way prevent you
from accomplishing your programming objective using Python.


Marko

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

#90389

On Monday, May 11, 2015 at 9:03:43 AM UTC-5, Marko Rauhamaa wrote:
> Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
> 
> > The point is that all too often someone wants to defend a specific
> > choice the developers have made and cites some general rule or
> > principle in support, ignoring the fact that python breaks that
> > rule/principle in other area's.
> 
> Granted, but you have set the trap for them by demanding a justification
> when no justification was required. Every language has their cute
> idiosyncrasies and arbitrary design choices.

No.  Here's where I must disagree.  I think one can infer a goal for particular programming languages, even if it is subconscious.  For example, with LISP it could be "generality".  For C, it could be "staying as close to the machine as possible while maximizing the use to humans" -- contradiction that works because they've limited their architecture to VonNeumann (stackless) machines.

I think the subconscious goal of OOP languages is to create a data ecosystem, starting with a unified data model under the realization that ultimately:  all data relates to other data -- that my database of wind speed and direction from 2012 is relatable, by some finite number of hops, to your data on population growth in Chicago.  Call it the "seven degrees of data" and remember the exabytes of data out there.

Python is creating the perfect system for that because it has an interpreter environment with which to manipulate objects that could be retrieved on the net and sent back out.  It has docstrings so that your foreign object can self-document, and doctests, so that I can be confident that your code works as *I* expect.

There are reasons to have limits on programming freedom.  It puts order to chaos.  It guides the wily programmers into a particular train of thought.  You don't override "True" because you'd be breaking one of the [explicit] goals of the language:  readability.  If there were no constraints, life itself could not exist.

I don't think shadowing built-in types was a design choice but simply never got exercised because most people are used to handling such things, *subconsciously*, like C.

To Mr. Gatti, my point was not an insult, it is a theoretical postulate in the domain of Computer Science.  One that has not really been studied.  OOP is still far from it's goal, so the field is still answering questions within it.

Mark

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

#90424

On Mon, 11 May 2015 07:56:56 -0700 (PDT), zipher
<dreamingforward@gmail.com> declaimed the following:

>No.  Here's where I must disagree.  I think one can infer a goal for particular programming languages, even if it is subconscious.  For example, with LISP it could be "generality".  For C, it could be "staying as close to the machine as possible while maximizing the use to humans" -- contradiction that works because they've limited their architecture to VonNeumann (stackless) machines.
>
	Pardon?

	VonNeumann architecture has nothing to do with stacks -- it is a
machine in which the instructions and data share storage and access (bus).
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#90442

Op 11-05-15 om 16:03 schreef Marko Rauhamaa:

> Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
>
>> The point is that all too often someone wants to defend a specific
>> choice the developers have made and cites some general rule or
>> principle in support, ignoring the fact that python breaks that
>> rule/principle in other area's.
> Granted, but you have set the trap for them by demanding a justification
> when no justification was required. Every language has their cute
> idiosyncrasies and arbitrary design choices.

I did not. My first reaction was after someone made this kind of defence.

-- 
Antoon Pardon

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

#90403

On Mon, 11 May 2015 11:27 pm, Antoon Pardon wrote:

> The point is that all too often someone wants to defend a specific choice
> the developers have made and cites some general rule or principle in
> support, ignoring the fact that python breaks that rule/principle in other
> area's.


"It's a free country, you can do what you like."

"No I can't, I'm not allowed to kill people."

"Um, okay."


Just because there are exceptions to a rule doesn't mean it isn't a general
rule. A few exceptions are just exceptions, they don't invalidate the fact
that "consenting adults" is a basic design principle of Python.


-- 
Steven

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

#90409

On Monday, May 11, 2015 at 10:44:51 AM UTC-5, Steven D'Aprano wrote:
> On Mon, 11 May 2015 11:27 pm, Antoon Pardon wrote:
> 
> > The point is that all too often someone wants to defend a specific choice
> > the developers have made and cites some general rule or principle in
> > support, ignoring the fact that python breaks that rule/principle in other
> > area's.
> 
> "It's a free country, you can do what you like."
> 
> "No I can't, I'm not allowed to kill people."
> 
> Just because there are exceptions to a rule doesn't mean it isn't a general
> rule. A few exceptions are just exceptions, they don't invalidate the fact
> that "consenting adults" is a basic design principle of Python.

The solution to this is to find an overarching maxim that encompasses both.  This was already solved (in your example) with the Age they called the Enlightenment (and perhaps arguably with Kant).  The solution was that your liberty extends to the point another's begins -- a more scalable maxim than "freedom".

With OOP, the solution is not to slide by having sloppy design goals, it's to find a noble purpose.  OOP by itself has no goal other than to try to make a system of re-usable objects.  By itself it's like having a bow and arrow with no target.  I'm suggesting there's a target:  a data ecosystem for the exabytes of data that exists with the Internet -- not simulating graphical objects on the screen or trying to re-make the real-world in the virtual world.   These are missteps that perhaps can be explored in languages specially tailored for it (Simula, POV-ray, Erlang, etc.).

Mark

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

#90425

On Tue, 12 May 2015 01:44:39 +1000, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following:

>On Mon, 11 May 2015 11:27 pm, Antoon Pardon wrote:
>
>> The point is that all too often someone wants to defend a specific choice
>> the developers have made and cites some general rule or principle in
>> support, ignoring the fact that python breaks that rule/principle in other
>> area's.
>
>
>"It's a free country, you can do what you like."

	... until you affect someone else... Then you need to negotiate <G>
>
>"No I can't, I'm not allowed to kill people."
>
	see above
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#90446

Op 11-05-15 om 17:44 schreef Steven D'Aprano:
> On Mon, 11 May 2015 11:27 pm, Antoon Pardon wrote:
>
>> The point is that all too often someone wants to defend a specific choice
>> the developers have made and cites some general rule or principle in
>> support, ignoring the fact that python breaks that rule/principle in other
>> area's.
>
> "It's a free country, you can do what you like."
>
> "No I can't, I'm not allowed to kill people."
>
> "Um, okay."
>
>
> Just because there are exceptions to a rule doesn't mean it isn't a general
> rule. A few exceptions are just exceptions, they don't invalidate the fact
> that "consenting adults" is a basic design principle of Python.

There is a difference between a basic design principle and a justification
for a particular instance. Answering the latter with the first as if the
first is all there is to it, is being simplistic.

Especially when there are multiple general rules that tend to conflict
with each other and more than once people just pick a rule that supports
them and ignore the rest.

-- 
Antoon Pardon

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

#90370

On Mon, 11 May 2015 09:39 pm, Antoon Pardon wrote:

> There is no
> a priori reason why we should turn "True" into a keyword and allow
> "int" in the builtins.

Why should there be an *a priori* reason?

There's no a priori reason why I speak English, instead of communicating
through the medium of dance. Nevertheless there are many good, compelling
reasons for speaking English (as well as some reasons that are best
described as historical accidents). Might I be better off if I spoke Latin,
Japanese or Klingon? Perhaps, perhaps not. Those are valid choices too, but
they're not choices I have made.

With programming languages, the designer can take the same route as Pascal
or Java, and define standard functions as keywords that cannot be shadowed
or redefined. Or one can design the language to be like Forth, where there
are no keywords and literally everything can be redefined.

Or one can take a middle-road, where certain syntactic elements, and a very
small number of constant values, are made keywords, and everything else is
free to be redefined.

There's no a priori reason for any of those choices. But there are reasons.


-- 
Steven

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

#90378

Op 11-05-15 om 14:34 schreef Steven D'Aprano:

> On Mon, 11 May 2015 09:39 pm, Antoon Pardon wrote:
>
>> There is no
>> a priori reason why we should turn "True" into a keyword and allow
>> "int" in the builtins.
> Why should there be an *a priori* reason?

I don't say there should be an *a priori* reason, but one implies or
at least strongly suggests an *a priori* reason when one comes with
such general rule as /We are all adults, so we allow this kind of thing./

"We allow buitins to be overridden", doesn't sound as a very accurate
description of the underlining reason, when you know that things have
been removed from builtins and made a keyword in order to prevent them
from being overridden.

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

#90383

On Mon, May 11, 2015 at 11:38 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> "We allow buitins to be overridden", doesn't sound as a very accurate
> description of the underlining reason, when you know that things have
> been removed from builtins and made a keyword in order to prevent them
> from being overridden.

There are principles, and then there are specific instances that go
against those principles. The overarching principle has its
justification; the violations have to have their own justifications.
As Steven said, there are no a priori reasons for most things - or to
put it another way, there are very few design decisions that come down
to a fundamental "this is right, this is wrong" - but there can be
strong and weak justifications for things.

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:

>>> dir(builtins)
['ArithmeticError', 'AssertionError', 'AttributeError',
'BaseException', 'BlockingIOError', 'BrokenPipeError', 'BufferError',
'BytesWarning', 'ChildProcessError', 'ConnectionAbortedError',
'ConnectionError', 'ConnectionRefusedError', 'ConnectionResetError',
'DeprecationWarning', 'EOFError', 'Ellipsis', 'EnvironmentError',
'Exception', 'False', 'FileExistsError', 'FileNotFoundError',
'FloatingPointError', 'FutureWarning', 'GeneratorExit', 'IOError',
'ImportError', 'ImportWarning', 'IndentationError', 'IndexError',
'InterruptedError', 'IsADirectoryError', 'KeyError',
'KeyboardInterrupt', 'LookupError', 'MemoryError', 'NameError',
'None', 'NotADirectoryError', 'NotImplemented', 'NotImplementedError',
'OSError', 'OverflowError', 'PendingDeprecationWarning',
'PermissionError', 'ProcessLookupError', 'ReferenceError',
'ResourceWarning', 'RuntimeError', 'RuntimeWarning', 'StopIteration',
'SyntaxError', 'SyntaxWarning', 'SystemError', 'SystemExit',
'TabError', 'TimeoutError', 'True', 'TypeError', 'UnboundLocalError',
'UnicodeDecodeError', 'UnicodeEncodeError', 'UnicodeError',
'UnicodeTranslateError', 'UnicodeWarning', 'UserWarning',
'ValueError', 'Warning', 'ZeroDivisionError', '__build_class__',
'__debug__', '__doc__', '__import__', '__loader__', '__name__',
'__package__', '__spec__', 'abs', 'all', 'any', 'ascii', 'bin',
'bool', 'bytearray', 'bytes', 'callable', 'chr', 'classmethod',
'compile', 'complex', 'copyright', 'credits', 'delattr', 'dict',
'dir', 'divmod', 'enumerate', 'eval', 'exec', 'exit', 'filter',
'float', 'format', 'frozenset', 'getattr', 'globals', 'hasattr',
'hash', 'help', 'hex', 'id', 'input', 'int', 'isinstance',
'issubclass', 'iter', 'len', 'license', 'list', 'locals', 'map',
'max', 'memoryview', 'min', 'next', 'object', 'oct', 'open', 'ord',
'pow', 'print', 'property', 'quit', 'range', 'repr', 'reversed',
'round', 'set', 'setattr', 'slice', 'sorted', 'staticmethod', 'str',
'sum', 'super', 'tuple', 'type', 'vars', 'zip']

in addition to these, which _are_ keywords:

>>> keyword.kwlist
['False', 'None', 'True', 'and', 'as', 'assert', 'break', 'class',
'continue', 'def', 'del', 'elif', 'else', 'except', 'finally', 'for',
'from', 'global', 'if', 'import', 'in', 'is', 'lambda', 'nonlocal',
'not', 'or', 'pass', 'raise', 'return', 'try', 'while', 'with',
'yield']

Python 2 had 'print' as a keyword, and it was specifically turned into
a non-keyword in Python 3 to allow it to be overridden. It could have
been turned into a function while still being a keyword, but it
wasn't. Conversely, True and False became keywords, because there's no
practical reason to override them. [1] You may well want to shadow
'copyright' with your own program's copyright notice, given that the
built-in name is primarily there for interactive use. You might use
'input' to store the incoming text in a non-interactive program, or
'quit' in an interactive one to store a flag that becomes True when
the user wants to terminate. Very frequently, 'id' is used as a
database ID. None of these shadowings is a problem to the language;
chances are none of them will ever be a problem to your code either.
Having most of the built-in names *not* be keywords means that adding
new built-ins doesn't break code; code that used the name for some
other meaning will still work, but won't be able to use the new
feature. That's a good thing.

ChrisA

[1] http://thedailywtf.com/articles/What_Is_Truth_0x3f_ notwithstanding.

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

#90433

Steven D'Aprano wrote:
> With programming languages, the designer can take the same route as Pascal
> or Java, and define standard functions as keywords that cannot be shadowed
> or redefined.

Nit: Pascal's standard types and functions are not reserved
words, they're predeclared identifiers, much as in Python,
and as far as I know can be shadowed.

-- 
Greg

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

#90443

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.

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

#90452

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.

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:


[steve@ando ~]$ python1.5
Python 1.5.2 (#1, Aug 27 2012, 09:09:18)  [GCC 4.1.2 20080704 (Red Hat
4.1.2-52)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> None = 23
>>> [].sort() is None
0
>>> print None
23


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.



> 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. It takes a middle ground, protecting you from the
worst consequences (no seg faults), but otherwise you're trusted to look
after yourself.

To give an analogy, you can consent to having a boxing match, with rules, a
referee, and clear limits on what force is permissible, but you cannot
legally consent to a duel to the death.



-- 
Steven

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

#90455

On Tuesday, May 12, 2015 at 8:56:32 AM UTC-5, 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;

Where is that the consensus?  Please cite examples.

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

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

Mark

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

#90458

On Wed, May 13, 2015 at 1:34 AM, zipher <dreamingforward@gmail.com> wrote:
> On Tuesday, May 12, 2015 at 8:56:32 AM UTC-5, Steven D'Aprano 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.
>

Please tell me what, precisely, is the difference between a type and a
function. Once you've settled that, please explain to me what the
built-in name 'int' is in all versions of Python.

ChrisA

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

#90523

On Tuesday, May 12, 2015 at 10:43:44 AM UTC-5, Chris Angelico wrote:
> On Wed, May 13, 2015 at 1:34 AM, zipher <dreamingforward@gmail.com> wrote:
> > 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.
>
> Please tell me what, precisely, is the difference between a type and a
> function.

A type is something that settles matters for the machine.  A function calculates on the machine.  You can have a type without a function, but you generally can't have a function without types.  If a distorted example like function f(): {} has an implicit return of an int in ANSI C.

> Once you've settled that, please explain to me what the
> built-in name 'int' is in all versions of Python.

'int' is a type that also has a function synonymous with it.  But they should not be considered the same.  They could, for example, be decoupled.  So that 'int' was the type and 'integer' was the function.

Mark



> ChrisA

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

#90464

On 12/05/2015 16:43, Chris Angelico wrote:
> On Wed, May 13, 2015 at 1:34 AM, zipher <dreamingforward@gmail.com> wrote:
>> On Tuesday, May 12, 2015 at 8:56:32 AM UTC-5, Steven D'Aprano 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.
>>
>
> Please tell me what, precisely, is the difference between a type and a
> function. Once you've settled that, please explain to me what the
> built-in name 'int' is in all versions of Python.
>
> ChrisA
>

Do we really have to feed this guy, he's worse than the RUE?

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

#90562

[Mr. Lawrence spaketh:]
> Do we really have to feed this guy, he's worse than the RUE?

While it may seem like an impossible goal, is it unworthy?  Is there something *better* for high-level, interpreted languages to be good for?

The truth is, that all the theory is worked out, as well as the heavy math that will be required to visualize it (thanks VPython!).  So it's only a matter of people being interested.  I, personally, give up on many occasions, not because of *its* impossibility but the stubborness of People`s.

mark

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

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

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

csiph-web