[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

[Mark Shannon]

On 18/07/2020 9:20 am, Inada Naoki wrote:

It seems great improvement, but I am worrying about performance.

Adding more attributes to the code object will increase memory usage
and importing time. Is there some estimation of the overhead?


Zero overhead (approximately).
We are just replacing one compressed table with another at the C level.
The other attributes are computed.



And I am worrying precise tracing blocks future advanced bytecode optimization.
Can we omit precise tracing and line number information when
optimization (`-O`) is enabled?


I don't think that is a good idea.
Performing any worthwhile performance optimization requires that we can 
reason about the behavior of programs.

Consistent behavior makes that much easier.
Inconsistent "micro optimizations" make real optimizations harder.

Cheers,
Mark.



Regards,

On Fri, Jul 17, 2020 at 11:49 PM Mark Shannon  wrote:


Hi all,

I'd like to announce a new PEP.

It is mainly codifying that Python should do what you probably already
thought it did :)

Should be uncontroversial, but all comments are welcome.

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





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

[Python-Dev] Re: How to customize CPython to a minimal set

[Steve Dower]

On 21Jul2020 0633, Huang, Yang wrote:

Yes. Micropyhton is also in consideration.

But sqlite3 is the first usage. There should be some additional features 
like numpy, scipy... Not sure if micropython supports well?


Or is there a feasible way to strip CPython ?


Only by manually removing modules from your own build. However, if you 
do that but want to continue using third-party packages, you'll find 
that there is very little you can remove (and nothing of significance).


The most interesting modules to omit are ssl and ctypes, because of the 
exposure to likely security issues (via OpenSSL and libffi), but 
practically every module out there will have some sort of dependency on 
these. So you'll end up only removing small/niche modules that might 
save you a couple of kilobytes of Python code.


Of the modules you suggested initially, I think you'll find that you 
need all of them for SQLite, let alone more complex libraries such as numpy.


In theory, we could have a smaller set of modules, but in practice there 
are so many cross-dependencies already out there that there isn't much 
to gain right now. It would take a bit of an ecosystem "reset" (i.e. 
develop completely new popular libraries with more narrowly scoped 
dependencies) to narrow things down at this point, and there's not much 
chance of that happening.


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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Rob Cliffe via Python-Dev]

On 18/07/2020 11:23, emmanuel.coir...@caissedesdepots.fr wrote:

Ethan Furman wrote:

The problem with any kind of sigil/keyword is that it becomes line noise
-- we would have to train ourselves to ignore them in order to see the
structure and variables we are actually interested in.  Once we become

Every syntax element can become noise once we're used to it. This is how Groovy is built 
from Java : they removed everything that can be removed, and still be 
"understandable" by the compiler. The result is the language being counter 
intuitive for people that don't do Groovy everyday... Can I write thing like this ? Seems 
to work... And with that ? Works too, but I don't know if it produces the same effect...

We can also think about syntax elements as strucural elements like pillars, 
helping the thought to elaborate while reading the code. Pillars are 
constraints for people in a building (they block your view, you have to bypass 
them, ...), but they helps building bigger constructions, and we're all used to 
them.

In this slightly modified example from the PEP :

 match entree[-1]:
 case Sides.SPAM:
 response = "Have you got anything without Spam?"
 case "letuce":
 response = "blablabla"
 case side:
 response = f"Well, could I have their Spam instead of the {side} 
then?"
 case 1542 | "plop":
 response = "blablabla2"

It's difficult for someone not mastering this feature to see immediatly that 
"side" will get it's value changed and that the last case will never match.


+1



 match entree[-1]:
 case Sides.SPAM:
 response = "Have you got anything without Spam?"
 case "letuce":
 response = "blablabla"
 case side=:
 response = f"Well, could I have their Spam instead of the {side} 
then?"
 case 1542 | "plop":
 response = "blablabla2"

Here we immediatly see that the first two cases don't work in the same way as the third, 
because there is "something more". It will even maybe indicate that the last 
case is useless...


