Wikipedia

Talk:Python (programming language)/Archive 1

< Talk:Python (programming language)
Latest comment: 18 years ago by Donhalcon in topic Parameter Passing
Archive 1Archive 2Archive 3→Archive 5

Some old comments

Python is described in "it transparently supports bignum arithmetic". "bignum" is defined as encompasing both arbitrarily large integers and rational numbers. Python does not yet provide for rational number arithmetic.

I don't believe Python supports Functional programming, as in Prolog or somesuch. It supports function-based programming... meaning that your program is just composed of functions not organized into classes and objects. I have gotten the two confused in the past, and I suspect that this is what happened here.

Or does Python really support functional programming? Is there some add-on package that allows this? I wasn't aware of one. -- ansible

Yes, Python really does have some built-in functional programming features such as "map()", "filter()", "reduce()" and a somewhat limited "lambda", although I've read that Guido van Rossum now regrets including these features in the language. As a more readable and "Pythonic" alternative, "list comprehensions" were more recently introduced into the language and can often be used instead of the older functional programming constructs.

I for one do not believe very much in language purity, and I say that as someone who admires Scheme. Fiddly distinctions such as "object-oriented" vs. "object-based", or "functional" vs. "function-based" vs. "pure-functional" are, simply put, religious disputes. As such, they may merit being mentioned in Wikipedia (as do real religious disputes) but should not be taken too seriously.
I consider functional programming, like object-oriented programming, to be chiefly a style of programming -- i.e. something that programmers do, not something that languages do. A language can allow a style of programming, or can even attempt to mandate its use (e.g. Scheme; Java), but it is the program which has a style not the language. It is in this light which I wrote in the subject article that "Object orientation and structured programming are supported, as well as functional programming."
(It is possible to write an imperative-style program in the "functional language" Scheme using begin and do, or an object-oriented program in the "structured language" ANSI C. It isn't possible to write a functional program in Pascal, though, since you can't pass around functions.)
Of course Python does not attempt to be a "pure-functional language" i.e. a language which requires programmers to use functional constructs. Nevertheless, it still permits the style in the large, by (for instance) permitting functions as values, generators, continuations, etc. --FOo
-------
"List comprehensions" may be more Pythonic, but how are they more readable? I find map, filter, and co. to be extremely readable and intuitive, much more so than the new list comprehensions. Unfortunately, GvR doesn't agree with me on that...

I do not think Python is 'strongly influenced' by Perl. In fact the design philosophy is diametrically opposite in some senses.pasokan

Let's see -- Python's an interpreted/bytecode-compiled language, with mixed type arrays, garbage collection, hashes/dicts as a basic type, a big standard library with support for Unix calls ... it has a lot in common with Perl. A large portion of the Python user base are "converts" from Perl. Python also self-consciously eschews Perl-like syntax, which is a different way of being "influenced" by Perl! --FOo

I'm not sure if we should say that Python is strongly typed. It provides a lot of implicit conversions (eg, between numeric types, between string types) and makes common use of functions accepting any one of a group of related types (any sequence, or any 'file-like object'). It doesn't make it easy to derive a new type from an old one without making it compatible (eg, you can't easily make a new integer type which isn't comparable with the standard Integer). Matthew Woodcraft

This is true. Python has a large number of distinct types (integers, floats, long integers, bignums, complex, e.g.) but converts implicitly among them all. I suppose you could say that Python has a complicated system of types, but isn't "strongly typed" ... especially since a lot of folks read "strongly" as "statically". --FOo

Hfastedge -- Please take more care when editing this article. Your point that Python is dynamically typed has already been integrated with the article and does not need to be repeated. A few of your other points were erroneous or misleading, which is why they were removed. Please take the time to understand this and do not simply add them again.

Your statement that Python programs are "interpreted, not compiled" is simply false. Python -- like Java and Perl -- is a bytecode-compiled language. Compilation is implicit before execution of uncompiled scripts, which is why a new Python user might not have noticed its existence. However, it's there; it's how Python works; and yes, compiler errors are distinct from runtime errors. Compiled Python files have the extension .pyc, or .pyo if optimized. If you've never seen one, you haven't used Python for very long.

