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

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

Question about math.pi is mutable

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

Contents

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

#98633

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> 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 "code object." I suspect even a string might
work as a code object.


Marko

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

#98635

On Wed, 11 Nov 2015 07:30 pm, Marko Rauhamaa wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> 
>> 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 "code object." I suspect even a string might
> work as a code object.

Sure. That's just quality of implementation. In principle, a Python
interpreter might even operate without any byte-code at all, parsing each
line of code before executing it.

Nevertheless, whatever quality of implementation compile/eval/exec offer,
they *must* be available at runtime, otherwise the language is just a
subset of Python.



-- 
Steven

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

#98580

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 say that *in principle* any function might modify or
> shadow builtins. That's true, because we don't know what's inside the
> function. But the compiler knows, because it actually executes the code

'interpreter'

> inside the function and can see what happens when it does. It doesn't have
> to predict in advance whether or not calling `func(x)` shadows the builtin
> `len` function, *it can see for itself* whether it did or not.
>
> At compile time, `func(x)` might do anything. But at runtime, we know
> exactly what it did, because it just did it.
>
> Imagine that the compiler keeps track of whether or not builtins has been

/compiler/code compiled by the compiler and interpreted by the 
interpreter (which could be the CPU)/

> modified. Think of it as a simple "dirty" flag that says "yes, builtins is
> still pristine" or "no, something may have shadowed or modified the
> builtins". That's fairly straight-forward: builtins is a dict, and the
> compiler can tell whether or not __setitem__ etc has been called on that
> dict. Likewise, it can keep track of whether or not a global has been
> created that shadows builtins: some of that can be done statically, at
> compile-time, but most of it needs to be done dynamically, at runtime.

This is more or less Victor Stinner's proposal, and he has a working 
prototype that runs nearly all the test suite.  He now plans to refine 
it and measure changes in space and time usage.

> If the flag is set, the compiler knows that the optimization is unsafe and
> it has to follow the standard name lookup, and you lose nothing: the
> standard Python semantics are still followed. But if the flag is clear, the
> compiler knows that nothing has shadowed or modified builtins, and a whole
> class of optimizations are safe. It can replace a call to (say) len(x) with
> a fast jump, avoiding an unnecessary name lookup in globals, and another
> unnecessary name lookup in builtins. Or it might even inline the call to
> len. Since *most* code doesn't play tricks with builtins, the overhead of
> tracking these changes pays off *most* of the time -- and when it doesn't,
> the penalty is very small.


-- 
Terry Jan Reedy

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

#98585

In a message of Tue, 10 Nov 2015 17:10:09 +1100, Ben Finney writes:
>Steven D'Aprano <steve@pearwood.info> 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 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 compiler was, and
what an interpreter was.  You did the compile things at compile time,
and then you the the interpreter things at runtime.

No more.  We have Just in Time compilers.  They do their compiling
at run time.  Or perhaps 'there is no such thing as compile time
any more'.

Laura

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

#98591

Laura Creighton <lac@openend.se> 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 compiler was,
> and what an interpreter was. You did the compile things at compile
> time, and then you the the interpreter things at runtime.
>
> No more. We have Just in Time compilers. They do their compiling at
> run time. Or perhaps 'there is no such thing as compile time any
> more'.

Very well. I argued on the basis of what could be determined at the time
Steven refers to as “compile time”, i.e. before any part of the module
begins to run.


Steven D'Aprano <steve@pearwood.info> writes:

> 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 calling this a JIT compiler, because the simple-minded
> compilation performed by `compile` etc doesn't use any run-time
> information. It just statically compiles the code to byte-code.

That's what I though. I'm aware of JIT compilers, and was pretty sure
Python doesn't have them. What's more, if it operates at a whole-module
level, and not later than when the module is imported.

Under those conditions, I maintain my objection to the proposed
optimisation.

The proposal is explicitly for optimisations made by the Python
compiler. As proposed, it only seems to be worthwhile once Python no
longer has a distinct “compiler” and “interpreter” is dissolved. Until
then, it seems pointless.

