Re: Question about math.pi is mutable

Op 14-11-15 om 04:11 schreef Michael Torrie: > On 11/10/2015 03:03 AM, Antoon Pardon wrote: >> Op 10-11-15 om 00:29 schreef Ben Finney: >>> >>> Who is doing what to whom? The user of the library isn't doing anything >>> to the library author, so what is it the library author would consent >>> to?

Re: Question about math.pi is mutable

On Fri, 13 Nov 2015 09:04:54 +1100, Steven D'Aprano wrote: > On Fri, 13 Nov 2015 07:40 am, Thomas 'PointedEars' Lahn wrote: > > [crap I expect] > And you should consider the irony, and hypocrisy, of somebody who signs > his posts "PointedEars" bitching about supposed "real names". TPEL has

Re: Question about math.pi is mutable

On 11/10/2015 03:03 AM, Antoon Pardon wrote: > Op 10-11-15 om 00:29 schreef Ben Finney: >> >> Who is doing what to whom? The user of the library isn't doing anything >> to the library author, so what is it the library author would consent >> to? Instead, you seem to be trying to assert a *power*

Re: Question about math.pi is mutable

On 11/13/2015 01:19 AM, Denis McMahon wrote: On Fri, 13 Nov 2015 09:04:54 +1100, Steven D'Aprano wrote: On Fri, 13 Nov 2015 07:40 am, Thomas 'PointedEars' Lahn wrote: [crap I expect] And you should consider the irony, and hypocrisy, of somebody who signs his posts "PointedEars" bitching

Re: Question about math.pi is mutable

Chris Angelico wrote: > […] Ben Finney […] wrote: >> I recommend you ignore that request; “Bartc” is fine as a name here, >> IMO. > > Given that LARTC means Linux Advanced Routing and Traffic Control, I'm > guessing Bartc is all about *BSD networking? :) I thought LART were the Luser Attitude

Re: Question about math.pi is mutable

On Fri, 13 Nov 2015 07:40 am, Thomas 'PointedEars' Lahn wrote: > And on GABELNs [1] it is considered polite to post using your real name. Falsehoods programmers believe about names: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ > You have been warned. And

Re: Question about math.pi is mutable

On 12/11/2015 20:40, Thomas 'PointedEars' Lahn wrote: Chris Angelico wrote: […] Ben Finney […] wrote: I recommend you ignore that request; “Bartc” is fine as a name here, IMO. Given that LARTC means Linux Advanced Routing and Traffic Control, I'm guessing Bartc is all about *BSD networking?

Re: Question about math.pi is mutable

On Fri, Nov 13, 2015 at 9:19 AM, BartC wrote: > (FWIW, my real first name is Bart and C is the initial of my last name. Very > dull I know.) That's a common way of signing emails. I sign most of mine "ChrisA", which (as you'll see from my headers) is constructed the same way. So

Re: Question about math.pi is mutable

Steven D'Aprano : > Since compile, eval and exec are Python built-ins, if it doesn't > include a byte-code compiler, it isn't Python. It's just a subset of > Python. compile() can be implemented trivially, or in any other manner. It simply needs to return a

Re: Question about math.pi is mutable

On Wed, 11 Nov 2015 07:30 pm, Marko Rauhamaa wrote: > Steven D'Aprano : > >> Since compile, eval and exec are Python built-ins, if it doesn't >> include a byte-code compiler, it isn't Python. It's just a subset of >> Python. > > compile() can be implemented

Re: Question about math.pi is mutable

Op 10-11-15 om 00:29 schreef Ben Finney: > > Who is doing what to whom? The user of the library isn't doing anything > to the library author, so what is it the library author would consent > to? Instead, you seem to be trying to assert a *power* of the library > author to restrict the library

Re: Question about math.pi is mutable

In a message of Tue, 10 Nov 2015 17:10:09 +1100, Ben Finney writes: >Steven D'Aprano writes: > >> Ben, I fear that you are not paying attention to me :-) > >Possibly, though I also think there's miscommunication in this thread. > >You speak of “compile time” and “run time”.

Re: Question about math.pi is mutable

On 11/9/2015 9:37 PM, Steven D'Aprano wrote: The compiler doesn't need to decide *in advance* whether the attribute might have changed. It knows whether it has changed or not *at runtime*. You are using 'compiler' when you should, to avoid confusion, use 'interpreter'. It's one thing to

Re: Question about math.pi is mutable

