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

#98420

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

But it allows the compiler to warn you if you pass a pointer to a
read-only data to a function that expects a pointer to writable data.

For those of us who occasionally make mistakes, such compiler warnings
are very useful.

-- 
Grant

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

#98425

Grant Edwards <invalid@invalid.invalid>:

> On 2015-11-07, Marko Rauhamaa <marko@pacujo.net> 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
> read-only data to a function that expects a pointer to writable data.

Unfortunately, it doesn't:

========================================================================
#include <stdio.h>
#include <string.h>

int main()
{
    const char name[] = "Tom";
    char *p = strstr(name, "Tom");
    strcpy(p, "Bob");
    printf("name = %s\n", name);
    return 0;
}
========================================================================

    $ cc -o prog prog.c
    $ ./prog
    Bob

No warning.

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.


Marko

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

#98426

Am 08.11.15 um 08:45 schrieb Marko Rauhamaa:
> Grant Edwards <invalid@invalid.invalid>:
>
>> On 2015-11-07, Marko Rauhamaa <marko@pacujo.net> 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
>> read-only data to a function that expects a pointer to writable data.
>
> Unfortunately, it doesn't:
>
> ========================================================================
> #include <stdio.h>
> #include <string.h>
>
> int main()
> {
>      const char name[] = "Tom";
>      char *p = strstr(name, "Tom");
>      strcpy(p, "Bob");
>      printf("name = %s\n", name);
>      return 0;
> }
> ========================================================================
>
>      $ cc -o prog prog.c
>      $ ./prog
>      Bob
>
> No warning.
>

