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

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

Experiences/guidance on teaching Python as a first programming language

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

Contents

  Experiences/guidance on teaching Python as a first programming language Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-12-09 12:23 +0000
    Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-09 05:54 -0800
    Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-09 08:57 -0800
      Re: Experiences/guidance on teaching Python as a first programming language William Ray Wing <wrw@mac.com> - 2013-12-09 12:55 -0500
      Re: Experiences/guidance on teaching Python as a first programming language Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-10 18:25 +1300
        Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-10 16:55 +1100
          Re: Experiences/guidance on teaching Python as a first programming   language Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-11 10:38 +1300
        Re: Experiences/guidance on teaching Python as a first programming language Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-10 20:35 -0500
          Re: Experiences/guidance on teaching Python as a first programming language Denis McMahon <denismfmcmahon@gmail.com> - 2013-12-11 02:16 +0000
            Re: Experiences/guidance on teaching Python as a first programming language Larry Martell <larry.martell@gmail.com> - 2013-12-11 07:08 -0500
          Re: Experiences/guidance on teaching Python as a first programming language Grant Edwards <invalid@invalid.invalid> - 2013-12-11 15:05 +0000
          Re: Experiences/guidance on teaching Python as a first programming language Rick Johnson <rantingrickjohnson@gmail.com> - 2013-12-16 16:47 -0800
            Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-16 20:06 -0500
              Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 01:25 +0000
              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-17 12:27 +1100
              Re: Experiences/guidance on teaching Python as a first programming language Gene Heskett <gheskett@wdtv.com> - 2013-12-16 20:32 -0500
              Re: Experiences/guidance on teaching Python as a first programming language "Cousin Stanley" <cousinstanley@gmail.com> - 2013-12-17 07:32 -0700
                Re: Experiences/guidance on teaching Python as a first programming language Gene Heskett <gheskett@wdtv.com> - 2013-12-17 12:27 -0500
        Re: Experiences/guidance on teaching Python as a first programming language Neil Cerutti <neilc@norwich.edu> - 2013-12-11 15:46 +0000
    Re: Experiences/guidance on teaching Python as a first programming language "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2013-12-09 23:32 +0000
      Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-09 18:42 -0500
        Re: Experiences/guidance on teaching Python as a first programming language "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2013-12-10 00:00 +0000
        Re: Experiences/guidance on teaching Python as a first programming language Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-09 20:56 -0500
    Re: Experiences/guidance on teaching Python as a first programming language Wolfgang Keller <feliphil@gmx.net> - 2013-12-12 21:36 +0100
      Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-13 08:12 +1100
        Re: Experiences/guidance on teaching Python as a first programming language Wolfgang Keller <feliphil@gmx.net> - 2013-12-16 21:32 +0100
          Re: Experiences/guidance on teaching Python as a first programming language "Rhodri James" <rhodri@wildebst.org.uk> - 2013-12-16 23:01 +0000
          Re: Experiences/guidance on teaching Python as a first programming language Ned Batchelder <ned@nedbatchelder.com> - 2013-12-16 19:28 -0500
            Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-16 16:39 -0800
              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-17 11:44 +1100
                Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-16 17:58 -0800
              Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-17 02:33 +0000
                Re: Experiences/guidance on teaching Python as a first programming language Rick Johnson <rantingrickjohnson@gmail.com> - 2013-12-16 20:41 -0800
                Re: Experiences/guidance on teaching Python as a first programming language Neil Cerutti <neilc@norwich.edu> - 2013-12-17 14:51 +0000
                  Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-17 09:54 -0500
                    Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 15:07 +0000
                    Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-17 15:24 +0000
                      Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 15:35 +0000
                      Re: Experiences/guidance on teaching Python as a first programming language Larry Martell <larry.martell@gmail.com> - 2013-12-17 11:21 -0500
                        Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-17 08:56 -0800
                  Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-17 10:03 -0800
                    Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-18 05:20 +1100
                    Re: Experiences/guidance on teaching Python as a first programming language Joel Goldstick <joel.goldstick@gmail.com> - 2013-12-17 13:39 -0500
                  Re: Experiences/guidance on teaching Python as a first programming language dkcombs@panix.com (David Combs) - 2014-01-29 03:17 +0000
              Re: Experiences/guidance on teaching Python as a first programming language Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-12-17 11:12 +0000
                Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-17 12:18 +0000
                Re: Experiences/guidance on teaching Python as a first programming language Wolfgang Keller <feliphil@gmx.net> - 2013-12-17 16:51 +0100
                  Re: Experiences/guidance on teaching Python as a first programming language Grant Edwards <invalid@invalid.invalid> - 2013-12-17 16:59 +0000
                    Re: Experiences/guidance on teaching Python as a first programming language Larry Martell <larry.martell@gmail.com> - 2013-12-17 12:18 -0500
                    Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 17:24 +0000
                    Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-17 17:44 +0000
                      Re: Experiences/guidance on teaching Python as a first programming language Grant Edwards <invalid@invalid.invalid> - 2013-12-17 19:38 +0000
                    Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-17 19:39 -0500
                      Re: Experiences/guidance on teaching Python as a first programming language Grant Edwards <invalid@invalid.invalid> - 2013-12-18 18:05 +0000
                        Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-18 18:17 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-18 20:49 -0500
                            Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-19 02:05 +0000
                            Re: Experiences/guidance on teaching Python as a first programming language Wolfgang Keller <feliphil@gmx.net> - 2013-12-19 15:54 +0100
                        Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-18 20:40 -0500
                          Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-18 20:05 -0800
                            Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-18 23:16 -0500
                              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-19 15:26 +1100
                              Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-18 20:48 -0800
                                Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-19 09:14 -0800
                              Re: Experiences/guidance on teaching Python as a first programming language 88888 Dihedral <dihedral88888@gmail.com> - 2013-12-18 22:03 -0800
                          Re: Experiences/guidance on teaching Python as a first programming language Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-19 19:40 +1300
                    Re: Experiences/guidance on teaching Python as a first programming language Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-17 20:20 -0500
                  Re: Experiences/guidance on teaching Python as a first programming language Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-12-17 17:09 +0000
                  Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-17 19:32 -0500
                    Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve@pearwood.info> - 2013-12-18 01:33 +0000
                      Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-18 13:11 +1100
                        Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve@pearwood.info> - 2013-12-18 08:22 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-18 19:32 +1100
                          Re: Experiences/guidance on teaching Python as a first programming
 language Dave Angel <davea@davea.name> - 2013-12-18 07:53 -0500
                          Re: Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-19 01:55 +1100
                            Re: Re: Experiences/guidance on teaching Python as a first programming language "Rhodri James" <rhodri@wildebst.org.uk> - 2013-12-19 00:10 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Neil Cerutti <neilc@norwich.edu> - 2013-12-18 15:17 +0000
                          Re: Re: Experiences/guidance on teaching Python as a first
 programming language Dave Angel <davea@davea.name> - 2013-12-18 15:52 -0500
                            Re: Experiences/guidance on teaching Python as a first programming language Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-19 19:41 +1300
                              Re: Experiences/guidance on teaching Python as a first programming
 language Dave Angel <davea@davea.name> - 2013-12-19 07:06 -0500
                        Re: Experiences/guidance on teaching Python as a first programming language Grant Edwards <invalid@invalid.invalid> - 2013-12-18 18:00 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-18 18:07 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-18 20:56 -0500
                            Re: Experiences/guidance on teaching Python as a first programming language Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-19 18:39 +1300
                              Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-19 00:56 -0500
                      Re: Experiences/guidance on teaching Python as a first programming language Paul Smith <paul@mad-scientist.net> - 2013-12-17 22:49 -0500
                        Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve@pearwood.info> - 2013-12-18 08:18 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-18 19:51 +1100
                            Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-19 16:20 +0000
                              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-20 04:02 +1100
                          Re: Experiences/guidance on teaching Python as a first programming language Ethan Furman <ethan@stoneleaf.us> - 2013-12-18 07:23 -0800
                            Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-18 08:53 -0800
                              Re: Experiences/guidance on teaching Python as a first programming language Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-18 19:29 -0500
                            Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-19 16:20 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-18 17:15 +0000
                            Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-19 17:12 +0000
                              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-20 04:28 +1100
                              Re: Experiences/guidance on teaching Python as a first programming language Neil Cerutti <neilc@norwich.edu> - 2013-12-19 18:40 +0000
                              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-20 07:18 +1100
                              Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-19 19:38 -0500
                                Re: Experiences/guidance on teaching Python as a first programming language "Rhodri James" <rhodri@wildebst.org.uk> - 2013-12-20 00:45 +0000
                                Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-20 02:16 +0000
                                  Re: Experiences/guidance on teaching Python as a first programming language Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-12-20 18:58 -0500
                                  Re: Experiences/guidance on teaching Python as a first programming language Ned Batchelder <ned@nedbatchelder.com> - 2013-12-20 21:04 -0500
                                Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-27 14:35 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Terry Reedy <tjreedy@udel.edu> - 2013-12-18 17:33 -0500
                            Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-19 17:06 +0000
                              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-20 04:18 +1100
                          Re: Experiences/guidance on teaching Python as a first programming language Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-12-19 00:21 +0000
                      Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve@pearwood.info> - 2013-12-18 07:53 +0000
                    Re: Experiences/guidance on teaching Python as a first programming language Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-12-17 18:33 -0800
                    Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-18 14:01 +1100
                    Re: Experiences/guidance on teaching Python as a first programming language Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-12-17 19:12 -0800
                    Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-18 14:24 +1100
                  Re: Experiences/guidance on teaching Python as a first programming language "Rhodri James" <rhodri@wildebst.org.uk> - 2013-12-19 00:49 +0000
                    Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-19 11:54 +1100
                    Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-18 20:29 -0800
                      Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-19 04:50 +0000
                        Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-18 21:09 -0800
                          Re: Experiences/guidance on teaching Python as a first programming language Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-19 05:36 +0000
                        Re: Experiences/guidance on teaching Python as a first programming language Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-19 21:31 +0000
                          Re: Experiences/guidance on teaching Python as a first programming language Roy Smith <roy@panix.com> - 2013-12-19 19:30 -0500
                Re: Experiences/guidance on teaching Python as a first programming language rusi <rustompmody@gmail.com> - 2013-12-18 01:18 -0800
                  Re: Experiences/guidance on teaching Python as a first programming language Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-12-18 10:06 +0000
              Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-18 01:10 +1100
            Re: Experiences/guidance on teaching Python as a first programming language Wolfgang Keller <feliphil@gmx.net> - 2013-12-17 16:22 +0100
              Re: Experiences/guidance on teaching Python as a first programming language Wolfgang Keller <feliphil@gmx.net> - 2013-12-19 16:14 +0100
                Re: Experiences/guidance on teaching Python as a first programming   language Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-12-20 09:42 +1300
                  Re: Experiences/guidance on teaching Python as a first programming language Chris Angelico <rosuav@gmail.com> - 2013-12-20 07:51 +1100
          Re: Experiences/guidance on teaching Python as a first programming language dkcombs@panix.com (David Combs) - 2014-01-29 03:09 +0000

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

