By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,857 Members | 1,768 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,857 IT Pros & Developers. It's quick & easy.

Python Success stories

P: n/a
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.
Jun 27 '08 #1
Share this Question
Share on Google+
45 Replies


P: n/a
azrael schrieb:
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.
This isn't worth too much, but nontheless:

http://www.tiobe.com/index.php/conte...pci/index.html

Klick on Perl & Python respectively to see who's going to need to use
something else some day.

But the real problem is not your friend - it's you. He hurts you because
you let him. Stop getting mad about that he teases you.

Diez
Jun 27 '08 #2

P: n/a
azrael wrote:
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.
He's joking. Perl is a dysfunctional language and its users need a
strong sense of humor to go on, day after day.

Jun 27 '08 #3

P: n/a
azrael skrev:
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"
When I started writing in Python in the nineties there was a lot of
tech-media coverage of Perl. Python was always mentioned as a rival to
Perl in those articles.

These days Python is mentioned in a lot of tech-articles. Perl is never
mentioned as a rival in those articles. Other languages like Ruby are.
Ok I am Python biased, but I don't see anything happen on the Perl front
anymore. It has simply gone quiet.
--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science

Jun 27 '08 #4

P: n/a
azrael a écrit :
Hy guys,
A friend of mine i a proud PERL developer which always keeps making
jokes on python's cost.
s/proud/stupid/
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.
Don't let cretins hurt you. One of my best friends who is a die-hard
Perl addict really loves Python too, and finds this kind of pissing
contests more than stupid.
Jun 27 '08 #5

P: n/a
On Apr 22, 6:34*am, "Diez B. Roggisch" <de...@nospam.web.dewrote:
azrael schrieb:
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.

This isn't worth too much, but nontheless:

http://www.tiobe.com/index.php/conte...pci/index.html

Klick on Perl & Python respectively to see who's going to need to use
something else some day.
One more limited worth datapoint:

http://www.google.com/trends?q=pytho...ramming&ctab=0
Jun 27 '08 #6

P: n/a
On Apr 22, 6:25 am, azrael <jura.gro...@gmail.comwrote:
A friend of mine i a proud PERL developer which always keeps making
jokes on python's cost.
This hurts. Please give me informations about realy famous
aplications.
you could show him what Master Yoda said when he compared Python to
Perl

http://www.personal.psu.edu/iua1/pythonvsperl.htm

i.
Jun 27 '08 #7

P: n/a
Which big aplications are written in python. I see its development,

There are no big applications written in Python.

Big applications are written in JAVA or COBOL or C# or other legacy
programming systems.

If you programm in Python, your applications become quite small. Only
frameworks in Python are big.

best wishes

Harald
Join us @ EuroPython 2008 in Vilnius to have more fun with Python
Submit your talk NOW
www.europython.org
Jun 27 '08 #8

P: n/a
En Tue, 22 Apr 2008 07:34:48 -0300, Diez B. Roggisch <de***@nospam.web.deescribió:
azrael schrieb:
>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.

This isn't worth too much, but nontheless:

http://www.tiobe.com/index.php/conte...pci/index.html
Also, you can enter the Python main site, on the right and very prominently you have a link to many successful stories: http://www.python.org/about/success/
But the real problem is not your friend - it's you. He hurts you because
you let him. Stop getting mad about that he teases you.
I agree.

--
Gabriel Genellina

Jun 27 '08 #9

P: n/a
On Tue, 22 Apr 2008 08:35:47 -0700 (PDT)
GHUM <ha**************@gmail.comwrote:
Which big aplications are written in python. I see its development,

There are no big applications written in Python.

Big applications are written in JAVA or COBOL or C# or other legacy
programming systems.

If you programm in Python, your applications become quite small. Only
frameworks in Python are big.
So the fact that there are no big applications written in Python IS the
success story.

--
D'Arcy J.M. Cain <da***@druid.net | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
Jun 27 '08 #10

P: n/a
On Apr 22, 5:25*am, azrael <jura.gro...@gmail.comwrote:
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.
Those would be insulting statements, but only if he wouldn't be a Perl
programmer. Everyone knows Perl's best days are long gone. Perl is not
a competent language anymore. I bet your friend is a system
administrator or something like that, because the only use for Perl is
writing quick-and-dirty scripts, and that's something that sysadmins
do the whole day.

