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

2009-10-02 Thread Steven Bethard 
On Thu, Oct 1, 2009 at 10:49 PM, Terry Reedy  wrote:
> As someone who likes .format() and who already uses such bound methods to
> print, such as in
>
> emsg = "...".format
> ...
>   if c: print(emsg(arg, barg))
>
> I find this **MUCH** preferable to the ugly and seemingly unnecessary
> wrapper class idea being bandied about. This would be scarcely worse than
> passing the string itself.

But it's not much of a transition plan. Or are you suggesting:

(1) Make API accept callables
(2) Issue warnings for regular strings
(3) Throw exceptions for regular strings
(4) Allow regular strings again, but assume {}-style 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] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

2009-10-02 Thread Ronald Oussoren 
 
On Friday, 02 October, 2009, at 04:07AM, "INADA Naoki"  
wrote:
>I found this hg's issue.
>http://mercurial.selenic.com/bts/msg8375
>
>I think below fix is not enabled on Mac OS X.
>http://svn.python.org/view/python/trunk/Include/pyport.h?view=diff&pathrev=43219&r1=36792&r2=36793
>
>I can't confirm it because I am not Mac OS X user.
>Can anyone confirm it?

Do you have a testcase that shows what the problem is?

Ronald

___
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

2009-10-02 Thread Brett Cannon 
On Thu, Oct 1, 2009 at 15:19, Steven Bethard  wrote:
> On Thu, Oct 1, 2009 at 11:03 AM, Brett Cannon  wrote:
>> So I created this last night:
>>
>> import collections
>>
>> class braces_fmt(str):
>>
>>    def __mod__(self, stuff):
>>        if isinstance(stuff, tuple):
>>            return self.__class__(self.format(*stuff))
>>        elif isinstance(stuff, collections.Mapping):
>>            return self.__class__(self.format(**stuff))
>>        else:
>>            return self.__class__(self.format(stuff))
>>
>> The biggest issue is that ``"%s" % {'a': 42}`` substitutes the dict
>> instead of throwing an error that str.format() would do with the code
>> above. But what's nice about this is I think I can use this now w/ any
>> library that expects % interpolation and it should basically work.
>
> I see how this could allow a user to supply a {}-format string to an
> API that accepts only %-format strings. But I still don't see the
> transition strategy for the API itself. That is, how does the %-format
> API use this to eventually switch to {}-format strings? Could someone
> please lay it out for me, step by step, showing what happens in each
> version?

First off, a wrapper like this I think is a temporary solution for
libraries that do not have any transition strategy, not a replacement
for one that is thought out (e.g. using a flag when appropriate). With
that said, you could transition by:

1. Nothing changes as hopefully the wrapper works fine (as people are
pointing out, though, my approach needs to override __str__() to
return 'self', else the str type will just return what it has
internally in its buffer).

2. Raise a deprecation warning when ``isinstance(ob, brace_fmt)`` is
false. When a class is passed in that is a subclass of brace_fmt, call
ob.format() on it.

3. Require the subclass.

4. Remove the requirement and always call ob.format().

-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] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

2009-10-02 Thread INADA Naoki 
> Do you have a testcase that shows what the problem is?
>
> Ronald

>>> s = '\xa0'
>>> assert s.strip() == s
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
'en_US.UTF-8'
>>> assert s.strip() == s

Second assert failed on Snow Leopard.

-- 
Naoki INADA  
___
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

2009-10-02 Thread Antoine Pitrou 
Steven Bethard  gmail.com> writes:
> 
> But it's not much of a transition plan. Or are you suggesting:

The question is why we want a transition plan that will bother everyone with no
tangible benefits for the user.

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

2009-10-02 Thread Barry Warsaw 

On Oct 2, 2009, at 5:34 AM, Antoine Pitrou wrote:


Steven Bethard  gmail.com> writes:


But it's not much of a transition plan. Or are you suggesting:


The question is why we want a transition plan that will bother  
everyone with no

tangible benefits for the user.


Forcing a transition to {}-strings might have limited usefulness, but  
enabling their use has clear benefits.  You just then have to decide  
how important TOOWTDI is.


-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] Summary of Python tracker Issues

