Re: [Python-Dev] transitioning from % to {} formatting

[Nick Coghlan]

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 Jun 21, 2009, at 5:40 PM, Eric Smith wrote:
>> I've basically come to accept that %-formatting can never go away,
>> unfortunately. There are too many places where %-formatting is used,
>> for example in logging Formatters. %-formatting either has to exist or
>> it has to be emulated.
> 
> 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.format(1,2,3) == "1 2 3"
> 
> and perhaps, for symmetry:
> y = oldstyle_formatstr("%s %s %s")
> y.format(1,2,3) == x % (1,2,3) == "1 2 3"
> 
> This allows the format string "style" decision is to be made external to
> the API actually calling the formatting function. Thus, it need not
> matter as much whether the logging API uses % or .format() internally --
> that only affects the *default* behavior when a bare string is passed in.
> 
> This could allow for a controlled switch towards the new format string
> format, with a long deprecation period for users to migrate:
> 
> 1) introduce the above feature, and recommend in docs that people only
> ever use new-style format strings, wrapping the string in
> newstyle_formatstr() when necessary for passing to an API which uses %
> internally.
> 2) A long time later...deprecate str.__mod__; don't deprecate
> newstyle_formatstr.__mod__.
> 3) A while after that (maybe), remove str.__mod__ and replace all calls
> in Python to % (used as a formatting operator) with .format() so that
> the default is to use newstyle format strings for all APIs from then on.

I must have missed this suggestion when it went past the first time. I
certainly like this approach - it has the virtue of only having to solve
the problem once, and then application developers can use it to adapt
any existing use of %-mod formatting to str.format formatting.

Something like:

class formatstr(str):
  def __mod__(self, other):
if isinstance(other, dict):
  return self.format(**dict)
if isinstance(other, tuple)
  return self.format(*other)
return self.format(other)

APIs that did their own parsing based on %-formatting codes would still
break, as would any that explicitly called "str" on the object (or
otherwise stripped the subclass away, such as via "'%s' % fmt"), but
most things should pass a string subclass through transparently.

I wouldn't bother with a deprecation plan for 'normal' %-formatting
though. I don't think it is going to be practical to actually get rid of
that short of creating Python 4.0.

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] transitioning from % to {} formatting

[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.
>
> E.g.
> x = newstyle_formatstr("{} {} {}")
> x % (1,2,3) == x.format(1,2,3) == "1 2 3"
>
> and perhaps, for symmetry:
> y = oldstyle_formatstr("%s %s %s")
> y.format(1,2,3) == x % (1,2,3) == "1 2 3"
>
> This allows the format string "style" decision is to be made external to the
> API actually calling the formatting function. Thus, it need not matter as
> much whether the logging API uses % or .format() internally -- that only
> affects the *default* behavior when a bare string is passed in.
>
> This could allow for a controlled switch towards the new format string
> format, with a long deprecation period for users to migrate:
>
> 1) introduce the above feature, and recommend in docs that people only ever
> use new-style format strings, wrapping the string in newstyle_formatstr()
> when necessary for passing to an API which uses % internally.
> 2) A long time later...deprecate str.__mod__; don't deprecate
> newstyle_formatstr.__mod__.
> 3) A while after that (maybe), remove str.__mod__ and replace all calls in
> Python to % (used as a formatting operator) with .format() so that the
> default is to use newstyle format strings for all APIs from then on.

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 format
strings, how should that API use newstyle_formatstr or
oldstyle_formatstr to make this transition?

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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] PEP 3144 review.

[Mark Dickinson]

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
>>> object that was compatible with other integers but somehow kept a hint
>>> that would cause printing it to use hex by default.
>>
>> At the risk of bringing in false analogies: it seems that Python
>> typically represents values of some type in their canonical form,
>> rather than remembering the form in which they arrived in the program:
>> - integer values "forget" how many preceding zeroes they have
>> - string literals forget which of the characters had been escaped, and
>>   whether the string was single- or double-quoted
>> - floating point values forget a lot more about their literal
>>   representation (including even the literal decimal value)
>>
>> I guess a close case would be rational numbers: clearly, 3÷2 == 6÷4;
>> would a Python library still remember (and repr) the original numerator
>> and denominator?
>
> For a concrete example of an object which remembers details about its
> creation that it ignores when determining equality, we have decimal.Decimal:
>
> .>> from decimal import Decimal as d
> .>> x = d("3.0")
> .>> y = d("3.00")
> .>> x
> d("3.0")
> .>> y
> d("3.00")
> .>> repr(x) == repr(y)
> False
> .>> x.as_tuple() == y.as_tuple()
> False
> .>> x == y
> True
[snipped]

[More on the Decimal analogy below.]

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')
>>> snoopy = IPv4Network('172.16.200.3/24')
>>> fqdn = {linus: 'linus.peanuts.net', snoopy: 'snoopy.peanuts.net'}
>>> fqdn[linus]  # expecting 'linus.peanuts.net'
'snoopy.peanuts.net'

Is this just a problem of education, teaching the users not to abuse
IPv4Network this way?  Or is this just an unlikely use of IPv4Network?
Or have I misunderstood the proposal altogether?

As for Decimal, I see that as another whole kettle of tuna:  equality for
Decimal couldn't reasonably have been done any other way---if it weren't
mandated by the standard, there would still be a very strong expectation
that == would mean numeric equality.  That is, I see the == operator
as having two distinct but mostly compatible uses in Python:  it's
used for numeric equality, *and* it's used as the equivalence relation for
determining container membership.  Mostly these two different meanings
get along fine, though they lead to some fun when trying to ensure
that x == y implies hash(x) == hash(y) for x and y two different numeric
types.

But since Decimals and floats aren't used as set elements or dict keys
that often, the fact that you can't store Decimal('1.0') and Decimal('1.00')
together in a set doesn't often get in the way.  I'd expect putting
IPv4Network objects in a set or dict to be more common.

Mark
___
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] PEP 389: argparse - new command line parsing module

[Paul Moore]

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
___
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] transitioning from % to {} formatting

[Paul Moore]

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 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 format
> strings, how should that API use newstyle_formatstr or
> oldstyle_formatstr to make this transition?

IIUC, the API doesn't change. It's just that the internal code goes as follows:

1. (Current) Use %. str and oldformat objects work as now, newformat
objects work (using .format).
2. Convert the code to use .format - oldformat and newformat objects
work as before, str objects must be in new format.

The problem is, there's a point at which bare str arguments change
behaviour. So unless people wrap their arguments when calling the API,
there's still a point when things break (albeit with a simple
workaround available).

So maybe we need transition steps - wrap bare str objects in oldformat
classes, and warn, then wrap str objects in newformat objects and
warn, then stop wrapping.

That sounds to me like "normal" usage (bare strings) will be
annoyingly painful for a substantial transition period.

I'm assuming that the oldformat and newformat classes are intended to
be transitional things, and there's no intention that users should be
using the wrapper objects always. (And of course better names than
"oldformat" and "newformat" are needed - as Martin pointed out, having
"old" and "new" in the names is inappropriate). Otherwise, I'm a
strong -1 on the whole idea.

Paul.
___
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] PEP 3144 review.

[Paul Moore]

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')
 snoopy = IPv4Network('172.16.200.3/24')
 fqdn = {linus: 'linus.peanuts.net', snoopy: 'snoopy.peanuts.net'}
 fqdn[linus]  # expecting 'linus.peanuts.net'
> 'snoopy.peanuts.net'

I certainly don't understand IPv4Network better than you :-) But that
just looks wrong to me - linus and snoopy are hosts not networks, so
making them IPv4Network classes seems wrong. I'd instinctively make
them IPv4Address objects (which, I believe, would work).

Paul.
___
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] PEP 3144 review.

[Mark Dickinson]

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 suggested:
>>
> linus = IPv4Network('172.16.200.1/24')
> snoopy = IPv4Network('172.16.200.3/24')
> fqdn = {linus: 'linus.peanuts.net', snoopy: 'snoopy.peanuts.net'}
> fqdn[linus]  # expecting 'linus.peanuts.net'
>> 'snoopy.peanuts.net'
>
> I certainly don't understand IPv4Network better than you :-) But that
> just looks wrong to me - linus and snoopy are hosts not networks, so
> making them IPv4Network classes seems wrong. I'd instinctively make
> them IPv4Address objects (which, I believe, would work).

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 the PEP and almost
all of this thread, but I can't help feeling I'm still missing something.  If
someone could point out the obvious to me I'd be grateful.

I don't have any opinion on whether the ip attribute should be retained
or not; but retaining it *and* ignoring it in comparisons just seems a
bit odd.

Mark
___
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] transitioning from % to {} formatting

[Eric Smith]

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
% substitution.


It's a maintenance burden. There are several outstanding bugs with it, 
admittedly not of any great significance. I've been putting time into 
fixing at least one of them. When Mark and I did short-float-repr, at 
least half of my time was consumed with %-formatting, mostly because of 
how it does memory management.


On the plus side, %-formatting is (and always will be) faster than 
str.format(). Its very limitations make it possible for it to be fast.


I'd note that PEP 3101 calls str.format() a replacement for 
%-formatting, not an alternate mechanism to achieve the same end.



* Add a new class, NewFormatter, which uses the {}-style formatting.
This is ugly because it makes the formatting we're trying to encourage
look like the alternative implementation instead of the standard one.


It's also ugly because the class has the word "new" in its name, which
no class should ever have. In a few years, it would still be around,
but not new anymore.


