As this is my first post I will try to introduce myself as requested in
the welcome email. If you aren't interested in my person, just continue
reading at the next paragraph. I'm a student from Vienna/Austria. I
attend what would match high school in the United States. I have been
writing Python for about 3 years now and have just began to dig into the
implementation of CPython.
Now to my real question. I have noticed that PyThread_acquire_lock
swallows all signals with pthread using sems. Looking at the source code
it appears that this is intended, but I cannot see the reason for that.
It seems the pthread sem implementation is the only one doing so. Can
any of you tell me the reason why it swallows signals?
I have already prepared a patch that introduces a new _noswallow
function if sem are used and uses this in threadmodule.c. But if there
isn't any real reason for it to swallow exceptions, I think it would be
wisest to change that.
Exception for setting attributes of built-in type differs between
CPython and IronPython. This is not purely theoretical, as
zope.interface tries to set Implements declaration as __implemented__
attribute of built-in type object, and excepts TypeError.
>>> object.flag = True
TypeError: can't set attributes of built-in/extension type 'object'
>>> object.flag = True
AttributeError: 'object' object has no attribute 'flag'
I was surprised that CPython raises TypeError. Library Reference seems
to mention it here:
Raised when an attribute reference or assignment fails. (When an
object does not support attribute references or attribute assignments
at all, TypeError is raised.)
What does it mean that "an object does not support attribute
references or attribute assignments at all"?
At 07:57 PM 6/29/2009 +0200, Tarek Ziadé wrote:
>If no one objects, I'd like to push PEP 376 in the "accepted" status
>and go ahead with its implementation,
>with continuous feedback at Distutils-SIG as we did to build it.
I do have a question about the current draft... Do zipped
distributions use EGG-INFO or a project-version.egg-info? This isn't
spelled out in the PEP, although I get the general idea that the
EGG-INFO format isn't supported, and thus the PEP and API do not
support existing .egg files. This should probably be made clear, if
that's the intention.
I am not the too technical guy, but thinking about the new way of
controlling the flow instead of throwing an error.
as of now if we need to break a control and go back, exceptions helps,
but it is not a actual way.
it would be great if we have a control over the frames execution, I mean
A calls B which calls C which calls D
at that point if we think to move directly to B (what error handler do
if that B has the handler defined of the error), changing the frames
instruction pointer to back to the B's position (in python code without
raising an exception) is a really useful for this web applications.
How we can achieve this? a simple way?
Actually python interpreter currently doing this.
method *B* <== has exception handler try: except:
method *D* <========= got exception here..
now exception handler checks that which caller methods has the exception
handler provided for this exception. in our case method B has this. so, the
instruction pointer has moved back to that method B with the exception.
We can have this same functionality* BUT WITHOUT THE USE OF EXCEPTION*.
where it can help?
so many places, & it gives the full power of execution control to the user.
A simple usage of this is :
Currently most of the WSGI frameworks breaking the flow if needed to go on
another route, it simple raising the exception, But if any of the called
modules handled those exceptions it fails the flow. and we can't guide the
extension modules to don't use full try except as it is the pythons power.
What you say?
Please excuse me if we have this control already, (can u explain?)
I hope, currently no languages gives such full control over coders.
Something that's been helping me squirrel out "wacky" and "fun" bugs
in multiprocessing is running the tests in a loop - sometimes hundreds
of times. Right now, I hack this up with a bash script, but I'm
sitting here wondering if adding a "loop for x iterations" option to
regrtest.py would be useful to others as well.
Any thoughts? Does anyone hate this idea with the power of a thousand suns?
Thanks for your answers.
Sorry for the title in upper case. I didn't
want to create troubles.
I've an important question for you: is it
possible that a large python module,
created using SWIG and with a hundred
of routines, makes slower the execution
(i.e. the job of ceval.c) of the Python
We've observed that, if we don't import
ndpsp.pyc at startup, the time of execution
of a loop containing the pass instruction
becomes near normal.
How Python recalls the C functions in
a C wrapper ?
Thanks for your very important help.
Python 2.4 will become 5 years old this November. I plan to make the
final security release this month or next month. If you want to see
additional patches in Python 2.4, please let us now, or commit them
yourself if you can.
Remember that only security fixes can be considered for inclusion,
and preferably only fixes that have already been applied to later
releases of Python.
On behalf of the Python development team, I'm thrilled to announce the first
production release of Python 3.1.
Python 3.1 focuses on the stabilization and optimization of the features and
changes that Python 3.0 introduced. For example, the new I/O system has been
rewritten in C for speed. File system APIs that use unicode strings now handle
paths with undecodable bytes in them. Other features include an ordered
dictionary implementation, a condensed syntax for nested with statements, and
support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1,
see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in the Python
To download Python 3.1 visit:
The 3.1 documentation can be found at:
Bugs can always be reported to:
benjamin at python.org
(on behalf of the entire python-dev team and 3.1's contributors)
On Jun 26, 2009, at 8:49 AM, benjamin.peterson wrote:
> Author: benjamin.peterson
> Date: Fri Jun 26 14:48:55 2009
> New Revision: 73569
> update release candidate shorthand
> Modified: peps/trunk/pep-0101.txt
> --- peps/trunk/pep-0101.txt (original)
> +++ peps/trunk/pep-0101.txt Fri Jun 26 14:48:55 2009
> @@ -66,7 +66,7 @@
> We use the following conventions in the examples below. Where a
> number is given, it is of the form X.YaZ, e.g. 2.6a3 for Python
> 2.6 alpha
> - 3, where "a" == alpha, "b" == beta, "c" == release candidate.
> + 3, where "a" == alpha, "b" == beta, "rc" == release candidate.
> Final releases are named "releaseXY". The branch tag is
> because this will point to the long lived maintenance branch.
> The fork
I'm sure this has been discussed but I missed it. Why was this change
made? If nothing else, it breaks many years of tradition.