[Python-ideas] Re: Bring back PEP 501

[Chris Angelico]

On Sat, May 8, 2021 at 8:21 AM Richard Damon  wrote:
>
> On 5/7/21 5:56 PM, Nick Humrich wrote:
> > Marc,
> >
> > You might have misunderstood me. I am not recommending sending the
> > database raw strings without parameters, but rather that i-strings
> > turn things into parameters and its impossible to mess up. Let me
> > explain a little.
> >
> > In sqlalchemy, you can use a format such as "update items set a=:value
> > where id=:item_id" then you tell it the value of the parameters.
> > SQLAlchemy then takes the :something part of the string and turns it
> > into a parameter ($1, $2, etc). The problem being however, there is
> > nothing stopping me from doing an f string on accident: f"update items
> > set a={something} where id=:value". Because f-strings are eager,
> > sqlalchemy cant protect you, you are now vulnerable to injection.
> > But with i-strings, because they are not eager, it would actually know
> > that you passed in the value as a variable, and turn it into a
> > parameter. It knows the difference between the static part of the
> > query and the dynamic part of the query, so it can actually protect
> > you from yourself, or protect early engineers who don't even know what
> > injection is.
> >
> > Nick
> >
> I think the issue is what would the result of the i-string actually be?
> The database APIs want typically a string + a tuple or a dictionary, two
> seperate things. Are you suggesting that to use i-stings, all the API's
> need to be adjusted to accept some new type of object that is a
> string/dictionary combo?
>

That would be the case, yes. An i-string would have to return a single
object (because every expression in Python is a single object), so
anything that's expecting two parameters would need to learn how to
handle that.

That's a small consideration, though. People can always create their
own small wrappers, eg:

def sql(istring):
return cursor.execute(istring.base, istring.vars)

or something like that. And APIs can be enhanced over time, with
i-string support being added to more things, same as Pathlib support
has been progressively added.

+1 on revisiting this.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5LN25VHERQXUJKBBUUPUJFW2YYBNSI25/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Bring back PEP 501

[Richard Damon]

On 5/7/21 5:56 PM, Nick Humrich wrote:
> Marc,
>
> You might have misunderstood me. I am not recommending sending the
> database raw strings without parameters, but rather that i-strings
> turn things into parameters and its impossible to mess up. Let me
> explain a little. 
>
> In sqlalchemy, you can use a format such as "update items set a=:value
> where id=:item_id" then you tell it the value of the parameters.
> SQLAlchemy then takes the :something part of the string and turns it
> into a parameter ($1, $2, etc). The problem being however, there is
> nothing stopping me from doing an f string on accident: f"update items
> set a={something} where id=:value". Because f-strings are eager,
> sqlalchemy cant protect you, you are now vulnerable to injection. 
> But with i-strings, because they are not eager, it would actually know
> that you passed in the value as a variable, and turn it into a
> parameter. It knows the difference between the static part of the
> query and the dynamic part of the query, so it can actually protect
> you from yourself, or protect early engineers who don't even know what
> injection is. 
>
> Nick
>
I think the issue is what would the result of the i-string actually be?
The database APIs want typically a string + a tuple or a dictionary, two
seperate things. Are you suggesting that to use i-stings, all the API's
need to be adjusted to accept some new type of object that is a
string/dictionary combo?

-- 
Richard Damon

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VX4QLIKNONV2UE6KNBJK6KA42MTVIUM7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Bring back PEP 501

[Nick Humrich]

Marc,

You might have misunderstood me. I am not recommending sending the database
raw strings without parameters, but rather that i-strings turn things into
parameters and its impossible to mess up. Let me explain a little.

In sqlalchemy, you can use a format such as "update items set a=:value
where id=:item_id" then you tell it the value of the parameters. SQLAlchemy
then takes the :something part of the string and turns it into a parameter
($1, $2, etc). The problem being however, there is nothing stopping me from
doing an f string on accident: f"update items set a={something} where
id=:value". Because f-strings are eager, sqlalchemy cant protect you, you
are now vulnerable to injection.
But with i-strings, because they are not eager, it would actually know that
you passed in the value as a variable, and turn it into a parameter. It
knows the difference between the static part of the query and the dynamic
part of the query, so it can actually protect you from yourself, or protect
early engineers who don't even know what injection is.

Nick


On Fri, May 7, 2021, 2:48 PM M.-A. Lemburg  wrote:

> On 07.05.2021 22:39, Ram Rachum wrote:
> > Hi Marc.
> >
> > On Fri, May 7, 2021 at 11:32 PM M.-A. Lemburg  > > wrote:
> >
> > On 07.05.2021 21:40, Nick Humrich wrote:
> > > PEP 501 was deferred because more learning and time was wanted
> after
> > introducing
> > > f-strings. Now that it has been 5 years, I wonder what the
> possibilities of
> > > revisiting PEP 501 are.
> > >
> > > I recently had the experience of using javascript "tagged template
> > literals" and
> > > was able to build a SQL string parser that is impossible to have
> SQL injection
> > > with. This is done by having the database connection object only
> accept a
> > > certain type of object, and all sql tagged template literals
> become that
> > object.
> > > Because variables are lazy evaluated, the template function can
> turn all
> > dynamic
> > > inputs into parameters in a SQL query. It is impossible for a dev
> to
> > > accidentally add a user imputed string as a literal.
> > > PEP 501 already mentions how templates (i-strings?) can solve
> injection.
> > This is
> > > a very incredible goal. Injection has been the #1 vulnerability on
> OWASP for
> > > over 10 years, and has been in the top 5 the entire time OWASP has
> existed
> > > (almost 20 years now).
> > > We have an opportunity to completely remove injection attacks.
> >
> > I think you ought to not use SQL injection as the primary argument
> > for i-strings.
> >
> > The DB API highly recommends passing any arguments
> > to a SQL to the database via binding parameters and let the database
> > do the binding of the SQL template on the server side.
> >
> > Sending those SQL templates and the parameters separately to the
> > database is not only safer, but also a lot more efficient and allows
> > for the database to much better manage query plan caching and reuse.
> >
> >
> > Interesting. When you do that in Python, does that mean something like
> %s in the
> > SQL query, and then after the query a list of arguments in the same
> order as the
> > %s tokens? Because if that's the case, maybe it'll be better to use an
> i-string
> > there, and NOT have the Python layer format the string, but use that
> i-string to
> > send the parameters separately to the database. It might be easier to
> read that way.
>
> The %s tokens in %-formatted SQL strings for e.g. PostgreSQL
> are sent to the database as-is. The binding of the parameters,
> which are passed separately as a tuple, is done by the database
> and not in Python, even though the format looks a lot like the
> %-formatting used in Python.
>
> There are other formats as well, e.g. the ? token format
> used in ODBC or the :1 tokens used for e.g. Oracle.
>
> See https://www.python.org/dev/peps/pep-0249/#paramstyle for
> details.
>
> > Even with i-strings we should *not* recommend doing the binding
> > of SQL strings in the Python application.
> >
> > There are other use cases where lazy binding can be useful, though,
> > e.g. when you don't know whether the interpolation will actually
> > get used (logging) or where you may want to render the template
> > in a different or extended namespace.
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, May 07 2021)
> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
> >>> Python Product Development ...https://consulting.egenix.com/
> 
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Am

[Python-ideas] Re: Bring back PEP 501

[M.-A. Lemburg]

On 07.05.2021 22:39, Ram Rachum wrote:
> Hi Marc.
> 
> On Fri, May 7, 2021 at 11:32 PM M.-A. Lemburg  > wrote:
> 
> On 07.05.2021 21:40, Nick Humrich wrote:
> > PEP 501 was deferred because more learning and time was wanted after
> introducing
> > f-strings. Now that it has been 5 years, I wonder what the 
> possibilities of
> > revisiting PEP 501 are. 
> >
> > I recently had the experience of using javascript "tagged template
> literals" and
> > was able to build a SQL string parser that is impossible to have SQL 
> injection
> > with. This is done by having the database connection object only accept 
> a
> > certain type of object, and all sql tagged template literals become that
> object.
> > Because variables are lazy evaluated, the template function can turn all
> dynamic
> > inputs into parameters in a SQL query. It is impossible for a dev to
> > accidentally add a user imputed string as a literal.
> > PEP 501 already mentions how templates (i-strings?) can solve injection.
> This is
> > a very incredible goal. Injection has been the #1 vulnerability on 
> OWASP for
> > over 10 years, and has been in the top 5 the entire time OWASP has 
> existed
> > (almost 20 years now).
> > We have an opportunity to completely remove injection attacks.
> 
> I think you ought to not use SQL injection as the primary argument
> for i-strings.
> 
> The DB API highly recommends passing any arguments
> to a SQL to the database via binding parameters and let the database
> do the binding of the SQL template on the server side.
> 
> Sending those SQL templates and the parameters separately to the
> database is not only safer, but also a lot more efficient and allows
> for the database to much better manage query plan caching and reuse.
> 
> 
> Interesting. When you do that in Python, does that mean something like %s in 
> the
> SQL query, and then after the query a list of arguments in the same order as 
> the
> %s tokens? Because if that's the case, maybe it'll be better to use an 
> i-string
> there, and NOT have the Python layer format the string, but use that i-string 
> to
> send the parameters separately to the database. It might be easier to read 
> that way.
  
The %s tokens in %-formatted SQL strings for e.g. PostgreSQL
are sent to the database as-is. The binding of the parameters,
which are passed separately as a tuple, is done by the database
and not in Python, even though the format looks a lot like the
%-formatting used in Python.

There are other formats as well, e.g. the ? token format
used in ODBC or the :1 tokens used for e.g. Oracle.

See https://www.python.org/dev/peps/pep-0249/#paramstyle for
details.

> Even with i-strings we should *not* recommend doing the binding
> of SQL strings in the Python application.
> 
> There are other use cases where lazy binding can be useful, though,
> e.g. when you don't know whether the interpolation will actually
> get used (logging) or where you may want to render the template
> in a different or extended namespace.
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 07 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YAGN7N45TCTLFNQNGC2RKVLHIHMBTQ76/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Bring back PEP 501

[Ram Rachum]

Hi Marc.

On Fri, May 7, 2021 at 11:32 PM M.-A. Lemburg  wrote:

> On 07.05.2021 21:40, Nick Humrich wrote:
> > PEP 501 was deferred because more learning and time was wanted after
> introducing
> > f-strings. Now that it has been 5 years, I wonder what the possibilities
> of
> > revisiting PEP 501 are.
> >
> > I recently had the experience of using javascript "tagged template
> literals" and
> > was able to build a SQL string parser that is impossible to have SQL
> injection
> > with. This is done by having the database connection object only accept a
> > certain type of object, and all sql tagged template literals become that
> object.
> > Because variables are lazy evaluated, the template function can turn all
> dynamic
> > inputs into parameters in a SQL query. It is impossible for a dev to
> > accidentally add a user imputed string as a literal.
> > PEP 501 already mentions how templates (i-strings?) can solve injection.
> This is
> > a very incredible goal. Injection has been the #1 vulnerability on OWASP
> for
> > over 10 years, and has been in the top 5 the entire time OWASP has
> existed
> > (almost 20 years now).
> > We have an opportunity to completely remove injection attacks.
>
> I think you ought to not use SQL injection as the primary argument
> for i-strings.
>
> The DB API highly recommends passing any arguments
> to a SQL to the database via binding parameters and let the database
> do the binding of the SQL template on the server side.
>
> Sending those SQL templates and the parameters separately to the
> database is not only safer, but also a lot more efficient and allows
> for the database to much better manage query plan caching and reuse.
>

Interesting. When you do that in Python, does that mean something like %s
in the SQL query, and then after the query a list of arguments in the same
order as the %s tokens? Because if that's the case, maybe it'll be better
to use an i-string there, and NOT have the Python layer format the string,
but use that i-string to send the parameters separately to the database. It
might be easier to read that way.


>
> Even with i-strings we should *not* recommend doing the binding
> of SQL strings in the Python application.
>
> There are other use cases where lazy binding can be useful, though,
> e.g. when you don't know whether the interpolation will actually
> get used (logging) or where you may want to render the template
> in a different or extended namespace.
>  --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, May 07 2021)
> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
> >>> Python Product Development ...https://consulting.egenix.com/
> 
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amtsgericht Duesseldorf: HRB 46611
>https://www.egenix.com/company/contact/
>  https://www.malemburg.com/
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/3OILH2BEAFQFCANUX3Q4BBT6H3W3MUXJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SA5BMJE3KGQRPVW3ARGM2ITPSZBGECDX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Bring back PEP 501