2009-10-02 Thread Python tracker 

ACTIVITY SUMMARY (09/25/09 - 10/02/09)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2410 open (+17) / 16447 closed (+24) / 18857 total (+41)

Open issues with patches:   958

Average duration of open issues: 673 days.
Median duration of open issues: 430 days.

Open Issues Breakdown
   open  2376 (+17)
pending33 ( +0)

Issues Created Or Reopened (44)
___

Mismatching use of memory APIs   09/28/09
CLOSED http://bugs.python.org/issue6836reopened r.david.murray  
  
   patch   

threading.local subclasses don't cleanup their state and it gets 09/29/09
CLOSED http://bugs.python.org/issue6990reopened pitrou  
  
   patch, needs review 

PEP 314 inconsistency (authors/author/maintainer)09/28/09
   http://bugs.python.org/issue6992reopened techtonik   
  
   

Python 3.1 interpreter Fatal Error on windows with unknown encod 09/25/09
CLOSED http://bugs.python.org/issue6995created  bahaelaila7 
  
   

Python 2.6.2 & 3.1.1 Installer   09/25/09
CLOSED http://bugs.python.org/issue6996created  deepakp 
  
   

python26 compiled on snow leopard x86_64 09/25/09
CLOSED http://bugs.python.org/issue6997created  monway  
  
   

Bug in Tutorial (introduction.rst)   09/25/09
CLOSED http://bugs.python.org/issue6998created  cofi
  
   

TypeError in pathfix.py  09/25/09
CLOSED http://bugs.python.org/issue6999created  amcnabb 
  
   patch   

optional second argument of string.capwords not documented   09/25/09
CLOSED http://bugs.python.org/issue7000created  MLModel 
  
   

turtle.py bug-fixes, backported from 3.1 [issue5923] 09/25/09
CLOSED http://bugs.python.org/issue7001created  gregorlingl 
  
   patch   

help me to set variables - 64 bit09/26/09
CLOSED http://bugs.python.org/issue7002created  ashish  
  
   

finish documentation of user local paths 09/26/09
   http://bugs.python.org/issue7003created  benjamin.peterson   
  
   

Py_RETURN_BOOL() convenience macro   09/27/09
CLOSED http://bugs.python.org/issue7004created  jon 
  
   patch   

ConfigParser does not handle options without values  09/27/09
   http://bugs.python.org/issue7005created  mkindahl
  
   patch   

The replacement suggested for callable(x) in py3k is not equival 09/27/09
   http://bugs.python.org/issue7006created  milko.krachounov
  
   

Tiny inconsistency in the orthography of "url encoded" in the do 09/27/09
   http://bugs.python.org/issue7007created  MLModel 
  
   

str.title() misbehaves with apostrophes  09/27/09
CLOSED http://bugs.python.org/issue7008created  nickd   
  
   

random.randint docs  09/28/09
CLOSED http://bugs.python.org/issue7009created  jgsack  
  
   

Rounding when converting float tuple to str  09/28/09
CLOSED http://bugs.python.org/issue7010created  scientist47

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

2009-10-02 Thread Steven Bethard 
On Fri, Oct 2, 2009 at 2:34 AM, Antoine Pitrou  wrote:
> Steven Bethard  gmail.com> writes:
>>
>> But it's not much of a transition plan. Or are you suggesting:
>
> The question is why we want a transition plan that will bother everyone with 
> no
> tangible benefits for the user.

I think Guido expressed my feelings pretty well:

On Wed, Sep 30, 2009 at 10:37 AM, Guido van Rossum  wrote:
> 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).

I agree with this 100% but I can't see it working unless we have some
sort of transition plan. Just saying "ok, switch your format strings
from % to {}" didn't work in Python 3.0 for various good reasons, and
I can't imagine it will work in Python 4.0 unless we have a transition
plan.

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

2009-10-02 Thread Karen Tracey 

At 05:15 PM 9/30/2009, 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.
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.


Django's template language does not have for/else, it has for/empty: 
http://docs.djangoproject.com/en/dev/ref/templates/builtins/#for-empty


