Python Success stories

[AlFire]

Now that you mention it, Python was also used in the Star Wars:
Knights of the Old Republic (KotOR) saga. You can even search the
scripts across the disc and take a look at hilarious code comments
like "this works but I don't know why"

and Shrek 3 http://www.linuxjournal.com/article/9653

 

[AlFire]

Now that you mention it, Python was also used in the Star Wars:
Knights of the Old Republic (KotOR) saga. You can even search the
scripts across the disc and take a look at hilarious code comments
like "this works but I don't know why"

and Shrek 3 http://www.linuxjournal.com/article/9653

 

[Istvan Albert]

x = x++;

has unspecified behaviour in C. That is, it is not specified
whether the value of x after execution of the statement is the
old value of x or one plus the old value of x.

unspecified means that the result could be anything: old value, old
value+1, -2993882, "trallalla", core dump, stack overflow etc...

in Java the behavior is specified, but many might find the result
counterintuitive:

int x = 0;
x = x++;
System.out.println(x);

prints 0, if I recall it correctly the ++ mutates after the assignment
takes place, therefore it increments the old value that then summarily
discarded.

i.

 

[Gabriel Genellina]

I think Gabriel meant "variables as boxes" - the classic description
of variables in "old school" programming languages, which is in
contrast to the "variables as labels" model used by Python.

Yes, I used the wrong expression here. Paul is right, I was thinking of
"variables" as a "box" with a label written on it, and a value inside.
That model is not valid in Python.

 

[Bob Woodham]

what about C++

To the extent that (historically) C++ was a superset of C, it was true of C++
as well. However, I haven't kept pace with the C++ standardization process.
C++ now has its own ANSI standard and I don't know what, if anything, the C++
standard has to say on this issue. Maybe a C++ guru can comment.

 

[Bob Woodham]

unspecified means that the result could be anything: old value, old
value+1, -2993882, "trallalla", core dump, stack overflow etc...

One would certainly hope there are only two possible results, the old value of
x or the incremented value of x.

I first encountered this issue with a C compiler that produced one of those
two results differently depending on the level of optimization requested.
(Ultimately, it boiled down to the issue of whether the compiler allocated x
to a register or as a standard memory reference). Rather than it being a bug,
I was surprised to discover that the C compiler had not, in fact, violated the
ANSI C standard.

Note that x can be a pointer of arbitrary type. Thus, it is not beyond the
realm of possibilty that a result different from what the programmer expected
might indeed produce, in the end, -2993882, "trallalla", core dump, stack
overflow etc...

I don't have a copy of the ISO/ANSI C spec at hand. Harbison and Steele, Jr.,
"C a Reference Manual (4th ed)," section 7.12.1, page 228, state, "In ISO C,
if a single object is modified more than once between successive sequence
points, the result is undefined." Assuming Harbison and Steele quote the 1990
spec correctly, the word I should have used is "undefined." Can you live with
that?

Aside: Yes, the issue is that x = x++; modifies the single object x more than
once between successive sequence points.

 

[Aahz]

Which big aplications are written in python.

YouTube

 

[Fuzzyman]

Hy guys,
A friend of mine i a proud PERL developer which always keeps making
jokes on python's cost.

Please give me any arguments to cut him down about his commnets
like :"keep programing i python. maybe, one day, you will be able to
program in VisualBasic"

This hurts. Please give me informations about realy famous
aplications.

`
Resolver One - a spreadsheet development environment for creating
business applications (aimed particularly at the financial services
industry) is written in IronPython.

There are around 30 000 lines of Python in the production code and
about 120 000 lines of Python code in the test framework.

Here is a quote from "Credit Cooperatif", a large French bank who are
now using Resolver One:

We use Excel and VBA, but we prefer Python for its combination of
simplicity and power. We were looking to better link spreadsheets with
Python programming, and Resolver One seemed to be the most elegant
solution because it was based on Python but also gave us compatibility
with our IT team’s architectural choice of Microsoft .NET.

Resolver One (Windows only but free to try and for non-commercial
use): http://www.resolversystems.com/

Michael Foord
http://www.ironpythoninaction.com/

 

[George Sakkis]

There are around 30 000 lines of Python in the production code and
about 120 000 lines of Python code in the test framework.

A rather off-topic and perhaps naive question, but isn't a 1:4
production/test ratio a bit too much ? Is there a guesstimate of what
percentage of this test code tests for things that you would get for
free in a statically typed language ? I'm just curious whether this
argument against dynamic typing - that you end up doing the job of a
static compiler in test code - holds in practice.

George

 

[cokofreedom]

A rather off-topic and perhaps naive question, but isn't a 1:4
production/test ratio a bit too much ? Is there a guesstimate of what
percentage of this test code tests for things that you would get for
free in a statically typed language ? I'm just curious whether this
argument against dynamic typing - that you end up doing the job of a
static compiler in test code - holds in practice.

George

To me it seems like more of an argument for a (more) concise Test
Framework for Python, or at least a fully fledge IDE beyond pyDev.

 

[MRAB]

To me it seems like more of an argument for a (more) concise Test
Framework for Python, or at least a fully fledge IDE beyond pyDev.

You could just as easily argue that it shows the power of Python:
something that contains so much functionality that it requires 120 000
lines to test completely needs only 30 000 lines to implement!

 

[greg]

I suspect that, although some of the things caught
by the tests would be caught by static typing, the
very *same* tests are also catching a lot of things
that wouldn't be caught by static typing.

Also, I don't think it's valid to equate the size of
the tests with the amount of effort it took to develop
them. For instance, the test suite for Pyrex is currently
larger than the Pyrex compiler, but I've still spent
far more time and effort developing the compiler than
writing the tests.

 

[Bruno Desthuilliers]

Ben Finney a écrit :

Right. The unit test suite should tend to increase: add tests far more
often than removing them. The application code, though, should tend to
grow less rapidly:

or even sometimes, at some point, start to shrink, thanks to: