Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 26 September 2013 16:53, Georg Brandl wrote: >> Sure, that's doable, but it dumps the full repr of "obj" in the middle >> of the sentence. The thing that's not practical is the neat and tidy >> wording Georg proposed, because the thing passed as "obj" is actually >> an arbitrary Python object that may have a messy repr (like a bound >> method, which is what gets passed in the __del__ case), so there's >> definite merit in keeping that repr at the *end* of the header line. > > Then this should be fine, I guess? > > Exception caught and not propagated in: <> Sure. I still prefer something like "Could not propagate exception from:" or "Caller could not propagate exception from " that better indicates we're suppressing it because it's infeasible to raise it rather than just because we feel like it, but any of them would offer a decent improvement over the status quo. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] asdl.py and Python-ast.[hc]
Hi All, Earlier this morning I had a slight tackle with a couple of the 3.4 bots (sorry everyone!). I fixed some problems in asdl.py - http://hg.python.org/cpython/rev/21d46e3ae60c - and used the 'with' statement. Some bots don't have Python 2.6+ and couldn't bootstrap Python-ast.h/c Two questions: * Should I always check-in Python-ast.h and Python-ast.c when I touch asdl* ? The generated files are unchanged, it's only the timestamp that changed. * Can we, in theory, use new Pythons for asdl* code, because Python-ast.* are, in fact, checked in so they don't have to be rebuilt by the bots or users? Thanks in advance, Eli ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?
On Wed, Sep 25, 2013 at 7:15 PM, Donald Stufft wrote: > > On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote: > > > Another reason to oppose this is what I've heard quite often from people > > regarding Python 2.7. I've been told that many folks are actually really > > happy with using 2.7 precisely because it extremely stable. They don't > have > > to worry about their stuff breaking or incompatibilities cropping up, > because > > it *doesn't* change. Python 2.7 is like a long-term maintenance > release, with > > guaranteed multi-year stability, and I think while that was unintended, > it's a > > *good* thing. This PEP proposes to break that, and I'm loathe to give > up that > > good reputation for this particular feature. > > Maybe I'm just naive but can you expand on how adding a module that nothing > else in the system imports (besides the installers; but you weren't > arguing against > adding this to the installers) would break someones use any other module? > If > they don't import it (which the vast bulk of people won't directly, nor at > all during > the operation of their applications) how does it's existence on the file > system > risk a breakage to their system? I think Barry's worry is precisely the fact that users do silly things, so having a new module suddenly show up in the stdlib can be a problem if people start using the module. We could conceivably try and not expose the module on sys.path somehow so that it can't be directly imported by anyone who doesn't have any business using it unless they jump through some hoops (e.g. stick it in Tools for Python 2.7 so the installers can get access but it won't end up in the stdlib install). Otherwise if Barry is worrying about a command-line tool being installed for some users of Python 2.7 vs. not then I don't know what the worry is because that happens on OS upgrades as well, let alone people who just happen to have done the install themselves vs. not. People are already told to install pip anyway, so if instructions point to ensurepip on PyPI as the canonical way to install pip then whether it's installed or not is fine as it will be mostly a no-op for 2.7.6 users and an actual install for others. But by including it then it does simplify teaching scenarios and long tail helps get pip out faster and more easily. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?
Le Thu, 26 Sep 2013 14:54:49 +1000, Nick Coghlan a écrit : > On 26 September 2013 14:30, Nick Coghlan wrote: > > That said, there are changes that I think are definitely worth > > making due to the concerns you raise: > > > > - the module name should be "_ensurepip" in all versions > > - the PEP should explicitly state that the "don't remove _ensurepip > > and it's wheel files" caveat for redistributors applies only in 3.4+ > > (where removing it will break pyvenv) > > Donald pointed out it makes more sense to continue with the idea of a > properly documented public "ensurepip" module in 3.4+, and have the > "_ensurepip" version as an implementation detail of the 2.7 and 3.3 > installers that is included in the stdlib primarily so it can be > covered by the existing buildbot fleet. Hmm, but what is the point of "_ensurepip" exactly? Are people supposed to type "python -m _ensurepip"? With all due respect, Barry's argument looks rather paranoid to me. I would suggest a clear choice: - either having "ensurepip" in 2.7 is useful and we endorse it as a public module (not something hidden somewhere) - which I personally think is reasonable - or it's not useful and we don't introduce it at all A middleground doesn't make sense here, except in a broken "design by committee" sense. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] asdl.py and Python-ast.[hc]
On Thu, Sep 26, 2013 at 9:52 AM, Eli Bendersky wrote: > Hi All, > > Earlier this morning I had a slight tackle with a couple of the 3.4 bots > (sorry everyone!). I fixed some problems in asdl.py - > http://hg.python.org/cpython/rev/21d46e3ae60c - and used the 'with' > statement. Some bots don't have Python 2.6+ and couldn't bootstrap > Python-ast.h/c > > Two questions: > > * Should I always check-in Python-ast.h and Python-ast.c when I touch > asdl* ? The generated files are unchanged, it's only the timestamp that > changed. > If Python-ast.* are checked in then yes. > * Can we, in theory, use new Pythons for asdl* code, because Python-ast.* > are, in fact, checked in so they don't have to be rebuilt by the bots or > users? > I don't see why not. the touch extension for hg is there specifically for these files to prevent having to regenerate them. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?
Ideally people won't be typing either of them because it'll be installed automatically. They might in some cases (accidentally uninstalled pip?) I agree that it seems there is paranoia going on here and that the risk is low and making it just be a special cased new feature is ok. However the point of the underscore prefix on 2.7 and 3.3 is to more effectively communicate that on these pythons you shouldn't rely on that module existing. I think that's worse situation then just making it ensurepip everywhere but better than 2.7 not getting it at all or Barry's suggestion. > On Sep 26, 2013, at 10:10 AM, Antoine Pitrou wrote: > > Le Thu, 26 Sep 2013 14:54:49 +1000, > Nick Coghlan a écrit : >> On 26 September 2013 14:30, Nick Coghlan wrote: >>> That said, there are changes that I think are definitely worth >>> making due to the concerns you raise: >>> >>> - the module name should be "_ensurepip" in all versions >>> - the PEP should explicitly state that the "don't remove _ensurepip >>> and it's wheel files" caveat for redistributors applies only in 3.4+ >>> (where removing it will break pyvenv) >> >> Donald pointed out it makes more sense to continue with the idea of a >> properly documented public "ensurepip" module in 3.4+, and have the >> "_ensurepip" version as an implementation detail of the 2.7 and 3.3 >> installers that is included in the stdlib primarily so it can be >> covered by the existing buildbot fleet. > > Hmm, but what is the point of "_ensurepip" exactly? Are people supposed > to type "python -m _ensurepip"? > > With all due respect, Barry's argument looks rather paranoid to me. > I would suggest a clear choice: > - either having "ensurepip" in 2.7 is useful and we endorse it as a > public module (not something hidden somewhere) - which I personally > think is reasonable > - or it's not useful and we don't introduce it at all > > A middleground doesn't make sense here, except in a broken "design by > committee" sense. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] asdl.py and Python-ast.[hc]
On Thu, Sep 26, 2013 at 7:18 AM, Brett Cannon wrote: > > > > On Thu, Sep 26, 2013 at 9:52 AM, Eli Bendersky wrote: > >> Hi All, >> >> Earlier this morning I had a slight tackle with a couple of the 3.4 bots >> (sorry everyone!). I fixed some problems in asdl.py - >> http://hg.python.org/cpython/rev/21d46e3ae60c - and used the 'with' >> statement. Some bots don't have Python 2.6+ and couldn't bootstrap >> Python-ast.h/c >> >> Two questions: >> >> * Should I always check-in Python-ast.h and Python-ast.c when I touch >> asdl* ? The generated files are unchanged, it's only the timestamp that >> changed. >> > > If Python-ast.* are checked in then yes. > Hmm, how do I do that? hg doesn't accept them for commit since their contents are not changed. > > >> * Can we, in theory, use new Pythons for asdl* code, because Python-ast.* >> are, in fact, checked in so they don't have to be rebuilt by the bots or >> users? >> > > I don't see why not. the touch extension for hg is there specifically for > these files to prevent having to regenerate them. > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] asdl.py and Python-ast.[hc]
2013/9/26 Eli Bendersky : > Hi All, > > Earlier this morning I had a slight tackle with a couple of the 3.4 bots > (sorry everyone!). I fixed some problems in asdl.py - > http://hg.python.org/cpython/rev/21d46e3ae60c - and used the 'with' > statement. Some bots don't have Python 2.6+ and couldn't bootstrap > Python-ast.h/c > > Two questions: > > * Should I always check-in Python-ast.h and Python-ast.c when I touch asdl* > ? The generated files are unchanged, it's only the timestamp that changed. > * Can we, in theory, use new Pythons for asdl* code, because Python-ast.* > are, in fact, checked in so they don't have to be rebuilt by the bots or > users? We should have the buildbots run "make touch", so they don't need to run asdl_c.py. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?
Le Thu, 26 Sep 2013 10:22:55 -0400, Donald Stufft a écrit : > Ideally people won't be typing either of them because it'll be > installed automatically. They might in some cases (accidentally > uninstalled pip?) Installing from source perhaps. > I agree that it seems there is paranoia going on here and that the > risk is low and making it just be a special cased new feature is ok. > However the point of the underscore prefix on 2.7 and 3.3 is to more > effectively communicate that on these pythons you shouldn't rely on > that module existing. That's a fair argument, although it also makes the thing a bit ugly. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Don't use fancy new Python features like 'with' - some bots don't have them
Am 26.09.2013 15:42, schrieb eli.bendersky: > http://hg.python.org/cpython/rev/931d95e9067f > changeset: 85801:931d95e9067f > user:Eli Bendersky > date:Thu Sep 26 06:41:36 2013 -0700 > summary: > Don't use fancy new Python features like 'with' - some bots don't have them > and can't bootstrap the parser. > > files: > Parser/asdl.py | 5 - > 1 files changed, 4 insertions(+), 1 deletions(-) > > > diff --git a/Parser/asdl.py b/Parser/asdl.py > --- a/Parser/asdl.py > +++ b/Parser/asdl.py > @@ -398,8 +398,11 @@ > scanner = ASDLScanner() > parser = ASDLParser() > > -with open(file) as f: > +try: > +f = open(file) > buf = f.read() > +finally: > +f.close() > tokens = scanner.tokenize(buf) > try: > return parser.parse(tokens) The open call needs to go outside the try-finally. cheers, Georg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Don't use fancy new Python features like 'with' - some bots don't have them
On Thu, Sep 26, 2013 at 9:07 AM, Georg Brandl wrote: > Am 26.09.2013 15:42, schrieb eli.bendersky: > > http://hg.python.org/cpython/rev/931d95e9067f > > changeset: 85801:931d95e9067f > > user:Eli Bendersky > > date:Thu Sep 26 06:41:36 2013 -0700 > > summary: > > Don't use fancy new Python features like 'with' - some bots don't have > them > > and can't bootstrap the parser. > > > > files: > > Parser/asdl.py | 5 - > > 1 files changed, 4 insertions(+), 1 deletions(-) > > > > > > diff --git a/Parser/asdl.py b/Parser/asdl.py > > --- a/Parser/asdl.py > > +++ b/Parser/asdl.py > > @@ -398,8 +398,11 @@ > > scanner = ASDLScanner() > > parser = ASDLParser() > > > > -with open(file) as f: > > +try: > > +f = open(file) > > buf = f.read() > > +finally: > > +f.close() > > tokens = scanner.tokenize(buf) > > try: > > return parser.parse(tokens) > > The open call needs to go outside the try-finally.\ > Done, thanks. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] asdl.py and Python-ast.[hc]
On Thu, Sep 26, 2013 at 7:28 AM, Benjamin Peterson wrote: > 2013/9/26 Eli Bendersky : > > Hi All, > > > > Earlier this morning I had a slight tackle with a couple of the 3.4 bots > > (sorry everyone!). I fixed some problems in asdl.py - > > http://hg.python.org/cpython/rev/21d46e3ae60c - and used the 'with' > > statement. Some bots don't have Python 2.6+ and couldn't bootstrap > > Python-ast.h/c > > > > Two questions: > > > > * Should I always check-in Python-ast.h and Python-ast.c when I touch > asdl* > > ? The generated files are unchanged, it's only the timestamp that > changed. > > * Can we, in theory, use new Pythons for asdl* code, because Python-ast.* > > are, in fact, checked in so they don't have to be rebuilt by the bots or > > users? > > We should have the buildbots run "make touch", so they don't need to > run asdl_c.py. > How should we go about doing this? I don't think we have it documented in the devguide how to tweak the buildbot scripts? Eli ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?
On Sep 26, 2013, at 10:28 AM, Antoine Pitrou wrote: > Le Thu, 26 Sep 2013 10:22:55 -0400, > Donald Stufft a écrit : >> Ideally people won't be typing either of them because it'll be >> installed automatically. They might in some cases (accidentally >> uninstalled pip?) > > Installing from source perhaps. Ah yea, installing from source is the time when they'd execute it, that slipped my mind. > >> I agree that it seems there is paranoia going on here and that the >> risk is low and making it just be a special cased new feature is ok. >> However the point of the underscore prefix on 2.7 and 3.3 is to more >> effectively communicate that on these pythons you shouldn't rely on >> that module existing. > > That's a fair argument, although it also makes the thing a bit ugly. Yea It's not my preferred thing to do and I think that calling it just ensurepip is fine, however I think if folks are worried about it, it could offer a compromise. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] asdl.py and Python-ast.[hc]
2013/9/26 Eli Bendersky : > > > > On Thu, Sep 26, 2013 at 7:28 AM, Benjamin Peterson > wrote: >> >> 2013/9/26 Eli Bendersky : >> > Hi All, >> > >> > Earlier this morning I had a slight tackle with a couple of the 3.4 bots >> > (sorry everyone!). I fixed some problems in asdl.py - >> > http://hg.python.org/cpython/rev/21d46e3ae60c - and used the 'with' >> > statement. Some bots don't have Python 2.6+ and couldn't bootstrap >> > Python-ast.h/c >> > >> > Two questions: >> > >> > * Should I always check-in Python-ast.h and Python-ast.c when I touch >> > asdl* >> > ? The generated files are unchanged, it's only the timestamp that >> > changed. >> > * Can we, in theory, use new Pythons for asdl* code, because >> > Python-ast.* >> > are, in fact, checked in so they don't have to be rebuilt by the bots or >> > users? >> >> We should have the buildbots run "make touch", so they don't need to >> run asdl_c.py. > > > How should we go about doing this? Complain to Antoine I suppose. :) -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] asdl.py and Python-ast.[hc]
> >> 2013/9/26 Eli Bendersky : > >> > Hi All, > >> > > >> > Earlier this morning I had a slight tackle with a couple of the 3.4 > bots > >> > (sorry everyone!). I fixed some problems in asdl.py - > >> > http://hg.python.org/cpython/rev/21d46e3ae60c - and used the 'with' > >> > statement. Some bots don't have Python 2.6+ and couldn't bootstrap > >> > Python-ast.h/c > >> > > >> > Two questions: > >> > > >> > * Should I always check-in Python-ast.h and Python-ast.c when I touch > >> > asdl* > >> > ? The generated files are unchanged, it's only the timestamp that > >> > changed. > >> > * Can we, in theory, use new Pythons for asdl* code, because > >> > Python-ast.* > >> > are, in fact, checked in so they don't have to be rebuilt by the bots > or > >> > users? > >> > >> We should have the buildbots run "make touch", so they don't need to > >> run asdl_c.py. > > > > > > How should we go about doing this? > > Complain to Antoine I suppose. :) > [+ Antoine] Done :) While we're at it, it seems that .hgtouch is wrong: Include/ast.h: Parser/Python.asdl Parser/asdl.py Parser/asdl_c.py Python/Python-ast.c: Include/ast.h The file Include/ast.h is not, in fact, auto-generated. But Include/Python-ast.h *is*, and it does not appear in this file. Typo? [+Ezio] Eli ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message
On 9/26/2013 3:17 AM, Nick Coghlan wrote: On 26 September 2013 16:53, Georg Brandl wrote: Sure, that's doable, but it dumps the full repr of "obj" in the middle of the sentence. The thing that's not practical is the neat and tidy wording Georg proposed, because the thing passed as "obj" is actually an arbitrary Python object that may have a messy repr (like a bound method, which is what gets passed in the __del__ case), so there's definite merit in keeping that repr at the *end* of the header line. Then this should be fine, I guess? Exception caught and not propagated in: <> Sure. I still prefer something like "Could not propagate exception from:" or "Caller could not propagate exception from " that better indicates we're suppressing it because it's infeasible to raise it rather than just because we feel like it, but any of them would offer a decent improvement over the status quo. With the full traceback printed, with the line where the exception originated, I do not think that the representation of the object is needed. It was a substitute for the traceback. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] asdl.py and Python-ast.[hc]
On Thu, 26 Sep 2013 11:46:07 -0700 Eli Bendersky wrote: > > >> 2013/9/26 Eli Bendersky : > > >> > Hi All, > > >> > > > >> > Earlier this morning I had a slight tackle with a couple of the 3.4 > > bots > > >> > (sorry everyone!). I fixed some problems in asdl.py - > > >> > http://hg.python.org/cpython/rev/21d46e3ae60c - and used the 'with' > > >> > statement. Some bots don't have Python 2.6+ and couldn't bootstrap > > >> > Python-ast.h/c > > >> > > > >> > Two questions: > > >> > > > >> > * Should I always check-in Python-ast.h and Python-ast.c when I touch > > >> > asdl* > > >> > ? The generated files are unchanged, it's only the timestamp that > > >> > changed. > > >> > * Can we, in theory, use new Pythons for asdl* code, because > > >> > Python-ast.* > > >> > are, in fact, checked in so they don't have to be rebuilt by the bots > > or > > >> > users? > > >> > > >> We should have the buildbots run "make touch", so they don't need to > > >> run asdl_c.py. > > > > > > > > > How should we go about doing this? > > > > Complain to Antoine I suppose. :) > > > [+ Antoine] > Done :) "make touch"? Wow, I'm learning new stuff everyday :-) (what point is there in adding things to Makefile if nobody knows about them?) cheers Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] asdl.py and Python-ast.[hc]
On Thu, Sep 26, 2013 at 1:45 PM, Antoine Pitrou wrote: > On Thu, 26 Sep 2013 11:46:07 -0700 > Eli Bendersky wrote: > > > > >> 2013/9/26 Eli Bendersky : > > > >> > Hi All, > > > >> > > > > >> > Earlier this morning I had a slight tackle with a couple of the > 3.4 > > > bots > > > >> > (sorry everyone!). I fixed some problems in asdl.py - > > > >> > http://hg.python.org/cpython/rev/21d46e3ae60c - and used the > 'with' > > > >> > statement. Some bots don't have Python 2.6+ and couldn't bootstrap > > > >> > Python-ast.h/c > > > >> > > > > >> > Two questions: > > > >> > > > > >> > * Should I always check-in Python-ast.h and Python-ast.c when I > touch > > > >> > asdl* > > > >> > ? The generated files are unchanged, it's only the timestamp that > > > >> > changed. > > > >> > * Can we, in theory, use new Pythons for asdl* code, because > > > >> > Python-ast.* > > > >> > are, in fact, checked in so they don't have to be rebuilt by the > bots > > > or > > > >> > users? > > > >> > > > >> We should have the buildbots run "make touch", so they don't need to > > > >> run asdl_c.py. > > > > > > > > > > > > How should we go about doing this? > > > > > > Complain to Antoine I suppose. :) > > > > > [+ Antoine] > > Done :) > > "make touch"? Wow, I'm learning new stuff everyday :-) > > (what point is there in adding things to Makefile if nobody knows about > them?) > The devguide would be a good place to mention this. http://bugs.python.org/issue15964 tracked the task for a while, but I'm not sure what the status is. Eli ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] asdl.py and Python-ast.[hc]
On Thu, 26 Sep 2013 14:43:48 -0400 Benjamin Peterson wrote: > 2013/9/26 Eli Bendersky : > > > > > > > > On Thu, Sep 26, 2013 at 7:28 AM, Benjamin Peterson > > wrote: > >> > >> 2013/9/26 Eli Bendersky : > >> > Hi All, > >> > > >> > Earlier this morning I had a slight tackle with a couple of the 3.4 bots > >> > (sorry everyone!). I fixed some problems in asdl.py - > >> > http://hg.python.org/cpython/rev/21d46e3ae60c - and used the 'with' > >> > statement. Some bots don't have Python 2.6+ and couldn't bootstrap > >> > Python-ast.h/c > >> > > >> > Two questions: > >> > > >> > * Should I always check-in Python-ast.h and Python-ast.c when I touch > >> > asdl* > >> > ? The generated files are unchanged, it's only the timestamp that > >> > changed. > >> > * Can we, in theory, use new Pythons for asdl* code, because > >> > Python-ast.* > >> > are, in fact, checked in so they don't have to be rebuilt by the bots or > >> > users? > >> > >> We should have the buildbots run "make touch", so they don't need to > >> run asdl_c.py. > > > > > > How should we go about doing this? > > Complain to Antoine I suppose. :) Here you are: http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/28/steps/compile/logs/stdio Of course, when it's using "-jN" there may be a race condition :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] asdl.py and Python-ast.[hc]
On Thu, Sep 26, 2013 at 2:00 PM, Antoine Pitrou wrote: > On Thu, 26 Sep 2013 14:43:48 -0400 > Benjamin Peterson wrote: > > 2013/9/26 Eli Bendersky : > > > > > > > > > > > > On Thu, Sep 26, 2013 at 7:28 AM, Benjamin Peterson < > benja...@python.org> > > > wrote: > > >> > > >> 2013/9/26 Eli Bendersky : > > >> > Hi All, > > >> > > > >> > Earlier this morning I had a slight tackle with a couple of the 3.4 > bots > > >> > (sorry everyone!). I fixed some problems in asdl.py - > > >> > http://hg.python.org/cpython/rev/21d46e3ae60c - and used the 'with' > > >> > statement. Some bots don't have Python 2.6+ and couldn't bootstrap > > >> > Python-ast.h/c > > >> > > > >> > Two questions: > > >> > > > >> > * Should I always check-in Python-ast.h and Python-ast.c when I > touch > > >> > asdl* > > >> > ? The generated files are unchanged, it's only the timestamp that > > >> > changed. > > >> > * Can we, in theory, use new Pythons for asdl* code, because > > >> > Python-ast.* > > >> > are, in fact, checked in so they don't have to be rebuilt by the > bots or > > >> > users? > > >> > > >> We should have the buildbots run "make touch", so they don't need to > > >> run asdl_c.py. > > > > > > > > > How should we go about doing this? > > > > Complain to Antoine I suppose. :) > > Here you are: > > http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/28/steps/compile/logs/stdio > > Of course, when it's using "-jN" there may be a race condition :-) > Right, which is probably even worse than before because now it's non-deterministic (first build will fail, subsequent will succeed). Is there a way to split it to: $ make touch $ make -jN all ? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?
On 27 Sep 2013 00:12, "Antoine Pitrou" wrote: > > Le Thu, 26 Sep 2013 14:54:49 +1000, > Nick Coghlan a écrit : > > On 26 September 2013 14:30, Nick Coghlan wrote: > > > That said, there are changes that I think are definitely worth > > > making due to the concerns you raise: > > > > > > - the module name should be "_ensurepip" in all versions > > > - the PEP should explicitly state that the "don't remove _ensurepip > > > and it's wheel files" caveat for redistributors applies only in 3.4+ > > > (where removing it will break pyvenv) > > > > Donald pointed out it makes more sense to continue with the idea of a > > properly documented public "ensurepip" module in 3.4+, and have the > > "_ensurepip" version as an implementation detail of the 2.7 and 3.3 > > installers that is included in the stdlib primarily so it can be > > covered by the existing buildbot fleet. > > Hmm, but what is the point of "_ensurepip" exactly? Are people supposed > to type "python -m _ensurepip"? > > With all due respect, Barry's argument looks rather paranoid to me. > I would suggest a clear choice: > - either having "ensurepip" in 2.7 is useful and we endorse it as a > public module (not something hidden somewhere) - which I personally > think is reasonable > - or it's not useful and we don't introduce it at all > > A middleground doesn't make sense here, except in a broken "design by > committee" sense. The *only* reason to have _ensurepip in the older versions is to make the "install pip" option in the installers work. By contrast, in 3.4+ it will be integrated into pyvenv and a fully supported API. The two levels make sense to me, especially since pyvenv in 3.3 *won't* be updated to invoke it automatically. 2.7 and 3.3 users will still need to install and use virtualenv to get pip automatically installed in virtual environments. Cheers, Nick. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] asdl.py and Python-ast.[hc]
On Thu, 26 Sep 2013 14:19:59 -0700 Eli Bendersky wrote: > On Thu, Sep 26, 2013 at 2:00 PM, Antoine Pitrou wrote: > > > On Thu, 26 Sep 2013 14:43:48 -0400 > > Benjamin Peterson wrote: > > > 2013/9/26 Eli Bendersky : > > > > > > > > > > > > > > > > On Thu, Sep 26, 2013 at 7:28 AM, Benjamin Peterson < > > benja...@python.org> > > > > wrote: > > > >> > > > >> 2013/9/26 Eli Bendersky : > > > >> > Hi All, > > > >> > > > > >> > Earlier this morning I had a slight tackle with a couple of the 3.4 > > bots > > > >> > (sorry everyone!). I fixed some problems in asdl.py - > > > >> > http://hg.python.org/cpython/rev/21d46e3ae60c - and used the 'with' > > > >> > statement. Some bots don't have Python 2.6+ and couldn't bootstrap > > > >> > Python-ast.h/c > > > >> > > > > >> > Two questions: > > > >> > > > > >> > * Should I always check-in Python-ast.h and Python-ast.c when I > > touch > > > >> > asdl* > > > >> > ? The generated files are unchanged, it's only the timestamp that > > > >> > changed. > > > >> > * Can we, in theory, use new Pythons for asdl* code, because > > > >> > Python-ast.* > > > >> > are, in fact, checked in so they don't have to be rebuilt by the > > bots or > > > >> > users? > > > >> > > > >> We should have the buildbots run "make touch", so they don't need to > > > >> run asdl_c.py. > > > > > > > > > > > > How should we go about doing this? > > > > > > Complain to Antoine I suppose. :) > > > > Here you are: > > > > http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/28/steps/compile/logs/stdio > > > > Of course, when it's using "-jN" there may be a race condition :-) > > > > Right, which is probably even worse than before because now it's > non-deterministic (first build will fail, subsequent will succeed). Only if "N" in "-jN" is big enough, I suspect. > Is there a way to split it to: > > $ make touch > $ make -jN all Probably but... I'm really too lazy to do this myself. Buildbot isn't very pleasant. Perhaps someone else wants to do it? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