Laura Creighton writes: > In a message of Tue, 10 Nov 2015 17:10:09 +1100, Ben Finney writes: > >I am a Bear of Little Brain, but: Isn't anything that the *compiler* > >does, by definition done at *compile* time? > > No. > > We used to have a pretty strict defintion about what a

Re: Question about math.pi is mutable

On Tue, 10 Nov 2015 11:14 pm, Ben Finney wrote: >> Python -- yes, even CPython -- has a runtime compiler. When you import >> a module, it is compiled (if needed) just before the import. Likewise, >> when you call the `compile`, `eval` or `exec` built-ins, the compiler >> operates. >> >> I'm not

Re: Question about math.pi is mutable

On Tue, 10 Nov 2015 05:10 pm, Ben Finney wrote: > Steven D'Aprano writes: > >> Ben, I fear that you are not paying attention to me :-) > > Possibly, though I also think there's miscommunication in this thread. > > You speak of “compile time” and “run time”. You also speak

Re: Question about math.pi is mutable

On Wednesday 11 November 2015 00:26, BartC wrote: > Does the Python language specify how it is to be compiled and executed? Not in so many words, but there are limitations on what you can do based on the specified semantics of Python. But so long as you meet those semantics, you can implement

Re: Question about math.pi is mutable

On 10/11/2015 11:34, Steven D'Aprano wrote: On Tue, 10 Nov 2015 05:10 pm, Ben Finney wrote: I am a Bear of Little Brain, but: Isn't anything that the *compiler* does, by definition done at *compile* time? In a manner of speaking, yes, of course. But you've missed the critical issue: when

Re: Question about math.pi is mutable

On Mon, Nov 9, 2015 at 11:22 PM, BartC wrote: > I tried this code: > > a=10 > print (a) > > del a > #print (a) > > a=20 > print (a) > > That sort of confirms what you are saying: that names don't even come into > existence until the first time they are encountered. They don't

Re: Question about math.pi is mutable

On 2015-11-08, Marko Rauhamaa wrote: > Grant Edwards : > >> On 2015-11-07, Marko Rauhamaa wrote: >>> "const" is a very ineffective tool that clutters the code and forces >>> you to sprinkle type casts around your code. >> >> But it

Re: Question about math.pi is mutable

Op 07-11-15 om 04:43 schreef Ben Finney: > Bartc 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

Re: Question about math.pi is mutable

On 09/11/2015 02:23, Steven D'Aprano wrote: On Mon, 9 Nov 2015 09:35 am, BartC wrote: import m a=10 b=20 c=30 m.f() The set of global names the compiler knows will be ("m","a","b","c"). Wrong. Up to the line "c=30", the set of names the compiler can infer are m, a, b and c. Once the line

Re: Question about math.pi is mutable

On Tue, 10 Nov 2015 06:45 am, Ben Finney wrote: > Steven D'Aprano writes: > >> The compiler doesn't need to decide in advance whether or not the >> module attributes have been changed. It can decide that at runtime, >> just before actually looking up the attribute. In

Re: Question about math.pi is mutable

Steven D'Aprano writes: > The compiler doesn't need to decide in advance whether or not the module > attributes have been changed. It can decide that at runtime, just before > actually looking up the attribute. In pseudo-code: > > if attribute might have changed: >

Re: Question about math.pi is mutable

On 09/11/2015 01:04, Ben Finney wrote: Chris Angelico writes: Hmm, then I was misunderstanding what BartC was advocating. I didn't think it would *fail* in the presence of dynamic attributes, but merely *perform suboptimally* (and presumably worse than current CPython).

Re: Question about math.pi is mutable

In a message of Tue, 10 Nov 2015 06:45:40 +1100, Ben Finney writes: >So the remaining space of code that is safe for the proposed >optimisation is trivially small. Why bother with such optimisations, if >the only code that can benefit is *already* small and simple? You have things backwards. The

Re: Question about math.pi is mutable

BartC writes: > On 09/11/2015 01:04, Ben Finney wrote: > > There isn't a way for the compiler to *know*, in all cases, whether > > module attributes will be updated during the lifetime of the program > > In what way can an attribute be updated, other than deleting it >

Re: Question about math.pi is mutable

Steven D'Aprano writes: > The compiler doesn't need to decide in advance whether or not the > module attributes have been changed. It can decide that at runtime, > just before actually looking up the attribute. In pseudo-code: > > if attribute might have changed: >

Re: Question about math.pi is mutable