[M.-A. Lemburg]

On 07.05.2021 21:40, Nick Humrich wrote:
> PEP 501 was deferred because more learning and time was wanted after 
> introducing
> f-strings. Now that it has been 5 years, I wonder what the possibilities of
> revisiting PEP 501 are. 
> 
> I recently had the experience of using javascript "tagged template literals" 
> and
> was able to build a SQL string parser that is impossible to have SQL injection
> with. This is done by having the database connection object only accept a
> certain type of object, and all sql tagged template literals become that 
> object.
> Because variables are lazy evaluated, the template function can turn all 
> dynamic
> inputs into parameters in a SQL query. It is impossible for a dev to
> accidentally add a user imputed string as a literal.
> PEP 501 already mentions how templates (i-strings?) can solve injection. This 
> is
> a very incredible goal. Injection has been the #1 vulnerability on OWASP for
> over 10 years, and has been in the top 5 the entire time OWASP has existed
> (almost 20 years now).
> We have an opportunity to completely remove injection attacks.

I think you ought to not use SQL injection as the primary argument
for i-strings.

The DB API highly recommends passing any arguments
to a SQL to the database via binding parameters and let the database
do the binding of the SQL template on the server side.

Sending those SQL templates and the parameters separately to the
database is not only safer, but also a lot more efficient and allows
for the database to much better manage query plan caching and reuse.

Even with i-strings we should *not* recommend doing the binding
of SQL strings in the Python application.

There are other use cases where lazy binding can be useful, though,
e.g. when you don't know whether the interpolation will actually
get used (logging) or where you may want to render the template
in a different or extended namespace.
 --
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 07 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3OILH2BEAFQFCANUX3Q4BBT6H3W3MUXJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Bring back PEP 501

[Ram Rachum]

+1

On Fri, May 7, 2021 at 10:42 PM Nick Humrich  wrote:

> PEP 501 was deferred because more learning and time was wanted after
> introducing f-strings. Now that it has been 5 years, I wonder what the
> possibilities of revisiting PEP 501 are.
>
> I recently had the experience of using javascript "tagged template
> literals" and was able to build a SQL string parser that is impossible to
> have SQL injection with. This is done by having the database connection
> object only accept a certain type of object, and all sql tagged template
> literals become that object. Because variables are lazy evaluated, the
> template function can turn all dynamic inputs into parameters in a SQL
> query. It is impossible for a dev to accidentally add a user imputed string
> as a literal.
> PEP 501 already mentions how templates (i-strings?) can solve injection.
> This is a very incredible goal. Injection has been the #1 vulnerability on
> OWASP for over 10 years, and has been in the top 5 the entire time OWASP
> has existed (almost 20 years now).
> We have an opportunity to completely remove injection attacks.
>
> I won't go through and mention other possibilities of i-strings because
> the PEP already does an amazing job of doing that.
>
>
> All recent (within the last two years) discussions of PEP 501 have
> proposed PEP 501 as a solution to various idea suggested, but then no
> further discussion on 501 happened. At least, not that I am aware of. If
> any further discussion of 501 has happened, I would be happy to read up and
> try to address any concerns.
> Some recent discussions were 501 is mentioned:
>
> https://mail.python.org/archives/list/python-ideas@python.org/thread/T3B56IXWSIPYFD33CMOSSYWMHPGLTDEZ/#MEE3X3HNLKU3ZX6JWHP3XCFUHELKHNLK
>
> https://mail.python.org/archives/list/python-ideas@python.org/thread/DX2ILPS2CHH5O5EGHQCAZG27NOZETYYQ/#WFYOO247PYWQNQW5CGOTVVBFBBLGCYCJ
>
> https://mail.python.org/archives/list/python-ideas@python.org/thread/3Z2YTIGJLSYMKKIGRSFK2DTDIXXVDGEK/#JMYEWFPO7XVLAX5VD7TBPNQW53SM3ZPN
>
> https://mail.python.org/archives/list/python-ideas@python.org/thread/DKW6Z6WKRWVPXPKYY2RUEX3NE4YZR5NR/#YBVUA74Y3FX7P5G4V74JQKQAADAUL4EM
>
> https://mail.python.org/archives/list/python-ideas@python.org/thread/ASPNKHVL7MSVVG3LHG2Z6S3SHV6AVIPN/#XKXXE7752ZBVULFTCOEOTZVCXGMXMY4L
>
>
> I would be willing to do any work required to get this PEP improved, but
> am very new to the PEP process and is what is needed. What is needed to
> revisit PEP 501, and what can I do to help?
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/5AW73ICBD4CVCRUNISRNAERPPF2KSOGZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KRW36VTPDFCGXEAIEN725GU42EFCFJQP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Bring back PEP 501

