Talk:Python (programming language)/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

→

Archive 10

Doctest

I have just created my first page on Doctest. Is there room for a link to it? --Paddy 08:21, 14 December 2005 (UTC)

Biased C Example

I modified the example which compared C code to Python code, because it added unnecessary curly braces, possibly as a biased way to show Python's neatness. --Phill

That bothered me before but I didn't change it. I think the whole example is bad, with or without braces, with braces it's biased because C doesn't need them in that case and without them it just sucks because it's meant to demonstrate that whitespace is significant in Python with regards to blocks but isn't in most other languages. Without the braces the example doesn't really convey the point clearly enough.

Off topic: I would have written that as return n == 0 ? 1 : n * factorial(n-1) in C and [*] 1..$n in my favorite language, guess which;) —Ævar Arnfjörð Bjarmason 22:25, 23 December 2005 (UTC)

I think you're quite right about it being a bad example. I can't come up with anything off the top of my head that is both simple and requires a block of statements. Off topic: Yeah, ?: is handy stuff, and the $ gives the language away. =) --Phill

I agree it was biased i tried to do a NPO V check but i think i messed up thanks for fixing it phill Rekh

Closures

Is it universally acknowledged that Python does in fact have closures? The example, that intends to prove that it does in fact have them, seems a bit far fetched to me. I think could make a similar example in C++, using templates and function objects, and then say that C++ supports closures. Or surely in Java, perhaps with inner classes. Most people would agree that C++ or Java doesn't have closures. I think, that by closures, most people mean a language where "stack-frames" are saved on the heap, instead of on the stack. Personally, I think the python-way is the best, but I still don't think it's closures. Be proud of not having closures!

Closures don't have anything to do with whether you allocate call frames on the heap or the stack; they are about the behavior and lifetime of nested functions' namespaces. (It's a convenient implementation detail that heap-allocated frames allow closures more easily, but you find languages implementing closures both ways.)

The article's example is messy, and not close to anything you'd ever write in practice, but it is definitely using closures. It's hard to come up with good examples... the trouble with most of them, if they're not contrived to begin with, is that by virtue of having to be small and self-contained, they don't really get a chance to show the benefit of closures in reducing code size and complexity. Here's another try, though; a caching function wrapper:

def cached(func):
    cache = {}
    def wrapper(*args):
        if args not in cache:
            cache[args] = func(*args)
        return cache[args]
    return wrapper

class Cached(object):
    def __init__(self, func):
        self.func = func
        self.cache = {}
    def __call__(self, *args):
         if args not in self.cache:
             self.cache[args] = self.func(*args)
         return self.cache[args]

The first is the closure version; the second emulates it by mirroring the __init__ function's namespace to instance attributes. In practice, you find many such "association" objects in closure-less languages, existing merely to contain and associate state that was already contained and associated in the namespaces of the functions that defined them.

--Piet Delport 02:41, 29 December 2005 (UTC)

Piet Delport's example is an improvement. But I tend to think we could do without the exampe altogether. Basically just a couple sentences that say "Python supports closures, but their use requires mutable parameters, unlike in some more strongly functional languages". Then maybe a link to an external example in some Python tutorial or the like. We don't need to teach people to program Python here, just let them know what it is. So mentioning something exists is often sufficient, without necessarily teaching readers the details. Lulu of the Lotus-Eaters 03:32, 29 December 2005 (UTC)

I agree.

Minor issue: the phrase "their use requires mutable parameters" seems unclear to me. I assume you're talking about the limitation that Python doesn't allow changing the surrounding closure, only reading it (thus requiring indirect changes to mutable objects)? Two things are worth disambiguating: First, you don't require this workaround to use closures in Python; many (dare i say "most"?) use cases of closures only need to read the surrounding bindings. Second, the limitation is actually only a syntactical one: since the Python runtime is open/introspectable, you can change the surrounding closure directly using non-syntactical means. In other words, it's more accurate to say that Python does have full closure support, but doesn't (yet) have a syntax for changing the surrounding closure.

(This whole issue is a good example of Python's (sometimes overwhelmingly) strong focus on elegant syntax, by the way: until a good syntax is found for disambiguating local and outer (closure) variable assignments, the designers would rather keep the feature inaccessible, than let working, but "unpythonic" syntax leak into the language. (This is similar to the long-standing single-expression lambda limitation: the runtime doesn't even make any distinction between function objects created using "def" and "lambda", but the (current) syntax limits the latter to one expression.))

--Piet Delport 12:36, 31 December 2005 (UTC)

I removed the confusing and tangential example of closures deliberately. An anon put something back, but I feel strongly the article is better without it. Lulu of the Lotus-Eaters 05:07, 25 February 2006 (UTC)

How about Criticisims?

I was going to say there was missing a section on criticisms of the language, but I see the subject has already been raised, so I just want to add my support for the idea.

A while back I remember seeing something about flaws and experiments in the language that didn't work out well, and was specifically looking for that information. It's not in this article, and I think it should be.

—165.170.128.66

Please, please, please no! Not this article. Maybe some other article so as not to disrupt the flow of a fairly good page. Lulu of the Lotus-Eaters 23:44, 5 January 2006 (UTC)

I feel that a criticism section would further enhance the quality of this article.

As a page written by people who love the language, it's hard to even think of putting down criticisms (or give credance to the criticisms one sees raised), but if it is to be an ecyclopedia entry then maybe we should have a criticisms section. Maybe something on the lines of:

 Some Perl programmers think of Python as being to restrictive; some Ruby programmers complain about Pythons lack of 'blocks' and 'true closures'. Some Java programmers .... --Paddy 05:05, 13 September 2006 (UTC)

About the speed issue, the closest reference I see to the fact that "some people criticize Python as being too slow" is this phrase: "Python's design does not emphasize runtime speed." And this is in the "philosophy" section, which doesn't really present it as a criticism. Although I've been working in Python up till five minutes ago, I think it's worth having a brief section that explains weaknesses of the language, even if it means being a bit redundant in referring to Psyco and other solutions.

(Fantasizing) "If this code goes over 50 FPS, the python's armed..."

--Kris Schnee 06:36, 13 September 2006 (UTC)

Still no, no, no... a criticism section in a PL article is ugly and out of place, and reflects a seriously misguided misunderstanding of "balance". There are indeed some other PLs that have such sections, but always to the detriment of those articles... and a lot of PL articles that thankfully eschew them. A PL isn't a debate for political office. Just neutrally present the features and history of a PL, neither advocating or condemning the fact it has the features it does! LotLE×talk 05:25, 14 September 2006 (UTC)

Why such prominance for Python 3000?

I would have thought that Python 3000 would be peripheral to many reading the page . Personally I think of discussions about 'the next great jump' in a languages evolution to be very important to the developer, but of much less import to the average user , and maybe detrimental to the non-user. As i write, it is section 2.1 of around 30-odd sections. I think readers might get the idea that Python changes too much. Paddy3118 Sunday, 29 January 2006 05:34 (a.m.) GMT

If anything, what the section should be getting across is how little Python changes. In other words, "Python 3000" is not a list of changes, but a list of non-changes: features and design fixes that are generally agreed to be desireable, but are explicitly deferred to some indefinite time in the future in order to maximize the stability and backwards-compatibility of the current language.

With that said, i agree that the section should move toward the end of the article (if only for the chronological flow). --Piet Delport 13:22, 23 February 2006 (UTC)

Python 3000 is free to be started, analogous to for example Perl 6. This article can just mention it in relation to history, or have an overview section and link to more info. People shouldn't be discouraged to contribute just so that the article stays short enough. --TuukkaH 13:54, 23 February 2006 (UTC)

Perl 6, while moving slowly and not yet ready-for-primetime, has seen thousands of hours of development and documentation. Python 3000 is more a creature of fiction, general idea about what "might be nice" at some point in the future. So it seems unlikely that we could have much of an encyclopedic article on Python 3000 any time soon. That said, I think Paddy3118's comment still applies: the more we say about Python 3000 in this article, the more wrong the impression is given about its concreteness. The recently expanded bullet items about it are indeed good in writing clarity, but I worry that adding more words makes the plans seems more definite than they are. Lulu of the Lotus-Eaters 19:04, 23 February 2006 (UTC)

That comparison isn't entirely fair, because in contrast to Perl 6, Python 3000 is definitely not[1] a complete rewrite/redesign. It's also not nearly that fictional or "might be nice" indefinite: most of the changes are quite concretely slated for the 3.0 release.