Anyway, seeing that nobody has posted on the "big applications"
matter, here are some examples: Zope ( http://www.zope.org ), Medusa
( http://www.nightmare.com/medusa ), Grail ( http://grail.sourceforge.net
).

On the "Python vs. Perl" matter, well, just search "Python Perl" on
Google or some other search engine, you'll literally find nothing but
pages talking about how Python is better than Perl.

On the other hand, I do admit that there's no other language better
than Perl to write a 3-10 line long program. In those cases, the Perl
version will not only be smaller than the C version, but even smaller
than the Python version. This is mostly due to Perls default variables
and "magic" events (like reading a line of a file directly into $_
when you're doing while (<FILE>) {...}, or automatically converting
between integer/string or scalar/list depending on the operators and
context ).

But a competent developer won't be writing such small scripts, unless,
as I said, you're a sysadmin or something like that. Otherwise,
there's no reason to use something as ugly and unconventional as Perl.
Jun 27 '08 #11

P: n/a
Sure. Python is more readable than Perl, though I have found Python
to have a weird behavior regarding this little issue :

How can you explain that Python doesn't support the ++ opeator,
whereas at the same time it does support the += operator ???

No python developer I know has been able to answer that.

Istvan Albert a écrit :
On Apr 22, 6:25 am, azrael <jura.gro...@gmail.comwrote:
>A friend of mine i a proud PERL developer which always keeps making
jokes on python's cost.
>This hurts. Please give me informations about realy famous
aplications.

you could show him what Master Yoda said when he compared Python to
Perl

http://www.personal.psu.edu/iua1/pythonvsperl.htm

i.
Jun 27 '08 #12

P: n/a
On Apr 22, 5:50*pm, Jérémy Wagner <jeremy.wag...@laposte.netwrote:
Sure. Python is more readable than Perl, though I have found Python
to have a weird behavior regarding this little issue :

How can you explain that Python doesn't support the ++ opeator,
whereas at the same time it does support the += operator ???

No python developer I know has been able to answer that.
Because ++ is of limited use and has poor readability?

'x++' vs 'x += 1' saves 3 characters and is less readable.

'my_long_variable += expression' vs 'my_long_variable =
my_long_variable + expression' saves a lot of characters and is more
readable, because it avoids the duplication of the variable name. When
my_long_variable is a more complex term (perhaps
my_long_variable[some_long_expression]) it's even better.

Plus you get the useful update-in-place behaviour when the left-hand-
side of the += expression is a list.

--
Paul Hankin
Jun 27 '08 #13

P: n/a
On Apr 22, 12:50 pm, Jérémy Wagner <jeremy.wag...@laposte.netwrote:
Sure. Python is more readable than Perl, though I have found Python
to have a weird behavior regarding this little issue :

How can you explain that Python doesn't support the ++ opeator,
whereas at the same time it does support the += operator ???

Because "Features A and B are in language X. Python adds Feature A.
Therefore Python must also add Feature B (or it'll be weird)" is not
valid logic.
Carl Banks
Jun 27 '08 #14

P: n/a
En Tue, 22 Apr 2008 13:50:54 -0300, Jérémy Wagner <je***********@laposte.netescribió:
Sure. Python is more readable than Perl, though I have found Python
to have a weird behavior regarding this little issue :

How can you explain that Python doesn't support the ++ opeator,
whereas at the same time it does support the += operator ???

No python developer I know has been able to answer that.
Because Python doesn't follow the "boxed variables" model. In other languages i++ changes the "value" stored inside the box "i", but the box itself (the variable) is still the same. Python doesn't have boxes, it has names that refer to objects. For all builtin numeric types, i += 1 creates a *new* object with the resulting value and makes the name "i" refer to this new object.
i++ would be confusing because it looks like a mutating operation over i, but in fact it would be an assignment.

--
Gabriel Genellina

Jun 27 '08 #15

P: n/a
On Apr 22, 3:25 am, azrael <jura.gro...@gmail.comwrote:
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.
Sage ( http://www.sagemath.org ) is a pretty large Python computer
algebra system ( about 150,000 unique lines of Python and 75,000
unique lines of Cython as a rough estimate). Python turned out to be
an _excellent_ language do this in since it allows for quick
development time for many things that aren't speed dependent while
allowing a seemless transition to fast code with Cython.

--Mike
Jun 27 '08 #16

P: n/a
On 22 ÁÐÒ, 14:25, azrael <jura.gro...@gmail.comwrote:
[....]
This hurts. Please give me informations about realy famous
aplications.
What do you mean by "really famous"?

Information is here:
http://www.python.org/about/quotes/

Are YouTube and Google famous enough?

--
Ivan
Jun 27 '08 #17

P: n/a
http://code.google.com/appengine/doc...appengine.html

2008/4/22 Ivan Illarionov <iv*************@gmail.com>:
On 22 ÁÐÒ, 14:25, azrael <jura.gro...@gmail.comwrote:
[....]
This hurts. Please give me informations about realy famous
aplications.

What do you mean by "really famous"?

Information is here:
http://www.python.org/about/quotes/

Are YouTube and Google famous enough?

--
Ivan
--
http://mail.python.org/mailman/listinfo/python-list


--
---
You can't have everything. Where would you put it? -- Steven Wright
---
please visit www.serpia.org
Jun 27 '08 #18

P: n/a
azrael wrote:
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.
--
http://mail.python.org/mailman/listinfo/python-list
Ask him why, if Perl is so great, it isn't one of the Google-approved
languages for internal use, when Python *is*.

Ask him how it feels to program in a wrote-only language.

Challenge him to a dual with dead kippers at twenty paces.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Jun 27 '08 #19

P: n/a
Steve Holden <st***@holdenweb.comwrites:
Challenge him to a dual with dead kippers at twenty paces.
Please, have some dignity!

Challenge him to a duel with live kippers. Live, *rabid* kippers. With
frickin' laser beams on their heads.

--
\ "A man's only as old as the woman he feels." -- Groucho Marx |
`\ |
_o__) |
Ben Finney
Jun 27 '08 #20

P: n/a
In article <ma*************************************@python.or g>,
Steve Holden <st***@holdenweb.comwrote:
Challenge him to a dual with dead kippers at twenty paces.
You gotta be careful about stuff like this. You might slap him with a dead
kipper only to discover he's got a dead camel in his pocket.

Of course, there's always http://en.wikipedia.org/wiki/Wikipedia:Trout
Jun 27 '08 #21

P: n/a
Ben Finney wrote:
Steve Holden <st***@holdenweb.comwrites:
>Challenge him to a dual with dead kippers at twenty paces.

Please, have some dignity!

Challenge him to a duel with live kippers. Live, *rabid* kippers. With
frickin' laser beams on their heads.
I like your style.

Though considering what it takes to kipper a herring, I'd be very
surprised if there *was* any such thing as a live kipper. With or
without laser beam.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Jun 27 '08 #22

P: n/a
Roy Smith wrote:
In article <ma*************************************@python.or g>,
Steve Holden <st***@holdenweb.comwrote:
>Challenge him to a dual with dead kippers at twenty paces.

You gotta be careful about stuff like this. You might slap him with a dead
kipper only to discover he's got a dead camel in his pocket.

Of course, there's always http://en.wikipedia.org/wiki/Wikipedia:Trout
Damn, pilchards, that was it!

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Jun 27 '08 #23

P: n/a
Gabriel Genellina <ga*******@yahoo.com.arwrote:
Because Python doesn't follow the "boxed variables" model.
Be careful here. `Boxed types' or `boxed objects' is a technical term
essentially meaning `heap-allocated objects, probably with reference
semantics', which Python most definitely does use -- so this almost
means the opposite of what you're talking about.

Python has the same basic data model as Lisp, Ruby, Smalltalk and many
other languages: a variable (or a `slot' in a compound data-object)
contains a reference to value; values can referred to by many variables.
Assignment simply copies these references around. This means that it's
easy to end up sharing the same object between lots of variables (or
structures).

Contrast this to the model used by C, Pascal and other `traditional'
compiled languages, where a variable is actually a container for a
value, and assignment is a copying operation rather than a sharing
operation.
In other languages i++ changes the "value" stored inside the box "i",
but the box itself (the variable) is still the same. Python doesn't
have boxes, it has names that refer to objects. For all builtin
numeric types, i += 1 creates a *new* object with the resulting value
and makes the name "i" refer to this new object.
Note that `+=' in Python is inconsistent! For numeric types (and other
immutable types, such as strings or tuples), `VAR += VALUE' means the
same thing as `VAR = VAR + VALUE' (ignoring tedious issues of multiple
evaluation of subexpressions -- e.g., subscripts -- in VAR), which as
mentioned above causes a new reference to be stored in VAR, referring to
the object which was computed by adding VALUE to the object previously
referred to by VAR. For lists, it does not do this: instead, it extends
the list in place, putting new values on the end of it.

(This is one of the language's few obvious inconsistencies, and probably
a reasonably justifiable one; but it's still worth pointing out.)

To be honest, I don't see any particular reason why `++' is any more of
a mutation operation than `+=' is in the languages that define it;
Python is actually one of the few to define one but not the other. (The
other one I can think of is Acorn's BBC BASIC, for whatever that's
worth; it too lacks `++'.) But then again, one of the main conceptual
advantages of `++' as an operator is that it has both pre- and post-
increment variants, which are useful when used as part of a wider
expression. This won't hold in Python, since assignments (which `++'
assuredly ought to be) aren't allowed as subexpressions anyway. So the
value of `++' would be limited to providing an abbreviation over the
already quite short `+= 1'.

That's not quite true, in fact: it might be useful to define other kinds
of incrementing for specialist types, but I can't think of any obvious
examples off the top of my head.

This argument doesn't apply to `+=' which has the benefit of saving you
from having to type the VAR twice (which is nontrivial if VAR contains
complex subexpressions) and -- more significantly -- saves a reader from
having to check whether VAR and VAR' actually match in `VAR = VAR' +
VALUE' and ensures only single evaluation of subexpressions of VAR.
None of this applies to `++'. So `++' is not a feature I find myself
sorely missing in Python.

-- [mdw]
Jun 27 '08 #24

P: n/a
azrael <ju*********@gmail.comwrote:
A friend of mine i a proud PERL developer which always keeps making
jokes on python's cost.
There is only one sane way to deal with this situation: You need a
common enemy. Java comes to mind ;-)