adept at ignoring them, we will again have difficulties when debugging
as we won't easily see them.
Besides which, the problem is solved:

namespace.var is a lookup
var is a store

These rules can't be deduced from a few examples, or from experience from other 
languages. You have to explicitly learn them.


+1


  Since newcomers won't propably learn them first (if at all), they won't understand how it works, 
and they will propably introduce bugs hard to debug. They'll think it's a kind of "swith 
case" new construct, and will use it that way, completly ignoring the "capturing" 
property that shows in some cases and not in others.

 match entree[-1]:
 case Sides.SPAM:
 # newcomers will understand that entree[-1] == Sides.SPAM and 
write the code they need

 SPAM = "spam"
 match entree[-1]:
 case SPAM:
 # newcomers will understand that entree[-1] == "spam" and write 
the code they need
 # ignoring that now, in the following code, SPAM == anything but 
"spam"
 # introducing a bug anywhere in the following code where SPAM is 
expected to hold the
 # initial value

Only a unit test case that test that SPAM has changed can detect this kind of bug. 
Generally speaking, unit test cases don't test values of "constants" before and 
after a test case. So it won't even help.

Here, we can argue that match is not a "switch case" like syntax, but newcomers from C, Java, 
Javascript, whatever WILL use it like a "switch case", and WILL read code where it will be used 
like that. Even if it's not the main use case, it will be used for that, because of 50 years of history of C 
that we can't ignore. Adding a "=" or something else will at least ring a bell.

We can argue that constants should be namespaced, but is it a general way of doing ? People can 
write "from module import SPAM" or "import module; module.SPAM". This is 
equivalent, but in one case, it may introduce a bug.

Do not forget that Python will be used by many more newcomers, new learners, new 
developers, data scientists, people with unknow backgrounds, and perhaps few, or no 
experience in programming. IMHO Python strength is that it's syntax is easy to learn 
because it is easy to deduce. The some rules that are counter-intuitive like the 
"else" clause for the loops can't cause any harm if misused because their 
misuse is detected immediatly, and we can avoid writing them (and most people do).

On the other hand, "capturing" variables mixed with "match" variables is 
counter-intuitive unless you explicitly learn the rules. You can't deduce it (there rules don't 
exist anywhere else). This feature is central of the PEP and will be used, and will introduce 
subtle bugs when misused.

That's why I consider the rules you stated is not the right way for this 
feature, and that we 

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

[Gregory P. Smith]

On Fri, Jul 17, 2020 at 10:41 AM Pablo Galindo Salgado 
wrote:

> I like the proposal in general but I am against removing lnotab. The
> reason is that many tools rely on reading this attribute to figure out the
> Python call stack information. For instance, many sampler profilers read
> this memory by using ptrace or process_vm_readv and they cannot execute any
> code on the process under tracing as that would be a security issue. If we
> remove a 'static' view of that information, it will impact negatively the
> current set of remote process analysis tools. The proposed new way of
> retrieving the line number will rely (if we deprecate and remove lnotab) on
> executing code, making it much more difficult for the ecosystem of
> profilers and remote process analysis tools to do their job.
>

+1 agreed.

"""Some care must be taken not to break existing tooling. To minimize
breakage, the co_lnotab attribute will be retained, but lazily generated on
demand.""" - https://www.python.org/dev/peps/pep-0626/#id4

This breaks existing tooling.

-gps


> --
>
> Pablo
>
> On Fri, 17 Jul 2020, 15:55 Mark Shannon,  wrote:
>
>> Hi all,
>>
>> I'd like to announce a new PEP.
>>
>> It is mainly codifying that Python should do what you probably already
>> thought it did :)
>>
>> Should be uncontroversial, but all comments are welcome.
>>
>> Cheers,
>> Mark.
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/BMX32UARJFY3PZZYKRANS6RCMR2XBVVM/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/57OXMUBV5FAEFXULRBCRAHEF7Q5GP6QT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NCW4PCOINV7HYUHND7EQ2GUWR22OZDXF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

