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',
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__',
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',
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
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
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).
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
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
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
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,): ...
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
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
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
-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)
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:
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
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
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)
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
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
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
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
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.
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
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 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
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
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.
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
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
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
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
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
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
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
+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
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
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.
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
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
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
41 matches
Mail list logo