* Have Formatter convert all %-style formatting strings to {}-style
formatting strings (automatically). This still involves some guessing,
and involves some serious hacking to translate from one to the other
(maybe it wouldn't even always be possible?). But at least we'd only
be using {}-style formatting under the hood.


I don't see the point of having a converter. The tricky part, as you
say, is the guessing. Whether the implementation then converts the
string or has two alternative formatting algorithms is an implementation
detail. I would favor continued use of the actual % substitution
code.


Having a converter and guessing are 2 distinct issues. I believe a 
convert from %-formatting specification strings to str.format() strings 
is possible. I point this out not because I think a converter solves 
this problem, but because in the past there's been a debate on whether a 
converter is even possible.


Eric.

___
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] PEP 3144 review.

[Mark Dickinson]

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 the PEP and almost
>> all of this thread, but I can't help feeling I'm still missing something.  If
>> someone could point out the obvious to me I'd be grateful.
>
> You're not missing anything that I'm aware of - unlike the use case for
> accepting a denormalised network definition in the IPNetwork constructor
> (which has been made quite clear in the list discussion, even if it is
> still a bit vague in the PEP), the use case for *retaining* the host
> information on the network object hasn't been well articulated at all.
>
> The closest anyone has come to describing a use case is an indirect
> comment via Guido that leaving out the attribute would involve real code
> having to find somewhere else to stash the original address details
> (e.g. by passing around an IPAddres/IPNetwork tuple rather than just an
> IPNetwork object).

Ah, thanks---I'd missed that bit.  So the .ip attribute is mainly for
backwards compatibility with existing uses/users of ipaddr.  I guess
that makes sense, then.  In particular, if it's suggested that new code
shouldn't make use of the .ip attribute, then the list/dict membership
problems described above can't arise.

> However, while I'd still be a little happier if the .ip attribute went
> away all together and another means was found to conveniently associate
> an IPAddress and an IPNetwork, keeping it doesn't bother me anywhere
> near as much as having network equivalence defined in terms of something
> other than the network ID and the netmask.

Makes sense.

Thanks,

Mark
___
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] PEP 3144 review.

[Stephen J. Turnbull]

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('172.16.200.1/24')
 > > snoopy = IPv4Network('172.16.200.3/24')
 > > fqdn = {linus: 'linus.peanuts.net', snoopy: 'snoopy.peanuts.net'}
 > > fqdn[linus]  # expecting 'linus.peanuts.net'

 > >> 'snoopy.peanuts.net'

Well, for one thing it would be broken anyway if __eq__ and __hash__
paid attention to the .ip attribute, because they *also* pay attention
to the .prefixlen (and I guess .network, redundantly) attribute.
Presumably the use in real code would not be fqdn[linus], you already
know about linus.  Rather, it would be equivalent to say

> fqdn[IPv4Network('172.16.200.1/16')]
KeyError

where an IP and network parsed out of some packet were used to
construct the key.  Of course it would work almost all the time, and
only break when, say, old-style class was used to infer the prefix
length, and was wrong.  So, no, I don't think we want to do this.


___
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] test_thread tracebacks

[skip]

>> 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
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] transitioning from % to {} formatting

[Barry Warsaw]

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="{asctime} - {name} - {levelname} - {message}")

For the % formatting, I suggest "dicttemplate" (assuming that
you *have* to use dictionary %(key)s style currently).

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 prefer 'format' :).  But I like this  
because there's not really any magic, it's explicit, and the decision  
is made by the coder at the call site.  The implementation does not  
need to guess at all.


If this is adopted, it should become a common idiom across Python so  
that once you've learned how to transition between the format strings,  
you pretty much know how to do it for any supporting API.  So we  
should adopt it across all of the standard library.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
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] transitioning from % to {} formatting

[Paul Moore]

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 decision is made by the coder at
> the call site.  The implementation does not need to guess at all.

Ignoring the "make it ugly to persuade people not to use it" aspect,
why not just use 'template'?

Paul
___
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] Python 2.6.3

[Barry Warsaw]

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.6 tree are allowed  
without checking with me first (via IRC, bug tracker or email).  I'll  
make an exception for svnmerge bookkeeping.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
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] Python 2.6.3rc1 available

[Barry Warsaw]

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.  Barring any unforeseen  
problems, we will make the final 2.6.3 release this Friday, October  
2nd.  Please give this release candidate a spin and let us know if you  
encounter any show stopping problems.


Enjoy,
-Barry



PGP.sig
Description: This is a digitally signed message part
___
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] Python logging and 1.5.2 compatibility

[Vinay Sajip]

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 sysadmins who wanted
to use logging with their system Python.

The Linux landscape has changed a bit since then. Most Linux distros ship with
much more recent versions of Python, and so I no longer see 1.5.2 support as
important.

Dropping support for 1.5.2 means that future changes to logging will not be
concerned with 1.5.2 compatibility. For example, boolean values which were 0/1
in the logging package will at some point be replaced by False/True, and newer
language features will start to be used when changes are made. There are no
plans for a specific "cleanup" exercise at the moment. In fact some changes
made a while ago inadvertently broke 1.5.2 compatibility, but no-one's
complained. So I'm assuming the whole thing is really a non-issue, and this
post is just to keep everyone in the picture.

A 1.5.2-compatible version of the package is still available via
http://www.red-dove.com/python_logging.html if anyone needs it. This version
is not actively maintained, but that shouldn't be an issue.

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] Python logging and 1.5.2 compatibility

[Antoine Pitrou]

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-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] Python logging and 1.5.2 compatibility

[R. David Murray]

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 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] operator precedence of __eq__, __ne__, etc, if both object have implementations

[Chris Withers]

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/ logging.

It would be very nice if these complex corner cases had a set of test
cases which could be run by all implementations (CPython, Jython,
IronPython, PyPy, etc).  I don't know.  Maybe the CPython test suite serves
that purpose, but it seems like it would be helpful if this sort of
"validation suite" was maintained as a separate project all implementations
could use and contribute to.


+1, and supported by documentation.

Something like a manuel-based table test would seem ideal for this:

http://packages.python.org/manuel/manuel/table-example.html

..but what are the chances of something like that getting into the 
python core docs?


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] sharing stdlib across python implementations

[Chris Withers]

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 me out.
 When I have something worth showing, I'll start the real PEP process.


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 packaging tools could manage them, and 
upgrade them independently of python packages when there are bug fixes. 
If that were the case, then pure python packages in the stdlib, of which 
there are many, *really* could be used across python implementations 
with no changes whatsoever...


The big changes I can see from here would be moving the tests to the 
packages from the central tests directory, and adding a setup.py file or 
some other form of metadata providion for each package. Not that big now 
that I've written it ;-)


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] Python logging and 1.5.2 compatibility

[Vinay Sajip]

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, I'm not sure if it now
makes sense to support a minimum version. When changing the package I intend to
be conservative in terms of using the simplest, rather than using the latest
language features (say, coroutines) just because they're available.

The reason it was done for 1.5.2 was that there was already a community of users
of the "standalone" package (which was 1.5.2-compatible) before it got accepted
into Python 2.3, and it didn't make sense at the time to maintain two different
codebases - one 1.5.2-compatible and one not. Keeping it compatible meant that
1.5.2-dependent users/sysadmins could just copy the whole package and have it
work, and take advantage of bug-fixes and enhancements as they appeared.

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. I don't think it's still necessary to hold back from using new
features just to support 1.5.2, given that a working implementation is available
if any 1.5.2 user should need it, and that the 1.5.2-dependent community will be
pretty minimal. A lot of water has passed under the bridge.

There are some new features which have been added in recent versions (say,
WatchedFileHandler in 2.6, NullHandler in 2.7) and these should still work if
copied and pasted into a codebase which runs with an older version of Python.
Certain projects which need to support multiple Python versions - Django, say -
can take advantage of this by e.g. offering a copy of these handlers in their
own codebase for use when constrained to work with an older Python version.

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] transitioning from % to {} formatting

[Steven D'Aprano]

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.format(1,2,3) == "1 2 3"

People will want this formatstr object to behave like strings, with 
concatenation, slicing, etc.:

>>> x = newstyle_formatstr("x{} {} : ")
>>> y = newstyle_formatstr("{}")
>>> (x[1:] + y) % (1, 2, 3)
'1 2 : 3'

Instead of having to support one type with %-formatting and 
{}-formatting (str), now the std lib will have two classes 
with %-formatting and {}-formatting. How is this an improvement?

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)

somestring % args 

with 

newstyle_formatstr(somestring) % args 

instead? That seems terribly pointless to me -- it does nothing about 
getting rid of % but adds a layer of indirection which slows down the 
code. Things are no better if the replacement code is:

newstyle_formatstr(somestring).format(*args)

(or similar). If we can do that, then why not just go all the way and 
use this as the replacement instead?

somestring.format(*args)




> and perhaps, for symmetry:
> y = oldstyle_formatstr("%s %s %s")
> y.format(1,2,3) == x % (1,2,3) == "1 2 3"

Now we have three classes that support both % and {} formatting. Great.


[...]
> This could allow for a controlled switch towards the new format
> string format, with a long deprecation period for users to migrate:
>
> 1) introduce the above feature, and recommend in docs that people
> only ever use new-style format strings, wrapping the string in
> newstyle_formatstr() when necessary for passing to an API which uses
> % internally.

And how are people supposed to know what the API uses internally?

Personally, I think your chances of getting people to write:

logging.Formatter(newstyle_formatstr("%(asctime)s - %(name)s - %(level)s - 
%(msg)s"))

instead of 

logging.Formatter("%(asctime)s - %(name)s - %(level)s - %(msg)s")

is slim to none -- especially when the second call still works. You'd 
better off putting the call to newstyle_formatstr() inside 
logging.Formatter, and not even telling the users.

Instead of wrapping strings in a class that makes .__mod__() 
and .format() behave the same, at some cost on every call presumably, 
my preferred approach would be a converter function (perhaps taken from 
2to3?) which modified strings like "%(asctime)s" to "{asctime}". That 
cost gets paid *once*, rather than on every call.

(Obviously the details will need to be ironed out, and it will depend on 
the external API. If the external API depends on the caller using % 
explicitly, then this approach may not work.)


> 2) A long time later...deprecate str.__mod__; 

How long? I hope that's not until I'm dead and buried.



-- 
Steven D'Aprano
___
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] sharing stdlib across python implementations

[Antoine Pitrou]

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 packaging tools could manage them, and 
> upgrade them independently of python packages when there are bug fixes. 

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 quality might become lower, rather than 
higher.

(of course, if we rigorously enforce APIs and preserve compatibility, this might
not be a real issue; but our compatibility story is a bit irregular, IMHO)

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] sharing stdlib across python implementations

[Chris Withers]

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 quality might become lower, rather than 
higher.


I'd certainly still see there being "blessed" python releases.
(The Zope community does this in the form of "known good sets" and 
these, for me, would be "the python releases")


However, it's pretty frustrating to not be able to upgrade a pure-python 
package with a critical bug (as happened recently to me with httplib) 
because it's part of the stdlib.


It's also frustrating to have to if-then-else about a package or 
project's dependencies when using dependency management tools like 
buildout when libraries such as elementtree and argparse become part of 
the stdlib when they weren't before...



(of course, if we rigorously enforce APIs and preserve compatibility, this might
not be a real issue; but our compatibility story is a bit irregular, IMHO)


Breaking it apart like this would *make* the compatibility story better...

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 new setuptools release?

[Chris Withers]

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 
maintainers of the 0.6 branch of setuptools, so that I could work on the 
fun bits I've long planned for 0.7, but never felt free to start on 
while there was so much still needing to be done on 0.6.


If this offer is still available, I'd lake to take you up on it.
I'd be more than willing to merge changes on the 0.6 distribute branch 
back into the setuptools codebase and do whatever is needed to get a new 
setuptools release out.


Why? Because there are a *lot* of copies of ez_setup.py and buildout's 
bootstrap.py that will need replacing if it doesn't happen. I think it'd 
be better for the python community all round if setuptools just 
continued in maintenance mode until whatever-ends-up-in-the-core exists 
and people want to use...


I'm happy to submit to whatever supervision is needed for you to trust 
me to do this, and I promise to be as careful as I can with this. I 
*know* how important this is and want to make it work...


All I want is for good stuff to happen for setuptools users and Python 
users in general, so I don't think all the suspicion and backbiting is 
merited. 


Fine, if that's true, I apologize (even spelled correctly!) for any 
previous involvement in this, but please help me help you achieve your 
aims...


To put this into a way that makes sense to me: I'm volunteering to keep 
distribute 0.6 and setuptools 0.6 in sync, no more, no less, and try and 
keep that as uncontroversial as possible, and get setuptools 0.6 
releases out to match distribute 0.6 releases as soon as I can.


Again, I feel I need to stress that the *only* reason I want to do this 
is to bring the benefits of the distribute work to the existing 
setuptools codebase, with appropriate attribution if that makes a 
difference.


Apologies if any of this is offensive to anyone. For once (really!) I 
really mean that :-)


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] Distutils ML wrap-up: setup.cfg new format

[Chris Withers]

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 required but no 
simpler", which I'm sure is what we're all aiming for. The problem is 
that it's fiendishly difficult ;-)


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] sharing stdlib across python implementations

[Olemis Lang]

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 actually a set of separate python packages with their own version
> metadata so that packaging tools could manage them, and upgrade them
> independently of python packages when there are bug fixes. If that were the
> case, then pure python packages in the stdlib, of which there are many,
> *really* could be used across python implementations with no changes
> whatsoever...
>

nice ! That's something I really liked about Python.NET

:)

BTW ... is there something like that for Java ? I mean to use J2[SE]E
classes using CPython ?

This could also be useful to have personalized distributions. I mean,
if I want to implement a Py app that will run in devices with limited
capabilities, and let's say that it only imports `sockets` module (or
a few more ;o), then it will be easier to prepare a subset of stdlib
in order to deploy just what is needed in such devices, and save some
space ;o).

Projects like py2exe or others, could use something like that in order
to extract relevant stdlib (modules | packages) and make them
available to Windows apps distributed as exe files (e.g. Hg )

CMIIW anyway, perhaps I'm just dreaming.

however ...

> The big changes I can see from here would be moving the tests to the
> packages from the central tests directory, and adding a setup.py file or
> some other form of metadata providion for each package. Not that big now
> that I've written it ;-)
>

In this case I envision the following issues if one setup.py file is
generated for every module or top-level package (... which is
-considering the previous message- how u plan to do it, isn't it ? )

  - the maintenance effort might increase
  - what about dependencies between stdlib modules ?
  - there are many attributes which will take the same values for each
and every
packages (e.g. version info, issue tracker, ...) and some that
will be specific
(e,g, maintainer, author, contact info, dependencies ...)
  - Overhead when a new package is included in stdlib (need to create and
maintain `setup.py` script, and so on ...)

So my $0.02 here are :

  - to have a single `setup.py` file (in the end it's a script, isn't it ? )
  - provide an argument in order to select module(s) to be included
(full stdlib if missing) in source distribution. In general any other
parameterization of the `setup.py` may be just ok, the goal is
to have only one
  - use a mechanism in order to specify config options for specific pkgs
modules, and make it available to the global `setup.py`. For example :
* Specify metadata using top-level fields in modules (e.g. __author__,
   __maintainer__, ...)
* Specify metadata using separate INI files for each target

What d'u think ?

There may be some issues with sdist anyway
:-/

PS: Will those packages be submitted to PyPI too ? I mean if not
sdists, at least meta-data ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Sobrepasa las 300 descargas el módulo dutest  -
http://feedproxy.google.com/~r/simelo-es/~3/U5rff5iTQPI/sobrepasa-las-300-descargas-el-modulo.html
___
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] transitioning from % to {} formatting

[Steven Bethard]

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 name of the
>> string type), i.e.
>>
>> logging.Formatter(
>>  format="{asctime} - {name} - {levelname} - {message}")
>>
>> For the % formatting, I suggest "dicttemplate" (assuming that
>> you *have* to use dictionary %(key)s style currently).
>>
>> 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 prefer 'format' :).  But I like this because there's not
> really any magic, it's explicit, and the decision is made by the coder at
> the call site.  The implementation does not need to guess at all.

Could you comment on what you think we should do when the parameter is
not positional? As I mentioned upthread, in the case of
logging.Formatter, it's already documented as taking the keyword
parameter "fmt", so we'd have to use the name "fmt" for % formatting.


Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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] transitioning from % to {} formatting

[Barry Warsaw]

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 would call the argument "format" (like the method name of the
string type), i.e.

logging.Formatter(
 format="{asctime} - {name} - {levelname} - {message}")

For the % formatting, I suggest "dicttemplate" (assuming that
you *have* to use dictionary %(key)s style currently).

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 prefer 'format' :).  But I like this because there's  
not
really any magic, it's explicit, and the decision is made by the  
coder at

the call site.  The implementation does not need to guess at all.


Could you comment on what you think we should do when the parameter is
not positional? As I mentioned upthread, in the case of
logging.Formatter, it's already documented as taking the keyword
parameter "fmt", so we'd have to use the name "fmt" for % formatting.


I'm okay with fmt==%-formatting and format=={}-formatting, but I'd  
also be okay with transitioning 'fmt' to 'dicttemplate' or whatever.   
I think the important thing is to be explicit in the method signature  
which one you want (secondary would be trying to standardize this  
across the stdlib).


-Barry



PGP.sig
Description: This is a digitally signed message part
___
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] sharing stdlib across python implementations

[Olemis Lang]

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 python packages with their
>> own version metadata so that packaging tools could manage them, and
>> upgrade them independently of python packages when there are bug fixes.
>
> 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 quality might become lower, rather than 
> higher.
>

You are right here !

-1 for splitting the test code and test suite

but I still think it could be a good idea ...

> (of course, if we rigorously enforce APIs and preserve compatibility,

-1

> this might
> not be a real issue; but our compatibility story is a bit irregular, IMHO)
>

mainly because of this ;o)

But it's still possible to use a parameterized `setup.py` and leave
things just like they are right now.

For instance, I have started something like that has been dome by the
FLiOOPS  project [1]_ (and possibly others, it's just an example ;o).
In the SVN repository there's a single trunk containing the whole
PyOOP package (which is not complete BTW). Inside of it there are
separate `setup.py` files for other distributions too :

  - `PyOOP` (which should contain them all) employs default `setup.py`
  - `dutest` is a single file (there are more in there) under
`oop.utils` package and
 is distributed separately too, so you can find in there `setup_dutest.py`
 script. All other packages rely on it to build test suites ;o)
  - CASPy (Comprehensive Assertion Support for Python) should be distributed
separately too, so it should have its own `setup_dbc.py` script
once it's ready.

When I create (SVN) tags for each package, I have to rename it
(extra-overhead), and I once global metadata changes, then I have to
change them all