[Carl Shapiro]

On Tue, Jul 21, 2020 at 11:46 AM Mark Shannon  wrote:

> On 18/07/2020 9:20 am, Inada Naoki wrote:
> > And I am worrying precise tracing blocks future advanced bytecode
> optimization.
> > Can we omit precise tracing and line number information when
> > optimization (`-O`) is enabled?
>
> I don't think that is a good idea.
> Performing any worthwhile performance optimization requires that we can
> reason about the behavior of programs.
> Consistent behavior makes that much easier.
> Inconsistent "micro optimizations" make real optimizations harder.
>

Echoing what Mark said, there should be no perceived tension between
debugging and optimization.  For over 20 years the JVM has been the
existence proof: Java is always precisely debuggable when the compiler is
generating code at the highest optimization levels.  IMHO, a Python user
shouldn't have to expect anything less.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/N2YEEYX5TVWLD3OAXTGMW77VSOCAIYVN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

[Gregory P. Smith]

On Fri, Jul 17, 2020 at 8:41 AM Ned Batchelder 
wrote:

> https://www.python.org/dev/peps/pep-0626/ :)
>
> --Ned.
>
> On 7/17/20 10:48 AM, Mark Shannon wrote:
> > Hi all,
> >
> > I'd like to announce a new PEP.
> >
> > It is mainly codifying that Python should do what you probably already
> > thought it did :)
> >
> > Should be uncontroversial, but all comments are welcome.
> >
> > Cheers,
> > Mark.
>
>
"""When a frame object is created, the f_lineno will be set to the line at
which the function or class is defined. For modules it will be set to
zero."""

Within this PEP it'd be good for us to be very pedantic.  f_lineno is a
single number.  So which number is it given many class and function
definition statements can span multiple lines.

Is it the line containing the class or def keyword?  Or is it the line
containing the trailing :?

Q: Why can't we have the information about the entire span of lines rather
than consider a definition to be a "line"?

I think that question applies to later sections as well.  Anywhere we refer
to a "line", it could actually mean a span of lines. (especially when you
consider \ continuation in situations you might not otherwise think could
span lines)

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

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

[Gregory P. Smith]

On Tue, Jul 21, 2020 at 1:39 PM Gregory P. Smith  wrote:

>
> On Fri, Jul 17, 2020 at 10:41 AM Pablo Galindo Salgado <
> pablog...@gmail.com> wrote:
>
>> I like the proposal in general but I am against removing lnotab. The
>> reason is that many tools rely on reading this attribute to figure out the
>> Python call stack information. For instance, many sampler profilers read
>> this memory by using ptrace or process_vm_readv and they cannot execute any
>> code on the process under tracing as that would be a security issue. If we
>> remove a 'static' view of that information, it will impact negatively the
>> current set of remote process analysis tools. The proposed new way of
>> retrieving the line number will rely (if we deprecate and remove lnotab) on
>> executing code, making it much more difficult for the ecosystem of
>> profilers and remote process analysis tools to do their job.
>>
>
> +1 agreed.
>
> """Some care must be taken not to break existing tooling. To minimize
> breakage, the co_lnotab attribute will be retained, but lazily generated on
> demand.""" - https://www.python.org/dev/peps/pep-0626/#id4
>
> This breaks existing tooling.
>

"The co_linetable attribute will hold the line number information. The
format is opaque, unspecified and may be changed without notice."
...
"Tools that parse the co_lnotab table should move to using the new
co_lines() method as soon as is practical."

Given it is impossible for tools doing passive inspection of Python VM
instances to execute code, co_linetable's exact format will be depended on
just as co_lnotab was.  co_lnotab was only quasi-"officially" documented in
the Python docs, it's spec lives in
https://github.com/python/cpython/blob/master/Objects/lnotab_notes.txt (pointed
to by a couple module's docs). The lnotab format "changed" once, in 3.6, an
unsigned delta was changed to signed (but I don't believe anything beyond
some experiments ever actually used negatives?).

