Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions
Hi, 2014-03-12 18:09 GMT+01:00 Guido van Rossum : > I want to reject this PEP. (...) > this was a well-written and well-researched PEP, and I think you've done a > great job moderating the discussion, collecting objections, reviewing > alternatives, and everything else that is required to turn a heated debate > into a PEP. Well done Chris (and everyone who helped), and good luck with > your next PEP! I spend many weeks to work (write the PEP *and* implement them) on the following PEPs and Guido rejected them: - PEP 416: Add a frozendict builtin type - PEP 410: Use decimal.Decimal type for timestamps It's hard to accept that a wonderful idea at a first look is not a good idea. Some months later, I now agree and see issues of my PEPs. The PEP process ensures that the Python "language" (+ stdlib) keeps consistent and well designed. Even if a PEP is rejected, it becomes the best reference if someone requests the same or a similar feature some months or years later. Rejected PEPs explain almost how the Python language was designed. For thanks Chris, and I hope that it's not too hard for you to accept the fact that your "inline try/except" idea is maybe not as good as you expected :-) Victor ___ 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] Requesting pronouncement on PEP 463: Exception-catching expressions
On Thu, Mar 13, 2014 at 8:15 PM, Victor Stinner wrote: > Even if a PEP is rejected, it becomes the best reference if someone > requests the same or a similar feature some months or years later. > Rejected PEPs explain almost how the Python language was designed. > > For thanks Chris, and I hope that it's not too hard for you to accept > the fact that your "inline try/except" idea is maybe not as good as > you expected :-) One of the original goals of the PEP was to get everything written down. I actually didn't have any sort of strong opinion on the matter until part way in; effectively, I had to first convince myself, then try to convince others :) So it's not hard to accept that the idea isn't such a good one. ChrisA ___ 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 463: Exception-catching expressions
On Thu, Mar 13, 2014 at 07:54:18AM +1100, Chris Angelico wrote: > On Thu, Mar 13, 2014 at 7:26 AM, "Martin v. Löwis" wrote: > > I think you (or someone) first needs to find a BDFL delegate. > > Traditionally, with syntax changes, there is a good chance that Guido > > doesn't want to delegate at all, so ask him whether he wants to delegate > > or not. > > He beat you to it; the PEP has now been rejected. :) Guido said he *wanted* to reject it, and that there would be no more pronouncement until after the language summit. I think you should wait until after the summit before declaring it categorically rejected, perhaps somebody will persuade Guido to change his mind :-) But either way, thanks for tackling this, the threads about syntax were monsterous and I ran out of steam trying to keep up with it all long ago. -- Steven ___ 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] Whats New in 3.4 is pretty much done...
On 11.03.2014 13:18, Victor Stinner wrote: > Hi, > > Thanks David! I added a summary of security improvements: > http://docs.python.org/dev/whatsnew/3.4.html#summary-release-highlights > > Can someone please review it? Don't hesitate to modify the text > directly. Check also if the summary is complete. Thanks a lot David and Victor! The list of security improvements is missing one, maybe two points that are IMHO relevant: * All stdlib modules now support server cert verification including hostname matching and CRL. * http://bugs.python.org/issue16499 isolated mode is a security improvement, too. Should the section or Whats New in general mention that Python builds without compiler warnings on most platforms and that we aim for zero warnings on all supported platforms and compilers? And there is the point with Coverity Scan. We have reached zero defects about half a year ago and fixed all new defects in a matter of days. I'll try to keep the defect rate down to zero in the future, too. The tool has helped me to identify a bunch of security-relevant issues like buffer overflows, invalid casts and more. It's something worth mentioning. But I don't want it to sound like an advert... Suggestions? Christian ___ 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] Whats New in 3.4 is pretty much done...
Christian Heimes writes: > But I don't want it to sound like an advert... Suggestions? Not to worry. It *can't* be an advert -- it's all true, and there are no irrelevant half-naked glistening bodies. (Former newts in the pond don't count.) Seriously, while "expect a clean build" is not "news" for Python, it's useful to state that we're at zero warnings nearly across the board, including Coverity. Accompanied by an open invitation for reports to the contrary, that's hardly like a commercial. Of course, following that up with "wink wink, nudge nudge, say no more say no more, eh?" would ruin the effect! ___ 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] Whats New in 3.4 is pretty much done...
Le 13/03/2014 11:49, Christian Heimes a écrit : Thanks a lot David and Victor! The list of security improvements is missing one, maybe two points that are IMHO relevant: * All stdlib modules now support server cert verification including hostname matching and CRL. CRL? really? I don't remember us doing automatic CRL downloads. And there is the point with Coverity Scan. We have reached zero defects about half a year ago and fixed all new defects in a matter of days. I'll try to keep the defect rate down to zero in the future, too. The tool has helped me to identify a bunch of security-relevant issues like buffer overflows, invalid casts and more. It's something worth mentioning. But I don't want it to sound like an advert... Suggestions? I don't think it should be mentioned at all. General code quality improvements are a given in any release, the fact that the issues were detected by Coverity rather than human scrutiny is a non-information (except as advertising for Coverity). 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] Requesting pronouncement on PEP 463: Exception-catching expressions
On Mar 13, 2014, at 10:15 AM, Victor Stinner wrote: >It's hard to accept that a wonderful idea at a first look is not a >good idea. Some months later, I now agree and see issues of my PEPs. >The PEP process ensures that the Python "language" (+ stdlib) keeps >consistent and well designed. > >Even if a PEP is rejected, it becomes the best reference if someone >requests the same or a similar feature some months or years later. >Rejected PEPs explain almost how the Python language was designed. > >For thanks Chris, and I hope that it's not too hard for you to accept >the fact that your "inline try/except" idea is maybe not as good as >you expected :-) Don't worry, there's always Python 4 . http://legacy.python.org/dev/peps/pep-0274/ -Barry ___ 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] Whats New in 3.4 is pretty much done...
2014-03-13 11:49 GMT+01:00 Christian Heimes : > * All stdlib modules now support server cert verification including > hostname matching and CRL. > > * http://bugs.python.org/issue16499 isolated mode is a security > improvement, too. Ok, I added these two items. Antoine wrote: > CRL? really? I don't remember us doing automatic CRL downloads. It's just the "support", nothing is automatic. I understood that you *can* load CRL and ask for CRL validation, but it must be done explicitly. There is a function to retrieve system CRLs on Windows. Victor ___ 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] PEP URLs
On 13 March 2014 13:28, Barry Warsaw wrote: > > http://legacy.python.org/dev/peps/pep-0274/ Are these "legacy.python.org" URLs the canonical locations for PEPs these days? The main page redirects there, but I'd have hoped there would be a www.python.org location... (Just checking before I update my PEP lookup bookmarklet :-)) Paul ___ 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 URLs
On Mar 13, 2014, at 10:06 AM, Paul Moore wrote: > On 13 March 2014 13:28, Barry Warsaw wrote: >> >> http://legacy.python.org/dev/peps/pep-0274/ > > Are these "legacy.python.org" URLs the canonical locations for PEPs > these days? The main page redirects there, but I'd have hoped there > would be a www.python.org location... > > (Just checking before I update my PEP lookup bookmarklet :-)) > > Paul > ___ > 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 AFAIK the www.python.org PEP stuff just isn’t done yet, and the legacy redirect is a temporary stopgap. - 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] PEP URLs
Quoting Paul Moore : On 13 March 2014 13:28, Barry Warsaw wrote: http://legacy.python.org/dev/peps/pep-0274/ Are these "legacy.python.org" URLs the canonical locations for PEPs these days? The main page redirects there, but I'd have hoped there would be a www.python.org location... http://www.python.org/dev/peps/pep-0274/ continues to work (as I thought you said yourself), so there *is* a www.python.org location. Regards, Martin ___ 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] Any non-3.4.0 docs in "default"?
I'm strongly considering literally copying over all the content in Doc/ from the default branch to the 3.4 branch. Not cherry-picking doc changes, simply copying everything en masse. I have two questions for the core devs. 1) Sound good? 2) Do you know of anything in Doc/ that shouldn't ship in 3.4.0? I know about the change to the build--3.4.1 won't auto-download Sphinx anymore. Is there anything else like that? Thanks, //arry/ p.s. I expect to tag 3.4.0 final somewhere between 48 and 72 hours from now. Hopefully the light at the end of the tunnel isn't an oncoming train! ___ 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] Any non-3.4.0 docs in "default"?
On Thu, Mar 13, 2014 at 11:16 AM, Larry Hastings wrote: > > > I'm strongly considering literally copying over all the content in Doc/ > from the default branch to the 3.4 branch. Not cherry-picking doc changes, > simply copying everything en masse. I have two questions for the core devs. > > 1) Sound good? > As long as no one answers "I know of something to not ship" to question #2, then it SGTM. -Brett > > 2) Do you know of anything in Doc/ that shouldn't ship in 3.4.0? I know > about the change to the build--3.4.1 won't auto-download Sphinx anymore. > Is there anything else like that? > > Thanks, > > > */arry* > > p.s. I expect to tag 3.4.0 final somewhere between 48 and 72 hours from > now. Hopefully the light at the end of the tunnel isn't an oncoming train! > > ___ > 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/brett%40python.org > > ___ 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] Requesting pronouncement on PEP 463: Exception-catching expressions
Tres Seaver writes: > On 03/12/2014 04:49 PM, Chris Angelico wrote: >> You can use hasattr() in place of AttributeError > > I use: > > getattr(subject, attrname, default)? > > *all the time*. In my opinion that's almost as ugly, because it still forces you to specify the attribute name as a string rather than an identifier. Best, Nikolaus -- Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C »Time flies like an arrow, fruit flies like a Banana.« ___ 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] Any non-3.4.0 docs in "default"?
13.03.14 17:16, Larry Hastings написав(ла): I'm strongly considering literally copying over all the content in Doc/ from the default branch to the 3.4 branch. Not cherry-picking doc changes, simply copying everything en masse. I have two questions for the core devs. 1) Sound good? 2) Do you know of anything in Doc/ that shouldn't ship in 3.4.0? I know about the change to the build--3.4.1 won't auto-download Sphinx anymore. Is there anything else like that? David fixed not only Doc/*, but some entities in Misc/NEWS too. And may be he fixed some docstrings. ___ 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] Any non-3.4.0 docs in "default"?
Le 13/03/2014 17:18, Serhiy Storchaka a écrit : 13.03.14 17:16, Larry Hastings написав(ла): I'm strongly considering literally copying over all the content in Doc/ from the default branch to the 3.4 branch. Not cherry-picking doc changes, simply copying everything en masse. I have two questions for the core devs. 1) Sound good? 2) Do you know of anything in Doc/ that shouldn't ship in 3.4.0? I know about the change to the build--3.4.1 won't auto-download Sphinx anymore. Is there anything else like that? David fixed not only Doc/*, but some entities in Misc/NEWS too. And may be he fixed some docstrings. None of this sounds release-critical at all. 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] Any non-3.4.0 docs in "default"?
Am 13.03.2014 17:50, schrieb Antoine Pitrou: > Le 13/03/2014 17:18, Serhiy Storchaka a écrit : >> 13.03.14 17:16, Larry Hastings написав(ла): >>> I'm strongly considering literally copying over all the content in Doc/ >>> from the default branch to the 3.4 branch. Not cherry-picking doc >>> changes, simply copying everything en masse. I have two questions for >>> the core devs. >>> >>> 1) Sound good? >>> >>> 2) Do you know of anything in Doc/ that shouldn't ship in 3.4.0? I know >>> about the change to the build--3.4.1 won't auto-download Sphinx >>> anymore. Is there anything else like that? There's a few follow-up changes to that. But as long as you restrict yourself to .rst files you will omit those. >> David fixed not only Doc/*, but some entities in Misc/NEWS too. And may >> be he fixed some docstrings. > > None of this sounds release-critical at all. Yep. 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] Whats New in 3.4 is pretty much done...
Am 13.03.2014 12:34, schrieb Stephen J. Turnbull: > Christian Heimes writes: > > > But I don't want it to sound like an advert... Suggestions? > > Not to worry. It *can't* be an advert -- it's all true, and there are > no irrelevant half-naked glistening bodies. (Former newts in the pond > don't count.) > > Seriously, while "expect a clean build" is not "news" for Python, it's > useful to state that we're at zero warnings nearly across the board, > including Coverity. Accompanied by an open invitation for reports to > the contrary, that's hardly like a commercial. I think Chris meant he'd sound like an ad for Coverity. 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] Any non-3.4.0 docs in "default"?
13.03.14 17:16, Larry Hastings написав(ла): I'm strongly considering literally copying over all the content in Doc/ from the default branch to the 3.4 branch. Not cherry-picking doc changes, simply copying everything en masse. I have two questions for the core devs. 1) Sound good? 2) Do you know of anything in Doc/ that shouldn't ship in 3.4.0? I know about the change to the build--3.4.1 won't auto-download Sphinx anymore. Is there anything else like that? d843a1caba78 adds aliases for cp273 codec and documents it. ea827c809765 updates pkgutil.find_loader() and documents this. b637064cc696 improves the pickling of enums and updates the documentation. dbf13a7d3987 adds debugging feasibility to asyncio and documents this. a63327162063 mangles __parameters in __annotations__ dict properly and mention this in whatsnews. d50a95fab002 adds a format() method to tracemalloc.Traceback and documents it. eef7899ea7ab makes Sphinx specific changes. 95de14f53cf5 makes asyncio.BaseEventLoop.sock_connect() to raise an error if the address is not resolved and document this. If this changesets are not in rc3, corresponding Doc/* changes should be reverted. ___ 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] Whats New in 3.4 is pretty much done...
On Thu, 13 Mar 2014 14:57:41 +0100 Victor Stinner wrote: > 2014-03-13 11:49 GMT+01:00 Christian Heimes : > > * All stdlib modules now support server cert verification including > > hostname matching and CRL. > > > > * http://bugs.python.org/issue16499 isolated mode is a security > > improvement, too. > > Ok, I added these two items. > > Antoine wrote: > > CRL? really? I don't remember us doing automatic CRL downloads. > > It's just the "support", nothing is automatic. I understood that you > *can* load CRL and ask for CRL validation, but it must be done > explicitly. There is a function to retrieve system CRLs on Windows. Then you should perhaps make your phrasing more explicit, because people may wrongly assume that CRL checking will be done automatically (IMHO). (especially since hostname checking, AFAIK, *is* automatic now) 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] Whats New in 3.4 is pretty much done...
Antoine Pitrou wrote on 03/13/2014 01:46:12 PM: > On Thu, 13 Mar 2014 14:57:41 +0100 > Victor Stinner wrote: > > 2014-03-13 11:49 GMT+01:00 Christian Heimes : > > > * All stdlib modules now support server cert verification including > > > hostname matching and CRL. > > > > > > * http://bugs.python.org/issue16499 isolated mode is a security > > > improvement, too. > > > > Ok, I added these two items. > > > > Antoine wrote: > > > CRL? really? I don't remember us doing automatic CRL downloads. > > > > It's just the "support", nothing is automatic. I understood that you > > *can* load CRL and ask for CRL validation, but it must be done > > explicitly. There is a function to retrieve system CRLs on Windows. > > Then you should perhaps make your phrasing more explicit, because > people may wrongly assume that CRL checking will be done automatically > (IMHO). > > (especially since hostname checking, AFAIK, *is* automatic now) Sorry if I'm out of line on my first post to this list, but I've been using the ssl module in 3.4 some lately (indeed, I have an open RFE on it for 3.5). While hostname checking can be done automatically, it's not the default (and if it will even work at all depends on the version of openssl installed). I suppose I could see it changed to read: * All stdlib modules now support server cert verification including hostname matching and CRL verification (but not automatic download). Of course, the reality is, using the ssl module requires a vary careful attention to detail, and probably always will. If a programmer is just going by the "What's New" section for security related code, I'm not sure there's much you can to to save them. ;p > > 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] Whats New in 3.4 is pretty much done...
On Thu, 13 Mar 2014 15:23:14 -0500, "Andrew M. Hettinger" wrote: > Antoine Pitrou wrote on 03/13/2014 01:46:12 PM: > > On Thu, 13 Mar 2014 14:57:41 +0100 > > Victor Stinner wrote: > > > 2014-03-13 11:49 GMT+01:00 Christian Heimes : > > > > * All stdlib modules now support server cert verification including > > > > hostname matching and CRL. > > > > > > > > * http://bugs.python.org/issue16499 isolated mode is a security > > > > improvement, too. > > > > > > Ok, I added these two items. > > > > > > Antoine wrote: > > > > CRL? really? I don't remember us doing automatic CRL downloads. > > > > > > It's just the "support", nothing is automatic. I understood that you > > > *can* load CRL and ask for CRL validation, but it must be done > > > explicitly. There is a function to retrieve system CRLs on Windows. > > > > Then you should perhaps make your phrasing more explicit, because > > people may wrongly assume that CRL checking will be done automatically > > (IMHO). > > > > (especially since hostname checking, AFAIK, *is* automatic now) > Sorry if I'm out of line on my first post to this list, but I've been using > the ssl module in 3.4 some lately (indeed, I have an open RFE on it for > 3.5). > > While hostname checking can be done automatically, it's not the default > (and if it will even work at all depends on the version of openssl > installed). > I suppose I could see it changed to read: > > * All stdlib modules now support server cert verification including > hostname matching and CRL verification (but not automatic download). > > Of course, the reality is, using the ssl module requires a vary careful > attention to detail, and probably always will. If a programmer is just > going by the "What's New" section for security related code, I'm not sure > there's much you can to to save them. ;p I opened issue 20913 to request that some sort of "best practices" documentation be added either to the SSL docs or as a separate chapter in the library reference. I do not feel competent to adjust the content of the security entries in whatsnew, so I have not. If someone wants to propose a patch or make an edit before Larry copies the files, please feel free. --David ___ 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] tracemallocqt: GUI to analyze tracemalloc snapshots
Hi,
To prepare my conference on tracemalloc for Pycon Montréal next month,
I wrote a GUI to analyze tracemalloc snapshots: "tracemallocqt".
https://bitbucket.org/haypo/tracemallocqt
It looks like that:
http://www.haypocalc.com/tmp/tracemallocqt_python34.png
I'm looking for testers and feedback on the GUI. You may be curious to
see which parts of Python is allocating the most memory, or maybe test
your favorite application to check if it leaks memory or how its
memory footprint can be reduced.
To run tracemallocqt, you have to install PySide and get tracemalloc
snapshots. It looks like most Linux distributions provide PySide
packages.
To take snapshots, see tracemalloc documentation:
http://docs.python.org/dev/library/tracemalloc.html
In short, use Python 3.4 with "-X tracemalloc=25" command line option
and then call:
---
import pickle, tracemalloc
snap = tracemalloc.take_snapshot()
with open("dump.pickle", "wb") as fp: pickle.dump(snap, fp, 2)
snap = None
---
It's more fun with at least 2 snapshots to compare them ;-)
I force pickle version 2 because tracemallocqt currently only works on
Python 2. (Mostly because I don't see how to get PySide for Python 3
on Fedora 20.)
Not all applications work on Python 3.4 right now, you can use the
pytracemalloc project which is tracemalloc for Python 2.5-3.3. Sorry,
you have to patch Python and recompile it. Here are instructions to
install a patched Python 2.7 with tracemalloc:
http://pytracemalloc.readthedocs.org/#manual-installation
If you don't want to take snapshot, you can compare these two files:
http://www.haypocalc.com/tmp/python34_start.pickle
http://www.haypocalc.com/tmp/python34_after_import.pickle
The source browser will not find Python source code, because the
snapshots contain absolute paths.
Victor
___
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] Whats New in 3.4 is pretty much done...
On 3/13/2014 7:34 AM, Stephen J. Turnbull wrote: Christian Heimes writes: > But I don't want it to sound like an advert... Suggestions? Not to worry. It *can't* be an advert -- it's all true, and there are no irrelevant half-naked glistening bodies. (Former newts in the pond don't count.) Seriously, while "expect a clean build" is not "news" for Python, It is for a Windows repository build. I just rebuilt: 3.3 gives lots of warning from multiple files; 3.4 none. Accompanied by an open invitation for reports to the contrary, that's hardly like a commercial. Now that no warnings is a serious goal for 3.4+, I will report them should they recur. -- 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] Whats New in 3.4 is pretty much done...
Georg Brandl writes: > I think Chris meant he'd sound like an ad for Coverity. Oh, that. IIRC, we pay them nothing for the service. I know that they do it in part for commercial reasons and that it undoubtedly doesn't cost them a lot, but nonetheless it is a benefit that wouldn't hurt for acknowledgment. As compared to other volunteer contributors, OK, maybe What's New is a bit prominent. But the real reason is that a clean Coverity sweep for software is like a Consumer Reports 5-star safety rating for automobiles. It's a a brand that signals quality, and an assessment independent of the developing organization. And like the 5-star rating, it cost effort (I gather much of it from Chris himself) to keep that clean bill of health from release to release. It may not be "new," exactly, but like the 5-star rating, I think our users want to know that it's renewed with each release. ___ 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] Whats New in 3.4 is pretty much done...
On Thu, Mar 13, 2014 at 8:29 PM, Terry Reedy wrote: > On 3/13/2014 7:34 AM, Stephen J. Turnbull wrote: >> >> Christian Heimes writes: >> >> > But I don't want it to sound like an advert... Suggestions? >> >> Not to worry. It *can't* be an advert -- it's all true, and there are >> no irrelevant half-naked glistening bodies. (Former newts in the pond >> don't count.) >> >> Seriously, while "expect a clean build" is not "news" for Python, > > > It is for a Windows repository build. I just rebuilt: 3.3 gives lots of > warning from multiple files; 3.4 none. > > >> Accompanied by an open invitation for reports to >> the contrary, that's hardly like a commercial. > > > Now that no warnings is a serious goal for 3.4+, I will report them should > they recur. If we're at no warnings, and no warnings is a serious goal, warnings should be errors. ___ 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 URLs
On 14 March 2014 00:10, Donald Stufft wrote: > AFAIK the www.python.org PEP stuff just isn't done yet, and the legacy > redirect is > a temporary stopgap. As Donald says, the official location hasn't changed, but the PEP repo based build process hasn't been integrated into the new site yet, so they're hitting the redirect to the legacy site. I opened https://github.com/python/pythondotorg/issues/297 to ask for an ETA on when we can expect them to be fully integrated. 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
