[Python-Dev] logging doc broken
I'm not sure where to report this but the online doc appears to be mismatched to python-2.6.5 for the logging module. Specifically, for a dir of an instance of a LogRecord, I'm seeing: ['__doc__', '__init__', '__module__', '__str__', 'args', 'created', 'exc_info', 'exc_text', 'filename', 'funcName', 'getMessage', 'levelname', 'levelno', 'lineno', 'module', 'msecs', 'msg', 'name', 'pathname', 'process', 'processName', 'relativeCreated', 'thread', 'threadName'] while the documentation lists a different set of attributes including lvl. --rich ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
On Sat, Dec 11, 2010 at 6:20 AM, K. Richard Pixley r...@noir.com wrote: I'm not sure where to report this but the online doc appears to be mismatched to python-2.6.5 for the logging module. Specifically, for a dir of an instance of a LogRecord, I'm seeing: ['__doc__', '__init__', '__module__', '__str__', 'args', 'created', 'exc_info', 'exc_text', 'filename', 'funcName', 'getMessage', 'levelname', 'levelno', 'lineno', 'module', 'msecs', 'msg', 'name', 'pathname', 'process', 'processName', 'relativeCreated', 'thread', 'threadName'] while the documentation lists a different set of attributes including lvl. As discussed on this list recently, the logging documentation can unfortunately give the impression that the attributes of the log record are the same as the arguments to the log record constructor. This is not the case - the actual list of attributes can be found in the table showing the useful LogRecord attributes that are available to formatters (and filters) when processing records: http://docs.python.org/library/logging#formatter-objects Vinay is currently working on updates to the logging documentation, and this is one of the things that is likely to change (with the table of attributes moved to the LogRecord section and referenced from the sections on Formatter and Filter objects). Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
K. Richard Pixley rich at noir.com writes: I'm not sure where to report this but the online doc appears to be mismatched to python-2.6.5 for the logging module. Specifically, for a dir of an instance of a LogRecord, I'm seeing: ['__doc__', '__init__', '__module__', '__str__', 'args', 'created', 'exc_info', 'exc_text', 'filename', 'funcName', 'getMessage', 'levelname', 'levelno', 'lineno', 'module', 'msecs', 'msg', 'name', 'pathname', 'process', 'processName', 'relativeCreated', 'thread', 'threadName'] while the documentation lists a different set of attributes including lvl. Please report this on bugs.python.org. Check that you were referring to the 2.6 documentation - I didn't see any references to attributes there (following a quick scan). Ideally, link to the wrong doc section on docs.python.org in your bug report. Thanks, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
On 13/12/2010 10:31, Vinay Sajip wrote: [...] Ideally, link to the wrong doc section on docs.python.org in your bug report. Now that's not a piece of advice you see very often :) TJG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
On Mon, Dec 13, 2010 at 8:31 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Please report this on bugs.python.org. Check that you were referring to the 2.6 documentation - I didn't see any references to attributes there (following a quick scan). Ideally, link to the wrong doc section on docs.python.org in your bug report. The reference to lvl makes me think this is the same mistake I made the other day (i.e. thinking the constructor parameters are also the LogRecord attributes) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
Nick Coghlan ncoghlan at gmail.com writes:
Vinay is currently working on updates to the logging documentation,
and this is one of the things that is likely to change (with the table
of attributes moved to the LogRecord section and referenced from the
sections on Formatter and Filter objects).
Yes, and to compound matters, the LogRecord constructor documentation lists the
attribute values in the place you'd expect the parameters to appear, using the
doc markup for attributes. This I think is what causes the confusion, although
the markup is different to that used for parameters it's not clear at first
glance.
However, these changes are after 2.7 and 3.1: In 2.6 documentation the
parameters are named as in the source, but there's no reference in the
LogRecord reference documentation about any attributes of the LogRecord.
Perhaps it would be best to do the following:
- Add constructor params using normal parameter markup (:param:)
- Create a separate section LogRecord Attributes with a table containing attr
name, description, how to use with % formatting and how to use with
{}-formatting. There is some overlap here with the parameter documentation for
the LogRecord constructor, but I can put in a rider which explains that the
param names and attr names are slightly different. (I could kick myself now for
not being more scrupulous originally, but I'm not sure I can go back and change
the param names in the source code now because in theory, someone might be
constructing a LogRecord using LogRecord(**kwargs)).
- Link to the latter section from the Formatter, Filter sections.
Anyone see problems with this, or have a better suggestion?
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
Tim Golden mail at timgolden.me.uk writes: On 13/12/2010 10:31, Vinay Sajip wrote: [...] Ideally, link to the wrong doc section on docs.python.org in your bug report. Now that's not a piece of advice you see very often :) True, but this area changed after 2.6 was released (after even 2.7, IIRC), so I want to be sure that if I'm going to change the doc sources on release26-maint, I'm doing the right thing. The 2.6 docs seem consistent with the 2.6 code, and while confusing (because the distinction between constructor param names and attr names is not spelled out), I don't see 2.6 docs as broken (or at least, I don't see where the breakage is). Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
On Mon, Dec 13, 2010 at 8:58 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
Vinay is currently working on updates to the logging documentation,
and this is one of the things that is likely to change (with the table
of attributes moved to the LogRecord section and referenced from the
sections on Formatter and Filter objects).
Yes, and to compound matters, the LogRecord constructor documentation lists
the
attribute values in the place you'd expect the parameters to appear, using the
doc markup for attributes. This I think is what causes the confusion, although
the markup is different to that used for parameters it's not clear at first
glance.
However, these changes are after 2.7 and 3.1: In 2.6 documentation the
parameters are named as in the source, but there's no reference in the
LogRecord reference documentation about any attributes of the LogRecord.
That's the problem though - if you don't read the intro paragraph
closely (which I didn't do), it's easy to jump to the conclusion that
those are also the attributes (since there is nothing else in the
section).
Perhaps it would be best to do the following:
- Add constructor params using normal parameter markup (:param:)
- Create a separate section LogRecord Attributes with a table containing
attr
name, description, how to use with % formatting and how to use with
{}-formatting. There is some overlap here with the parameter documentation for
the LogRecord constructor, but I can put in a rider which explains that the
param names and attr names are slightly different. (I could kick myself now
for
not being more scrupulous originally, but I'm not sure I can go back and
change
the param names in the source code now because in theory, someone might be
constructing a LogRecord using LogRecord(**kwargs)).
- Link to the latter section from the Formatter, Filter sections.
Anyone see problems with this, or have a better suggestion?
Yep, that's what I had assumed you were going to do (this did come up
in the big thread about the logging docs, but you may have missed it).
You're also right about the backwards compatibility problem with
changing the parameter names. It's the one downside of keyword
arguments - it makes the parameter names part of a function's public
API, so they are much harder to fix when you make a mistake.
That said, you can't get a one-to-one correspondence in this case
anyway, since some of the parameters relate to multiple attributes
(e.g. lvl becomes both levelNo and levelName).
It is rare that anyone will be constructing a LogRecord manually
though, so I don't think the parameter names matter all that much in
practice. It is far more common that people will be creating them
implicitly through the Logger event notification methods or by
deserialising them.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
On Mon, Dec 13, 2010 at 9:04 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Tim Golden mail at timgolden.me.uk writes: On 13/12/2010 10:31, Vinay Sajip wrote: [...] Ideally, link to the wrong doc section on docs.python.org in your bug report. Now that's not a piece of advice you see very often :) True, but this area changed after 2.6 was released (after even 2.7, IIRC), so I want to be sure that if I'm going to change the doc sources on release26-maint, I'm doing the right thing. It was more a comment on the fact that, at first glance, that sentence looks like an instuction to provide an incorrect link, rather than to provide a link to the section of the docs that is incorrect. Just a quirk of English grammar :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
Dear Python Developers, It is s my first post to python-dev, so let me introduce myself briefly: Jan Kaliszewski, programmer and composer, sometimes also NGO activist. Coming to the matter... The discussion started with remark by Mark Dickinson about such a syntax oddity: def f(a, b,): ... is fine, but def f(*, a, b,): ... is a SyntaxError Then some other similar oddities were pointed at (*args/**kwargs-related ones as well as calls like f(*, a=3,) causing SyntaxError too). References: * http://mail.python.org/pipermail/python-dev/2010-July/101636.html * http://bugs.python.org/issue9232 * http://bugs.python.org/issue10682 But yesterday both mentioned issues has been closed as rejected -- with suggestion that it would probably require a PEP to modify Python in this aspect (as there is no clear consensus). So I'd opt for re-opening the discussion -- I suppose that more people could be interested in solving the issue (at least after the end of PEP 3003 moratorium period). I think that seeing that: def f(a, b): ... def f(a, b,): ... def f(a, *, b): ... def f(a, *args, b): ... x(1, 2, 3, 4, z=5) x(1, 2, 3, 4, z=5,) x(1, *(2,3,4), z=5) ...are ok, then -- def f(a, *, b,): ... def f(a, *args, b,): ... x(1, *(2,3,4), z=5,): ... ...should be ok as well, and consequently -- def f(a, *args,): ... def f(a, **kwargs,): ... x(1, *(2,3,4),) x(1, **dict(z=6),) ...should also be ok. Please also note that Py3k's function annotations make one-def-argument- -per-line formattig style the most suitable in some cases, e.g.: def my_func( spam:Very tasty and nutritious piece of food, ham:For experts only, *more_spam:Not less tasty and not less nutritious!, spammish_inquisition:Nobody expects this!, ) - Spam, spam, spam, spam, spam, spam, spam, spam, spam, spam: ... Regards, Jan Kaliszewski ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On Mon, Dec 13, 2010 at 9:44 PM, Jan Kaliszewski z...@chopin.edu.pl wrote: I think that seeing that: def f(a, b): ... def f(a, *, b): ... def f(a, *args, b): ... x(1, 2, 3, 4, z=5) x(1, *(2,3,4), z=5) As per the closure of the affected tickets, the likely outcome of such a discussion would be the deprecation and subsequent removal of support for the following two options: def f(a, b,): ... x(1, 2, 3, 4, z=5,): ... Function arguments are not lists. Even when separated onto multiple lines, the closing ): should remain on the final line with other content. That would be a lot of hassle to get rid of something that people probably aren't doing in the first place, though. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
On 13/12/2010 11:21, Nick Coghlan wrote: On Mon, Dec 13, 2010 at 9:04 PM, Vinay Sajipvinay_sa...@yahoo.co.uk wrote: Tim Goldenmailat timgolden.me.uk writes: On 13/12/2010 10:31, Vinay Sajip wrote: [...] Ideally, link to the wrong doc section on docs.python.org in your bug report. Now that's not a piece of advice you see very often :) True, but this area changed after 2.6 was released (after even 2.7, IIRC), so I want to be sure that if I'm going to change the doc sources on release26-maint, I'm doing the right thing. It was more a comment on the fact that, at first glance, that sentence looks like an instuction to provide an incorrect link, rather than to provide a link to the section of the docs that is incorrect. Just a quirk of English grammar :) Thanks, Nick. That is what I meant. I wanted to indicate that it was tongue-in-cheek, but I never can remember the sequence of characters which means that... TJG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On 13/12/2010 13:25, Nick Coghlan wrote: On Mon, Dec 13, 2010 at 9:44 PM, Jan Kaliszewskiz...@chopin.edu.pl wrote: I think that seeing that: def f(a, b): ... def f(a, *, b): ... def f(a, *args, b): ... x(1, 2, 3, 4, z=5) x(1, *(2,3,4), z=5) As per the closure of the affected tickets, the likely outcome of such a discussion would be the deprecation and subsequent removal of support for the following two options: def f(a, b,): ... x(1, 2, 3, 4, z=5,): ... Function arguments are not lists. Even when separated onto multiple lines, the closing ): should remain on the final line with other content. Why? For very long signatures I still mildly prefer this: def f(self, first, second, third, fourth, foo=None, bar=None, baz=None, spam=None, eggs=None, ham=None ): Over putting the closing paren: on the last line of the def. Of course not having such long signatures is even more preferable, but *sometimes* they are needed. All the best, Michael Foord That would be a lot of hassle to get rid of something that people probably aren't doing in the first place, though. Regards, Nick. -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/13/2010 08:25 AM, Nick Coghlan wrote: On Mon, Dec 13, 2010 at 9:44 PM, Jan Kaliszewski z...@chopin.edu.pl wrote: I think that seeing that: def f(a, b): ... def f(a, *, b): ... def f(a, *args, b): ... x(1, 2, 3, 4, z=5) x(1, *(2,3,4), z=5) As per the closure of the affected tickets, the likely outcome of such a discussion would be the deprecation and subsequent removal of support for the following two options: def f(a, b,): ... x(1, 2, 3, 4, z=5,): ... Function arguments are not lists. Even when separated onto multiple lines, the closing ): should remain on the final line with other content. That would be a lot of hassle to get rid of something that people probably aren't doing in the first place, though. I actually make use of the feature when dealing with APIs which both a) take lots of arguments (more than fit comfortably on two lines at whatever indentation they are called), and b) have optional trailing arguments: I always leave the trailing comma in place in such cases, with the closing paren on the following line, so that adding or removing an argument at the end of the list stays consistent (the diffs are better, too, when I use this pattern). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0GIsoACgkQ+gerLs4ltQ5HLwCfYFSyVrFtt04h6a39hyK6BD2c t8oAoJdXNS7wIsjF34ZiOQCwQGq9Qs2v =ZWqW -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On Mon, Dec 13, 2010 at 11:42 PM, Tres Seaver tsea...@palladion.com wrote: I actually make use of the feature when dealing with APIs which both a) take lots of arguments (more than fit comfortably on two lines at whatever indentation they are called), and b) have optional trailing arguments: I always leave the trailing comma in place in such cases, with the closing paren on the following line, so that adding or removing an argument at the end of the list stays consistent (the diffs are better, too, when I use this pattern). My personal preferences aren't strong either way, but the issues were closed because committers voiced opinions against making this consistent in the other direction (i.e. always allowing the trailing comma). I don't know that a full PEP is really needed, but the status quo is that some committers said no and others don't really care about the issue all that much, so the current behaviour is going to remain in place unless those in the first group change their mind (or Guido weighs in and says change it). Creating a PEP is one way to carry out such persuasion (probably overkill though). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
Nick Coghlan dixit (2010-12-13, 23:25): Function arguments are not lists. Even when separated onto multiple lines, the closing ): should remain on the final line with other content. Not necessarily, IMHO. 1. What about my example with '- xxx' return-value annotation? (especially when that annotation is a long expression) 2. There are two argument-list-formatting idioms I apply -- depending on which is more suitable in a particular case: a) when argument specs/expressions are not very long and rather if their number is not very big: def function(argument_spec1, argument_spec2, argument_spec3, argument_spec4, argument_spec5, argument_spec6): function_call(expression1, expression2, expression3, expression4, expression5, expression6) b) for long argument lists and/or argument specs/expressions (e.g. when default values or argument annotations are defined as long expressions): def function( long_argument_spec1, long_argument_spec2, long_argument_spec3, long_argument_spec4, long_argument_spec5, long_argument_spec6, ): function_call( long_expression1, long_expression2, long_expression3, long_expression4, long_expression5, long_expression6, ) Note that option 'b' is more convenient for refactorization, diffs etc. Regards, *j ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
Nick Coghlan ncoghlan at gmail.com writes: Yep, that's what I had assumed you were going to do (this did come up in the big thread about the logging docs, but you may have missed it). I hadn't missed it - I'm just spelling out in more detail what I'm going to do. That said, you can't get a one-to-one correspondence in this case anyway, since some of the parameters relate to multiple attributes (e.g. lvl becomes both levelNo and levelName). It is rare that anyone will be constructing a LogRecord manually though, so I don't think the parameter names matter all that much in practice. It is far more common that people will be creating them implicitly through the Logger event notification methods or by deserialising them. I agree, it's a pretty unlikely scenario. Of course, I do make use of the parameter names in the dictConfig approach, so I can't really complain. I should hopefully remember this when I'm writing out a method or function signature for a public API :-) Regards, Vinay ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On Mon, 13 Dec 2010 23:25:58 +1000, Nick Coghlan ncogh...@gmail.com wrote: On Mon, Dec 13, 2010 at 9:44 PM, Jan Kaliszewski z...@chopin.edu.pl wrote: I think that seeing that: =A0 =A0def f(a, b): ... =A0 =A0def f(a, *, b): ... =A0 =A0def f(a, *args, b): ... =A0 =A0x(1, 2, 3, 4, z=3D5) =A0 =A0x(1, *(2,3,4), z=3D5) As per the closure of the affected tickets, the likely outcome of such a discussion would be the deprecation and subsequent removal of support for the following two options: def f(a, b,): ... x(1, 2, 3, 4, z=3D5,): ... Function arguments are not lists. Even when separated onto multiple lines, the closing ): should remain on the final line with other content. That would be a lot of hassle to get rid of something that people probably aren't doing in the first place, though. Counter examples from google code search: http://www.google.com/codesearch/p?hl=en#copo3dCwf5E/django/utils/simplejson/encoder.pyq=^\s*\):sa=Ncd=5ct=rc (also appears in json in the stdlib) http://www.google.com/codesearch/p?hl=en#algXCqBNNP0/vendor/python-clientform/ClientForm.pyq=^\ *\):sa=Ncd=3ct=rc (class def) http://www.google.com/codesearch/p?hl=en#KT-ZlRkUunU/trunk/code/output/ExprParser.pyq=def\(.*,\s\):sa=Ncd=2ct=rc http://www.google.com/codesearch/p?hl=en#XnG7n8Mjf2s/GoogleSearch.pyq=def\(.*,\s\):sa=Ncd=3ct=rc http://www.google.com/codesearch/p?hl=en#MokQ50OeeyU/src/python/ndogen/parser/matlab/parser.pyq=def\(.*,\s\):sa=Ncd=5ct=rc Not many, granted, but not zero, either, and I'm sure there are lots more out there[*]. I do especially like the fact that there is one in the stdlib :) It seems like the status quo is fine. I wouldn't object to it being made more consistent. I would object to removing the existing cases. -- R. David Murray www.bitdance.com [*] code search's response to various regexes was somewhat surprising; expressions I thought should have been supersets resulted in fewer hits. Nor could I think of a way to search for function invocations ending with a comma. Then again, I usually make lots of mistakes with regexes. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On Mon, Dec 13, 2010 at 5:42 AM, Tres Seaver tsea...@palladion.com wrote: I actually make use of the feature when dealing with APIs which both a) take lots of arguments (more than fit comfortably on two lines at whatever indentation they are called), and b) have optional trailing arguments: I always leave the trailing comma in place in such cases, with the closing paren on the following line, so that adding or removing an argument at the end of the list stays consistent (the diffs are better, too, when I use this pattern). Same here, and it's a soft style rule at Google that trailing commas are good -- they can help produce shorter diffs. I'm at least +0 on allowing trailing commas in the situation the OP mentioned. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
Nick Coghlan ncoghlan at gmail.com writes: Yep, that's what I had assumed you were going to do (this did come up in the big thread about the logging docs, but you may have missed it). Ok, I've now checked in this change, and would be grateful for any feedback. Time for a break :-) Thanks a lot for all your patience and valuable feedback, Nick. It's been very helpful, and I hope it will make the logging docs more accessible to those who've been put off in the past. I've emailed Georg about how best to reorganise into: intro + basic tutorial (at current location) advanced tutorial reference cookbook and I'm waiting for his suggestions on how best to implement (in terms of breaking up into different files etc). Thanks and regards, Vinay ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossum gu...@python.org wrote: I'm at least +0 on allowing trailing commas in the situation the OP mentioned. FWIW, I am also about +0.5 on allowing trailing comma. Note that in a similar situation, the C standardization committee has erred on the side of consistency: A new feature of C99: a common extension in many implementations allows a trailing comma after the list of enumeration constants. The Committee decided to adopt this feature as an innocuous extension that mirrors the trailing commas allowed in initializers. http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf Similarly, I find allowing trailing comma in keyword only arguments lists to be an innocuous extension that mirrors the trailing commas allowed in the positional arguments lists. A possible benefit that I have not seen mentioned is that if developer decides to convert some of the trailing arguments in her function to keyword only, she does not have to worry about removing the trailing comma. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On Mon, 13 Dec 2010 14:09:02 -0500 Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossum gu...@python.org wrote: I'm at least +0 on allowing trailing commas in the situation the OP mentioned. FWIW, I am also about +0.5 on allowing trailing comma. Note that in a similar situation, the C standardization committee has erred on the side of consistency: A new feature of C99: a common extension in many implementations allows a trailing comma after the list of enumeration constants. The Committee decided to adopt this feature as an innocuous extension that mirrors the trailing commas allowed in initializers. http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf Similarly, I find allowing trailing comma in keyword only arguments lists to be an innocuous extension that mirrors the trailing commas allowed in the positional arguments lists. +1 from me as well. Special cases are hard to remember. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On 12/13/2010 11:17 AM, Antoine Pitrou wrote: On Mon, 13 Dec 2010 14:09:02 -0500 Alexander Belopolskyalexander.belopol...@gmail.com wrote: On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossumgu...@python.org wrote: I'm at least +0 on allowing trailing commas in the situation the OP mentioned. FWIW, I am also about +0.5 on allowing trailing comma. Note that in a similar situation, the C standardization committee has erred on the side of consistency: A new feature of C99: a common extension in many implementations allows a trailing comma after the list of enumeration constants. The Committee decided to adopt this feature as an innocuous extension that mirrors the trailing commas allowed in initializers. http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf Similarly, I find allowing trailing comma in keyword only arguments lists to be an innocuous extension that mirrors the trailing commas allowed in the positional arguments lists. +1 from me as well. Special cases are hard to remember. +1. I tend to put them in, and then take out the ones that Python won't accept. Then, when I add another item to the list, Python tells me to go back and put the one I took out back in again, and take out the one I put in at the new end of the list. Annoying. (for vertically arranged lists, one per line, primarily, with ) on the last line by itself. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
On 12/13/2010 6:04 AM, Vinay Sajip wrote: True, but this area changed after 2.6 was released (after even 2.7, IIRC), so I want to be sure that if I'm going to change the doc sources on release26-maint, 2.6 is in security-fix only mode. I am not sure if that precludes doc fixes, on the chance that there will ever be a security fix, as it does non-security bug fixes, but is it hardly worth the bother compared to improving active releases. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On Mon, Dec 13, 2010 at 3:51 PM, R. David Murray rdmur...@bitdance.com wrote: It seems like the status quo is fine. I wouldn't object to it being made more consistent. I would object to removing the existing cases. Same here, on all three counts. In one of the projects I'm currently working on, we've settled on a style that does quite a lot of: my_thing = Thing( foo = Foo(arg1, arg2, ...), bar = Bar(arg3, arg4, ...), ... ) and I've found the trailing comma very convenient during refactoring and API experimentation. (There's still good fun to be had arguing about the indentation of that closing parenthesis, though.) Mar ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On 12/13/2010 11:39 AM, Mark Dickinson wrote:
my_thing = Thing(
foo = Foo(arg1, arg2, ...),
bar = Bar(arg3, arg4, ...),
...
)
and I've found the trailing comma very convenient during refactoring
and API experimentation. (There's still good fun to be had arguing
about the indentation of that closing parenthesis, though.)
Clearly it needs to be indented one level, because it is a continuation
of the prior line, just like the foo and bar and ... lines are
continuations and therefore indented.
I'd have argued differently for languages that use {} to delimit blocks.
Enjoy!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On 13Dec2010 20:17, Antoine Pitrou solip...@pitrou.net wrote: | On Mon, 13 Dec 2010 14:09:02 -0500 | Alexander Belopolsky alexander.belopol...@gmail.com wrote: | | On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossum gu...@python.org wrote: | I'm at least +0 on | allowing trailing commas in the situation the OP mentioned. | | | FWIW, I am also about +0.5 on allowing trailing comma. Note that in a | similar situation, the C standardization committee has erred on the | side of consistency: | | | A new feature of C99: a common extension in many implementations | allows a trailing comma after the list of enumeration constants. The | Committee decided to adopt this feature as an innocuous extension that | mirrors the trailing commas allowed in initializers. | http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf | | Similarly, I find allowing trailing comma in keyword only arguments | lists to be an innocuous extension that mirrors the trailing commas | allowed in the positional arguments lists. | | +1 from me as well. Special cases are hard to remember. +1 again. Both the special cases and probably an example of diff friendliness: x = f(a, b=3, ##c=4, hacking at dev time d=5) Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ A Master is someone who started before you did. - Gary Zukav ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On 12/13/2010 2:17 PM, Antoine Pitrou wrote: On Mon, 13 Dec 2010 14:09:02 -0500 Alexander Belopolskyalexander.belopol...@gmail.com wrote: On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossumgu...@python.org wrote: I'm at least +0 on allowing trailing commas in the situation the OP mentioned. FWIW, I am also about +0.5 on allowing trailing comma. Note that in a similar situation, the C standardization committee has erred on the side of consistency: A new feature of C99: a common extension in many implementations allows a trailing comma after the list of enumeration constants. The Committee decided to adopt this feature as an innocuous extension that mirrors the trailing commas allowed in initializers. http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf Similarly, I find allowing trailing comma in keyword only arguments lists to be an innocuous extension that mirrors the trailing commas allowed in the positional arguments lists. +1 from me as well. Special cases are hard to remember. Same here. A strong +1 for a consistent rule (always or never allowed) with a +1 for always given others use case of one param/arg per line. So I think the issues should be reopened. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On Dec 13, 2010, at 1:21 PM, Terry Reedy wrote: Same here. A strong +1 for a consistent rule (always or never allowed) with a +1 for always given others use case of one param/arg per line. It seems to me that a trailing comma in an argument list is more likely to be a user error than a deliberate comma-for-the-future. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On Mon, Dec 13, 2010 at 1:55 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Dec 13, 2010, at 1:21 PM, Terry Reedy wrote: Same here. A strong +1 for a consistent rule (always or never allowed) with a +1 for always given others use case of one param/arg per line. It seems to me that a trailing comma in an argument list is more likely to be a user error than a deliberate comma-for-the-future. Really? Have you observed this? Even if it was inserted by mistake, it is harmless. Python has a long tradition of allowing redundant trailing commas in comma-separated lists, and it is habit-forming. That's the issue the OP had: he expected it to work in the one context where it doesn't. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] configparser 1.1 - one last bug fix needed
Hi there.
There's one last thing that needs to be done with configparser for 3.2.
Raymond, Fred, Michael and Georg already expressed their approval on that so
unless anybody finds a flaw in the idea expressed below, I'm going to make
the change for 3.2b2:
- the ConfigParser class will be removed
- the SafeConfigParser class will be renamed to ConfigParser
- 2to3 will rename SafeConfigParser classes to ConfigParser
- 2to3 will warn on the subtle behaviour change when ConfigParser classes
are found
What's the difference?
--
Both ConfigParser and SafeConfigParser implement interpolation, e.g. option
values can contain special tokens similar to those implemented by Python's
string formatting: %(example)s. These tokens are replaced during get()
operations by values from respective keys (either from the current section
or from the DEFAULT section).
SafeConfigParser was originally introduced to fix a couple of ConfigParser
problems:
- when a token didn't match the %(name)s syntax, it was simply treated as
a raw value. This caused configuration errors like %var or %(no_closing_s)
to be missed.
- if someone actually wanted to store arbitrary strings in values, including
Python formatting strings, there was no way to escape %(name)s in the
configuration. The programmer had to know in advance that some value may
hold %(name)s and only get() values from that option using
get('section', 'option', raw=True)
Then however, that option could not use interpolation anymore.
- set() originally allowed to store non-string values in the parser. This
was not meant to be a feature and caused trouble when the user tried to
save the configuration to a file or get the stored values back using typed
get() methods.
SafeConfigParser solves these problems by validating interpolation syntax
(only %(name)s or %% are allowed, the latter being an escaped percent sign)
and raising exceptions on syntax errors, and validating type on set()
operations so that no non-string values can be passed to the parser using
the API.
Why change that?
When ConfigParser was left alone, it remained the default choice for most
end users, including our own distutils and logging libs. This was a very
weak choice, and most current ConfigParser users are not aware of the
interpolation quirks. I had to close a couple of issues related to people
trying to store non-string values internally in the parser.
The current situation needlessly complicates the documentation. Explaining
all the above quirks to each new user who only wants to parse an INI file is
weak at best. Moreover, users trust Python to do the right thing by default
and according to their intuition. In this case, going for the default
configparser.ConfigParser class without consulting the documentation is
clearly a suboptimal choice.
One last argument is that SafeConfigParser is an awkward name. It implicates
the other parsers are somehow unsafe, or that this specific parser protects
users from something. This is generally considered a naming antipattern.
When?
-
You might ask whether this can be done for 3.2 (e.g. is that a feature or
a bugfix). In Raymond's words, the beta process should be used to flesh out
the APIs, test whether they work as expected and fix suboptimal decisions
before we hit the release candidate stage. He consideres this essentially
a bugfix and I agree.
You might ask why do that now and not for 3.3. We believe that 3.2 is the
last possible moment of introducing a change like that. The adoption rate is
currently still low and application authors porting projects from 2.x expect
incompatibilities. When they are non-issues, handled by 2to3, there's
nothing to be afraid of.
But isn't that... INCOMPATIBLE?!
Yes, it is. Thanks to the low py3k adoption rate now's the only moment where
there's marginal risk of introducing silent incompatibility (there are
hardly any py3k projects out there). Projects ported from Python 2.x will be
informed by 2to3 of the change. We believe that this will fix more bugs than
it introduces.
Support for bare % signs would be the single case where ConfigParser might
have appeared a more natural solution. In those cases we expect that users
will rather choose to turn off interpolation whatsoever.
Summary
---
If you have any strong, justified arguments against this bugfix, speak up.
Otherwise the change will be made on Thursday.
--
Interpolating regards,
Łukasz Langa
tel. +48 791 080 144
WWW http://lukasz.langa.pl/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using logging in the stdlib and its unit tests
On 07/12/2010 20:26, Vinay Sajip wrote: I would suggest that when unit testing, rather than adding StreamHandlers to log to stderr, that something like TestHandler and Matcher from this post: http://plumberjack.blogspot.com/2010/09/unit-testing-and-logging.html For Python 2, my testfixtures package has had some helpful bits in this area for a while now: http://packages.python.org/testfixtures/logging.html I find it important to be able to check my code is logging what I think it should be logging! cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On 12/13/2010 1:55 PM, Raymond Hettinger wrote: It seems to me that a trailing comma in an argument list is more likely to be a user error than a deliberate comma-for-the-future. It seems to me that a trailing comma, especially in the case of one parameter per line, is a deliberate comma-for-the-future. It's a good reminder that you are dealing with a list of some sort, rather than a statement, when you look at just one parameter on the line. Especially if the ) is on the next line, which I prefer. Yes, a parameter list is not a python list, nor a python tuple, but it is still a generic, comma-separated list, and all such are more conveniently dealt with, in the multi-line case, if trailing commas are permitted. And, of course, the one-entry tuple needs the comma to differentiate it from some other expression, forcing the trailing comma into the syntax... so there can be no consistent rule for all commas that doesn't permit trailing commas. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
On Tue, Dec 14, 2010 at 5:34 AM, Terry Reedy tjre...@udel.edu wrote: On 12/13/2010 6:04 AM, Vinay Sajip wrote: True, but this area changed after 2.6 was released (after even 2.7, IIRC), so I want to be sure that if I'm going to change the doc sources on release26-maint, 2.6 is in security-fix only mode. I am not sure if that precludes doc fixes, on the chance that there will ever be a security fix, as it does non-security bug fixes, but is it hardly worth the bother compared to improving active releases. Fixing it in the 2.7 maintenance branch will be sufficient to modify docs.python.org, which is likely the most important place to update. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
On Tue, Dec 14, 2010 at 4:55 AM, Vinay Sajip vinay_sa...@yahoo.co.ukwrote: Nick Coghlan ncoghlan at gmail.com writes: Yep, that's what I had assumed you were going to do (this did come up in the big thread about the logging docs, but you may have missed it). Ok, I've now checked in this change, and would be grateful for any feedback. Time for a break :-) Hmm, that may not have built correctly, since it isn't showing up in the web version of the dev docs yet. I skimmed the diff on python-checkins though, and it looked good to me. I think the revised docs should make it *much* easier for people to get a handle on how the logging system works (I know my own understanding of it is significantly better than it was a couple of weeks ago). Cheers, Nick. P.S. I'm off visiting family for a couple of weeks, so my email access is going to be sketchy for a while. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] configparser 1.1 - one last bug fix needed
+1 from me. If anyone complains too much, perhaps we can offer to retain the old ConfigParser as _BuggyConfigParser? (that idea is only partially tongue-in-cheek...) Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] configparser 1.1 - one last bug fix needed
Wiadomość napisana przez Nick Coghlan w dniu 2010-12-14, o godz. 01:20: +1 from me. If anyone complains too much, perhaps we can offer to retain the old ConfigParser as _BuggyConfigParser? (that idea is only partially tongue-in-cheek...) We may leave the LegacyInterpolation class if someone *really* needs to support that. That way RawConfigParser(interpolation=LegacyInterpolation()) is effectively the old ConfigParser. -- Nondeprecatorily yours, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On Tue, Dec 14, 2010 at 5:39 AM, Mark Dickinson dicki...@gmail.com wrote: On Mon, Dec 13, 2010 at 3:51 PM, R. David Murray rdmur...@bitdance.com wrote: It seems like the status quo is fine. I wouldn't object to it being made more consistent. I would object to removing the existing cases. Same here, on all three counts. In one of the projects I'm currently working on, we've settled on a style that does quite a lot of: my_thing = Thing( foo = Foo(arg1, arg2, ...), bar = Bar(arg3, arg4, ...), ... ) and I've found the trailing comma very convenient during refactoring and API experimentation. (There's still good fun to be had arguing about the indentation of that closing parenthesis, though.) Another valid use case that occurred to me is building up a string-keyed dictionary: mapping = dict( x=1, y=2, z=3, ) So, on reflection, removing the existing cases where it is supported is certainly unreasonable, which makes the consistency argument that much stronger. For the record, I reopened issue #9232 (noting the lack of consensus), and (as someone suggested on the tracker) changed the resolution on the other one to be as a duplicate of #9232. Cheers, Nick. P.S. As I noted in the logging discussion, my email access is going to be a bit sketchy for the next couple of weeks. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] configparser 1.1 - one last bug fix needed
On Tue, 14 Dec 2010 10:20:04 +1000 Nick Coghlan ncogh...@gmail.com wrote: +1 from me. If anyone complains too much, perhaps we can offer to retain the old ConfigParser as _BuggyConfigParser? (that idea is only partially tongue-in-cheek...) Or we can put it in the buggy module which receives all buggy code. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] logging doc broken
Nick Coghlan ncoghlan at gmail.com writes: Hmm, that may not have built correctly, since it isn't showing up in the web version of the dev docs yet. I skimmed the diff on python-checkins though, and it looked good to me. I'll keep an eye on the build (built OK on my machine but I'm not sure what the build trigger is for docs.python.org). I think the revised docs should make it *much* easier for people to get a handle on how the logging system works (I know my own understanding of it is significantly better than it was a couple of weeks ago). Glad to hear that. P.S. I'm off visiting family for a couple of weeks, so my email access is going to be sketchy for a while. Have a nice time, and thanks for all the help. Regards, Vinay ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists -- continuation
On Dec 13, 2010, at 2:16 PM, Guido van Rossum wrote: On Mon, Dec 13, 2010 at 1:55 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: It seems to me that a trailing comma in an argument list is more likely to be a user error than a deliberate comma-for-the-future. Really? Have you observed this? Even if it was inserted by mistake, it is harmless. I only have one data point, my own mistakes. The SyntaxError has occasionally been helpful to me when working out a function signature or to detect a copy and paste error. In both cases, it meant that there was supposed to be another argument and it had been either forgotten or mispasted. Also, if I were reviewing someone else's code and saw a trailing comma in a function definition, it would seem weird and I would wonder if the author intended a different signature. FWIW, this isn't important to me at all. Was just noting my own experience. Don't put assign much weight to it, I don't have much of a preference either way. Python has a long tradition of allowing redundant trailing commas in comma-separated lists, and it is habit-forming. Right. I see that in the wild quite often and use it myself. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