But anyway, i don't think those things are the point. As i see it, the encyclopedic significance of "Python 3000" does not lie in whether it's a concrete version/release or not (we're not describing any other major feature releases, after all), but rather in that it's one of the more visible examples of Python's idiosyncratically conservative language design approach. That's not really enough to deserve its own article, but it certainly deserves a solid mention. --Piet Delport 01:03, 24 February 2006 (UTC)

On Portal:Free software, Python is currently the featured article

Just to let you know. The purpose of featuring an article is both to point readers to the article and to highlight it to potential contributors. It will remain the feature for a week or so. The previous feature was Berkeley Software Distribution. Gronky 15:43, 14 March 2006 (UTC)

qsort example. I don't understand how it could work.

Hello,

I'm under the impression that the qsort example is flawed somehow. Or is it me? The function extracts the pivot, then creates a list with all sorted elements smaller than the pivot, the pivot itself, then the qsorted elements larger or equal to the pivot. This will insert the pivot twice in the list (as it appears both as itself and in this second sublist,) if i'm not mistaken. --William Sauron 07:49, 18 March 2006 (UTC)

Afraid you're mistaken. Look again. pivot=L[0]. The stuff before and after the pivot is taken from L[1:]. So somthing that is equal to the pivot will get inserted at top, but pivot itself only goes in once. If it were not this way, what would happen when you sorted: [3,3,4,2,2,4,1,1,5,6]? Lulu of the Lotus-Eaters 18:30, 18 March 2006 (UTC)

Or empirically:

>>> def qsort(L):
...   if L == []: return []
...   pivot = L[0]
...   return qsort([x for x in L[1:] if x < pivot]) + [pivot] + \
...          qsort([y for y in L[1:] if y >= pivot])
... 
>>> l = [3,3,4,2,2,4,1,1,5,6]
>>> l2 = [3,3,4,2,2,4,1,1,5,6]
>>> l.sort()
>>> l
[1, 1, 2, 2, 3, 3, 4, 4, 5, 6]
>>> ll = qsort(l2)
>>> ll
[1, 1, 2, 2, 3, 3, 4, 4, 5, 6]

Lulu of the Lotus-Eaters 20:50, 18 March 2006 (UTC)

I was indeed mistaken, but now I see. I'm quite new to Python, but now at least I understand my error. For some reason the "el" and the "one" symbols have exactly the same glyph on my display so I didn't interpret L[1:] very well :-( Anyway, thanks and sorry again for the disturbance.

--William Sauron 09:03, 19 March 2006 (UTC)

Ambiguous whitespace "difficult to find"?

The article states: "Since they are not visually distinguishable (in many tools), mixing spaces and tabs can create bugs that are particularly difficult to find."

I think this is severely overstating the problem. Firstly, mixed indentation is only a potential problem if you edit with certain non-standard tab widths, and secondly, even then, all that's required to detect the problem is to run Python with the -t or -tt switches (which turn ambiguous whitespace into a warning and an error, respectively). In other words, they are trivial to find, and (in most cases) just as easy to automatically fix.

--Piet Delport 18:51, 24 March 2006 (UTC)

There is also reindent.py available in .../Tools/scripts/ that has algorithms for changing the indentation of Python scripts. Paddy3118 07:21 08 April 2006.

Problems with this article

I think this article overstates several problems that in truth don't occur among programs written in other languages.

I think "simple visual layout" is subjective, to say the least. The "misleading indention mistake" is a mistake that, perhaps a first-time user of C would make... writing his first program ;)

The statement that immutable strings imply run time efficiency is, in general, not true. The comment about having "vast support" for OOP is essentially useless. Don't just say "vast support", compare and constract with other OOP implementations: ObjC, Smalltalk, C++, etc

I also get the feeling from this article that it's primarily interested in conveying the "greatness" of python as opposed to facts.

--Jdavis79 10:45, 9 April 2006 (UTC)

Of course, when we start using "fuzzy" adjectives, it will always be more or less subjective. But it is also the strength of natural language. Regarding "layout", objectively, you would have hard time finding language that has simpler layout (for usual constructs, that is, minimalism in syntax is a different thing). Regarding "misleading indentation", Guido certainly wasn't first-time user of C when he started work on Python. Regarding "vast support for OOP", it's simply true - Python has everything any common OOP language has (even more, such as multiple inheritance). Anyway, I think that current consensus here is not to compare programming languages with each other in their respective articles, but to point to articles about the each feature, and compare the languages here (because the former means much more redundancy). If you're dissatisfied with my answer, though, what do you suggest to do with the article? Samohyl Jan 05:32, 10 April 2006 (UTC)

The "vast" sentence was awkward, and I rewrote it. The immutable string issue also needed some simplifications: it was too argumentative in both pros and cons; I believe my rephrasing is more plainly factual. I cannot see anything wrong after reading the description of misleading indentation in C: it's not just that highly experienced C users most certainly make these errors too (or else there wouldn't be an "obfuscated C contest", after all)... more importantly, the existing language is quite factual and neutral, unlike Jdavis79's retort. Lulu of the Lotus-Eaters 07:18, 10 April 2006 (UTC)