#62323

On 2013-12-18, Chris Angelico <rosuav@gmail.com> wrote:

> Well, okay. In C you can't have Foo.foo().

If "Foo" is a structure with a field named "foo" that is a pointer to
a function, then you can indeed "have" Foo.foo().

-- 
Grant Edwards               grant.b.edwards        Yow! It's OKAY -- I'm an
                                  at               INTELLECTUAL, too.
                              gmail.com            

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

#62326

On 18/12/2013 18:00, Grant Edwards wrote:
> On 2013-12-18, Chris Angelico <rosuav@gmail.com> wrote:
>
>> Well, okay. In C you can't have Foo.foo().
>
> If "Foo" is a structure with a field named "foo" that is a pointer to
> a function, then you can indeed "have" Foo.foo().
>

Complete fooey :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

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

#62356

In article <l8snr8$snu$1@reader1.panix.com>,
 Grant Edwards <invalid@invalid.invalid> wrote:

> On 2013-12-18, Chris Angelico <rosuav@gmail.com> wrote:
> 
> > Well, okay. In C you can't have Foo.foo().
> 
> If "Foo" is a structure with a field named "foo" that is a pointer to
> a function, then you can indeed "have" Foo.foo().

Sigh.  This has gone off in a direction I never intended.

What I meant was that in C++, when you write call a method by name, it 
can sometimes be difficult to know exactly what method is being called.  
Between inheritance, optional parameters, automatic type promotion, 
default constructors, and maybe a few other things I've forgotten, even 
if you've got all the signatures of foo() in front of you, it can 
sometimes be hard to figure out which one the compiler will pick.