PS: Another alternative for stdlib could be to have common data in
`setup.cfg` and separate `setup.py` scripts, but I don't really like
this one ...

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Sobrepasa las 300 descargas el módulo dutest  -
http://feedproxy.google.com/~r/simelo-es/~3/U5rff5iTQPI/sobrepasa-las-300-descargas-el-modulo.html
___
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] transitioning from % to {} formatting

[Steven Bethard]

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,
 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="{asctime} - {name} - {levelname} - {message}")

 For the % formatting, I suggest "dicttemplate" (assuming that
 you *have* to use dictionary %(key)s style currently).
>>
>> Could you comment on what you think we should do when the parameter is
>> not positional? As I mentioned upthread, in the case of
>> logging.Formatter, it's already documented as taking the keyword
>> parameter "fmt", so we'd have to use the name "fmt" for % formatting.
>
> I'm okay with fmt==%-formatting and format=={}-formatting, but I'd also be
> okay with transitioning 'fmt' to 'dicttemplate' or whatever.  I think the
> important thing is to be explicit in the method signature which one you want
> (secondary would be trying to standardize this across the stdlib).

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', type=int, default=42,
help='A foo of type %(type)s, defaulting to %(42)s)

That is, existing keyword arguments that already have good names (and
are pretty much always used as keyword arguments) take format strings.
I'm not sure that changing the name of usage= or help= here is really
an option.

I guess in this case I'm stuck with something like Benjamin's
suggestion of adding an additional flag to control which type of
formatting, and the corresponding 4 versions of cleanup. Ew.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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] transitioning from % to {} formatting

[Barry Warsaw]

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', type=int, default=42,
   help='A foo of type %(type)s, defaulting to %(42)s)

That is, existing keyword arguments that already have good names (and
are pretty much always used as keyword arguments) take format strings.
I'm not sure that changing the name of usage= or help= here is really
an option.


Ah right.


I guess in this case I'm stuck with something like Benjamin's
suggestion of adding an additional flag to control which type of
formatting, and the corresponding 4 versions of cleanup. Ew.


I missed Benjamin's suggestion, but in this case I would say add a  
flag to ArgumentParser.  I'm either going to want {} formatting all or  
nothing.  E.g.


import argparse
parser = ArgumentParser(usage='{prog} [--foo]', format=argparse.BRACES)
parser.add_argument(
'--foo', type=int, default=42,
help='A foo of type {type}, defaulting to {42}')

(although that last looks weird ;).

-Barry



PGP.sig
Description: This is a digitally signed message part
___
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] sharing stdlib across python implementations

[Olemis Lang]

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 and typos, should be

For instance, something like that has been done by the FLiOOPS  project [1]_

.. [1] py trunk @ FLiOOPS @ sf.net
(http://sourceforge.net/apps/trac/flioops/browser/py/trunk)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Sobrepasa las 300 descargas el módulo dutest  -
http://feedproxy.google.com/~r/simelo-es/~3/U5rff5iTQPI/sobrepasa-las-300-descargas-el-modulo.html
___
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] PEP 3144 review.

[R. David Murray]

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:


linus = IPv4Network('172.16.200.1/24')
snoopy = IPv4Network('172.16.200.3/24')
fqdn = {linus: 'linus.peanuts.net', snoopy: 'snoopy.peanuts.net'}
fqdn[linus] ?# expecting 'linus.peanuts.net'

'snoopy.peanuts.net'


I certainly don't understand IPv4Network better than you :-) But that
just looks wrong to me - linus and snoopy are hosts not networks, so
making them IPv4Network classes seems wrong. I'd instinctively make
them IPv4Address objects (which, I believe, would work).


I didn't reply to Guido's post about not wanting a third class
(IPAddressWithMask or somesuch) because it made it harder for people to
choose the "right" class to use.  He went on to say that if there was
only one class, they'd have a 100% chance of getting it right.

Well, the original ipaddr implementation had one class(*), but it wasn't
deemed acceptable by the community, and at least one real user
of ipaddr has expressed appreciation of the 2.0 addition of the
explicit IPAddress data type, so it seems like that was the right
direction to go.

Now the new implementation has two classes, and the above example shows
that people _will_ make the wrong choice.  I'd say that was _because of_
the loose parsing and the ip attribute.  If IPv4Network only accepted
valid network addresses and masks, and there was a separate parsing
function that took an arbitrary IP+netmask and returned an (IPAddress,
IPNetwork) tuple, then the user would choose the right class, IMO,
because otherwise they couldn't even get their code to parse the input.
That seems like good design to me.

But I think I'm descending to beating a dead horse here

--David (RDM)

(*) yes, I'm ignoring the IPv4/IPv6 split throughout this message.___
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] PEP 389: argparse - new command line parsing module

[Vinay Sajip]

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, logging is 1300
SLOC, less than say tarfile, pickletools, pydoc and decimal.

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] transitioning from % to {} formatting

[James Y Knight]

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)
   somestring % args
with
   newstyle_formatstr(somestring) % args
instead? That seems terribly pointless to me


Indeed, that *would* be terribly pointless! Actually, more than  
pointless, it would be broken, as you've changed the API from taking  
oldstyle format strings to newstyle format strings.


That is not the suggestion. The intention is to change /nearly  
nothing/ in the std lib, and yet allow users to use newstyle string  
substitution with every API.


Many Python APIs (e.g. logging) currently take a %-type formatting  
string. It cannot simply be changed to take a {}-type format string,  
because of backwards compatibility concerns. Either a new API can be  
added to every one of those functions/classes, or, a single API can be  
added to inform those places to use newstyle format strings.



This could allow for a controlled switch towards the new format
string format, with a long deprecation period for users to migrate:

1) introduce the above feature, and recommend in docs that people
only ever use new-style format strings, wrapping the string in
newstyle_formatstr() when necessary for passing to an API which uses
% internally.


And how are people supposed to know what the API uses internally?


It's documented, (as it already must be, today!).


Personally, I think your chances of getting people to write:
logging.Formatter(newstyle_formatstr("%(asctime)s - %(name)s - % 
(level)s - %(msg)s"))

instead of
logging.Formatter("%(asctime)s - %(name)s - %(level)s - %(msg)s")


That's not my proposal.

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}")


This despite the fact that logging has not been changed to use {}- 
style formatting internally. It should continue to call "self._fmt %  
record.__dict__" for backward compatibility.


That's not to say that this proposal would allow no work to be done to  
check the stdlib for issues. The Logging module presents one: it  
checks if the format string contains "%{asctime}" to see if it should  
bother to calculate the time. That of course would need to be changed.  
Best would be to stick an instance which lazily generates its string  
representation into the dict. The other APIs mentioned on this thread  
(BaseHTTPServer, email.generator) will work immediately without  
changes, however.


James
___
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] PEP 389: argparse - new command line parsing module

[Vinay Sajip]

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.net/blog/2009/09/14/opster/

I've contacted Steven about a similar approach for argparse, and we're waiting
for Yuvgoog's work on argparse(func) to be done to see if there's a feasible
similar approach.



___
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] transitioning from % to {} formatting

[Raymond Hettinger]

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 prefer 'format' :). But I like this because there's not
really any magic, it's explicit, and the decision is made by the coder at
the call site. The implementation does not need to guess at all.


Could you comment on what you think we should do when the parameter is
not positional? As I mentioned upthread, in the case of
logging.Formatter, it's already documented as taking the keyword
parameter "fmt", so we'd have to use the name "fmt" for % formatting.


Unless there is a firm decision to switch to kill %-formatting across the board,
I don't think anything should be done at all.   

Creating Py3.x was all about removing cruft and clutter.  I don't think it 
would be improved by adding two ways to do it for everything in the 
standard library.  That is a lot of additional code, API expansion, and 
new testing, fatter docs, and extra maintenance, but giving us no new 
functionality.


Anytime we start hearing about newstyle/oldstyle combinations, I think
a flag should go up.  Anytime there is a proposal to make sweeping
additions that do not  add new capabilities, a flag should go up.

I understand the desire to have all formatting support both ways,
but I don't think it is worth the costs.  People *never* need both ways
though they may have differing preferences about which *one* to use.

my-two-cents,


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] PEP 3144 review.

[Terry Reedy]

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:


linus = IPv4Network('172.16.200.1/24')
snoopy = IPv4Network('172.16.200.3/24')
fqdn = {linus: 'linus.peanuts.net', snoopy: 'snoopy.peanuts.net'}
fqdn[linus]  # expecting 'linus.peanuts.net'

'snoopy.peanuts.net'

Is this just a problem of education, teaching the users not to abuse
IPv4Network this way?  Or is this just an unlikely use of IPv4Network?
Or have I misunderstood the proposal altogether?


This gets at why I suggested the docs be organized as I suggested, with 
'Network is range of addresses defined by address within range ...'
and 'Definition address is retained' *immediately* followed by 
'Definition address is mostly ignored, including for comparisons'. The 
latter caveat should mention the implication for hash() and set/dict 
membership. The point is to emphasize from the beginning that a network 
is a network (with an address, that many will ignore), rather than an 
address (with a network).


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] PEP 389: argparse - new command line parsing module

[Guido van Rossum]

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, and other revision control systems (P4 anyone?)
with a rich command-line interface. There are some variants, e.g.
whether global and subcommand-specific flags may overlap, and whether
flags may follow positional args (Hg and SVN seem to differ here a
bit).

