Dag Sverre Seljebotn wrote:
1) It doesn't work well with multiple interpreter states. Ok, nothing works
with that at the moment, but it is on the roadmap for Python
Is it really? I got the impression that it's not considered feasible,
since it would require massive changes to the entire implem
On Fri, Apr 13, 2012 at 11:22 PM, Dag Sverre Seljebotn
wrote:
>
>
> Robert Bradshaw wrote:
>
>>On Fri, Apr 13, 2012 at 2:24 PM, Nathaniel Smith wrote:
>>> On Fri, Apr 13, 2012 at 9:27 PM, Dag Sverre Seljebotn
>>> wrote:
Ah, I didn't think about 6-bit or huffman. Certainly helps.
On Fri, Apr 13, 2012 at 3:06 PM, Dag Sverre Seljebotn
wrote:
>
>
> Robert Bradshaw wrote:
>
>>On Fri, Apr 13, 2012 at 1:27 PM, Dag Sverre Seljebotn
>> wrote:
>>> Ah, I didn't think about 6-bit or huffman. Certainly helps.
>>
>>Yeah, we don't want to complicate the ABI too much, but I think
>>some
Dag Sverre Seljebotn wrote:
>
>
>Robert Bradshaw wrote:
>
>>On Fri, Apr 13, 2012 at 2:24 PM, Nathaniel Smith
>wrote:
>>> On Fri, Apr 13, 2012 at 9:27 PM, Dag Sverre Seljebotn
>>> wrote:
Ah, I didn't think about 6-bit or huffman. Certainly helps.
I'm almost +1 on your proposal
Robert Bradshaw wrote:
>On Fri, Apr 13, 2012 at 2:24 PM, Nathaniel Smith wrote:
>> On Fri, Apr 13, 2012 at 9:27 PM, Dag Sverre Seljebotn
>> wrote:
>>> Ah, I didn't think about 6-bit or huffman. Certainly helps.
>>>
>>> I'm almost +1 on your proposal now, but a couple of more ideas:
>>>
>>> 1)
Robert Bradshaw wrote:
>On Fri, Apr 13, 2012 at 1:27 PM, Dag Sverre Seljebotn
> wrote:
>> Ah, I didn't think about 6-bit or huffman. Certainly helps.
>
>Yeah, we don't want to complicate the ABI too much, but I think
>something like 8 4-bit common chars and 32 6-bit other chars (or 128
>8-bit o
On Fri, Apr 13, 2012 at 2:24 PM, Nathaniel Smith wrote:
> On Fri, Apr 13, 2012 at 9:27 PM, Dag Sverre Seljebotn
> wrote:
>> Ah, I didn't think about 6-bit or huffman. Certainly helps.
>>
>> I'm almost +1 on your proposal now, but a couple of more ideas:
>>
>> 1) Let the key (the size_t) spill ove
On Fri, Apr 13, 2012 at 9:27 PM, Dag Sverre Seljebotn
wrote:
> Ah, I didn't think about 6-bit or huffman. Certainly helps.
>
> I'm almost +1 on your proposal now, but a couple of more ideas:
>
> 1) Let the key (the size_t) spill over to the next specialization entry if
> it is too large; and prepe
On Fri, Apr 13, 2012 at 1:27 PM, Dag Sverre Seljebotn
wrote:
> Ah, I didn't think about 6-bit or huffman. Certainly helps.
Yeah, we don't want to complicate the ABI too much, but I think
something like 8 4-bit common chars and 32 6-bit other chars (or 128
8-bit other chars) wouldn't be outrageous
On Fri, Apr 13, 2012 at 12:52 PM, Stefan Behnel wrote:
> Robert Bradshaw, 13.04.2012 20:21:
>> On Fri, Apr 13, 2012 at 10:26 AM, Robert Bradshaw wrote:
>>> On Fri, Apr 13, 2012 at 4:59 AM, Dag Sverre Seljebotn wrote:
On 04/13/2012 01:38 PM, Stefan Behnel wrote:
> That would only apply at
Ah, I didn't think about 6-bit or huffman. Certainly helps.
I'm almost +1 on your proposal now, but a couple of more ideas:
1) Let the key (the size_t) spill over to the next specialization entry if it
is too large; and prepend that key with a continuation code (two size-ts could
together say "
Robert Bradshaw, 13.04.2012 20:21:
> On Fri, Apr 13, 2012 at 10:26 AM, Robert Bradshaw wrote:
>> On Fri, Apr 13, 2012 at 4:59 AM, Dag Sverre Seljebotn wrote:
>>> On 04/13/2012 01:38 PM, Stefan Behnel wrote:
That would only apply at a per-module level, though, so it would
require an indire
Robert Bradshaw, 13.04.2012 21:26:
> On Fri, Apr 13, 2012 at 12:15 PM, Stefan Behnel wrote:
>> Stefan Behnel, 13.04.2012 07:24:
>>> Dag Sverre Seljebotn, 13.04.2012 00:34:
On 04/13/2012 12:11 AM, Dag Sverre Seljebotn wrote:
http://wiki.cython.org/enhancements/cep1000
>>>
>>> I'm all for d
On Fri, Apr 13, 2012 at 12:15 PM, Stefan Behnel wrote:
> Stefan Behnel, 13.04.2012 07:24:
>> Dag Sverre Seljebotn, 13.04.2012 00:34:
>>> On 04/13/2012 12:11 AM, Dag Sverre Seljebotn wrote:
>>> http://wiki.cython.org/enhancements/cep1000
>>
>> I'm all for doing something in this direction and have
Stefan Behnel, 13.04.2012 07:24:
> Dag Sverre Seljebotn, 13.04.2012 00:34:
>> On 04/13/2012 12:11 AM, Dag Sverre Seljebotn wrote:
>> http://wiki.cython.org/enhancements/cep1000
>
> I'm all for doing something in this direction and have been hinting at it
> on the PyPy mailing list for a while, wit
On Fri, Apr 13, 2012 at 10:26 AM, Robert Bradshaw wrote:
> On Fri, Apr 13, 2012 at 4:59 AM, Dag Sverre Seljebotn
> wrote:
>> On 04/13/2012 01:38 PM, Stefan Behnel wrote:
>>> That would only apply at a per-module level, though, so it would require
>>> an
>>> indirection for the signature IDs. But
On Fri, Apr 13, 2012 at 5:48 AM, mark florisson
wrote:
> On 13 April 2012 12:59, Dag Sverre Seljebotn
> wrote:
>> On 04/13/2012 01:38 PM, Stefan Behnel wrote:
>>>
>>> Robert Bradshaw, 13.04.2012 12:17:
On Fri, Apr 13, 2012 at 1:52 AM, Dag Sverre Seljebotn wrote:
>
> On 04/13/20
On Fri, Apr 13, 2012 at 4:59 AM, Dag Sverre Seljebotn
wrote:
> On 04/13/2012 01:38 PM, Stefan Behnel wrote:
>>
>> Robert Bradshaw, 13.04.2012 12:17:
>>>
>>> On Fri, Apr 13, 2012 at 1:52 AM, Dag Sverre Seljebotn wrote:
On 04/13/2012 01:38 AM, Robert Bradshaw wrote:
>
> Have you gi
On 13 April 2012 14:27, Dag Sverre Seljebotn wrote:
> On 04/13/2012 03:01 PM, mark florisson wrote:
>>
>> On 13 April 2012 13:48, Stefan Behnel wrote:
>>>
>>> Stefan Behnel, 13.04.2012 14:27:
Dag Sverre Seljebotn, 13.04.2012 13:59:
>
> Requiring interning is somewhat less elegan
Stefan Behnel, 13.04.2012 07:11:
> Robert Bradshaw, 12.04.2012 22:21:
>> On Thu, Apr 12, 2012 at 11:21 AM, mark florisson wrote:
>>> Could we run the pyregr test suite manually instead of automatically?
>>> It takes a lot of resources to build, and a single simple push to the
>>> cython-devel branc
On 04/13/2012 03:01 PM, mark florisson wrote:
On 13 April 2012 13:48, Stefan Behnel wrote:
Stefan Behnel, 13.04.2012 14:27:
Dag Sverre Seljebotn, 13.04.2012 13:59:
Requiring interning is somewhat less elegant in one way, but it makes a lot
of other stuff much simpler.
That gives us
struct {
On 13 April 2012 13:48, Stefan Behnel wrote:
> Stefan Behnel, 13.04.2012 14:27:
>> Dag Sverre Seljebotn, 13.04.2012 13:59:
>>> Requiring interning is somewhat less elegant in one way, but it makes a lot
>>> of other stuff much simpler.
>>>
>>> That gives us
>>>
>>> struct {
>>> void *pointer;
Stefan Behnel, 13.04.2012 14:27:
> Dag Sverre Seljebotn, 13.04.2012 13:59:
>> Requiring interning is somewhat less elegant in one way, but it makes a lot
>> of other stuff much simpler.
>>
>> That gives us
>>
>> struct {
>> void *pointer;
>> PyBytesObject *signature;
>> } record;
>>
>> and
On 13 April 2012 12:59, Dag Sverre Seljebotn wrote:
> On 04/13/2012 01:38 PM, Stefan Behnel wrote:
>>
>> Robert Bradshaw, 13.04.2012 12:17:
>>>
>>> On Fri, Apr 13, 2012 at 1:52 AM, Dag Sverre Seljebotn wrote:
On 04/13/2012 01:38 AM, Robert Bradshaw wrote:
>
> Have you given any t
On 13 April 2012 12:38, Stefan Behnel wrote:
> Robert Bradshaw, 13.04.2012 12:17:
>> On Fri, Apr 13, 2012 at 1:52 AM, Dag Sverre Seljebotn wrote:
>>> On 04/13/2012 01:38 AM, Robert Bradshaw wrote:
Have you given any thought as to what happens if __call__ is
re-assigned for an object (or
Dag Sverre Seljebotn, 13.04.2012 13:59:
> On 04/13/2012 01:38 PM, Stefan Behnel wrote:
>> Robert Bradshaw, 13.04.2012 12:17:
>>> On Fri, Apr 13, 2012 at 1:52 AM, Dag Sverre Seljebotn wrote:
On 04/13/2012 01:38 AM, Robert Bradshaw wrote:
> Minor nit: I don't think should_dereference is wort
On Fri, Apr 13, 2012 at 12:59 PM, Dag Sverre Seljebotn
wrote:
> I'll go one further: Intern Python bytes objects. It's just a PyObject*, but
> it's *required* (or just strongly encouraged) to have gone through
>
> sig = sys.modules['_nativecall']['interned_db'].setdefault(sig, sig)
>
> Obviously i
On Fri, Apr 13, 2012 at 9:52 AM, Dag Sverre Seljebotn
wrote:
> On 04/13/2012 01:38 AM, Robert Bradshaw wrote:
>> Also, I'm not sure the type registration will scale, especially if
>> every callable type wanted to get registered. (E.g. currently closures
>> and generators are new types...) Where to
On 04/13/2012 01:38 PM, Stefan Behnel wrote:
Robert Bradshaw, 13.04.2012 12:17:
On Fri, Apr 13, 2012 at 1:52 AM, Dag Sverre Seljebotn wrote:
On 04/13/2012 01:38 AM, Robert Bradshaw wrote:
Have you given any thought as to what happens if __call__ is
re-assigned for an object (or subclass of an
Robert Bradshaw, 13.04.2012 12:17:
> On Fri, Apr 13, 2012 at 1:52 AM, Dag Sverre Seljebotn wrote:
>> On 04/13/2012 01:38 AM, Robert Bradshaw wrote:
>>> Have you given any thought as to what happens if __call__ is
>>> re-assigned for an object (or subclass of an object) supporting this
>>> interface
Dag Sverre Seljebotn, 13.04.2012 11:13:
> On 04/13/2012 07:24 AM, Stefan Behnel wrote:
>> Dag Sverre Seljebotn, 13.04.2012 00:34:
>>> http://wiki.cython.org/enhancements/cep1000
>>
>> There's PEP 362 which proposes a Signature object. It seems to have
>> attracted some interest lately and Guido see
On Fri, Apr 13, 2012 at 1:52 AM, Dag Sverre Seljebotn
wrote:
> On 04/13/2012 01:38 AM, Robert Bradshaw wrote:
>>
>> On Thu, Apr 12, 2012 at 3:34 PM, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 04/13/2012 12:11 AM, Dag Sverre Seljebotn wrote:
Travis Oliphant recently raised the issue
Stefan Behnel, 13.04.2012 07:24:
> Dag Sverre Seljebotn, 13.04.2012 00:34:
>> http://wiki.cython.org/enhancements/cep1000
>
> I'm all for doing something in this direction and have been hinting at it
> on the PyPy mailing list for a while, without reaction so far. I'll trigger
> them again, with a
On 04/13/2012 07:24 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 13.04.2012 00:34:
On 04/13/2012 12:11 AM, Dag Sverre Seljebotn wrote:
Travis Oliphant recently raised the issue on the NumPy list of what
mechanisms to use to box native functions produced by his Numba so that
SciPy functions ca
On 04/13/2012 01:38 AM, Robert Bradshaw wrote:
On Thu, Apr 12, 2012 at 3:34 PM, Dag Sverre Seljebotn
wrote:
On 04/13/2012 12:11 AM, Dag Sverre Seljebotn wrote:
Travis Oliphant recently raised the issue on the NumPy list of what
mechanisms to use to box native functions produced by his Numba
35 matches
Mail list logo
