On 8/23/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > It *does* implement that! So there's the solution: these APIs should
> > not insist on bytes but use the buffer API. It's quite a bit of work I
> > suspect (especially since you can't use PyArg_ParseTuple with y# any
> > more) but worth i
> It *does* implement that! So there's the solution: these APIs should
> not insist on bytes but use the buffer API. It's quite a bit of work I
> suspect (especially since you can't use PyArg_ParseTuple with y# any
> more) but worth it.
I think there could be another code for PyArg_ParseTuple (or
That looks like a simple logic bug in the routine where the assert is
failing (should return 1 when detecting None). I'll check in a fix
momentarily.
--Guido
On 8/23/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 8/22/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> > > > There are currently
This was now fixed in 3.0. Somebody might want to backport.
On 7/28/07, lcaamano <[EMAIL PROTECTED]> wrote:
>
> On Jul 20, 1:52 pm, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > I discovered what appears to be a thread-unsafety inuuid.py. This is
> > in the trunk as well as in 3.x; I'm using t
Yes, I think this would be way cool! I believe there are already a few
fixers that print messages about things they know are wrong but don't
know how to fix, those could also be integrated (although arguably
you'd want those messages to be treated as more severe).
Does this mean that Django is com
On 8/23/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Gregory P. Smith wrote:
> > Wasn't a past mailing list thread claiming the bytes type was supposed
> > to be great for IO? How's that possible unless we add a lock to the
> > bytesobject?
>
> Doesn't the new buffer protocol provide something for
Here's the final form of the SSL patch. Now includes a test file. All
bugs discovered on Wednesday have been fixed.
Bill
Index: Lib/socket.py
===
*** Lib/socket.py (revision 57372)
--- Lib/socket.py (working copy)
***
Thanks!
Committed revision 57375.
On 8/23/07, Yuri Ginsburg <[EMAIL PROTECTED]> wrote:
> The attached small patch makes output buffer thus making uuid.py thread-safe.
>
> --
> Yuri Ginsburg (YG10)
>
> ___
> Python-3000 mailing list
> Python-3000@python
Hi Ero,
Thanks for these! I checked them in.
The datetime patch had a few problems (did you run the unit test?)
that I got rid of.
The function you were looking for does exist, it's
PyUnicode_AsUTF8String(). (which returns a new object instead of a
borrowed reference). I changed your code to use
This patch implements rich comparisons with dict views such that
dict().keys() can be compared like a set (i.e. < is subset, etc).
Keir
Index: Objects/dictobject.c
===
--- Objects/dictobject.c (revision 57367)
+++ Objects/dictobject.c
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.
Gregory P. Smith wrote:
> Wasn't a past mailing list thread claiming the bytes type was supposed
> to be great for IO? How's that possible unless we add a lock to the
> bytesobject?
Doesn't the new buffer protocol provide something for
getting a locked view of the data? If so, it seems like
bytes
Guido van Rossum wrote:
> cmp() is still alive and __cmp__ is used to overload it; on the one
> hand I'd like to get rid of it but OTOH it's occasionally useful.
Maybe you could keep cmp() but implement it in terms
of, say, __lt__ and __eq__?
--
Greg Ewing, Computer Science Dept, +--
The attached small patch makes output buffer thus making uuid.py thread-safe.
--
Yuri Ginsburg (YG10)
uuid.py.diff
Description: Binary data
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubsc
As part of the Python 3000 sprint (at Google's Chicago office), I've
been working on the documentation for 2to3. I'm publishing updates at
http://red-bean.com/~adrian/2to3.rst and will submit this as a
documentation patch when it's completed. (I didn't get as much done
today as I would have liked,
I figured it out by stepping through builtin_trunc and into
_PyType_Lookup for a bit. The type is not completely initialized;
apparently fundamental types like float get initialized lazily
*really* late. Inserting this block of code before the _PyType_Lookup
call fixes things:
if (Py_Type(
Hi,
I'm attaching a small patch result of attempting to tackle part of
one of the tasks in the Google Sprint.
The patch removes most of the references of PyString_* calls in the
"time" and "datetime" modules and adds Unicode support instead.
There's a problem in "datetime" with
"_PyUnico
Patch submitted to Roundup; it's issue #1007:
http://bugs.python.org/issue1007
(It's listed under Python 2.6 as there's currently no appropriate choice
in the "Versions" list.)
/larry/
___
Python-3000 mailing list
Python-3000@python.org
http://ma
The newly introduced trunc() and round() have the following odd behavior:
$ ./python
Python 3.0x (py3k, Aug 23 2007, 17:15:22)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> trunc(3.14)
Traceback (most recent call last):
F
Attached is a patch for review.
As of revision 57341 (only a couple hours old as of this writing),
test_shelve was failing on my machine. This was because I didn't have
any swell databases available, so anydbm was falling back to dumbdbm,
and dumbdbm had a bug. In Py3k, dumbdbm's dict-like
This patch fixes rich set comparison so that x < y works when x is a
set and y is something which implements the corresponding comparison.
Keir
Index: Objects/setobject.c
===
--- Objects/setobject.c (revision 57362)
+++ Objects/setobj
Alex and I did a bunch more work based on this patch and checked it in:
Committed revision 57359.
On 8/22/07, Keir Mierle <[EMAIL PROTECTED]> wrote:
> This patch fixes the previously added truncate, and also fixes round
> behavior. The two argument version of round is not currently handling
> th
Paul Dubois schrieb:
> FYI: docutils will require some modification of at least the io module,
> to the extent that the ideal mode of fixing the current sources so that
> a subsequent pass of 2to3 will do the job, is probably not possible (but
> may be outside of this one file). I've made a report
FYI: docutils will require some modification of at least the io module, to
the extent that the ideal mode of fixing the current sources so that a
subsequent pass of 2to3 will do the job, is probably not possible (but may
be outside of this one file). I've made a report to the docutils tracker to
th
On Thu, Aug 23, 2007 at 09:18:59PM +0200, "Martin v. L?wis" wrote:
> > I -detest- the idea of making another temporary copy of the data just
> > to allow the GIL to be released during IO. data copies == bad.
> > Wasn't a past mailing list thread claiming the bytes type was supposed
> > to be great
> I -detest- the idea of making another temporary copy of the data just
> to allow the GIL to be released during IO. data copies == bad.
> Wasn't a past mailing list thread claiming the bytes type was supposed
> to be great for IO? How's that possible unless we add a lock to the
> bytesobject? (
On 8/22/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> > > 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.
test_bsddb works for me on Ubuntu, and t
Bill Janssen schrieb:
>> I plan to spend some Real Time on those today and I think Bill is
>> going to meet up with me on #python-dev when the Californians wake up.
>
> That's not working real well right now... IRC seems wedged for me.
>
> Probably a firewall issue.
>
> I've got to try a diffe
> I plan to spend some Real Time on those today and I think Bill is
> going to meet up with me on #python-dev when the Californians wake up.
That's not working real well right now... IRC seems wedged for me.
Probably a firewall issue.
I've got to try a different location, and we'll try to conn
On Thu, Aug 23, 2007 at 09:49:19AM +0200, "Martin v. L?wis" wrote:
> > Yeah you did the keys (good!). I just checked in a change to require
> > values to also by bytes. Maybe that goes so far as to be inconvenient?
>
> Ah, ok. I think it is fine. We still need to discuss what the best
> way is t
On 22/08/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > * Add Demo/classes/Rat.py to the stdlib?
>
> Yes, but it needs a makeover. At the very least I'd propose the module
> name to be rational.
If no-one else gets to this, I might take a look. But I'm not likely
to make fast progress as I do
On 23/08/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Coerce is definitely dead.
>
> cmp() is still alive and __cmp__ is used to overload it; on the one
> hand I'd like to get rid of it but OTOH it's occasionally useful. So
> it'll probably stay. However, to overload <, == etc. you *have* to
>
Coerce is definitely dead.
cmp() is still alive and __cmp__ is used to overload it; on the one
hand I'd like to get rid of it but OTOH it's occasionally useful. So
it'll probably stay. However, to overload <, == etc. you *have* to
overload __lt__ and friends.
On 8/23/07, Paul Moore <[EMAIL PROTEC
Can I just check - is __cmp__ due for removal in Py3K? There's no
mention of it in PEP 3100, but its status seems unclear from
references I've found.
Actually, is __coerce__ still around, as well? Again, I can't see a
clear answer in the PEPs or list discussions.
Paul.
___
Aahz,
While the sprint is going on (and because I knew about the tracker
move) I've encouraged people at the sprint to post their patches
directly to python-3000 -- most likely the review feedback will be
given in person and then the patch will be checked in. This is quicker
than using a tracker f
On 8/22/07, John Reese <[EMAIL PROTECTED]> wrote:
> 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.
On Wed, Aug 22, 2007, Keir Mierle wrote:
>
> 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.
Please wait until the new python.org bug tracker is up and post the
patch there.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 22, 2007, at 10:06 PM, Guido van Rossum wrote:
> 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
> Yeah you did the keys (good!). I just checked in a change to require
> values to also by bytes. Maybe that goes so far as to be inconvenient?
Ah, ok. I think it is fine. We still need to discuss what the best
way is to do string:string databases, or string:bytes databases.
I added StringKeys
On Thu, Aug 23, 2007 at 07:58:33AM +0200, "Martin v. L?wis" wrote:
> > 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 an
Gregory P. Smith schrieb:
> 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.
b = bytes(1)
b[0] = 65
doesn't create an intermediate stri
41 matches
Mail list logo