-- 
 \     “There is something wonderful in seeing a wrong-headed majority |
  `\           assailed by truth.” —John Kenneth Galbraith, 1989-07-28 |
_o__)                                                                  |
Ben Finney

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

#98629

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 calling this a JIT compiler, because the simple-minded
>> compilation performed by `compile` etc doesn't use any run-time
>> information. It just statically compiles the code to byte-code.
> 
> That's what I though. I'm aware of JIT compilers, and was pretty sure
> Python doesn't have them. 

What do you think PyPy is then?

CPython is intentionally a pretty simple-minded compiler. Even no-brainer
constant folding is mildly controversial among some Python devs. But
CPython isn't "Python", it is just the reference implementation. Nuitka
aims to be an optimized AOT (Ahead Of Time) Python compiler, and PyPy is
already a state of the art (if not cutting edge) JIT Python compiler.

And if Victor Skinner's experimental FAT Python works out, even CPython
itself will gain some simple JIT techniques, rather similar to what Psycho
was doing ten years ago.


> What's more, if it operates at a whole-module 
> level, and not later than when the module is imported.

Now you're getting into implementation details of the JIT compiler. Can it
track entities across modules? How exactly does it operate?

PyPy is a "tracing JIT", which (if I have understood correctly) means it
actually analyses the code as it runs, using knowledge gained at runtime to
dynamically decide what to compile. This means that PyPy is best suited to
code that has long-running loops, and not well suited to scripts that don't
run for a long time. But another (hypothetical) JIT compiler might be more
like Psycho.


> Under those conditions, I maintain my objection to the proposed
> optimisation.
> 
> The proposal is explicitly for optimisations made by the Python
> compiler. As proposed, it only seems to be worthwhile once Python no
> longer has a distinct “compiler” and “interpreter” is dissolved. Until
> then, it seems pointless.

Python has not had a distinct "compiler" and "interpreter" since about
version 0.1. The execution module of Python as a dynamic byte-code
compiled, interpreted language with eval and exec *depends* on the compiler
being available during the execution phase, i.e. at runtime.

Some of the things I've suggested already exist, and have proven that they
work: Psycho and PyPy, to say nothing of similar technologies for other
equally dynamic languages such as Javascript and Smalltalk. Others are
state of the art compiler techniques -- they might not have been applied to
*Python* but that's only because nobody has got around to it, not because
it can't be done.

I daresay that there are implementation challenges to making Python faster
than it is without compromising on the semantics of the language, but there
is nothing fundamentally impossible about the idea.

Ben, I know that the IT crowd is rather conservative, and the Python
community even more so, but at the point where you are denying the
possibility of technologies which *already exist* I think that things have
got a bit out of hand. It's a bit like somebody getting on Twitter to
tweet "A globally interconnected communication network allowing computers
all over the world to communicate? Impossible! And even if it were
possible, nobody would use it."

;-)

 

-- 
Steven

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

#98551

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 reason that you want to optimise this is that it is small, simple, 
and slow_slow_slow_slow_slow.

It is the things that are complicated and large that usually aren't worth
optimising. You don't call them often enough for it to be worth it to
optimise them.  Your analysis and set up overhead will be more than
the speed gains you realise.  If you can find something that is small,
simple, and ubiquitous -- that's the place to look for performance
gains.

PyPy gets most of its speed by optimising loops.  Most loops in Python
run perfectly well without making use of any of the dynanism that is
potentially available -- "it's nice to have the ability to do something
that, as a matter of fact, I am not going to do right now".  But the
overhead for checking to see if I have made use of it is huge, which
is why 'set things up so that if it is never used, we can go pretty much
as fast as C' is a win.  After you have paid for your setup costs for
making the fast and the slow path, you get enough fast path activity
that you come out way ahead.

Laura

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

#98561

Laura Creighton <lac@openend.se> 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* small and simple?
>
> You have things backwards.
> The reason that you want to optimise this is that it is small, simple, 
> and slow_slow_slow_slow_slow.
>
> It is the things that are complicated and large that usually aren't
> worth optimising. You don't call them often enough for it to be worth
> it to optimise them.

I appreciate you making the the distinction explicit between a small and
simple *code unit* (e.g. an small, simple, often-called function),
versus a large and complex *code unit* (e.g. a large, complex,
infrequently-called class definition).

I'm pointing out an orthogonal issue: The only code to which the
proposed optimisation could apply is *module-level* (infrequently
called) code, which *has no complications* (i.e. not a code unit).

The simplicitly of the small section of code is not the issue; the
dynamism of the entire program is what negates the applicability of the
optimisation.

If the simple, predictable-by-the-compiler segment of code were actually
isolated in a simple unit, then yes, such optimisations might be
considered. But, as already discussed, the optimisation is not intended
to apply to such code units. So that is moot in this case.

Instead, we're talking about optimisations proposed *only* for
module-level code (i.e. not isolated); and what negates their
applicability is *any* dynamism (i.e. not simple), anywhere in the
program (i.e. not a code unit). The space of applicability for the
proposed optimisation shrinks to irrelevance, AFAICT.

-- 
 \        “If the arguments in favor of atheism upset you, explain why |
  `\        they’re wrong. If you can’t do that, that’s your problem.” |