Steven D'Aprano writes: > Ben, I fear that you are not paying attention to me :-) Possibly, though I also think there's miscommunication in this thread. You speak of “compile time” and “run time”. You also speak of what the compiler can do, at run time. I am a Bear of

Re: Question about math.pi is mutable

On Mon, 9 Nov 2015 12:04 pm, Ben Finney wrote: > There isn't a way for the compiler to *know*, in all cases, whether > module attributes will be updated during the lifetime of the program > (short of, as pointed out elsewhere, running the entire program under > all possible conditions). > > So

Re: Question about math.pi is mutable

Laura Creighton writes: > In a message of Tue, 10 Nov 2015 06:45:40 +1100, Ben Finney writes: > >So the remaining space of code that is safe for the proposed > >optimisation is trivially small. Why bother with such optimisations, if > >the only code that can benefit is *already*

Re: Question about math.pi is mutable

Antoon Pardon writes: > Op 07-11-15 om 04:43 schreef Ben Finney: > > Python assumes the programmers using it are consenting adults. Doing > > harmful things is difficult but not forbidden. > > I find that to be contradictory. Why should you make something difficult

Re: Question about math.pi is mutable

Ben Finney wrote: We should certainly not have a compiler that makes needless difference to code behaviour under test conditions versus non-test conditions. Indeed. Volkswagen tried a version of that recently, and it didn't end well... -- Greg --

Re: Re: Question about math.pi is mutable

Hi, Chris Angelico , Thank you for your help ! :-) From: Chris Angelico Date: 2015-11-06 18:30 To: wa...@travelsky.com CC: python-list Subject: Re: Question about math.pi is mutable On Fri, Nov 6, 2015 at 1:33 PM, wa...@travelsky.com <wa...@travelsky.com> wrote: > Hello, python-

Re: Question about math.pi is mutable

On Sun, 8 Nov 2015 08:44 pm, Marko Rauhamaa wrote: > Steven D'Aprano : > >> On Sun, 8 Nov 2015 01:23 am, Marko Rauhamaa wrote: >>> Correct. That's not Python's fault, however. Python should not try to >>> placate the performance computing people. (Alas, it is now trying to

Re: Question about math.pi is mutable

On 08/11/2015 11:50, Marko Rauhamaa wrote: BartC : On 08/11/2015 11:02, Marko Rauhamaa wrote: That elegant dynamism comes at a cost: method lookup is not a constant memory offset. Rather, it is a dictionary lookup. I've never understood why this seems to be necessary in

Re: Question about math.pi is mutable

Steven D'Aprano : > On Sun, 8 Nov 2015 01:23 am, Marko Rauhamaa wrote: >> 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

Re: Question about math.pi is mutable

On 08/11/2015 12:43, Marko Rauhamaa wrote: BartC : On 08/11/2015 11:50, Marko Rauhamaa wrote: import shutil class Source: def __init__(self): self.remaining = "hello world" def

Re: Question about math.pi is mutable

Paul Rubin : > Marko Rauhamaa writes: >> Point is, the consequences of "proper" use of const are so annoying even >> standard library functions would rather grossly abuse it than tolerate >> compiler warnings everywhere. > > I'm not sure what the C

Re: Question about math.pi is mutable

Steven D'Aprano : > So... you have no need for Python to be fast, and even less need for > Python code to be correct... Correct. If I didn't think so, I'd still be using Java instead of Python. > Or perhaps you mean that you don't need help writing correct code, > because

Re: Question about math.pi is mutable

BartC : > On 08/11/2015 11:50, Marko Rauhamaa wrote: >> >> import shutil >> >> class Source: >> def __init__(self): >> self.remaining = "hello world" >> >> def read(self, count): >>

Re: Question about math.pi is mutable

On Sun, Nov 8, 2015 at 10:19 PM, BartC wrote: > I've never understood why this seems to be necessary in Python. Why do names > have to be looked up? (I'm assuming this is searching by name in some sort > of table.) Yes, if by "searching" you include hash-table lookup. A CPython

Re: Question about math.pi is mutable

On 11/08/2015 04:19 AM, BartC wrote: >> That elegant dynamism comes at a cost: method lookup is not a constant >> memory offset. Rather, it is a dictionary lookup. > > I've never understood why this seems to be necessary in Python. Why do > names have to be looked up? (I'm assuming this is

Re: Question about math.pi is mutable

On Sun, 8 Nov 2015 09:40 pm, Bartc wrote: > On 08/11/2015 02:59, Steven D'Aprano wrote: >> On Sun, 8 Nov 2015 02:01 am, Bartc wrote: >> >>> 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