How about creating something defined and always present for once given the
need has been demonstrated.  Even if we don't, it will be used, and we will
be unable to change it within a release.

-gps


> -gps
>
>
>> --
>>
>> Pablo
>>
>> On Fri, 17 Jul 2020, 15:55 Mark Shannon,  wrote:
>>
>>> Hi all,
>>>
>>> I'd like to announce a new PEP.
>>>
>>> It is mainly codifying that Python should do what you probably already
>>> thought it did :)
>>>
>>> Should be uncontroversial, but all comments are welcome.
>>>
>>> Cheers,
>>> Mark.
>>> ___
>>> Python-Dev mailing list -- python-dev@python.org
>>> To unsubscribe send an email to python-dev-le...@python.org
>>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>>> Message archived at
>>> https://mail.python.org/archives/list/python-dev@python.org/message/BMX32UARJFY3PZZYKRANS6RCMR2XBVVM/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/57OXMUBV5FAEFXULRBCRAHEF7Q5GP6QT/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HFQKDM4TVJPNHHHIJN3BGU2N3CRRXNQY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

[Inada Naoki]

On Wed, Jul 22, 2020 at 3:43 AM Mark Shannon  wrote:
>
> On 18/07/2020 9:20 am, Inada Naoki wrote:
> > It seems great improvement, but I am worrying about performance.
> >
> > Adding more attributes to the code object will increase memory usage
> > and importing time. Is there some estimation of the overhead?
>
> Zero overhead (approximately).
> We are just replacing one compressed table with another at the C level.
> The other attributes are computed.
>
> >
> > And I am worrying precise tracing blocks future advanced bytecode 
> > optimization.
> > Can we omit precise tracing and line number information when
> > optimization (`-O`) is enabled?
>
> I don't think that is a good idea.
> Performing any worthwhile performance optimization requires that we can
> reason about the behavior of programs.
> Consistent behavior makes that much easier.
> Inconsistent "micro optimizations" make real optimizations harder.
>
> Cheers,
> Mark.
>

Tracing output is included in the program behavior?

For example, if two code block is completely equal:

if a == 1:
   very very
   long
   code block
elif a == 2:
   very very
   long
   code block

This code can be translated into like this (pseudo code):

if a == 1:
goto block1
if a == 2:
goto block1
block1:
very very
long
code block

But if we merge two equal code blocks, we can not produce precise line
numbers, can we?
Is this inconsistent microoptimization that real optimization harder?
This optimization must be prohibited in future Python?

Regards,
-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/F7J337VCPPS47QYSNKSQ2CXGRNQTAYJG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: datetime module refactoring: folder vs parallel private modules

[Antoine Pitrou]

On Mon, 20 Jul 2020 19:49:38 -0700
Guido van Rossum  wrote:
> I would go with Ivan's second suggestion (_pydatetime.py). The Zen of
> Python mentions "flat is better than nested" and a package seems overkill
> here (I'm not sure why you chose a package for zoneinfo, but it looks like
> it has a little more internal structure than a datetime package would have.)

Just my two cents, but I agree with Guido.

Best regards

Antoine.

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

[Python-Dev] Re: How to customize CPython to a minimal set

[Huang, Yang]

Hi, Guido

Yes. Micropyhton is also in consideration.
But sqlite3 is the first usage. There should be some additional features like 
numpy, scipy... Not sure if micropython supports well?

Or is there a feasible way to strip CPython ?

Thanks.

From: Guido van Rossum 
Sent: Monday, July 20, 2020 10:45 PM
To: Huang, Yang 
Cc: python-dev@python.org
Subject: Re: [Python-Dev] How to customize CPython to a minimal set

Have you considered starting with micropython? It’s made for embedded systems 
and fully supports Python 3 syntax. Adding sqlite3 support to it will be less 
work than stripping all the I/O from CPython.

—Guido

