Guido van Rossum added the comment:
In a brief off-line chat we concluded that the desired API would be closer to
PyErr_Restore().
--
___
Python tracker
<https://bugs.python.org/issue45
Change by Guido van Rossum :
--
Removed message: https://bugs.python.org/msg403481
___
Python tracker
<https://bugs.python.org/issue14757>
___
___
Python-bug
Guido van Rossum added the comment:
Followup: https://github.com/faster-cpython/ideas/issues/93
New paper: https://arxiv.org/abs/2109.02958
--
___
Python tracker
<https://bugs.python.org/issue14
Guido van Rossum added the comment:
See GitHub.com/faster-cpython/ideas/issues/93 for a belated follow-up.
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue14
Guido van Rossum added the comment:
Victor:
> I expect even more interesting speedup with bytes string longer than 6k
> bytes. And I'm quite sure that it's common that people manipulates long
> strings in Python :-)
But do they use them as dict keys? AFAIK strings aren&
Guido van Rossum added the comment:
Worth revisiting?
--
___
Python tracker
<https://bugs.python.org/issue29410>
___
___
Python-bugs-list mailing list
Unsub
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue29410>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
It was a comment about my general lack of understanding of how the importlib
bootstrap process works. I should probably start reading the docstrings before
complaining more. :-)
--
___
Python tracker
<ht
Guido van Rossum added the comment:
I'm trying to understand the proposed solution, "have _imp.is_frozen() check
the module in sys.modules." Does that mean it would do a dict lookup first?
Maybe you should do that in the caller instead? importlib/_bootstrap.py calls
it a few
Guido van Rossum added the comment:
Do you think the API you're looking for is available at the C level? Like
PyErr_SetExcInfo()?
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
Whoa. os.path is not always an alias for posixpath, is it?
--
___
Python tracker
<https://bugs.python.org/issue45
Guido van Rossum added the comment:
> I'm surprised no one else noticed this until now.
Most people probably just use Google and read whatever comes up. I was looking
whether the official docs for map mentioned that map is actually an iterator
class. (Th
New submission from Guido van Rossum :
I was looking for the docs for 'map' and tried to use the search box on
docs.python.org. This gave a lot of things whose name started with or contained
'map', but the entry for the builtin map() function was hidden really far dow
Guido van Rossum added the comment:
I'm not against additional tutorial for typing. But the standard library manual
is supposed to be a complete reference. There is enough variation between
different generic types (e.g. are the parameters covariant?) that ought to be
documented. I
Guido van Rossum added the comment:
> Where are capabilities like "list[str]" and "dict[str, list[int]]" going to
> be documented?
I think those should go with the individual types as well. AFter all, it's
specific to the type how many parameters it has an
Guido van Rossum added the comment:
I think we should go ahead and duplicate the documentation in collections.abc
(and in a few other places -- PEP 585 lists some builtins, some in contextlib,
some in re). Then we won't have to worry about what happens when the typing
module is slimmed
Guido van Rossum added the comment:
Serhiy:
> I propose an opposite change -- take data known at compile time (name,
> qualname and annotations).
I'm confused by your phrase "take data" -- do you mean remove these? Or wht do
you propose we do with them?
> It will ma
Guido van Rossum added the comment:
And it's most definitely 3.11, not 3.9. (Did you mean to change a different
issue?)
--
versions: +Python 3.11 -Python 3.9
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
@santhu_reddy12, why did you assign this to the Parser category? IMO this issue
is clearly in the Build category. (We haven't met, I assume you have triage
permissions?)
--
___
Python tracker
&
Guido van Rossum added the comment:
Not so fast.
I'm not in favor of (c) co_doc either any more (for the reasons you state). I
would go for (b), a CO_DOCSTRING flag plus co_consts[0]. I expect that
co_consts sharing to be a very minor benefit, but you could easily count this
with an
Guido van Rossum added the comment:
Shouldn't we just close the issue and the unused PR? Otherwise we'll just have
yet another vague bpo issue that doesn't have anything particularly actionable
-- "there's some code that could be refactored" is not enough of
Guido van Rossum added the comment:
The plan is to add __file__ back, based on where the stdlib lives (we won’t do
any stat() calls for frozen files).
--
___
Python tracker
<https://bugs.python.org/issue45
Guido van Rossum added the comment:
Hm. IMO it is up to static type checkers to reject bad use of types. The
runtime should be relaxed so type checkers can develop new features assigning
new semantics to such constructs.
--
nosy: +gvanrossum
Guido van Rossum added the comment:
Ah, I think the docs need to be clarified a bit. Here's what I was missing:
The key thing to know here is that there are *three* state variables;
`c_tracefunc`, `c_profilefunc` (on the thread state), and `use_tracing` (on the
C frame).
Nor
Guido van Rossum added the comment:
I'm still torn about the need for a __file__ attribute. Assuming it's more
likely that people write code that *reads* stdlib source for some reason (maybe
printing more context for error messages) than *writing* it (which would be
truly str
Guido van Rossum added the comment:
May the best PR win. :-)
--
___
Python tracker
<https://bugs.python.org/issue45026>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
I wonder if part of the problem here isn't that protocols are primarily focused
on instances, where the __init__ method is explicitly *not* considered part of
the type.
IIRC supporting protocols for classes was an afterthought.
That said you have m
Guido van Rossum added the comment:
Sounds good, you have my blessing.
--
___
Python tracker
<https://bugs.python.org/issue24076>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
The patch looks fine, but it looks a bit like benchmark chasing. Is the speed
of builtin sum() of a sequence of integers important enough to do this bit of
inlining? (It may break if we change the internals of Py_Long, as Mark Shannon
has been wanting to
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue45116>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue43760>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue45026>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue24165>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
(Never mind, that should have gone to https://bugs.python.org/issue24165, which
is the integer freelist -- conclusion there in 2015 was also that it didn't do
much.)
--
___
Python tracker
&
Guido van Rossum added the comment:
Should we try the free list for integers again?
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue24
Guido van Rossum added the comment:
@Stefan
> FWIW, a PGO build of Py3.7 is now about 20% *faster* here than my Ubuntu
> 16/04 system Python 2.7
Does that mean we can close this issue? Or do I misunderstand what you are
comparing? 32 vs. 64 bits? PGO vs. non-PGO?
OTOH on my Mac I
Guido van Rossum added the comment:
> It would be nice to freeze argparse.py and its dependencies. For
> command-line tools, startup time is important.
I quickly checked, and argparse has at least these dependencies:
argparse
re
enum
types
operator
functools
collections
keyword
r
Guido van Rossum added the comment:
BTW, why does the script still run Programs/_freeze_module over all the modules
to be frozen? Isn't that up to the Makefile or its Windows equivalent?
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
(Ah, now I recall how the $(srcdir) mechanism works again. Generated files do
*not* have a $(srcdir) prefix, since they are generated in the destination
directory. Hence the fix for the buildbot failure a few days ago. I take back
my skepticism about that
Guido van Rossum added the comment:
FWIW, Python/frozen_modules/__hello__.h is still in the repo somehow.
--
___
Python tracker
<https://bugs.python.org/issue45
Guido van Rossum added the comment:
We can once GH-28375 lands.
--
___
Python tracker
<https://bugs.python.org/issue45188>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
> Note that the filename information is already available in the
> code object's co_filename attribute.
Hm, in the latest (3.11) main that's not true -- co_filename is set to
something like "". And that's about right, since
Guido van Rossum added the comment:
I tried this:
- remove the generated .h files
- touched dictobject.c
- touched dictobject.h
After each step I tried to rebuild. Each case the compilation of frozen.c
failed and then the build stopped, so apparently the .h files weren't generated
Guido van Rossum added the comment:
I would move "default to "on" (except if actually running out of the source
tree)" to the "maybe" category. I left a few comments in other deps. I think we
should start by turning this on by default in PGO builds.
Separate
Guido van Rossum added the comment:
I would propose that marshal internally make an extra pass over its input in
order to determine which objects are referenced multiple times. This will speed
up reading marshalled data (in addition to addressing the reproducibility issue
with debug builds
Guido van Rossum added the comment:
Is this now done? I.e. can we now drop the frozen .h files from the repo?
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue45
Guido van Rossum added the comment:
Honestly I find it debatable whether we're doing anyone a favor by publishing
the __file__ of the corresponding stdlib file for frozen modules. There will be
situations where this points to the wrong file, and editing the file will not
have an e
Change by Guido van Rossum :
--
resolution: -> wont fix
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
If you reduce the number of modules being frozen you could probably manage
to land this (or most of it) before tackling those other issues.
--
___
Python tracker
<https://bugs.python.org/issue45
Guido van Rossum added the comment:
I think that module is probably a relic from the Python 1 days…
--
___
Python tracker
<https://bugs.python.org/issue45
Guido van Rossum added the comment:
We're not (yet) trying to optimize the code being executed (we should perhaps
add an issue about class creation to https://github.com/faster-cpython/ideas).
I agree that marshal is very fast already; I doubt the extra cost of wordcode
would pay off
Guido van Rossum added the comment:
Raymond, I am super grateful that you are showing us the assembly language.
That's the kind of thing we need to do more of if we want to be successful. (In
this case I'm not surprised by the outcome, but I have never studied x86
assembly and
Guido van Rossum added the comment:
Da-woods, can you take care of that?
--
___
Python tracker
<https://bugs.python.org/issue45122>
___
___
Python-bugs-list m
Guido van Rossum added the comment:
Serhiy’s comment from 2014-01-04 gives the answer. It’s different reading from
a file than from a string. And only “python x.py” still reads from a file.
--
___
Python tracker
<https://bugs.python.org/issue20
Guido van Rossum added the comment:
Which part puzzles you?
I see that you tried
>>> #\0
This does not contain a null byte, just three characters: a hash, a backslash,
and a digit zero.
--
___
Python tracker
<https://bugs.python.or
Guido van Rossum added the comment:
That sounds like a good plan (note that alpha 1 will go out around Oct 4).
I left an issue for Cython: https://github.com/cython/cython/issues/4365
--
___
Python tracker
<https://bugs.python.org/issue45
Guido van Rossum added the comment:
PS. It would be nice to also update Cython, which is the only thing that uses
these C APIs.
--
___
Python tracker
<https://bugs.python.org/issue45
New submission from Guido van Rossum :
This is up for grabs.
For reference, the Steering Council approved getting rid of these two C APIs
without honoring the customary two-release deprecation period required by PEP
387.
For reference see https://github.com/python/steering-council/issues/75
Guido van Rossum added the comment:
Since this primarily affects static type checkers such as mypy, Pyre and
pyright, it’s best to discuss it on typing-sig.
--
___
Python tracker
<https://bugs.python.org/issue44
Guido van Rossum added the comment:
Updating an existing (standards track) PEP significantly is not
traditional. I recommend writing a new PEP.
On Sun, Sep 5, 2021 at 01:24 Ken Jin wrote:
>
> Ken Jin added the comment:
>
> Guido, OP has kindly written a mini PEP for this. Do yo
Guido van Rossum added the comment:
Let's wait until Mark Shannon is back from vacation (another week).
Note that class docstrings *are* contained in the class body code object --
there's executable code equivalent to
__doc__ = "this is the docstring"
But I agree i
Guido van Rossum added the comment:
Since we're not changing the magic number, wheels created for rc1 will still
work with the final 3.10 (and vice versa!) -- creating a wheel or PYC file just
will produce a different sequence of bytes, but there are other things that do
that.
Then
Guido van Rossum added the comment:
Are you sure? I know we're really close to the release, but I'd much rather
change the PYC format during the RC cycle than once we're doing bugfix
releases. I don't think we've ever changed the magic number between bugfix
releases
Guido van Rossum added the comment:
I am still not convinced that it's a good idea to put the docstring in the
surrounding code object. I'd like to be able to see it when I introspect a code
object, not just when introspecting a function object (I may be analyzing code
only, and
Guido van Rossum added the comment:
Maybe issue45024 is also connected? (It also seems to relate to hasattr()
logic.)
--
___
Python tracker
<https://bugs.python.org/issue23
Guido van Rossum added the comment:
We can add to the 3.10 docs that it is deprecated without any code change. And
in 3.11 we can add a warning.
--
___
Python tracker
<https://bugs.python.org/issue40
Guido van Rossum added the comment:
How come the deprecation didn't happen in 3.10? Were people just not
interested?
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
All legit cases, I agree, but are they worth the considerable work?
--
___
Python tracker
<https://bugs.python.org/issue44
Guido van Rossum added the comment:
This sounds like a project requiring a considerable amount of plumbing to get
the info from where it's available to where it's needed. For example, importlib
reads the PYC file, checks the header, and then passes the rest of the file to
mar
Guido van Rossum added the comment:
You're right, I'm being inconsistent. :-( I withdraw my objection.
There are cases where sys.exit() is easier than returning an exit code, e.g.
when the error is discovered deep inside some other code. But it's probably
better to ra
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue21736>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
I've seen it a few times. I don't do this that often, but since I've discovered
"git worktree" this has occurred to me a few times (can't recall if it was
every time, but today wasn't the first). I'm totally
Guido van Rossum added the comment:
I wonder what the 3.10 compiler does different to cause this -- in 3.9 that
extra None is not in co_consts.
(Note: Mark is on vacation for 2 weeks.)
--
nosy: +Mark.Shannon, gvanrossum
___
Python tracker
<ht
New submission from Guido van Rossum :
When I make a fresh checkout of the main branch on Windows and type
"pcbuild\build" it starts downloading some distributions (e.g. sqlite) and then
starts building. Fine. But at some point there's a whole bunch of errors that
seem to com
Guido van Rossum added the comment:
Is this ready to close?
--
___
Python tracker
<https://bugs.python.org/issue45019>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Thanks, the rewrite is great!
I have one nit: did you consider which of these two idioms is better?
if __name__ == "__main__":
main()
vs.
if __name__ == "__main__":
sys.exit(main())
Your docs seem to promote the second,
Guido van Rossum added the comment:
Thanks! This comes right in time, because we're working on freezing many more
modules, and modules containing frozen sets didn't have a consistent frozen
representation. Now they do!
(See issue45019, issue45020)
--
nosy: +
Guido van Rossum added the comment:
I think we shouldn't change *which* code object contains the docstring
(changing anything about that is likely to disturb someone's workflow in a way
that's hard to fix) -- only how PyFunction_New finds that docstring in the code
object
Guido van Rossum added the comment:
FWIW, I'd be okay with doing the -X flag in a separate PR.
--
___
Python tracker
<https://bugs.python.org/is
Guido van Rossum added the comment:
> At this point, here are the open questions I'm seeing:
> + The editing-stdlib-.py-files problem: [...]
> + Compatibility: [...]
? + Penalty for too many frozen modules: [...]
> FWIW, I think the ideal mechanism for a dev build wil
Guido van Rossum added the comment:
[Gregory Szorc]
> What do you set __file__ to? [...]
Exactly. I think it should not be set, just like it's not set for builtin
modules.
> I have some observations about the implications of this. I typed up a long
> comment but then re
Guido van Rossum added the comment:
> FWIW, I asked Ned Batchelder about this and he said this approach
> ("fullcoverage" [1]) was added to support running coverage on the stdlib.
> [...]
The docs you pointed out in [3] (where it talks about a *horrible hack yo
Guido van Rossum added the comment:
Why all the hating on docstrings? What have docstrings done wrong? I know
there's the -OO flag that strips docstrings, but it doesn't work well and I
think it was a mistake.
--
___
Python track
Guido van Rossum added the comment:
Gregor, thanks for sharing your experience!
I guess freezing the entire stdlib instead of just a smattering of modules
(like we do here) exacerbated the problems in your case.
Builtin modules (such as sys or time) don't have a __file__ attribute e
Guido van Rossum added the comment:
> I'd like to remove docstring from code object at all.
> func.__doc__ can be set by MAKE_FUNCTION or STORE_ATTR.
You'd just be moving the problem though -- the docstring would have be included
in the co_consts array of the surrounding cod
Guido van Rossum added the comment:
> Since nobody's said so in so many words (so far in this thread anyway): the
> prototype from Jeethu Rao in 2018 was a different technology than what Eric
> is doing. The "Programs/_freeze_importlib.c" Eric's playing with
Guido van Rossum added the comment:
Adding Larry in case he remembers more color. (Larry: the key question here is
whether some version of this (like the one I've been working on, or a simpler
one that Eric has prepared) is viable, given that any time someone works on one
of the froz
Guido van Rossum added the comment:
The plot thickens. By searching my extensive GMail archives for Jeethu Rao I
found an email from Sept. 14 to python-dev by Larry Hastings titled "Store
startup modules as C structures for 20%+ startup speed improvement?"
It references an issu
Guido van Rossum added the comment:
We should ask Neil S. for the issue where Larry introduced this. That might
have some discussion.
But if I had to guess, it’s confusing that you can see *Python* source that
you can’t edit (or rather, where editing doesn’t get reflected in the next
Python
Guido van Rossum added the comment:
> The big time consumer is turning marshal'ed code objects back
> into Python objects, though. If that could be made faster by
> e.g. using a more efficient storage format such as one which is
> platform dependent, it'd be a much bigger
Guido van Rossum added the comment:
I noticed nedbat un-nosied himself. Probably he didn't realize you were
calling him out because it's possible this would affect coverage.py?
--
___
Python tracker
<https://bugs.python.o
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue45017>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
So let’s add that in a separate PR.
--
--Guido (mobile)
--
___
Python tracker
<https://bugs.python.org/issue24234>
___
___
Guido van Rossum added the comment:
What about __bytes__?
--
___
Python tracker
<https://bugs.python.org/issue24234>
___
___
Python-bugs-list mailing list
Unsub
Guido van Rossum added the comment:
Unfortunately you can’t use Python keywords in such positions and we have no
plans to fix this. Serhiy’s workaround is the best you can do.
--
resolution: -> wont fix
stage: -> resolved
status: open -&g
Guido van Rossum added the comment:
New changeset 16b9be4861e007ad483611ba0479feb2b90ea783 by Maximilian Hils in
branch 'main':
bpo-44926: `get_type_hints`: Add note about type aliases with forward refs
(#27859)
https://github.com/python/cpyt
Guido van Rossum added the comment:
Thanks to both of you!!
--
___
Python tracker
<https://bugs.python.org/issue44957>
___
___
Python-bugs-list mailin
Guido van Rossum added the comment:
Ken, this sounds like a good idea. Can you help?
--
nosy: +gvanrossum, kj
___
Python tracker
<https://bugs.python.org/issue44
Change by Guido van Rossum :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue44921>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
We could mention this in the docs for one or more of the following:
- type aliases (old or new syntax)
- forward references
- get_type_hints()
Ken Jin, can you guide Maximilian towards a successful doc update PR
401 - 500 of 5533 matches
Mail list logo