I've helped write at least two tools at Google that have this
structure; both used different approaches, and neither was
particularly easy to get right. Getting all the different --help
output to make sense was mostly a manual process. (E.g. "foo --help"
should print the general flags and the list of known subcommands,
whereas "foo --help subcommand" should print flags and other usage
info about the specific subcommand.) Also switching out to different
calls based on the subcommand should/might be part of this.

I would be willing to live with a third option parser in the stdlib if
it solved this problem well.

-- 
--Guido van Rossum (home page: http://www.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] PEP 389: argparse - new command line parsing module

[Robert Kern]

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 has already, say,
used getopt or optparse in conjunction with a GUI library, and what
feedback they have about that.


I use argparse (and previously optparse) frequently to handle the command line 
arguments of GUI apps. I tend to use them in the same way as CLI programs, 
though, since I usually only use command line arguments when starting the GUIs 
from the terminal. I am blissfully unaware of the problems Paul mentioned about 
Windows GUI-mode programs. I'm not sure what would make a program "GUI-mode" or 
not. Certainly, I have written Python programs that use wxPython and PyQt on 
Windows that print to stdout/stderr, and they appear to work fine.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

___
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] transitioning from % to {} formatting

[Martin v. Löwis]

>>> 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 maintenance burden.

Well - that's the cost of keeping it in the language. It's not a problem
with using it while it *is* in the language.

So if a decision was made to eventually remove % formatting, it would
be reasonable to start migrating code to PEP 3101. However, no such
decision has been made (and hopefully won't be throughout 3.x), so
as the mechanism *is* available, there is no need to start changing
existing code (except the for actual issue Steven discusses, namely
libraries that expect strings in % template form).

> 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 option, not as an actual replacement.
This becomes clear when reading the "Backwards Compatibility" section:

# Backwards compatibility can be maintained by leaving the existing
# mechanisms in place.  The new system does not collide with any of
# the method names of the existing string formatting techniques, so
# both systems can co-exist until it comes time to deprecate the
# older system.

Regards,
Martin
___
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] transitioning from % to {} formatting

[Terry Reedy]

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 forget about 
it ;-).


+10 on the goal.

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] transitioning from % to {} formatting

[Martin v. Löwis]

> 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 coder at the call site.  The implementation does not need to
> guess at all.

Unfortunately, as Steven pointed out, the parameter is *already*
documented with the name "fmt". So one option would be to call it
"fmt" and "format"; the other option would be to not only deprecate
the positional passing, but also the passing under the name fmt=.

As for calling it "dicttemplate" - I'm sure people can and will propose
alternative spellings :-)

Regards,
Martin
___
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] PEP 389: argparse - new command line parsing module

[Robert Kern]

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 probably familiar with this
pattern from SVN, Hg, and other revision control systems (P4 anyone?)
with a rich command-line interface. There are some variants, e.g.
whether global and subcommand-specific flags may overlap, and whether
flags may follow positional args (Hg and SVN seem to differ here a
bit).

I've helped write at least two tools at Google that have this
structure; both used different approaches, and neither was
particularly easy to get right. Getting all the different --help
output to make sense was mostly a manual process. (E.g. "foo --help"
should print the general flags and the list of known subcommands,
whereas "foo --help subcommand" should print flags and other usage
info about the specific subcommand.) Also switching out to different
calls based on the subcommand should/might be part of this.

I would be willing to live with a third option parser in the stdlib if
it solved this problem well.


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.


http://argparse.googlecode.com/svn/tags/r101/doc/other-methods.html#sub-commands

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

___
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] transitioning from % to {} formatting

[Antoine Pitrou]

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}")

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="Python", msg="Buildbots are down")

All this without having to learn about a separate "compatibility wrapper 
object".

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] transitioning from % to {} formatting

[Raymond Hettinger]

[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 be nice.  But as long as the language supports
%-formatting, it is going to be around in one form or another.   Any non-casual 
user will bump into %-formatting in books, in third-party modules, in ASPN recipes, 
on the newsgroup, and in our own source code.  If they maintain any exising

software, they will likely encounter too.  It doesn't seem to be a subject that
can be ignored.

Also, I think it premature to say that {}-formatting has been proven in battle.
AFAICT, there has been very little uptake.  I've personally made an effort
to use {}-formatting more often but find that I frequently have to lookup
the syntax and need to experiment with the interactive interpreter to get it 
right.
I haven't found it easy to teach or to get other people to convert.  This is
especially true if the person has encountered %-formatting in other languages
(it is a popular approach).


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] transitioning from % to {} formatting

[Steven Bethard]

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 = ArgumentParser(usage='%(prog)s [--foo]')
>>   parser.add_argument(
>>       '--foo', type=int, default=42,
>>       help='A foo of type %(type)s, defaulting to %(42)s)

Yep, sorry, typo, that should have been %(default)s, not %(42)s.

>> I guess in this case I'm stuck with something like Benjamin's
>> suggestion of adding an additional flag to control which type of
>> formatting, and the corresponding 4 versions of cleanup. Ew.
>
> I missed Benjamin's suggestion, but in this case I would say add a flag to
> ArgumentParser.  I'm either going to want {} formatting all or nothing.
>  E.g.
>
> import argparse
> parser = ArgumentParser(usage='{prog} [--foo]', format=argparse.BRACES)

Yeah, that's basically Benjamin's suggestion, with the transition path being:

(1) Introduce format= keyword argument, defaulting to PERCENTS
(2) Deprecate format=PERCENTS
(3) Error on format=PERCENTS (Benjamin suggested just changing the
default here, but that would give a release where errors would pass
silently)
(4) Deprecate format= keyword argument.
(5) Remove format= keyword argument.

It's a little sad that it takes 5 versions to do this, but I guess if
a user is on top of things, at version (1) they add format=BRACES to
all their code, and then remove those at version (4). So even though
there are 5 versions, there are only two code changes required.

At least in the case of argparse, this can be a constructor argument
as you suggest, and we only have to introduce this flag in one place.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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] transitioning from % to {} formatting

[Guido van Rossum]

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 option, not as an actual replacement.
> This becomes clear when reading the "Backwards Compatibility" section:

The problem is, PEP 3101 and our interpretation of it evolved. The
original proposal for {}-formatting was certainly put forward with the
aim to completely *replace* %-formatting, and care was taken in the
design to cover all use cases, avoid known problems, etc.

Then we started looking seriously at conversion from Python 2 to
Python 3 and we discovered that converting %-formatting to
{}-formatting was a huge can of worms, and decided it wasn't worth to
try and do *at the time* given the Python 3 schedule. We considered
some kind of gentle deprecation warning, but decided that even that
would be too noisy. So now we have two competing mechanisms.

In the long run, say Python 4, I think we don't need both, and we
should get rid of one. My preference is still getting rid of
%-formatting, due to the problems with it that prompted the design of
{}-formatting (no need to reiterate the list here).

So how do we get there? My proposal would be to let this be a gradual
take-over of a new, superior species in the same niche as an older
species. (Say, modern man over Neanderthal man.) Thus, as new code is
written (especially example code, which will be copied widely), we
should start using {}-formatting, and when new APIs are designed that
tie in to some kind of formatting, they should use {}-formatting.
Adding support for {}-formatting, in addition to %-formatting, to
existing APIs like the logging package also strikes me as a good idea,
as long as backwards compatibility can be preserved. (I have no strong
ideas on how to do this right now.)

If we do this right, by the time Python 4 comes around, {}-formatting
will have won the race, and there won't be a question about removing
%-formatting at the time. I wouldn't be surprised if by then static
analysis techniques will have improved so that we *can* consider
automatic conversion by then.

-- 
--Guido van Rossum (home page: http://www.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] Python logging and 1.5.2 compatibility

[Martin v. Löwis]

> 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.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 389: argparse - new command line parsing module

[Barry Warsaw]

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 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 same help text.  This is the way bzr does it  
for example and it works great.


Other than that, I think argparse supports Guido's use case very nicely.

-Barry



PGP.sig
Description: This is a digitally signed message part
___
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] transitioning from % to {} formatting

[Barry Warsaw]

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.

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  
strings, and all I can use is %-strings, it's almost guaranteed that I  
will have bugs because a translator forgot the trailing 's'.  This  
exactly the motivation that led to PEP 292 $-strings.


In fact, while we're at it, it would be kind of cool if I could use $- 
strings in log templates.  Antoine's idea of accepting a callable  
might fit that bill nicely.


-Barry



PGP.sig
Description: This is a digitally signed message part
___
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] PEP 389: argparse - new command line parsing module

[Brett Cannon]

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 top of getopt, and can be seen here:
>
> http://blogg.ingspree.net/blog/2009/09/14/opster/
>
> I've contacted Steven about a similar approach for argparse, and we're waiting
> for Yuvgoog's work on argparse(func) to be done to see if there's a feasible
> similar approach.

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.

-Brett
___
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] Python 2.6.3

[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.


-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 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.6 tree are allowed
without checking with me first (via IRC, bug tracker or email).  I'll
make an exception for svnmerge bookkeeping.

-Barry



___
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] Python 2.6.3

[Barry Warsaw]

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 a digitally signed message part
___
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] Python 2.6.3

[Raymond Hettinger]

[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.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.3

[Sridhar Ratnakumar]

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 and let you know.

-srid

___
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] PEP 3144 review.