Re: Question about math.pi is mutable

On 08/11/2015 11:30, Steven D'Aprano wrote: On Sun, 8 Nov 2015 09:40 pm, Bartc wrote: This is what I mean about people not understanding it! I'm pretty sure I understand what *I* mean by constant, and what Pascal means by it, and why the Pascal meaning doesn't quite match what Python can

Re: Question about math.pi is mutable

BartC : >>> On 08/11/2015 11:50, Marko Rauhamaa wrote: import shutil class Source: def __init__(self): self.remaining = "hello world" def

Re: Question about math.pi is mutable

On Mon, Nov 9, 2015 at 12:42 AM, BartC wrote: > Sorry, you'll have to assume I'm very stupid. > > What exactly is being looked up, and in what? > > From what I can understand in your example: > > * You are calling shutil.copyfileobj with two arguments, which happen to be >

Re: Question about math.pi is mutable

Bartc : > (In the case of Python, the main obstacle is that a constant name from > inside an imported module is not visible when this module is compiled > to byte-code. So it has to assume it can be anything.) Which it can. Optimizing for naive floating-point constants could be

Re: Question about math.pi is mutable

On 08/11/2015 02:59, Steven D'Aprano wrote: On Sun, 8 Nov 2015 02:01 am, Bartc wrote: 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.)

Re: Question about math.pi is mutable

On 08/11/2015 03:50, Steven D'Aprano wrote: On Sun, 8 Nov 2015 01:23 am, Marko Rauhamaa wrote: Your point of view is really down-to-earth. It's slightly analogous to protesting against Unicode because you only ever need ASCII. I don't think so, but in any case, Bart is *way* oversimplifying

Re: Question about math.pi is mutable

BartC : > On 08/11/2015 11:02, Marko Rauhamaa wrote: >> That elegant dynamism comes at a cost: method lookup is not a constant >> memory offset. Rather, it is a dictionary lookup. > > I've never understood why this seems to be necessary in Python. Why do > names have to be looked

Re: Question about math.pi is mutable

On Mon, Nov 9, 2015 at 4:54 AM, BartC wrote: > That would be true for locals as well. But as far as I can tell from the > CPython source code, byte-codes uses an index to represent a local, which > represents an entry into a linear table. > > I can't quite see why that can't be

Re: Question about math.pi is mutable

BartC writes: > I've never understood why this seems to be necessary in Python. Why do > names have to be looked up? (I'm assuming this is searching by name in > some sort of table.) No, it is literally looking the name up as a key in a namespace dictionary — which is just like

Re: Question about math.pi is mutable

On 08/11/2015 21:00, Ben Finney wrote: BartC writes: I've never understood why this seems to be necessary in Python. Why do names have to be looked up? (I'm assuming this is searching by name in some sort of table.) No, it is literally looking the name up as a key in a

Re: Question about math.pi is mutable

On Nov 8, 2015 12:01 PM, "BartC" wrote: > > But then, you say that additional attributes, potentially millions of different ones, can be invented at runtime. Although I don't see how it can remove names that are part of the source code: if "A.B" is in the file, then surely "A"

Re: Question about math.pi is mutable

On 08/11/2015 15:59, Michael Torrie wrote: On 11/08/2015 04:19 AM, BartC wrote: That elegant dynamism comes at a cost: method lookup is not a constant memory offset. Rather, it is a dictionary lookup. I've never understood why this seems to be necessary in Python. Why do names have to be

Re: Question about math.pi is mutable

On 08/11/2015 18:01, Chris Angelico wrote: On Mon, Nov 9, 2015 at 4:54 AM, BartC wrote: That would be true for locals as well. But as far as I can tell from the CPython source code, byte-codes uses an index to represent a local, which represents an entry into a linear table.

Re: Question about math.pi is mutable

On 09/11/2015 00:00, Ben Finney wrote: BartC writes: Is this typical Python code? Creating global objects in other modules (or writing all over essential data structures in a library module). Not “creating global objects”, but changing the referent of a name in some other

Re: Question about math.pi is mutable

On Sun, 8 Nov 2015 11:28 pm, Chris Angelico wrote: > On Sun, Nov 8, 2015 at 10:19 PM, BartC wrote: >> I've never understood why this seems to be necessary in Python. Why do >> names have to be looked up? (I'm assuming this is searching by name in >> some sort of table.) > >

Re: Question about math.pi is mutable

