Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #98341 > unrolled thread
| Started by | "wangq@travelsky.com" <wangq@travelsky.com> |
|---|---|
| First post | 2015-11-06 10:33 +0800 |
| Last post | 2015-11-13 09:52 +1100 |
| Articles | 20 on this page of 110 — 24 participants |
Back to article view | Back to comp.lang.python
Question about math.pi is mutable "wangq@travelsky.com" <wangq@travelsky.com> - 2015-11-06 10:33 +0800
Re: Question about math.pi is mutable Bartc <bc@freeuk.com> - 2015-11-06 12:30 +0000
Re: Question about math.pi is mutable Lorenzo Sutton <lorenzofsutton@gmail.com> - 2015-11-06 17:12 +0100
Re: Question about math.pi is mutable Bartc <bc@freeuk.com> - 2015-11-06 19:30 +0000
Re: Question about math.pi is mutable Chris Angelico <rosuav@gmail.com> - 2015-11-07 06:40 +1100
Re: Question about math.pi is mutable Christian Gollwitzer <auriocus@gmx.de> - 2015-11-06 20:59 +0100
Re: Question about math.pi is mutable Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-11-06 23:19 +0100
Re: Question about math.pi is mutable Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-11-07 00:48 +0100
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-07 13:00 +1100
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-07 14:43 +1100
Re: Question about math.pi is mutable Bartc <bc@freeuk.com> - 2015-11-07 11:23 +0000
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-07 22:35 +1100
Re: Question about math.pi is mutable Bartc <bc@freeuk.com> - 2015-11-07 11:57 +0000
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-07 23:15 +1100
Re: Question about math.pi is mutable Bartc <bc@freeuk.com> - 2015-11-07 13:00 +0000
Re: Question about math.pi is mutable Laura Creighton <lac@openend.se> - 2015-11-07 15:09 +0100
Re: Question about math.pi is mutable Marko Rauhamaa <marko@pacujo.net> - 2015-11-07 16:23 +0200
Re: Question about math.pi is mutable Marko Rauhamaa <marko@pacujo.net> - 2015-11-07 16:28 +0200
Re: Question about math.pi is mutable Bartc <bc@freeuk.com> - 2015-11-07 15:01 +0000
Re: Question about math.pi is mutable Marko Rauhamaa <marko@pacujo.net> - 2015-11-07 19:46 +0200
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-08 14:07 +1100
Re: Question about math.pi is mutable Random832 <random832@fastmail.com> - 2015-11-08 01:29 -0500
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-08 13:59 +1100
Re: Question about math.pi is mutable Bartc <bc@freeuk.com> - 2015-11-08 10:40 +0000
Re: Question about math.pi is mutable Marko Rauhamaa <marko@pacujo.net> - 2015-11-08 13:02 +0200
Re: Question about math.pi is mutable BartC <bc@freeuk.com> - 2015-11-08 11:19 +0000
Re: Question about math.pi is mutable Marko Rauhamaa <marko@pacujo.net> - 2015-11-08 13:50 +0200
Re: Question about math.pi is mutable BartC <bc@freeuk.com> - 2015-11-08 12:39 +0000
Re: Question about math.pi is mutable Marko Rauhamaa <marko@pacujo.net> - 2015-11-08 14:43 +0200
Re: Question about math.pi is mutable BartC <bc@freeuk.com> - 2015-11-08 13:42 +0000
Re: Question about math.pi is mutable Marko Rauhamaa <marko@pacujo.net> - 2015-11-08 16:33 +0200
Re: Question about math.pi is mutable Chris Angelico <rosuav@gmail.com> - 2015-11-09 02:11 +1100
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-09 11:58 +1100
Re: Question about math.pi is mutable Chris Angelico <rosuav@gmail.com> - 2015-11-08 23:28 +1100
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-09 11:35 +1100
Re: Question about math.pi is mutable Michael Torrie <torriem@gmail.com> - 2015-11-08 08:59 -0700
Re: Question about math.pi is mutable BartC <bc@freeuk.com> - 2015-11-08 17:54 +0000
Re: Question about math.pi is mutable Chris Angelico <rosuav@gmail.com> - 2015-11-09 05:01 +1100
Re: Question about math.pi is mutable BartC <bc@freeuk.com> - 2015-11-08 18:58 +0000
Re: Question about math.pi is mutable Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-08 12:51 -0700
Re: Question about math.pi is mutable Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-11-08 18:13 -0500
Re: Question about math.pi is mutable BartC <bc@freeuk.com> - 2015-11-08 23:54 +0000
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-09 11:00 +1100
Re: Question about math.pi is mutable BartC <bc@freeuk.com> - 2015-11-09 00:11 +0000
Re: Question about math.pi is mutable Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-11-09 08:18 -0500
Re: Question about math.pi is mutable Chris Angelico <rosuav@gmail.com> - 2015-11-09 11:04 +1100
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-09 11:26 +1100
Re: Question about math.pi is mutable Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-11-09 21:29 +1300
Re: Question about math.pi is mutable Chris Angelico <rosuav@gmail.com> - 2015-11-09 11:36 +1100
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-09 11:50 +1100
Re: Question about math.pi is mutable Chris Angelico <rosuav@gmail.com> - 2015-11-09 11:56 +1100
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-09 12:04 +1100
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-09 22:22 +1100
Re: Question about math.pi is mutable Random832 <random832@fastmail.com> - 2015-11-09 10:32 -0500
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-10 06:45 +1100
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-10 13:37 +1100
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-10 17:10 +1100
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-10 22:34 +1100
Re: Question about math.pi is mutable BartC <bc@freeuk.com> - 2015-11-10 13:26 +0000
Re: Question about math.pi is mutable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-11-11 18:38 +1100
Re: Question about math.pi is mutable Marko Rauhamaa <marko@pacujo.net> - 2015-11-11 10:30 +0200
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-11 22:20 +1100
Re: Question about math.pi is mutable Terry Reedy <tjreedy@udel.edu> - 2015-11-10 03:30 -0500
Re: Question about math.pi is mutable Laura Creighton <lac@openend.se> - 2015-11-10 11:33 +0100
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-10 23:14 +1100
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-11 12:10 +1100
Re: Question about math.pi is mutable Laura Creighton <lac@openend.se> - 2015-11-09 21:07 +0100
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-10 10:21 +1100
Re: Question about math.pi is mutable BartC <bc@freeuk.com> - 2015-11-09 16:54 +0000
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-10 06:52 +1100
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-09 08:00 +1100
Re: Question about math.pi is mutable BartC <bc@freeuk.com> - 2015-11-08 22:35 +0000
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-09 09:54 +1100
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-09 13:23 +1100
Re: Question about math.pi is mutable BartC <bc@freeuk.com> - 2015-11-09 12:22 +0000
Re: Question about math.pi is mutable Chris Angelico <rosuav@gmail.com> - 2015-11-09 23:36 +1100
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-08 22:30 +1100
Re: Question about math.pi is mutable BartC <bc@freeuk.com> - 2015-11-08 12:24 +0000
Re: Question about math.pi is mutable Grant Edwards <invalid@invalid.invalid> - 2015-11-07 16:16 +0000
Re: Question about math.pi is mutable Marko Rauhamaa <marko@pacujo.net> - 2015-11-07 20:00 +0200
Re: Question about math.pi is mutable Grant Edwards <invalid@invalid.invalid> - 2015-11-08 03:31 +0000
Re: Question about math.pi is mutable Marko Rauhamaa <marko@pacujo.net> - 2015-11-08 09:45 +0200
Re: Question about math.pi is mutable Christian Gollwitzer <auriocus@gmx.de> - 2015-11-08 09:00 +0100
Re: Question about math.pi is mutable Paul Rubin <no.email@nospam.invalid> - 2015-11-08 00:08 -0800
Re: Question about math.pi is mutable Marko Rauhamaa <marko@pacujo.net> - 2015-11-08 11:49 +0200
Re: Question about math.pi is mutable Grant Edwards <invalid@invalid.invalid> - 2015-11-09 14:49 +0000
Re: Question about math.pi is mutable Bartc <bc@freeuk.com> - 2015-11-07 15:19 +0000
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-08 14:50 +1100
Re: Question about math.pi is mutable Marko Rauhamaa <marko@pacujo.net> - 2015-11-08 11:44 +0200
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-08 22:11 +1100
Re: Question about math.pi is mutable Marko Rauhamaa <marko@pacujo.net> - 2015-11-08 13:25 +0200
Re: Question about math.pi is mutable BartC <bc@freeuk.com> - 2015-11-08 11:06 +0000
Re: Question about math.pi is mutable Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-09 15:49 +0100
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-10 10:29 +1100
Re: Question about math.pi is mutable Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-10 11:03 +0100
Re: Question about math.pi is mutable Michael Torrie <torriem@gmail.com> - 2015-11-13 20:11 -0700
Re: Question about math.pi is mutable Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-11-14 16:02 +0100
Re: Question about math.pi is mutable Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-11-06 23:26 +0100
Re: Question about math.pi is mutable Terry Reedy <tjreedy@udel.edu> - 2015-11-06 20:49 -0500
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-07 13:06 +1100
Re: Question about math.pi is mutable Bartc <bc@freeuk.com> - 2015-11-07 23:02 +0000
Re: Question about math.pi is mutable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-11-07 23:27 +0000
Re: Question about math.pi is mutable Ben Finney <ben+python@benfinney.id.au> - 2015-11-08 10:32 +1100
Re: Question about math.pi is mutable Chris Angelico <rosuav@gmail.com> - 2015-11-08 10:52 +1100
Re: Question about math.pi is mutable Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-11-12 21:40 +0100
Re: Question about math.pi is mutable Steven D'Aprano <steve@pearwood.info> - 2015-11-13 09:04 +1100
Re: Question about math.pi is mutable Denis McMahon <denismfmcmahon@gmail.com> - 2015-11-13 09:19 +0000
Re: Question about math.pi is mutable Larry Hudson <orgnut@yahoo.com> - 2015-11-13 18:30 -0800
Re: Question about math.pi is mutable BartC <bc@freeuk.com> - 2015-11-12 22:19 +0000
Re: Question about math.pi is mutable Chris Angelico <rosuav@gmail.com> - 2015-11-13 09:52 +1100
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | "wangq@travelsky.com" <wangq@travelsky.com> |
|---|---|
| Date | 2015-11-06 10:33 +0800 |
| Subject | Question about math.pi is mutable |
| Message-ID | <mailman.77.1446804678.16136.python-list@python.org> |
Hello, python-list guys:
I am a newbie of python from Beijing. China.
I have a question about "math.pi".
As you can see in the attachment, why i can modify "math.pi"?
(in "mathmodule.c" "pi" is a "static const double")
Thank you in advance!
Best Wishes！
[toc] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-06 12:30 +0000 |
| Message-ID | <n1i6d4$bfg$1@dont-email.me> |
| In reply to | #98341 |
On 06/11/2015 02:33, wangq@travelsky.com wrote: > Hello, python-list guys: > > I am a newbie of python from Beijing. China. > I have a question about "math.pi". > As you can see in the attachment, why i can modify "math.pi"? > (in "mathmodule.c" "pi" is a "static const double") Python isn't C. Your attachment isn't visible, but it can be demonstrated easily: import math math.pi=0 print (math.pi) In Python, presumably 'pi' is just another variable, and variables can be written to. (Perhaps math.pi would be better off as a function.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Lorenzo Sutton <lorenzofsutton@gmail.com> |
|---|---|
| Date | 2015-11-06 17:12 +0100 |
| Message-ID | <mailman.90.1446826322.16136.python-list@python.org> |
| In reply to | #98349 |
On 06/11/2015 13:30, Bartc wrote: > On 06/11/2015 02:33, wangq@travelsky.com wrote: >> Hello, python-list guys: >> >> I am a newbie of python from Beijing. China. >> I have a question about "math.pi". >> As you can see in the attachment, why i can modify "math.pi"? >> (in "mathmodule.c" "pi" is a "static const double") > > Python isn't C. > > Your attachment isn't visible, but it can be demonstrated easily: > > import math > > math.pi=0 > > print (math.pi) > > In Python, presumably 'pi' is just another variable, and variables can > be written to. > > (Perhaps math.pi would be better off as a function.) Still nothing stops you from doing: math.sin = 0 If you really want to?
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-06 19:30 +0000 |
| Message-ID | <n1iv1c$hst$1@dont-email.me> |
| In reply to | #98359 |
On 06/11/2015 16:12, Lorenzo Sutton wrote:
>
>
> On 06/11/2015 13:30, Bartc wrote:
>> On 06/11/2015 02:33, wangq@travelsky.com wrote:
>>> Hello, python-list guys:
>>>
>>> I am a newbie of python from Beijing. China.
>>> I have a question about "math.pi".
>>> As you can see in the attachment, why i can modify "math.pi"?
>>> (in "mathmodule.c" "pi" is a "static const double")
>>
>> Python isn't C.
>>
>> Your attachment isn't visible, but it can be demonstrated easily:
>>
>> import math
>>
>> math.pi=0
>>
>> print (math.pi)
>>
>> In Python, presumably 'pi' is just another variable, and variables can
>> be written to.
>>
>> (Perhaps math.pi would be better off as a function.)
>
> Still nothing stops you from doing:
>
> math.sin = 0
>
> If you really want to?
Well, you might notice something is wrong when you try and do math.sin(x)!
But I see your point. Even a function can be set to another function, or
to one that returns a nonsense value.
Is there no way then in Python to declare:
pi = 3.141519 # etc
and make it impossible to override?
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-11-07 06:40 +1100 |
| Message-ID | <mailman.93.1446838846.16136.python-list@python.org> |
| In reply to | #98362 |
On Sat, Nov 7, 2015 at 6:30 AM, Bartc <bc@freeuk.com> wrote: > Is there no way then in Python to declare: > > pi = 3.141519 # etc > > and make it impossible to override? Nope. Even in C++, where classes can define certain things as const, private, and other such restrictions, you can always get around them by manipulating pointers appropriately. In Python, there's a *convention* that a leading underscore means "private", but the language doesn't enforce anything about it. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2015-11-06 20:59 +0100 |
| Message-ID | <n1j0nt$odf$1@dont-email.me> |
| In reply to | #98363 |
Am 06.11.15 um 20:40 schrieb Chris Angelico:
> On Sat, Nov 7, 2015 at 6:30 AM, Bartc <bc@freeuk.com> wrote:
>> Is there no way then in Python to declare:
>>
>> pi = 3.141519 # etc
>>
>> and make it impossible to override?
>
> Nope. Even in C++, where classes can define certain things as const,
> private, and other such restrictions, you can always get around them
> by manipulating pointers appropriately.
No, that is not right. If you cast away the constness from a pointer to
a constant, you can technically write to that memory, but the behaviour
is undefined - another way of saying that the program is illegal.
In many cases, the compiler will inline the constant - because you
promised, that it can't change - and the update to the constant will not
change in all parts of the program:
apfelkiste:Tests chris$ cat constub.cpp
#include <iostream>
void call_by_ref(const double &v) {
std::cout<<"In function: v="<<v<<std::endl;
}
int main() {
const double pi=3.14;
double *errptr = const_cast<double*>(&pi);
*errptr= 0.0;
std::cout<<"Now pi is "<<pi<<std::endl;
call_by_ref(pi);
return 0;
}
apfelkiste:Tests chris$ g++ constub.cpp
apfelkiste:Tests chris$ ./a.out
Now pi is 3.14
In function: v=0
Christian
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2015-11-06 23:19 +0100 |
| Message-ID | <1521937.lCYGF7V2BE@PointedEars.de> |
| In reply to | #98363 |
Chris Angelico wrote:
> On Sat, Nov 7, 2015 at 6:30 AM, Bartc <bc@freeuk.com> wrote:
>> Is there no way then in Python to declare:
>>
>> pi = 3.141519 # etc
>>
>> and make it impossible to override?
>
> Nope. Even in C++, where classes can define certain things as const,
> private, and other such restrictions, you can always get around them
> by manipulating pointers appropriately. In Python, there's a
> *convention* that a leading underscore means "private", but the
> language doesn't enforce anything about it.
It is certainly possible for attributes of (instances of) new-style classes
(starting with Python 3.2 at the latest) to be read-only by declaring them a
property that does not have a setter, or one that has a setter that throws a
specific exception (here: the former):
#--------------------------
class SafeMath(object):
def __init__ (self):
from math import pi
self._pi = pi
@property
def pi (self):
return self._pi
#--------------------------
| >>> math = SafeMath()
| >>> math.pi
| 3.141592653589793
| >>> math.pi = 42
| Traceback (most recent call last):
| File "<stdin>", line 1, in <module>
| AttributeError: can't set attribute
(Or you can use “pi = property(…)” within the class declaration.)
In theory, it should be possible to substitute “math” with a reference to an
object that acts as a proxy for the original “math” module object but whose
base class declares the attributes for all the constants read-only.
--
PointedEars
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2015-11-07 00:48 +0100 |
| Message-ID | <11393078.50naPz65Nn@PointedEars.de> |
| In reply to | #98376 |
Thomas 'PointedEars' Lahn wrote:
> In theory, it should be possible to substitute “math” with a reference to
> an object that acts as a proxy for the original “math” module object but
> whose base class declares the attributes for all the constants read-only.
#!/usr/bin/env python3
#---------------------------------------------------------------------------
import importlib
class MyMath(object):
def getter_factory (prop):
def getter (self):
return getattr(importlib.__import__("math", globals(), locals(),
[prop], 0), prop)
return getter
pi = property(getter_factory("pi"), lambda self, val: None,
lambda self: None)
e = property(getter_factory("e"), lambda self, val: None,
lambda self: None)
inf = property(getter_factory("inf"), lambda self, val: None,
lambda self: None)
nan = property(getter_factory("nan"), lambda self, val: None,
lambda self: None)
def __getattr__ (self, name):
return getattr(importlib.__import__("math", globals(), locals(),
[name], 0), name, None)
math = MyMath()
print(math.pi, math.e, math.inf, math.nan)
math.pi = 42
math.e = 42
math.inf = 42
math.nan = 42
print(math.pi, math.e, math.inf, math.nan)
print(math.ceil(2.41))
#---------------------------------------------------------------------------
Using property() instead of decorators here was intended to achieve DRY by
using a loop, but I could not find a way to define class attributes
dynamically. Suggestions?
--
PointedEars
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2015-11-07 13:00 +1100 |
| Message-ID | <563d5b41$0$1585$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #98376 |
On Sat, 7 Nov 2015 09:19 am, Thomas 'PointedEars' Lahn wrote: > It is certainly possible for attributes of (instances of) new-style > classes (starting with Python 3.2 at the latest) to be read-only by > declaring them a property that does not have a setter, or one that has a > setter that throws a specific exception (here: the former): > > #-------------------------- > class SafeMath(object): > def __init__ (self): > from math import pi > self._pi = pi > > @property > def pi (self): > return self._pi The obvious problem with that is that it is trivially easy for the coder to set self._pi to change the value of self.pi. Here's a version that at first seems promising: py> def builder(): ... from math import pi as PI ... def pi(self): ... return PI ... return pi ... py> class MathLib(object): ... pi = property(builder()) ... py> mathlib = MathLib() py> mathlib.pi 3.141592653589793 py> mathlib.pi = 3.12 Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: can't set attribute There's no _pi accessible that somebody might change. If you dig into the property object itself, you eventually get to the cell object containing the value for pi: py> MathLib.pi.fget.__closure__[0] <cell at 0xb7bd5134: float object at 0xb7be5c30> but there doesn't appear to be any way to manipulate the cell internals to change the value. But you don't need to: py> MathLib.pi = property(lambda self: 4.2) py> mathlib.pi 4.2 A determined coder can change nearly anything done in pure Python code. *Personally*, I too would like Python to have some equivalent of (say) Pascal `const`, names which cannot be rebound once assigned to the first time. Not to prevent determined coders from changing things, but to avoid *accidental* changes done in error. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2015-11-07 14:43 +1100 |
| Message-ID | <mailman.103.1446867842.16136.python-list@python.org> |
| In reply to | #98362 |
Bartc <bc@freeuk.com> writes: > Is there no way then in Python to declare: > > pi = 3.141519 # etc > > and make it impossible to override? No, and it would be a bad thing if that were something a library author could forbid. Python assumes the programmers using it are consenting adults. Doing harmful things is difficult but not forbidden. Notably, the author of a library should not be forbidding the Pythonic ability to change name bindings as needed. If you want to have a different value bound to the name ‘math.pi’, and you go ahead and explicitly ask to change that binding, the library author has no business forbidding that. -- \ “Software patents provide one more means of controlling access | `\ to information. They are the tool of choice for the internet | _o__) highwayman.” —Anthony Taylor | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-07 11:23 +0000 |
| Message-ID | <n1kmse$p0o$1@dont-email.me> |
| In reply to | #98385 |
On 07/11/2015 03:43, Ben Finney wrote:
> Bartc <bc@freeuk.com> writes:
>
>> Is there no way then in Python to declare:
>>
>> pi = 3.141519 # etc
>>
>> and make it impossible to override?
>
> No, and it would be a bad thing if that were something a library author
> could forbid.
>
> Python assumes the programmers using it are consenting adults. Doing
> harmful things is difficult but not forbidden.
But surely it can't hurt to ensure certain values can't be changed
accidentally or maliciously?
Some dynamic languages (OK, I'm thinking of mine) simply allow you to write:
const pi = 3.14159
Then this can't be changed, because it would be the equivalent of writing:
3.14159 = 0
What would be the harm in this?
It's a very simple idea, yet many people and languages either don't like
it or can't grasp it. Not even C has the feature, if you don't count
using the crude #define for the purpose.
In the case of Python, it could have allowed 'constant folding', so that
math.pi*2 need not be evaluated at runtime.
(Python however does make it quite difficult to add features like this.
Mostly because such names are not visible across modules when compiling.
Also it is still possible to write math = some_other_module.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2015-11-07 22:35 +1100 |
| Message-ID | <mailman.104.1446896120.16136.python-list@python.org> |
| In reply to | #98388 |
Bartc <bc@freeuk.com> writes: > On 07/11/2015 03:43, Ben Finney wrote: > > Bartc <bc@freeuk.com> writes: > > > >> Is there no way then in Python to declare: > >> > >> pi = 3.141519 # etc > >> > >> and make it impossible to override? > > > > No, and it would be a bad thing if that were something a library author > > could forbid. > > > > Python assumes the programmers using it are consenting adults. Doing > > harmful things is difficult but not forbidden. > > But surely it can't hurt to ensure certain values can't be changed > accidentally or maliciously? The value ‘3.141519’ (in your example above) can't be changed. That value will always be exactly the same, as long as the program is running. What I think you mean is “surely it can't hurt to ensure certain names can never be bound to any value but their initial binding”. On that I strongly disagree, for the reasons already discussed in this thread: it arrogates to the library author the power to forbid patching the library, which cripples extending, debugging, introspection, and a host of other useful activities. -- \ “I object to doing things that computers can do.” —Olin Shivers | `\ | _o__) | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-07 11:57 +0000 |
| Message-ID | <n1koqr$v63$1@dont-email.me> |
| In reply to | #98389 |
On 07/11/2015 11:35, Ben Finney wrote:
> Bartc <bc@freeuk.com> writes:
>
>> On 07/11/2015 03:43, Ben Finney wrote:
>>> Bartc <bc@freeuk.com> writes:
>>>
>>>> Is there no way then in Python to declare:
>>>>
>>>> pi = 3.141519 # etc
>>>>
>>>> and make it impossible to override?
>>>
>>> No, and it would be a bad thing if that were something a library author
>>> could forbid.
>>>
>>> Python assumes the programmers using it are consenting adults. Doing
>>> harmful things is difficult but not forbidden.
>>
>> But surely it can't hurt to ensure certain values can't be changed
>> accidentally or maliciously?
>
> The value ‘3.141519’ (in your example above) can't be changed. That
> value will always be exactly the same, as long as the program is
> running.
>
> What I think you mean is “surely it can't hurt to ensure certain names
> can never be bound to any value but their initial binding”.
>
> On that I strongly disagree, for the reasons already discussed in this
> thread: it arrogates to the library author the power to forbid patching
> the library, which cripples extending, debugging, introspection, and a
> host of other useful activities.
Why would it stop introspection?
If the source is available, why would it stop anyone extending a library?
To my mind, Python allows far too much freedom in being able to change
anything at any time. Imagine if the interfaces to Win32 API or to the
Linux kernel could be turned upside down from one microsecond to the
next, while programs are still running.
Take a simple function like thousands of others:
def dull(x,y,z);
.....
.....
99.9999% of the time, the name 'dull' is not going to be bound to
anything else, and it would just be called like this:
dull(10,20,30)
Yet Python has to assume 100% of the time that it could have been
changed. Think of the opportunities for optimising if the probability
was 0%.
Perhaps if library authors want people tinkering with their code at
runtime, they should mark it as such ('var', 'volatile' etc). Because
most of us are quite happy with a boring, static library that is not
likely to morph into something else!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2015-11-07 23:15 +1100 |
| Message-ID | <mailman.105.1446898544.16136.python-list@python.org> |
| In reply to | #98390 |
Bartc <bc@freeuk.com> writes: > To my mind, Python allows far too much freedom in being able to change > anything at any time. You're welcome to that opinion. I don't see you present a reason why it should affect anyone else's opinion of Python, though. > Yet Python has to assume 100% of the time that it could have been > changed. Think of the opportunities for optimising if the probability > was 0%. Such a pity that Python is missing all those opportunities for widespread adoption, by not hewing closer to your preferences. -- \ “That's the essence of science: Ask an impertinent question, | `\ and you're on the way to the pertinent answer.” —Jacob | _o__) Bronowski, _The Ascent of Man_, 1973 | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-07 13:00 +0000 |
| Message-ID | <n1kshk$brb$1@dont-email.me> |
| In reply to | #98391 |
On 07/11/2015 12:15, Ben Finney wrote:
> Bartc <bc@freeuk.com> writes:
>
>> To my mind, Python allows far too much freedom in being able to change
>> anything at any time.
>
> You're welcome to that opinion. I don't see you present a reason why it
> should affect anyone else's opinion of Python, though.
Not just my option. From this 2010 paper for example ('High performance
implementation of Python for CLI ...' by Antonio Cuni):
"As a language, Python is very hard to implement efficiently: the
presence of highly dynamic constructs makes static analysis of programs
extremely difficult, thus preventing ahead of time (AOT) compilers to
generate efficient target code."
>> Yet Python has to assume 100% of the time that it could have been
>> changed. Think of the opportunities for optimising if the probability
>> was 0%.
>
> Such a pity that Python is missing all those opportunities for
> widespread adoption, by not hewing closer to your preferences.
Plenty of other people working on faster Pythons appear to have trouble
with its being so dynamic.
(Earlier this year, I was upgrading my own language to be much more
Python-like in its internal workings. But I gave it up because I was
losing so many nice features that also made it easy to implement
efficiently.
As one example of many, named constants (the 'const' feature earlier in
the thread), were used for 'switch' statements. Without 'const', then I
couldn't have a fast 'switch'.)
I suppose my coding style is just different from people who write
Python. When I define a function f(), then it's always going to be
function f and is never going to change. A call to such a function can
therefore be streamlined.
If I ever need it to be dynamic, then I use a function pointer:
g=f
f is still the static function, g is a now a reference to it, and is a
little slower to call. But the /vast majority/ of function calls are
going to be static.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Laura Creighton <lac@openend.se> |
|---|---|
| Date | 2015-11-07 15:09 +0100 |
| Message-ID | <mailman.106.1446905384.16136.python-list@python.org> |
| In reply to | #98392 |
In a message of Sat, 07 Nov 2015 13:00:37 +0000, Bartc writes:
>Not just my option. From this 2010 paper for example ('High performance
>implementation of Python for CLI ...' by Antonio Cuni):
>
>"As a language, Python is very hard to implement efficiently: the
>presence of highly dynamic constructs makes static analysis of programs
>extremely difficult, thus preventing ahead of time (AOT) compilers to
>generate efficient target code."
Recall that my friend Anto is discussing 'why my phd thesis was hard
stuff, as I did this for PyPy' and not 'Python would be better if it
were easier to write fast compilers for it'. :)
Anto loves the dynamic nature of python. It just makes pypy hard.
Laura
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-11-07 16:23 +0200 |
| Message-ID | <87d1vlzy4p.fsf@elektro.pacujo.net> |
| In reply to | #98392 |
Bartc <bc@freeuk.com>:
> Not just my option. From this 2010 paper for example ('High performance
> implementation of Python for CLI ...' by Antonio Cuni):
>
> "As a language, Python is very hard to implement efficiently: the
> presence of highly dynamic constructs makes static analysis of
> programs extremely difficult, thus preventing ahead of time (AOT)
> compilers to generate efficient target code."
Correct. That's not Python's fault, however. Python should not try to
placate the performance computing people. (Alas, it is now trying to do
just that with the introduction of static typing annotation.)
> Plenty of other people working on faster Pythons appear to have
> trouble with its being so dynamic.
That's, literally, their problem.
> As one example of many, named constants (the 'const' feature earlier
> in the thread), were used for 'switch' statements. Without 'const',
> then I couldn't have a fast 'switch'.)
Fast, fast, fast. We have plenty of fast programming languages. Python
should *not* sacrifice its dynamism (which the fast languages don't
have) for speed. Python is already fast enough for most programming
tasks.
In my work, I currently use bash, Python and C. For many, many tasks,
bash is superior to Python. For others, Python can't compete with C. Yet
the vast gap between bash and C is nicely filled with Python.
Those three golf clubs are all I need in my bag. Java, C#, go, C++ have
great merits. However, I really don't ever miss them.
(The one club I have special sentiments for is Scheme. I don't use it
professionally for, though, because its ecosystem is not quite developed
enough yet.)
> I suppose my coding style is just different from people who write
> Python. When I define a function f(), then it's always going to be
> function f and is never going to change. A call to such a function can
> therefore be streamlined.
Your point of view is really down-to-earth. It's slightly analogous to
protesting against Unicode because you only ever need ASCII.
You would be right in that Python programs hardly ever make use of or
directly depend on the degrees of freedom Python affords. They are used
every here and there, however, and, most imporantly, they make it
possible to define the semantics of the programming language in a sound,
concise manner. That way it is easier to implement Python, learn
Python and use Python correctly.
Imagine there was a national standard that defined that you could only
sell hatchets that split wood in a downward movement. You might argue
that hardly anyone swung a hatchet sideways, and it would be dangerous
anyway. However, that kind of a standard would make it very difficult to
manufacture the simple concept of a hatchet. The contraption would be
expensive, fragile, heavy and difficult to use even for the intended
up-down splitting purpose.
I wouldn't like Python to turn into such a contraption.
Marko
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-11-07 16:28 +0200 |
| Message-ID | <878u69zxww.fsf@elektro.pacujo.net> |
| In reply to | #98394 |
Marko Rauhamaa <marko@pacujo.net>: > In my work, I currently use bash, Python and C. For many, many tasks, > bash is superior to Python. For others, Python can't compete with C. > Yet the vast gap between bash and C is nicely filled with Python. And, by the way, the introduction of the "const" keyword was maybe the biggest mistake the C standardizers ever made. It turned out to be about as useful as a mosquito buzzing at your ear, and equally persistent and annoying. Marko
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-07 15:01 +0000 |
| Message-ID | <n1l3kd$5ma$1@dont-email.me> |
| In reply to | #98395 |
On 07/11/2015 14:28, Marko Rauhamaa wrote: > Marko Rauhamaa <marko@pacujo.net>: > >> In my work, I currently use bash, Python and C. For many, many tasks, >> bash is superior to Python. For others, Python can't compete with C. >> Yet the vast gap between bash and C is nicely filled with Python. > > And, by the way, the introduction of the "const" keyword was maybe the > biggest mistake the C standardizers ever made. It turned out to be about > as useful as a mosquito buzzing at your ear, and equally persistent and > annoying. (Yes, 'const' in C is a waste of time, and half the people using it don't appear to know what it means. Some people also like to use it practically everywhere so that you can no longer make out the actual code. The version in C++ is a more complicated form even further away from what people really want. Neither have the simplicity of concept of Pascal's 'const', which is just a named value. Not a variable that won't change once initialised, not a parameter that won't be changed nor any addressable location.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-11-07 19:46 +0200 |
| Message-ID | <8737whzor4.fsf@elektro.pacujo.net> |
| In reply to | #98397 |
Bartc <bc@freeuk.com>:
> (Yes, 'const' in C is a waste of time, and half the people using it
> don't appear to know what it means.
It cannot mean anything meaningful; it's completely useless.
For example, what could one think of standard library functions whose
prototypes are:
char *strstr(const char *haystack, const char *needle);
int execve(const char *filename, char *const argv[],
char *const envp[]);
Ok, enough of C.
Marko
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.python
csiph-web