[Nick Humrich]

PEP 501 was deferred because more learning and time was wanted after
introducing f-strings. Now that it has been 5 years, I wonder what the
possibilities of revisiting PEP 501 are.

I recently had the experience of using javascript "tagged template
literals" and was able to build a SQL string parser that is impossible to
have SQL injection with. This is done by having the database connection
object only accept a certain type of object, and all sql tagged template
literals become that object. Because variables are lazy evaluated, the
template function can turn all dynamic inputs into parameters in a SQL
query. It is impossible for a dev to accidentally add a user imputed string
as a literal.
PEP 501 already mentions how templates (i-strings?) can solve injection.
This is a very incredible goal. Injection has been the #1 vulnerability on
OWASP for over 10 years, and has been in the top 5 the entire time OWASP
has existed (almost 20 years now).
We have an opportunity to completely remove injection attacks.

I won't go through and mention other possibilities of i-strings because the
PEP already does an amazing job of doing that.


All recent (within the last two years) discussions of PEP 501 have proposed
PEP 501 as a solution to various idea suggested, but then no further
discussion on 501 happened. At least, not that I am aware of. If any
further discussion of 501 has happened, I would be happy to read up and try
to address any concerns.
Some recent discussions were 501 is mentioned:
https://mail.python.org/archives/list/python-ideas@python.org/thread/T3B56IXWSIPYFD33CMOSSYWMHPGLTDEZ/#MEE3X3HNLKU3ZX6JWHP3XCFUHELKHNLK
https://mail.python.org/archives/list/python-ideas@python.org/thread/DX2ILPS2CHH5O5EGHQCAZG27NOZETYYQ/#WFYOO247PYWQNQW5CGOTVVBFBBLGCYCJ
https://mail.python.org/archives/list/python-ideas@python.org/thread/3Z2YTIGJLSYMKKIGRSFK2DTDIXXVDGEK/#JMYEWFPO7XVLAX5VD7TBPNQW53SM3ZPN
https://mail.python.org/archives/list/python-ideas@python.org/thread/DKW6Z6WKRWVPXPKYY2RUEX3NE4YZR5NR/#YBVUA74Y3FX7P5G4V74JQKQAADAUL4EM
https://mail.python.org/archives/list/python-ideas@python.org/thread/ASPNKHVL7MSVVG3LHG2Z6S3SHV6AVIPN/#XKXXE7752ZBVULFTCOEOTZVCXGMXMY4L


I would be willing to do any work required to get this PEP improved, but am
very new to the PEP process and is what is needed. What is needed to
revisit PEP 501, and what can I do to help?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5AW73ICBD4CVCRUNISRNAERPPF2KSOGZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Adding classes to modules is a tedious job. Wait! What about introducing a slot in PyModuleDef to hold the objects?

[Shreyan Avigyan]

It's tedious to add classes one by one using PyModule_AddObject in 
PyInit_module function. Wouldn't it be much easier if there's a slot that has 
an array of all the classes in their PyObject form and it'll automatically add 
those classes. Since this is a backwards compatibility change it'll be best if 
a macro (like PY_AUTO_OBJECT maybe?) is defined then it'll add those classes 
automatically. If the slot is NULL or 0 then don't add anything. But yeah they 
may add more classes if they want but it doesn't matter much.

Thanking you,

With Regards,
Shreyan Avigyan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/H6VU6PKXRYZEZSDVX2JPVQOYQ7LU2PD7/
Code of Conduct: http://python.org/psf/codeofconduct/