On Sun, 8 Nov 2015 11:39 pm, BartC wrote: >> shutil.copyfileobj(Source(), Dest()) >> > > OK, so here, it is necessary to resolve "copyfileobj" by seeing if > "shutil" is something that contains a name "copyfileobj" that

Re: Question about math.pi is mutable

Chris Angelico writes: > Hmm, then I was misunderstanding what BartC was advocating. I didn't > think it would *fail* in the presence of dynamic attributes, but > merely *perform suboptimally* (and presumably worse than current > CPython). There isn't a way for the compiler to

Re: Question about math.pi is mutable

Chris Angelico writes: > Testing/mocking is a completely separate consideration (eg you can > inject a shadow for a built-in name) Not for the purpose of making compiler optimisations, as BartC is advocating. The compiler definitely should not treat “is this code part of a

Re: Question about math.pi is mutable

BartC writes: > Is this typical Python code? Creating global objects in other modules > (or writing all over essential data structures in a library module). Not “creating global objects”, but changing the referent of a name in some other module. Yes, that's quite a common

Re: Question about math.pi is mutable

On Mon, Nov 9, 2015 at 11:00 AM, Ben Finney wrote: > BartC writes: > >> Is this typical Python code? Creating global objects in other modules >> (or writing all over essential data structures in a library module). > > Not “creating global objects”,

Re: Question about math.pi is mutable

Chris Angelico writes: > On Mon, Nov 9, 2015 at 11:26 AM, Ben Finney > wrote: > > Chris Angelico writes: > > > >> Testing/mocking is a completely separate consideration (eg you can > >> inject a shadow for a built-in name) > > >

Re: Question about math.pi is mutable

On Mon, Nov 9, 2015 at 11:50 AM, Ben Finney wrote: > You misunderstand me. I'm not saying the optimisations would be > crippled. I am saying that, in order to achieve those optimisations, the > *test code* would be crippled. > > I am pointing out that the assumption

Re: Question about math.pi is mutable

On Mon, 9 Nov 2015 09:35 am, BartC wrote: > Suppose this is the python program: > > import m > a=10 > b=20 > c=30 > m.f() > > The set of global names the compiler knows will be ("m","a","b","c"). Wrong. Up to the line "c=30", the set of names the compiler can infer are m, a, b and c. Once the

Re: Question about math.pi is mutable

On Mon, Nov 9, 2015 at 11:26 AM, Ben Finney wrote: > Chris Angelico writes: > >> Testing/mocking is a completely separate consideration (eg you can >> inject a shadow for a built-in name) > > Not for the purpose of making compiler optimisations, as

Re: Question about math.pi is mutable

BartC writes: > On 08/11/2015 21:00, Ben Finney wrote: > > The namespace can change dynamically, which is another way of what > > people have been trying to tell you all through this thread. > > > > The compiler *cannot* know what the names will be at every single > > point

Re: Question about math.pi is mutable

On 08/11/2015 23:13, Dennis Lee Bieber wrote: On Sun, 8 Nov 2015 18:58:36 +, BartC declaimed the following: But then, you say that additional attributes, potentially millions of different ones, can be invented at runtime. Although I don't see how it can remove names that

Re: Question about math.pi is mutable

On 08/11/2015 11:02, Marko Rauhamaa wrote: Bartc : (In the case of Python, the main obstacle is that a constant name from inside an imported module is not visible when this module is compiled to byte-code. So it has to assume it can be anything.) Which it can. That

Re: Question about math.pi is mutable

Am 08.11.15 um 08:45 schrieb Marko Rauhamaa: Grant Edwards : On 2015-11-07, Marko Rauhamaa wrote: "const" is a very ineffective tool that clutters the code and forces you to sprinkle type casts around your code. But it allows the compiler to warn

Re: Question about math.pi is mutable

Marko Rauhamaa writes: > Point is, the consequences of "proper" use of const are so annoying even > standard library functions would rather grossly abuse it than tolerate > compiler warnings everywhere. I'm not sure what the C standard says about that example, but C++ is much

Re: Question about math.pi is mutable

Bartc 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

Re: Question about math.pi is mutable

Bartc writes: > On 07/11/2015 03:43, Ben Finney wrote: > > Bartc 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

Re: Question about math.pi is mutable

On 07/11/2015 12:15, Ben Finney wrote: Bartc 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.

Re: Question about math.pi is mutable

On 07/11/2015 14:23, Marko Rauhamaa wrote: Bartc : 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. The gap between

