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
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
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