It is not neutral ;). This article speaks of components of the language being "very useful", how other features of the language turn a task into a "surprisingly straightforward and natural process", and various assertions about the "strengths" of python.. blasting the reader with how "great" it is. What's wrong with a simple "what it does" layout and let the reader, surprise, decide if the language is great, has particular strengths, etc? Just tell me how to iterate over a list.. just tell me that lists can be sliced.. don't tell me that and then follow it up by telling me how "awesome" such a feature is. Jdavis79 13:15, 10 April 2006 (UTC)

I am not able to find the word "awsome" in the article. Nor can I find "suprisingly straightforward". Nor "great". It's hard to respond to criticisms of the article for using phrases that a page search does not show as actually existing. There was a thread of sense in Jdavis79s first comment, however exaggerated its expression, but at this point s/he seems just to be inventing phrases that might someday occur in order to complain about them. I get the feeling that s/he's one of those odd editors with some sort of chip on his/her shoulder against the article subject (which I've seen in the oddest, and one would think non-controversial, subject areas). Lulu of the Lotus-Eaters 15:08, 10 April 2006 (UTC)

Is it possible for, say, an article to be hateful without actually containing the word "hate" ? That's just an example. The article does contain references to "strenghts", and how features enables tasks to be a "straightforward and natural process." You're right, it does not contain the word "awesome" but I would have thought that experienced editors would always keep one word constantly in mind: tone. The tone of this article is, I'd estimate, a amalgam of 4/5 factual information and 1/5 following up on how useful, clever, well-thought-out, idiot-proof, ingenious, canny, apt, cunning, yadd yadda yadd, those features are. Yes, it does not contain any of those words, but again, refer to concept of Tone.

Again, just state what the language DOES. What, exactly, is wrong with this? Just tell the reader how to do operations, the keywords involved, the history, don't follow it up with a biased tone of how ingenius those features are. I mean, look at the example of writing quicksort using list comprehensions as being "elegant." And whose opinion is this? Either get rid of all that superfluous stuff and stick to the NPOV facts or if you must inject that stuff, prefix or postfix it with some kind of warning.. "Some [language designers|programmers] consider this a useful feature." I mean, a C++ article could have a lame little example of computing an approximation of sqrt(n) using template metaprogramming with no function-call overhead.. all inline. Now, is that a C++ feature.. YES. Fact. Is it fast? clever? clear? straight-forward? useful? elegant? Opinion, Opinion, Opinion, Opinion, Opinion, Opinion. Depends on who you ask. Jdavis79 23:15, 10 April 2006 (UTC)

There is a point where slavish neutrality becomes obfuscation.

About the Quicksort wording: what do you find biased? You should know that the notion of "elegance" is (generally) quite widely agreed upon in mathematics and programming, and not nearly as frivolously subjective as you imply. Sure, the finer points of elegance are always being debated, but i don't think any competent programmer would consider the more conventional C/Java/whatever implementations of Quicksort more "elegant" than list comprehension-based implementations in languages like Python or Haskell.

Other than that, can you please list the sections that offend? --Piet Delport 00:00, 11 April 2006 (UTC)

I can't see anything worth addressing in Jdavis79's most recent comment. An encyclopedia article isn't a tutorial or reference text on a programming language—neither for Python nor for other programming languages. A lot more important than enumerating every keyword is giving readers a sense of what people say about a given languages, what people think of as its strengths or weaknesses, what advantages or disadvantages it has over other languages. Of course, that sort of thing can go too far and become advocacy (or condemnation), but a certain degree is highly desirable for an article. In fact, I have deliberately removed material that strayed too far in the tutorial direction (pointers to tutorials are fine, but not writing one here).

As Piet Delport observes, the quicksort example is a quite good illustration of the "feel" or "gestalt" of Python, and of how it contrasts with other somewhat similar languages. Likewise, the C++ article could well include a little bit on template metaprogramming, and why people care about that (or maybe that would be in a sister article, I don't edit over there; but the topic is worth discussing somewhere).

"Elegance" is one of the traits that most often lends an appeal to Python (versus other languages). For example, a current project I've just wrapped up is basically a Java job: the longtime Java programmer who runs the company frequently expresses a desire to do more in Python instead. There are good reasons why most of what he does (and I did recently on this project) needs to be in Java. This Java programmer (and others I've spoken with) don't prefer particularly because Python has multiple inheritance versus single; and they don't usually have any huge dislike of braces; and mostly they don't have any deep understanding of Python metaprogramming per se. The terms in which people usually express a preference for Python (among those who do, obviously it's not everyone who does so), is more often than not about it's greater "elegance"... it's not directly measurable, and it's not a keyword that can be enumerated, but it is what people/readers are interested in. Lulu of the Lotus-Eaters 01:16, 11 April 2006 (UTC)

