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 th
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 th
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
> > thoug
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 memor
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 t
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 o
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 be
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 modul
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
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 su
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
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 lit
12 matches
Mail list logo