This construct did come from an external snippet that used 'else' 
instead of 'empty'.  However when it was integrated into Django the 
'else' name was specifically rejected because it did the opposite of 
what for/else does in Python.


Karen

___
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

2009-10-02 Thread Raymond Hettinger 


[Steven Bethard]

. Just saying "ok, switch your format strings
from % to {}" didn't work in Python 3.0 for various good reasons, and
I can't imagine it will work in Python 4.0 unless we have a transition
plan.


Do the users get any say in this?
I imagine that some people are heavily invested in %-formatting.

Because there has been limited uptake on {}-formatting (afaict),
we still have limited experience with knowing that it is actually
better, less error-prone, easier to learn/rember, etc.   Outside
a handful of people on this list, I have yet to see anyone adopt
it as the preferred syntax. 


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

2009-10-02 Thread Antoine Pitrou 
Raymond Hettinger  rcn.com> writes:
> 
> Because there has been limited uptake on {}-formatting (afaict),
> we still have limited experience with knowing that it is actually
> better, less error-prone, easier to learn/rember, etc.

It is known to be quite slower.

The following timings are on the py3k branch:

- with positional arguments:
$ ./python -m timeit -s "s='%s %s'; t = ('hello', 'world')" "s % t"
100 loops, best of 3: 0.313 usec per loop
$ ./python -m timeit -s "f='{} {}'.format; t = ('hello', 'world')" "f(*t)"
100 loops, best of 3: 0.572 usec per loop

- with named arguments:
$ ./python -m timeit -s "s='%(a)s %(b)s'; d = dict(a='hello', b='world')" "s % 
d"
100 loops, best of 3: 0.387 usec per loop
$ ./python -m timeit -s "f='{a} {b}'.format; d = dict(a='hello', b='world')"
"f(**d)"
100 loops, best of 3: 0.581 usec per loop


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

2009-10-02 Thread Martin Geisler 
"Raymond Hettinger"  writes:

> [Steven Bethard]
>>. Just saying "ok, switch your format strings
>> from % to {}" didn't work in Python 3.0 for various good reasons, and
>> I can't imagine it will work in Python 4.0 unless we have a transition
>> plan.
>
> Do the users get any say in this?

I'm a user! :-)

I hate calling methods on string literals, I think it looks very odd to
have code like this:

  "Displaying {0} of {1} revisions".format(x, y)

Will we be able to write this as

  "Displaying {0} of {1} revisions" % (x, y)

too?

> I imagine that some people are heavily invested in %-formatting.
>
> Because there has been limited uptake on {}-formatting (afaict), we
> still have limited experience with knowing that it is actually better,
> less error-prone, easier to learn/rember, etc. Outside a handful of
> people on this list, I have yet to see anyone adopt it as the
> preferred syntax.

I've skimmed over the PEP, and the new {}-syntax seems to have some nice
features. But I've not seen it used anywhere yet.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.


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

[Python-Dev] RELEASED Python 2.6.3

2009-10-02 Thread Barry Warsaw 
On behalf of the Python community, I'm happy to announce the  
availability of Python 2.6.3.  This is the latest production-ready  
version in the Python 2.6 series.  Somewhere near 100 bugs have been  
fixed since Python 2.6.2 was released in April 2009.  Please see the  
NEWS file for all the gory details.


http://www.python.org/download/releases/2.6.3/NEWS.txt

Source tarballs, Windows installers and the Mac OS X disk image can be  
downloaded from the Python 2.6.3 page.


http://www.python.org/download/releases/2.6.3/

For more information on Python 2.6 in general, please see

http://docs.python.org/whatsnew/2.6.html

Please report bugs for any Python version in the Python tracker.

http://bugs.python.org

Enjoy,
-Barry

Barry Warsaw
ba...@python.org
Python 2.6 Release Manager
(on behalf of the entire python-dev team)



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

2009-10-02 Thread Steven Bethard 
On Fri, Oct 2, 2009 at 12:43 PM, Martin Geisler  wrote:
> I hate calling methods on string literals, I think it looks very odd to
> have code like this:
>
>  "Displaying {0} of {1} revisions".format(x, y)
>
> Will we be able to write this as
>
>  "Displaying {0} of {1} revisions" % (x, y)
>
> too?