Oh come on.. just because I say "tell me what the language does" you infer that I would in fact prefer the article on python to be little more than an enumeration of keywords and a listing of the Backus-Naur formalism for the language grammar? No. And, Yes. The C++ article should have a section on template meta programming. And this is how I would word it.. first, define template meta programming. Offer a small example.. say computing the approximation of sqrt(n). Stop. That's it. Done. Now, C++ programmers who don't know of this will immediately recognize its value, thinking to themselves, "hey, there's no function call overhead. That's useful." See? The article didn't have to explicitly say, "One extremely useful paradigm supported by C++ is..", the particular programmer that read it recognized it immediately as being useful in his toolbox of skills. Another programmer, say an embedded microcontroller programmer that uses C++ would probably not find such a feature useful because of ever-present space-efficiency constraints. Again.. the reader decided for himself. And other people, people that don't know any programming whatsoever.. why bother trying to explicitly explain the merits of this particular language feature to them? they don't know apples from oranges when it comes to that language anyway... send them to C++ for Non-programmers ;) Jdavis79 02:52, 11 April 2006 (UTC)

So in other words, an article section like Generic programming#Templates should definitely not lead with a comment like: "Templates are of great utility to programmers in C++"? And it definitely should not continue with something like: "The C++ Standard Template Library (STL) provides many useful functions within a framework of connected templates.", or still less "As the templates in C++ are very expressive they may be used for things other than generic programming."

Of course, I entirely disagree with criticism of any of these quite encyclopedic descriptions. I think the editors of the Generic programming article did a nice job (I hadn't read it until now)... as have the editors of the Python article (and likewise for other programming languages, those of which I've read all having analogous tones). Lulu of the Lotus-Eaters 03:44, 11 April 2006 (UTC)

Yes, I'd agree that this section needs a bit of tweaking. For example, it's not an implication that combining templates with multiple inheritance and operator overloading is always a "win win." At times it can make things worse. Thus, the article should probably reflect this: It's not a silver bullet. Also, it should probably say "The C++ Standard Template Library (STL) provides many commonly used constructs within a framework of connected templates." This conveys the point that is really trying to be made... the fact that the C++ STL has linked lists built in, it has arrays that can grow dynamically built in, it has associative arrays built in. But the most important fact here is that these constructs, the STL containers as they're called, are not "hardcoded" into the language compiler. No, they're compiled into your program just as if you'd written the code. Meaning, that if you write your own version of the STL linked list container.. say that is a singly linked list.. rather than a doubly linked list container like the C++ STL std::list<T> container.. the compiler makes no distinction whatsoever between your container the the container that comes bundled with the compiler. Is that useful? expressive? powerful? Let the reader decide. All the article has stated is fact. Jdavis79 04:09, 11 April 2006 (UTC)

Short circuit metaphor

I think "can" is probably OK language, better than simply "does short circuit". It's not optional in the sense of being a language switch or the like... but individual expressions may not be evaluated prior to the final term. E.g., I would call this a "short-circuit":

 2==3 and 1+1==2

But I would not call this a short-circuit (since the "circuit" needs to complete):

1+1==2 and 2==3

On the other hand, this one may short-circuit, but we don't know until runtime:

foo==bar and 2==3

Lulu of the Lotus-Eaters 03:21, 14 April 2006 (UTC)

As far as i understand it, "short-circuiting" refers to whether the language specifies/guarantees minimal evaluation or not; it doesn't have anything to do with whether any particular evaluation is actually smaller (or not) under short-circuiting/minimal evaluation (instead of full evaluation). In other words, in Python, all the evaluations above are short-circuiting, even though not all of them are actually shorter, as a result.

