Hey everyone,
Sorry I haven't been available for this recently, I've been working
far too much (10-14 hours/day, 6 days/week, since November) to really
do any "fun" programming. Also, sorry for top-posting.
As I stated 2+ and 6+ months ago, the patches I submitted 9+ months
ago work (I've been u
Greg Ewing wrote:
> Eric Smith wrote:
>
>> 1: exposing builtin_format(), probably giving it another name
>> (PyObject_Format?) and moving it somewhere other than bltinmodule.c.
>
> PyObject_Format sounds more like an API for invoking the
> __format__ lookup mechanism. Maybe something like
> PyOb
On Thu, Feb 14, 2008 at 2:36 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Eric Smith wrote:
> > Are you saying I should call _PyType_Lookup first?
>
> No, I think he's saying that you don't need to call
> _PyType_Lookup at all, because anything that it could
> find will also be found by PyObject
Eric Smith wrote:
> 1: exposing builtin_format(), probably giving it another name
> (PyObject_Format?) and moving it somewhere other than bltinmodule.c.
PyObject_Format sounds more like an API for invoking the
__format__ lookup mechanism. Maybe something like
PyObject_DefaultFormat would be bett
Eric Smith wrote:
> Are you saying I should call _PyType_Lookup first?
No, I think he's saying that you don't need to call
_PyType_Lookup at all, because anything that it could
find will also be found by PyObject_GetAttr.
So just call PyObject_GetAttr and it should Just Work.
--
Greg
___
On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.5.2 (release candidate 1).
This is the second bugfix release of Python 2.5. Python 2.5 is now in
bugfix-only mode; no new features are being added. According to the
release notes, over
> Since I can't change issue assignment I reply here.
> Issue 1745035 (which is still open) should concern 2.5.2.
Thanks for pointing that out. As the release candidate
has been produced already, it's too late for this specific
patch to go into 2.5.2. Maybe we can consider it for 2.5.3.
Regards,
Christian Heimes <[EMAIL PROTECTED]> wrote:
> +1 on focusing on improving pymalloc to handle int and float
>object allocations even better
I wonder if the int and float types could use a faster internal
pymalloc interface. I can't remember the details but I seem to
recall that pymalloc must j
On 14 Feb, 16:36, "Giampaolo Rodola'" <[EMAIL PROTECTED]> wrote:
> Ok, I'll try to take a look at all asyncore/chat reports and try to
> summarize them by splitting patches which solve bugs and patches which
> add enhancements or functionalities.
>
> On 14 Feb, 16:12, "Facundo Batista" <[EMAIL PROT
On 14 Feb, 2008, at 17:48, Mark Dickinson wrote:
On Thu, Feb 14, 2008 at 11:21 AM, Ronald Oussoren <[EMAIL PROTECTED]
> wrote:
Hi,
I've just filed issue2114 (http://bugs.python.org/issue2114) because
test_decimal.py fails on OSX 10.3 with Python 2.5.2c1.
It looks like you've got a file Lib/t
On Thu, Feb 14, 2008 at 11:21 AM, Ronald Oussoren <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> I've just filed issue2114 (http://bugs.python.org/issue2114) because
> test_decimal.py fails on OSX 10.3 with Python 2.5.2c1.
It looks like you've got a file Lib/test/decimaltestdata/normalize.decTest
(or poss
Hi,
I've just filed issue2114 (http://bugs.python.org/issue2114) because
test_decimal.py fails on OSX 10.3 with Python 2.5.2c1 (using the
python.org build that will be released soon). The same test passes on
OSX 10.4 and 10.5 (both Intel and PPC) using the exact same binaries.
IIRC the 2.5.
First of all, you're conflating my two possible patches.
One patch just addresses the problem of strings and bytes, as GvR
asked me to do, and adds an 8-line class called iterator_producer that
adapts iterators into producers. The patch doesn't change how the
module works at all, and iterator_prod
Ok, I'll try to take a look at all asyncore/chat reports and try to
summarize them by splitting patches which solve bugs and patches which
add enhancements or functionalities.
On 14 Feb, 16:12, "Facundo Batista" <[EMAIL PROTECTED]> wrote:
> 2008/2/14, Giampaolo Rodola' <[EMAIL PROTECTED]>:
>
> >
2008/2/14, Giampaolo Rodola' <[EMAIL PROTECTED]>:
> asyncore and asynchat are in a difficult position right now since a
> lot of patches for both modules are pending and no decisions are
> taken.
> In detail I'm talking about patches 1519, 1541, 2073 and 1736190 which
> is the most important o
On Feb 13, 2008, at 2:57 PM, Martin v. Löwis wrote:
> The 2.5 maintenance branch will be frozen tomorrow (Thursday)
> around 7:00 UTC. Please don't make any changes to the branch
> after that point unless you are directly involved in the release
> process.
The documentation packages have been uplo
Since I can't change issue assignment I reply here.
Issue 1745035 (which is still open) should concern 2.5.2.
On 13 Feb, 20:57, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> The 2.5 maintenance branch will be frozen tomorrow (Thursday)
> around 7:00 UTC. Please don't make any changes to the branc
(wrong quoting: obvioulsly I was talking to Daniel)
___
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
asyncore and asynchat are in a difficult position right now since a
lot of patches for both modules are pending and no decisions are
taken.
In detail I'm talking about patches 1519, 1541, 2073 and 1736190 which
is the most important one since it includes a lot of fixes for other
reported issues (e.
Eric Smith wrote:
> I see 2 approaches:
>
> 1: exposing builtin_format(), probably giving it another name
> (PyObject_Format?) and moving it somewhere other than bltinmodule.c.
>
> 2: Instead of calling the C code directly, lookup "format" in Python's
> builtins, and call it. This, I think, wou
Eric Smith schrieb:
> While implementing "".format(), I need to call the builtin format()
> function, which I've already implemented (in
> bltinmodule.c:builtin_format()). In the py3k branch, I just hardcoded
> the same functionality into "".format(), which seems like the wrong
> thing to do, giv
While implementing "".format(), I need to call the builtin format()
function, which I've already implemented (in
bltinmodule.c:builtin_format()). In the py3k branch, I just hardcoded
the same functionality into "".format(), which seems like the wrong
thing to do, given how complex the code is.
I
Guido van Rossum wrote:
> Try this:
>
> if (PyInstance_Check(obj)) {
> bound_method = PyObject_GetAttr(obj, str__format__);
> if (!bound_method)
> return NULL;
>
> Py_DECREF(bound_method);
> return
> }
> else {
> do it the py3k way;
> }
Yes! I had converged on something similar.
23 matches
Mail list logo