And that sort of confusion never happens in C.

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

#62374

Roy Smith wrote:
> even 
> if you've got all the signatures of foo() in front of you, it can 
> sometimes be hard to figure out which one the compiler will pick.

And conversely, sometimes the compiler will have a hard
time figuring out which one you want it to pick!

I had an experience in Java recently where a library
author had provided two overloads of a function, that
at first sight could be disambiguated by argument types.
But for a certain combination of types it was
ambiguous, and I was unlucky enough to want to use that
particular combination, and the compiler insisted on
picking the wrong one. As far as I could see, it was
*impossible* to call the other overload with those
parameter types.

I ended up resorting to copying the whole function and
giving it another name, just so I could get it called.

-- 
Function overloading: Just say no.
Greg

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

#62375

In article <bhff4qF21fhU1@mid.individual.net>,
 Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote:

> Roy Smith wrote:
> > even 
> > if you've got all the signatures of foo() in front of you, it can 
> > sometimes be hard to figure out which one the compiler will pick.
> 
> And conversely, sometimes the compiler will have a hard
> time figuring out which one you want it to pick!
> 
> I had an experience in Java recently where a library
> author had provided two overloads of a function, that
> at first sight could be disambiguated by argument types.
> But for a certain combination of types it was
> ambiguous, and I was unlucky enough to want to use that
> particular combination, and the compiler insisted on
> picking the wrong one. As far as I could see, it was
> *impossible* to call the other overload with those
> parameter types.
> 
> I ended up resorting to copying the whole function and
> giving it another name, just so I could get it called.

BTDT.

We were doing a huge network management application.  There was an 
SNMP_Manager class, which had three or four different constructors, each 
one taking a dozen or more arguments, many of them optional.

I finally got fed up with eternally trying to figure out which 
constructor was being called and replaced them with a series of factory 
functions: construct_for_traps(), construct_for_polling(), etc.

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

#62268

On Wed, 2013-12-18 at 01:33 +0000, Steven D'Aprano wrote:
> And "What does 'implementation-specific undefined behaviour' actually 
> mean in practice?", another common question when dealing with C.

Only asked by people who haven't had it explained.  There's "undefined
behavior", and there's "implementation-specific behavior", but it is
impossible to have "implementation-specific undefined behavior".

And, the definitions are simple to understand: "undefined behavior"
means that if your program invokes it, there is no definition of what
will happen.  This is buggy code.

"Implementation-specific" behavior means that the standard requires the
implementation to do some well-defined thing, but the standard does not
define exactly what it must be.  You can go look up what your
implementation will do in its documentation (the standard requires that
it be documented), but you can't assume the same thing will happen in
another implementation.  This is non-portable code.

It's a very rare language indeed that has no undefined or
implementation-specific behaviors.  Python gets to "cheat" by having one
reference implementation.  Every time you've had to go try something out
in the Python interpreter because the documentation didn't provide the
details you needed, that WAS implementation-specific behavior.

> > You never have to wonder what the
> > lifetime of an object is, 
> 
> Since C isn't object oriented, the lifetime of objects in C is, um, any 
> number you like. "The lifetime of objects in <some language with no 
> objects> is ONE MILLION YEARS!!!" is as good as any other vacuously true 
> statement.

The implication that only an "object oriented" language could have a
concept of object lifetimes is false.  Another, less hyperbolic way of
saying this is that in C, the lifetime of objects is _exactly as long as
you specify_.  Heap objects come into existence when you explicitly
create them, and they go out of existence when you explicitly destroy
them.  If you don't destroy them, they never go away.  If you destroy
them more than once, that's undefined behavior.  Stack objects are even
simpler.

> > or be mystified by which of the 7 signatures
> > of Foo.foo() are going to get called, 
> 
> Is that even possible in C? If Foo is a struct, and Foo.foo a member, I 
> don't think C has first-class functions and so Foo.foo can't be callable.

Of course that's valid C.  It's true that C doesn't have first-class
functions, but it supports invoking functions through pointers and you
can store functions in data members, pass functions as arguments, and
return functions from other functions, so Foo.foo can certainly be
callable.

~$ cat /tmp/foo.c
#include <stdio.h>

struct Foo {
    void (*foo)();
};

void foobar(void) { printf("foobar\n"); }

int main()
{
    struct Foo Foo = { foobar };
    Foo.foo();
    return 0;
}

$ gcc -Wall -o /tmp/foo /tmp/foo.c

$ /tmp/foo
foobar

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

#62277