I doubt it. One of the major complaints about the %-style formatting
was that the use of % produced (somewhat) unexpected errors because of
how operator precedence works::

>>> '{0}'.format(4 + 1)
'5'
>>> '%s' % 4 + 1
Traceback (most recent call last):
  File "", line 1, in 
TypeError: cannot concatenate 'str' and 'int' objects

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] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

2009-10-02 Thread Jan Hosang 

Confirmed on 10.6 for 2.6.3 and 2.7a0. For 3.2a0 both asserts fail.

On 02.10.2009, at 10:29, INADA Naoki wrote:


Do you have a testcase that shows what the problem is?

Ronald



s = '\xa0'
assert s.strip() == s
import locale
locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')

'en_US.UTF-8'

assert s.strip() == s


Second assert failed on Snow Leopard.

--
Naoki INADA  
___
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/jan.hosang%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] transitioning from % to {} formatting

2009-10-02 Thread Steven Bethard 
On Fri, Oct 2, 2009 at 11:56 AM, Raymond Hettinger  wrote:
> [Steven Bethard]
>> Just saying "ok, switch your format strings
>> from % to {}" didn't work in Python 3.0 for various good reasons, and
>> I can't imagine it will work in Python 4.0 unless we have a transition
>> plan.
>
> Do the users get any say in this?
> I imagine that some people are heavily invested in %-formatting.
>
> Because there has been limited uptake on {}-formatting (afaict),
> we still have limited experience with knowing that it is actually
> better, less error-prone, easier to learn/rember, etc.   Outside
> a handful of people on this list, I have yet to see anyone adopt
> it as the preferred syntax.

Sure, I guess this is a possibility too, and it could make the
transition process I have to work through for argparse much easier.
;-)

To be clear, are you suggesting that APIs that currently support only
%-formatting shouldn't bother supporting {}-formatting at all? Or are
you suggesting that they should support both, but support for
%-formatting should never go away?

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

2009-10-02 Thread Toshio Kuratomi 
On 09/29/2009 04:38 PM, Steven Bethard wrote:
> On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman  
> wrote:
>> On approximately 9/29/2009 1:57 PM, came the following characters from the
>> keyboard of Steven Bethard:
>>> If you're not using argparse to write command line applications, then
>>> I don't feel bad if you have to do a tiny bit of extra work to take
>>> care of that use case. In this particular situation, all you have to
>>> do is subclass ArgumentParser and override exit() to do whatever you
>>> think it should do.
> [snip]
>>> There is only a single method in argparse that prints things,
>>> _print_message(). So if you want it to do something else, you can
>>> simply override it in a subclass. I can make that method public if
>>> this is a common use case.
>>
>> Documenting both of these options would forestall people from thinking it is
>> only useful for console applications.
> 
> I'm totally fine with people thinking it is only useful for console
> applications. That's what it's intended for. That said, if there are
> people out there who want to use it for other applications, I'm happy
> to make things easier for them if I know concretely what they want.
> 
Note: on Unix systems, --help should still print to the terminal, not
pop up a GUI text box with the help information.  So being able to
override the behaviour might be good but it is more than a simple, GUI
vs console distinction.  Are we talking about anything else than --help
output (for the printing question)?

About exit(), I agree with others about wanting to catch the exception
myself and then choosing to exit from the code.  I'm not sure that it's
actually useful in practice, though...it might just feel cleaner but not
actually be that helpful.

-Toshio



signature.asc
Description: OpenPGP digital 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] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

2009-10-02 Thread INADA Naoki 
> Confirmed on 10.6 for 2.6.3 and 2.7a0. For 3.2a0 both asserts fail.

OK.
`s = '\xa0'` should be `s = b'\xa0'`.

Should I file a bug?

-- 
Naoki INADA  
___
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] PEP 3121

2009-10-02 Thread Andrew Svetlov 
What real status of this document?

As I figured out py3k trunk uses this ones.
Most part of 'battery included' modules don't use this feature,
leaving m_traverse, m_clear and m_free NULL pointers.

There are only exception: _io.

But looks like all underground python machinery is already ported to
support PEP.