[Guido van Rossum]

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
>>> this sort of use.  If not, then what's it for?  I've read the PEP and almost
>>> all of this thread, but I can't help feeling I'm still missing something.  
>>> If
>>> someone could point out the obvious to me I'd be grateful.
>>
>> You're not missing anything that I'm aware of - unlike the use case for
>> accepting a denormalised network definition in the IPNetwork constructor
>> (which has been made quite clear in the list discussion, even if it is
>> still a bit vague in the PEP), the use case for *retaining* the host
>> information on the network object hasn't been well articulated at all.
>>
>> The closest anyone has come to describing a use case is an indirect
>> comment via Guido that leaving out the attribute would involve real code
>> having to find somewhere else to stash the original address details
>> (e.g. by passing around an IPAddres/IPNetwork tuple rather than just an
>> IPNetwork object).
>
> Ah, thanks---I'd missed that bit.  So the .ip attribute is mainly for
> backwards compatibility with existing uses/users of ipaddr.  I guess
> that makes sense, then.  In particular, if it's suggested that new code
> shouldn't make use of the .ip attribute, then the list/dict membership
> problems described above can't arise.

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. Since this
is just one extra attribute on an IPNetwork object I don't think that
adding extra classes which only differ from the IPvXNetwork classes in
having this one extra attribute is worthy.

-- 
--Guido van Rossum (home page: http://www.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] PEP 3144 review.

[R. David Murray]

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 attribute was precisely a convenience to allow
this sort of use. ?If not, then what's it for? ?I've read the PEP and almost
all of this thread, but I can't help feeling I'm still missing something. ?If
someone could point out the obvious to me I'd be grateful.


You're not missing anything that I'm aware of - unlike the use case for
accepting a denormalised network definition in the IPNetwork constructor
(which has been made quite clear in the list discussion, even if it is
still a bit vague in the PEP), the use case for *retaining* the host
information on the network object hasn't been well articulated at all.

The closest anyone has come to describing a use case is an indirect
comment via Guido that leaving out the attribute would involve real code
having to find somewhere else to stash the original address details
(e.g. by passing around an IPAddres/IPNetwork tuple rather than just an
IPNetwork object).


Ah, thanks---I'd missed that bit. ?So the .ip attribute is mainly for
backwards compatibility with existing uses/users of ipaddr. ?I guess
that makes sense, then. ?In particular, if it's suggested that new code
shouldn't make use of the .ip attribute, then the list/dict membership
problems described above can't arise.


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. Since this
is just one extra attribute on an IPNetwork object I don't think that
adding extra classes which only differ from the IPvXNetwork classes in
having this one extra attribute is worthy.


I don't believe anyone ever suggested adding a class that differed from
IPvXNetwork by the presence or absence of an 'ip' attribute.  The two
approaches(*) suggested were:

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).

2) add a class that differs from IPvXAddress by having a 'network'
attribute that points (possibly lazily) to an IPvXNetwork object,
and perhaps 'netmask' and 'hostmask' attributes.

Especially after my experience with writing a real example program, I
prefer (1).

--David

(*) For completeness there was also a third approach: add a 'network'
attribute to IPvXAddress that would be None if there were no associated
netmask.  Conceptual problems with this were raised which I won't
summarize; IMO it would only be slightly better than IPvXNetwork having an
'.ip' attribute.___
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] PEP 389: argparse - new command line parsing module

[Andrew McNabb]

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 same help text.  This is the way bzr does it for 
> example and it works great.

In some commands, options as well as subcommands can change subsequent
parsing.  The iptables command is a good example of a command-line
program that follows this practice.  From the man page:

  after [a module name is specified], various extra command line options
  become available, depending on the specific module.  You can specify
  multiple extended match modules in one line, and you can use the -h or
  --help options after the module has been specified to receive help
  specific to that module.

In the case of iptables, module names are specified as options, not as
subcommands.

>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)?

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.
I'm pretty sure that bzr dynamically loads modules this way.  Can
argparse help with this?

Sorry for all of the questions.  I ask them because I have some
experience with adding the above features to optparse, and it was a lot
of work to get it right.  It also seems like there are a lot of programs
that need to load modules dynamically.  I would be really excited if
argparse made this easier than optparse did.


-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
___
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] PEP 389: argparse - new command line parsing module

[Robert Kern]

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 --help

to basically print the same help text.  This is the way bzr does it for
example and it works great.


In some commands, options as well as subcommands can change subsequent
parsing.  The iptables command is a good example of a command-line
program that follows this practice.  From the man page:

   after [a module name is specified], various extra command line options
   become available, depending on the specific module.  You can specify
   multiple extended match modules in one line, and you can use the -h or
   --help options after the module has been specified to receive help
   specific to that module.

In the case of iptables, module names are specified as options, not as
subcommands.


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)?


I have not done so, but I suspect so. The implementation of .add_subparsers() 
adds to the positional argument list, but one could be written to append to the 
option list.



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.
I'm pretty sure that bzr dynamically loads modules this way.  Can
argparse help with this?


Not out-of-box, but it looks fairly straightforward to plug in. The subparser 
logic is mostly encapsulated in the _SubparsersAction class. You can register a 
new class for it:


parser.register('action', 'parsers', MySubParsersAction)

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

___
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] Announcing PEP 3136

[Yuvgoog Greenle]

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
include when the list was empty?)
3. When the loop didn't exit because of a break statement.

HINTS: The way django does it is opposite the way python does it and there
may be more than one correct answer.

Any chances of cleaning this one up for python 4? I'm not sure how though I
have a few ideas.

On Tue, Sep 29, 2009 at 11:47 PM, Guido van Rossum  wrote:

> On Tue, Sep 29, 2009 at 1:20 PM, Hatem Nassrat  wrote:
> > Tue Jul 3 10:14:17 CEST 2007, Guido van Rossum wrote:
> >> On 6/30/07, Matt Chisholm  wrote:
> >> > I've created and submitted a new PEP proposing support for labels in
> >> > Python's break and continue statements.  Georg Brandl has graciously
> >> > added it to the PEP list as PEP 3136:
> >> >
> >> > http://www.python.org/dev/peps/pep-3136/
> >>
> >> I think this is a good summary of various proposals that have been
> >> floated in the past, plus some new ones. As a PEP, it falls short
> >> because it doesn't pick a solution but merely offers a large menu of
> >> possible options. Also, there is nothing about implementation yet.
> >>
> >> However, I'm rejecting it on the basis that code so complicated to
> >> require this feature is very rare. In most cases there are existing
> >> work-arounds that produce clean code, for example using 'return'.
> >
> > I agree that this feature will only serve as a quick hack and in many
> > cases it would be misused and ugly code will be the result. However,
> > it seems that there are some shortcuts that have sneaked into python
> > (I am a fairly new Python programmer, only since late 2.4, so don't
> > shoot me). The specific one of which I speak about is:
> >
> > while_stmt ::=  "while" expression ":" suite
> >["else" ":" suite]
> >
> > for_stmt ::=  "for" target_list "in" expression_list ":" suite
> >  ["else" ":" suite]
> >
> > try1_stmt ::=  "try" ":" suite
> >   ("except" [expression ["as" target]] ":" suite)+
> >   ["else" ":" suite]
> >   ["finally" ":" suite]
> >
> > All these else's seem like shortcuts to me. I did find a use for them,
> > once I found out they existed, but I get butterflies whenever I do.
>
> In English, butterflies are usually a good thing (they mean you'e in love).
>
> These else clauses (assuming you're talking about that) have been in
> the language pretty much forever. The combined except/finally clause
> is newer, it was added because Java allows it and it was actually a
> pretty common usage.
>
> --
> --Guido van Rossum (home page: http://www.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/ubershmekel%40gmail.com
>
___
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] Announcing PEP 3136

[Michael Foord]

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 empty then yes. If you mean 
something else then explain.


2. When the loop terminates through exhaustion of the list (does this 
include when the list was empty?)

Yes.

3. When the loop didn't exit because of a break statement.



No.

This is pretty much the definition of the else statement semantics and 
are clearly defined.


HINTS: The way django does it is opposite the way python does it and 
there may be more than one correct answer.


If you mean the Django template language does it differently from Python 
then you'll have to speak to the Django guys. The Django template 
language may be inspired by Python and written in Python but it isn't 
Python and has no obligation to use the same semantics. Python is very 
clear.


Any chances of cleaning this one up for python 4? I'm not sure how 
though I have a few ideas.


See above. The else statement semantics for both loops and exception 
handling are extremely useful and don't need cleaning up. If you have 
further ideas then the Python-ideas list is the right place to discuss 
potential language changes or additions.


All the best,


Michael Foord

On Tue, Sep 29, 2009 at 11:47 PM, Guido van Rossum > wrote:


On Tue, Sep 29, 2009 at 1:20 PM, Hatem Nassrat mailto:hnass...@gmail.com>> wrote:
> Tue Jul 3 10:14:17 CEST 2007, Guido van Rossum wrote:
>> On 6/30/07, Matt Chisholm http://theory.org>> wrote:
>> > I've created and submitted a new PEP proposing support for
labels in
>> > Python's break and continue statements.  Georg Brandl has
graciously
>> > added it to the PEP list as PEP 3136:
>> >
>> > http://www.python.org/dev/peps/pep-3136/
>>
>> I think this is a good summary of various proposals that have been
>> floated in the past, plus some new ones. As a PEP, it falls short
>> because it doesn't pick a solution but merely offers a large
menu of
>> possible options. Also, there is nothing about implementation yet.
>>
>> However, I'm rejecting it on the basis that code so complicated to
>> require this feature is very rare. In most cases there are existing
>> work-arounds that produce clean code, for example using 'return'.
>
> I agree that this feature will only serve as a quick hack and in
many
> cases it would be misused and ugly code will be the result. However,
> it seems that there are some shortcuts that have sneaked into python
> (I am a fairly new Python programmer, only since late 2.4, so don't
> shoot me). The specific one of which I speak about is:
>
> while_stmt ::=  "while" expression ":" suite
>["else" ":" suite]
>
> for_stmt ::=  "for" target_list "in" expression_list ":" suite
>  ["else" ":" suite]
>
> try1_stmt ::=  "try" ":" suite
>   ("except" [expression ["as" target]] ":" suite)+
>   ["else" ":" suite]
>   ["finally" ":" suite]
>
> All these else's seem like shortcuts to me. I did find a use for
them,
> once I found out they existed, but I get butterflies whenever I do.

In English, butterflies are usually a good thing (they mean you'e
in love).

These else clauses (assuming you're talking about that) have been in
the language pretty much forever. The combined except/finally clause
is newer, it was added because Java allows it and it was actually a
pretty common usage.

--
--Guido van Rossum (home page: http://www.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/ubershmekel%40gmail.com




___
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/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
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] PEP 389: argparse - new command line parsing module

[Vinay Sajip]

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 agree - it's just an approach which shows some promise and is worth exploring.
I'm not suggesting jumping in with both feet. But it does show about getopt that
perhaps there's life in the old dog yet ;-)

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] PEP 3144 review.

[Martin v. Löwis]

> 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 puzzling that non of the readers here
can think of any, and the continued assertion that use cases do exist
without them being presented is somewhat disturbing.

Regards,
Martin
___
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] PEP 389: argparse - new command line parsing module

[Steven Bethard]

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 be a nice feature.

> 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.
> I'm pretty sure that bzr dynamically loads modules this way.  Can
> argparse help with this?

You can probably already do this. I'm not 100% sure what you want to
do, but it's certainly possible to define an argparse.Action that
loads a module when it's invoked. It might look something like::

class MyAction(argparse.Action):
def __call__(self, parser, namespace, value, option_string=None):
mod = __import__(value) # or whatever

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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] transitioning from % to {} formatting