On Tue, 17 Dec 2013 22:49:43 -0500, Paul Smith wrote:

> On Wed, 2013-12-18 at 01:33 +0000, Steven D'Aprano wrote:
>> And "What does 'implementation-specific undefined behaviour' actually
>> mean in practice?", another common question when dealing with C.
> 
> Only asked by people who haven't had it explained.  There's "undefined
> behavior", and there's "implementation-specific behavior", but it is
> impossible to have "implementation-specific undefined behavior".

Of course it is possible. An implementation has to do *something*, even 
if it's not defined anywhere. Even if that "something" is crash, or emit 
no code, or display a compile-time error. I think you're making a 
distinction that doesn't apply to the plain-English meaning of the words 
I was using: the behaviour is undefined by the standard and specific to 
that implementation.


> And, the definitions are simple to understand: "undefined behavior"
> means that if your program invokes it, there is no definition of what
> will happen.  This is buggy code.

Yes, it is buggy code, but nevertheless it often works the way people 
expect it to work, and so through carelessness or ignorance programmers 
rely on it. If you've ever written i+1 without a guard for the case that 
i is INT_MAX, you're guilty of that too.

The C99 standard lists 191 different kinds of undefined behavior, 
including what happens when there is an unmatched ' or " on a line of 
source code.

You want to know why programs written in C are so often full of security 
holes? One reason is "undefined behaviour". The C language doesn't give a 
damn about writing *correct* code, it only cares about writing 
*efficient* code. Consequently, one little error, and does the compiler 
tell you that you've done something undefined? No, it turns your validator 
into a no-op -- silently:

http://code.google.com/p/nativeclient/issues/detail?id=245

No compile-time error, no run-time error, just blindingly fast and 
correct (according to the standard) code that does the wrong thing.


> "Implementation-specific" behavior means that the standard requires the
> implementation to do some well-defined thing, but the standard does not
> define exactly what it must be.  You can go look up what your
> implementation will do in its documentation (the standard requires that
> it be documented), but you can't assume the same thing will happen in
> another implementation.  This is non-portable code.

So much for the promise of C to be portable :-)


> It's a very rare language indeed that has no undefined or
> implementation-specific behaviors.

Java? Ada?

But indeed, most languages do have odd corners where odd things happen. 
Including Python, as you point out. But C has so many of them, and they 
affect *nearly everything*.

The aim of C is to write fast code, and if it happens to be correct, 
that's a bonus. C compilers will compromise on safety and correctness in 
order to be fast. Then end result is usually one of two outcomes:

- the programmer spends a lot of time and effort to manually guard 
against the undefined behaviour, thus slowing down the code;

- or he doesn't, and has bugs and security vulnerabilities in the code.


> Python gets to "cheat" by having one
> reference implementation.  Every time you've had to go try something out
> in the Python interpreter because the documentation didn't provide the
> details you needed, that WAS implementation-specific behavior.

The situation is quite different though. Python makes at least one 
implicit promise: nothing you write in pure Python can possibly cause a 
segfault. No buffer overflows for you!

We don't know what locals()['spam'] = 42 will do inside a function, but 
unlike the C case, we can reason about it:

- it may bind 42 to the name "spam";

- it may raise a runtime exception;

- it may even be a no-op;

But even if it is a no-op, the Python compiler doesn't have carte blanche 
to do anything it likes with the entire function, as a C compiler has. C 
has more indeterminacy than Python.



>> > You never have to wonder what the
>> > lifetime of an object is,
>> 
>> Since C isn't object oriented, the lifetime of objects in C is, um, any
>> number you like. "The lifetime of objects in <some language with no
>> objects> is ONE MILLION YEARS!!!" is as good as any other vacuously
>> true statement.
> 
> The implication that only an "object oriented" language could have a
> concept of object lifetimes is false.

Only object-oriented languages have *objects*. C does not have objects, 
it has values.

And yes, I'm being pedantic.


[...]
>> > or be mystified by which of the 7 signatures of Foo.foo() are going
>> > to get called,
>> 
>> Is that even possible in C? If Foo is a struct, and Foo.foo a member, I
>> don't think C has first-class functions and so Foo.foo can't be
>> callable.
> 
> Of course that's valid C.  It's true that C doesn't have first-class
> functions, but it supports invoking functions through pointers and you
> can store functions in data members, pass functions as arguments, and
> return functions from other functions, so Foo.foo can certainly be
> callable.

Okay, fair enough, that's why I prefixed my statement with a question.



-- 
Steven

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

#62282

On Wed, Dec 18, 2013 at 7:18 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> You want to know why programs written in C are so often full of security
> holes? One reason is "undefined behaviour". The C language doesn't give a
> damn about writing *correct* code, it only cares about writing
> *efficient* code. Consequently, one little error, and does the compiler
> tell you that you've done something undefined? No, it turns your validator
> into a no-op -- silently:

I disagree about undefined behaviour causing a large proportion of
security holes. Maybe it produces some, but it's more likely to
produce crashes or inoperative codde. The example you cite is a rare
one where it's actually security code; that's why it's a security
vulnerability. If the same operation were flagging, say, that this
value needed to be saved to disk, then the same bug would result in
stuff not getting saved on that platform, which isn't a security risk.

Here's something from CERN about C and security:
https://security.web.cern.ch/security/recommendations/en/codetools/c.shtml

Apart from the last one (file system atomicity, not a C issue at all),
every single issue on that page comes back to one thing: fixed-size
buffers and functions that treat a char pointer as if it were a
string. In fact, that one fundamental issue - the buffer overrun -
comes up directly when I search Google for 'most common security holes
in c code' (second hit, Wikipedia "Buffer overflow" page). Here's
another page listing security concerns:

http://www.makelinux.net/alp/085