That is strange. In C, I can see thet problem here, because it is 
impossible to define a const correct strstr. But in C++ I have expected 
that according to the overload, the const version of strstr would be 
selected (http://www.cplusplus.com/reference/cstring/strstr/ ) . Still:

apfelkiste:Tests chris$ cat prog.cpp
#include <cstdio>
#include <cstring>

int main()
{
     const char name[] = "Tom";
     char *p = strstr(name, "Tom"); // this line should be an error
     strcpy(p, "Bob");
     printf("name = %s\n", name);
     return 0;
}

apfelkiste:Tests chris$ g++ -Wall prog.cpp
apfelkiste:Tests chris$ ./a.out
Bus error: 10

It segfaults because on OSX, const can be stored in write-only memory.

apfelkiste:Tests chris$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.6.0
Thread model: posix


	Christian

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

#98427

Marko Rauhamaa <marko@pacujo.net> 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 stricter about those conversions, and g++ does flag an error if
you compile that code with it.

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

#98432

Paul Rubin <no.email@nospam.invalid>:

> Marko Rauhamaa <marko@pacujo.net> 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 stricter about those conversions, [...]

C++ gets const even more wrong than C, and const is the least of C++'s
problems.


Marko

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

#98528

On 2015-11-08, Marko Rauhamaa <marko@pacujo.net> wrote:
> Grant Edwards <invalid@invalid.invalid>:
>
>> On 2015-11-07, Marko Rauhamaa <marko@pacujo.net> 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
>> read-only data to a function that expects a pointer to writable data.
>
> Unfortunately, it doesn't:
>
>========================================================================
> #include <stdio.h>
> #include <string.h>
>
> int main()
> {
>     const char name[] = "Tom";
>     char *p = strstr(name, "Tom");
>     strcpy(p, "Bob");
>     printf("name = %s\n", name);
>     return 0;
> }
>========================================================================
>
>     $ cc -o prog prog.c
>     $ ./prog
>     Bob
>
> No warning.

Yes, there are ways to fool the compiler by converting a const char*
to a plain char* like you did with strstr().  But in my experience
there are plenty of cases where it will generate a useful warning.

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

That's your opinion.

My differs: _I_ find it useful.  I don't have that many problems with
it.  If you don't like it, don't use it -- nobody is forcing you to
declare 'const' variables. 

-- 
Grant

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

#98398

On 07/11/2015 14:23, Marko Rauhamaa wrote:
> Bartc <bc@freeuk.com>:

> 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 Python and C is still pretty big!

-- 
Bartc

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

#98421

On Sun, 8 Nov 2015 01:23 am, Marko Rauhamaa wrote:

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

That is factually incorrect.

The motive behind the introduction of typing annotations is not "speed",
but "correctness". Guido has expressed skepticism that typing annotations
can be used to improve the speed of Python programs, and has suggested that
the future of optimization is JIT compilers like PyPy rather than static
compilers like Nuitka.

[Aside: I have to disagree with Guido's thoughts on compilers. Even if JIT
compilers are ultimately faster for long-running code, they don't help much
for short-running code, and surely there is a lot of low-hanging fruit that
an optimizing compiler can perform. Victor Skinner is experimenting with a
version of CPython which, among other things, detects when built-ins have
not been modified, and can inline them for speed.]

If type annotations lead to faster code, that's a bonus, but it isn't why
they are being added to the language. They are added to improve correctness
and documentation, to enable type-checks to be performed by linters and
compile-time type-checkers.


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

Yeah, but most of them suck. Why can't we have a fast programming language
that is as nice to use as Python? Why can't Python be fast?



> Python 
> should *not* sacrifice its dynamism (which the fast languages don't
> have) for speed. Python is already fast enough for most programming
> tasks.

Well, I don't know about anyone else, but I personally always want my
scripts and programs to run slower. I can't tell you how annoyed I was when
new-style classes became as fast or faster than old-style classes.

*wink*


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

I don't think so, but in any case, Bart is *way* oversimplifying the
potential optimizations available. Function inlining depends on the
function being small enough that inlining it does more good than harm, but
it doesn't require that f never changes.

Perhaps Laura can confirm this, but I understand that PyPy can inline
functions. Simplified:

The compiler builds a fast path and a slow path, and a guard. If the
function is the one you expect, the interpreter takes the fast path, which
includes the inlined function. But if the function has been rebound, the
guard triggers, and the interpreter takes the slow path, which follows the
slow, dynamic implementation. In pseudo-code:

def spam():
    result = eggs(x)

will compile as if it were written like this:

def spam():
    if eggs is EXPECTED_EGGS:
        # inline code
        do_this()
        do_that()
        result = another_thing(x)
    else:
        result = eggs(x)


The compiler manages all the book-keeping for you, automatically, and as
functions grow and shrink in complexity, it will automatically decide which
ones can be inlined and which cannot. You write the simplest, most obvious
code which is easy to maintain, and the compiler managers the ugly
optimizations.


> You would be right in that Python programs hardly ever make use of or
> directly depend on the degrees of freedom Python affords.

That's certainly true. Every Python program pays a significant speed penalty
(perhaps as much as 10 x slower than it need be) for features which are
used by probably less than 1% of code.

The choice is not between "dynamic language" and "fast language". You can
have both. Smalltalk proves it. Javascript proves it. You just need smarter
compilers which can optimize the usual, non-dynamic cases while still
allowing dynamic code to work.

We often say that the reason Python is anything up to a factor of 100 times
slower than languages like Java is because Python is so dynamic, but that's
not true. Python is so slow because *Python compilers aren't smart enough*.
CPython is a relatively simple reference implementation which applies
hardly any optimizations.

Even such simple things as constant folding are slightly controversial! If
you go back to older versions of Python, code like this:

    x = 1 + 1

actually performed the addition at runtime, instead of being compiled to:

    x = 2

Believe it or not, even something as simple as that remains controversial,
with some folks (including Guido) expressing doubt that constant-folding is
worthwhile.

But PyPy proves that Python compilers can be smarter, and optimize more,
without sacrificing dynamicism.


> 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 don't think that's a good analogy.

A better analogy is, imagine that Ford built a car that allowed you to swap
out the radio, the doors, the tyres, even the engine, while the car was
moving. You could unplug the engine while driving down the road, and plug
in a new one, and the car would just keep going. As a consequence, the car
is significantly bigger and slower than most other cars, and occasionally
it is useful (when you get a flat tyre, you don't have to stop, you just
swap into place a new tyre and keep going) but generally it's not used much
(who swaps out the seat that they are sitting on?).

Ford call this car "Python".


> I wouldn't like Python to turn into such a contraption.




-- 
Steven

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

#98431

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

> 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 annotation.)
>
> That is factually incorrect.
>
> The motive behind the introduction of typing annotations is not "speed",
> but "correctness".

