On Wed, Oct 4, 2017, 09:00 Antoine Pitrou, wrote:
> On Wed, 4 Oct 2017 10:14:22 -0400
> Barry Warsaw wrote:
> > On Oct 3, 2017, at 13:29, Benjamin Peterson wrote:
> >
> > > I'm not sure turning the implementation details of our internal formats
> > > into APIs is the way to go.
> >
> > I still
On 5 October 2017 at 23:44, Barry Warsaw wrote:
> On Oct 4, 2017, at 13:53, Benjamin Peterson wrote:
>
> > It might be helpful to enumerate the usecases for such an API. Perhaps a
> > narrow, specialized API could satisfy most needs in a supportable way.
>
> Currently `python -m dis thing.py` co
Honestly I think the API for accessing historic pyc headers should itself
also be 3rd party. CPython itself should not bother (backwards
compatibility with pyc files has never been a feature).
On Thu, Oct 5, 2017 at 6:44 AM, Barry Warsaw wrote:
> On Oct 4, 2017, at 13:53, Benjamin Peterson wrot
On Oct 4, 2017, at 13:53, Benjamin Peterson wrote:
> It might be helpful to enumerate the usecases for such an API. Perhaps a
> narrow, specialized API could satisfy most needs in a supportable way.
Currently `python -m dis thing.py` compiles the source then disassembles it.
It would be kind o
On Wed, Oct 4, 2017, at 07:14, Barry Warsaw wrote:
> On Oct 3, 2017, at 13:29, Benjamin Peterson wrote:
>
> > I'm not sure turning the implementation details of our internal formats
> > into APIs is the way to go.
>
> I still think an API in the stdlib would be useful and appropriate, but
> it
On Wed, 4 Oct 2017 10:14:22 -0400
Barry Warsaw wrote:
> On Oct 3, 2017, at 13:29, Benjamin Peterson wrote:
>
> > I'm not sure turning the implementation details of our internal formats
> > into APIs is the way to go.
>
> I still think an API in the stdlib would be useful and appropriate, but
On Oct 3, 2017 9:55 AM, "Serhiy Storchaka" wrote:
While PEP 552 is accepted, I would want to see some changes.
1. Increase the size of the constant part of the signature to at least 32
bits. Currently only the third and forth bytes are constant, and they are
'\r\n', that is often occurred in tex
On Oct 3, 2017, at 13:29, Benjamin Peterson wrote:
> I'm not sure turning the implementation details of our internal formats
> into APIs is the way to go.
I still think an API in the stdlib would be useful and appropriate, but it’s
not like this couldn’t be done as a 3rd party module.
-Barry
On Tue, Oct 3, 2017, at 08:03, Barry Warsaw wrote:
> Guido van Rossum wrote:
> > There have been no further comments. PEP 552 is now accepted.
> >
> > Congrats, Benjamin! Go ahead and send your implementation for review.Oops.
> > Let me try that again.
>
> While I'm very glad PEP 552 has been a
26.09.17 23:47, Guido van Rossum пише:
I've read the current version of PEP 552 over and I think everything
looks good for acceptance. I believe there are no outstanding objections
(or they have been adequately addressed in responses).
Therefore I intend to accept PEP 552 this Friday, unless g
03.10.17 18:15, Guido van Rossum пише:
It's really not that hard. You just check the magic number and if it's
the new one, skip 4 words. No need to understand the internals of the
header.
Hence you should know all old magic numbers to determine if the read
magic number is the new one. Right?
I'm fine with adding an API, though I don't think that an API that knows
about all current (historic) and future formats belongs in importlib.util
-- that module only concerns itself with the *current* format.
In terms of the API design I'd make take an IO[bytes] and just read and
parse the header
On Tue, 3 Oct 2017 08:15:04 -0700
Guido van Rossum wrote:
> It's really not that hard. You just check the magic number and if it's the
> new one, skip 4 words. No need to understand the internals of the header.
Still, I agree with Barry that an API would be nice.
Regards
Antoine.
>
> On Oct 3
It's really not that hard. You just check the magic number and if it's the
new one, skip 4 words. No need to understand the internals of the header.
On Oct 3, 2017 08:06, "Barry Warsaw" wrote:
> Guido van Rossum wrote:
> > There have been no further comments. PEP 552 is now accepted.
> >
> > Con
Guido van Rossum wrote:
> There have been no further comments. PEP 552 is now accepted.
>
> Congrats, Benjamin! Go ahead and send your implementation for review.Oops.
> Let me try that again.
While I'm very glad PEP 552 has been accepted, it occurs to me that it
will now be more difficult to pars
On Sat, 30 Sep 2017 at 18:46 Benjamin Peterson wrote:
> What do you mean by bytecode-specific APIs? The internal importlib ones?
>
There's that, but more specifically py_compile and compileall.
-Brett
>
> On Fri, Sep 29, 2017, at 09:38, Brett Cannon wrote:
> > BTW, if you find the bytecode-sp
Please start a new thread on python-dev. It's unrelated to
"deterministic pyc files".
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pytho
On Mon, Oct 2, 2017 at 6:42 AM, Guido van Rossum wrote:
> On Sun, Oct 1, 2017 at 1:52 PM, Koos Zevenhoven wrote:
>
>> On Oct 1, 2017 19:26, "Guido van Rossum" wrote:
>>
>> Your PEP is currently incomplete. If you don't finish it, it is not even
>> a contender. But TBH it's not my favorite anywa
One more thing. I would really appreciate it if you properly wrapped lines
in your PEP around column 72 instead of using a single line per paragraph.
This is the standard convention, see the template in PEP 12.
On Sun, Oct 1, 2017 at 8:42 PM, Guido van Rossum wrote:
> On Sun, Oct 1, 2017 at 1:52
On Sun, Oct 1, 2017 at 1:52 PM, Koos Zevenhoven wrote:
> On Oct 1, 2017 19:26, "Guido van Rossum" wrote:
>
> Your PEP is currently incomplete. If you don't finish it, it is not even a
> contender. But TBH it's not my favorite anyway, so you could also just
> withdraw it.
>
>
> I can withdraw it
On Oct 1, 2017 19:26, "Guido van Rossum" wrote:
Your PEP is currently incomplete. If you don't finish it, it is not even a
contender. But TBH it's not my favorite anyway, so you could also just
withdraw it.
I can withdraw it if you ask me to, but I don't want to withdraw it without
any reason.
Your PEP is currently incomplete. If you don't finish it, it is not even a
contender. But TBH it's not my favorite anyway, so you could also just
withdraw it.
On Oct 1, 2017 9:13 AM, "Koos Zevenhoven" wrote:
> On Sep 29, 2017 18:21, "Guido van Rossum" wrote:
>
>
> PS. PEP 550 is still unaccepte
On Sep 29, 2017 18:21, "Guido van Rossum" wrote:
PS. PEP 550 is still unaccepted, awaiting a new revision from Yury and
Elvis.
This is getting really off-topic, but I do have updates to add to PEP 555
if there is interest in that. IMO, 555 is better and most likely faster
than 550, but on the
What do you mean by bytecode-specific APIs? The internal importlib ones?
On Fri, Sep 29, 2017, at 09:38, Brett Cannon wrote:
> BTW, if you find the bytecode-specific APIs are sub-par while trying to
> update them, let me know as I have been toying with cleaning them up and
> centralizing them unde
BTW, if you find the bytecode-specific APIs are sub-par while trying to
update them, let me know as I have been toying with cleaning them up and
centralizing them under importlib for a while and just never gotten around
to sitting down and coming up with a better design that warranted putting
the t
Thanks, Guido and everyone who submitted feedback!
I guess I know what I'll be doing this weekend.
On Fri, Sep 29, 2017, at 08:18, Guido van Rossum wrote:
> Let me try that again.
>
> There have been no further comments. PEP 552 is now accepted.
>
> Congrats, Benjamin! Go ahead and send your im
Let me try that again.
There have been no further comments. PEP 552 is now accepted.
Congrats, Benjamin! Go ahead and send your implementation for review.Oops.
Let me try that again.
PS. PEP 550 is still unaccepted, awaiting a new revision from Yury and
Elvis.
--
--Guido van Rossum (python.org
Hi all,
Do the accepted PEP were 552, not 550?
Thanks,
Louie.
2017-09-29 22:40 GMT+08:00 Guido van Rossum :
> It's Friday!
>
> There have been no further comments. PEP 550 is now accepted.
>
> Congrats, Benjamin! Go ahead and send your implementation for review.
>
> --Guido
>
> On Tue, Sep 26,
It's Friday!
There have been no further comments. PEP 550 is now accepted.
Congrats, Benjamin! Go ahead and send your implementation for review.
--Guido
On Tue, Sep 26, 2017 at 1:47 PM, Guido van Rossum wrote:
> I've read the current version of PEP 552 over and I think everything looks
> good
I've read the current version of PEP 552 over and I think everything looks
good for acceptance. I believe there are no outstanding objections (or they
have been adequately addressed in responses).
Therefore I intend to accept PEP 552 this Friday, unless grave objections
are raised on this mailing
30 matches
Mail list logo