The reason i changed the language is that "can short-circuit" suggests that the behavior is not always guaranteed, and that you thus can't rely on it for things like if x in foo and foo[x] == bar: .... --Piet Delport 21:51, 14 April 2006 (UTC)

It's fine, I'm not going to change the words you put in. But the circuit metaphor suggests something fairly specific, which is an actual reduction of evaluation path, not just potential reduction for boolean operators. "Minimal evaluation" or "lazy evaluation" might be more precise terms, since they aren't quite so subject to the specific image/metaphor. Lulu of the Lotus-Eaters 00:42, 15 April 2006 (UTC)

I don't know; this is the first time i've seen "short-circuit" considered to suggest anything but minimal evaluation (potential evaluation reduction) in general. The term has always reminded me of "short-cut", which (to me) clearly implies only potential reduction (if, instead, it was always available, it would be the standard method, not a short-cut :). --Piet Delport 01:58, 15 April 2006 (UTC)

"Short-circuit evaluation" is a technical term in certain computer languages. I'm not sure, but I think it's in K&R -- it may have been used first to describe C, for all I know. It means precisely what is being described here: a small instance of lazy evaluation in the context of a not-usually-lazy language. It's not really any more of a metaphor than the term "lazy" is. --FOo 01:51, 15 April 2006 (UTC)

I don't know offhand whether K&R used the term, nor whether that was the first usage. But as well as the metaphor being fairly clear about excluding cases where no "circuit" is actually "shorted", it seems like a majority of technical uses I can find in a web search favor the more literal reading of the metaphor. A language feature, then, is "potential short-circuiting" (or the latest edit about "short-circuit semantics"). For example:

Short circuit evaluation refers to the condition where an expression is no longer evaluated since further evaluation cannot change the value of the expression.[2]

Opportunities for short-circuit evalution are apparent from the truth tables...[3]

A short-circuit evaluation of an expression is one in which the result is determined without evaluating all of the operands and/or operators.[4]

