Antoine Pitrou wrote:
Hi,
James Y Knight fuhm.net> writes:
- Having os.getcwdb isn't much use when you can't even run python in
the first place when the current directory has "bad" bytes in it.
I don't agree it's a similar problem. Python should be installed in a well-known
place with a s
[EMAIL PROTECTED] wrote:
In issue 3783 (http://bugs.python.org/issue3783) the question was raised
about whether or not it's worthwhile making this guarantee:
zip(d.keys(), d.values()) == d.items()
in the face of no changes to the mapping object. At issue is whether the
SQL query should for
Martin v. Löwis wrote:
I wouldn't mind letting Cython special case subtypes of str (or unicode in
Py3) *somehow*, as long as this "somewhow" proves to be a viable solution that
only applies to exactly those types *and* can be done realiably for subtypes
of subtypes. I'm just not aware of such a s
Eric Smith wrote:
I just checked in the code to close this issue
(http://bugs.python.org/issue3038). It's in both 2.6 and 3.0.
Make that http://bugs.python.org/issue3083.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.pytho
Eric Smith wrote:
Marcin ‘Qrczak’ Kowalczyk wrote:
2008/5/29 Eric Smith <[EMAIL PROTECTED]>:
I don't see it as a big problem. You can now use any prefix you want,
instead of the hard coded values that # supplied.
Except that it works incorrectly for negative numbers.
Excellent
Eric Smith wrote:
Barry?
By which I meant "Barry, what's your opinion?", not "who is Barry?"
(which I well know). Geez, I write the worst email sometimes.
ERic.
Guido van Rossum wrote:
I'd check with Barry, but given that .format() is a new feature in
the
Barry?
Guido van Rossum wrote:
I'd check with Barry, but given that .format() is a new feature in
these releases anyway and this is a pretty small addition to one tiny
bit of code I would have been okay with it if I were release manager.
On Mon, Jun 30, 2008 at 11:36 AM, Eric Smith
&l
I finally have some cycles for this. Is it okay to add '#' to hex, bin,
and oct for str.format(), even though it's now after the beta?
Eric.
Guido van Rossum wrote:
Of course.
On Fri, May 30, 2008 at 12:23 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
Guido van Rossum wro
Nick Coghlan wrote:
Doing the right thing for negative numbers is a good point. It also
means the prefix can be handled properly when dealing with aligned
fields. The following update to the standard format specifier in the PEP:
[[fill]align][#][sign][0][minimumwidth][.precision][type]
Th
Guido van Rossum wrote:
I'd be fine with adding '#' back to the formatting language for hex and oct.
And bin, I assume?
On Thu, May 29, 2008 at 5:45 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
wesley chun wrote:
On 5/29/08, Eric Smith <[EMAIL PROTECTED]> wrote:
wesley chun wrote:
On 5/29/08, Eric Smith <[EMAIL PROTECTED]> wrote:
Marcin 'Qrczak' Kowalczyk wrote:
Except that it works incorrectly for negative numbers.
wow, that is a great point. i didn't think of this either. it makes
it very inconvenient (see below) and makes
Marcin ‘Qrczak’ Kowalczyk wrote:
2008/5/29 Eric Smith <[EMAIL PROTECTED]>:
I don't see it as a big problem. You can now use any prefix you want,
instead of the hard coded values that # supplied.
Except that it works incorrectly for negative numbers.
Excellent point. If only th
wesley chun wrote:
hi,
i'm looking to duplicate this string format operator '#' functionality
with the new format(). here it is using the old string format
operator:
i = 45
'dec: %d/oct: %o/hex: %X' % (i, i, i) # no "#" means no leading "0" or
"0x/X"
'dec: 45/oct: 55/hex: 2D'
'dec:
Eric Smith wrote:
'n' is like 'g', but adds locale-specific thousands separators.
Issue 2802 (http://bugs.python.org/issue2802) points out that 'n'
formatting isn't useful for integers, because it first converts to
float. There's no way to get 1,000
'n' is like 'g', but adds locale-specific thousands separators.
Issue 2802 (http://bugs.python.org/issue2802) points out that 'n'
formatting isn't useful for integers, because it first converts to
float. There's no way to get 1,000,000 as a result, since 'g' converts
to '1e+06'.
I propose a
Guido van Rossum wrote:
> I thought I had a reasonable proposal: deprecate in 3.1, remove in
> 3.3. Adding a PendingDeprecationWarning in 3.0 would be fine. Doing
> anything in 2.6 would not be fine, except perhaps making it a
> PendingDeprecationWarning whan -3 is given.
How do you feel if I clos
Anand Balachandran Pillai wrote:
> Hi list,
>
> After updating py3k trunk to the most recent svn version
> (62349) and building Python, I am getting the following
> error while trying to start the interpreter.
>
> [EMAIL PROTECTED] ~]$ /usr/local/bin/python
> Fatal Python error: Py_Initialize: c
I've proposed on another thread the no new features are added to %
formatting, specifically the PEP 3127 (Integer Literal Support and
Syntax) '%b' formatting. It didn't generate any discussion, so I
thought I'd bring it up in its own thread.
I'd like to see us take the position that % formatti
Guido van Rossum wrote:
> I think there are too many risks with this approach, especially given
> that we're keeping % formatting mainly for backwards compatibility
> reasons. There will inevitably be corner cases where the conversion
> doesn't work exactly the same way as the old code or where the
mpatibility
> reasons. There will inevitably be corner cases where the conversion
> doesn't work exactly the same way as the old code or where the
> conversion is wrong for whatever reason, and it would be quite painful
> to change back.
>
> If 2.6 can't support %b, so be it
I'm working on issue 2416, adding %b to % formatting
(http://bugs.python.org/issue2416). It's really quite a pain,
especially in 2.6 with int and long and str and unicode.
I'm contemplating just making % formatting compute a new format string
and call str.format (or obj.__format__, or somethin
Eric Smith wrote:
> Greg Ewing wrote:
>> Charles Merriam wrote:
>>> How can I write the greatest common denominator of this code:
>>>
>>> print "Hello World!" # yes, that needs to be Unicode.
>> Something like
>>
>>from __futu
Greg Ewing wrote:
> Charles Merriam wrote:
>> How can I write the greatest common denominator of this code:
>>
>> print "Hello World!" # yes, that needs to be Unicode.
>
> Something like
>
>from __future__ import unicode_literals
>from py3k_compat import Print
>
>Print("Hello World!
Guido van Rossum wrote:
> Cool, I can live with that. Are all current __future__ statements
> still valid in 3.0?
Yes, all of them are in __future__.py. But most references to 2 of them
(nested scopes and generators) have been deleted from the C code, in
both 2.6 and 3.0.
I think it is useful
Guido van Rossum wrote:
> Cool, I can live with that. Are all current __future__ statements
> still valid in 3.0?
I believe so, yes. But I'll double check.
>
> On Thu, Mar 20, 2008 at 5:55 PM, Eric Smith
> <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
Guido van Rossum wrote:
> Really? I though 2to3 was supposed to remove all __future__ imports?
I was convinced when Christian pointed out the statement in
http://docs.python.org/lib/module-future.html:
"No feature description will ever be deleted from __future__."
Admittedly, I implemented more
Christian Heimes wrote:
> Thomas Wouters schrieb:
> > This surprises me greatly. The reason this is true in 2.x is for the
> obvious
>> backward compatibility. 3.0 is about not worrying about backward
>> compatibility. Why do we need to keep the future imports?
>>
>
> The __future__ docs say "No
Martin v. Löwis wrote:
>> Will python 2.6 have something like "from future import
>> unicode_string_literals" ?
>
> It was proposed before, I don't know whether any implementation
> on that has started.
I don't see anything in the bug tracker. I'd be willing to look at it,
if this is what we w
[EMAIL PROTECTED] wrote:
> Martin> One option that I envision is that you might keep all sources as
> Martin> 2.x, and only convert to 3.x at installation time,
>
> How can this ever work? Aren't there always going to be some
> incompatibilities which aren't covered by -3 or 2to3? Those
Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Feb 28, 2008, at 4:03 PM, Eric Smith wrote:
>
>> Barry Warsaw wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>> On Feb 28, 2008, at 2:49 PM, Christia
Barry Warsaw wrote:
>>> Okay, let's go ahead and make it official.
>>> I plan on cutting the alphas for 2.6 and 3.0 at about 6pm Eastern
>>> (UTC-5) time or 2300 UTC. Let's freeze the tree one hour prior to
>>> that: 2200 UTC Friday 29-Feb-2008.
>>
>> Argh! I was going to check the last of th
Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Feb 28, 2008, at 2:49 PM, Christian Heimes wrote:
>
>> Hey Barry!
>
> Hi Christian!
>
>> When are you planing to freeze the code of the trunk and branches/py3k
>> for the upcoming alpha releases? I'll merge the last mo
Eric Smith wrote:
> Guido van Rossum wrote:
>> If this is Py3k, perhaps the result should be a PyUnicode instead?
>
> Probably so, yes.
>
> But I can't reproduce this on a Fedora Core 6 box. I'm compiling under
> Windows now to see if I can repr
y, even if I can't reproduce it.
Eric.
>
> On Sun, Feb 24, 2008 at 1:19 PM, Eric Smith
> <[EMAIL PROTECTED]> wrote:
>> Brett Cannon wrote:
>> > test_types is triggering an assertion error::
>> >
>> > Objects/stringlib/string_format.h:497
Brett Cannon wrote:
> test_types is triggering an assertion error::
>
> Objects/stringlib/string_format.h:497: failed assertion
> `PyString_Check(result)'
>
> A *really* quick session with gdb would seem to suggest that 'result'
> is actually a str, so I don't know what is going on. Don't have
Guido van Rossum wrote:
> On Jan 27, 2008 8:16 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> eric.smith wrote:
>>> Author: eric.smith
>>> Date: Sun Jan 27 22:07:59 2008
>>> New Revision: 60376
>>>
>>> Modified:
>>>python/branches/py3k/Lib/test/test_float.py
>>>python/branches/py3k/Lib/test
Neal Becker wrote:
> Right now we have 2 rather different stdlib modules for parsing options from
> ini-style files and from command line. I believe it would be desirable to
> have one module that can handle both. Is there interest in pursuing this
> idea?
I'd be interested. I think rolling in
Christian Heimes wrote:
> Eric Smith wrote:
>> And backporting __format__ and friends back to trunk is on my pending
>> list. The fact that upgrading to Leopard broke my compilation
>> environment isn't helping me out, unfortunately.
>
> I've seen several
Mark Summerfield wrote:
> Hi,
>
> I'm using Python 30a.
>
> The docs for str.format()'s 'g' format say
> "General format. This prints the number as a fixed-point number,
> unless the number is too large, in which case it switches to 'e'
> exponent notation."
> The fixed-point format u
Facundo Batista wrote:
> 2007/11/30, Mark Summerfield <[EMAIL PROTECTED]>:
>
>> BTW I notice that decimal.Decimal() numbers can't be used with the 'e',
>> 'f', or 'g' formats. I know that these numbers aren't floating-point
>> under the hood, but this still seems a bit counter-intuitive to me.
>
Christian Heimes wrote:
> Greg Ewing wrote:
>> Christian Heimes wrote:
>>> With Python 2.5 the input and output data isn't implicitly
>>> converted
>> Are you sure that's always true? What about systems
>> where newlines aren't \n?
>
> Windows is a strange beast. As far as I can remember the OS co
Nick Coghlan wrote:
> Eric Smith wrote:
>> Eric Smith wrote:
>>> I have a patch to add __format__ to datetime.time, .date, and
>>> .datetime. For non-empty format_spec's, I just pass on to
>>> .strftime. For empty format_spec's, it returns str(sel
Eric Smith wrote:
> I have a patch to add __format__ to datetime.time, .date, and .datetime.
> For non-empty format_spec's, I just pass on to .strftime. For empty
> format_spec's, it returns str(self).
What's the best way to call str(self)?
I'm currently doin
Paul Moore wrote:
> I'd like to see the default format specified (somewhere). I note that
> the default format for datetime values seems to differ for me (on
> 3.0a1 on Windows)
>
> Python 3.0a1 (py3k:57844, Aug 31 2007, 16:54:27) [MSC v.1310 32 bit
> (Intel)] on win32
> Type "help", "copyright",
Eric Smith wrote:
> Martin v. Löwis wrote:
>>> I have a patch to add __format__ to datetime.time, .date, and .datetime.
>>> For non-empty format_spec's, I just pass on to .strftime. For empty
>>> format_spec's, it returns str(self).
>>>
>&
Martin v. Löwis wrote:
>> I have a patch to add __format__ to datetime.time, .date, and .datetime.
>> For non-empty format_spec's, I just pass on to .strftime. For empty
>> format_spec's, it returns str(self).
>>
>> I think this is the only reasonable interpretation of format_spec's for
>> da
I have a patch to add __format__ to datetime.time, .date, and .datetime.
For non-empty format_spec's, I just pass on to .strftime. For empty
format_spec's, it returns str(self).
I think this is the only reasonable interpretation of format_spec's for
datetime. Does anyone think otherwise?
E
ange these to IndexError and KeyError.
Eric.
>
> On 9/3/07, Eric Smith <[EMAIL PROTECTED]> wrote:
>> Ron Adam points out some differences in which exceptions are thrown by
>> str.format and string.Formatter. For example, on a missing positional
>> argument:
>
Ron Adam points out some differences in which exceptions are thrown by
str.format and string.Formatter. For example, on a missing positional
argument:
>>> "{0}".format()
Traceback (most recent call last):
File "", line 1, in
ValueError: Not enough positional arguments in format string
>>
Talin wrote:
> I'm looking for a volunteer who understands the Decimal class well
> enough to write a __format__ method for it. It should handle all of the
> same format specifiers as float.__format__, but it should not use the
> same implementation as float (so as to preserve accuracy.)
>
> Al
Martin v. Löwis wrote:
>>> For me on OS X, I'm still getting a failure in test_plistlib and an
>>> unexpected skip in test_ssl.
>> If it helps, the test_plistlib errors follow.
>
> In case it isn't clear: test_plistlib will fail *only* on OS X, because
> it isn't run elsewhere. So somebody with
Barry Warsaw wrote:
> For me on OS X, I'm still getting a failure in test_plistlib and an
> unexpected skip in test_ssl.
If it helps, the test_plistlib errors follow.
$ ./python.exe Lib/test/test_plistlib.py -v
test_appleformatting (__main__.TestPlistlib) ... ERROR
test_appleformattingfromlit
Georg Brandl wrote:
> Eric Smith schrieb:
>> Talin wrote:
>>> I just posted on the tracker a patch which adds extensive documentation
>>> for PEP 3101 to the Python Library Reference. This includes:
>>>
>>>str.format()
>>>format()
&
Talin wrote:
> I just posted on the tracker a patch which adds extensive documentation
> for PEP 3101 to the Python Library Reference. This includes:
>
>str.format()
>format()
>__format__
>Formatter
>format string syntax
>format specification mini-language
>
> http://bugs
Talin wrote:
> I'm looking for a volunteer who understands the Decimal class well
> enough to write a __format__ method for it. It should handle all of the
> same format specifiers as float.__format__, but it should not use the
> same implementation as float (so as to preserve accuracy.)
If no
Ron Adam wrote:
>
>
> Eric Smith wrote:
>> Ron Adam wrote:
>>>> get_field(field_name, args, kwargs, used_args)
>>>> Given a field_name as returned by parse, convert it to an object to
>>>> be formatted. The default version takes strings of
Talin wrote:
> Also I wanted to ask: How about making the built-in 'format' function
> have a default value of "" for the second argument? So I can just say:
>
>format(x)
>
> as a synonym for:
>
>str(x)
I implemented this in r57797.
Eric.
Ron Adam wrote:
>> get_field(field_name, args, kwargs, used_args)
>> Given a field_name as returned by parse, convert it to an object to be
>> formatted. The default version takes strings of the form defined in
>> the PEP, such as "0[name]" or "label.title". It records which args
>> have been
Martin v. Löwis wrote:
>>> It should still require an environment variable, say
>>> PYTHONNOERRORWINDOW, whether or not it should be considered only
>>> in debug releases, I don't know. One place to put it would be
>>> Modules/main.c (where all the other environment variables are
>>> considered).
>
Martin v. Löwis wrote:
>> New patch (still detects the debug build because the name of the C runtime
>> dll depends on it):
>
> I know it will be difficult to talk you into not using ctypes :-),
> but...
>
> I think this should go into the interpreter code itself. One problem
> with your patch is
Talin wrote:
> Eric Smith wrote:
>> Eric Smith wrote:
>>> Jim Jewett wrote:
>>
>>>> but you might want to take inspiration from the "tail" of an
>>>> elementtree node, and return the field with the literal next to it as
>>>>
Martin v. Löwis wrote:
>> I keep Py_UNICODE* pointers into this PyUnicodeObject in my iterator
>> object, and I access these pointers on subsequent calls to my next()
>> method. Is this an error? The more I think about it the more convinced
>> I am it's an error.
>
> Because the pointer may c
As part of the PEP 3101 stuff, I have an iterator that I've written in
C. It has a PyUnicodeObject* in it, which holds the string I'm parsing.
I do some parsing, return a result, do some more parsing on the next
call, etc. This code is callable from Python code.
I keep Py_UNICODE* pointers
The URL is getting mangled, it should be:
http://www.python.org/dev/buildbot/all/S-390%20Debian%203.0/builds/9
[EMAIL PROTECTED] wrote:
> The Buildbot has detected a new failure of S-390 Debian 3.0.
> Full details are available at:
> http://www.python.org/dev/buildbot/all/S-390%2520Debian%25203.0
Eric Smith wrote:
> Jim Jewett wrote:
>> but you might want to take inspiration from the "tail" of an
>> elementtree node, and return the field with the literal next to it as
>> a single object.
>>
>> (literal_text, field_name, format_spec, co
Jim Jewett wrote:
> On 8/28/07, Eric Smith <[EMAIL PROTECTED]> wrote:
>> parse(format_string)
>
>> ... returns an iterable of tuples
>> (literal_text, field_name, format_spec, conversion)
>
> Which are really either
>
> (literal_text, None
Eric Smith wrote:
> One of the things that PEP 3101 deliberately under specifies is the
> Formatter class, leaving decisions up to the implementation. Now that a
> working implementation exists, I think it's reasonable to tighten it up.
I should also have included the recipe
One of the things that PEP 3101 deliberately under specifies is the
Formatter class, leaving decisions up to the implementation. Now that a
working implementation exists, I think it's reasonable to tighten it up.
I have checked in a Formatter class that specifies the following methods
(in addi
Neal Norwitz wrote:
> There are several other known warnings on various platforms:
...
> Python/../Objects/stringlib/unicodedefs.h:26: warning: 'STRINGLIB_CMP'
> defined but not used
I fixed this warning in r57613. Unfortunately I had to change from an
inline function to a macro, but I don't see
acker?
Eric Smith wrote:
> There are a handful of remaining issues, but it works for the most part.
>
> http://bugs.python.org/issue1009
>
> Thanks to Guido and Talin for all of their help the last few days, and
> thanks to Patrick Maupin for help with the initial implementa
There are a handful of remaining issues, but it works for the most part.
http://bugs.python.org/issue1009
Thanks to Guido and Talin for all of their help the last few days, and
thanks to Patrick Maupin for help with the initial implementation.
Known issues:
Better error handling, per the PEP.
Ron Adam wrote:
>
>
> Eric Smith wrote:
>> Ron Adam wrote:
>>>> I've been re-reading the PEP, in an effort to make sure everything
>>>> is working. I realized that these tests should not pass. The PEP
>>>> says that "Format spec
Ron Adam wrote:
>> I've been re-reading the PEP, in an effort to make sure everything is
>> working. I realized that these tests should not pass. The PEP says
>> that "Format specifiers can themselves contain replacement fields".
>> The tests above have replacement fields in the field name, w
Guido van Rossum wrote:
> On 8/22/07, Eric Smith <[EMAIL PROTECTED]> wrote:
>> James Thiele wrote:
>>> In the section "Explicit Conversion Flag" of PEP 3101 it says:
>>>
>>> Currently, two explicit conversion flags are recognized:
>>&
James Thiele wrote:
> In the section "Explicit Conversion Flag" of PEP 3101 it says:
>
> Currently, two explicit conversion flags are recognized:
>
> !r - convert the value to a string using repr().
> !s - convert the value to a string using str().
> --
> It does not say what acti
Eric Smith wrote:
> Talin wrote:
>> A new version is up, incorporating material from the various discussions
>> on this list:
>>
>> http://www.python.org/dev/peps/pep-3101/
>
> self.assertEquals('{0[{1}]}'.format('abcdefg', 4), '
Greg Ewing wrote:
> Guido van Rossum wrote:
>> But how often will you need this? (You only need the !s part if you
>> don't know that the argument is a string.)
>
> Maybe I'm confused. I thought we had agreed that most
> types would delegate to str if they didn't understand
> the format, so most o
Eric V. Smith wrote:
[a duplicate message]
Please ignore this. I accidentally sent it twice.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/pyt
Guido van Rossum wrote:
> Hm, those damn dependencies. In that case I suggest adding it to sys
> instead of creating a new internal method. It could be
> sys._formatparser or whatever useful name you'd like to give it, as
> long as it starts with an underscore. That should solve it.
Okay, that's m
Guido van Rossum wrote:
> On 8/20/07, Eric Smith <[EMAIL PROTECTED]> wrote:
>> Modules/Setup.dist contains this comment:
>> # This only contains the minimal set of modules required to run the
>> # setup.py script in the root of the Python source tree.
>>
>>
I'm basically done with format(), string.format(), object.__format__(),
string.__format__(), long.__format__(), and float.__format__(). I have
some cleanup left to do from all of the refactoring, but it's passing
the vast majority of my tests.
The only real remaining work is to implement strin
Guido van Rossum wrote:
>> Converting to strings doesn't really buy you much, since we have the !s
>> specifier. But I think it's needed for backward compatibility with %
>> formatting.
>
> Why? The conversion code can just generate !s:-20 instead of :-20s.
True enough. I'll take it out, too.
T
Guido van Rossum wrote:
> On 8/19/07, Eric Smith <[EMAIL PROTECTED]> wrote:
>> Talin wrote:
>>> Wow, excellent feedback. I've added your email to the list of reminders
>>> for the next round of edits.
>> Here's something else for future edits:
>
Eric Smith wrote:
> 2. I'm making the format specifiers as strict as I can. So, I've made
> these ValueError's:
I should have mentioned that I expect there to be criticism of this
decision. I'd like to start with making the specifier parser strict, we
can alway
Talin wrote:
> Wow, excellent feedback. I've added your email to the list of reminders
> for the next round of edits.
Here's something else for future edits:
1. When converting a string to an integer, what should the rules be?
Should:
format("0xd", "d")
produce "13", or should it be an error?
Guido van Rossum wrote:
> On 8/17/07, Eric Smith <[EMAIL PROTECTED]> wrote:
>> I'm refactoring the sandbox implementation, and I need to add the code
>> that parses the standard format specifiers to py3k. Since strings,
>> ints, and floats share same format s
I'm refactoring the sandbox implementation, and I need to add the code
that parses the standard format specifiers to py3k. Since strings,
ints, and floats share same format specifiers, I want to have only a
single parser.
My first question is: where should this parser code live? Should I
cr
Ron Adam wrote:
>
> 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 "co
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
[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
> 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
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
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
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 ha
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
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
Talin wrote:
> Eric Smith wrote:
>> Talin wrote:
>>> Guido expressed a definite preference for having them be first.
>>
>> I was afraid of that. Then can we say they'll always go first? Or is
>> the intent really to say they can go anywhere (PEP says &
Talin wrote:
> Eric Smith wrote:
>> James Thiele wrote:
>>> The section on the explicit conversion flag contains the following line:
>>>
>>> These flags are typically placed before the format specifier:
>>>
>>> Where else can they be plac
I mentioned this in another message, but I thought I'd mention it here.
I see this change in the behavior of sys.stdin.name, between 2.3.3 and
3.0x (checked out a few minutes ago).
$ python
Python 2.3.3 (#1, May 7 2004, 10:31:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
Type "help
James Thiele wrote:
> The section on the explicit conversion flag contains the following line:
>
> These flags are typically placed before the format specifier:
>
> Where else can they be placed?
I'd like this to say they can only be placed where the PEP describes
them, or maybe to be onl
1 - 100 of 107 matches
Mail list logo