[Nick Coghlan]

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 format
> strings, how should that API use newstyle_formatstr or
> oldstyle_formatstr to make this transition?

The problem is that many (most?) of the problematic APIs (such as
logging) will have multiple users in a given application, so getting the
granularity of any behavioural switches right is going to be difficult.

Providing a formatstr() type that makes .__mod__() work based on a
.format() style string (and a formatmod() type that does the opposite)
would allow for extremely fine-grained decision making, since every
format string will either be an ordinary str instance or else an
instance of the formatting subclass.

(Note that the primary use case for both proposed types is an
application developer adapting between two otherwise incompatible third
party libraries - the choice of class just changes based on whether the
old code being adapted is the code invoking mod on a format string or
the code providing a format string that expects to be used with the mod
operator).

I don't see any way for delayed formatting of "normal" strings in any
existing API to move away from %-formatting except via a long and
painful deprecation process (i.e. first warning when bare strings are
used for a release or two, then switching entirely to the new formatting
method) or by duplicating the API and maintaining the two interfaces in
parallel for the foreseeable future.

As Paul noted, the two proposed classes may also be useful to the
library developer during such a transition process - they could accept
strings in the "wrong" format just by wrapping them appropriately rather
than having to maintain the parallel APIs all the way through the
software stack.

Probably worth letting these concepts bake for a while longer, but it
definitely be nice to do *something* to help enable this transition in
2.7/3.2.

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] PEP 3144 review.

[Peter Moody]

[...@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 was 192.168.1.100.
having a separate class or two for this is overly burdensome in my
mind. FWIW, netaddr does the same thing.

Cheers,
/peter

On Wed, Sep 30, 2009 at 2:34 PM, "Martin v. Löwis"  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.
>
> I, and probably others, would really, REALLY like to see one such
> "common use case". I do find it puzzling that non of the readers here
> can think of any, and the continued assertion that use cases do exist
> without them being presented is somewhat disturbing.
>
> Regards,
> Martin
> ___
> 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/python-dev%40hda3.com
>
___
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] PEP 3144 review.

[Raymond Hettinger]

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 find it puzzling that non of the readers here
can think of any, and the continued assertion that use cases do exist
without them being presented is somewhat disturbing.


A concrete use case would help put the discussion on a better technical footing.

FWIW, it doesn't look like any of the competing packages ever
found a need to add support for this yet-to-be-presented use case:  
http://code.google.com/p/netaddr/wiki/YetAnotherPythonIPModule




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] PEP 3144 review.

[Peter Moody]

[...@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]
>>
>> I, and probably others, would really, REALLY like to see one such
>> "common use case". I do find it puzzling that non of the readers here
>> can think of any, and the continued assertion that use cases do exist
>> without them being presented is somewhat disturbing.
>
> A concrete use case would help put the discussion on a better technical
> footing.
>
> FWIW, it doesn't look like any of the competing packages ever
> found a need to add support for this yet-to-be-presented use case:
>  http://code.google.com/p/netaddr/wiki/YetAnotherPythonIPModule

netaddr actually does have support for this.

>>> import netaddr
>>> netaddr.IPNetwork('1.1.1.1/24').ip
IPAddress('1.1.1.1')
>>>

cheers,
/peter

> 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/python-dev%40hda3.com
>
___
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] PEP 3144 review.

[Daniel Stutzbach]

.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 forcing the user to decide what metadata
to store.  Every time I've ever needed to store an IP address or a network,
I've always need to store a bunch of other affiliated data with it.  E.g.:

class GnutellaPeer:
# IP address, port, timestamp, and dozen of other fields

class NetworkInterface:
   # IP address, subnet mask, name, MAC address, etc.

class Route:
   # interface, IP address, subnet mask, gateway address, route priority

Is it such a burden for the programmer to store one extra field in the class
they will inevitably write?

For that matter, I do not see the advantage to an IPNetwork class that saves
the programmer from having to separately store the IP address and subnet
mask.  Maybe I am biased by my background: I learned network programming in
C, and I think of an IP address as little more than an integer type with a
special string representation.

People have voiced support for the IPNetwork class and for the occasional
utility of an .ip field.  I assume they have good use cases.  It would be
nice if the use cases were collected into the PEP, in a clear and articulate
way.  Preferably by someone other than ipaddr author, for whom the use cases
are understandably a bit too obvious to explain at length with
exasperation.  It aught to be easy to justify the functionality of the
library, if the use cases are clearly articulated.