(P.S. To Fubar Obfusco: Do you know who I am, btw? Informing me that it's a "technical term" might not exactly be necessary or appropriate. E.g. search google for "short-circuit python": I wrote the third hit, and two others in the top ten). Lulu of the Lotus-Eaters 02:41, 15 April 2006 (UTC)

To my knowledge, as Fubar Obfusco has said, short circuiting always refers to the lazy evaluation of operators such as || in C. No expression of the form (X && Y), or in Python (X and Y), can be said to short circuit, because both X and Y must be fully evaluated in order to determine the truth of the entire expression. (Of course, if X and Y are complex expressions, they may themselves contain some operators which induce short-circuiting.) Cadr 15:41, 15 April 2006 (UTC)

No, no. Clearly short-circuiting can apply to the Python 'and' operator. The only question we're discussing is exactly what the scope and usage of the term "short-circuit" is. I argue both that most people do (as quoted), and that one generally should (because unfamiliar readers will), read the metaphor fairly flat-footedly. An example for 'and':

>>> def F():
...     print "False"
...     return False
... 
>>> def T():
...     print "True"
...     return True
... 
>>> if F() and T():
...     print "Truth is untruth"
... 
False
>>> if T() and F():
...     print "Truth is untruth"
... 
True
False

As I read the term, the first 'if' test short-circuited, but the second 'if' did not have the opportunity to do so (but we didn't know that until runtime). I am 100% in agreeement with Fubar Obfusco and Piet Delport about the actual behavior (and moreover, the Python shell proves it)... 'T()' does not ever evaluate in the first 'if' test above, but both 'T()' and 'F()' do evaluate in the second 'if' test. Lulu of the Lotus-Eaters 16:01, 15 April 2006 (UTC)

Yes, sorry, I was forgetting that 'and' could shortcircuit if the first operand is false. So I guess we are all in agreement, actually? Cadr 16:17, 15 April 2006 (UTC)

Design by contract

The article claims python supports Design by contract. The "Design by contract" article itself however only lists two external packages for python which are not part of the standard lib. I cannot see any native DbC support in python 2 either.

Article changed to reflect the fact that design by contract is supported through extensions to the langauge. --Chrismith 20:42, 22 April 2006 (UTC)

Removal of Perl/Ruby in See also section?

Why? Why can editors of Perl not allow such links? The See also section is left denuded.

If it turns out that the section cannot just be reverted then, at least a link to General-purpose dynamic languages should be added to the section. --Paddy 21:03, 1 May 2006 (UTC)

Some people objected to me adding a list of popular alternatives to Perl in the Perl article, so I wanted to be consistant in this article.

Feel free to add your dynamic languages link. I just added a link to Comparison of programming languages, which I just fixed up and will fix up further eventually. -Barry- 00:54, 2 May 2006 (UTC)

Decorators?

I wonder if we should try to include a discussion of decorators in this article. This isn't an article or tutorial on Python syntax, and as such we are certainly not exhaustive in explaining constructs. But the passing mention of metaprogramming via the __dict__ attribute made me think of the fact that decorators are probably the best choice for most metaprogramming jobs in the latest Python versions.

What do other editors think? Worth including or too esoteric? LotLE×talk 20:34, 22 May 2006 (UTC)

A discussion on decorators would probably be a little much for this article. However, the syntax section is getting a little long anyway - Python syntax, analogous to C syntax would have a place for an explanation about decorators. We'd leave a vastly trimmed-down version of what's there right now (indentation, statements, fundamental datatypes, interesting expressions (lambda, listcomps, etc) (maybe)). I've seen this proposed above once or twice, but I feel if we add any more syntactical nuances to the article it will be stretched too far, so the time is opportune. --Sam Pointon 20:42, 22 May 2006 (UTC)

I like that proposal. Want to start it, Sam Pointon? LotLE×talk 21:06, 22 May 2006 (UTC)

Nevermind. I decided to be bold, and started the suggested child myself. I started with a pretty aggressive cut-and-paste. Most likely, we'll want to move a little bit more back up from the child to the main article. But I like the look of only giving a general "feel-of-the-language" description in the main article, and let the actual syntax discussion go in the so-named child. LotLE×talk 21:18, 22 May 2006 (UTC)

Good going! --Piet Delport 10:26, 23 May 2006 (UTC)

Proposed Python 3 article merge

If there are no objections, i would like to merge Python 3 into this article. Could interested users please take a look at Talk:Python 3? --Piet Delport 22:30, 5 June 2006 (UTC)

Oppose merge. See Talk:Python 3 for explanation. LotLE×talk 02:01, 6 June 2006 (UTC)

In case other readers are interested: I responded to your concerns over there, and tried to explain my motivation a bit better. --Piet Delport 10:42, 6 June 2006 (UTC)

Exuberant?? and other strange philosophy.

In paragraph two of the philosophy section, the phrase "exuberant syntax" is uttered. This betrays, at least, a poor understanding of the word exuberant. Exuberant has very strong emotional connotations; Perl syntax does not run joyfully down a line of text. I don't really see how to get rid of it, but something like

"Python often provides features as built-in functions and extension modules rather than as additional syntax."

seems, to me, to be an improvement.

Also, IMHO(In my hostile opinion, in this case) in the preceding paragraph, "multi-paradigm language" verges on idiot speak. It appears to pervade the programming entries on wikipedia, so I again choose not to edit the actual entry, but "Python supports (list of 4 programming styles). Extensions like|such as|whatever pyDBC and Contracts for Python provide support for Design by Contract." is a pretty good replacement for the first several sentences of that paragraph. In the python box, the paradigm: multi-paradigm is especially rich. It provides no information what-so-ever. —Preceding unsigned comment added by Maxerickson (talk • contribs)

I entirely disagree with all these points. The phrase exuberant is widely used in Perl circles, and about Perl, so the contrast is informative. I presume, likewise that Exuberant Ctags also don't run joyfully in a literal sense; and yet that's the name (per common programming parlance) that the creators chose for the well-known project. For example, Dr. Dobb's Journal reviewing Beginning Perl, and uses the characterization.[5]

"Multi-paradigm" is likewise well-known and well-understood; moreover, the term is much more accurate and precise than is the awkward amalgm of examples Maxerickson suggests. For example, the term is discussed explicitly in the article Programming language. More importantly, Python's own website, and probably most third party descriptions of it use the "multi-paradigm" phrase.

I admit that a few of the terms used in describing Python might be unfamiliar to readers entirely unfamiliar with programming-language lingo. But most are either defined well enough contextually or wikilinked to appropriate places. Some such terms have slightly different usages or meanings outside of programming lingo. While being excessively jargonistic is bad, I don't believe this article does so, and eschewing all technical or subject-specific vocabulary to reach every member of the "great unwashed" is just as much a pitfall. LotLE×talk 01:54, 12 June 2006 (UTC)

If exuberant is used in the perl community, great. That doesn't really help it make any sense to somebody who has no sense of the perl community. It also means that it probably doesn't belong in a wikipedia article meant to inform about python.

The multi-paradigm stuff: I have no interest in swimming up hill; I prefer to just let the whole world be wrong. That said, it makes the article wordier without making it more informative. If my list is awkward, it probably shouldn't comprise the majority of that paragraph. I also disagree that a catch-all is in any way "precise".

I would love a pointer to 'multi-paradigm' on python.org. The first twenty hits on google for "site:python.org multi-paradigm" are mailing list archives. Getting rid of the dash doesn't help.

Sorry about not signing that last post...Maxerickson 00:55, 13 June 2006 (UTC)

Hmmm... I'm softening on the "multi-paradigm" usage. I'm sure that in the past the Python website used that description near the front page; but looking now, it's not there. General google search for "multi-paradigm python" shows lots of hits, but not quite "definitive". The "idiot-speak" degradation probably put me off a bit (especially since I probably use that characterization in my book on Python; and I'm sure my book-writing colleagues do). I guess we could be more explicit on what programming paradigms Python supports, if there is some unclarity there. LotLE×talk 01:10, 13 June 2006 (UTC)

Re-revisiting, I'm not sure what's to be done. I read the article text again, and it seems about as explicit as we might get. Multi-paradigm programming language is linked to a whole article that explains it. And the next sentence explicitly lists several supported paradigms (each linked to appropriate articles). That seems like a pretty good definition of what the term means. LotLE×talk 01:13, 13 June 2006 (UTC)

To clarify, it is idiot-speak because idiots have stripped paradigm of most of its value, not for some intrinsic reason. I've read some of your book and liked what I read(I've seen you post in c.l.python under Lulu... but didn't make the connection until you mentioned writing a book and clicked your user page link), even when it was over my head. The general thrust of my initial complaint is that using multi-paradigm anywhere in the entry requires explaining it somewhere in the entry, but doesn't really make the entry a great deal more informative. It stands up without ever mentioning paradigm at all. It also makes less sense as a philosophy section then, which I hadn't really thought about. Hmmm.Maxerickson 01:49, 13 June 2006 (UTC)

I think "paradigm" is actually "post-idiocy". There were a few years, maybe centered 5-7 years back, when the word was all the rage of businessese gibberish. But the idiots have moved on to trying to ruin other words, and we can use it as an actual word again (well, not that I ever stopped, but I recognized the peril). I mostly just think of Thomas Kuhn myself, though I recognize he hardly invented the word either. But we can hardly strip every word used by idiots from every serious article: we'd have to do some sort of global replace on "web-based", "portal", "large scale", "enterprise", "social network", and a bunch of stuff (I wouldn't really be sad to see "enabling" go)... probably some of which is used in this article. LotLE×talk 02:37, 13 June 2006 (UTC)