Maybe it's good point to update PEP?
"accepted; may not be implemented yet" sounds a bit confusing.
Just insert somethere close to top of content: "Implemented by Python
itself, but builtin modules should be converted".

Next question: are where all 'python standard library' modules looks
like "not converted yet" really need to be refactored?
Or we can split this huge set to 'looks already good' and 'requires some work'?
And just add comment for every PyModuleDef definition like:
"Completely satisfy PEP 3121, signed and stamped by Martin von Loewis
and GvR".?

Last question: PEP refers to "multiple interpreters" feature of python.
This feature presented at least in 2.xx branch (don't remember about
1.xx - up to 2003 I used python as scripting language only and not
care about C interface).
I never saw usage of this one in real use cases.
Is there projects (preferable with code sources, of course)  what runs
multiple interpreter in same process?
___
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

2009-10-02 Thread Brett Cannon 
On Wed, Sep 30, 2009 at 05:29, Paul Moore  wrote:
> 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'?

Might confuse people with string.Template.

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

2009-10-02 Thread Terry Reedy 

Steven Bethard wrote:

On Thu, Oct 1, 2009 at 10:49 PM, Terry Reedy  wrote:

As someone who likes .format() and who already uses such bound methods to
print, such as in

emsg = "...".format
...
  if c: print(emsg(arg, barg))

I find this **MUCH** preferable to the ugly and seemingly unnecessary
wrapper class idea being bandied about. This would be scarcely worse than
passing the string itself.


But it's not much of a transition plan.


It is a 'plan' to transition from not being able to use the new 
formatting, which I prefer, throughout the stdlib, to being able to do so.


I believe most, even if not all, find that acceptable. Certainly, I 
think you should be able to implement the above for argparse before 
submitting it. And I would hope that 3.2, in a year, is generally 
.format usable.


This is the first step in a possible long-term replacement, but there is 
currently no consensus to do any more than this. So I think it premature 
to do any more. I would agree, for instance, that an auto-translation 
tool is needed.


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

2009-10-02 Thread Nick Coghlan 
Mark Dickinson wrote:
> 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.

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

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.

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

2009-10-02 Thread Raymond Hettinger 


[Terry Reedy]
I would agree, for instance, that an auto-translation 
tool is needed.


We should get one written.  ISTM, every %-formatting
string is directly translatable to an equivalent {}-formatting string.


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

2009-10-02 Thread Benjamin Peterson 
2009/10/2 Raymond Hettinger :
>
> [Terry Reedy]
>>
>> I would agree, for instance, that an auto-translation tool is needed.
>
> We should get one written.  ISTM, every %-formatting
> string is directly translatable to an equivalent {}-formatting string.

Yes, but not all are possible to guess with mere static analysis.



-- 
Regards,
Benjamin
___
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 3121

2009-10-02 Thread Nick Coghlan 
Andrew Svetlov wrote:
> Maybe it's good point to update PEP?
> "accepted; may not be implemented yet" sounds a bit confusing.

That's the status though - the PEP is accepted, implementation is ongoing.

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

2009-10-02 Thread Nick Coghlan 
Toshio Kuratomi wrote:
> About exit(), I agree with others about wanting to catch the exception
> myself and then choosing to exit from the code.  I'm not sure that it's
> actually useful in practice, though...it might just feel cleaner but not
> actually be that helpful.

As others have pointed out, if you want to do that then you can just
catch SystemExit.

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

2009-10-02 Thread Nick Coghlan 
Steven Bethard wrote:
> On Fri, Oct 2, 2009 at 12:43 PM, Martin Geisler  wrote:
>> I hate calling methods on string literals, I think it looks very odd to
>> have code like this:
>>
>>  "Displaying {0} of {1} revisions".format(x, y)
>>
>> Will we be able to write this as
>>
>>  "Displaying {0} of {1} revisions" % (x, y)
>>
>> too?
> 
> I doubt it. One of the major complaints about the %-style formatting
> was that the use of % produced (somewhat) unexpected errors because of
> how operator precedence works::
> 
 '{0}'.format(4 + 1)
> '5'
 '%s' % 4 + 1
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: cannot concatenate 'str' and 'int' objects
> 
> Steve

