Neal Norwitz wrote:
> On 8/15/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Georg Brandl schrieb:
>>> Neal will change his build scripts, so that the 2.6 and 3.0 devel
>>> documentation pages at docs.python.org will be built from these new
>>> trees soon.
>> Okay, I made the switch. I tagged the
Carl Johnson wrote:
> (First, let me apologize for diving into a bike shed discussion.)
>
> There are two proposed ways to handle custom __format__ methods:
>
>> class MyInt:
>> def __format__(self, spec):
>> if int.is_int_specifier(spec):
>> return int(self).__format__
On Thu, 16 Aug 2007 13:18:12 +1200
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Andrew James Wade wrote:
> > {1:!renewal date: %Y-%m-%d} # no special meaning for ! here.
>
> Yuck. Although it might happen to work due to reuse of
> strftime, I'd consider that bad style -- constant parts
> of the output
On 15/08/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> EXAMPLES:
>
[...]
> Examples from python3000 list:
[...]
Can I suggest that these all go into the PEP, to give readers some
flavour of what the new syntax will look like?
I'd also repeat the suggestion that these examples be posted to
comp.lang.p
Paul Moore wrote:
> On 15/08/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>> EXAMPLES:
>>
> [...]
>> Examples from python3000 list:
> [...]
>
> Can I suggest that these all go into the PEP, to give readers some
> flavour of what the new syntax will look like?
>
> I'd also repeat the suggestion that th
On 16/08/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> Currently these particular examples aren't the syntax supported by the PEP.
> It's an alternative/possibly syntax only if there is enough support for a
> serial left to right specification pattern as outlined.
Ah, I hadn't realised that. I've bee
As part of implementing PEP 3101, I need to add __format__ to object, to
achieve the equivalent of:
class object:
def __format__(self, format_spec):
return format(str(self), format_spec)
I've added __format__ to int, unicode, etc., but I can't figure out
where or how to add it to
Alex> The PEP abstract says this proposal will replace the '%' operator,
I hope this really doesn't happen. printf-style formatting has a long
history both in C and Python and is well-understood. Its few limitations
are mostly due to the binary nature of the % operator, not to the power or
Talin wrote:
> Alex Holkner wrote:
>> What is the behaviour of whitespace in a format specifier? e.g.
>> how much of the following is valid?
>>
>> "{ foo . name : 20s }".format(foo=open('bar'))
>
> Eric, it's your call :)
I'm okay with whitespace before the colon (or !, as the case may b
[EMAIL PROTECTED] schrieb:
> Alex> The PEP abstract says this proposal will replace the '%' operator,
>
> I hope this really doesn't happen. printf-style formatting has a long
> history both in C and Python and is well-understood. Its few limitations
> are mostly due to the binary nature of
Eric Smith wrote:
> Any pointers are appreciated. Something as simple as "look at foo.c" or
> "grep for __baz__" would be good enough.
look at Objects/typeobject.c and grep for PyMethodDef object_methods[]
Christian
___
Python-3000 mailing list
Pytho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 16, 2007, at 8:29 AM, [EMAIL PROTECTED] wrote:
> Alex> The PEP abstract says this proposal will replace the '%'
> operator,
>
> I hope this really doesn't happen. printf-style formatting has a long
> history both in C and Python and is w
> > Alex> The PEP abstract says this proposal will replace the '%' operator,
> [EMAIL PROTECTED]:
> > I hope this really doesn't happen. printf-style formatting has a long
> > history both in C and Python and is well-understood. Its few limitations
> > are mostly due to the binary nature of
Thanks for the detailed response.
Guido> Now on to the transition. On the one hand I always planned this
Guido> to *replace* the old %-formatting syntax, which has a number of
Guido> real problems: "%s" % x raises an exception if x happens to be a
Guido> tuple, and you have to wri
Christian Heimes wrote:
> Eric Smith wrote:
>> Any pointers are appreciated. Something as simple as "look at foo.c" or
>> "grep for __baz__" would be good enough.
>
> look at Objects/typeobject.c and grep for PyMethodDef object_methods[]
I should have mentioned that's among the things I've alre
On 8/13/07, Carl Johnson <[EMAIL PROTECTED]> wrote:
> I also like the idea of using "!r" for calling repr ...
> s = "10"
> print("{0!i:+d}".format(s)) #prints "+10"
> The !i attempts to cast the string to int. ...
> The logic is that ! commands are abbreviated functions ...
Which does the "i" me
On 16/08/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> Christian Heimes wrote:
> > look at Objects/typeobject.c and grep for PyMethodDef object_methods[]
>
> I should have mentioned that's among the things I've already tried.
[...]
> You don't see the methods in typeobject.c (__mro__, etc).
__mro__
Guido van Rossum wrote:
> While we're not copying .NET *exactly*, most of the basic ideas are
> very similar; the discussion at this point is mostly about the
> type-specific mini-languages. My proposal is to use *exactly the same
> mini-language as used in 2.x %-formatting* (but without the '%'
>
> Alex> The PEP abstract says this proposal will replace the '%' operator,
>
> I hope this really doesn't happen. printf-style formatting has a long
> history both in C and Python and is well-understood. Its few limitations
> are mostly due to the binary nature of the % operator, not to the
Paul's right. I agree it's confusing that object and type are both
defined in the same file (though there's probably a good reason, given
that type is derived from object and object is an instance of type
:-). To add methods to object, add them to object_methods in that
file. I've tested this.
On
On 8/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Thanks for the detailed response.
>
> Guido> Now on to the transition. On the one hand I always planned this
> Guido> to *replace* the old %-formatting syntax, which has a number of
> Guido> real problems: "%s" % x raises an e
On 8/16/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 16/08/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> > Currently these particular examples aren't the syntax supported by the PEP.
> > It's an alternative/possibly syntax only if there is enough support for a
> > serial left to right specification
On 8/16/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> Talin wrote:
> > Alex Holkner wrote:
> >> What is the behaviour of whitespace in a format specifier? e.g.
> >> how much of the following is valid?
> >>
> >> "{ foo . name : 20s }".format(foo=open('bar'))
> >
> > Eric, it's your call :)
>
Guido van Rossum wrote:
> Paul's right. I agree it's confusing that object and type are both
> defined in the same file (though there's probably a good reason, given
> that type is derived from object and object is an instance of type
> :-). To add methods to object, add them to object_methods in t
I have a patch against the py3k branch (http://bugs.python.org/1775604)
that adds UTF-32 codecs. On a narrow build it combines surrogate pairs
in the unicode object into one codepoint on encoding and creates
surrogate pairs for codepoints outside the BMP on decoding.
Should I apply this to the py3
On Aug 16, 2007, at 12:38 PM, Guido van Rossum wrote:
> I use it in the same way we used to refer to Python 3000 in the
> past. :-)
If we acknowledge that Python 3.0 isn't the same as Python 3000, we
don't even need a new name for it. ;-)
-Fred
--
Fred Drake
_
Walter Dörwald schrieb:
> I have a patch against the py3k branch (http://bugs.python.org/1775604)
> that adds UTF-32 codecs. On a narrow build it combines surrogate pairs
> in the unicode object into one codepoint on encoding and creates
> surrogate pairs for codepoints outside the BMP on decoding.
Talin wrote:
> Eric Smith wrote:
>> James Thiele wrote:
>>> I think the example:
>>>
>>> "My name is {0.name}".format(file('out.txt'))
> Those examples are kind of contrived to begin with. Maybe we should
> replace them with more realistic ones.
I just added this test case:
d = dat
[EMAIL PROTECTED] wrote:
> Alex> The PEP abstract says this proposal will replace the '%' operator,
[...]
I agree with Skip, too. The % printf operator is a very useful and
powerful feature. I'm doing newbie support at my university and in
#python. Newbies are often astonished how easy and po
On 8/16/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Walter Dörwald schrieb:
> > I have a patch against the py3k branch (http://bugs.python.org/1775604)
> > that adds UTF-32 codecs. On a narrow build it combines surrogate pairs
> > in the unicode object into one codepoint on encoding and crea
On 8/16/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Alex> The PEP abstract says this proposal will replace the '%' operator,
>
> [...]
>
> I agree with Skip, too. The % printf operator is a very useful and
> powerful feature. I'm doing newbie support at my uni
Eric Smith wrote:
> I should have mentioned that's among the things I've already tried.
>
> But that appears to add methods to 'type', not to an instance of
> 'object'. If you do dir(object()):
>
> You don't see the methods in typeobject.c (__mro__, etc).
>
> This is pretty much the last hurdle
[Tonight, the role of old, cranky python-dev'er will be played by
Brett Cannon. Don't take this personally, Christian, your email just
happened to be last. =)]
On 8/16/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Alex> The PEP abstract says this proposal wil
> Are you sure that you have changed the correct array?
Yes, that was the issue. I changed the wrong array. I stupidly assumed
that it was one object per file, but of course there's no valid reason
to make that assumption.
I'm sure I don't have the most best version of this coded up, but that
Paul Moore wrote:
> On 16/08/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>> Currently these particular examples aren't the syntax supported by the PEP.
>> It's an alternative/possibly syntax only if there is enough support for a
>> serial left to right specification pattern as outlined.
>
> Ah, I h
Guido van Rossum wrote:
> On 8/16/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Walter Dörwald schrieb:
>>> I have a patch against the py3k branch (http://bugs.python.org/1775604)
>>> that adds UTF-32 codecs. On a narrow build it combines surrogate pairs
>>> in the unicode object into one co
STeVe> I honestly can't see the point of keeping this::
'%-10s bought %02i apples for %3.2f' % ('John', 8, 3.78)
STeVe> 'John bought 08 apples for 3.78'
STeVe> alongside this::
'{0:-10} bought {1:02i} apples for {2:3.2f}'.format('John', 8, 3.78)
STeVe
> OK, then I'll check it into the py3k branch, and backport it to the trunk.
This raises another procedural question: are we still merging from the
trunk to the 3k branch, or are they now officially split?
If we still merge, and assuming that the implementations are
sufficiently similar and live
Brett> But how is::
Brett> "{0} is happy to see {1}".format('Brett', 'Christian')
Brett> that less easier to read than::
Brett> "%s is happy to see %s" % ('Brett', 'Christian')
Brett> ? Yes, PEP 3101 style is more to type but it isn't grievous; we
Brett> have just
Brett Cannon wrote:
> [Tonight, the role of old, cranky python-dev'er will be played by
> Brett Cannon. Don't take this personally, Christian, your email just
> happened to be last. =)]
hehe :)
I don't feel offended.
> But how is::
>
> "{0} is happy to see {1}".format('Brett', 'Christian')
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 16, 2007, at 3:52 PM, [EMAIL PROTECTED] wrote:
> STeVe> I honestly can't see the point of keeping this::
>
> '%-10s bought %02i apples for %3.2f' % ('John', 8, 3.78)
> STeVe> 'John bought 08 apples for 3.78'
>
> STeVe>
On 8/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Brett> But how is::
>
> Brett> "{0} is happy to see {1}".format('Brett', 'Christian')
>
> Brett> that less easier to read than::
>
> Brett> "%s is happy to see %s" % ('Brett', 'Christian')
>
> Brett> ? Yes, PEP 31
On 8/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> STeVe> I honestly can't see the point of keeping this::
>
> '%-10s bought %02i apples for %3.2f' % ('John', 8, 3.78)
> STeVe> 'John bought 08 apples for 3.78'
>
> STeVe> alongside this::
>
> '{0:-10
[EMAIL PROTECTED] wrote:
> Brett> But how is::
>
> Brett> "{0} is happy to see {1}".format('Brett', 'Christian')
>
> Brett> that less easier to read than::
>
> Brett> "%s is happy to see %s" % ('Brett', 'Christian')
>
> Brett> ? Yes, PEP 3101 style is more to type
On Aug 16, 2007, at 4:19 PM, Brett Cannon wrote:
> Well, for me the "realness" of Py3K is the same now as it was back
> when Guido created teh p3yk branch.
Somehow, I suspect the reality of Python 3.0 for any individual is
strong tied to the amount of time they've had to read the emails,
PEPs,
> A simple merge won't work, because in 3.0 the codec uses bytes and in
> 2.6 it uses str. Also the call to the decoding error handler has
> changed, because in 3.0 the error handler could modify the mutable input
> buffer.
So what's the strategy then? Block the trunk revision from merging?
Regar
Martin v. Löwis wrote:
>> OK, then I'll check it into the py3k branch, and backport it to the trunk.
>
> This raises another procedural question: are we still merging from the
> trunk to the 3k branch, or are they now officially split?
>
> If we still merge, and assuming that the implementations
On 8/16/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > OK, then I'll check it into the py3k branch, and backport it to the trunk.
>
> This raises another procedural question: are we still merging from the
> trunk to the 3k branch, or are they now officially split?
I plan to set up merging ag
Martin v. Löwis wrote:
>> A simple merge won't work, because in 3.0 the codec uses bytes and in
>> 2.6 it uses str. Also the call to the decoding error handler has
>> changed, because in 3.0 the error handler could modify the mutable input
>> buffer.
>
> So what's the strategy then? Block the tru
On 8/16/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
>
> >> A simple merge won't work, because in 3.0 the codec uses bytes and in
> >> 2.6 it uses str. Also the call to the decoding error handler has
> >> changed, because in 3.0 the error handler could modify the mutable i
On 8/16/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> But how is::
> "{0} is happy to see {1}".format('Brett', 'Christian')
> that less easier to read than::
> "%s is happy to see %s" % ('Brett', 'Christian')
Excluding minor aesthetics, they are equivalent.
The new format only has advanta
> I've never used svnmerge, so I don't know what the strategy for
> automatic merging would be.
Reading about svnmerge tells me that you probably should use
"svnmerge merge -r -S trunk -M" on the 3k branch;
this should record the revision from the branch as already
(manually) merged.
Regards,
Ma
On 8/16/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
[SNIP]
> You are right. I'm guilty as charged to be a participant of a red bike
> shed discussion. :) I'm seeing myself as a small Python user and
> developer who is trying to get in touch with the gods in the temple of
> python core develop
>* the new is more verbose than the old
>* the curly braces and [012]: prefixes are just syntactic sugar when
> converting old to new
>* in situations where the format string isn't a literal that mechanical
> translation from old to new won't be possible
>* lots of people
> There's one other problem that I see, though it might be minor or
> infrequent enough not to matter. %s positional placeholders are
> easily to generate programmatically than {#} placeholders. Think
> about translating this:
>
> def make_query(flag1, flag2):
> base_query = 'SELECT
> But just saying you like %s over {0} is
> like saying you don't like the decorator syntax: that's nice and all,
> but that is not a compelling reason to change the decision being made.
My guess is that the folks who object to it are, like me, folks who
primarily work in Python and C, and don't w
> I think most of these points are irrelevant. The curly braces are not
> just syntactic sugar, at least the opening brace is not; the digit
> is not syntactic sugar in the case of message translations.
Are there "computation of matching braces" problems here?
> That lots of people are familiar w
On 8/16/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 8/15/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > Okay, I made the switch. I tagged the state of both Python branches
> > before the switch as tags/py{26,3k}-before-rstdocs/.
>
> http://docs.python.org/dev/
> http://docs.python.org/dev/3.
Guido van Rossum wrote:
> The only added wrinkle is that you can also write
> {0!r} to *force* using repr() on the value.
What if you want a field width with that? Will you be
able to write {0!10r} or will it have to be {0!r:10}?
--
Greg
___
Python-3000
Jim Jewett wrote:
> You can't write int(s) if you're passing a mapping (or tuple) from
> someone else; at best you can copy the mapping and modify certain
> values.
Maybe this could be handled using a wrapper object that
takes a sequence or mapping and a collection of functions
to be applied to sp
[EMAIL PROTECTED] wrote:
> "{0} asks {1} if he is happy to see {1}".format('Brett', 'Skip',
> 'Christian')
>
> ^^^ whoops
This kind of mistake is easy to spot if the format
string is short.
If it's not short, it would be better to use names:
"{ask
Given that filenames containing spaces make things a bit more challenging
for tools like find and xargs would it be possible to get rid of them in the
Python source tree? I only see two files containing spaces at the moment:
./Mac/Icons/Disk Image.icns
./Mac/Icons/Python Folder.icns
Can
Martin v. Löwis wrote:
> (it is then flawed also in that you don't typically
> have placeholders for the result fields and table name - not sure
> whether you even can in DB-API).
It probably depends on the underlying DB, but most DB
interfaces I know of don't allow such a thing.
My biggest gripe
On 8/16/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > The only added wrinkle is that you can also write
> > {0!r} to *force* using repr() on the value.
>
> What if you want a field width with that? Will you be
> able to write {0!10r} or will it have to be {0!r:10}?
The la
I see two new tests failing tonight:
- test_xmlrpc fails on all platforms I have. This is due to several
new tests that were merged in from the trunk; presumably those tests
need changes due to str vs. bytes.
- test_codecs fails on OSX PPC only. This is in the new UTF-32 codecs;
probably a byte o
Bill Janssen schrieb:
>> I think most of these points are irrelevant. The curly braces are not
>> just syntactic sugar, at least the opening brace is not; the digit
>> is not syntactic sugar in the case of message translations.
>
> Are there "computation of matching braces" problems here?
I don't
Martin v. Löwis wrote:
> Bill Janssen schrieb:
>>> I think most of these points are irrelevant. The curly braces are not
>>> just syntactic sugar, at least the opening brace is not; the digit
>>> is not syntactic sugar in the case of message translations.
>> Are there "computation of matching brace
Martin v. Lo"wis wrote:
> Bill Janssen schrieb:
>>> I think most of these points are irrelevant. The curly braces are not
>>> just syntactic sugar, at least the opening brace is not; the digit
>>> is not syntactic sugar in the case of message translations.
>> Are there "computation of matching br
Alexandre Vassalotti schrieb:
> On 8/16/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>> On 8/15/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> > Okay, I made the switch. I tagged the state of both Python branches
>> > before the switch as tags/py{26,3k}-before-rstdocs/.
>>
>> http://docs.python.org
69 matches
Mail list logo
