Talk:Python syntax and semantics/Archive 1

Archive 1

This page needs a better name

Very little of the page is syntax, it's almost entirely semantics. It needs a better name. Otherwise, it's well done. 165.189.91.148 21:15, 28 August 2006 (UTC)

Stupid examples

The example C function int foo() is missing a return statement. I assume this was supposed to be declared void foo(int x), and have corrected it. 202.89.153.166 09:35, 8 January 2007 (UTC)

List Comprehensions Out of date?

If i recall, the language was changed in a recent rev so that list comprehensions are no longer immediately expanded. --64.238.49.65 01:09, 3 March 2007 (UTC)

No, you're thinking of generator expressions. EdC 11:19, 3 March 2007 (UTC)

Scoping?

Can someone dedicate a section to scoping? Does Python use static or dynamic scoping, or some other kind? indil (talk) 05:40, 4 August 2008 (UTC)

EAFP

I'm getting really tired of people regurgitating the so-called EAFP style of programming. As far as I can tell, Alex Martelli came up with this one for Python in a Nutshell, and it has been widely quoted disseminated in spite of the fact that AFAIK there isn't a shred of evidence that EAFP actually increases readability. It probably does increase performance, but I don't think EAFP would be as widely cited if this were the only claimed benefit, and there isn't any evidence cited that it actually does increase performance. Given that readability is highly subjective anyway, I don't think the statement "EAFP increases readability" is verifiable. The tone of the section needs to be less POV for EAFP too. Mistercupcake (talk) 01:23, 10 August 2008 (UTC)

The perceived readability advantage of EAFP (i.e. using try/except rather than if/else) was certainly widely discussed on the Python newsgroup/mailing list long before Alex wrote his book. I do not know of any specific quantitative studies that provide any evidence (and doubt any exist), but the belief is pretty old and pretty widespread.

Actually, the advantage usually presented isn't really readability per se. It's more like the belief that programs structured with try/except promote better programming practice or a better way of conceptualizing the problem. That may lead to readability, but it comes from a bit different direction. LotLE×talk 01:32, 10 August 2008 (UTC)

EAFP does help when later Duck Typing as it promotes the use of less type/is-a checks and focuses on what can be done. --Paddy (talk) 10:30, 10 August 2008 (UTC)

"the whitespace thing"

QUOTE
The term "the whitespace thing" is commonly used in online discussion of the merits of block delimiter styles, e.g. "Python - Indentation/whitespace".; ""The Whitespace Thing" for OCaml".; "Proposal: Official whitespace response".
END OF QUOTE

None of the sources seems to be reliable. I would remove them from the article as well as statements they support unless reliable sources can be cited.
-- 17c (talk) 02:14, 7 February 2009 (UTC)

What sort of citation would you prefer to see for "common use in online discussions" than those very discussions where it is so used?! The sources presented aren't there mostly to discuss the third-party usage, but are direct examples of the usage (I could easily add hundreds of others, but picked a few as "typical").

I do, of course, know that (and why) secondary sources are preferred to primary ones (which one could argue those footnotes constitute). Unfortunately, for technical topics like this, primary sources are what we largely rely on, since there's not the sort secondary discussion there more often is for, e.g. political, artistic, literary, historical, etc. topics. For example, this very article has multiple citations to the actual Python.org website for various facts, even though that is also a primary source rather than secondary. LotLE×talk 02:33, 7 February 2009 (UTC)

I removed a {dubious} tag that looks WP:POINTy at best, disruptive at worst. It seems pretty much nonsensical to claim it is dubious that either "Python uses the off-side rule" or "this rule is sometimes called 'the whitespace thing'"... I honestly cannot discern any sensible meaning to the tag.

The most I can make sense of would be the claim that the phrase "whitespace thing" is insufficiently notable for the article. Or maybe the claim that mentioning it isn't an encyclopedic tone, but that seems like reaching. I confess that I used to see the phrase more often 5 years ago of so, in Python discussions, than I do nowadays. I'd like someone else to chime in on notability though. LotLE×talk 02:42, 7 February 2009 (UTC)

It seems to be jargon and not notable. Good sources are also missing. 17c (talk) 18:34, 9 February 2009 (UTC)

syntactic constructions

From the introduction:

[Python] has notably fewer syntactic constructions than other popular structured languages [...]

What does syntactic construction mean? Thanks, --Abdull (talk) 14:02, 18 September 2009 (UTC)

Fewer types of statements/expressions, I believe. For instance, it only has 7 keyword statements: if, for, while, try, class, def, with. No C-style for-loop, no do-while loop, etc. --Cybercobra (talk) 03:52, 19 September 2009 (UTC)

Not really true. There are also pass, yield, return, exec, print (granted, the last two have become functions in Python 3). Benwing (talk) 09:24, 5 July 2010 (UTC)

I think it refers to comparing something like the EBNF for Python and say Ruby or Java and finding that the graph for Python would have fewer nodes and edges. --Paddy (talk) 05:27, 6 July 2010 (UTC)

Or try this for pictures of the grammar of several languages including Python. —Preceding unsigned comment added by Paddy3118 (talk • contribs) 10:07, 6 July 2010 (UTC)

Dubious edit range in "‎Data structures"

http://en.wikipedia.org/enwiki/w/index.php?title=Python_syntax_and_semantics&diff=581045060&oldid=577309604
To me this addition seems dubious, poor quality, and it considerably lengthened what originally was a short introduction.
Note that this range of 11 revisions contains no less than 9 successive revisions by IP 123.123.254.234 within a very short time (followed by two external typo fixes since then (the latest one is from me)), see the article history.
I think those modifications should be reverted or at least "heavily reworked" (and maybe moved elsewhere). — Preceding unsigned comment added by 88.136.17.130 (talk) 15:09, 10 November 2013 (UTC)

Multi-line comments

Multi-line string literals can be used for comments, but I've never seen it outside of a formal docstring (i.e. as the first statement in a definition) or a hack (to block out code in an editor that doesn't support inserting #'s on multiple lines). The code example doesn't even compile. Robertwb (talk) 00:45, 23 September 2014 (UTC)

closure example needed

closure example needed —Preceding unsigned comment added by 150.101.166.15 (talk) 01:43, 15 February 2008 (UTC)

Added, using the example from Closure (computer science). EdC (talk) 00:23, 21 February 2008 (UTC)

Doesn't the example need to show the results of running foo(1, 2) (i.e. what gets printed) in order to make the point? Ma-Ma-Max Headroom (talk) 18:11, 28 September 2014 (UTC)

Indentation errors in C

I feel that this particular paragraph: "The following is an example of misleading indentation in C: [...] For example, the -gnatyx option perform style checks for Ada code in GNAT. Since the version 6, GCC supports a -Wmisaligned-indentation option which checks for consistency between grouping and indentation." is off-topic for a page named "Python syntax and semantics". Going into details of languages other than Python is not important here. Are you all fine to remove this text block to make this section more readable? Thanks and best greetings, PAB-global (talk) 10:34, 1 June 2016 (UTC)

Since I am not seeing any objections within 5 months, I will remove the above mentioned part of the text. PAB-global (talk) 16:28, 14 November 2016 (UTC)