[Python-Dev] astgen.py vs. ASDL for ASTs
Hello, Some history (as best as I could collect it) followed by a question: Before Python 2.5, the ast stdlib module was auto generated by a script named astgen.py from a textual AST definition in Tools/compiler/ast.txt. Since 2.5 (http://www.python.org/dev/peps/pep-0339/) ASTs are part of the normal compilation flow by the Python compiler itself, and the ast module uses the same ASTs generated from Parser/Python.asdl My question is, when the switch was made in 2.5 - why didn't the existing AST-generating code was used and the path moved to ASDL instead? What advantages does ASDL have over the previous approach? One reason I could think of is that ASDL nodes are typed and that's maybe better for the generated C code to handle. [My interest here is personal. One of my projects (pycparser) uses a astgen.py-like approach, and in a new project I'm considering the options again and remembered ASDL. ADSL's documentation it extremely scarce online - seems like CPython is one of its only somewhat-visible users these days] Thanks in advance, Eli ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] astgen.py vs. ASDL for ASTs
2013/9/25 Eli Bendersky : > Hello, > > Some history (as best as I could collect it) followed by a question: > > Before Python 2.5, the ast stdlib module was auto generated by a script > named astgen.py from a textual AST definition in Tools/compiler/ast.txt. Sorry, what Python 2.4 ast stdlib module? Any module named "ast" (or "_ast") didn't exist until 2.5. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] astgen.py vs. ASDL for ASTs
cc'ing Jeremy Hylton who made the decision to use Zephyr. On Wed, Sep 25, 2013 at 9:15 AM, Eli Bendersky wrote: > Hello, > > Some history (as best as I could collect it) followed by a question: > > Before Python 2.5, the ast stdlib module was auto generated by a script > named astgen.py from a textual AST definition in Tools/compiler/ast.txt. > > Since 2.5 (http://www.python.org/dev/peps/pep-0339/) ASTs are part of the > normal compilation flow by the Python compiler itself, and the ast module > uses the same ASTs generated from Parser/Python.asdl > > My question is, when the switch was made in 2.5 - why didn't the existing > AST-generating code was used and the path moved to ASDL instead? What > advantages does ASDL have over the previous approach? One reason I could > think of is that ASDL nodes are typed and that's maybe better for the > generated C code to handle. > > [My interest here is personal. One of my projects (pycparser) uses a > astgen.py-like approach, and in a new project I'm considering the options > again and remembered ASDL. ADSL's documentation it extremely scarce online > - seems like CPython is one of its only somewhat-visible users these days] > > Thanks in advance, > Eli > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] astgen.py vs. ASDL for ASTs
On Wed, Sep 25, 2013 at 9:28 AM, Benjamin Peterson wrote: > 2013/9/25 Eli Bendersky : > > Hello, > > > > Some history (as best as I could collect it) followed by a question: > > > > Before Python 2.5, the ast stdlib module was auto generated by a script > > named astgen.py from a textual AST definition in Tools/compiler/ast.txt. > > Sorry, what Python 2.4 ast stdlib module? Any module named "ast" (or > "_ast") didn't exist until 2.5. > I think Eli is talking about the compiler package's own AST. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] astgen.py vs. ASDL for ASTs
On Wed, Sep 25, 2013 at 6:28 AM, Benjamin Peterson wrote: > 2013/9/25 Eli Bendersky : > > Hello, > > > > Some history (as best as I could collect it) followed by a question: > > > > Before Python 2.5, the ast stdlib module was auto generated by a script > > named astgen.py from a textual AST definition in Tools/compiler/ast.txt. > > Sorry, what Python 2.4 ast stdlib module? Any module named "ast" (or > "_ast") didn't exist until 2.5. > Lib/compiler/ast.py (that's in 2.4) Sorry, I should have been more precise ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] astgen.py vs. ASDL for ASTs
On Wed, Sep 25, 2013 at 6:35 AM, Eli Bendersky wrote: > > > > On Wed, Sep 25, 2013 at 6:28 AM, Benjamin Peterson wrote: > >> 2013/9/25 Eli Bendersky : >> > Hello, >> > >> > Some history (as best as I could collect it) followed by a question: >> > >> > Before Python 2.5, the ast stdlib module was auto generated by a script >> > named astgen.py from a textual AST definition in Tools/compiler/ast.txt. >> >> Sorry, what Python 2.4 ast stdlib module? Any module named "ast" (or >> "_ast") didn't exist until 2.5. >> > > Lib/compiler/ast.py (that's in 2.4) > > Sorry, I should have been more precise > http://docs.python.org/release/2.4/lib/module-compiler.ast.html ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Installing python27-devel on Centos5.8 running python2.4
Hi All I need help in installing python development packages (python27-devel) on Centos5.8. Upgrading hardware is not an option as of now. I've installed python2.7 in the same machine by $ wget --no-check-certificate http://www.python.org/ftp/python/2.7.3/Python-2.7.3.tgz $ ./configure --prefix=/usr/local/Python2.7 $ make altinstall Now I need help in installing python-devel package for 2.7. $ sudo yum info python2.7-devel gives no info. Whereas the package is there for python26-devel. Tried many suggestions after googling but still no luck. Any help or pointer for exact steps will be great. Thanks Alok Bhan ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Installing python27-devel on Centos5.8 running python2.4
This list is for the developing *of *Python, not it's use. You can try asking on python-list for some help. On Wed, Sep 25, 2013 at 4:07 AM, alok bhan wrote: > Hi All > > I need help in installing python development packages (python27-devel) on > Centos5.8. Upgrading hardware is not an option as of now. > > I've installed python2.7 in the same machine by > $ wget --no-check-certificate > http://www.python.org/ftp/python/2.7.3/Python-2.7.3.tgz > $ ./configure --prefix=/usr/local/Python2.7 > $ make altinstall > > Now I need help in installing python-devel package for 2.7. > > $ sudo yum info python2.7-devel gives no info. Whereas the package is > there for python26-devel. > > Tried many suggestions after googling but still no luck. Any help or > pointer for exact steps will be great. > > Thanks > Alok Bhan > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > > ___ Python-Dev mailing list [email protected] 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 23, 2013, at 09:15 PM, Nick Coghlan wrote: >With the last round of updates, I believe PEP 453 is ready for >Martin's pronouncement. I want to raise an objection to PEP's proposal to add this as a new feature to Python 2.7 and 3.3. I understand the rationale as stated here: http://www.python.org/dev/peps/pep-0453/#id38 but I still object. ;) I think we've learned it's generally pretty risky to add new features in point releases, and this is a fairly major (and would be the first?) violation of the principal of Python 2.7's conservative maintenance. At the very least, I'd like to know why there's no other alternative. For example, you could provide a PyPI package with this functionality, and let the binary packagers adopt it into their binary packages, for platforms that care. So for example, Linux systems which start from the source tarball could opt out (by doing nothing special) since there are other ways to achieve a similar benefit. For OS X and Windows users getting binary downloads from www.python.org, I think it would be acceptable if the .dmg or .msi included this external package. Why does it have to be added to the source tree for stable releases? Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] 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, 25 Sep 2013 16:50:22 -0400 Barry Warsaw wrote: > On Sep 23, 2013, at 09:15 PM, Nick Coghlan wrote: > > >With the last round of updates, I believe PEP 453 is ready for > >Martin's pronouncement. > > I want to raise an objection to PEP's proposal to add this as a new feature to > Python 2.7 and 3.3. I understand the rationale as stated here: > > http://www.python.org/dev/peps/pep-0453/#id38 > > but I still object. ;) > > I think we've learned it's generally pretty risky to add new features in point > releases, and this is a fairly major (and would be the first?) violation of > the principal of Python 2.7's conservative maintenance. > > At the very least, I'd like to know why there's no other alternative. For > example, you could provide a PyPI package with this functionality, and let the > binary packagers adopt it into their binary packages, for platforms that care. > > So for example, Linux systems which start from the source tarball could opt > out (by doing nothing special) since there are other ways to achieve a similar > benefit. For OS X and Windows users getting binary downloads from > www.python.org, I think it would be acceptable if the .dmg or .msi included > this external package. If it's bundled in the official binary installers, it makes little sense not to add to the source tree, IMHO. First because most people get one of the installers rather than the source tree (on http://www.python.org/webstats/, MSI builds win by ten to one). Second because the few people who get the source tree are experienced users who will get bitten less by hypothetical quirks or oddities. Third because otherwise we're probably making things harder for our beloved packagers ;-) Regards Antoine. ___ Python-Dev mailing list [email protected] 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 26 Sep 2013 06:53, "Barry Warsaw" wrote: > > On Sep 23, 2013, at 09:15 PM, Nick Coghlan wrote: > > >With the last round of updates, I believe PEP 453 is ready for > >Martin's pronouncement. > > I want to raise an objection to PEP's proposal to add this as a new feature to > Python 2.7 and 3.3. I understand the rationale as stated here: > > http://www.python.org/dev/peps/pep-0453/#id38 > > but I still object. ;) > > I think we've learned it's generally pretty risky to add new features in point > releases, and this is a fairly major (and would be the first?) violation of > the principal of Python 2.7's conservative maintenance. > > At the very least, I'd like to know why there's no other alternative. For > example, you could provide a PyPI package with this functionality, and let the > binary packagers adopt it into their binary packages, for platforms that care. > > So for example, Linux systems which start from the source tarball could opt > out (by doing nothing special) since there are other ways to achieve a similar > benefit. For OS X and Windows users getting binary downloads from > www.python.org, I think it would be acceptable if the .dmg or .msi included > this external package. > > Why does it have to be added to the source tree for stable releases? If it can get into the installers another way, it doesn't, really. It only needs to be in the source tree for 3.4+. Alternatively, we could be explicit that the "don't remove it" guideline only applies in 3.4+, where it will be needed by pyvenv. That way, people doing custom builds from source can easily bootstrap pip and we don't need to come up with an alternate solution for getting them into the installers. Cheers, Nick. > > Cheers, > -Barry > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > ___ Python-Dev mailing list [email protected] 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 25, 2013, at 4:50 PM, Barry Warsaw wrote: > Why does it have to be added to the source tree for stable releases? I think it should be placed in the source tree for the stable releases. The reasoning is that 2.7 is going to stick around for a long time. Immediately this won't be ubiquitous but as time goes on you'll be able to be ensured that a ``python -m ensure pip`` exists so that in situations where you don't have pip you'll be able to install it. While not directly relevant to the change I do think this is something users support. I've received a fair but of feedback as I was writing the original draft of the PEP and then throughout the process when me and Nick were working on it. Almost all of it was positive (some of it extremely so) a fair bit of them pointed out the backport to 2.7 as something they were *really* wanting. An early draft of this did not have the backport to 2.7 and when I showed *that* version around to get feedback people were less enthusiastic about it and generally viewed it as "nice but worthless to me for N years". What users want isn't rationale in and of itself but I think it's an important data point, especially given how long 2.7.LASTEVER is going to be relevant to end users. - 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 [email protected] 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 25, 2013, at 05:33 PM, Donald Stufft wrote: >I think it should be placed in the source tree for the stable releases. The >reasoning is that 2.7 is going to stick around for a long time. Immediately >this won't be ubiquitous but as time goes on you'll be able to be ensured >that a ``python -m ensure pip`` exists so that in situations where you don't >have pip you'll be able to install it. > >While not directly relevant to the change I do think this is something users >support. I've received a fair but of feedback as I was writing the original >draft of the PEP and then throughout the process when me and Nick >were working on it. Almost all of it was positive (some of it extremely so) >a fair bit of them pointed out the backport to 2.7 as something they were >*really* wanting. > >An early draft of this did not have the backport to 2.7 and when I showed >*that* version around to get feedback people were less enthusiastic >about it and generally viewed it as "nice but worthless to me for N years". Yeah, I get all this, but it's essentially the same reasoning that lead to Python 2.2.1's addition of True and False. The same flaw occurs though because you cannot guarantee that invocation of `python -m ensurepip` will work unless you micro version check (LBYL) or prepare to catch resulting errors. This essentially means that if you want to write portable Python 2.7 code and scripts, you have to be very cautious, or what works on one box won't necessarily work on another, even though they both have "Python 2.7". It also means that anybody who's documenting about this great new feature has to warn people that, well, maybe it won't work on your machine even though you have Python 2.7 because you don't have a new enough Python 2.7. It means that not all Python 2.7's are alike in a rather fundamental and highly visible way. I personally think that's a recipe for more problems than it solves, and if I was the RM for 2.7 I would not allow it. But I'm not. >What users want isn't rationale in and of itself but I think it's an important >data point, especially given how long 2.7.LASTEVER is going to be >relevant to end users. Users want what users want. It's our job to make the best technical decisions based on all the facts. I understand that Python 2.7 will be around for a long time, and that it would be very convenient to do this. Why is this not opening up the door to more new features being added in future Python 2.7 point releases (or any other stable release)? At least I think the burden should be very high, and the PEP should do a better job of explaining why *no* other option will accomplish the goal. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] 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 07:14 AM, Nick Coghlan wrote: >On 26 Sep 2013 06:53, "Barry Warsaw" wrote: >> >> Why does it have to be added to the source tree for stable releases? > >If it can get into the installers another way, it doesn't, really. It only >needs to be in the source tree for 3.4+. Sure, new features can of course go in the development release. :) -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] 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 25, 2013, at 5:51 PM, Barry Warsaw wrote: > On Sep 25, 2013, at 05:33 PM, Donald Stufft wrote: > >> I think it should be placed in the source tree for the stable releases. The >> reasoning is that 2.7 is going to stick around for a long time. Immediately >> this won't be ubiquitous but as time goes on you'll be able to be ensured >> that a ``python -m ensure pip`` exists so that in situations where you don't >> have pip you'll be able to install it. >> >> While not directly relevant to the change I do think this is something users >> support. I've received a fair but of feedback as I was writing the original >> draft of the PEP and then throughout the process when me and Nick >> were working on it. Almost all of it was positive (some of it extremely so) >> a fair bit of them pointed out the backport to 2.7 as something they were >> *really* wanting. >> >> An early draft of this did not have the backport to 2.7 and when I showed >> *that* version around to get feedback people were less enthusiastic >> about it and generally viewed it as "nice but worthless to me for N years". > > Yeah, I get all this, but it's essentially the same reasoning that lead to > Python 2.2.1's addition of True and False. The same flaw occurs though > because you cannot guarantee that invocation of `python -m ensurepip` will > work unless you micro version check (LBYL) or prepare to catch resulting > errors. This essentially means that if you want to write portable Python 2.7 > code and scripts, you have to be very cautious, or what works on one box won't > necessarily work on another, even though they both have "Python 2.7". > > It also means that anybody who's documenting about this great new feature has > to warn people that, well, maybe it won't work on your machine even though you > have Python 2.7 because you don't have a new enough Python 2.7. > > It means that not all Python 2.7's are alike in a rather fundamental and > highly visible way. > > I personally think that's a recipe for more problems than it solves, and if I > was the RM for 2.7 I would not allow it. But I'm not. Well I don't think many scripts will be executing ensurepip, maybe i'm wrong, but yes it does mean that not all Python 2.7's are alike. Most likely though at some point 2.7.XXX is going to be near standard as the 2.7 hold outs stay on it and time progresses. It more or less shifts the "time until projects can assume people have pip available or easily installable" from "until 3.4+ is ubiquitous and 2.7 is gone (Years?) to "until Python 2.7.6 is ubiquitous" which will be a much shorter time. > >> What users want isn't rationale in and of itself but I think it's an >> important >> data point, especially given how long 2.7.LASTEVER is going to be >> relevant to end users. > > Users want what users want. It's our job to make the best technical decisions > based on all the facts. I understand that Python 2.7 will be around for a > long time, and that it would be very convenient to do this. Why is this not > opening up the door to more new features being added in future Python 2.7 > point releases (or any other stable release)? > Other than the fact that it in itself is an exception to the rule this actually strengthens that because it makes it easier for people to install new things into Python 2.7 outside of the release cycle. So things like the new enum module can more easily be backported and used as an installable than as part of the language. The obvious exemption to this is language level features, but as this itself isn't a language level feature i'm not sure how relevant that is. > At least I think the burden should be very high, and the PEP should do a > better job of explaining why *no* other option will accomplish the goal. This is totally fair and we can expand on it more for sure. > > Cheers, > -Barry > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io - 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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Close #19030: improvements to inspect and Enum.
Hmm, I think I just noticed a subtle bug in the new version that I missed previously - I believe it may now misclassify a function in an instance dict as a method. Would need to try it out to be sure. Cheers, Nick. ___ Python-Dev mailing list [email protected] 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 26 Sep 2013 07:54, "Barry Warsaw" wrote: > > On Sep 25, 2013, at 05:33 PM, Donald Stufft wrote: > > >I think it should be placed in the source tree for the stable releases. The > >reasoning is that 2.7 is going to stick around for a long time. Immediately > >this won't be ubiquitous but as time goes on you'll be able to be ensured > >that a ``python -m ensure pip`` exists so that in situations where you don't > >have pip you'll be able to install it. > > > >While not directly relevant to the change I do think this is something users > >support. I've received a fair but of feedback as I was writing the original > >draft of the PEP and then throughout the process when me and Nick > >were working on it. Almost all of it was positive (some of it extremely so) > >a fair bit of them pointed out the backport to 2.7 as something they were > >*really* wanting. > > > >An early draft of this did not have the backport to 2.7 and when I showed > >*that* version around to get feedback people were less enthusiastic > >about it and generally viewed it as "nice but worthless to me for N years". > > Yeah, I get all this, but it's essentially the same reasoning that lead to > Python 2.2.1's addition of True and False. The same flaw occurs though > because you cannot guarantee that invocation of `python -m ensurepip` will > work unless you micro version check (LBYL) or prepare to catch resulting > errors. This essentially means that if you want to write portable Python 2.7 > code and scripts, you have to be very cautious, or what works on one box won't > necessarily work on another, even though they both have "Python 2.7". There's a bit of a difference between adding new builtins and adding a new utility module, though. The only regular invocations of ensurepip in 2.7 and 3.3 should be from our installers and people doing a custom build from source. Would a leading underscore in the module name make you more comfortable with the idea? It's really intended mostly as a hidden implementation detail of the installers and pyvenv anyway, so calling it "_ensurepip" would help make that explicit while still letting people invoke it directly if absolutely necessary. Cheers, Nick. > > It also means that anybody who's documenting about this great new feature has > to warn people that, well, maybe it won't work on your machine even though you > have Python 2.7 because you don't have a new enough Python 2.7. > > It means that not all Python 2.7's are alike in a rather fundamental and > highly visible way. > > I personally think that's a recipe for more problems than it solves, and if I > was the RM for 2.7 I would not allow it. But I'm not. > > >What users want isn't rationale in and of itself but I think it's an important > >data point, especially given how long 2.7.LASTEVER is going to be > >relevant to end users. > > Users want what users want. It's our job to make the best technical decisions > based on all the facts. I understand that Python 2.7 will be around for a > long time, and that it would be very convenient to do this. Why is this not > opening up the door to more new features being added in future Python 2.7 > point releases (or any other stable release)? > > At least I think the burden should be very high, and the PEP should do a > better job of explaining why *no* other option will accomplish the goal. > > Cheers, > -Barry > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > ___ Python-Dev mailing list [email protected] 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 25, 2013, at 06:15 PM, Donald Stufft wrote: >Well I don't think many scripts will be executing ensurepip, maybe i'm wrong, >but yes it does mean that not all Python 2.7's are alike. Most likely though >at some point 2.7.XXX is going to be near standard as the 2.7 hold outs stay >on it and time progresses. I think it's too optimistic to hope that we'll ever see significant convergence across the Python 2.7 ecosystem. For example, I'd be really surprised if you'd see this show up in a stable release of Debian or Ubuntu (the only ones I can speak somewhat authoritatively about), even if we wanted to cherrypick updates in newer Python 2.7 point releases. Linux distros tend to be even more anal about avoiding new features in stable releases, for the same really good reasons, IMHO :). I think for the platforms you're targeting (OS X, Windows), you're going to see a wide variety for a very long time. It's depressing how infrequently people upgrade *anything*. 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. >It more or less shifts the "time until projects can assume people have pip >available or easily installable" from "until 3.4+ is ubiquitous and 2.7 is >gone (Years?) to "until Python 2.7.6 is ubiquitous" which will be a much >shorter time. Yeah, maybe, but I'm pretty skeptical about the enthusiasm for upgrades. ;) >> Users want what users want. It's our job to make the best technical >> decisions based on all the facts. I understand that Python 2.7 will be >> around for a long time, and that it would be very convenient to do this. >> Why is this not opening up the door to more new features being added in >> future Python 2.7 point releases (or any other stable release)? >> > >Other than the fact that it in itself is an exception to the rule this >actually strengthens that because it makes it easier for people to install >new things into Python 2.7 outside of the release cycle. So things like the >new enum module can more easily be backported and used as an installable than >as part of the language. The obvious exemption to this is language level >features, but as this itself isn't a language level feature i'm not sure how >relevant that is. So, why shouldn't we add enum to the Python 2.7 stdlib? Or any other new feature? Just be aware that if this PEP is accepted for Python 2.7, the bar will be set much lower for other Really Useful Features That Make Users Lives Better. >> At least I think the burden should be very high, and the PEP should do a >> better job of explaining why *no* other option will accomplish the goal. > >This is totally fair and we can expand on it more for sure. Cool. Maybe in the course of that discussion, a better alternative that doesn't add a new feature to Python 2.7 will present itself. I really hope so. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] 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 25, 2013, at 7:04 PM, Barry Warsaw wrote: > So, why shouldn't we add enum to the Python 2.7 stdlib? Or any other new > feature? Just be aware that if this PEP is accepted for Python 2.7, the bar > will be set much lower for other Really Useful Features That Make Users Lives > Better. Because with PEP453 you can just ``pip install enum34`` it :) - 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 [email protected] 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 09:01 AM, Nick Coghlan wrote: >Would a leading underscore in the module name make you more comfortable >with the idea? It's really intended mostly as a hidden implementation >detail of the installers and pyvenv anyway, so calling it "_ensurepip" >would help make that explicit while still letting people invoke it directly >if absolutely necessary. If it was also undocumented, and we can guarantee that it will have no impact outside of the module itself, then maybe. I'm not sure it would be enough for me to accept it if I were the RM, but I'm not (thankfully. :). I still think it's optimistic to pin any hopes on its widespread availability in future 2.7 point releases on people's actual systems. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] 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 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? - 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 [email protected] 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 25, 2013, at 07:08 PM, Donald Stufft wrote: >On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote: > >> So, why shouldn't we add enum to the Python 2.7 stdlib? >Because with PEP453 you can just ``pip install enum34`` it :) Of course, pip messing with global Python state on a package managed system like most Linux distros, is a whole 'nuther happy fun ball of killer beeswax. :) mixing-metaphors-ly y'rs, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] 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 25, 2013, at 7:15 PM, Barry Warsaw wrote: > Of course, pip messing with global Python state on a package managed system > like most Linux distros, is a whole 'nuther happy fun ball of killer > beeswax. :) > > mixing-metaphors-ly y'rs, > -Barry (For reals a pip and apt-get playing nicely is on my stack of PEPs to do) - 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 [email protected] 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
[ I've replied to two messages here: Georg's and Glenn's (supporting MRAB's).
- Cameron
]
On 25Sep2013 08:22, Georg Brandl wrote:
| Am 24.09.2013 00:11, schrieb Greg Ewing:
| > How about something like "Uncaught exception in __del__
| > method ignored"? It explains fairly clearly what has
| > happened, and also indicates what do do about it --
| > catch it in the __del__ method.
|
| "Exception in __del__ caught and not propagated:"
| Georg
On 24Sep2013 09:33, Glenn Linderman wrote:
| [MRAB]:
| >> Why not just say something like "Cannot propagate exception..."; it's
| >> simpler than "Unpropagatable exception...". [...]
|
| First one I've heard that accurately and unambiguously and briefly
| describes the issue.
| +1
I'm strongly in favour of Georg's one ("Exception in __del__ caught and not
propagated").
Why?
It says simply and clearly what has happened.
It denotes the relevant context (__del__) in which it happened.
The reader can then decide to find out why that decision may have been made.
Why not MRAB's? ("Cannot propagate exception...")
While better than "Unpropagatable exception" and "unraisable" and
"unreraisable", it has the same flaw that I think underlies Antoine's
concerns: it suggests the reason there's an error printed instead
of further propagation is a _property of the exception_.
It doesn't say it outright, but as an outsider that is definitely
what I would at first infer.
So: a small +0.1 for "Cannot propagate exception..."
And: a big +2 for "Exception in __del__ caught and not propagated:".
Cheers,
--
Cameron Simpson
Let the bullet of your thought achieve the true and final path of its
trajectory before it reaches the ear of the listener, lest it plow out the
other side of his head. - Henry David Thoreau
___
Python-Dev mailing list
[email protected]
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 26/09/2013 00:05, Cameron Simpson wrote:
[ I've replied to two messages here: Georg's and Glenn's (supporting MRAB's).
- Cameron
]
On 25Sep2013 08:22, Georg Brandl wrote:
| Am 24.09.2013 00:11, schrieb Greg Ewing:
| > How about something like "Uncaught exception in __del__
| > method ignored"? It explains fairly clearly what has
| > happened, and also indicates what do do about it --
| > catch it in the __del__ method.
|
| "Exception in __del__ caught and not propagated:"
| Georg
On 24Sep2013 09:33, Glenn Linderman wrote:
| [MRAB]:
| >> Why not just say something like "Cannot propagate exception..."; it's
| >> simpler than "Unpropagatable exception...". [...]
|
| First one I've heard that accurately and unambiguously and briefly
| describes the issue.
| +1
I'm strongly in favour of Georg's one ("Exception in __del__ caught and not
propagated").
Why?
It says simply and clearly what has happened.
It denotes the relevant context (__del__) in which it happened.
The reader can then decide to find out why that decision may have been made.
Why not MRAB's? ("Cannot propagate exception...")
While better than "Unpropagatable exception" and "unraisable" and
"unreraisable", it has the same flaw that I think underlies Antoine's
concerns: it suggests the reason there's an error printed instead
of further propagation is a _property of the exception_.
It doesn't say it outright, but as an outsider that is definitely
what I would at first infer.
So: a small +0.1 for "Cannot propagate exception..."
And: a big +2 for "Exception in __del__ caught and not propagated:".
Well, my suggestion was more about eliminating the adjective+noun form;
it seemed it just wasn't
possible to cram the desired meaning into a single word, so it was
better not to try!
___
Python-Dev mailing list
[email protected]
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/25/2013 5:17 PM, MRAB wrote:
On 26/09/2013 00:05, Cameron Simpson wrote:
[ I've replied to two messages here: Georg's and Glenn's (supporting
MRAB's).
- Cameron
]
On 25Sep2013 08:22, Georg Brandl wrote:
| Am 24.09.2013 00:11, schrieb Greg Ewing:
| > How about something like "Uncaught exception in __del__
| > method ignored"? It explains fairly clearly what has
| > happened, and also indicates what do do about it --
| > catch it in the __del__ method.
|
| "Exception in __del__ caught and not propagated:"
| Georg
On 24Sep2013 09:33, Glenn Linderman wrote:
| [MRAB]:
| >> Why not just say something like "Cannot propagate exception...";
it's
| >> simpler than "Unpropagatable exception...". [...]
|
| First one I've heard that accurately and unambiguously and briefly
| describes the issue.
| +1
I'm strongly in favour of Georg's one ("Exception in __del__ caught
and not propagated").
Why?
It says simply and clearly what has happened.
It denotes the relevant context (__del__) in which it happened.
The reader can then decide to find out why that decision may have
been made.
Why not MRAB's? ("Cannot propagate exception...")
While better than "Unpropagatable exception" and "unraisable" and
"unreraisable", it has the same flaw that I think underlies Antoine's
concerns: it suggests the reason there's an error printed instead
of further propagation is a _property of the exception_.
It doesn't say it outright, but as an outsider that is definitely
what I would at first infer.
So: a small +0.1 for "Cannot propagate exception..."
And: a big +2 for "Exception in __del__ caught and not propagated:".
Well, my suggestion was more about eliminating the adjective+noun
form; it seemed it just wasn't
possible to cram the desired meaning into a single word, so it was
better not to try!
Georg hadn't suggested his yet when I approved MRAB's, but your
reasoning is sound, Cameron, unless there is some reason that the
message can't or shouldn't be as long as what Georg suggested.
In between in length and clarity might be:
__del__ cannot propagate exception
All of these are less confusing that the adj+noun form, that MRAB was
the first to get away from.
___
Python-Dev mailing list
[email protected]
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?
Donald Stufft writes: > On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote: > > > So, why shouldn't we add enum to the Python 2.7 stdlib? Or any > > other new feature? Just be aware that if this PEP is accepted > > for Python 2.7, the bar will be set much lower for other Really > > Useful Features That Make Users Lives Better. > > Because with PEP453 you can just ``pip install enum34`` it :) Uh, I've been doing that for years (well, not with ``enum34``, to be sure). And not just with 2.7, 2.6 and 2.5 too. Who needs PEP 453? Not me (ironically, I'll probably have a PEP 453 Python within 48 hours of its public release). OTOH, as Barry points out, the target population doesn't upgrade very often. What gets them to upgrade (or install in parallel) is the installation of a package that requires an upgraded Python. But that typically means a bump from x.y to x.z, and that will never happen to 2.7. So they'll see a failure of some kind anyway if the ensurepip feature is used! That is going to blowback on distributors, which is going to make PEP 453 real popular with them. Not. ___ Python-Dev mailing list [email protected] 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 26 September 2013 09:08, Barry Warsaw wrote: > On Sep 26, 2013, at 09:01 AM, Nick Coghlan wrote: > >>Would a leading underscore in the module name make you more comfortable >>with the idea? It's really intended mostly as a hidden implementation >>detail of the installers and pyvenv anyway, so calling it "_ensurepip" >>would help make that explicit while still letting people invoke it directly >>if absolutely necessary. > > If it was also undocumented, and we can guarantee that it will have no impact > outside of the module itself, then maybe. I'm not sure it would be enough for > me to accept it if I were the RM, but I'm not (thankfully. :). > > I still think it's optimistic to pin any hopes on its widespread availability > in future 2.7 point releases on people's actual systems. The recommended user experience for 2.7 users on Windows and Mac OS X will be "Install the latest Python 2.7 from python.org". This feature is *not* aimed at existing users *at all*. For Python 2.7, the benefits are aimed almost entirely at beginners installing Python for the first time, regardless of platform. There's a *side effect* for existing users, where for Windows and Mac OS X users, the pip bootstrapping instructions become "install the latest maintenance release" rather than downloading and running the bootstrap script from pip-installer.org. The presence or absence of _ensurepip should be completely irrelevant to end users, as it will be there in 2.7 solely to make the new feature of the installer work. Your alternative proposal is to instead come up with a *new* mechanism to support the feature, specifically for 2.7. That's increasing the chance of breakage, not reducing it, *because the _ensurepip tests would no longer be executed by the Python 2.7 buildbots*. 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) The benefits are most obvious in the case of 2.7, so both Donald and I are also fine with skipping making any changes to Python 3.3. The kind of environment that could make it difficult to upgrade from Python 3.3. to 3.4 is unlikely to condone the installation and use of pip anyway. There is one other change which is potentially reasonable, and that's changing the default state of the "Install pip (the default Python package management utility)?" checkbox. I believe it should be checked by default in all versions, but if Benjamin decides that it should be unchecked by default in 2.7, I'd be willing to go along with that. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 26 September 2013 11:52, Stephen J. Turnbull wrote: > Donald Stufft writes: > > > On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote: > > > > > So, why shouldn't we add enum to the Python 2.7 stdlib? Or any > > > other new feature? Just be aware that if this PEP is accepted > > > for Python 2.7, the bar will be set much lower for other Really > > > Useful Features That Make Users Lives Better. > > > > Because with PEP453 you can just ``pip install enum34`` it :) > > Uh, I've been doing that for years (well, not with ``enum34``, to be > sure). And not just with 2.7, 2.6 and 2.5 too. Who needs PEP 453? > Not me (ironically, I'll probably have a PEP 453 Python within 48 > hours of its public release). New users on Windows and Mac OS X. I've heard many more complaints from folks running tutorials about the pip bootstrapping process than I ever have from the community at large about the GIL :P Linux and other *nix platforms are affected primarily due to the fact that we also want pyvenv to start making pip available by default in 3.4+, so we need the PEP to account for making that possible while still playing nice with the Linux distro vendors. > OTOH, as Barry points out, the target population doesn't upgrade very > often. If somebody already has Python installed, they're not really part of the target population, except in the sense that the pip bootstrap instruction become "upgrade Python to the latest maintenance release" rather than "got to this website, download and run this bootstrap script". (Keeping those instructions consistent for 3.3 users as well would be the advantage of updating 3.3 in addition to 2.7 and 3.4) > What gets them to upgrade (or install in parallel) is the > installation of a package that requires an upgraded Python. But that > typically means a bump from x.y to x.z, and that will never happen to > 2.7. So they'll see a failure of some kind anyway if the ensurepip > feature is used! That is going to blowback on distributors, which is > going to make PEP 453 real popular with them. Not. I'm not sure what usage model you're assuming for _ensurepip, but it appears to be wrong. End users should be able to just run pip, and either have it work, or else get a message from the OS vendor telling them to install the appropriate system package. If it doesn't work, then the advice will be to upgrade to the latest Python maintenance release. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 26 September 2013 09:05, Cameron Simpson wrote:
> On 24Sep2013 09:33, Glenn Linderman wrote:
> | [MRAB]:
> | >> Why not just say something like "Cannot propagate exception..."; it's
> | >> simpler than "Unpropagatable exception...". [...]
> |
> | First one I've heard that accurately and unambiguously and briefly
> | describes the issue.
> | +1
>
> I'm strongly in favour of Georg's one ("Exception in __del__ caught and not
> propagated").
>
> Why?
>
> It says simply and clearly what has happened.
> It denotes the relevant context (__del__) in which it happened.
> The reader can then decide to find out why that decision may have been made.
Such a change is highly unlikely to happen, as it would require
changing every location where we call PyErr_WriteUnraisable.
> Why not MRAB's? ("Cannot propagate exception...")
>
> While better than "Unpropagatable exception" and "unraisable" and
> "unreraisable", it has the same flaw that I think underlies Antoine's
> concerns: it suggests the reason there's an error printed instead
> of further propagation is a _property of the exception_.
> It doesn't say it outright, but as an outsider that is definitely
> what I would at first infer.
It's substantially better than the status quo, though, and it
shouldn't require any changes outside PyErr_WriteUnraisable.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
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 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. Redistributors will be free to remove "_ensurepip" from 2.7 and 3.3, but the PEP will continue to advise strongly against removing "ensurepip" from 3.4+ (since it will be a documented feature and a dependency of pyvenv) > The benefits are most obvious in the case of 2.7, so both Donald and I > are also fine with skipping making any changes to Python 3.3. The kind > of environment that could make it difficult to upgrade from Python > 3.3. to 3.4 is unlikely to condone the installation and use of pip > anyway. In replying to Stephen I realised the benefit of making a similar change in the 3.3 installer is that it means the preferred pip bootstrapping instructions for both 2.7 and 3.3 can be to update to the latest maintenance release of CPython, rather than needing to tell 3.3 users to consider upgrading to 3.4 when that release contains potentially breaking changes to the way file descriptors are handled. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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
Hi Nick,
On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan wrote:
>> I'm strongly in favour of Georg's one ("Exception in __del__ caught and not
>> propagated").
>
> Such a change is highly unlikely to happen, as it would require
> changing every location where we call PyErr_WriteUnraisable.
Er, why? It seems to me it's a matter of changing these three lines
in PyErr_WriteUnraisable():
- PyFile_WriteString("Exception ignored in: ", f);
+ PyFile_WriteString("Exception in ", f);
PyFile_WriteObject(obj, f, 0);
- PyFile_WriteString("\n", f);
+ PyFile_WriteString(" caught and not propagated:\n", f);
I don't see what makes this technically different from the other
solution, "Cannot propagate exception..."
A bientôt,
Armin.
___
Python-Dev mailing list
[email protected]
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 26 September 2013 15:42, Armin Rigo wrote:
> Hi Nick,
>
> On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan wrote:
>>> I'm strongly in favour of Georg's one ("Exception in __del__ caught and not
>>> propagated").
>>
>> Such a change is highly unlikely to happen, as it would require
>> changing every location where we call PyErr_WriteUnraisable.
>
> Er, why? It seems to me it's a matter of changing these three lines
> in PyErr_WriteUnraisable():
>
> - PyFile_WriteString("Exception ignored in: ", f);
> + PyFile_WriteString("Exception in ", f);
> PyFile_WriteObject(obj, f, 0);
> - PyFile_WriteString("\n", f);
> + PyFile_WriteString(" caught and not propagated:\n", f);
>
> I don't see what makes this technically different from the other
> solution, "Cannot propagate exception..."
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.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
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, 25 Sep 2013 19:15:05 -0400 Barry Warsaw wrote: > On Sep 25, 2013, at 07:08 PM, Donald Stufft wrote: > > >On Sep 25, 2013, at 7:04 PM, Barry Warsaw wrote: > > > >> So, why shouldn't we add enum to the Python 2.7 stdlib? > > >Because with PEP453 you can just ``pip install enum34`` it :) > > Of course, pip messing with global Python state on a package managed system > like most Linux distros, is a whole 'nuther happy fun ball of killer > beeswax. :) pip install --user enum34 :-) ___ Python-Dev mailing list [email protected] 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
Am 26.09.2013 08:22, schrieb Nick Coghlan:
> On 26 September 2013 15:42, Armin Rigo wrote:
>> Hi Nick,
>>
>> On Thu, Sep 26, 2013 at 6:59 AM, Nick Coghlan wrote:
I'm strongly in favour of Georg's one ("Exception in __del__ caught and
not propagated").
>>>
>>> Such a change is highly unlikely to happen, as it would require
>>> changing every location where we call PyErr_WriteUnraisable.
>>
>> Er, why? It seems to me it's a matter of changing these three lines
>> in PyErr_WriteUnraisable():
>>
>> - PyFile_WriteString("Exception ignored in: ", f);
>> + PyFile_WriteString("Exception in ", f);
>> PyFile_WriteObject(obj, f, 0);
>> - PyFile_WriteString("\n", f);
>> + PyFile_WriteString(" caught and not propagated:\n", f);
>>
>> I don't see what makes this technically different from the other
>> solution, "Cannot propagate exception..."
>
> 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: <>
Georg
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