Re: Question about math.pi is mutable

In a message of Sat, 07 Nov 2015 13:00:37 +, 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

Re: Question about math.pi is mutable

On 07/11/2015 11:35, Ben Finney wrote: Bartc writes: On 07/11/2015 03:43, Ben Finney wrote: Bartc 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

Re: Question about math.pi is mutable

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

Re: Question about math.pi is mutable

Marko Rauhamaa : > 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"

Re: Question about math.pi is mutable

On 07/11/2015 14:28, Marko Rauhamaa wrote: Marko Rauhamaa : 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

Re: Question about math.pi is mutable

On 07/11/2015 03:43, Ben Finney wrote: Bartc 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

Re: Question about math.pi is mutable

On 2015-11-07, Marko Rauhamaa wrote: > Marko Rauhamaa : > >> 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

Re: Question about math.pi is mutable

Bartc : > (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

Re: Question about math.pi is mutable

Grant Edwards : > I take it you don't write embedded code that runs from ROM? I do. The > const keyword is the most valuable addition to the C language since > the function prototype. Without it, you used to have to jump through > all sorts of hoops to get read-only data

Re: Question about math.pi is mutable

On 07/11/2015 23:02, Bartc wrote: On 06/11/2015 22:26, Thomas 'PointedEars' Lahn wrote: Bartc wrote: ^ Please fix. What's the problem? He is the problem. I assume it's because he thinks he's a dog, cat or some other animal. -- My fellow Pythonistas, ask not what our language can

Re: Question about math.pi is mutable

On 06/11/2015 22:26, Thomas 'PointedEars' Lahn wrote: Bartc wrote: ^ Please fix. What's the problem? -- https://mail.python.org/mailman/listinfo/python-list

Re: Question about math.pi is mutable

Bartc writes: > On 06/11/2015 22:26, Thomas 'PointedEars' Lahn wrote: > > Bartc wrote: > > ^ > > Please fix. > > What's the problem? As far as I can tell, you're being asked to change that to your “real” name, whatever that is supposed to mean. I recommend you ignore that

Re: Question about math.pi is mutable

On Sun, Nov 8, 2015 at 10:32 AM, Ben Finney wrote: > I recommend you ignore that request; “Bartc” is fine as a name here, > IMO. Given that LARTC means Linux Advanced Routing and Traffic Control, I'm guessing Bartc is all about *BSD networking? :) ChrisA --

Re: Question about math.pi is mutable

On Sun, 8 Nov 2015 02:01 am, Bartc wrote: > 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.) Unfortunately the concept of "named

Re: Question about math.pi is mutable

On Sun, 8 Nov 2015 04:46 am, Marko Rauhamaa wrote: > Bartc : > >> (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

Re: Question about math.pi is mutable

On 2015-11-07, Marko Rauhamaa wrote: > Grant Edwards : > >> I take it you don't write embedded code that runs from ROM? I do. The >> const keyword is the most valuable addition to the C language since >> the function prototype. Without it, you used to

Re: Question about math.pi is mutable

On Sun, 8 Nov 2015 01:23 am, Marko Rauhamaa wrote: > Bartc : > >> 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 >>

Re: Question about math.pi is mutable

Steven D'Aprano writes: > Surely that is obvious? I don't speak much C, but I would expect that inside > the functions, const parameters can be read, but not assigned to. "*const" > is a mystery to me though. There's a program (and now a website) called cdecl that can decode

Re: Question about math.pi is mutable

Grant Edwards : > On 2015-11-07, Marko Rauhamaa wrote: >> "const" is a very ineffective tool that clutters the code and forces >> you to sprinkle type casts around your code. > > But it allows the compiler to warn you if you pass a pointer to a >

Re: Question about math.pi is mutable

On Sat, 7 Nov 2015 09:26 am, Thomas 'PointedEars' Lahn wrote: ^ > Bartc wrote: > ^ > Please fix. Why? There's nothing wrong with somebody signing their posts "Bartc". It is no more silly than somebody calling themselves "PointedEars". Please

Re: Question about math.pi is mutable

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

Re: Question about math.pi is mutable

On 11/6/2015 5:26 PM, Thomas 'PointedEars' Lahn wrote: Bartc wrote: import math math.pi=0 print (math.pi) In Python, presumably 'pi' is just another variable, and variables can be written to. “pi” is the name of an attribute of the module object referred to by “math”. (Perhaps math.pi

Re: Question about math.pi is mutable

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

  1   2   >