First entry: Buffer overruns. Second: File system races. Third:
Improper quoting of shell commands.

Not one of the above pages, nor any other that I came across as I was
skimming, mentioned anything involving undefined behaviour. Every one
of them is issues with properly-defined behaviour - unless you count
specific details of memory layout. If you know that automatic
variables are stored on the stack, then you can blow some buffer and
overwrite the return value. But that's the *attacker* depending on
undefined behaviour, not the *programmer*, who simply has a bug in his
code (something that's able to write more to the buffer than there's
room for).

Python is actually *worse* than C in this respect. I know this
particular one is reasonably well known now, but how likely is it that
you'll still see code like this:

def create_file():
    f = open(".....", "w")
    f.write(".......")
    f.write(".......")
    f.write(".......")

Looks fine, is nice and simple, does exactly what it should. And in
(current versions of) CPython, this will close the file before the
function returns, so it'd be perfectly safe to then immediately read
from that file. But that's undefined behaviour. Python does not
guarantee that this will work, so this might work for years and then
break when it's run under Jython, or it might even work in Jython too,
but there's just one specific situation where the file's read
immediately after being written, and that one case fails. I think
that's used at least as often as any of C's pieces of undefined
behaviour.

ChrisA

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

#62403

On Wed, 18 Dec 2013 19:51:26 +1100, Chris Angelico wrote:

> On Wed, Dec 18, 2013 at 7:18 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> You want to know why programs written in C are so often full of
>> security holes? One reason is "undefined behaviour". The C language
>> doesn't give a damn about writing *correct* code, it only cares about
>> writing *efficient* code. Consequently, one little error, and does the
>> compiler tell you that you've done something undefined? No, it turns
>> your validator into a no-op -- silently:
> 
> I disagree about undefined behaviour causing a large proportion of
> security holes. 

I didn't actually specify "large proportion", that's your words. But 
since you mention crashes:

> Maybe it produces some, but it's more likely to produce
> crashes or inoperative codde. 

*Every* crash is a potential security hole. Not only is a denial of 
service, but a fatal exception[1] is a sign that arbitrary memory has 
been executed as if it were code, or an illegal instruction executed. 
Every such crash is a potential opportunity for an attacker to run 
arbitrary code. There are only two sorts of bugs: bugs with exploits, and 
bugs that haven't been exploited *yet*.

I think you are severely under-estimating the rule of undefined behaviour 
in C on security vulnerabilities. I quote from "Silent Elimination of 
Bounds Checks":

"Most of the security vulnerabilities described in my book, Secure Coding 
in C and C++, Second Edition, are the result of exploiting undefined 
behavior in code."

http://www.informit.com/articles/article.aspx?p=2086870

Undefined behaviour interferes with the ability of the programmer to 
understand causality with respect to his source code. That makes bugs of 
all sorts more likely, including buffer overflows.

Earlier this year, four researchers at MIT analysed how undefined 
behaviour is effecting software, and they found that C compilers are 
becoming increasingly aggressive at optimizing such code, resulting in 
more bugs and vulnerabilities. They found 32 previously unknown bugs in 
the Linux kernel, 9 in Postgres and 5 in Python.

http://www.itworld.com/security/380406/how-your-compiler-may-be-compromising-application-security


I believe that the sheer number of buffer overflows in C is more due to 
the language semantics than the (lack of) skill of the programmers. C the 
language pushes responsibility for safety onto the developer. Even expert 
C programmers cannot always tell what their own code will do. Why else do 
you think there are so many applications for checking C code for buffer 
overflows, memory leaks, buggy code, and so forth? Because even expert C 
programmers cannot detect these things without help, and they don't get 
that help from the language or the compiler.

[...]
> Apart from the last one (file system atomicity, not a C issue at all),
> every single issue on that page comes back to one thing: fixed-size
> buffers and functions that treat a char pointer as if it were a string.
> In fact, that one fundamental issue - the buffer overrun - comes up
> directly when I search Google for 'most common security holes in c code'

I think that you have missed the point that buffer overflows are often a 
direct consequence of the language. For example:

http://www.kb.cert.org/vuls/id/162289

Quote:

"Some C compilers optimize away pointer arithmetic overflow tests that 
depend on undefined behavior without providing a diagnostic (a warning). 
Applications containing these tests may be vulnerable to buffer overflows 
if compiled with these compilers."

The truly frightening thing about this is that even if the programmer 
tries to write safe code that checks the buffer length, the C compiler is 
*allowed to silently optimize that check away*.


> Python is actually *worse* than C in this respect.

You've got to be joking.


> I know this
> particular one is reasonably well known now, but how likely is it that
> you'll still see code like this:
> 
> def create_file():
>     f = open(".....", "w")
>     f.write(".......")
>     f.write(".......")
>     f.write(".......")
> 
> Looks fine, is nice and simple, does exactly what it should. And in
> (current versions of) CPython, this will close the file before the
> function returns, so it'd be perfectly safe to then immediately read
> from that file. But that's undefined behaviour. 

No it isn't. I got chastised for (allegedly) conflating undefined and 
implementation-specific behaviour. In this case, whether the file is 
closed or not is clearly implementation-specific behaviour, not 
undefined. An implementation is permitted to delay closing the file. It's 
not permitted to erase your hard drive.

Python doesn't have an ISO standard like C, so where the documentation 
doesn't define the semantics of something, CPython behaves as the 
reference implementation. CPython allows you to simultaneously open the 
same file for reading and writing, in which case subsequent reads and 
writes will deterministically depend on the precise timing of when writes 
are written to disk. That's not something which the language can control, 
given the expected semantics of file I/O. The behaviour is defined, but 
it's defined in such a way that what you'll get is deterministic but 
unpredictable -- a bit like dict order, or pseudo-random numbers.