Oh, then I'm even more disappointed with type annotation.


Marko

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

#98441

On Sun, 8 Nov 2015 08:44 pm, Marko Rauhamaa wrote:

> Steven D'Aprano <steve@pearwood.info>:
> 
>> 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 annotation.)
>>
>> That is factually incorrect.
>>
>> The motive behind the introduction of typing annotations is not "speed",
>> but "correctness".
> 
> Oh, then I'm even more disappointed with type annotation.


/me does a double-take


Wait a minute, you've just spent a bunch of paragraphs explaining that
Python is plenty fast enough (for you), that you don't need it to be
faster. Okay. Now you're saying that you're *even more* disappointed that
type annotations will be used to make code *more correct* and *less buggy*.

So... you have no need for Python to be fast, and even less need for Python
code to be correct...

Or perhaps you mean that you don't need help writing correct code, because
your code is perfect...

It is moments like this I wonder if you are trolling.


-- 
Steven

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

#98443

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

> 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 your code is perfect...

Python's noise-free syntax does more for code quality than compile-time
type checking.


Marko

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

#98440

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 the
> potential optimizations available. Function inlining depends on the
> function being small enough that inlining it does more good than harm, but
> it doesn't require that f never changes.

I didn't really have function in-lining in mind (although once you are 
sure a specific function will always be called, that is a possibility 
for the compiler).

There are plenty of optimisations available if you know you are calling 
a function, and the compiler can 'see' the source code:

* You don't need to check that 'f' in 'f(a,b,c)' is a function; it will be.

* You will know whether the number of arguments provided is correct or 
not, and make adjustments at compile-time if not

* Where keyword parameters are used, this can also all be sorted out at 
compile-time, rather than at runtime

* (And does Python still need to do a lookup for the name 'f'? I don't 
know; the CPython sources are hard to follow. But in my interpreters, 
this is never necessary at runtime.)

However, most functions will not be visible to the compiler because they 
are in imported modules. A certain amount of work can be done when a 
module is loaded, but this now starts to get complicated.

> Even such simple things as constant folding are slightly controversial! If
> you go back to older versions of Python, code like this:
>
>      x = 1 + 1
>
> actually performed the addition at runtime, instead of being compiled to:
>
>      x = 2
>
> Believe it or not, even something as simple as that remains controversial,

Actually, it's not so simple! If floating point expressions are 
involved, the results can be different between compiler and runtime, if 
the compilation is done on a separate machine. But this is only a 
problem is byte-code is distributed rather than sources.

-- 
BartC

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

#98529

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

I find that to be contradictory. Why should you make something difficult
if you are consenting adults? I also find it important that consenting
adults can choose in how far they can consent. This whole idea of python
assuming we are consenting adults and thus making it impossible to not
consent seems weird.

> Notably, the author of a library should not be forbidding the Pythonic
> ability to change name bindings as needed.

If the author of a library doesn't wish to consent to this I don't see
what is wrong with that.

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

I disagree. Maybe the author is willing to freely give support but only
on the condition that the user used the library as it was largely intended.
I see no more reason to allow math.pi to be rebound to another value as
to allow True, False or None to be rebound.

So why should we allow the language designers to forbid the latter but
library authors not the former?

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

#98562

Antoon Pardon <antoon.pardon@rece.vub.ac.be> 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
> if you are consenting adults?

It's no more contradictory than the fact Python makes it difficult for
consenting adults to exchange hard-to-follow code indentation. The
principle that There Should Be (Preferably Only) One Obvious Way To Do
It directly implies that other ways should be difficult. That's not a
contradiction with treating Python programmers as consenting adults.

> This whole idea of python assuming we are consenting adults and thus
> making it impossible to not consent seems weird.