_o__)                                     —Amanda Marcotte, 2015-02-13 |
Ben Finney

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

#98544

On 09/11/2015 01:04, Ben Finney wrote:
> Chris Angelico <rosuav@gmail.com> 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 *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 altogether?

(Moving or renaming can be done in terms of creation and deletion. For 
the purposes of trying to avoid a lookup, we're not that interested in 
much else.)

-- 
Bart C.

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

#98550

BartC <bc@freeuk.com> 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
> altogether?

* Bind a new name to a value.
* Re-bind an existing name to a different value.
* Delete an existing name.

Any of those can be done at run-time, in any module's namespace, by
arbitrary code somewhere in the program.

-- 
 \        “Sane people have an appropriate perspective on the relative |
  `\     importance of foodstuffs and human beings. Crazy people can't |
_o__)                 tell the difference.” —Paul Z. Myers, 2010-04-18 |
Ben Finney

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

#98477

BartC <bc@freeuk.com> 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 any other Python dictionary, but
nominated internally for use as the namespace dictionary.

The distinction is important, because like any other dictionary it can
change at run-time and the bindings between name and value can change,
can be added, and can be removed.

> When a module is compiled, while the compiler can't see the
> definitions inside the imported modules, it /will/ know all the names
> that appear in this module, so it can organise them into fixed tables.

Not true. 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
they'll be looked un in the namespace dictionary. This dynamism of each
namespace is a Python feature.

-- 
 \                  “It is … incumbent upon us to recognize that it is |
  `\    inappropriate for religion to play any role in issues of state |
_o__)        [of] a modern democracy.” —Lawrence M. Krauss, 2012-05-28 |
Ben Finney

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

#98481

On 08/11/2015 21:00, Ben Finney wrote:
> BartC <bc@freeuk.com> 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 any other Python dictionary, but
> nominated internally for use as the namespace dictionary.
>
> The distinction is important, because like any other dictionary it can
> change at run-time and the bindings between name and value can change,
> can be added, and can be removed.

That part is not a problem.

>> When a module is compiled, while the compiler can't see the
>> definitions inside the imported modules, it /will/ know all the names
>> that appear in this module, so it can organise them into fixed tables.
>
> Not true. 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
> they'll be looked un in the namespace dictionary. This dynamism of each
> namespace is a Python feature.

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

I don't believe code can remove these names (that would cause problems). 
You say the set of global names can be added to - after this lot, but I 
can't see that the first four are going to change.

Therefore these names could be referred to by index.

Attributes are harder because they are more of a free-for-all, but 
suppose you do have m.f().

"m" is easy, it's entry 0 in the global table for this module, so no 
lookup-by-name is needed. You examine it, and it's a module.

It's now necessary to find f within the global table for m. This is 
where it gets tricky if you want to avoid a lookup. And I expect you 
will say that any code can randomly add names within the global table of m.

But bear with me. Suppose the interpreter were to maintain a table for 
each static (not runtime) attribute encountered in the source code. The 
compile can produce empty tables for the attributes it's seen. In this 
case the table for "f" would be empty: (). The compiler will also 
produce a list of such tables for all attributes.

