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 <newt0...@gmail.com> 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
