On 8/21/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> I'd like to spend some time during the Sprint doing three things:
>
> 1. Doing a code review of the modified SSL C code with 2 or 3 others.
> Can we get a small conference room with a projector to use for an hour?
> If not, I can provid
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), 'e')
> self.assertEquals('{foo[{bar}]}'.format(foo='abcdefg', ba
There are still some open issues here that need answers:
* Should __pos__ coerce the argument to be an instance of the type
it's defined on?
* Add Demo/classes/Rat.py to the stdlib?
* How many of __trunc__, __floor__, __ceil__, and __round__ should be
magic methods? For __round__, when do we want
If I want to check an object for stringedness in py3k do I use
PyString_Check or PyUnicode_Check?
Thx,
Skip
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/ma
On 8/22/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> There are still some open issues here that need answers:
>
> * Should __pos__ coerce the argument to be an instance of the type
> it's defined on?
Yes, I think so. That's what the built-in types do (in case the object
is an instance of a sub
[EMAIL PROTECTED] schrieb:
> If I want to check an object for stringedness in py3k do I use
> PyString_Check or PyUnicode_Check?
In the medium term, you should use PyUnicode_Check. In the short
term, additionally, do PyString_Check as well if you want to
support str8 (your choice). In the long ter
Eric Smith wrote:
> 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), 'e')
>> self.assertEquals('{foo[{bar}]}'
Good afternoon. I'm in the Google Python Sprint working on getting
the test_xmlrpc unittest to pass. The following patch was prepared by
Jacques Frechet and me. We'd appreciate feedback on the attached
patch.
What was broken:
1. BaseHTTPServer attempts to parse the http headers with an
rfc822
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 action is taken if an unrecognized expli
Thanks! I've checked the bulk of this in, excepting the fix for #3,
which I fixed at the source in longobject.c. Also, I changed the call
to io.StringIO() to first convert the bytes to characters, using the
same encoding as used for the HTTP request header line (Latin-1).
--Guido
On 8/22/07, John
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
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:
> >
> > !r - convert the value to a string using repr().
> > !s - convert the v
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:
>>>
>>> !r - convert the value to a string using repr().
>>>
The attached patch fixes math.ceil to delegate to x.__ceil__() if it
is defined, according to PEP 3141, and adds tests to cover the new
cases. Patch is against r57303.
No new test failures are introduced.
Keir
Index: Lib/test/test_math.py
==
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
On Tue, Aug 07, 2007 at 06:53:32AM +0200, "Martin v. L?wis" wrote:
> > I guess we have to rethink our use of these databases somewhat.
>
> Ok. In the interest of progress, I'll be looking at coming up with
> some fixes for the code base right now; as we agree that the
> underlying semantics is byt
> > There are currently about 7 failing unit tests left:
> >
> > test_bsddb
> > test_bsddb3
...
fyi these two pass for me on the current py3k branch on ubuntu linux
and mac os x 10.4.9.
-greg
___
Python-3000 mailing list
Python-3000@python.org
http://m
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 specifiers can themselves contain replacement fields".
>>> The tests above have replacement f
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 specifiers can themselves contain replacement
fields". The tes
For me too. Great work whoever fixed these (and other tests, like xmlrpc).
All I've got left failing is the three email tests, and I know Barry
Warsaw is working on those. (Although he used some choice swearwords
to describe the current state. :-)
--Guido
On 8/22/07, Gregory P. Smith <[EMAIL PRO
My mistake, out of habit I limited the submit to the Lib subdirectory.
Will do later.
On 8/22/07, John Reese <[EMAIL PROTECTED]> wrote:
> Thanks, sounds good. I'm curious why you left out the change to
> Doc/library/xmlrpclib.rst -- the documentation of the type of the
> parameter was out-of-date
On Wed, 22 Aug 2007 21:33:19 -0400
Eric Smith <[EMAIL PROTECTED]> wrote:
> Ron Adam wrote:
...
> > That would mean there is no way to pass a brace to a __format__ method.
>
> No way using string.format, correct. You could pass it in using the
> builtin format(), or by calling __format__ directl
On Wed, 22 Aug 2007 23:15:56 -0400
Andrew James Wade <[EMAIL PROTECTED]> wrote:
> And I'd do
> the recursive substitution before even starting to parse the field:
> it's simple and powerful.
Scratch that suggestion; the implications need to be thought through.
If we allow recursive substitution o
Thanks, sounds good. I'm curious why you left out the change to
Doc/library/xmlrpclib.rst -- the documentation of the type of the
parameter was out-of-date, if it was ever right.
On 8/22/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Thanks! I've checked the bulk of this in, excepting the fix
This patch fixes the previously added truncate, and also fixes round
behavior. The two argument version of round is not currently handling
the round toward even case.
Keir
Index: Python/bltinmodule.c
===
--- Python/bltinmodule.c (revi
Eric Smith wrote:
> 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 specifiers can themselves contain replacem
> IMHO all of that is desirable in many situations but it is not strict.
> bytes:bytes or int:bytes (depending on the database type) are
> fundamentally all the C berkeleydb library knows. Attaching meaning
> to the keys and values is up to the user. I'm about to try a _bsddb.c
> that strictly en
Is there anything similar to chr(65) for creating a single byte string
that doesn't involve creating an intermediate string or tuple object?
bytes(chr(65))
bytes((65,))
both seem slightly weird.
Greg
___
Python-3000 mailing list
Python-3000@python.o
On Wed, Aug 22, 2007 at 11:12:32PM -0700, Gregory P. Smith wrote:
> Is there anything similar to chr(65) for creating a single byte string
> that doesn't involve creating an intermediate string or tuple object?
>
> bytes(chr(65))
> bytes((65,))
>
> both seem slightly weird.
>
> Greg
yes i kno
29 matches
Mail list logo
