Am 13.12.2012 18:09, schrieb andrew.svetlov:
> changeset: 80840:9347869d1066
> user: Andrew Svetlov <andrew.svetlov(a)gmail.com>
> date: Thu Dec 13 19:09:33 2012 +0200
> Issue #16049: add abc.ABC helper class.
> Patch by Bruno Dupuis.
> Doc/library/abc.rst | 18 ++++++++++++++----
> Lib/abc.py | 6 ++++++
> Lib/test/test_abc.py | 13 +++++++++++++
> Misc/NEWS | 3 +++
> 4 files changed, 36 insertions(+), 4 deletions(-)
> diff --git a/Doc/library/abc.rst b/Doc/library/abc.rst
> --- a/Doc/library/abc.rst
> +++ b/Doc/library/abc.rst
> @@ -12,9 +12,9 @@
> This module provides the infrastructure for defining :term:`abstract base
> -classes <abstract base class>` (ABCs) in Python, as outlined in :pep:`3119`; see the PEP for why this
> -was added to Python. (See also :pep:`3141` and the :mod:`numbers` module
> -regarding a type hierarchy for numbers based on ABCs.)
> +classes <abstract base class>` (ABCs) in Python, as outlined in :pep:`3119`;
> +see the PEP for why this was added to Python. (See also :pep:`3141` and the
> +:mod:`numbers` module regarding a type hierarchy for numbers based on ABCs.)
> The :mod:`collections` module has some concrete classes that derive from
> ABCs; these can, of course, be further derived. In addition the
> @@ -23,7 +23,7 @@
> hashable or a mapping.
> -This module provides the following class:
> +This module provides the following classes:
> .. class:: ABCMeta
> @@ -127,6 +127,16 @@
> available as a method of ``Foo``, so it is provided separately.
> +.. class:: ABC
> + A helper class that has :class:`ABCMeta` as metaclass. :class:`ABC` is the
> + standard class to inherit from in order to create an abstract base class,
> + avoiding sometimes confusing metaclass usage.
> + Note that :class:`ABC` type is still :class:`ABCMeta`, therefore inheriting
> + from :class:`ABC` requires usual precautions regarding metaclasses usage
> + as multiple inheritance may lead to metaclass conflicts.
Needs a versionadded.
I wonder if is it worth/if there is any interest in trying to "clean" up
distutils: nothing in terms to add new features, just a *major* cleanup
retaining the exact same interface.
I'm not planning anything like *adding features* or rewriting
rpm/rpmbuild here, simply cleaning up that un-holy code mess. Yes it
served well, don't get me wrong, and I think it did work much better
than anything it was meant to replace it.
I'm not into the py3 at all so I wonder how possibly it could
fit/collide into the big plan.
Or I'll be wasting my time?
The default version shown on http://docs.python.org/ is now 3.3.0,
which I think is a Good Thing. However, http://python.org/download/
puts 2.7 first, and says:
"""If you don't know which version to use, start with Python 2.7; more
existing third party software is compatible with Python 2 than Python
3 right now."""
Firstly, is this still true? (I wouldn't have a clue.) And secondly,
would this be better worded as "one's better but the other's a good
fall-back"? Something like:
"""Don't know which version to use? Python 3.3 is the recommended
version for new projects, but much existing software is compatible
with Python 2."""
I only ever send people there to learn about programming, not to get a
dependency for an existing codebase, so I don't know what is actually
On Tue, 11 Dec 2012 03:05:19 +0100 (CET)
gregory.p.smith <python-checkins(a)python.org> wrote:
> Using 'long double' to force this structure to be worst case aligned is no
> longer required as of Python 2.5+ when the gc_refs changed from an int (4
> bytes) to a Py_ssize_t (8 bytes) as the minimum size is 16 bytes.
> The use of a 'long double' triggered a warning by Clang trunk's
> Undefined-Behavior Sanitizer as on many platforms a long double requires
> 16-byte alignment but the Python memory allocator only guarantees 8 byte
> So our code would allocate and use these structures with technically improper
> alignment. Though it didn't matter since the 'dummy' field is never used.
> This silences that warning.
> Spelunking into code history, the double was added in 2001 to force better
> alignment on some platforms and changed to a long double in 2002 to appease
> Tru64. That issue should no loner be present since the upgrade from int to
> Py_ssize_t where the minimum structure size increased to 16 (unless anyone
> knows of a platform where ssize_t is 4 bytes?)
What?? Every 32-bit platform has a 4 bytes ssize_t (and size_t).
> We can probably get rid of the double and this union hack all together today.
> That is a slightly more invasive change that can be left for later.
How do you suggest to get rid of it? Some platforms still have strict
alignment rules and we must enforce that PyObjects (*) are always
aligned to the largest possible alignment, since a PyObject-derived
struct can hold arbitrary C types.
(*) GC-enabled PyObjects, anyway. Others will be naturally aligned
thanks to the memory allocator.
What's more, I think you shouldn't be doing this kind of change in a
bugfix release. It might break compiled C extensions since you are
changing some characteristics of object layout (although you would
probably only break those extensions which access the GC header, which
is probably not many of them). Resource consumption improvements
generally go only into the next feature release.
Hark fellow Emacsers. All you unenlightened heathens can stop reading now.
A few years ago, my colleague Jono Lange wrote probably the best little chunk
of Emacs lisp ever. `M-x bzr-tools-grep` lets you easily search a Bazaar
repository for a case-sensitive string, providing you with a nice *grep*
buffer which you can scroll through. When you find a code sample you want to
look at, C-c C-c visits the file and plops you right at the matching line.
You *only* grep through files under version control, so you get to ignore
generated files, and compilation artifacts, etc.
Of course, this doesn't help you for working on the Python code base, because
Mercurial. I finally whipped up this straight up rip of Jono's code to work
with hg. I'm actually embarrassed to put a copyright on this thing, and would
happily just donate it to Jono, drop it in Python's Misc directory, or slip it
like a lump of coal into the xmas stocking of whoever wants to "maintain" it
for the next 20 years.
But anyway, it's already proven enormously helpful to me, so here it is.
P.S. Who wants to abuse Jono and Matthew's copyright again and provide a
<shudder> git version?
;; Copyright (c) 2012 Barry A. Warsaw
;; Permission is hereby granted, free of charge, to any person obtaining
;; a copy of this software and associated documentation files (the
;; "Software"), to deal in the Software without restriction, including
;; without limitation the rights to use, copy, modify, merge, publish,
;; distribute, sublicense, and/or sell copies of the Software, and to
;; permit persons to whom the Software is furnished to do so, subject to
;; the following conditions:
;; The above copyright notice and this permission notice shall be
;; included in all copies or substantial portions of the Software.
;; THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
;; EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
;; MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
;; NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
;; LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
;; OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
;; WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
;; This code is based on bzr-tools.el
;; Copyright (c) 2008-2009 Jonathan Lange, Matthew Lefkowitz
"hg locate --print0 | xargs -0 grep -In %s"
"The command used for grepping files using hg. See `hg-tools-grep'.")
;; Run 'code' at the root of the branch which dirname is in.
(defmacro hg-tools-at-branch-root (dirname &rest code)
`(let ((default-directory (locate-dominating-file (expand-file-name ,dirname) ".hg"))) ,@code))
(defun hg-tools-grep (expression dirname)
"Search a branch for `expression'. If there's a C-u prefix, prompt for `dirname'."
(let* ((string (read-string "Search for: "))
(dir (if (null current-prefix-arg)
(read-directory-name (format "Search for %s in: " string)))))
(list string dir)))
(grep-find (format hg-tools-grep-command (shell-quote-argument expression)))))
The current CPython bytecode interpreter is rather more complex than it
needs to be. A number of bytecodes could be eliminated and a few more
simplified by moving the work involved in handling compound statements
(loops, try-blocks, etc) from the interpreter to the compiler.
This simplest example of this is the while loop...
This currently compiled as
if not cond goto end
but it could be compiled as
if cond goto start
which eliminates one instruction per iteration.
A more complex example is a return in a try-finally block.
Currently, handling the return is complex and involves "pseudo
exceptions", but if part3 were duplicated by the compiler, then the
RETURN bytecode could just perform a simple return.
The code above would be compiled thus...
if not X goto endif
part3 <<< duplicated
part3 <<< duplicated
The changes I am proposing are:
Allow negative line deltas in the lnotab array (bytecode deltas would
Remove the SETUP_LOOP, BREAK and CONTINUE bytecodes
Simplify the RETURN bytecode
Eliminate "pseudo exceptions" from the interpreter
Simplify (or perhaps eliminate) SETUP_TRY, END_FINALLY, END_WITH.
Reverse the sense of the FOR_ITER bytecode (ie. jump on not-exhausted)
The net effect of these changes would be:
Reduced code size and reduced code complexity.
A small (1-5%)? increase in speed, due the simplification of the
bytecodes and a very small change in the number of bytecodes executed.
A small change in the static size of the bytecodes (-2% to +2%)?
Although this is a quite intrusive change, I think it is worthwhile as
it simplifies ceval.c considerably.
The interpreter has become rather convoluted and any simplification has
to be a good thing.
I've already implemented negative line deltas and the transformed while
I'm currently working on the block unwinding.
Good idea? Bad idea?
Should I write a PEP or is the bug tracker sufficient?