cu
Philipp

--
Dr. Philipp Pagel
Lehrstuhl f. Genomorientierte Bioinformatik
Technische Universität München
http://mips.gsf.de/staff/pagel
Jun 27 '08 #25

P: n/a
On 23 Apr, 11:12, Mark Wooding <m...@distorted.org.ukwrote:
Gabriel Genellina <gagsl-...@yahoo.com.arwrote:
Because Python doesn't follow the "boxed variables" model.

Be careful here. `Boxed types' or `boxed objects' is a technical term
essentially meaning `heap-allocated objects, probably with reference
semantics', which Python most definitely does use -- so this almost
means the opposite of what you're talking about.
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.

[...]
This won't hold in Python, since assignments (which `++'
assuredly ought to be) aren't allowed as subexpressions anyway.
This syntactic note is probably one of the biggest arguments against
it, yes, since many of the benefits it has in C would be absent in
Python.

[...]
That's not quite true, in fact: it might be useful to define other kinds
of incrementing for specialist types, but I can't think of any obvious
examples off the top of my head.
Well, as I recall, data structures in C++ (such as iterators) often
use the pre/post-increment/decrement operators as shorthand, arguably
reflecting the "pointer arithmetic" heritage of the C family of
languages. It would be pure sugar in Python, though.

Paul
Jun 27 '08 #26