Python is a dynamically typed language, because that is how it is designed. It is neither a mistake nor an accident. Talking about this as if it is something suitable to "change" with a "paradigm shift" is not talking about Python, it is talking about your opinion of dynamic vs. static typing.

Your claims regarding "massive projects" vs. "rapid prototyping" are ill-advised in the light of the many massive projects that have been written quite successfully in dynamically typed languages (including Python). If you would like to discuss advantages and disadvantages that critics perceive in static and dynamic type-systems, you might want to do so on the pages for those subjects.

In addition, I suggest strongly that you study the writing style of other Wikipedia articles, as it will help you to integrate your work more fully with an article. You might particularly want to watch your use of links -- introducing a link with "here is:" is rough anywhere on the Web. Namespaces are not created lightly. Also, needless indentation turning a Wiki document into a piece of flat text are not desirable. --FOo

substantively?. Ok here: about the above stuff, theres no need for me to reply as I agree more of less with your changes. Although .pyc are simply compiled to bytecode, and python barely does any kind of optimization, so you really like to toot your own horn.
re the new, more relevant stuff, I feel that unit testing should be mentioned directly with the explanation of pythons type system, and that some points of the culture list should be included on the page.

Hfastedge 09:05 18 Jun 2003 (UTC)


A fine general article as the the features of Python, but (unless I'm to tired to notice it) there doesn't seem to be a mention of the uses of Python as a glue language, either with C/C++ using a SWIG interface or with Java in the form of Jython. The stuff about Python vs. Java, whilst being a fair enough comparison, maybe misleads into thinking that their use is in direct competition, whereas they can play complementary roles in development. I'd be tempted to make these comments but I'm (a) rather too new to wikipedia to chance it and (b) way too tired at the moment. But I think this stuff is worth mentioning. sobekhotep

Inheritance

From what I read, Python has inheritance but no access control (public, private,...). Can someone ellaborate on OOP in Python? -- Error

Python has inheritance, including multiple inheritance. It has limited support for private variables using name mangling. See the "Classes" section of the tutorial for details.
From the tutorial: As is true for modules, classes in Python do not put an absolute barrier between definition and user, but rather rely on the politeness of the user not to "break into the definition."
OOP doctrines such as the use of accessor methods to read data members are not enforced in Python. Just as Python offers functional programming constructs but does not attempt to demand referential transparency (contra Scheme), it offers (and extensively uses!) its object system but does not demand OOP behavior (contra Java). --FOo 04:58, 2 Sep 2003 (UTC)

Collection types

Python 2.3 now comes with an un-ordered collection type, the set. I too will refrain from adding to the Python Wiki page as I cannot match the high standard of the article. - Paddy3118

Added link to Aspect oriented programming for the types of programming styles that Python offers. See this article or this google search for support. Hyakugei

Are there enough users who like both to mention them in this article?

Now this is a beautifully written page with very high technical value. I am afraid though that there is a little bit of personal oppinion in the philosophy section (and that seems almost normal :) By judging the comments my point of view was confirmed. For what seems to be the technical influence between Perl and Python there is IMHO more than enough evidence to claim a relationship. When it comes to the point of view of the users I think it might be a good idea to outline that there are two groups of people, myself being part of the second one, and I would love if this second group could be mentioned in this article. My idea would be to write something as follows:

"It is interesting to notice that given the aforementioned similarities [between Perl and Python] there are some who consider them very much different in style and quality. Some others like both languages for their qualities and would rather prefer to see the two languages evolve together".

But great work, really great work.

Robert Dober robert.dober@free.fr 195.167.202.147 16:39, 1 Jun 2004 (UTC)

Python History

Hi, Pythoners. Over at object oriented programming, I wrote the following: 

Python and Ruby are relatively recent languages that were built from the ground up with OOP...

I have recently read some conflicting statements about object based functionality only being added in version 2.2. Over at python.org, I was't able to find anything that specifically mentioned whether or not object orientation was in the language from the beginning. Would anyone know? Thanks. AdmN 21:16, 26 Aug 2004 (UTC)

AFAIK, Python was object oriented from the start, or at least from very early on. However, types (int, str, etc) and user classes were separate things (e.g. you couldn't make a class that inherited from int) until 2.2. Fredrik | talk 21:26, 26 Aug 2004 (UTC)

What about Parrot ?

Shouldn't be Parrot, the common framework for Python and Perl be mentioned ?

Maybe it's an attempt of Perl to devour Python, maybe it's just a joke... However, it received attention of several important programmers. For instance, Perl creator.

Hgfernan 22:38, 4 Sep 2004 (UTC)

What About TIM Peters and his Pythonic Thesis?

I think that if we are talking about Philosopy of Python we should mention Tim Peters Pythonic Thesis I wrote a quick page on him and his Python Thesis, perapsh this should be included too?

Formatting of C examples

An anon user removed all but the outermost braces from the example of the factorial function written in C. I have reverted it back for the time being because I'm not sure the anon's version is correct, or clear, whereas the pre-edit version is both.

Is it correct?

The statement blocks from which the anon removed the braces were blocks of one statement each. Since I have not written C code in a decade, my knowledge is rusty; I believe this may be technically correct, that you may omit the braces from a statement block only if there's only one statement in the block. However, I am not sure on this point.

Is it clear?

Even if the code as the anon edited it is compiler-correct, it is misleading; the entire point of the comparison is that Python uses indentation, as opposed to punctuation, which is what C uses in every case except single-statement blocks, where it becomes optional.

What should we do about it?

In the short term, I have reverted, as previously mentioned. However, in the long term, we should perhaps decide between three alternatives (assuming that omission of braces is in fact legal in C for single-statement blocks):

The code as it was before the anon edit. The disadvantage is that it does not show the one instance in C where a programmer may choose to omit the braces. The advantage is that it more accurately reflects the general practices of C. Since the article is about Python and not C, the disadvantages don't strike me as too significant in this case.

The code as it was after the anon edit. The disadvantage is that it does not show one possible way a C programmer might format their code in the one case where they have a choice. The advantage is that it is more accurate, at least in terms of how a C programmer might format (many programmers choose to format consistently in the style that is always allowed, even when they language offers a choice.)

A different example that requires multiple-statement blocks. The disadvantage is that it would require careful selection of a new example. The advantage is that it would not be an artificial example. This doesn't strike me as too much of an advantage; don't hundreds of computer text books demonstrate basic principles by showing the bubble sort, despite the notorious inefficiency of the bubble sort?

I think on the whole my recommendation is for the first alternative, but if anyone disagrees, please bring up the issue here.

-- Antaeus Feldspar 18:26, 21 Sep 2004 (UTC)

Good practice in C uses braces here, so that a later addition to the then-clause does the right thing. Moreover, the distinction being raised is between punctuated blocks (C) and indented blocks (Python), so braces are needed. I think the code is fine as it aws (with the braces) -- an example using multiple-statement blocks is harmless but I do not think it is necessary. —FOo 19:24, 21 Sep 2004 (UTC)
Sorry for the removal of the braces in the first place. I made the change facetiously to try to raise the point that it was a poor example since it was valid without the braces. When I first read the comparison of Python code and C code, it did not clearly communicate to me the difference between the two, because I (as a seasoned C programmer) immediately saw that I could remove those braces. Without the knowledge that Python is indentation based, I (as having no prior knowledge of Python) was momentarily confused since it would be natural to assume (to a C programmer) that perhaps it didn't require braces since it only consisted of one statement. Of course, having read the rest of the text, I realised the point that was being attempted to be made, but isn't the intention of the example to make it obvious? I think that, although the page is about Python, since the comparison is with C, the example should be clear to C programmers what the intented point was. — The anon that made the change 11:23, 22 Sep 2004 (UTC)
I think the whole problem is caused by formatting the C example in the same fashion as the Python version. If you re-write the C version in a single line, converting all whitespace to single spaces, you might get the idea across better. HTH HAND --Phil | Talk 12:33, Sep 22, 2004 (UTC)

Example

I have not made this change in the main article in order that someone more familiar with Python can confirm the correctness of the example. --Phil | Talk 12:48, Sep 22, 2004 (UTC)

Factorial function in C
int factorial(int x) {      
    if (x == 0) {                      
        return 1;                   
    } else {
        return x * factorial(x-1);
    }
}

is syntactically equivalent to: 

int factorial(int x) { if (x == 0) { return 1; } else { return x * factorial(x-1); } }
Factorial function in Python
def factorial(x):
    if x == 0:
        return 1
    else:
        return x * factorial(x-1)

is not equivalent to: 

def factorial(x): if x == 0: return 1 else: return x * factorial(x-1)


Just to present an alternative for consideration, what about presenting both C examples? Show the single-line version, show the braced version, then compare them with the Python version.
Note that I don't necessarily advocate this alternative, I just suggest it's one of our options. After the point that Fubar brought up, I think it's probably best to show two examples formatted according to best practice for the respective language, even if that causes confusion for the occasional reader who (sorry, anon) doesn't read the article to understand the difference that the examples demonstrate. -- Antaeus Feldspar 17:04, 22 Sep 2004 (UTC)
No apology necessary. I did read the article and understand the difference that the example demonstrated. My point was that the example did not make the article any clearer. This defeats the purpose of having an example. I still maintain it's a bad example until it clearly shows how C syntax is not influenced by whitespace and Python syntax is. I would suggest an example such as:
Example in C (poor indentation)
if (x == 0)
    x = 100;
    y = 100; /* Syntactically legal, but misleading indentation; y is assigned the value 100 regardless of the condition */
Example in C (good indendation, identical meaning as the

above): 

if (x == 0)
    x = 100;
y = 100;
Example in Python
if x == 0:
    x = 100
    y = 100 # No confusion possible, y only assigned the value 100 if the x == 0 condition was true
Example in Python (different meaning due to indentation)
if x == 0:
    x = 100
y = 100 # y is assigned regardless of the x == 0 condition outcome
I realise that the above examples aren't worded particularly well, they're just intended to illustrate my point in this discussion. If I am alone on this then I gracefully admit my error in judgement. Kind regards, no longer anonymously Chris Young 04:37, 23 Sep 2004 (UTC)

- Just want to point out that this is a rather poor way to implement a factorial function. The number of recursions is very quickly exceded.

That's not surprising. The point is not to implement an efficient factorial function, it's to show the operation of the language. -- Antaeus Feldspar 02:54, 5 Nov 2004 (UTC)

Feldspar, I am not convinced. Please supply better proof. 216.153.214.94 03:49, 5 Nov 2004 (UTC)

Wow, Not-Rex-Really, you sure have found a lame and sad way to spend your time. -- Antaeus Feldspar 04:38, 5 Nov 2004 (UTC)

Certainly, a better way to show the operation of the language would be 

fac = lambda x: reduce(lambda a,b: a*b, xrange(1, x+1))

;)

This is anti-Python; code that you can't read and maintain. What is a? What is b? Even the variable name is not clear - fac?

For the record, this performs pretty much identically (I timed both with a couple of numbers between 10 and 100000) to 

   def fac(x):
       product = 1
       for n in xrange(1, x+1):
           product *= n
       return product

-- Fredrik | talk 04:32, 5 Nov 2004 (UTC)

  • This is a fascinating discussion and further clarifies a number of differences between the languages. Perhaps it should be edited into its own page? John Elder 19:01, 7 Jun 2005 (UTC)

Although its only an example for indentation, the code could be simplified. There is not point in the "if else" in this case, its a one branch conditional.

Factorial function in C: 

int factorial(int x) {
    if (x == 0)
        return 1;
    return x * factorial(x - 1);
}

Factorial function in Python: 

def factorial(x):
   if x == 0:
        return 1
    return x * factorial(x - 1)

This can be "simplified" to: 

def factorial(x):
    return x == 0 and 1 or x * factorial(x - 1)

But this code is less readable. Its not clear what is the exit condition, you have to "parse" the line to understand it.

Adventurous editing

It is possible that my last edit didn't improve the article in all respects. Comments would be welcome.

Three lines were removed; I'll motivate why here:

  • Some of the software used to control the scoreboard at the Melbourne Cricket Ground is written in Python.
    • This fact seems trivial. Python, like every other major programming language, is used in many different places. Maybe this is worth mentioning in the Melbourne Cricket Ground article, but as far as I can see, it's not particularly relevant to Python itself. Fredrik | talk 17:49, 23 Sep 2004 (UTC)
      • I abstain on the other edits (leaning towards agreement) but this one I disagree with. You know and I know that Python is a major programming language, and we have a good idea of just how major, but we're aiming at a reader who doesn't know. I think if anything, we should be editing in more places where Python is known to be used, so that the reader gets a real sense of just how widely used it is. -- Antaeus Feldspar 18:56, 23 Sep 2004 (UTC)

Hmm, there are some confusing, misleading or plain wrong statements in this article:

  • The statements about logical operators are confusing and misleading for a number of reasons;
  • Python 2.2 didn't change the truth values of objects, and it's been possible to overload operators since before 1.5.2: it's not a new thing.
  • Python doesn't support continuations. (It does allow continuation passing style, of course, and the dialect Stackless Python used to support them; but the mainstream language does not.)

(I know should fix the article; but if I don't get around to finishing that, at least my objections are recorded.)


Python wants Python

I think it's about time that we move this page to Python. 9 out of Google's top 10 hits for the word "python" is to the language and the other one is for Monty Python. The real life snake just isn't interesting enough. Eric B. and Rakim 07:07, 12 Jan 2005 (UTC)

Do C first. Nobody does a Google search for some boring letter. :) --FOo 15:21, 12 Jan 2005 (UTC)
Wow! That's really cool. Searching for the other letters are also interesting. It seems like Google does something with the results so you get very strange results when searching for single letter stuff. Eric B. and Rakim 17:38, 13 Jan 2005 (UTC)
Needless to say, Google and the web have a bias because they're dominated by a technical elite forming a tiny portion of the world's population. You could argue this doesn't matter, because these people are also our audience, but I offer a stronger objection: that generically-named articles should be on generic topics that anyone can understand, if possible. Even if the Water language were as popular as C, most people would be a lot more familiar with the wet stuff. Deco 04:08, 13 Jan 2005 (UTC)
I can refute the "technical elite" argument right now, I think more about the other arguments later. Do a book search in a library or book store, search for Python. You will have hard time finding any living snakes. So it is not only Google and the www that has a bias and is part of a technical elite. It's the book publishers and librarians too. AND: "Python is the common name for the Boidae Family of nonvenomous constricting snakes—specifically the subfamily Pythonidae." <- biological elite. :) Eric B. and Rakim 17:38, 13 Jan 2005 (UTC)

As big a fan as I am, Python the language just does not have the prominence that would justify it displacing the very thing it was (indirectly) named after. -- Antaeus Feldspar 19:52, 13 Jan 2005 (UTC)

Confusing statement about docstrings

However, if the block that is being out-commented contains docstrings it wont work and the code wont run.

What is that supposed to mean? - Fredrik | talk 02:43, 14 Jan 2005 (UTC)

Imagine this: 

 def foo():
     """Hi foo()"""

"docstringing" it out: 

 """
 def foo():
     """Hi foo()"""
 """

The compiler will throw a SyntaxError at "Hi foo()" because it thinks that is the code. Ok badly phrased, but the essence is that commenting using docstrings is bad. :) Eric B. and Rakim 02:55, 14 Jan 2005 (UTC)

