I am out of the office until 06/06/2012.
I will be out of the office Monday and Tuesday, June 4-5. I expect to have
some email access but may be delayed in responding.
Note: This is an automated response to your message "Python-Dev Digest,
Vol 107, Issue 9" sent on 06/04/2012 0:19:23.
This is the only notification you will receive while this person is away.
Are these dead in the water or are we going to try to change our release
cycle? I'm just asking since 3.3 final is due out in about 3 months and
deciding on this along with shifting things if we do make a change could
end up taking that long and I suspect if we don't do this for 3.3 we are
probably never going to do it for Python 3 series as a whole.
On 03/15/2012 03:02 PM, Lindberg, Van wrote:
> FYI, the location of the tcl/tk libraries does not appear to be set in
> the virtualenv, even if tkinter is installed and working in the main
> Python installation. As a result, tk-based apps will not run from a
> virtualenv.
Thanks for the report! I've added this to the list of open issues in the
PEP and I'll look into it.
Carl
Hi
I was reading a bit about the regex module and I would like to present some
other solution into speeding up the re module for Python.
So, as a bit of background - pypy has a re compatible module. It's also
JITted and it's also exportable as a C library (that is a library you can
call from C with C API, not a python extension module). I wonder if it
would be worth to put some work into it to make it a library that CPython
can use.
On the minus side, the JIT only works on x86 and x86_64, on the plus side,
since it's 100% API compatible, it can be used as a _xxx speedup module
relatively easy.
Do people have opinions?
Cheers,
fijal
It seems that by moving to VS 2010, we have killed Windows 2000 support,
for the same reason VS 2012 would kill XP support: Windows 2000
apparently won't recognize the .exe files as executables anymore.
I haven't actually tested this: can somebody please confirm?
A year ago, Brian put a statement into PEP 11 that 3.3 would support
Windows 2000 still, but with a warning. Under my recent PEP change,
Windows 2000 does not need to be supported anymore since 13.07.2010,
when Microsoft's extended support expired.
So I propose to just remove the claim from the PEP that 3.3 would
still be supported, and not go through any notification period.
Objections?
As a consequence, we could then change some of the deferred-loading
stuff for "new" (i.e. XP+) API into proper linking.
Regards,
Martin
Like Python? Like Italy? Like meetings? Then I've got a treat for you!
I'll be chairing a Python Language Summit this July in historic
Florence, Italy. It'll be on July 1st (the day before EuroPython
starts) at the Grand Hotel Mediterraneo conference center. Language
Summits are when the Python core contributors step away from their
computers and get together for a day to argue in person.
Email me if you're interested in attending; I can send you the final
details and simultaneously get a rough headcount.
Volunteers to take notes are greatly appreciated,
//arry/
Hi,
When setting a trace function with settrace, the trace function when called
with a new scope can return another trace function or None, indicating the
inner scope should not be traced.
I used settrace for some time but calling the trace function for every line
of code is a performance killer.
So I moved on to setprofile, which calls a trace function every function
entry/exit. now here's the problem: the return value from the trace
function is ignored (intentionally), denying the possibility to skip
tracing of 'hot' or 'not interesting' code.
I would like to propose two alternatives:
1. setprofile will not ignore the return value and mimic settrace's
behavior.
2. setprofile is just a wrapper around settrace that limits
it's functionality, lets make settrace more flexible so setprofile will be
redundant. here's how: settrace will recieve an argument called 'events',
the trace function will fire only on events contained in that list. for
example: setprofile = partial(settrace, events=['call', 'return'])
I personally prefer the second.
Some context to this issue:
I'm building a python tracer - a logger that records each and every
function call. In order for it to run in production systems, the overhead
should be minimal. I would like to allow the user to say which
function/module/classes to trace or skip, for example: the user will skip
all math/cpu intensive operations. another example: the user will want to
trace his django app code but not the django framework.
your thoughts?
Thanks, Alon Horev
The implementation for sys.implementation is going to use a new (but
"private") type[1]. It's basically equivalent to the following:
class namespace:
def __init__(self, **kwargs):
self.__dict__.update(kwargs)
def __repr__(self):
keys = (k for k in self.__dict__ if not k.startswith('_'))
pairs = ("{}={!r}".format(k, self.__dict__[k]) for k in sorted(keys))
return "{}({})".format(type(self).__name__, ", ".join(pairs))
There were other options for the type, but the new type was the best
fit and not hard to do. Neither the type nor its API is directly
exposed publicly, but it is still accessible through
"type(sys.implementation)".
This brings me to a couple of questions:
1. should we make the new type un-instantiable (null out tp_new and tp_init)?
2. would it be feasible to officially add the type (or something like
it) in 3.3 or 3.4?
I've had quite a bit of positive feedback on the type (otherwise I
wouldn't bother bringing it up). But, if we don't add a type like
this to Python, I'd rather close the loophole and call it good (i.e.
*not* introduce a new type by stealth). My preference is for the type
(or equivalent) to be blessed in the language. Regardless of the
specific details of such a type, my more immediate concern is with the
impact on sys.implementation of python-dev's general sentiment in this
space.
-eric
[1] http://bugs.python.org/issue14673
I have just codified our current policy on supporting
Windows releases, namely that we only support some Windows
version until Microsoft ends its extended support period.
As a consequence, Windows XP will be supported until
08/04/2014, and Windows 7 until 14/01/2020 (unless Microsoft
extends that date further).
I have also added wording on Visual Studio support which may
still require consensus. My proposed policy is this:
1. There is only one VS version supported for any feature release.
Because of the different branches, multiple versions may be
in use.
2. The version that we use for a new feature release must still
have mainstream support (meaning it can still be purchased
regularly).
3. We should strive to keep the number of VS versions used
simultaneously small.
VS 2008 has mainstream support until 09/04/2013, so we could have
used it for 3.3 still, however, mainstream support ends within the
likely lifetime of 3.3, so switching to VS 2010 was better. VS 2010
will have mainstream support until 14/07/2015, so we can likely
use it for 3.4 as well, and only reconsider for 3.5 (at which point XP
support will not be an issue anymore). VS 2012 is out for 3.4 as it
doesn't support XP.
Regards,
Martin
