[Python-Dev] PEP 454: tracemalloc (n-th version)
"n-th version": Sorry, I don't remember the version number of the PEP :-)
http://www.python.org/dev/peps/pep-0454/
Lastest changes:
* rename disable/enable/is_enabled() to stop/start/is_tracing()
* Snapshot.apply_filters() now returns a new Snapshot instance
* a traceback now always contains a least 1 frame, use (('', 0),) if
the traceback cannot read or if the traceback limit is 0
* Rename Filter.traceback to Filter.all_frames
* write more documentation on filter functions
Charles-François doesn't look convinced that disabling temporarily
tracing is useful, me neither. Another concern is that it is not
possible to disable completly tracing, only disable tracing new
allocations, deallocations are still tracing. I chose a simpler API
with limitations.
The PEP is not *completly* different than my first proposition. Even
if the latest PEP has fewer functions and classes, it's almost as
powerful. I replaced complex classes and high-level API with short
examples in the documentation:
http://www.haypocalc.com/tmp/tracemalloc/library/tracemalloc.html#examples
For the implementation of tracemalloc, see:
http://bugs.python.org/issue18874
Rietveld link to the latest patch:
http://bugs.python.org/review/18874/#ps9797
Victor
___
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] python2 and python3 and vim
I came across this in the VIM documentation: Vim can be built in four ways (:version output): 1. No Python support(-python, -python3) 2. Python 2 support only(+python or +python/dyn, -python3) 3. Python 3 support only(-python, +python3 or +python3/dyn) 4. Python 2 and 3 support (+python/dyn, +python3/dyn) Some more details on the special case 4: When Python 2 and Python 3 are both supported they must be loaded dynamically. When doing this on Linux/Unix systems and importing global symbols, this leads to a crash when the second Python version is used. So either global symbols are loaded but only one Python version is activated, or no global symbols are loaded. The latter makes Python's "import" fail on libraries that expect the symbols to be provided by Vim. I've never played with embedding Python. Does this make sense to anyone who has? Is there some limitation in our embedding and/or import machinery here, or is this more likely to be a shortcoming on the VIM side? Mostly I'm asking out of curiosity in hopes of learning something; I doubt I'll have enough motivation to make time to work on solving this. --David ___ 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] python2 and python3 and vim
On Sun, Nov 3, 2013 at 8:59 AM, R. David Murray wrote: > I came across this in the VIM documentation: > > Vim can be built in four ways (:version output): > 1. No Python support(-python, -python3) > 2. Python 2 support only(+python or +python/dyn, -python3) > 3. Python 3 support only(-python, +python3 or +python3/dyn) > 4. Python 2 and 3 support (+python/dyn, +python3/dyn) > > Some more details on the special case 4: > > When Python 2 and Python 3 are both supported they must be loaded > dynamically. > > When doing this on Linux/Unix systems and importing global symbols, > this leads > to a crash when the second Python version is used. So either global > symbols > are loaded but only one Python version is activated, or no global > symbols are > loaded. The latter makes Python's "import" fail on libraries that > expect the > symbols to be provided by Vim. > > I've never played with embedding Python. Does this make sense to > anyone who has? Is there some limitation in our embedding and/or > import machinery here, or is this more likely to be a shortcoming on > the VIM side? > > Mostly I'm asking out of curiosity in hopes of learning something; > I doubt I'll have enough motivation to make time to work on solving this. > I'm not used to it being possible to have multiple different embedded Python interpreters in one process at all. The Python C API symbols exported by one python interpreter will conflict with another python interpreter. We don't provide isolation of interpreters within a process. IIRC, if you do have multiple even of the same version within a single process they are still all sharing the same python memory allocator pools and GIL and more. That someone even went through the hoops to attempt to get vim to allow having some semblance of both python 2 and python 3 embedded dynamically at runtime seems like overkill to me. Pick one and go with it. Vim should declare at some point in 2014 that the embedded Python in vim is now Python 3 only and move on. The rare users who actually use the embedded bazillion scripting languages within vim will need to update their code, ideally to be 2 and 3 compatible. -gps ___ 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] python2 and python3 and vim
On 4 Nov 2013 03:00, "R. David Murray" wrote: > > I came across this in the VIM documentation: > > Vim can be built in four ways (:version output): > 1. No Python support(-python, -python3) > 2. Python 2 support only(+python or +python/dyn, -python3) > 3. Python 3 support only(-python, +python3 or +python3/dyn) > 4. Python 2 and 3 support (+python/dyn, +python3/dyn) > > Some more details on the special case 4: > > When Python 2 and Python 3 are both supported they must be loaded dynamically. > > When doing this on Linux/Unix systems and importing global symbols, this leads > to a crash when the second Python version is used. So either global symbols > are loaded but only one Python version is activated, or no global symbols are > loaded. The latter makes Python's "import" fail on libraries that expect the > symbols to be provided by Vim. > > I've never played with embedding Python. Does this make sense to > anyone who has? Is there some limitation in our embedding and/or > import machinery here, or is this more likely to be a shortcoming on > the VIM side? > > Mostly I'm asking out of curiosity in hopes of learning something; > I doubt I'll have enough motivation to make time to work on solving this. Essentially what Greg said - we export many of the same symbols from both shared libraries, so if you try to load both CPython 2 and 3 into one process, the dynamic linker isn't going to be happy about it at all. Since making it work would be a lot of work for minimal benefit, the most that could realistically be done is to make it fail a little more gracefully (I believe that would need to be done on the Vim side of things, though). Cheers, Nick. > > --David > ___ > 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] python2 and python3 and vim
On Nov 04, 2013, at 08:04 AM, Nick Coghlan wrote: >Since making it work would be a lot of work for minimal benefit, the most >that could realistically be done is to make it fail a little more >gracefully (I believe that would need to be done on the Vim side of things, >though). Right. I can't remember the details, but I've seen similar types of dual-plugin support in other applications. Generally it means you can *either* import Python 2 code or Python 3 code in a single process, but once you've fired up the first runtime, the application will prevent you from firing up the other. So yes, I think Vim would have to put that guard in, and I agree that there's not much benefit in trying to make this work in Python. -Barry ___ 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] Problem installing matplotlib 1.3.1 with Python 2.7.6 and 3.3.3 (release candidate 1)
Hello, I tried to install matplotlib 1.3.1 on the release candidates of Python 2.7.6 and 3.3.3. I am on Mac OS X 10.6.8. Although the installation gave no problems, there is a problem with Tcl/Tk. The new Pythons have their own embedded Tcl/Tk, but when installing matplotlib it links to the Frameworks version of Tcl and TK, not to the embedded version. This causes confusion when importing matplotlib.pyplot: objc[70648]: Class TKApplication is implemented in both /Library/Frameworks/Python.framework/Versions/2.7/lib/libtk8.5.dylib and /Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined. objc[70648]: Class TKMenu is implemented in both /Library/Frameworks/Python.framework/Versions/2.7/lib/libtk8.5.dylib and /Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined. objc[70648]: Class TKContentView is implemented in both /Library/Frameworks/Python.framework/Versions/2.7/lib/libtk8.5.dylib and /Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined. objc[70648]: Class TKWindow is implemented in both /Library/Frameworks/Python.framework/Versions/2.7/lib/libtk8.5.dylib and /Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined. And then later it gives a lot of error messages. So I think it should be linked to the embedded version. For this the matplotlib setupext.py should be adapted to find out if there is an embedded Tcl/Tk in the Python installation and set the link parameters accordingly. However, the installed Python versions (from the DMG's) do not contain the Tcl/Tk header files, only the shared library and the tcl files. So I thing the distributed Python should also include the Tcl/Tk header files. -- Piet van Oostrum WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4] ___ 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 (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run
On Sun, Nov 3, 2013 at 10:54 PM, Terry Reedy wrote: > On 11/3/2013 11:48 PM, terry.reedy wrote: >> >> http://hg.python.org/cpython/rev/cced7981ec4d >> changeset: 86908:cced7981ec4d >> branch: 2.7 >> user:Terry Jan Reedy >> date:Sun Nov 03 23:37:54 2013 -0500 >> summary: >>Issue #X: Fix test_idle so that idlelib test cases are actually run >> under test.regrtest on 2.7. > > > This message is the one included with the patch by Ned Daily. Because a > message *was* included (not normal), hg import committed the patch > immediately, without giving me a chance to edit the patch or message. As far > as I know, there is no way I could have edited the message after the commit. > If there was, let me know. hg commit has an "--amend" option that allows you to change the last (un-pushed) commit. Even if there aren't actually any changes to be committed, it will pop up a text editor with the commit message of the last commit already filled in, allowing you to change the message. Any time you `hg commit --amend`, it saves the original commit locally as a bundle in the .hg dir, so you can restore it if need be. I haven't tested it, but from a quick look at TortoiseHg Workbench's Commit screen, it looks like --amend can be done from the down arrow on the commit button, "Amend current revision". -- Zach ___ 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 (2.7): Issue #XXXXX: Fix test_idle so that idlelib test cases are actually run
On Sun, Nov 3, 2013 at 8:54 PM, Terry Reedy wrote: > On 11/3/2013 11:48 PM, terry.reedy wrote: >> >> http://hg.python.org/cpython/rev/cced7981ec4d >> changeset: 86908:cced7981ec4d >> branch: 2.7 >> user:Terry Jan Reedy >> date:Sun Nov 03 23:37:54 2013 -0500 >> summary: >>Issue #X: Fix test_idle so that idlelib test cases are actually run >> under test.regrtest on 2.7. > > > This message is the one included with the patch by Ned Daily. Because a > message *was* included (not normal), hg import committed the patch > immediately, without giving me a chance to edit the patch or message. As far > as I know, there is no way I could have edited the message after the commit. > If there was, let me know. Besides what Zach mentions, most of the time you probably want to "hg import --no-commit ", run it, test it, then commit it with whatever message you want. ___ 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