That is not a problem with Python docstrings specifically, but with nested open/close-marked comment in general. Consider the following C example:
/*
int function()
{
  /* Returns 0*/
  return 0;
}
*/
In fact, Python gives even you a way to avoid the problem; using ''' for the outer comment.
The statement as it stands is too vague as it does not explain "wont work", and as explained above inaccurate. In fact I don't think it's worth mentioning at all, because it is a trivial syntax error. You also get a syntax error if you nest parentheses incorrectly, but we don't mention that -- for good reasons. Fredrik | talk 00:33, 16 Jan 2005 (UTC)

Removal of reference to Oz as a multi-paradigm language

The reference to Oz I had introduced a few months ago as a multi-paradigm language (like Python & Perl) has been removed and I can't see any discussion on the reason for this. Oz is considered by many as the most multi-paradigm language in existence today. Oz is the language used within the new book Concepts, Techniques, and Models of Computer Programming, MIT press. This book is already considered a classic, and possibly the equivalent of Structure and Interpretation of Computer Programs, by Sussman & Abelsson. See Lambda The Ultimate site for many references to this book. I therefore bring the reference to Oz back in the Python page.

Parameter Passing

Latest comment: 18 years ago1 comment1 person in discussion

The explanation of parameter passing in Python needs work. It is a common confusion to say that Python passes values by reference (even among experienced Pythonistas), but GvR explains it correctly in his tutorial. Basically, all parameters are passed by value, but object values are references. The reason this becomes an issue is that mutable objects appear to be passed by reference. Non-mutable objects such as numbers and strings don't show this behavior. What doesn't seem to be commonly understood is that the same issue shows up with assignment:

x = [1, 2, 3]
y = x
x[:] = [3, 2, 1]
print y

It's also a bit awkward to say that Python variables "contain" values. Python variables actually bind names to values which isn't the same thing. Looked at that way, you can see that after y = x, y and x are different names bound to the same value. Mutating the object bound to x will naturally affect the object bound to y -- it's the same object. That list isn't contained in two different places, it just has two different names.--Quale 21:01, 7 Mar 2005 (UTC)

To me, saying that you're passing a value that is a reference just seems like an awkward way of saying that you're passing a reference. Fredrik | talk 07:58, 8 Mar 2005 (UTC)
It seems that way to many people, but it's incorrect. The inventor of Python would say Python passes by reference if it was an accurate description of what Python does. Consider this:
def foo(x):
x = [3, 2, 1]
y = [1, 2, 3]
foo(y)
print y
If a reference to y was passed to foo then y would be changed to [3, 2, 1] after the foo(y) call. It isn't. Python like Java, Scheme and most other modern languages, passes parameters by value. The problem is that many people don't understand what values are in those languages. The value is really just an object. It isn't really a reference, although many people say they find it easier to think of it that way. I wonder if it really does help considering how confused they are about how parameters are passed. The other common confusion is that many people mistakenly think that passing by value requires making copies.--Quale 17:00, 8 Mar 2005 (UTC)
What I meant is of course that *objects* are passed by reference. I don't think of variables themselves as being passed around at all - I just think of them as dictionary lookups in locals(), globals() etc... - Fredrik | talk 18:04, 8 Mar 2005 (UTC)
Well, all values in Python are objects, so everything gets passed the same way. You would have to say that Python objects are assigned by reference too, because values are passed and assigned the same way.--Quale 01:56, 9 Mar 2005 (UTC)
Yep, that's what I say. Fredrik | talk 07:12, 9 Mar 2005 (UTC)
OK. Now add the fact that the definition of call-by-value is that the value passed is the same kind of value that is used for the right hand side of an assignment and you will correctly conclude that Python is CBV. For call-by-reference, the value passed is the value that's used on the left hand side of an assignment. A college programming language theory or compiler class will discuss l-values and r-values. --Quale 07:33, 9 Mar 2005 (UTC)
Thanks for the explanation. Fredrik | talk 07:41, 9 Mar 2005 (UTC)
If someone wants to know what Python really uses, do a literature search for call-by-object-reference and/or call-by-sharing (see CLOS papers for early use of these terms). While saying that Python uses call-by-value is slightly less misleading than saying that Python uses call-by-reference, it's not CBV in any of the traditional senses.
Quale, would you mind taking a look at Call-by-something? It's a mess and really needs to be cleaned up by someone who knows what they're talking about, and it seems like you have the knowledge. -- Antaeus Feldspar 18:22, 8 Mar 2005 (UTC)
Funny you should mention that. I looked at parameter (computer science) earlier today and it isn't good. I'll take a crack at it probably in the next couple of days. As you know it's hard to explain. It's made a little harder by the fact that practicing programmers use the terms a lot more loosely than computer science language theorists do. The distinctions are subtle and many extremely competent programmers who aren't theorists find the definitions have consequences that they find counterintuitive (such as Python, Java and Pascal all being call-by-value languages).--Quale 01:56, 9 Mar 2005 (UTC)
What I find remarkable is that understanding these (seemingly complicated) parameter binding mechanisms becomes trivial once you've implemented them. Maybe a pseudocode implementation would be desirable on parameter (computer science) for each mechanism? 11:48, 21 Jun 2005 (UTC)
The parameter (computer science) section on call-by-something now lives at evaluation strategy, in case anyone is actually still reading this thread. --bmills 03:40, 7 February 2006 (UTC)

Related page moves

I moved Python (disambiguation) to Python and Python to Python (snake) to make the Wikipedia easier to navigate. A large number of the python links were about the language and this will reduce the average number of clicks to get around. I know some people here would have liked this article to become the main Python page, but I think that's a bit computer programmer centric and would simply reverse the problem. I followed the example of Cobra.

Still, the existing links to Python that are about the language should be fixed to point directly to this article. Daniel Quinlan 09:40, Mar 8, 2005 (UTC)

continuations as functional?

Sayeth the article:

Because Python permits functions as arguments, it is also possible to partially simulate more subtle functional constructs, such as the continuation.

In what sense are continuations "functional"? ISTM they are imperative, in the sense that they are a facility for manipulating control flow. Neilc 12:50, 1 Apr 2005 (UTC)

Maybe you should ask at Talk:Continuation? -- Antaeus Feldspar 01:34, 2 Apr 2005 (UTC)
There's no meaningful sense in which normal Python supports continuations. I shall remove this comment from the article. -- ciphergoth 10:15, 2005 Apr 2 (UTC)
Could you explain Denys Duchier's article "Continuations Made Simple and Illustrated" then? --FOo 17:15, 2 Apr 2005 (UTC)
FOo, it looks like Duchier is showing how Python can currently be used to simulate continuations -- but this doesn't mean that continuations are part of the language. For instance, you could simulate a GOTO in Python with something like the following:
if not (shouldGOTOLine500):  # line 470
    furble(x)            # line 480
    quimble(y)           # line 490
foobaz(x,y)              # line 500
but it wouldn't be a GOTO, merely a simulation of one. In the same sense, you can simulate continuations by rewriting your code, and certain language features like exception handling and generators work in continuation-like ways -- but continuations, like GOTOs, are not a feature present in the language.
Warning: I may be completely wrong about all this, as I do not claim to be an expert on continuations or anything near expert. -- Antaeus Feldspar 00:45, 3 Apr 2005 (UTC)
Sounds reasonable. My impression was that Duchier was trying to illustrated something like continuation passing style (CPS). It would be rather absurd to claim that first-class continuations (call/cc) are in Python. However, Python exceptions are equivalent to escape continuations -- see continuation for the distinction -- and are used as such, for instance in the Mailman mailing list manager.
As for whether continuations are a functional-programming feature ... It's my impression that CPS and first-class continuations are generally regarded as related to functional programming, but that exceptions are no more connected to functional than to structured programming. --FOo 02:29, 3 Apr 2005 (UTC)


Printing example

This looks simpler: 

def add_and_print_maker(x):
    def temp(y):
        print x, "+", y, "=", x+y
    return temp

Than: 

def add_and_print_maker(x):
    def temp(y):
        print "%d + %d = %d" % (x, y, x+y)
    return temp
  • A valid point. But they operate differently. Your simpler example will properly function with strings (catenation, not addition), but the example as listed will throw an error. The comparison of the two functions is worth keeping around, as well as a discussion of their differences - does the formatted print statement run faster or slower than the catenated one? John Elder 19:08, 7 Jun 2005 (UTC)

and PyAlaMode, an IDE for Python created by Orbtech, a company specializing in Python. ??

since when wikipedia does free ad to company. or is PyAlaMode a necessity to someone. PLEASE REMOVE THAT and put PyGTK or PyQT or whatever PyFOO u want, or just remove [cause you already have 2 exmaples nad it's enough]

Retrieved from "https://en.wiki.x.io/w/index.php?title=Talk:Python_(programming_language)/Archive_1&oldid=1248636738"