<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Sionigdha,</p>
<p>Thanks for your proposal. We've discussed among several
maintainers, but no one appears to be available to mentor a GSoC
project.</p>
<p>Even</p>
<div class="moz-cite-prefix">Le 09/03/2026 à 16:21, Sionigdha
Sadhukhan via gdal-dev a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAGCrGoNt0vqbDc93USKw0AJPNtGhCQmjbZgTs24pAKSyFb_GYg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<p
class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal gmail-leading-[1.7]">I
also wanted to ask is GDAL planning to participate under the
OSGeo GSoC 2026 umbrella this year? I noticed there isn't a
GDAL-specific ideas page yet and wanted to check before
finalizing my proposal. I have also shared my introduction
and proposal direction on the OSGeo Discourse here: <a
class="gmail-underline gmail-underline-offset-2 gmail-decoration-1 gmail-decoration-current/40 gmail-hover:decoration-current gmail-focus:decoration-current moz-txt-link-freetext"
href="https://discourse.osgeo.org/t/introduction-sionigdha-sadhukhan-gsoc-2026-proposal-gdal-python-stub-hardening-runtime-validation-type-coverage/152757"
moz-do-not-send="true">https://discourse.osgeo.org/t/introduction-sionigdha-sadhukhan-gsoc-2026-proposal-gdal-python-stub-hardening-runtime-validation-type-coverage/152757</a></p>
<p
class="gmail-font-claude-response-body gmail-break-words gmail-whitespace-normal gmail-leading-[1.7]">If
any maintainer would be open to mentoring or giving feedback
on the proposal draft, I would be very grateful.</p>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Tue, 3 Mar 2026 at 18:46,
Sionigdha Sadhukhan <<a
href="mailto:snigdha.lee75@gmail.com"
moz-do-not-send="true" class="moz-txt-link-freetext">snigdha.lee75@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="font-size:inherit">
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)"
dir="auto">Hello GDAL developers,</p>
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">Over
the past weeks, while contributing to GDAL and working
on Python binding-related issues and PRs, I have been
studying the current Python stub generation pipeline in
detail. In particular, I explored the <code
style="font-family:monospace">docstub</code> integration
and the implementation in <code
style="font-family:monospace">_analysis.py</code>, <code
style="font-family:monospace">_docstrings.py</code>,
and <code style="font-family:monospace">_stubs.py</code>,
along with recent PRs related to docstring cleanup and
stub generation.</p>
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">From
examining the code, I understand that:</p>
<ul
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">
<li>
<p><code style="font-family:monospace">.pyi</code> files
are generated entirely from docstrings using a
custom Lark grammar.</p>
</li>
<li>
<p>Type resolution is handled through <code
style="font-family:monospace">TypeMatcher</code> and
import reconstruction.</p>
</li>
<li>
<p>Unresolved types fall back to <code
style="font-family:monospace">_typeshed.Incomplete</code>.</p>
</li>
<li>
<p>There is currently no mechanical validation step
ensuring that generated stubs remain consistent with
the actual runtime callable signatures produced by
SWIG.</p>
</li>
</ul>
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">This
means the stub layer is structurally decoupled from the
runtime bindings, and drift between:</p>
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">C++
→ SWIG → Python runtime → docstrings → generated stubs</p>
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">is
theoretically possible without automated detection.</p>
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">For
GSoC, I would like to explore a project focused on
hardening and modernizing this pipeline through
runtime–stub consistency validation and stricter
enforcement mechanisms.</p>
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">A
possible scope could include:</p>
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)"
dir="auto"><strong>Runtime–Stub Signature Validator</strong></p>
<ul
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">
<li>
<p>Import <code style="font-family:monospace">osgeo</code> modules
and inspect public callables using <code
style="font-family:monospace">inspect.signature()</code>.</p>
</li>
<li>
<p>Parse generated <code style="font-family:monospace">.pyi</code> files.</p>
</li>
<li>
<p>Detect mismatches in parameter names, counts,
defaults, and return presence.</p>
</li>
<li>
<p>Produce structured reports of inconsistencies.</p>
</li>
</ul>
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)"
dir="auto"><strong>Stricter Stub Generation Mode</strong></p>
<ul
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">
<li>
<p>Optionally fail (or emit stronger diagnostics) on
unresolved types instead of silently aliasing to <code
style="font-family:monospace">_typeshed.Incomplete</code>.</p>
</li>
<li>
<p>Provide measurable metrics on annotation coverage
and unresolved types.</p>
</li>
</ul>
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)"
dir="auto"><strong>CI Integration</strong></p>
<ul
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">
<li>
<p>Integrate validation checks into CI to prevent
silent drift over time.</p>
</li>
<li>
<p>Keep the approach incremental and compatible with
the existing docstring-driven workflow.</p>
</li>
</ul>
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">The
goal would not be to redesign SWIG bindings or replace
the current system, but to introduce a validation and
enforcement layer that increases confidence in typing
correctness, IDE support, and long-term maintainability
of the Python bindings.</p>
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">Before
developing this into a formal proposal, I would really
appreciate feedback on:</p>
<ul
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">
<li>
<p>Whether runtime–stub consistency validation aligns
with current Python binding priorities.</p>
</li>
<li>
<p>Whether there are known constraints or prior
efforts in this direction.</p>
</li>
<li>
<p>Whether this scope would be appropriate and
realistic for a GSoC project.</p>
</li>
</ul>
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)">Thank
you very much for your time. I would be happy to refine
or narrow this idea based on feedback.</p>
<p
style="font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:inherit;color:rgb(0,0,0)"
dir="auto">Best regards,<br>
Sionigdha</p>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>