patch

ctypes/utils.py problem

Hi everyone,

I'm working with the LTTng (Linux Tracing) team and we came across a problem
with our user-space tracer and Python default behavior. We provide a libc
wrapper that instrument free() and malloc() with a simple ld_preload of that lib.

This lib *was* named "liblttng-ust-libc.so" and we came across python software
registering to our trace registry daemon (meaning that somehow the python binary
is using our in-process library). We dig a bit and found this:

Lib/ctypes/utils.py:

def _findLib_ldconfig(name):
	# XXX assuming GLIBC's ldconfig (with option -p)
        expr = r'/[^\(\)\s]*lib%s\.[^\(\)\s]*' % re.escape(name)
        res = re.search(expr,
                        os.popen('/sbin/ldconfig -p 2>/dev/null').read())

and, at least, also found in _findLib_gcc(name) and _findSoname_ldconfig(name).

This cause Python to use any library ending with "libc.so" to be loaded....

I don't know the reasons behind this but we are concerned about "future issues"
that can occur with this kind of behavior.

For now, we renamed our lib so everything is fine.

Thanks a lot guys.
David

PEP for new dictionary implementation

Proposed PEP for new dictionary implementation, PEP 410?
is attached.

Cheers,
Mark.

PEP: XXX
Title: Key-Sharing Dictionary
Version: $Revision$
Last-Modified: $Date$
Author: Mark Shannon <mark <at> hotpy.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 08-Feb-2012
Python-Version: 3.3 or 3.4
Post-History: 08-Feb-2012

Abstract
========

This PEP proposes a change in the implementation of the builtin dictionary
type ``dict``. The new implementation allows dictionaries which are used as
attribute dictionaries (the ``__dict__`` attribute of an object) to share
keys with other attribute dictionaries of instances of the same class.

Motivation
==========

Code review tool uses my old email address

Hi,

I changed my email address (about a year ago) and updated my bug tracker 
settings to my new address (late last year).
However, the code review tool still shows my old email address.
How do I change it?

Cheers,
Mark.

folding cElementTree behind ElementTree in 3.3

Hello,

Here's a note from "What's new in Python 3.0":

"""A common pattern in Python 2.x is to have one version of a module
implemented in pure Python, with an optional accelerated version
implemented as a C extension; for example, pickle and cPickle. This
places the burden of importing the accelerated version and falling
back on the pure Python version on each user of these modules. In
Python 3.0, the accelerated versions are considered implementation
details of the pure Python versions. Users should always import the
standard version, which attempts to import the accelerated version and
falls back to the pure Python version. The pickle / cPickle pair
received this treatment. The profile module is on the list for 3.1.
The StringIO module has been turned into a class in the io module."""

Is there a good reason why xml.etree.ElementTree /
xml.etree.cElementTree did not "receive this treatment"?

In the case of this module, it's quite unfortunate because:

1. The accelerated module is much faster and memory efficient (see
recent benchmarks here: http://bugs.python.org/issue11379), and XML
processing is an area where processing matters
2. The accelerated module implements the same API
3. It's very hard to even find out about the existence of the
accelerated module. Its sole mention in the docs is this un-emphasized
line in http://docs.python.org/dev/py3k/library/xml.etree.elementtree.html:

"A C implementation of this API is available as xml.etree.cElementTree."

Add a new "locale" codec?

Hi,

I added PyUnicode_DecodeLocale(), PyUnicode_DecodeLocaleAndSize() and
PyUnicode_EncodeLocale() to Python 3.3 to fix bugs. I hesitate to
expose this codec in Python: it can be useful is some cases,
especially if you need to interact with C functions.

The glib library has functions using the *current* locale encoding,
g_locale_from_utf8() for example.

Related issue with more information:
http://bugs.python.org/issue13619

Victor

Re: which C language standard CPython must conform to

On Tue, Feb 7, 2012 at 1:41 PM, "Martin v. Löwis" <martin <at> v.loewis.de> wrote:
> Am 07.02.2012 20:10, schrieb Gregory P. Smith:
>> Why do we still care about C89?  It is 2012 and we're talking about
>> Python 3.  What compiler on what platform that anyone actually cares
>> about does not support C99?
>
> As Amaury says: Visual Studio still doesn't support C99. The story is
> both funny and sad: In Visual Studio 2002, the release notes included
> a comment that they couldn't consider C99 (in 2002), because of lack of
> time, and the standard came so quickly. In 2003, they kept this notice.
> In VS 2005 (IIRC), they said that there is too little customer demand
> for C99 so that they didn't implement it; they recommended to use C++
> or C#, anyway. Now C2011 has been published.

Thanks!  I've probably asked this question before.  Maybe I'll learn
this time. ;)

Some quick searching shows that there is at least hope Microsoft is on
board with C++11x (not so surprising, their crown jewels are written
in C++).  We should at some point demand a C++ compiler for CPython
and pick of subset of C++ features to allow use of but that is likely
reserved for the Python 4 timeframe (a topic for another thread and
time entirely, it isn't feasible for today's codebase).

In that timeframe another alternative Question may make sense to ask:
Do we need a single unified all-platform-from-one-codebase python
interpreter?

If we can get other VM implementations up to date language feature
wise and manage to sufficiently decouple standard library development

requirements for moving __import__ over to importlib?

[Python-ideas] matrix operations on dict :)

need help with frozen module/marshal/gc issue involving sub-interpreters for importlib bootstrapping

Volunteer

You may remember me from a couple of years ago when I was trying to help 
out with Python.  Unfortunately I trod on a few toes.  I now know why. 
I have been diagnosed with Asperger Syndrome at 55 years old.
I would like to give it another go.
--

-- 
Cheers.

Mark Lawrence.