This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients docs@python, eli.bendersky, eric.araujo, eric.snow, ezio.melotti, georg.brandl, petere, terry.reedy
Date 2011-07-18.19:14:06
SpamBayes Score 9.113671e-11
Marked as misclassified No
Message-id <1311016448.14.0.493114570589.issue12531@psf.upfronthosting.co.za>
In-reply-to
Content
I would not propose to do everything in one grand patch as it would be way too much to review all at once. A somewhat separate subissue is whether there should be however many separate issues over the next however many years or one master issue with multiple patches.

The existing patch is enough to review for now. It needs changes and should add everything needed just for * and **. And there may be some unwritten policy issues.

I agree that the directive for * should be moved as Eli says.
I think 'statement' should be changed to 'function calls', or maybe 'in function calls' or 'function call operator' for both * and **.
The same directives should be added to the tutorial at the top and middle of Tutorial 4.7.4 Unpacking Argument Lists.
The existing * and ** 'statement' directives for defs in both tutorial and reference should become 'function defs' (or 'definitions') or 'in def statement'.
The existing * 'operator' directive should be 'number multiplication' or 'number multiplication operator' or at least 'number operator'.
Perhaps it (and the following) should be duplicated in the tutorial.
A new * 'sequence repetition* directive should be added.
The existing ** 'operator' directive should be 'number exponentiation'.
New 'assigment' and 'import' directives are needed.

I think *all* the entries for a given symbol should be considered together so that they can be properly differentiated. We should minimize duplicates that appear like this -- 'statement, [1]' -- and such duplicates should refer to the *same* usage. 

Policy issues:

I think 'statement' should be reserved for statement keywords like def, class, etc. Things in statements should be at least qualified as 'in <specific> statement.

I see that plain 'operator' is currently used for most or all operators. I think they should at least be qualified as to category -- number operator, seqeunce operator, comparision operator, logic operator, etc. This might tell users all they need to know and would separate overloaded operators like '*'.

Both general suggestions follow other usages. Classes are specified as 'class in <modname>', not just 'class'. Functions are specified not just with '()' but also 'in <modname>' Expanding 'statement' to 'in <keyword> statement' or something would be in the same spirit. Methods are specified as '<class> method', not just 'method'. Operators should get the same differentiation with at least '<optype> operator' if not more detail.

[separate issue note: 'as' seems not to be indexed.]

Adding Georg as I am suggesting a deviation from certain precedents (and conformance to others).
History
Date User Action Args
2011-07-18 19:14:08terry.reedysetrecipients: + terry.reedy, georg.brandl, ezio.melotti, eric.araujo, eli.bendersky, petere, docs@python, eric.snow
2011-07-18 19:14:08terry.reedysetmessageid: <1311016448.14.0.493114570589.issue12531@psf.upfronthosting.co.za>
2011-07-18 19:14:07terry.reedylinkissue12531 messages
2011-07-18 19:14:06terry.reedycreate