Re: [Cython] [ENH] Compile-time code execution (macros / templates)
Would the following be a good use case for what you're discussing?
```
cdef class Base:
cdef __cinit__(self, **kwargs):
for name in self.list_defined_on_subclass:
value = kwargs[name]
setattr(self, name, value)
cpdef copy(self):
kwargs = {name: getattr(self, name) for name
in self.list_defined_on_subclass}
return type(self)(**kwargs)
cdef class Foo(Base):
list_defined_on_subclass = ["foo", "bar"]
cdef class Bar(Base):
list_defined_on_subclass = ["bar", "baz"]
```
and then at compile-time have the macro expand Foo to something like
```
cdef class Foo:
cdef:
something foo
something_else bar
def __cinit__(self, *, foo, bar):
self.foo = foo
self.bar = bar
cpdef copy(self):
return type(self)(foo=self.foo, bar=self.bar)
```
On Fri, Feb 26, 2021 at 6:46 PM Prakhar Goel wrote:
> > Indeed, internally it rewrites the AST, of course. I think that's the
> > simplest way to implement it. But it doesn't mean the user that write
> > the compile-time code would have to be aware of the AST at all.
> > I mean, if you have a good use-case for it, then I'm ok with allowing
> > the compile-time code manipulating it. But I'd really prefer this not be
> > the main use of the compile-time execution feature.
>
> Ah. I see where you are coming from. Wouldn't this be a ridiculous
> amount of work? At least if we insisted on something with a clean
> mental model that wouldn't just shred the user with a thousand corner
> cases? It would need a whole new sub-syntax in Cython with detailed
> semantics for all the weird things code lets people do (e.g. what if
> the input function f gets used like a first-class object and placed in
> a Python list that then gets passed to another function... at compile
> time...). You're basically asking for scheme's syntax-case but harder
> because Python/Cython are nowhere near as regular! And scheme's
> syntax-case is a beast (read up on phase separation if you don't
> believe me: https://docs.racket-lang.org/guide/phases.html).
>
> AST manipulation isn't _that_ hard (esp. with good helper libraries)
> and on the plus side, the basic idea is dead-simple to implement: just
> call some random Python function that the user points you towards.
> There's going to be some scaffolding but of an entirely manageable
> amount.
>
> I mean... if you think "there's really no major obstacle" then more
> power to you! I'd love to see what you come up with. But I think
> you're underestimating the complexity of the task.
> --
>
> Warm Regards
> Prakhar Goel
> ___
> cython-devel mailing list
> cython-devel@python.org
> https://mail.python.org/mailman/listinfo/cython-devel
>
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] How best to contribute
Hi Matti, I've been on the developer mailing list for a while just soaking in the knowledge. I can't really contribute because of who my employer is, and how difficult it is to secure approvals. However I would love to join your calls if you want to schedule them. I for one am glad cython exists and love reading the mailing list when things come up on it. Best regards, Henry On Fri, Feb 26, 2021, 03:03 Matti Picus wrote: > Hi. > > I would like to start contributing in a meaningful way to Cython on the > order of ~1 day a week, within the framework of the time allocated to me > from my employer (Quansight Labs) toward open source contributions. Over > time, my goal is push for an HPy[0] backend for Cython, but I also want > to help the project move forward toward an official 3.0 release and in > general to help out where needed. > > > So working backwards: > > What are the immediate pain points that I could help out with in general? > > How can I help with the 3.0 release (there are issues marked as > "blockers", are all of them truly critical)? > > And, in the long term, is there a way to start designing a new backend > for HPy? > > > I would also like to suggest that Cython hold monthly open "developer > calls" where people can meet face-to-face (on zoom) to work out > priorities and triage particularly difficult issues or PRs. I would be > happy to try to set this up (mainly to negotiate a time that would work) > if you-all think it is a good idea and would contribute more than it > would distract. > > > Thanks, > > Matti > > > [0] HPy [https://hpy.readthedocs.io/en/latest] > > ___ > cython-devel mailing list > cython-devel@python.org > https://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [ENH] Compile-time code execution (macros / templates)
Hm.
If I understand correctly what you want is to generate attributes at
compile-time and then get all the benefits of having statically declared
attributes at run-time.
This looks like a very interesting use-case. I guess it's a kind of
named tuples with custom methods. The syntax you propose is quite
pythonic and I would love that cython support something like that.
However, in the current state of the code you proposed as some weird
stuff going on.
First and foremost, it would be quite challenging to disentangle what
should be executed at compile-time and what should be left for the
run-time.
Second, you'd actually generate a different Base class for each of its
subclasses. Which is pretty weird from a typing perspective. Your Foo
and Bar wouldn't have a common base class beside Object. I guess what
you're trying to do is kind of a compile-time generated mixin.
I guess a better outline for this could be something like this:
```
cdef class Base:
pass
def generate_mixin(attrs):
cdef class C:
# Generate content based on attrs
return C
ctfe Foo = generate_mixin(["foo", "bar"])
ctfe Bar = generate_mixin(["bar", "baz"])
```
These Foo and Bar classes could then be subclassed to add whatever
specific method you want.
On the other hand, the syntax I proposed makes it very clear what's
executed at compile-time or run-time, but cannot support your use-case.
Especially declaring a varying number of cdef attributes.
I know D supports features like this. But it does so with a vastly
different set of concepts. Like the `mixin` keyword that inline a
compile-time string into the code.
I guess I'll think about it and see if I can come up with a small set of
concepts and syntaxes that support this use-case without having to
resort to full blown AST manipulation.
Le Fri, Feb 26, 2021 at 07:07:23PM -0800, Brock Mendel a écrit :
>Would the following be a good use case for what you're discussing?
>```
>cdef class Base:
> cdef __cinit__(self, **kwargs):
> for name in self.list_defined_on_subclass:
> value = kwargs[name]
> setattr(self, name, value)
> cpdef copy(self):
> kwargs = {name: getattr(self, name) for name
>in self.list_defined_on_subclass}
> return type(self)(**kwargs)
>cdef class Foo(Base):
> list_defined_on_subclass = ["foo", "bar"]
>cdef class Bar(Base):
> list_defined_on_subclass = ["bar", "baz"]
>```
>and then at compile-time have the macro expand Foo to something like
>
>```
>cdef class Foo:
> cdef:
> something foo
> something_else bar
> def __cinit__(self, *, foo, bar):
> self.foo = foo
> self.bar = bar
> cpdef copy(self):
> return type(self)(foo=self.foo, bar=self.bar)
>```
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
