On Dec 13, 2010, at 2:16 PM, Guido van Rossum wrote:
> On Mon, Dec 13, 2010 at 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.
>
> Really? Have you observed this? Ev
Nick Coghlan 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
On Tue, 14 Dec 2010 10:20:04 +1000
Nick Coghlan 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 bugg
On Tue, Dec 14, 2010 at 5:39 AM, Mark Dickinson wrote:
> On Mon, Dec 13, 2010 at 3:51 PM, R. David Murray
> 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
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 clas
+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
_
On Tue, Dec 14, 2010 at 4:55 AM, Vinay Sajip wrote:
> Nick Coghlan 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 gr
On Tue, Dec 14, 2010 at 5:34 AM, Terry Reedy 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-f
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-
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 pa
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
On Mon, Dec 13, 2010 at 1:55 PM, Raymond Hettinger
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
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 d
On 12/13/2010 2:17 PM, Antoine Pitrou wrote:
On Mon, 13 Dec 2010 14:09:02 -0500
Alexander Belopolsky wrote:
On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossum 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 trail
On 13Dec2010 20:17, Antoine Pitrou wrote:
| On Mon, 13 Dec 2010 14:09:02 -0500
| Alexander Belopolsky wrote:
|
| > On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossum wrote:
| > > I'm at least +0 on
| > > allowing trailing commas in the situation the OP mentioned.
| > >
| >
| > FWIW, I am also
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 indentat
On Mon, Dec 13, 2010 at 3:51 PM, R. David Murray 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
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 12/13/2010 11:17 AM, Antoine Pitrou wrote:
On Mon, 13 Dec 2010 14:09:02 -0500
Alexander Belopolsky wrote:
On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossum 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 trail
On Mon, 13 Dec 2010 14:09:02 -0500
Alexander Belopolsky wrote:
> On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossum 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
> simi
On Mon, Dec 13, 2010 at 11:54 AM, Guido van Rossum 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 consis
Nick Coghlan 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
On Mon, Dec 13, 2010 at 5:42 AM, Tres Seaver 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
On Mon, 13 Dec 2010 23:25:58 +1000, Nick Coghlan wrote:
> On Mon, Dec 13, 2010 at 9:44 PM, Jan Kaliszewski 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
Tim Golden timgolden.me.uk> writes:
> > 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 :)
>
> Th
Nick Coghlan 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-
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 th
On Mon, Dec 13, 2010 at 11:42 PM, Tres Seaver 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
-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 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, *(
On 13/12/2010 13:25, Nick Coghlan wrote:
On Mon, Dec 13, 2010 at 9:44 PM, Jan Kaliszewski 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 li
On 13/12/2010 11:21, Nick Coghlan wrote:
On Mon, Dec 13, 2010 at 9:04 PM, Vinay Sajip wrote:
Tim Golden 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 y
On Mon, Dec 13, 2010 at 9:44 PM, Jan Kaliszewski 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 wo
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:04 PM, Vinay Sajip wrote:
> Tim Golden 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 :)
On Mon, Dec 13, 2010 at 8:58 PM, Vinay Sajip wrote:
> Nick Coghlan 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 f
Tim Golden 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
Nick Coghlan 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,
On Mon, Dec 13, 2010 at 8:31 PM, Vinay Sajip 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
>
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.pyth
K. Richard Pixley 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 Sat, Dec 11, 2010 at 6:20 AM, K. Richard Pixley 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__', '__st
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', 'func
42 matches
Mail list logo