A Python implementation is not permitted to optimize away subsequent 
reads, erase your hard drive, or download a copy of Wikipedia from the 
Internet. A C compiler is permitted to do any of these.

(Of course, no competent C compiler would actually download all of 
Wikipedia, since that would be slow. Instead, they would probably only 
download the HTTP headers for the main page.)




[1] I'm talking low level exceptions or errors, not Python exceptions.


-- 
Steven

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

#62406

On Fri, Dec 20, 2013 at 3:20 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Wed, 18 Dec 2013 19:51:26 +1100, Chris Angelico wrote:
>
>> On Wed, Dec 18, 2013 at 7:18 PM, Steven D'Aprano <steve@pearwood.info>
>> wrote:
>>> You want to know why programs written in C are so often full of
>>> security holes? One reason is "undefined behaviour". The C language
>>> doesn't give a damn about writing *correct* code, it only cares about
>>> writing *efficient* code. Consequently, one little error, and does the
>>> compiler tell you that you've done something undefined? No, it turns
>>> your validator into a no-op -- silently:
>>
>> I disagree about undefined behaviour causing a large proportion of
>> security holes.
>
> I didn't actually specify "large proportion", that's your words. But
> since you mention crashes:

You implied that it's a significant cause of security holes. I counter
by saying that most security holes come from well-defined behaviour.

> I think you are severely under-estimating the rule of undefined behaviour
> in C on security vulnerabilities. I quote from "Silent Elimination of
> Bounds Checks":
>
> "Most of the security vulnerabilities described in my book, Secure Coding
> in C and C++, Second Edition, are the result of exploiting undefined
> behavior in code."
>
> http://www.informit.com/articles/article.aspx?p=2086870

I don't intend to buy the book to find out what he's talking about.
All I know is that the one single most common cause of problems in C,
the buffer overrun, is NOT "exploiting undefined behavior", an nor are
several other common problems (as described in my previous message).

> Earlier this year, four researchers at MIT analysed how undefined
> behaviour is effecting software, and they found that C compilers are
> becoming increasingly aggressive at optimizing such code, resulting in
> more bugs and vulnerabilities. They found 32 previously unknown bugs in
> the Linux kernel, 9 in Postgres and 5 in Python.
>
> http://www.itworld.com/security/380406/how-your-compiler-may-be-compromising-application-security

Yes, those are issues. Not nearly as large as the ones that _don't_
involve your compiler hurting you, except that CPython had proper
memory-usage discipline and didn't have the more glaring bugs.

> I believe that the sheer number of buffer overflows in C is more due to
> the language semantics than the (lack of) skill of the programmers. C the
> language pushes responsibility for safety onto the developer. Even expert
> C programmers cannot always tell what their own code will do. Why else do
> you think there are so many applications for checking C code for buffer
> overflows, memory leaks, buggy code, and so forth? Because even expert C
> programmers cannot detect these things without help, and they don't get
> that help from the language or the compiler.

I agree. The lack of a native string type is fundamental to probably
99% of C program bugs. (Maybe I'm exaggerating, but I reckon it'll be
ball-park.) But at no point do these programs or programmers *exploit*
undefined behaviour. They might run into it when things go wrong, but
by that time, things have already gone wrong. Example:

int foo()
{
    char buffer[80];
    gets(buffer);
    return buffer[0]=='A';
}

So long as the user enters no more than 79 characters, this function's
perfectly well defined. It's vulnerable because user input can trigger
a problem, but if anyone consciously exploits compiler-specific memory
layouts, it's the attacker, and *NOT* the original code. On the flip
side, this code actually does depend on undefined behaviour:

int bar()
{
    char buffer[5];
    char tmp;
    memset(buffer,0,6);
    return tmp;
}

This code is always going to go past its buffer, and if 'tmp' happens
to be the next thing in memory, it'll be happily zeroed. I'm pretty
sure I saw code like this on thedailywtf.com a while back.

>> Python is actually *worse* than C in this respect.
>
> You've got to be joking.

Trolling, more than joking, but as usual, there is a grain of truth in
what I say.

>> I know this
>> particular one is reasonably well known now, but how likely is it that
>> you'll still see code like this:
>>
>> def create_file():
>>     f = open(".....", "w")
>>     f.write(".......")
>>     f.write(".......")
>>     f.write(".......")
>>
>> Looks fine, is nice and simple, does exactly what it should. And in
>> (current versions of) CPython, this will close the file before the
>> function returns, so it'd be perfectly safe to then immediately read
>> from that file. But that's undefined behaviour.
>
> No it isn't. I got chastised for (allegedly) conflating undefined and
> implementation-specific behaviour. In this case, whether the file is
> closed or not is clearly implementation-specific behaviour, not
> undefined. An implementation is permitted to delay closing the file. It's
> not permitted to erase your hard drive.