Here there is only one, and the "f" table will have index 0, which is 
what can be used within the byte-code.

The hard part would be in building and maintaining that table. When 
module m is loaded, let's say it defines function "f". Now that can be 
used to create the first entry in the attribute table for "f": ($m, 
$m.f). Here, $m is some internal reference to m, and $m.f is some 
internal reference to m.f().

Now back to resolving m.f(): we know the "m" part is module $m. For "f", 
it looks through its attribute table (remember it's index 0, so instant 
access), and there is only one entry. We're lucky as that entry's owner 
matches the "m." part of this access. So we know it refers to $m.f. No 
lookups by name needed in this case.

However not all random attributes will be neatly defined somewhere as 
functions or classes that will be listed in these little tables. So 
sometimes, an actual lookup will still be needed.

-- 
Bart C

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

#98482

BartC <bc@freeuk.com> 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 they'll be looked un in the namespace dictionary. This
> > dynamism of each namespace is a Python feature.
>
> 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").
>
> I don't believe code can remove these names (that would cause
> problems).

It may indeed cause problems. Those names can nevertheless be changed.

Names at module level are simply attributes on the module object. The
module can gain attributes, lose attributes, and its attributes can
chage; its namespace is just as mutable as any other object's namespace.

> You say the set of global names can be added to - after this lot, but
> I can't see that the first four are going to change.

You have not yet learned enough about the Python data model:

    A module object has a namespace implemented by a dictionary object
    (this is the dictionary referenced by the __globals__ attribute of
    functions defined in the module). Attribute references are
    translated to lookups in this dictionary, e.g., m.x is equivalent
    to m.__dict__["x"]. A module object does not contain the code
    object used to initialize the module (since it isn’t needed once
    the initialization is done).

    <URL:https://docs.python.org/3/reference/datamodel.html>

Any name can be deleted, just like any other reference, with the ‘del’
statement.

Any reference (including names) can be added or changed in a module
namespace like any other object's namespace.

> Attributes are harder because they are more of a free-for-all

Please understand that a module *is* an object, and a name in a module's
namespace *is* an attribute on that module.

Also, please *learn about* the way Python works; you have certainly been
here long enough to know how to look up answers in the documentation
instead of making ignorant assertions here.

