ΕΕΛΛΑΚ - Λίστες Ταχυδρομείου

Interest in "Python bindings for Apothesis" (GSoC 2026) - Introduction and Questions

  • Subject: Interest in "Python bindings for Apothesis" (GSoC 2026) - Introduction and Questions
  • From: Άρης Σκυλλάς <arisskyllas2004 [ at ] gmail [ dot ] com>
  • Date: Fri, 13 Mar 2026 18:51:14 +0200
Dear Nikolaos and Vissarion,

My name is Aristeidis Skyllas and I am a 4th year Computer Science student
at the National and Kapodistrian University of Athens. I am writing this
mail to express my strong interest in contributing to the project "Python
bindings for Apothesis" for GSoC 2026.

My technical background consists of strong C/C++ knowledge, moderate
experience in Python through university work in Machine Learning, SQL and
frontend development with React. My most recent work is a university
project based on the SIGMOD 2025 programming contest, where we built a
parallel hash join pipeline using advanced techniques in C++ such as
unchained hash table with bloom filtering, multi-threading and work
stealing, late-materialization, column-store and zero-copy to achieve high
performance executions.

In the past few days I have cloned the repository of "Apothesis", explored
it in depth, as well as building and running the simulation with the input
given. So far I have a general idea of the approach I would follow to
create the bindings. I plan using a binding tool such as pybind11 or
nanobind to create two layers. The first will consist of raw bindings,
wrapping the C++ classes and exposing them to Python. The second layer will
be a pure Python wrapper providing a user-friendly API for direct usage. On
top of that , there would be unit tests, documentation and usage examples.

I would really like to hear how you envision the project with these
questions:

1) How deep do you think the bindings should go? Obviously the user will
have bindings for initializing and executing the simulation and getting the
results. Beyond that, how deep should the python interface go? Should users
also be able to inspect and modify sites of the lattices, change parameters
or define processes?

2) While studying the code I realized that only the "SimpleCubic" lattice
type has been fully implemented. FCC, HCP and Diamond are missing features
like readHeightsFromFile(), buildSteps() and computeCoverages(). Are
completing these inside the project scope or the bindings are supposed to
wrap only the existing functionality?

If there is another preferred communication channel I would love to join
and discuss more ideas. Any answers on the above questions or guidance on
how to move forward from here would be greatly appreciated.

Best Regards,
Aris Skyllas
Github: ArisS44
----
Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του Google Summer of Code - A discussion list for student developers and mentors of Google Summer of Code projects.,
https://lists.ellak.gr/gsoc-developers/listinfo.html
Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr>.

πλοήγηση μηνυμάτων