On Fri, May 7, 2021 at 8:14 PM Neil Schemenauer wrote:
>
> On 2021-05-07, Pablo Galindo Salgado wrote:
> > Technically the main concern may be the size of the unmarshalled
> > pyc files in memory, more than the storage size of disk.
>
> It would be cool if we could mmap the pyc files and have the
On Fri, May 7, 2021 at 6:51 PM Steven D'Aprano wrote:
> On Tue, Oct 20, 2020 at 01:53:34PM +0100, Mark Shannon wrote:
> > Hi everyone,
> >
> > CPython is slow. We all know that, yet little is done to fix it.
> >
> > I'd like to change that.
> > I have a plan to speed up CPython by a factor of
On 2021-05-07, Pablo Galindo Salgado wrote:
> Technically the main concern may be the size of the unmarshalled
> pyc files in memory, more than the storage size of disk.
It would be cool if we could mmap the pyc files and have the VM run
code without an unmarshal step. One idea is something
Although we were originally not sympathetic with it, we may need to offer
an opt-out mechanism for those users that care about the impact of the
overhead of the new data in pyc files
and in in-memory code objectsas was suggested by some folks (Thomas, Yury,
and others). For this, we could propose
On Fri, May 7, 2021 at 6:39 PM Steven D'Aprano wrote:
> On Fri, May 07, 2021 at 06:02:51PM -0700, Chris Jerdonek wrote:
>
> > To know what compression methods might be effective, I’m wondering if it
> > could be useful to see separate histograms of, say, the start column
> number
> > and width
> I'm wondering if it's possible to compromise with one position that's
not as complete but still gives a good hint:
Even if is possible, it will be quite less useful (a lot of users wanted to
highlight full ranges for syntax errors, and that change was very well
received
when we announce it in
On Tue, Oct 20, 2020 at 01:53:34PM +0100, Mark Shannon wrote:
> Hi everyone,
>
> CPython is slow. We all know that, yet little is done to fix it.
>
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few
> years. But it needs funding.
I've noticed a
On 2021-05-08 01:43, Pablo Galindo Salgado wrote:
Some update on the numbers. We have made some draft implementation to
corroborate the
numbers with some more realistic tests and seems that our original
calculations were wrong.
The actual increase in size is quite bigger than previously
On Fri, May 07, 2021 at 06:02:51PM -0700, Chris Jerdonek wrote:
> To know what compression methods might be effective, I’m wondering if it
> could be useful to see separate histograms of, say, the start column number
> and width over the code base. Or for people that really want to dig in,
>
On Fri, May 7, 2021 at 5:44 PM Pablo Galindo Salgado
wrote:
> Some update on the numbers. We have made some draft implementation to
> corroborate the
> numbers with some more realistic tests and seems that our original
> calculations were wrong.
> The actual increase in size is quite bigger than
One last note for clarity: that's the increase of size in the stdlib, the
increase of size
for pyc files goes from 28.471296MB to 34.750464MB, which is an increase of
22%.
On Sat, 8 May 2021 at 01:43, Pablo Galindo Salgado
wrote:
> Some update on the numbers. We have made some draft
Some update on the numbers. We have made some draft implementation to
corroborate the
numbers with some more realistic tests and seems that our original
calculations were wrong.
The actual increase in size is quite bigger than previously advertised:
Using bytes object to encode the final object
On Fri, 7 May 2021, 8:13 am Ethan Furman, wrote:
> On 5/6/21 7:14 AM, Jelle Zijlstra wrote:
>
> > Maybe others have different workflows, but I don't see much of a need
> > for keeping your fork's main branch up to date.
>
> I will occasionally do a `git push origin main` just to shut up the
>
On Sat, 8 May 2021, 8:53 am Pablo Galindo Salgado,
wrote:
> > One thought: could the stored column position not include the
> indentation? Would that help?
>
> The compiler doesn't have access easy access to the source unfortunately
> so we don't know how much is the indentation. This can make
On Tue, 4 May 2021, 10:50 am Łukasz Langa, wrote:
>
> On 4 May 2021, at 02:04, Łukasz Langa wrote:
>
> Having renamed the branch in my fork first, the exact sequence I used on
> my own clone was:
>
> ❯ git checkout master
> ❯ git branch -m master main
> ❯ git fetch origin
> ❯ git branch -u
It’s with great pleasure that I announce that python-docs-theme has been
released to PyPI.
Thanks to the hard work and patience of Olga Bulat, @obulat, Python’s doc theme
is now responsive. Many thanks to everyone who has contributed to this release
by filing issues, writing PRs, reviewing
> One thought: could the stored column position not include the
indentation? Would that help?
The compiler doesn't have access easy access to the source unfortunately so
we don't know how much is the indentation. This can make life
a bit harder for other tools, although it can make it easier for
Thanks, Irit for your comment!
> Is it really every instruction? Or only those that can raise exceptions?
Technically only the ones that can raise exceptions, but the majority can
and optimizing this to only restrict to the set that can raise exceptions
has
the danger than the mapping needs to
> haha, true... Does our parser even have a maximum line length? (I'm not
suggesting being unlimited or matching that if huge, 64k is already
ridiculous
We use py_ssize_t in some places but at the end of the day the lines and
columns have a limit of INT_MAX IIRC
On Fri, 7 May 2021 at 23:35,
This is actually a very good point. The only disadvantage is that it
complicates the parsing a bit and we loose the possibility of indexing
the table by instruction offset.
On Fri, 7 May 2021 at 23:01, Larry Hastings wrote:
> On 5/7/21 2:45 PM, Pablo Galindo Salgado wrote:
>
> Given that column
On Fri, May 7, 2021 at 3:24 PM Pablo Galindo Salgado
wrote:
> Thanks a lot Gregory for the comments!
>
> An additional cost to this is things that parse text tracebacks not
>> knowing how to handle it and things that log tracebacks
>> generating additional output.
>
> We should provide a way for
On 2021-05-07 22:56, Larry Hastings wrote:
On 5/7/21 2:45 PM, Pablo Galindo Salgado wrote:
Given that column numbers are not very big compared with line numbers,
we plan to store these as unsigned chars
or unsigned shorts. We ran some experiments over the standard library
and we found that the
On 2021-05-07 22:45, Pablo Galindo Salgado wrote:
Hi there,
We are preparing a PEP and we would like to start some early discussion
about one of the main aspects of the PEP.
The work we are preparing is to allow the interpreter to produce more
fine-grained error messages, pointing to
the
Thanks a lot Gregory for the comments!
An additional cost to this is things that parse text tracebacks not knowing
> how to handle it and things that log tracebacks generating additional
> output.
We should provide a way for people to disable the feature on a process as
> part of this while they
On Fri, May 7, 2021 at 2:50 PM Pablo Galindo Salgado
wrote:
> Hi there,
>
> We are preparing a PEP and we would like to start some early discussion
> about one of the main aspects of the PEP.
>
> The work we are preparing is to allow the interpreter to produce more
> fine-grained error messages,
On Fri, May 7, 2021 at 10:52 PM Pablo Galindo Salgado
wrote:
>
> The cost of this is having the start column number and end column number
> information for every bytecode instruction
>
Is it really every instruction? Or only those that can raise exceptions?
Technically the main concern may be the size of the unmarshalled pyc files
in memory, more than the storage size of disk.
On Fri, 7 May 2021, 23:04 Antoine Pitrou, wrote:
> On Fri, 7 May 2021 22:45:38 +0100
> Pablo Galindo Salgado wrote:
> >
> > The cost of this is having the start column
On Fri, May 7, 2021 at 3:01 PM Larry Hastings wrote:
> On 5/7/21 2:45 PM, Pablo Galindo Salgado wrote:
>
> Given that column numbers are not very big compared with line numbers, we
> plan to store these as unsigned chars
> or unsigned shorts. We ran some experiments over the standard library and
On Fri, 7 May 2021 22:45:38 +0100
Pablo Galindo Salgado wrote:
>
> The cost of this is having the start column number and end column number
> information for every bytecode instruction
> and this is what we want to discuss (there is also some stack cost to
> re-raise exceptions but that's not a
On 5/7/21 2:45 PM, Pablo Galindo Salgado wrote:
Given that column numbers are not very big compared with line numbers,
we plan to store these as unsigned chars
or unsigned shorts. We ran some experiments over the standard library
and we found that the overhead of all pyc files is:
* If we use
Hi there,
We are preparing a PEP and we would like to start some early discussion
about one of the main aspects of the PEP.
The work we are preparing is to allow the interpreter to produce more
fine-grained error messages, pointing to
the source associated to the instructions that are failing.
ACTIVITY SUMMARY (2021-04-30 - 2021-05-07)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7428 (-25)
closed 48377 (+104)
total 55805 (+79)
Open issues
32 matches
Mail list logo