P: n/a
-----Original Message-----
From: py********************************@python.org [mailto:python-
li*************************@python.org] On Behalf Of azrael
Sent: Tuesday, April 22, 2008 6:26 AM
To: py*********@python.org
Subject: Python Success stories

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.

IIRC, Python is used in games like Eve Online (SciFi MMO) and Vampire:
Bloodlines (RPG.) Years later, a dedicated fan is still fixing/updating
the Bloodlines python scripts that control the dialogue and scripted
events.

OTOH, I use Perl over Python when it comes to Windows COM scripts due to
finding a typelib that Python just refused to load. *shrug*

Perl, Python, and your friend are tools. Use them appropriately for the
given situation.

Jun 27 '08 #27

P: n/a
2008/4/23, Reedick, Andrew <jr****@att.com>:
>
IIRC, Python is used in games like Eve Online (SciFi MMO) and Vampire:
Bloodlines (RPG.) Years later, a dedicated fan is still fixing/updating
the Bloodlines python scripts that control the dialogue and scripted
events.
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" :D
Jun 27 '08 #28

P: n/a
Civilisation 4 uses Python everywhere and is the main tool used by
Modders of the game.
Jun 27 '08 #29

P: n/a
On 2008-04-22, Paul Hankin <pa*********@gmail.comwrote:
On Apr 22, 5:50*pm, Jérémy Wagner <jeremy.wag...@laposte.netwrote:
>Sure. Python is more readable than Perl, though I have found Python
to have a weird behavior regarding this little issue :

How can you explain that Python doesn't support the ++ opeator,
whereas at the same time it does support the += operator ???

No python developer I know has been able to answer that.

Because ++ is of limited use and has poor readability?