On Mon, Jul 20, 2020 at 06:48 Huang, Yang 
mailto:yang.hu...@intel.com>> wrote:

Hi, all

There is a request to run python in a Linux-based embedded resource constrained 
system with sqlite3 support.

So many features are not required, like posixmodule, signalmodule, hashtable ...
But seems there are some dependencies among the 
Modules/Parser/Python/Objects/Programs...

Is there a way to tailor CPython 3 to a minimal set with sqlite3 (the less 
syscalls the better) ?
Is it possible to do that?

Thank you.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to 
python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ECPLKXQ42VNLHD5DP3RG57L3QTJ77FUT/
Code of Conduct: http://python.org/psf/codeofconduct/
--
--Guido (mobile)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CVRL4VTGITKVHLHHTZR5HBCZ4EK2WIPE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How to customize CPython to a minimal set

[Guido van Rossum]

I expect it will be unfeasible to strip CPython. If you disagree, try it.
;-)

On Mon, Jul 20, 2020 at 22:35 Huang, Yang  wrote:

> Hi, Guido
>
>
>
> Yes. Micropyhton is also in consideration.
>
> But sqlite3 is the first usage. There should be some additional features
> like numpy, scipy... Not sure if micropython supports well?
>
>
>
> Or is there a feasible way to strip CPython ?
>
>
>
> Thanks.
>
>
>
> *From:* Guido van Rossum 
> *Sent:* Monday, July 20, 2020 10:45 PM
> *To:* Huang, Yang 
> *Cc:* python-dev@python.org
> *Subject:* Re: [Python-Dev] How to customize CPython to a minimal set
>
>
>
> Have you considered starting with micropython? It’s made for embedded
> systems and fully supports Python 3 syntax. Adding sqlite3 support to it
> will be less work than stripping all the I/O from CPython.
>
>
>
> —Guido
>
>
>
> On Mon, Jul 20, 2020 at 06:48 Huang, Yang  wrote:
>
>
> Hi, all
>
> There is a request to run python in a Linux-based embedded resource
> constrained system with sqlite3 support.
>
> So many features are not required, like posixmodule, signalmodule,
> hashtable ...
> But seems there are some dependencies among the
> Modules/Parser/Python/Objects/Programs...
>
> Is there a way to tailor CPython 3 to a minimal set with sqlite3 (the less
> syscalls the better) ?
> Is it possible to do that?
>
> Thank you.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/ECPLKXQ42VNLHD5DP3RG57L3QTJ77FUT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> --Guido (mobile)
>
-- 
--Guido (mobile)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6KGEFLM7M5L457WH5JJLL6UEGJSABLPE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How to customize CPython to a minimal set

[MRAB]

On 2020-07-21 06:33, Huang, Yang wrote:

Hi, Guido

Yes. Micropyhton is also in consideration.

But sqlite3 is the first usage. There should be some additional features 
like numpy, scipy... Not sure if micropython supports well?


Or is there a feasible way to strip CPython ?

Thanks.


You want a minimal Python, yet with numpy, scipy, ...? Those sound like 
contradictory goals to me!




*From:* Guido van Rossum 
*Sent:* Monday, July 20, 2020 10:45 PM
*To:* Huang, Yang 
*Cc:* python-dev@python.org
*Subject:* Re: [Python-Dev] How to customize CPython to a minimal set

Have you considered starting with micropython? It’s made for embedded 
systems and fully supports Python 3 syntax. Adding sqlite3 support to it 
will be less work than stripping all the I/O from CPython.


—Guido

On Mon, Jul 20, 2020 at 06:48 Huang, Yang > wrote:



Hi, all

There is a request to run python in a Linux-based embedded resource
constrained system with sqlite3 support.

So many features are not required, like posixmodule, signalmodule,
hashtable ...
But seems there are some dependencies among the
Modules/Parser/Python/Objects/Programs...

Is there a way to tailor CPython 3 to a minimal set with sqlite3
(the less syscalls the better) ?
Is it possible to do that?

Thank you.


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