James Y Knight wrote:
> I'm resending a message I sent in June, since it seems the same thread
> has come up again, and I don't believe anybody actually responded
> (positively or negatively) to the suggestion back then.
>
> http://mail.python.org/pipermail/python-dev/2009-June/090176.html
>
> On
On Tue, Sep 29, 2009 at 10:04 PM, James Y Knight wrote:
> It'd possibly be helpful if there were builtin objects which forced the
> format style to be either newstyle or oldstyle, independent of whether % or
> format was called on it.
>
> E.g.
> x = newstyle_formatstr("{} {} {}")
> x % (1,2,3) ==
On Wed, Sep 30, 2009 at 1:44 AM, Nick Coghlan wrote:
> Martin v. Löwis wrote:
>>> I would say that there certainly are precedents in other areas for
>>> keeping the information about the input form around. For example,
>>> occasionally it would be handy if parsing a hex integer returned an
>>> obj
2009/9/30 Greg Ewing :
> Paul Moore wrote:
>>
>> I'd rather argparse (or any library function)
>> didn't call sys.exit on my behalf - it should raise an exception.
>
> Actually, sys.exit() *does* raise an exception (i.e.
> SystemExit) that you can catch if you want.
That's a good point...
Paul
___
2009/9/30 Steven Bethard :
> On Tue, Sep 29, 2009 at 10:04 PM, James Y Knight wrote:
>> It'd possibly be helpful if there were builtin objects which forced the
>> format style to be either newstyle or oldstyle, independent of whether % or
>> format was called on it.
> So I understand how this migh
2009/9/30 Mark Dickinson :
> Please could someone who understands the uses of IPNetwork better than
> I do explain why the following wouldn't be a significant problem, if __eq__
> and __hash__ were modified to disregard the .ip attribute as suggested:
>
linus = IPv4Network('172.16.200.1/24')
>
On Wed, Sep 30, 2009 at 10:52 AM, Paul Moore wrote:
> 2009/9/30 Mark Dickinson :
>> Please could someone who understands the uses of IPNetwork better than
>> I do explain why the following wouldn't be a significant problem, if __eq__
>> and __hash__ were modified to disregard the .ip attribute as
Martin v. Löwis wrote:
Steven Bethard wrote:
There's a lot of code already out there (in the standard library and
other places) that uses %-style formatting, when in Python 3.0 we
should be encouraging {}-style formatting.
I don't agree that we should do that. I see nothing wrong with using
%
On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan wrote:
> Mark Dickinson wrote:
>> Okay, so maybe this is an abuse of IPv4Network. But I'd (mis?)understood
>> that the retention of the .ip attribute was precisely a convenience to allow
>> this sort of use. If not, then what's it for? I've read th
Mark Dickinson writes:
> >> Please could someone who understands the uses of IPNetwork
> >> better than I do explain why the following wouldn't be a
> >> significant problem, if __eq__ and __hash__ were modified to
> >> disregard the .ip attribute as suggested:
> > linus = IPv4Network('1
>> It's been awhile since I rebuilt Python and ran the test suite. This
>> evening I noticed this on my Mac (OS X 10.5):
Sorry, trunk.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Un
On Sep 29, 2009, at 11:15 PM, Martin v. Löwis wrote:
I would propose that the format argument gets an argument name,
according to the syntax it is written in. For PEP 3101 format,
I would call the argument "format" (like the method name of the
string type), i.e.
logging.Formatter(
format="{asc
2009/9/30 Barry Warsaw :
> Although I hate the name 'dicttemplate', this seems like the best solution
> to me. Maybe it's good that 'dicttemplate' is so ugly though so that people
> will naturally prefer 'format' :). But I like this because there's not
> really any magic, it's explicit, and the d
On Sep 30, 2009, at 12:29 AM, Ned Deily wrote:
In my opinion, the standard python.org OS X installer for 2.6.3 now
"works well" on 10.4, 10.5, and 10.6 and is ready for release.
Fantastic, thanks. Martin's uploaded the Windows binaries so I'll
make the announcement now. No commits to the 2
The first (and hopefully last) release candidate for Python 2.6.3 is
now available via
http://www.python.org/download/releases/2.6.3/
Source releases and Windows binaries are currently available, and Mac
OS X binaries should be forthcoming.
Nearly 100 bugs have been fixed since 2.6.2. Bar
I'm planning to "officially" drop support for Python 1.5.2 in the logging
package.
When the logging package was introduced in Python 2.3, many Linux distros were
shipping 1.5.2 as the system's Python, even though 2.2 had been out for a
while. So it seemed important to support 1.5.2 for those sysad
Le Wed, 30 Sep 2009 13:27:41 +, Vinay Sajip a écrit :
> I'm planning to "officially" drop support for Python 1.5.2 in the
> logging package.
Thanks for the announcement.
So, what is the minimum supported version now?
Regards
Antoine.
___
Python-D
On Wed, 30 Sep 2009 at 13:27, Vinay Sajip wrote:
I'm planning to "officially" drop support for Python 1.5.2 in the logging
package.
What's the minimum version of Python that the logging module now officially
supports?
--David (RDM)
___
Python-Dev mai
s...@pobox.com wrote:
Dino> For IronPython we wrote a set of tests which go through and define
Dino> the various operator methods in all sorts of combinations on both
Dino> new-style and old-style classes as well as subclasses of those
Dino> classes and then do the comparisons w/
Frank Wierzbicki wrote:
Talk has started up again on the stdlib-sig list about finding a core
stdlib + tests that can be shared by all implementations, potentially
living apart from CPython. I have volunteered to put together a PEP
on the subject, with Jessie Noller and Brett Canon are helping m
Antoine Pitrou pitrou.net> writes:
> So, what is the minimum supported version now?
Well, each version is tested with the release of Python which it's part of, and
in theory it would be possible for the code in logging for that release to use
features only available in that release of Python. So
On Wed, 30 Sep 2009 03:04:05 pm James Y Knight wrote:
> It'd possibly be helpful if there were builtin objects which forced
> the format style to be either newstyle or oldstyle, independent of
> whether % or format was called on it.
>
> E.g.
> x = newstyle_formatstr("{} {} {}")
> x % (1,2,3) == x.
Chris Withers simplistix.co.uk> writes:
>
> I'm on on stdlib-sig and I'm afraid I don't have the bandwidth to start
> on it, but I'd just like to throw in (yet again) that it would be great
> if the stdlib was actually a set of separate python packages with their
> own version metadata so that
Antoine Pitrou wrote:
This sounds like a bad idea to me. Each Python release is tested and debugged as
a whole. If you have a lot of possible combinations (module A version 1.1 with
module B version 1.2, etc.), it becomes impossible for us to ensure proper QA
for the whole and as a result the qua
P.J. Eby wrote:
Here's what actually happened, if anyone cares. Tarek and friends
announced a fork of setuptools. I reviewed the work and saw that -- for
the most part -- I was happy with it, and opined as how I might be
willing to bless the the "package inquisition" team as official
maintai
Antoine Pitrou wrote:
As far as I'm concerned, anything which looks intuitive enough (e.g. ini-style)
and not overly complicated is fine. The details of the syntax aren't really
important as long as they make sense, and don't get in the way.
This is a variant of "as simple as possible and requi
On Wed, Sep 30, 2009 at 9:28 AM, Chris Withers wrote:
> Frank Wierzbicki wrote:
>>
>> Talk has started up again on the stdlib-sig list about finding a core
>> stdlib + tests that can be shared by all implementations, potentially
>> living apart from CPython.
>
[...]
>
> if the
> stdlib was actuall
On Wed, Sep 30, 2009 at 5:21 AM, Barry Warsaw wrote:
> On Sep 29, 2009, at 11:15 PM, Martin v. Löwis wrote:
>
>> I would propose that the format argument gets an argument name,
>> according to the syntax it is written in. For PEP 3101 format,
>> I would call the argument "format" (like the method
On Sep 30, 2009, at 11:22 AM, Steven Bethard wrote:
On Wed, Sep 30, 2009 at 5:21 AM, Barry Warsaw
wrote:
On Sep 29, 2009, at 11:15 PM, Martin v. Löwis wrote:
I would propose that the format argument gets an argument name,
according to the syntax it is written in. For PEP 3101 format,
I woul
On Wed, Sep 30, 2009 at 9:43 AM, Antoine Pitrou wrote:
> Chris Withers simplistix.co.uk> writes:
>>
>> I'm on on stdlib-sig and I'm afraid I don't have the bandwidth to start
>> on it, but I'd just like to throw in (yet again) that it would be great
>> if the stdlib was actually a set of separate
On Wed, Sep 30, 2009 at 8:31 AM, Barry Warsaw wrote:
> On Sep 30, 2009, at 11:22 AM, Steven Bethard wrote:
>> On Wed, Sep 30, 2009 at 5:21 AM, Barry Warsaw wrote:
>>> On Sep 29, 2009, at 11:15 PM, Martin v. Löwis wrote:
I would propose that the format argument gets an argument name,
acc
On Sep 30, 2009, at 11:39 AM, Steven Bethard wrote:
Thanks for the clarification. I generally like this approach, though
it's not so convenient for argparse which already takes format strings
like this::
parser = ArgumentParser(usage='%(prog)s [--foo]')
parser.add_argument(
'--foo'
On Wed, Sep 30, 2009 at 10:37 AM, Olemis Lang wrote:
> On Wed, Sep 30, 2009 at 9:43 AM, Antoine Pitrou wrote:
>> Chris Withers simplistix.co.uk> writes:
>>>
[...]
>
> For instance, I have started something like that has been dome by the
> FLiOOPS project [1]_
Sorry for the missing reference an
On Wed, 30 Sep 2009 at 10:52, Paul Moore wrote:
2009/9/30 Mark Dickinson :
Please could someone who understands the uses of IPNetwork better than
I do explain why the following wouldn't be a significant problem, if __eq__
and __hash__ were modified to disregard the .ip attribute as suggested:
Yuvgoog Greenle gmail.com> writes:
>
+1 for adding argparse and eventually deprecating optparse, -0 for deprecating
getopt.
> 2. Big modules - 1 uber-module for each subject that does everything. Maybe
logging is an example of this.
I'm not sure that it is, if you mean code size. In Python 2.5,
On Sep 30, 2009, at 10:34 AM, Steven D'Aprano wrote:
E.g.
x = newstyle_formatstr("{} {} {}")
x % (1,2,3) == x.format(1,2,3) == "1 2 3"
Moving along, let's suppose the newstyle_formatstr is introduced.
What's
the intention then? Do we go through the std lib and replace every
call
to (say)
Brett Cannon python.org> writes:
> Obviously if one of the getopt supporters has a better way of doing
> this then please speak up.
I'm not a getopt supporter per se - I'm +1 for argparse - but Opster provides
some nice syntax sugar on top of getopt, and can be seen here:
http://blogg.ingspree.
The positional parameter would also mean dicttemplate, and
would be deprecated (eventually requiring a keyword-only
parameter).
Although I hate the name 'dicttemplate', this seems like the best solution
to me. Maybe it's good that 'dicttemplate' is so ugly though so that people
will naturally
Mark Dickinson wrote:
On Wed, Sep 30, 2009 at 1:44 AM, Nick Coghlan wrote:
Please could someone who understands the uses of IPNetwork better than
I do explain why the following wouldn't be a significant problem, if __eq__
and __hash__ were modified to disregard the .ip attribute as suggested:
On a tangent -- a use case that I see happening frequently but which
is pretty poorly supported by optparse is a command-line that has a
bunch of general flags, then a 'subcommand name', and then more flags,
specific to the subcommand. Most here are probably familiar with this
pattern from SVN, Hg,
On 2009-09-29 18:38 PM, Steven Bethard wrote:
I don't really use GUI libraries, so I wouldn't be able to come up
with such an example. I'd also rather not make API changes based on
speculative use cases, so before I spend time documenting these
things, I'd really like to hear from someone who ha
>>> There's a lot of code already out there (in the standard library and
>>> other places) that uses %-style formatting, when in Python 3.0 we
>>> should be encouraging {}-style formatting.
>>
>> I don't agree that we should do that. I see nothing wrong with using
>> % substitution.
>
> It's a ma
James Y Knight wrote:
> allow users to use newstyle string substitution with every API.
However it is done, I think someone (like new Python programmers) should
be able to program in Python3, and use everything in the stdlib, without
ever learning % formatting -- and that I should be able to fo
> Although I hate the name 'dicttemplate', this seems like the best
> solution to me. Maybe it's good that 'dicttemplate' is so ugly though
> so that people will naturally prefer 'format' :). But I like this
> because there's not really any magic, it's explicit, and the decision is
> made by the
On 2009-09-30 11:38 AM, Guido van Rossum wrote:
On a tangent -- a use case that I see happening frequently but which
is pretty poorly supported by optparse is a command-line that has a
bunch of general flags, then a 'subcommand name', and then more flags,
specific to the subcommand. Most here are
James Y Knight fuhm.net> writes:
>
> The user could write either:
> logging.Formatter("%(asctime)s - %(name)s - %(level)s - %(msg)s")
> (as always -- that can't be changed without a long deprecation
> period), or:
> logging.Formatter(newstyle_formatstr("{asctime} - {name} - {level} -
> {msg}"
[Terry Reedy]
However it is done, I think someone (like new Python programmers) should
be able to program in Python3, and use everything in the stdlib, without
ever learning % formatting -- and that I should be able to forget about
it ;-).
+10 on the goal.
If that were possible, it would b
On Wed, Sep 30, 2009 at 8:50 AM, Barry Warsaw wrote:
> On Sep 30, 2009, at 11:39 AM, Steven Bethard wrote:
>
>> Thanks for the clarification. I generally like this approach, though
>> it's not so convenient for argparse which already takes format strings
>> like this::
>>
>> parser = ArgumentPar
On Wed, Sep 30, 2009 at 9:48 AM, "Martin v. Löwis" wrote:
>> I'd note that PEP 3101 calls str.format() a replacement for
>> %-formatting, not an alternate mechanism to achieve the same end.
>
> I think this is a mis-wording; the intent of the PEP apparently is
> to propose this mechanism as an opt
> PEP 291 (Backward Compatibility for Standard Library) mentions logging as
> having
> 1.5.2 compatibility, and I'm thinking that it can be removed from that PEP
> altogether.
Done!
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
On Sep 30, 2009, at 12:58 PM, Robert Kern wrote:
I don't think argparse supports the "foo --help subcommand" OOB. I
think it would be simple to modify argparse to make it do so. It
does support general options followed by a subcommand with options,
though.
Right. I've made it kind of wor
On Sep 30, 2009, at 1:01 PM, Antoine Pitrou wrote:
Why not allow logging.Formatter to take a callable, which would in
turn call the
callable with keyword arguments?
Therefore, you could write:
logging.Formatter("{asctime} - {name} - {level} - {msg}".format)
This is a very interesting idea
On Wed, Sep 30, 2009 at 09:21, Vinay Sajip wrote:
> Brett Cannon python.org> writes:
>
>> Obviously if one of the getopt supporters has a better way of doing
>> this then please speak up.
>
> I'm not a getopt supporter per se - I'm +1 for argparse - but Opster provides
> some nice syntax sugar on
2.6.3rc1 builds fine on Linux x86/x86_64, MacOSX 10.4 ppc/x86, Windows
32bit/64bit, HP-UX, AIX and Solaris just like 2.6.2 did.
-srid
On Wed, 30 Sep 2009 05:34:02 -0700, Barry Warsaw wrote:
On Sep 30, 2009, at 12:29 AM, Ned Deily wrote:
In my opinion, the standard python.org OS X installe
On Sep 30, 2009, at 3:36 PM, Sridhar Ratnakumar wrote:
2.6.3rc1 builds fine on Linux x86/x86_64, MacOSX 10.4 ppc/x86,
Windows 32bit/64bit, HP-UX, AIX and Solaris just like 2.6.2 did.
Thanks for the feedback! Did you run the test suite on any of these?
-Barry
PGP.sig
Description: This is
[Sridhar Ratnakumar]
2.6.3rc1 builds fine on Linux x86/x86_64, MacOSX 10.4 ppc/x86, Windows
32bit/64bit, HP-UX, AIX and Solaris just like 2.6.2 did.
Did the test suite pass too?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
On Wed, 30 Sep 2009 12:44:14 -0700, Barry Warsaw wrote:
2.6.3rc1 builds fine on Linux x86/x86_64, MacOSX 10.4 ppc/x86, Windows
32bit/64bit, HP-UX, AIX and Solaris just like 2.6.2 did.
Thanks for the feedback! Did you run the test suite on any of these?
I will run the tests sometime tonight
On Wed, Sep 30, 2009 at 4:33 AM, Mark Dickinson wrote:
> On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan wrote:
>> Mark Dickinson wrote:
>>> Okay, so maybe this is an abuse of IPv4Network. But I'd (mis?)understood
>>> that the retention of the .ip attribute was precisely a convenience to allow
>>
On Wed, 30 Sep 2009 at 13:11, Guido van Rossum wrote:
On Wed, Sep 30, 2009 at 4:33 AM, Mark Dickinson wrote:
On Wed, Sep 30, 2009 at 12:06 PM, Nick Coghlan wrote:
Mark Dickinson wrote:
Okay, so maybe this is an abuse of IPv4Network. ?But I'd (mis?)understood
that the retention of the .ip att
On Wed, Sep 30, 2009 at 02:22:53PM -0400, Barry Warsaw wrote:
>
> Right. I've made it kind of work in Mailman 3, but it would be nice for
> argparse to support this out of the box. Note that I think you want two
> forms:
>
> foo help subcommand
> foo subcommand --help
>
> to basically print the
On 2009-09-30 15:17 PM, Andrew McNabb wrote:
On Wed, Sep 30, 2009 at 02:22:53PM -0400, Barry Warsaw wrote:
Right. I've made it kind of work in Mailman 3, but it would be nice for
argparse to support this out of the box. Note that I think you want two
forms:
foo help subcommand
foo subcommand
I like how python has a minimalistic and powerful syntax (-1 for the break
___ PEP).
Also, I really dislike the for/else ambiguity "butterflies".
When is the else after a loop executed?1. When the loop isn't entered at
all.
2. When the loop terminates through exhaustion of the list (does this
inclu
Yuvgoog Greenle wrote:
I like how python has a minimalistic and powerful syntax (-1 for the
break ___ PEP).
Also, I really dislike the for/else ambiguity "butterflies".
When is the else after a loop executed?
1. When the loop isn't entered at all.
If you mean because the list / iterator is emp
Brett Cannon python.org> writes:
> I am reluctant to jump on these argument parsing decorators until they
> have existed outside the standard library for a while and have settled
> down as I suspect some people want to use annotations to do type
> conversion/checking, others don't, etc.
>
I agr
> I don't know -- this is (from what Peter told me) a common use case so
> he (and presumably others) would from time to time have to write
> extra code to keep track of that IP address in a new app.
I, and probably others, would really, REALLY like to see one such
"common use case". I do find it
On Wed, Sep 30, 2009 at 1:17 PM, Andrew McNabb wrote:
> >From my cursory reading of the documentation, it looks like argparse can
> only add subparsers for subcommands. Is there any way to add subparsers
> based on options instead (as iptables does)?
Currently this is not supported, but it would
Steven Bethard wrote:
> So I understand how this might help a user to move from %-style
> formatting to {}-style formatting, but it's still not clear to me how
> to use this to evolve an API. In particular, if the goal is for the
> API to move from accepting %-style format strings to {}-style forma
[...@google.com]
this is what I wrote:
it's not so much a need as it is useful. it's useful to take an
address like 192.168.1.100/24 and derive a bunch of information from
it (like the network address, broadcast address, containing supernets,
etc), but still remember that the original address wa
I don't know -- this is (from what Peter told me) a common use case so
he (and presumably others) would from time to time have to write
extra code to keep track of that IP address in a new app.
[MvL]
I, and probably others, would really, REALLY like to see one such
"common use case". I do fi
[...@google.com]
On Wed, Sep 30, 2009 at 2:51 PM, Raymond Hettinger wrote:
>
>>> I don't know -- this is (from what Peter told me) a common use case so
>>> he (and presumably others) would from time to time have to write
>>> extra code to keep track of that IP address in a new app.
>
> [MvL]
>>
.On Wed, Sep 30, 2009 at 3:33 PM, R. David Murray wrote:
>1) do not add another class, just pass around (IPvXAddress,
>IPVXNetwork) tuples when the address needs to be retained (or write
>your own tailored trivial class, like I did in my example).
>
I've been puzzled by objections to
Barry Warsaw writes:
> The first (and hopefully last) release candidate for Python 2.6.3 is
> now available
[…]
Thank you for this announcement, and the efforts that go into making
this work available.
*Especially* thank you for avoiding the oxymoronic “Released: 2.6.3
release candidate” or sim
On Wed, Sep 30, 2009 at 02:40:20PM -0700, Steven Bethard wrote:
>
> > Also, is it possible to add these subparsers dynamically? For example,
> > you would want to be able to load a module immediately after parsing the
> > name instead of having to keep a predetermined list of all module names.
>
Steven Bethard gmail.com> writes:
> There's a lot of code already out there (in the standard library and
> other places) that uses %-style formatting, when in Python 3.0 we
> should be encouraging {}-style formatting. We should really provide
> some sort of transition plan. Consider an example fr
Yuvgoog Greenle wrote:
I like how python has a minimalistic and powerful syntax (-1 for the
break ___ PEP).
Also, I really dislike the for/else ambiguity "butterflies".
Properly understood, no ambiguity.
while c:
x()
is equivalent to hypothetical
label z:
if c:
x()
goto: z
So
while
On Wed, Sep 30, 2009 at 16:03, Vinay Sajip wrote:
> Steven Bethard gmail.com> writes:
>
>> There's a lot of code already out there (in the standard library and
>> other places) that uses %-style formatting, when in Python 3.0 we
>> should be encouraging {}-style formatting. We should really provi
Vinay Sajip yahoo.co.uk> writes:
>
> Does it seems too onerous to expect people to pass an additional "use_format"
> keyword argument with every logging call to indicate how to interpret the
> message format string? Or does the PercentMessage/BraceMessage type approach
> have any mileage? What do
Daniel Stutzbach writes:
> People have voiced support for the IPNetwork class
The obvious use cases are
1. parsing and validating strings that purport to describe networks,
2. providing a received for the result of a function that deduces the
network from an arbitrary address and a mask
Antoine Pitrou pitrou.net> writes:
> Why not allow logging.Formatter to take a callable, which would in turn call
> the callable with keyword arguments?
>
> Therefore, you could write:
>logging.Formatter("{asctime} - {name} - {level} - {msg}".format)
>
> and then:
>logging.critical(name
Barry Warsaw python.org> writes:
>
> This is a very interesting idea.
>
> Note that one of the reasons to /at least/ support {}-strings also is
> that %-strings are simply too error prone in many situations. For
> example, if I decide to support internationalization of log format
> strin
80 matches
Mail list logo