'x++' vs 'x += 1' saves 3 characters and is less readable.
In addition, the statement

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.
Jun 27 '08 #30

P: n/a
On 2008-04-23, Mark Wooding <md*@distorted.org.ukwrote:
Python is actually one of the few to define one but not the other. (The
other one I can think of is Acorn's BBC BASIC, for whatever that's
worth; it too lacks `++'.)
You should've added it in Termite Basic then :-p
Jun 27 '08 #31

P: n/a
Bob Woodham wrote:
>
x = x++;

has unspecified behaviour in C.
what about C++
Jun 27 '08 #32

P: n/a
Cristina Yenyxe González García wrote:
2008/4/23, Reedick, Andrew <jr****@att.com>:
>IIRC, Python is used in games like Eve Online (SciFi MMO) and Vampire:
Bloodlines (RPG.) Years later, a dedicated fan is still fixing/updating
the Bloodlines python scripts that control the dialogue and scripted
events.

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" :D
and Shrek 3 http://www.linuxjournal.com/article/9653

--
a.
Jun 27 '08 #33

P: n/a
Cristina Yenyxe González García wrote:
2008/4/23, Reedick, Andrew <jr****@att.com>:
>IIRC, Python is used in games like Eve Online (SciFi MMO) and Vampire:
Bloodlines (RPG.) Years later, a dedicated fan is still fixing/updating
the Bloodlines python scripts that control the dialogue and scripted
events.

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" :D
and Shrek 3 http://www.linuxjournal.com/article/9653

--
a.
Jun 27 '08 #34

P: n/a
On Apr 23, 2:08 pm, Bob Woodham <wood...@cs.ubc.cawrote:
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.
Jun 27 '08 #35

P: n/a
En Wed, 23 Apr 2008 08:43:56 -0300, Paul Boddie <pa**@boddie.org.uk>
escribió:
On 23 Apr, 11:12, Mark Wooding <m...@distorted.org.ukwrote:
>Gabriel Genellina <gagsl-...@yahoo.com.arwrote:
Because Python doesn't follow the "boxed variables" model.

Be careful here. `Boxed types' or `boxed objects' is a technical term
essentially meaning `heap-allocated objects, probably with reference
semantics', which Python most definitely does use -- so this almost
means the opposite of what you're talking about.

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.

--
Gabriel Genellina

Jun 27 '08 #36

P: n/a
On 2008-04-24, AlFire <sp******************@ggmail.comwrote:
Bob Woodham wrote:
>>
x = x++;

has unspecified behaviour in C.

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.
Jun 27 '08 #37

P: n/a
On 2008-04-24, Istvan Albert <is***********@gmail.comwrote:
On Apr 23, 2:08 pm, Bob Woodham <wood...@cs.ubc.cawrote:
>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...
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.
Jun 27 '08 #38

P: n/a
In article <7e**********************************@c65g2000hsa. googlegroups.com>,
azrael <ju*********@gmail.comwrote:
>
Which big aplications are written in python.
YouTube
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

Why is this newsgroup different from all other newsgroups?
Jun 27 '08 #39

P: n/a
On Apr 22, 11:25 am, azrael <jura.gro...@gmail.comwrote:
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/
Jun 27 '08 #40

P: n/a
On Apr 29, 2:25*pm, Fuzzyman <fuzzy...@gmail.comwrote:
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
Jun 27 '08 #41

P: n/a
>
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.
Jun 27 '08 #42

P: n/a
On Apr 30, 10:47 am, cokofree...@gmail.com wrote:
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.
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! :-)
Jun 27 '08 #43

P: n/a
Someone wrote:
>>>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.
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.

--
Greg
Jun 27 '08 #44

P: n/a
greg <gr**@cosc.canterbury.ac.nzwrites:
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.
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: refactor duplication, remove redundant code, and
add new code.

This should tend to result in the unit test suite growing over time
faster than the application code does, even if roughly the same effort
goes into both. Thus the size of each is not a good indicator of the
amount of effort.

--
\ "I got a postcard from my best friend, it was a satellite |
`\ picture of the entire Earth. On the back he wrote, 'Wish you |
_o__) were here'." -- Steven Wright |
Ben Finney
Jun 27 '08 #45

P: n/a
Ben Finney a écrit :
greg <gr**@cosc.canterbury.ac.nzwrites:
>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.

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:
refactor duplication, remove redundant code,
Jun 27 '08 #46

This discussion thread is closed

Replies have been disabled for this discussion.