-- 
 \       “What I resent is that the range of your vision should be the |
  `\                                 limit of my action.” —Henry James |
_o__)                                                                  |
Ben Finney

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

#98499

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 line "m.f()" executes, *all bets are off*. The
compiler can no longer infer *anything* about those names. In principle,
m.f may have reached into the globals and deleted *any* of the names,
including itself.


> I don't believe code can remove these names (that would cause problems).

Of course names can be removed. There's even a built-in statement to do
so: "del".

Deleting names from namespaces is a moderately common thing to do.


> You say the set of global names can be added to - after this lot, but I
> can't see that the first four are going to change.

Of course they can change.


> Therefore these names could be referred to by index.

Perhaps. But that adds significant complexity to the compiler, and the
performance benefits *in practice* may not be as good as you imagine. After
all, there is usually far more to real programs than just getting and
setting names.

Nevertheless, such indexed name lookups do have the potential to save time,
and in fact that's what CPython already does with local variables. We can
get a *rough* indication of how big a difference this micro-optimization
makes by disabling it. Unfortunately, this only works in Python 2 -- in
Python 3, you can no longer defeat the local variable optimization.


def unopt():
    from math import *  # Defeats the local variable optimization.
    x = sin; x = cos; x = tan; x = exp; x = pi
    x = e; x = trunc; x = log; x = hypot; x = sqrt
    return

def opt():
    from math import sin, cos, tan, exp, pi, e, trunc, log, hypot, sqrt
    x = sin; x = cos; x = tan; x = exp; x = pi
    x = e; x = trunc; x = log; x = hypot; x = sqrt
    return

from timeit import Timer
t1 = Timer("unopt()", setup="from __main__ import unopt")
t2 = Timer("opt()", setup="from __main__ import opt")

# Best of five trials of 1,000,000 calls each.
print min(t1.repeat(repeat=5))
print min(t2.repeat(repeat=5))


When I run this code, I get

16.5607659817 seconds for unopt, and 3.58955097198 seconds for opt. That's a
significant difference. But remember that not all of that difference is due
to the name lookups (unopt also imports more stuff), and also remember that
this is a pretty unrealistic benchmark. Real functions do more than just
look up a variable name over and over.


> Attributes are harder because they are more of a free-for-all, but
> suppose you do have m.f().
> 
> "m" is easy, it's entry 0 in the global table for this module, so no
> lookup-by-name is needed. You examine it, and it's a module.
> 
> It's now necessary to find f within the global table for m. This is
> where it gets tricky if you want to avoid a lookup. And I expect you
> will say that any code can randomly add names within the global table of
> m.

Of course it can. It can even add names to builtins.

Oh, and you don't know that m is a module until you inspect it at runtime.
It could be any object.



> But bear with me. Suppose the interpreter were to maintain a table for
> each static (not runtime) attribute encountered in the source code. The
> compile can produce empty tables for the attributes it's seen. In this
> case the table for "f" would be empty: (). The compiler will also
> produce a list of such tables for all attributes.

I have no idea how well this implementation would work. My guess is that if
you look at, say, Nuitka, it may perform optimizations like this. (The aim
of Nuitka is to be a static optimizing compiler.) PyPy may do things like
this too, using a JIT optimizing compiler. PyPy is capable of far more than
such simple optimizations.

As I have argued all along, it is certainly not true that Python's
dynamicism prevents all such optimizations. It just makes them harder.


-- 
Steven

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

#98514

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 "m.f()" executes, *all bets are off*. The
> compiler can no longer infer *anything* about those names. In principle,
> m.f may have reached into the globals and deleted *any* of the names,
> including itself.
>
>
>> I don't believe code can remove these names (that would cause problems).
>
> Of course names can be removed. There's even a built-in statement to do
> so: "del".

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 
just contain None, or some other value which means the name itself 
exists, but it hasn't been initialised to anything. And that del removes 
the name completely from the set that are known.

That makes Python unlike any other language I've used.

On the other hand, if I put the above code into a function and then call 
the function, attempting to print a just after it's been deleted results in:

  UnboundLocalError: local variable 'a' referenced before assignment

So while local names can presumably be manipulated just like globals, 
that doesn't stop being implemented via a fixed slot in a table.

>> Therefore these names could be referred to by index.
>
> Perhaps. But that adds significant complexity to the compiler,

It would mean that each name needs a flag indicating whether or not it 
has yet been brought into existence by an assignment in the program, or 
has been banished by the use of del.

> and the
> performance benefits *in practice* may not be as good as you imagine. After
> all, there is usually far more to real programs than just getting and
> setting names.

Any programs will consist largely of pushing names and constants (LOAD 
ops), performing some operations on them, and then sometimes popping 
values (STORE ops).

If the names represent complex data, then doing the work on the data 
will dominate the timings. But often it's the 'little' variables that 
hold indices, counts, flags etc that are being frequently loaded and stored.

> def unopt():
>      from math import *  # Defeats the local variable optimization.
>      x = sin; x = cos; x = tan; x = exp; x = pi
>      x = e; x = trunc; x = log; x = hypot; x = sqrt
>      return
>
> def opt():
>      from math import sin, cos, tan, exp, pi, e, trunc, log, hypot, sqrt
>      x = sin; x = cos; x = tan; x = exp; x = pi
>      x = e; x = trunc; x = log; x = hypot; x = sqrt
>      return

> When I run this code, I get
>
> 16.5607659817 seconds for unopt, and 3.58955097198 seconds for opt. That's a
> significant difference.

The optimisation means the code can use LOAD_FAST instead of LOAD_NAME. 
It still uses STORE_FAST instead of STORE_NAME, so perhaps the 
difference could be even more if the unoptimised version had to use 
STORE_NAME.

-- 
Bartc

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

#98515

On Mon, Nov 9, 2015 at 11:22 PM, BartC <bc@freeuk.com> 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 just contain
> None, or some other value which means the name itself exists, but it hasn't
> been initialised to anything. And that del removes the name completely from
> the set that are known.
>
> That makes Python unlike any other language I've used.

It's a direct consequence of the dynamic namespacing. You'll find
similar results in JavaScript/ECMAScript if you play around with
prototype-based inheritance, which has a similar rule ("if the
property isn't here, look at the prototype") to the Python namespacing
rule ("if the name isn't in this namespace, look at the next one
outward").

And you're absolutely correct. Unused names do not "contain None" in
any sense - they utterly do not exist. When you 'del' a name, that
name utterly ceases to exist.

> On the other hand, if I put the above code into a function and then call the
> function, attempting to print a just after it's been deleted results in:
>
>  UnboundLocalError: local variable 'a' referenced before assignment

That's a special case of NameError that was added to make it a bit
easier to track down certain types of bug.

> So while local names can presumably be manipulated just like globals, that
> doesn't stop being implemented via a fixed slot in a table.
>

Global names are simply module attributes, so they can be manipulated
in many ways. Function locals are not; there's no way to say
"current_stack_frame.foo = 2", so there's no need to hack around with
name lookups. (The locals() dictionary isn't meant to be modified, and
changes may or may not have effect on actual local name bindings.)

ChrisA

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

#98444

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 parameter that won't be changed nor any addressable location.)
>>
>> Unfortunately the concept of "named value" doesn't match well with
>> Python's design. That implies a separate compilation step which doesn't
>> fit well with Python's runtime semantics. Very little happens at
>> compile-time in Python that *must* happen at compile-time.
>>
>> I'm also not sure what difference you think there is between "named
>> value" and "variable that won't change once initialised".
> 
> 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
do. I'm not sure I understand what *you* mean, or why you think a "variable
that won't change" isn't good enough.


> In NASM terms, a named constant is like:
> 
>      daysinweek   equ   7           ; definition
> 
>      mov rax, daysinweek            ; using it, as immediate value
>      mov rbx, daysinweek*2          ; an a 'compile-term' expression
> ;   mov daysinweek,8               ; can't be done! Illegal syntax

In pseudo-Python, we have:

const daysinweek = 7  # let's just pretend it exists
x = daysinweek + 1  # this is fine
daysinweek = 8  # an error

Apart from the difference between compile-time and run-time, why would this
not be satisfactory?

Oh, and just to satisfy Ben, the determined monkey-patcher can write:

globals()['daysinweek'] = 8

if they really want to defeat the compiler. The idea is to avoid
*accidental* bindings.



> While a 'const' variable, C style, might be:
[...]

Why does your C code look like assembler?


> So in native code, a named value is not much different to a literal such
> as 7, or 3.14159. (But unlike C's #define, the name is a proper symbol
> with normal scope rules, and a type).
> 
> The distinction at the machine level can be blurred with some
> instructions sets where there might not be an immediate data option for
> some data widths or types. Also where named constants are applied to
> things such as strings, which necessarily use storage.

I am not interested in the limitations of low-level machine languages. They
have very little to say about what Python can or should do.


> In the language however, you will not be able to use the named constant
> as an lvalue, and you will usually be able to use it for compile-time
> constant folding and for dimensioning fixed-bound arrays and such.)

We're talking about Python, and how the concept of "const" might apply to a
Python-like language. Compile-time constant folding is not part of it,
because the constant itself might not exist at compile-time:

const START = time.time()

Fixed-bound arrays are irrelevant (neither lists nor arrays are
fixed-bounds; tuples are, but they are constructed at runtime, not compile
time). 


>> Python has a convention for "constants" -- all UPPERCASE names. The fact
>> that the convention exists is enough to prove that the concept
>> of "constant" is a useful one. The difference between Python's
>> pseudo-constants and (say) Pascal's actual constants is that in Python,
>> the burden of ensuring that neither you, nor any of the libraries you
>> call, modifies the "constant" falls on you, the user, whereas in Pascal
>> the compiler or interpreter performs that checking for you.
> 
> With a real named constant the check can always be done at compile-time.
> Unless you have a pure interpreter or some more elaborate way of
> executing source code.

Python has such a "more elaborate way" of executing source code:


exec("""
if condition:
    import time
    const START = time.time()
    x = START + 1
""")




-- 
Steven

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

#98446

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
> do. I'm not sure I understand what *you* mean, or why you think a "variable
> that won't change" isn't good enough.

I showed you what I mean. A named constant is a just a value - with a 
label. That value doesn't need to be stored in a 'box' anywhere, in 
exactly the same manner as values that can be written to (and therefore 
at risk of being overwritten).

But let me turn it around: why is it so important to use variables for 
this purpose?

>> In NASM terms, a named constant is like:
>>
>>       daysinweek   equ   7           ; definition
>>
>>       mov rax, daysinweek            ; using it, as immediate value
>>       mov rbx, daysinweek*2          ; an a 'compile-term' expression
>> ;   mov daysinweek,8               ; can't be done! Illegal syntax
>
> In pseudo-Python, we have:
>
> const daysinweek = 7  # let's just pretend it exists
> x = daysinweek + 1  # this is fine
> daysinweek = 8  # an error
>
> Apart from the difference between compile-time and run-time, why would this
> not be satisfactory?

If that's all that's possible, that it will have to do. And might solve 
the OP's problem.

But for a true named constant, there is no actual assignment. It really 
is not necessary. 'daysinweek' is just a synonym for '7'.

>
>> While a 'const' variable, C style, might be:
> [...]
>
> Why does your C code look like assembler?

I mean the 'const' is C style. The assembly code is to highlight the 
difference between what C calls a const, and what I call a named constant.

> I am not interested in the limitations of low-level machine languages. They
> have very little to say about what Python can or should do.

OK, let's take a higher level one:

  const a = 2
  var   b = 3

  c = a+b

which might generate a byte-code like this:

       push_ci   2
       push_m    [b]
       add
       pop_m     [c]

Now apply this to Python byte-code. Can you not see the advantage of not 
having to deal with variable names, reference counts, garbage collection 
and all that?

I don't know what you had in mind for implementing the pretend 'const' 
in your Python example above. But if it takes the form of an extra 
runtime attribute, then all variable accesses will be slowed then if it 
is has to be checked for every assignment, and 'const' names won't be 
any faster.

>> In the language however, you will not be able to use the named constant
>> as an lvalue, and you will usually be able to use it for compile-time
>> constant folding and for dimensioning fixed-bound arrays and such.)
>
> We're talking about Python, and how the concept of "const" might apply to a
> Python-like language. Compile-time constant folding is not part of it,
> because the constant itself might not exist at compile-time:
>
> const START = time.time()

You're thinking in C terms again. The C 'const' really means 'read-only' 
and applies to ordinary variables. It has nothing to do with my named 
constants which are always known at compile-time

(That's if the definitions are visible. If not, then they will be known 
at the time the module they're in is compiled. Linking these is one of 
the problems in a Python implementation.)

> Fixed-bound arrays are irrelevant (neither lists nor arrays are
> fixed-bounds; tuples are, but they are constructed at runtime, not compile
> time).

Think of a possible 'switch' statement then, and the values for its case 
labels.

> Python has such a "more elaborate way" of executing source code:
>
>
> exec("""
> if condition:
>      import time
>      const START = time.time()
>      x = START + 1
> """)

(1) That is not a const but a variable with a read-only attribute. The 
expression after the "=" should itself be a constant expression or a 
literal value. (No reason why Python shouldn't have such an attribute, 
but that's different from what I'm talking about.)

(2) I assume that the contents of the string passed to exec() are first 
compiled to byte-code. Then that's the same as a normal compile, with 
the same problems of visibility and imparting its constant definitions 
to code that is compiled separately. (If the use 'exec' is more subtle, 
then we might as well give up!)

-- 
BartC

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

#98401

On 2015-11-07, Marko Rauhamaa <marko@pacujo.net> 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.

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 placed into read-only memory.

-- 
Grant

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

#98403

Grant Edwards <invalid@invalid.invalid>:

> 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 placed into read-only memory.

If all you need is a linker directive that places data in a read-only
section, "const" is a very ineffective tool that clutters the code and
forces you to sprinkle type casts around your code.


Marko

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

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

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

csiph-web