The problem is that delaying closing the file is a potentially major
issue, if the file is about to be reopened. And it _is_ undefined
behaviour that one particular Python implementation handles in a very
simple and convenient way (and, what's more, in a way that matches how
other languages (eg C++, Pike) would handle it, so it's going to "feel
right" to people); it's actually very easy to depend on this without
realizing it.

> Python doesn't have an ISO standard like C, so where the documentation
> doesn't define the semantics of something, CPython behaves as the
> reference implementation. CPython allows you to simultaneously open the
> same file for reading and writing, in which case subsequent reads and
> writes will deterministically depend on the precise timing of when writes
> are written to disk.

Errr, Python does have its standard. It's not an
implementation-defined language. Yes, there are places where CPython
is the de facto standard, but that doesn't mean something's not
undefined.

Delaying the close might be completely insignificant, but it has the
potential to be critical (depending on the exact share modes and
such). And, in the strictest sense of the word, it *is* undefined, and
it *is* depended on.

ChrisA

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

#62311

On 12/18/2013 12:18 AM, Steven D'Aprano wrote:
> On Tue, 17 Dec 2013 22:49:43 -0500, Paul Smith wrote:
>> On Wed, 2013-12-18 at 01:33 +0000, Steven D'Aprano wrote:
>>> On 12/17/2013 04:32 PM, Roy Smith wrote:
>>>>
>>>> You never have to wonder what the
>>>> lifetime of an object is,
>>>
>>> Since C isn't object oriented, the lifetime of objects in C is, um, any
>>> number you like. "The lifetime of objects in <some language with no
>>> objects> is ONE MILLION YEARS!!!" is as good as any other vacuously
>>> true statement.
>>
>> The implication that only an "object oriented" language could have a
>> concept of object lifetimes is false.
>
> Only object-oriented languages have *objects*. C does not have objects,
> it has values.

The word 'object' has many more meanings than the one implied by Object Oriented Programming, as you well know.

> And yes, I'm being pedantic.

No, you're being an ass.

--
~Ethan~

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

#62316

On Wednesday, December 18, 2013 8:53:54 PM UTC+5:30, Ethan Furman wrote:
> On 12/18/2013 12:18 AM, Steven D'Aprano wrote:
> > On Tue, 17 Dec 2013 22:49:43 -0500, Paul Smith wrote:
> >> On Wed, 2013-12-18 at 01:33 +0000, Steven D'Aprano wrote:
> >>> On 12/17/2013 04:32 PM, Roy Smith wrote:
> >>>> You never have to wonder what the
> >>>> lifetime of an object is,
> >>> Since C isn't object oriented, the lifetime of objects in C is, um, any
> >>> number you like. "The lifetime of objects in <some language with no
> >>> objects> is ONE MILLION YEARS!!!" is as good as any other vacuously
> >>> true statement.
> >> The implication that only an "object oriented" language could have a
> >> concept of object lifetimes is false.
> > Only object-oriented languages have *objects*. C does not have objects,
> > it has values.

> The word 'object' has many more meanings than the one implied by Object Oriented Programming, as you well know.

> > And yes, I'm being pedantic.

> No, you're being an ass.

Is this discussion REALLY happening...???  In a non-programmer/layman forum it
would be completely normal

However given that we are supposedly a programmer list I am incredulous

Here is some innocuous looking python code:

A>

def draw_helper(canvas, level, p1, p2, p3):
    if level == 1:
        canvas.create_polygon(p1, p2, p3)
    else:
        p4 = midpoint(p1, p2)
        p5 = midpoint(p2, p3)
        p6 = midpoint(p1, p3)
        draw_helper(canvas, level - 1, p1, p4, p6)
        draw_helper(canvas, level - 1, p4, p2, p5)
        draw_helper(canvas, level - 1, p6, p5, p3)


And here is what happens when you run it

B>

http://homes.cs.washington.edu/~reges/python/sierpinski8.png
(More here http://homes.cs.washington.edu/~reges/python/)

Can you really say that what you see in B you can infer from A
WITHOUT RUNNING IT??

The above is the subject that is technically called 'complexity' in
math terms. If we allow the term 'complex' to be more general (like
the argument about 'object') then this becomes the pain and beauty,
the mystery and horror of programming -- seemingly trivial code when
seen as a PROGRAM can endlessly evolve into unimaginable complexity
when elaborated into a PROCESS.

So when Chris/Roy are talking of the simplicity of C's lifetime rules they
are talking of the primitive building blocks to make and understand
program-texts.

And when Steven/Devin are talking of the complexity of the same they are
talking of the arcane results that emerge when those programs run.

And from here its a small step to understand why python's slightly
more complicated semantics result in so much less complexity than
C's seemingly simple rules: C has a double complexity generator --
stack + heap vs python only having a 'managed' heap.

Analogously if the Sierpinsky triangle above were flattened into 1-d
there would be nothing to note about it.

Like python: Boring 'weenie' language... Never segfaults

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

#62349

On Wed, 18 Dec 2013 08:53:05 -0800 (PST), rusi <rustompmody@gmail.com>
declaimed the following:

>
>Is this discussion REALLY happening...???  In a non-programmer/layman forum it
>would be completely normal
>
>However given that we are supposedly a programmer list I am incredulous
>
>Here is some innocuous looking python code:
>
>A>
>
>def draw_helper(canvas, level, p1, p2, p3):
>    if level == 1:
>        canvas.create_polygon(p1, p2, p3)
>    else:
>        p4 = midpoint(p1, p2)
>        p5 = midpoint(p2, p3)
>        p6 = midpoint(p1, p3)
>        draw_helper(canvas, level - 1, p1, p4, p6)
>        draw_helper(canvas, level - 1, p4, p2, p5)
>        draw_helper(canvas, level - 1, p6, p5, p3)
>
>
>And here is what happens when you run it
>
>B>
>
>http://homes.cs.washington.edu/~reges/python/sierpinski8.png
>(More here http://homes.cs.washington.edu/~reges/python/)
>
>Can you really say that what you see in B you can infer from A
>WITHOUT RUNNING IT??
>

	That the code recursively draws a triangle made of smaller triangles...
Yes, I could figure that out from the code without running it (nor even
noticing the particular file name of the image linked).
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#62404

On Wed, 18 Dec 2013 07:23:54 -0800, Ethan Furman wrote:

> On 12/18/2013 12:18 AM, Steven D'Aprano wrote:

>> And yes, I'm being pedantic.
> 
> No, you're being an ass.

My my, it doesn't take much of a challenge to the Holy Church Of C to 
bring out the personal attacks.


-- 
Steven

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

#62318

On 18/12/2013 08:18, Steven D'Aprano wrote:
>
> The C99 standard lists 191 different kinds of undefined behavior,
> including what happens when there is an unmatched ' or " on a line of
> source code.
>
> No compile-time error, no run-time error, just blindingly fast and
> correct (according to the standard) code that does the wrong thing.
>

Plenty of compile-time warnings depending on the compiler, which the 
CPython core devs take a great deal of trouble to eliminate on every 
buildbot.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

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

#62408

On Wed, 18 Dec 2013 17:15:30 +0000, Mark Lawrence wrote:

> On 18/12/2013 08:18, Steven D'Aprano wrote:
>>
>> The C99 standard lists 191 different kinds of undefined behavior,
>> including what happens when there is an unmatched ' or " on a line of
>> source code.
>>
>> No compile-time error, no run-time error, just blindingly fast and
>> correct (according to the standard) code that does the wrong thing.
>>
>>
> Plenty of compile-time warnings depending on the compiler, which the
> CPython core devs take a great deal of trouble to eliminate on every
> buildbot.

Correct. The *great deal of trouble* part is important. Things which are 
the responsibility of the language and compiler in (say) Java, D, Rust, 
Go, etc. are the responsibility of the programmer with C.

I mention these languages as they are all intended to be safer languages 
than C while still being efficient. Whether they succeed or not is 
another question.

Now, I wish to be absolutely clear. There are certain programming areas 
where squeezing out every last iota of performance is important, and to 
do so may require making some compromises on correctness or safety. I 
find the C standard's position on undefined behaviour to be 
irresponsible, but, hey, maybe it is justified on the basis that C is a 
systems language intended for use in writing performance-critical 
operating system kernels, device drivers and similar. It's fine for 
Python to promise that nothing you do will ever cause a segfault, but for 
a language used to write kernels and device drivers, you probably want 
something more powerful and less constrained.

But why is so much non-performance critical code written in C? Why so 
many user-space applications? History has shown us that the decision to 
prefer efficiency-by-default rather than correctness-by-default has been 
a disaster for software safety and security. C language practically is 
the embodiment of premature optimization: the language allows compilers 
to silently throw your code away in order to generate efficient code by 
default, whether you need it or not.


-- 
Steven

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

#62411

On Fri, Dec 20, 2013 at 4:12 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> But why is so much non-performance critical code written in C? Why so
> many user-space applications?

Very good question! I don't have an answer. There are a few
"maybe-answers", but they mostly come down to "programmer didn't know
of a viable alternative". When I wrote RosMud, I wrote it in C++,
because I was making tweaks to an existing C++ program (Gmud) and
because I thought that that was the way to make it run fast enough for
what I needed. Seven years on (or will be, come January), I've learned
how much can be done in Python, Pike, and other high level languages,
and RosMud's successor is not written in C.

Maybe part of the answer comes from people who've learned based on old
hardware. Growing up in the 80s on an Epson XT-clone, I wrote code in
BASIC, C, and assembly. Now, most of my performance problems in BASIC
were because of flawed algorithms (it's amazing how slowly an O(n*n)
algorithm will run, isn't it!), but I could imagine someone growing up
learning "C is the only way to make code run fast" and then going on
to teach the next generation of programmers to use C, without
necessarily even explaining why.

But that's just speculation. All I know is, even if you do need to
write in C for some reason (your preferred language doesn't have
bindings for some library, maybe), chances are you can write the
tiniest bit of code that way, and do the rest in a high level
language.

ChrisA

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

#62412

On 2013-12-19, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, Dec 20, 2013 at 4:12 AM, Steven D'Aprano
><steve+comp.lang.python@pearwood.info> wrote:
>> But why is so much non-performance critical code written in C?
>> Why so many user-space applications?
>
> Very good question! I don't have an answer. There are a few
> "maybe-answers", but they mostly come down to "programmer
> didn't know of a viable alternative".

I believe it was Andrew Plotkin (glk, Glulxe, lots of other
stuff) who said that writing good C requires something like
brain-damage. Once you have acquired the brain-damage, writing C
code is no problem; in fact, it feels darn good.

And another thing: How many other languages have their very own
calling convention?

-- 
Neil Cerutti

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

#62414

On Fri, Dec 20, 2013 at 5:40 AM, Neil Cerutti <neilc@norwich.edu> wrote:
> And another thing: How many other languages have their very own
> calling convention?

Pascal does (sometimes called the Win32 convention).

ChrisA

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

#62421

In article <52b328f7$0$6512$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> Correct. The *great deal of trouble* part is important. Things which are 
> the responsibility of the language and compiler in (say) Java, D, Rust, 
> Go, etc. are the responsibility of the programmer with C.

Does anybody ever use D?  I looked at it a few years ago.  It seemed 
like a very good concept.  Sort of C++, with the worst of the crap torn 
out.  If nothing else, with the preprocessor torn out :-)

Did it ever go anywhere?

> Now, I wish to be absolutely clear. There are certain programming areas 
> where squeezing out every last iota of performance is important, and to 
> do so may require making some compromises on correctness or safety. I 
> find the C standard's position on undefined behaviour to be 
> irresponsible, but, hey, maybe it is justified on the basis that C is a 
> systems language intended for use in writing performance-critical 
> operating system kernels, device drivers and similar. It's fine for 
> Python to promise that nothing you do will ever cause a segfault, but for 
> a language used to write kernels and device drivers, you probably want 
> something more powerful and less constrained.

I disagree entirely (but respectfully).  If you want to get down to the 
hardware where you can fiddle bits, you want as little getting between 
you and the silicon as possible.  Every time you add a safety feature, 
you put another layer of *stuff* between you and the machine.

That's not to say it's the right language to be writing applications.

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

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

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

csiph-web