2012/1/21 Chris Colbert :
>
>
> On Sat, Jan 21, 2012 at 2:35 AM, Vitja Makarov
> wrote:
>>
>> 2012/1/21 Stefan Behnel :
>> > Chris Colbert, 19.01.2012 09:18:
>> >> If it doesn't pass PyDict_CheckExact you won't be able to use it as the
>> >> globals to eval or exec.
>> >
>> > What makes you say th
On Sat, Jan 21, 2012 at 2:35 AM, Vitja Makarov wrote:
> 2012/1/21 Stefan Behnel :
> > Chris Colbert, 19.01.2012 09:18:
> >> If it doesn't pass PyDict_CheckExact you won't be able to use it as the
> >> globals to eval or exec.
> >
> > What makes you say that? I tried and it worked for me, all the w
2012/1/21 Stefan Behnel :
> Vitja Makarov, 19.01.2012 08:49:
>> 2012/1/19 Robert Bradshaw:
>>> On Wed, Jan 18, 2012 at 12:30 PM, Vitja Makarov wrote:
I tried to optimize module lookups (__pyx_m) by caching internal PyDict
state.
In this example bar() is 1.6 time faster (500us a
2012/1/21 Stefan Behnel :
> Chris Colbert, 19.01.2012 09:18:
>> If it doesn't pass PyDict_CheckExact you won't be able to use it as the
>> globals to eval or exec.
>
> What makes you say that? I tried and it worked for me, all the way back to
> Python 2.4:
>
>
> Python 2.4.6 (#
On Fri, Jan 20, 2012 at 10:00 PM, Stefan Behnel wrote:
> Vitja Makarov, 19.01.2012 08:49:
>> 2012/1/19 Robert Bradshaw:
>>> On Wed, Jan 18, 2012 at 12:30 PM, Vitja Makarov wrote:
I tried to optimize module lookups (__pyx_m) by caching internal PyDict
state.
In this example bar
On Fri, Jan 20, 2012 at 11:58 PM, Stefan Behnel wrote:
> Chris Colbert, 19.01.2012 09:18:
> > If it doesn't pass PyDict_CheckExact you won't be able to use it as the
> > globals to eval or exec.
>
> What makes you say that? I tried and it worked for me, all the way back to
> Python 2.4:
>
>
Ah, y
Vitja Makarov, 19.01.2012 08:49:
> 2012/1/19 Robert Bradshaw:
>> On Wed, Jan 18, 2012 at 12:30 PM, Vitja Makarov wrote:
>>> I tried to optimize module lookups (__pyx_m) by caching internal PyDict
>>> state.
>>>
>>> In this example bar() is 1.6 time faster (500us against 842us):
>>>
>>> C = 123
>>>
Chris Colbert, 19.01.2012 09:18:
> If it doesn't pass PyDict_CheckExact you won't be able to use it as the
> globals to eval or exec.
What makes you say that? I tried and it worked for me, all the way back to
Python 2.4:
Python 2.4.6 (#2, Jan 21 2010, 23:45:25)
[GCC 4.4.1] on
On Thu, Jan 19, 2012 at 12:18 AM, Chris Colbert wrote:
> If it doesn't pass PyDict_CheckExact you won't be able to use it as the
> globals to eval or exec.
:(. I wonder how many other places have similar restrictions, perhaps
even implicitly. In particular, this would mean that an eval statement
If it doesn't pass PyDict_CheckExact you won't be able to use it as the
globals to eval or exec. That's assuming you hack the module type so you
can change its __dict__.
On Jan 19, 2012 2:01 AM, "Robert Bradshaw"
wrote:
> On Wed, Jan 18, 2012 at 11:53 PM, Vitja Makarov
> wrote:
> > 2012/1/19 Vit
On 19 January 2012 08:00, Robert Bradshaw wrote:
> On Wed, Jan 18, 2012 at 11:53 PM, Vitja Makarov
> wrote:
>> 2012/1/19 Vitja Makarov :
>>> 2012/1/19 Robert Bradshaw :
I think the right thing to do here is make all module-level globals
into "cdef public" attributes, i.e. C globals wit
On Wed, Jan 18, 2012 at 11:53 PM, Vitja Makarov wrote:
> 2012/1/19 Vitja Makarov :
>> 2012/1/19 Robert Bradshaw :
>>> I think the right thing to do here is make all module-level globals
>>> into "cdef public" attributes, i.e. C globals with getters and setters
>>> for Python space. I'm not sure wh
2012/1/19 Vitja Makarov :
> 2012/1/19 Robert Bradshaw :
>> I think the right thing to do here is make all module-level globals
>> into "cdef public" attributes, i.e. C globals with getters and setters
>> for Python space. I'm not sure whether this would best be done by
>> creating a custom dict or
2012/1/19 Robert Bradshaw :
> I think the right thing to do here is make all module-level globals
> into "cdef public" attributes, i.e. C globals with getters and setters
> for Python space. I'm not sure whether this would best be done by
> creating a custom dict or module subclass, but it would pr
AFAIK, a module's dict is readonly, so I don't believe a dict subclass will
work there (I could be wrong) unless you hack up the module object from C.
You can do it with descriptors on a ModuleType however, which should be
plenty fast from Cython-land.
In [16]: class AGetter(object):
:
I think the right thing to do here is make all module-level globals
into "cdef public" attributes, i.e. C globals with getters and setters
for Python space. I'm not sure whether this would best be done by
creating a custom dict or module subclass, but it would probably be
cleaner and afford much mo
I tried to optimize module lookups (__pyx_m) by caching internal PyDict state.
In this example bar() is 1.6 time faster (500us against 842us):
C = 123
def foo(a):
return C * adef bar():
for i in range(1): foo(i)
Here is proof of
concept:https://github.com/vitek/cython/commit/1d
17 matches
Mail list logo
