Re: [Python-Dev] PEP 454 (tracemalloc) close to pronouncement
I'm happy with the latest PEP because it is minimal but core features are still present: - get the traceback where an object was allocated, - get traces of memory blocks, - compute statistics on memory usage per line, file or traceback, - compute differences between two snapshots. We now have an object API to access low-level traces without killing performances. Temporary objects (read only views) are generated on demand. Generating concrete objects for each trace is really too slow because there are as many traces as memory blocks (500.000 memory blocks at the end of Python test suite for example). Victor Le lundi 11 novembre 2013, Charles-François Natali a écrit : > Hi, > > After several exchanges with Victor, PEP 454 has reached a status > which I consider ready for pronuncement [1]: so if you have any last > minute comment, now is the time! > > Cheers, > > cf > > > [1] http://www.python.org/dev/peps/pep-0454/ > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%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
[Python-Dev] Is pygettext.py deprecated?
I was looking at http://bugs.python.org/issue1098749, which adds extraction of multiple-line strings to pygettext.py, but on the ticket Mark Lawrence suggested that "pygettext should be deprecated". Is it deprecated? (It's not listed in PEP 4, but it isn't a module.) Debian wrote a man page for pygettext that starts with: pygettext is deprecated. The current version of xgettext supports many languages, including Python. GNU xgettext didn't understand any languages other than C at one time, so pygettext.py was written to handle Python code but not C code. But now xgettext will parse Python code. I assume xgettext's parsing is just using regexes, not an actual parse tree, so it may work equally well for Python 2.x and 3.x. Do we want to deprecate pygettext.py? If so, we should rewrite http://docs.python.org/3/library/gettext.html, which encourages people to use pygettext, and add it to PEP4. --amk ___ 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 454 (tracemalloc) close to pronouncement
2013/11/11 Charles-François Natali : > After several exchanges with Victor, PEP 454 has reached a status > which I consider ready for pronuncement [1]: so if you have any last > minute comment, now is the time! Because the PEP has a long history, 49 mercurial revisions between september and november 2013, I tried to summarize its history. Most important changes of the PEP 454 between initial versions and the current (final?) version: - tracemalloc can store a whole traceback instead of just the filename and line number of the most recent frame - tracemalloc is no more a high-level tool, but a core module exposing only one thing, traces on memory blocks, with a light Snapshot class to compute statistics. Tasks, DisplayTop class, command line interface and metrics have been removed. - many functions and features with no real use cases were removed. For example, get_trace(address) was taking a raw address, whereas such address is not directly accessible in Python. It was replaced with get_object_traceback(obj) which has a better API. - better API providing access to all data from traces to statistics. Raw traces are accessible via Snapshot.traces which generates temporary read-only view to get an object API. - minimalist API, ex: no more Snapshot.timestamp attribute - no more "premature optimizations". For example, statistics are no more computed during capture in C, but computed on a snapshot in Python. Charles-François did a great job to convert a high-level and specialized tool to a reusage and generic module. Thanks for all your advices! Without all these changes, it would be harder to extend tracemalloc later and to reuse tracemalloc for different use cases. 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
Re: [Python-Dev] Is pygettext.py deprecated?
On Nov 11, 2013, at 04:30 PM, A.M. Kuchling wrote: >Do we want to deprecate pygettext.py? If so, we should rewrite >http://docs.python.org/3/library/gettext.html, which encourages people >to use pygettext, and add it to PEP4. I think we should deprecate it. If we find things that xgettext can't handle that pygettext can, we should help to fix the former. -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
Re: [Python-Dev] Is pygettext.py deprecated?
On Nov 11, 2013, at 1:30 PM, A.M. Kuchling wrote: > I was looking at http://bugs.python.org/issue1098749, which adds > extraction of multiple-line strings to pygettext.py, but on the ticket > Mark Lawrence suggested that "pygettext should be deprecated". Is it > deprecated? (It's not listed in PEP 4, but it isn't a module.) > > Debian wrote a man page for pygettext that starts with: > > pygettext is deprecated. The current version of xgettext > supports many languages, including Python. > > GNU xgettext didn't understand any languages other than C at one time, > so pygettext.py was written to handle Python code but not C code. But > now xgettext will parse Python code. I assume xgettext's > parsing is just using regexes, not an actual parse tree, so it may > work equally well for Python 2.x and 3.x. > > Do we want to deprecate pygettext.py? If so, we should rewrite > http://docs.python.org/3/library/gettext.html, which encourages people > to use pygettext, and add it to PEP4. +1 on deprecating it, though I'd prefer to recommend the pure python Babel instead of xgettext. Babel can extract gettext messages from Python code and also has has plugins for extracting from various popular Python templating languages. It's also easier to setup against Python projects using distutils/setuptools. -- Philip Jenvey ___ 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] Is pygettext.py deprecated?
Quoting "A.M. Kuchling" : GNU xgettext didn't understand any languages other than C at one time, so pygettext.py was written to handle Python code but not C code. That's not the only reason. Another two reasons are that a) it works on Windows (for xgettext, you'll have to install Cygwin, which some consider a bit heavy - if all you need is xgettext) b) it comes with Python (interesting on Unix systems that don't come with a pre-built xgettext; less relevant now as most Unix systems are Linux these days) I see no real harm done by keeping (and possibly fixing) pygettext. I also see little harm in removing it, although I guess that some people might still rely on it. Regards, Martin ___ 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] Assign(expr* targets, expr value) - why targetS?
On Sun, Nov 10, 2013 at 8:34 AM, Benjamin Peterson wrote: > 2013/11/10 anatoly techtonik : >> http://hg.python.org/cpython/file/1ee45eb6aab9/Parser/Python.asdl >> >> In Assign(expr* targets, expr value), why the first argument is a list? > > x = y = 42 Thanks. Speaking of this ASDL. `expr* targets` means that multiple entities of `expr` under the name 'targets' can be passed to Assign statement. Assign uses them as left value. But `expr` definition contains things that can not be used as left side assignment targets: expr = BoolOp(boolop op, expr* values) | BinOp(expr left, operator op, expr right) ... | Str(string s) -- need to specify raw, unicode, etc? | Bytes(bytes s) | NameConstant(singleton value) | Ellipsis -- the following expression can appear in assignment context | Attribute(expr value, identifier attr, expr_context ctx) | Subscript(expr value, slice slice, expr_context ctx) | Starred(expr value, expr_context ctx) | Name(identifier id, expr_context ctx) | List(expr* elts, expr_context ctx) | Tuple(expr* elts, expr_context ctx) If I understand correctly, this is compiled into C struct definitions (Python-ast.c), and there is a code to traverse the structure, but where is code that validates that the structure is correct? Is it done on the first level - text file parsing, before ASDL is built? If so, then what is the role of this ADSL exactly that the first step is unable to solve? Is it possible to fix ADSL to move `expr` that are allowed in Assign into `expr` subset? What effect will it achieve? I mean - will ADSL compiler complain about wrong stuff on the left side, or it will still be a role of some other component. Which one? ___ 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] [RELEASED] Python 3.3.3 release candidate 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm quite happy to announce the Python 3.3.3 release candidate 2. Python 3.3.3 includes several security fixes and over 150 bug fixes compared to the Python 3.3.2 release. This release fully supports OS X 10.9 Mavericks. In particular, this release fixes an issue that could cause previous versions of Python to crash when typing in interactive mode on OS X 10.9. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in the 3.3 series, see http://docs.python.org/3.3/whatsnew/3.3.html To download Python 3.3.3 rc2 visit: http://www.python.org/download/releases/3.3.3/ This is a preview release, please report any bugs to http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlKB1G4ACgkQN9GcIYhpnLAu5gCfRkfpnEs+rmtZ9iTjaaZcHDx3 sNYAn180Q4cFZmKtwJdaG+g/3jHAVd97 =n/Tt -END 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] Assign(expr* targets, expr value) - why targetS?
anatoly techtonik wrote: where is code that validates that the structure is correct? Is it done on the first level - text file parsing, before ASDL is built? If so, then what is the role of this ADSL exactly that the first step is unable to solve? I think it's done by the code that traverses the AST and generates bytecode. It complains if it comes across something that it doesn't know how to generate assignment code for. The reason it's done this way is that Python's LL parser can't see far enough ahead to know that it's processing an assignment until it has parsed the whole LHS and gets to the '='. Up to that point, it could well be just something to be evaluated, so it has to accept a general expression. I suppose a validation step could be performed before putting it into the AST, but there's no point, because the problem will become obvious during code generation anyway. -- Greg ___ 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
