This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author skrah
Recipients Arfrever, Jim.Jewett, Trundle, alex, asvetlov, barry, bfroehle, chris.jerdonek, daniel.urban, david.villa, dmalcolm, eric.smith, ezio.melotti, gregory.p.smith, gvanrossum, jcea, jkloth, larry, mark.dickinson, ncoghlan, pitrou, scoder, serhiy.storchaka, skrah, v+python
Date 2013-02-17.12:38:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
Serhiy Storchaka <> wrote:
> >  { path: [string, bytes, int] => path_converter => path_t },
> And register types somewhere:

I must admit that I had a similar thought when I first heard about the project:
If we're going through all this anyway, why not have a registry with signatures
and type annotations for all functions?

But since we're dealing with C files, intuitively I think it's better to stick
to C conventions.

Imagine that the preprocessor had full-blown C parser support, so we could

  static int
  path_converter(/* [string, bytes, int] */ PyObject *o, void *p) {

Later we tell the preprocessor to generate a function taking an argument "path"
of type [string, bytes, int] that will be passed on to path_converter().

In the absence of type inference, it feels natural to me to declare the
type in both places.

What *is* a problem is that we need some discipline in case the type of
path_converter() changes at some point, since the C compiler won't know
about [string, bytes, int].
Date User Action Args
2013-02-17 12:38:34skrahsetrecipients: + skrah, gvanrossum, barry, gregory.p.smith, jcea, mark.dickinson, ncoghlan, pitrou, scoder, larry, eric.smith, jkloth, ezio.melotti, Arfrever, v+python, alex, Trundle, asvetlov, dmalcolm, daniel.urban, chris.jerdonek, Jim.Jewett, serhiy.storchaka, bfroehle, david.villa
2013-02-17 12:38:34skrahlinkissue16612 messages
2013-02-17 12:38:33skrahcreate