This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 | → | Archive 10 |
I have just created my first page on Doctest. Is there room for a link to it? -- Paddy 08:21, 14 December 2005 (UTC)
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
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 agree it was biased i tried to do a NPO V check but i think i messed up thanks for fixing it phill Rekh
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!
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]
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)
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.
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)
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)
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
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)
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)
>>> 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]
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)
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)
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)
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)
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)
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)
if x in foo and foo[x] == bar: ...
. --
Piet Delport
21:51, 14 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:
(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)
>>> 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
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.
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)
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)
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)
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)
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)
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)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 | → | Archive 10 |
I have just created my first page on Doctest. Is there room for a link to it? -- Paddy 08:21, 14 December 2005 (UTC)
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
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 agree it was biased i tried to do a NPO V check but i think i messed up thanks for fixing it phill Rekh
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!
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]
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)
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.
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)
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)
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
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)
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)
>>> 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]
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)
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)
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)
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)
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)
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)
if x in foo and foo[x] == bar: ...
. --
Piet Delport
21:51, 14 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:
(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)
>>> 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
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.
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)
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)
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)
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)
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)
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)