The current PEP begins by noting that many other IP address libraries are
available, but doesn't describe what makes ipaddr unique or superior other
than a claim to being lightweight.  After downloading several of the other
IP address libraries (http://bit.ly/483Yw4), ipaddr appears to be the second
largest, after the huge netaddr package.
I worry that this discussion has focused too much on the details of ipaddr
(and the false dichotomy of "ipaddr versus nothing"), without properly
tackling the question of "What use-cases for IP addresses are sufficiently
universal* that they belong in the standard library?"

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Python 2.6.3rc1 available

[Ben Finney]

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 similar. I hope this signifies a trend toward
using the more accurate term “available” for announcing availability of
anything that's not an actual release.

-- 
 \ “Guaranteed to work throughout its useful life.” —packaging for |
  `\  clockwork toy, Hong Kong |
_o__)  |
Ben Finney


pgp5dDFVVkuU1.pgp
Description: 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] PEP 389: argparse - new command line parsing module

[Andrew McNabb]

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.
> > I'm pretty sure that bzr dynamically loads modules this way.  Can
> > argparse help with this?
> 
> You can probably already do this. I'm not 100% sure what you want to
> do, but it's certainly possible to define an argparse.Action that
> loads a module when it's invoked. It might look something like::
> 
> class MyAction(argparse.Action):
> def __call__(self, parser, namespace, value, option_string=None):
> mod = __import__(value) # or whatever

This looks much easier than what I was able to do in optparse.  Cool.

-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
___
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] transitioning from % to {} formatting

[Vinay Sajip]

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 from the logging
> docs:
> 
> logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - %(message)s")
> 
> We'd like to support both this style as well as the following style:
> 
> logging.Formatter("{asctime} - {name} - {levelname} - {message}")
> 

In logging at least, there are two different places where the formatting issue
crops up.

The first is creating the "message" part of the the logging event, which is
made up of a format string and arguments.

The second is the one Steven's mentioned: formatting the message along with
other event data such as time of occurrence, level, logger name etc. into the
final text which is output.

Support for both % and {} forms in logging would need to be considered in
these two places. I sort of liked Martin's proposal about using different
keyword arguments, but apart from the ugliness of "dicttemplate" and the fact
that "fmt" is already used in Formatter.__init__ as a keyword argument, it's
possible that two different keyword arguments "fmt" and "format" both referring
to format strings might be confusing to some users.

Benjamin's suggestion of providing a flag to Formatter seems slightly better,
as it doesn't change what existing positional or keyword parameters do, and
just adds an additional, optional parameter which can start off with a default
of False and transition to a default of True.

However, AFAICT these approaches only cover the second area where formatting
options are chosen - not the creation of the message from the parameters passed
to the logging call itself. 

Of course one can pass arbitrary objects as messages which contain their own
formatting logic. This has been possible since the very first release but I'm
not sure that it's widely used, as it's usually easier to pass strings. So
instead of passing a string and arguments such as

logger.debug("The %s is %d", "answer", 42)

one can currently pass, for a fictitious class PercentMessage,

logger.debug(PercentMessage("The %s is %d", "answer", 42))

and when the time comes to obtain the formatted message, LogRecord.getMessage
calls str() on the PercentMessage instance, whose __str__ will use %-formatting
to get the actual message.

Of course, one can also do for example

logger.debug(BraceMessage("The {} is {}", "answer", 42))

where the __str__() method on the BraceMessage will do {} formatting.

Of course, I'm not suggesting we actually use the names PercentMessage and
BraceMessage, I've just used them there for clarity.

Also, although Raymond has pointed out that it seems likely that no one ever
needs *both* types of format string, what about the case where application A
depends on libraries B and C, and they don't all share the same preferences
regarding which format style to use? ISTM no-one's brought this up yet, but it
seems to me like a real issue. It would certainly appear to preclude any
approach that configured a logging-wide or logger-wide flag to determine how to
interpret the format string.

Another potential issue is where logging events are pickled and sent over
sockets to be finally formatted and output on different machines. What if a
sending machine has a recent version of Python, which supports {} formatting,
but a receiving machine doesn't? It seems that at the very least, it would
require a change to SocketHandler and DatagramHandler to format the "message"
part into the LogRecord before pickling and sending. While making this change
is simple, it represents a potential backwards-incompatible problem for users
who have defined their own handlers for doing something similar.

Apart from thinking through the above issues, the actual formatting only
happens in two locations - LogRecord.getMessage and Formatter.format - so
making the code do either %- or {} formatting would be simple, as long as it
knows which of % and {} to pick.

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 y'all think?

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] Announcing PEP 3136

[Terry Reedy]

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 c:
  x()
else:
  y()

is equivalent to

label 1:
if c:
  x()
  goto: 1
else"
  y()

The else clause fires (once) if and when the if/while condition 
evaluates as false. Break and continue are restricted *unconditional* 
goto statements, and so *cannot* trigger an else clause.


In for loops, the implied condition is 'there is another item in the 
collection represented by the iterable'.


For any more, move to another list.

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] transitioning from % to {} formatting

[Brett Cannon]

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 provide
>> some sort of transition plan. Consider an example from the logging
>> docs:
>>
>> logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - %(message)s")
>>
>> We'd like to support both this style as well as the following style:
>>
>> logging.Formatter("{asctime} - {name} - {levelname} - {message}")
>>
>
> In logging at least, there are two different places where the formatting issue
> crops up.
>
> The first is creating the "message" part of the the logging event, which is
> made up of a format string and arguments.
>
> The second is the one Steven's mentioned: formatting the message along with
> other event data such as time of occurrence, level, logger name etc. into the
> final text which is output.
>
> Support for both % and {} forms in logging would need to be considered in
> these two places. I sort of liked Martin's proposal about using different
> keyword arguments, but apart from the ugliness of "dicttemplate" and the fact
> that "fmt" is already used in Formatter.__init__ as a keyword argument, it's
> possible that two different keyword arguments "fmt" and "format" both 
> referring
> to format strings might be confusing to some users.
>
> Benjamin's suggestion of providing a flag to Formatter seems slightly better,
> as it doesn't change what existing positional or keyword parameters do, and
> just adds an additional, optional parameter which can start off with a default
> of False and transition to a default of True.
>
> However, AFAICT these approaches only cover the second area where formatting
> options are chosen - not the creation of the message from the parameters 
> passed
> to the logging call itself.
>
> Of course one can pass arbitrary objects as messages which contain their own
> formatting logic. This has been possible since the very first release but I'm
> not sure that it's widely used, as it's usually easier to pass strings. So
> instead of passing a string and arguments such as
>
> logger.debug("The %s is %d", "answer", 42)
>
> one can currently pass, for a fictitious class PercentMessage,
>
> logger.debug(PercentMessage("The %s is %d", "answer", 42))
>
> and when the time comes to obtain the formatted message, LogRecord.getMessage
> calls str() on the PercentMessage instance, whose __str__ will use 
> %-formatting
> to get the actual message.
>
> Of course, one can also do for example
>
> logger.debug(BraceMessage("The {} is {}", "answer", 42))
>
> where the __str__() method on the BraceMessage will do {} formatting.
>
> Of course, I'm not suggesting we actually use the names PercentMessage and
> BraceMessage, I've just used them there for clarity.
>
> Also, although Raymond has pointed out that it seems likely that no one ever
> needs *both* types of format string, what about the case where application A
> depends on libraries B and C, and they don't all share the same preferences
> regarding which format style to use? ISTM no-one's brought this up yet, but it
> seems to me like a real issue. It would certainly appear to preclude any
> approach that configured a logging-wide or logger-wide flag to determine how 
> to
> interpret the format string.
>
> Another potential issue is where logging events are pickled and sent over
> sockets to be finally formatted and output on different machines. What if a
> sending machine has a recent version of Python, which supports {} formatting,
> but a receiving machine doesn't? It seems that at the very least, it would
> require a change to SocketHandler and DatagramHandler to format the "message"
> part into the LogRecord before pickling and sending. While making this change
> is simple, it represents a potential backwards-incompatible problem for users
> who have defined their own handlers for doing something similar.
>
> Apart from thinking through the above issues, the actual formatting only
> happens in two locations - LogRecord.getMessage and Formatter.format - so
> making the code do either %- or {} formatting would be simple, as long as it
> knows which of % and {} to pick.
>
> 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 y'all think?

I personally prefer the keyword argument approach to act as a flag,
but that's me.

As for the PercentMessage/BraceMessage, I would make sure that you
just simply take the string format and simply apply the arguments
later to cut down on the amount of parentheses butting up against each
other: ``logger.debug(BraceMessage("The {} is {}"), "answer", 42)``.
It's still an acceptable solution 

Re: [Python-Dev] transitioning from % to {} formatting

[Antoine Pitrou]

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 y'all think?

What about the proposal I made earlier?
(support for giving a callable, so that you pass the "{foobar}".format method
when you want new-style formatting)



___
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] PEP 3144 review.

[Stephen J. Turnbull]

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
3.  (controversial) providing the function in (2) as a method or
constructor
4.  holding certain information associated with a network such as
a. broadcast address
b. (controversial) the arbitrary address from (2) (I count this as
   obvious because I'm a packrat and hate to throw away any data,
   but really if generated as in 2 I see no use case)
5.  providing an iterator for the addresses in the network.

Note that (1) and (2) have analogous use cases for IPv?Address.

 > and for the occasional utility of an .ip field.  I assume they have
 > good use cases.

[Please don't do that, not even ironically.  90% of the heat in this
thread has come because people discussed proposed syntax without
agreeing on a common use case to compare the semantics to.]

The only use case I can imagine for .ip is to represent a single
gateway:

def make_gateway(network, gateway):
gw = IPv4Network(network)# eg network = '192.168.1.0/0'
gw.ip = IPv4Address(gateway).ip  # eg gateway = '192.168.2.1'
return gw

Note that this usage *cannot* be served by parsing "denormalized
network descriptions" as the gateway address (ie, make_gateway cannot
be a one-argument function).  I did think about a use case like that
for DNS SRV records, but servers are looked up by service, not by
network, in most cases.  So gateways are really the only service that
fits this model.

Also, it seems to me that this usage is well-served by the change to
the definition of __eq__ to compare .network and .prefixlen, viz.

def find_gateway_address(network, gateway_list):
"raises ValueError if no gateway known for network"
# it's interesting that there's no sequence method for this
return gateway_list[gateway_list.index(network)].ip

 > I worry that this discussion has focused too much on the details of
 > ipaddr (and the false dichotomy of "ipaddr versus nothing"),

It's not a false dichotomy; this PEP proposes adding ipaddr, not any
other library.  Of course if ipaddr needs additional functionality, it
should be added before approval.  But you seem to question whether any
of the functionality is necessary, and I don't recall any posts of the
form, "this is really sweet, but it needs salt".

 > without properly tackling the question of "What use-cases for IP
 > addresses are sufficiently universal* that they belong in the
 > standard library?"

I think that the use cases given above are pretty universal.  The
string parsing cases alone give sufficient rationale for existence of
at least one class, and since addresses and networks are conceptually
different (for me, anyway), I am happy to have two different classes.

___
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] transitioning from % to {} formatting

[Vinay Sajip]

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="Python", msg="Buildbots are down")

This seems perhaps usable for a Formatter instantiation (infrequent) but a
problem for the case where you want to convert format_str + args -> message
(potentially frequent, and less readable). Another problem is that logging
calls already use keyword arguments (extra, exc_info) and so backward
compatibility might be compromised. It also feels like passing a callable could
encourage patterns of usage which restrict our flexibility for future changes:
we want for now to just allow choosing between % and {}, but a callable can do
anything. That's more flexible, to be sure, but more specialized formatting
requirements are already catered for using e.g. the PercentMessage/BraceMessage
approach.

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] transitioning from % to {} formatting

[Vinay Sajip]

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  
> strings, and all I can use is %-strings, it's almost guaranteed that I  
> will have bugs because a translator forgot the trailing 's'.  This  
> exactly the motivation that led to PEP 292 $-strings.
> 
> In fact, while we're at it, it would be kind of cool if I could use $- 
> strings in log templates.  Antoine's idea of accepting a callable  
> might fit that bill nicely.

You're already covered if you use the PercentMessage/BraceMessage approach I
mentioned elsewhere in this thread. Suppose:

#Just typing this in, it's not tested or anything
class DollarMessage:
def __init__(self, fmt, *args, **kwargs):
self.fmt = fmt
self.args = args
self.kwargs = kwargs

def __str__(self):
return string.Template(self.fmt).substitute(*args, **kwargs)



___
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