You misunderstand the implication: I'm saying that because Python
assumes we are consenting adults, that such actions remain possible.

> > Notably, the author of a library should not be forbidding the Pythonic
> > ability to change name bindings as needed.
>
> If the author of a library doesn't wish to consent to this I don't see
> what is wrong with that.

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 user. Such a power is not granted by
Python.

Instead, the library author is obliged to treat the library user as an
adult who consents to the freedoms inherent to Python's design, and to
not restrict their use of the library needlessly.

-- 
 \     “Facts are stubborn things; and whatever may be our wishes, our |
  `\   inclinations, or the dictates of our passion, they cannot alter |
_o__)        the state of facts and evidence.” —John Adams, 1770-12-04 |
Ben Finney

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

#98582

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 user. Such a power is not granted by
> Python.

Python is not at liberty to grant or deny such a power. Python is just
a vehicle in which code is written. The author of a library can restrict
its use anyway he sees fit.

> Instead, the library author is obliged to treat the library user as an
> adult who consents to the freedoms inherent to Python's design, and to
> not restrict their use of the library needlessly.

There is no such obligation. And if it was an obligation, you can hardly
talk about consenting. Consenting adults mean that either party can
decide on conditions. Once one party is obligated it is no longer consenting.

-- 
Antoon Pardon

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

#98789

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* of the library
>> author to restrict the library user. Such a power is not granted by
>> Python.
> 
> Python is not at liberty to grant or deny such a power. Python is just
> a vehicle in which code is written. The author of a library can restrict
> its use anyway he sees fit.

No he cannot, outside the bounds of copyright law.  Why would you think
otherwise?  The only document that binds the end user in any way is the
copyright license, unless some other formal contract has been arranged.

>> Instead, the library author is obliged to treat the library user as an
>> adult who consents to the freedoms inherent to Python's design, and to
>> not restrict their use of the library needlessly.
> 
> There is no such obligation. And if it was an obligation, you can hardly
> talk about consenting. Consenting adults mean that either party can
> decide on conditions. Once one party is obligated it is no longer consenting.

You are correct there is no obligation, but nor does Python empower the
library developer.   He may attempt obfuscation or other means to
control the use of his library of course, but only copyright grants him
legal authority of any kind.

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

#98810

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? Instead, you seem to be trying to assert a *power* of the library
>>> author to restrict the library user. Such a power is not granted by
>>> Python.
>>
>> Python is not at liberty to grant or deny such a power. Python is just
>> a vehicle in which code is written. The author of a library can restrict
>> its use anyway he sees fit.
> 
> No he cannot, outside the bounds of copyright law.  Why would you think
> otherwise?  The only document that binds the end user in any way is the
> copyright license, unless some other formal contract has been arranged.

You haven't contradicted me in any way. What you are talking about here
is in what form those restrictions must be published. I am talking about
the restrictions the author can put in a license.

-- 
Antoon Pardon

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

#98377

Bartc wrote:
^^^^^
Please fix.

> On 06/11/2015 02:33, wangq@travelsky.com wrote:
>>      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.

“pi” is the name of an attribute of the module object referred to by “math”.
 
> (Perhaps math.pi would be better off as a function.)

Perhaps not.  Calling a function includes an overhead that one does not want 
in already costly floating-point calculations.

In my opinion, mathematical constants should be implemented as constants 
(non-overwritable, non-deletable, throwing exceptions when attempting to do 
either) but apparently the authors of math.py disagree.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#98381

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 would be better off as a function.)
>
> Perhaps not.  Calling a function includes an overhead that one does not want
> in already costly floating-point calculations.
>
> In my opinion, mathematical constants should be implemented as constants
> (non-overwritable, non-deletable, throwing exceptions when attempting to do
> either) but apparently the authors of math.py disagree.

One of multiple discussions of the 'constants' idea.
bugs.python.org/issue1465406
It is mostly about speed.

-- 
Terry Jan Reedy

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

#98383

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 stop
trying to enforce non-existent rules about internet identities on others.



-- 
Steven

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

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

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

csiph-web