Proposal for Disambiguation

IMO we need a disambig. page for the animal and the programming language.

-- scott —Preceding unsigned comment added by 64.132.237.49 (talk • contribs)

There already is one: Python (disambiguation) --ozzmosis 16:41, 19 June 2006 (UTC)

Advance notice: I am planning on editing the External Links section

I am planning to remove a bunch of links from the External Links section based on Wikipedia's policy on External links (see External links). I don't want to remove all links, but I feel that the external links section is quite bloated and I would like to see it slimmed down a bit; Wikipedia is not meant to be a collection of outside links. In particular, I feel that links easily accessed from the python.org site do not need to be here. Similarly, links to python-related topics that may not be of general interest should be removed (I'm looking at you, "Python for Series 60 — Resources for developing in Python on the Nokia Series 60 mobile platform"). If you have a strong feeling about why a particular link should or should not be included, speak now. Please refer to the Wikipedia policy on external links in your arguments. Zukeeper 01:58, 13 July 2006 (UTC)

I agree. I have wanted to do the same, but didn't want to single out any one particular thing as uniquely "unworthy". I tend to think the few general tutorials and free books (i.e. that are not platform- or task-specific) are OK, especially if they are not on python.org. Nokia Series 60 is particularly egregiously over-specific, I concur. LotLE×talk 02:55, 13 July 2006 (UTC)