The other major problem with the use of the mod operator is the bugs
encountered with "fmt % obj" when obj happened to be a tuple or a dict.

So no, the switch to a method rather than an operator was deliberate.

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

2009-10-02 Thread Terry Reedy 

Benjamin Peterson wrote:

2009/10/2 Raymond Hettinger :

[Terry Reedy]

I would agree, for instance, that an auto-translation tool is needed.

We should get one written.  ISTM, every %-formatting
string is directly translatable to an equivalent {}-formatting string.


Yes, but not all are possible to guess with mere static analysis.


Even if perfect is not possible, decently good would probably cover a 
lot of use cases.


___
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

2009-10-02 Thread Nick Coghlan 
Raymond Hettinger wrote:
> Because there has been limited uptake on {}-formatting (afaict),
> we still have limited experience with knowing that it is actually
> better, less error-prone, easier to learn/rember, etc.   Outside
> a handful of people on this list, I have yet to see anyone adopt
> it as the preferred syntax.

A self-fulfilling prophecy if ever I heard one... uptake is limited
because there's a large legacy code base that doesn't use it and many
APIs don't support it, so we shouldn't bother trying to increase the
number of APIs that *do* support it?

I'm starting to think that a converter between the two format
mini-languages may be the way to go though.

fmt_braces is meant to provide a superset of the capabilites of
fmt_percent, so a forward converter shouldn't be too hard. A reverse
converter may have to punt with ValueError when it finds things that
cannot be expressed in the fmt_percent mini language though.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

2009-10-02 Thread Stephen J. Turnbull 
Nick Coghlan writes:

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

s/equivalence/equality/

There are several notions of equivalence in play, and all can be
implemented as methods.  The question is which one is going to be "==".
___
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

2009-10-02 Thread Bugbee, Larry 
> > Do the users get any say in this?
> 
> I'm a user! :-)
> 
> I hate calling methods on string literals, I think it looks very odd
> to have code like this:
> 
>   "Displaying {0} of {1} revisions".format(x, y)

Ugh!  Good point.  

Is Python to be an easy-to-learn-and-remember language?  I submit we are losing 
that one.  To a user, this will be confusing.  To a C programmer coming over to 
Python, especially so.  Some of what makes %-formatting easy to remember is its 
parallel in C.  

I'm conflicted.  Philosophically I like the idea of mnemonic names over 
positional variables and allowing variable values determined elsewhere to be 
inserted in print strings.  It is appealing.  

Unless the benefit is at least 2x, a change should not be made, and I don't 
think this benefit rises to where it is worth the confusion and problems.  
...and converting the legacy base.  And forget pretty, not that %-formatting is 
pretty either.  Besides, according to the bench, it is slower too.  And it will 
take editors a while before the new syntax is supported and colorized, thus 
some errors for a while.  

...and if one wants a "{" or a "}" in the printed output, one has to escape it? 
 That is -2x over wanting a "%" in the output.  

So until I see a *significant* benefit, my vote is *not* remove %-formatting.  
Make both available and if {} is to win, it will.  

___
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

2009-10-02 Thread James Y Knight 

On Oct 2, 2009, at 2:56 PM, Raymond Hettinger wrote:

Do the users get any say in this?
I imagine that some people are heavily invested in %-formatting.

Because there has been limited uptake on {}-formatting (afaict),
we still have limited experience with knowing that it is actually
better, less error-prone, easier to learn/rember, etc.   Outside
a handful of people on this list, I have yet to see anyone adopt
it as the preferred syntax.


Well, I actually think it was a pretty bad idea to introduce {}  
formatting, because %-formatting is well-known in many other  
languages, and $-formatting is used by basically all the rest. So the  
introduction of {}-formatting has always seemed silly to me, and I  
wish it had not happened.


HOWEVER, much worse than having a new, different, and strange  
formatting convention is having *multiple* formatting conventions  
arbitrarily used in different places within the language, with no  
rhyme or reason.


So, given that brace-formatting was added, and that it's been declared  
the way forward, I'd *greatly* prefer it taking over everywhere in  
python, instead of having to use a mixture.


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