I asked one year ago if we should drop OS/2 support: Andrew MacIntyre,
our OS/2 maintainer, answered:
Extract: << The 3.x branch needs quite a bit of work on OS/2 to
deal with Unicode, as OS/2 was one of the earlier OSes with full
multiple language support and IBM developed a unique API. I'm still
struggling to come to terms with this, partly because I myself don't
"need" it. >>
So one year later, Python 3 does still not support OS/2.
About VMS: I don't know if anyone is using Python (2 or 3) on VMS, or if
Python 3 does work on VMS. I bet that it does just not compile :-)
I don't know anyone using VMS or OS/2.
There are 39 #ifdef VMS and 52 #ifdef OS2. We can keep them and wait
until someone work on these OSes to ensure that the test suite pass. But
if nobody cares of these OSes and nobody wants to maintain them, it
would be easier for the maintenance of the Python source code base to
remove specific code.
Well, not "remove" directly, but plan to remove it using the PEP 11
procedure (mark OS/2 and VMS as unsupported, and remove the code in
Sorry if I am asking the obvious, but why are the aliases of set types not
included in the 'types' module? I thought for a moment that they are just
classes, but no, they introduce themselves as built-in types, just like any
other standard Python type.
> print type(set([1, 2, 4]))
> print type(frozenset([3, 5]))
Is it intentional, or is there some meaning behind this? If not, shouldn't they
be added to the module?
Darmowy program do wypełniania PIT: http://linkint.pl/f2931
>>> type (3.)
File "<stdin>", line 1
SyntaxError: invalid syntax
Superficially the last example ought to be legal syntax (and return
Is it an oversight which could be fixed in a straightforward way, or are
there reasons why it can't?
I have tested this with Python 2.5 and Python 3.2.
Ubuntu 11.04 added support for multiarch libraries:
At the moment, I don't care about issue 1294959 which I think addresses
building multiarch flavors of Python:
I have a much more short-term concern, which is being able to build Python
from source *on* a multiarch Debian/Ubuntu:
The problem is that without this patch (or something like it), several of the
extension modules do not build because setup.py does not search the
directories in which the third party .so files live. The patch in the tracker
is fairly straightforward and should be robust enough for platforms without
dpkg-architecture(1). It's adapted from the patch in the Ubuntu source
I would like to apply this patch (or its moral equivalent) to all active,
affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3.3, as
soon as possible. Without this, it will be very difficult for anyone on
future Ubuntu or Debian releases to build Python. Since it's not a new
feature, but just a minor fix to the build process, I think it should be okay
to back port.
Please comment here or in the tracker for issue 11715.
I'm testing my faulthandler repository on the custom buildbots, here are
some remarks and issues.
The form still refers to SVN ('Branch to build' is relative to
http://svn.python.org/projects/python.) => the branch is relative to
I cannot write "#" in the branch field to specify... the branch (only
the repository). If the branch contains "#", the request looks to be
ignored (without any warning/error). I merged my faulthandler branch
into the default branch (in my features/faulthandler branch).
I don't understand the meaning of the "project" field. It is maybe
something specific to Subversion?
What are the 3 optional properties?
If branch doesn't end with a slash (e.g. "features/faulthandler"), the
request is ignored (without any warning/error).
I canceled a build on a Windows buildbot during the "tests" step using
the [Cancel] button, but it failed to kill the process:
command interrupted, killing pid 2168
SIGKILL failed to kill process
using fake rc=-1
program finished with exit code -1
To test my faulthandler feature branch, the correct parameters are:
Reason: test faulthandler
(leave the project and the 6 property fields empty)
The repository looks like a duplicate of the branch field. I would be
better to use "default" as the branch and "features/faulthandler" as the
I would be nice to have error messages.
Well, I'll do like welcome message of the python-dev-request ask.
I'm a brazilian C programmer and I'm learning how to programm in Python fast
because it is cool.
I installed python a few days ago in my notebook. So, I will be here
learning with you guys just watching you and your discussions about what it
is better for python's future for while and when I fell 100% sure about what
I have to post it here. I will.
I'm sorry about my English. That's my first time typing in English in a
See you guys!
Jayme Proni Filho
Phone: +55 - 17 - 3631 - 6576
Mobile: +55 - 17 - 9605 - 3560
e-Mail: jaymeproni at yahoo dot com dot br
I actually created a bug entry for this
(http://bugs.python.org/issue11798) and just later it occurred that I
should've asked in the list first :)
So, here's the text for opinions:
Right now, when doing a test case, one must clear all the variables
created in the test class, and I believe this shouldn't be needed...
self.obj1 = MyObject()
Ideally (in my view), right after running the test, it should be
garbage-collected and the explicit tearDown just for deleting the
object wouldn't be needed (as the test would be garbage-collected,
that reference would automatically die), because this is currently
very error prone... (and probably a source of leaks for any
sufficiently big test suite).
If that's accepted, I can provide a patch.
Le mardi 19 avril 2011 à 22:42 -0400, Terry Reedy a écrit :
> On 4/19/2011 5:59 PM, victor.stinner wrote:
> > Issue #11223: Add threading._info() function providing informations about the
> > thread implementation.
> Since this is being documented, making it part of the public api, why
> does it have a leading underscore?
Well, I suppose that this function might be specific to CPython. Do you
think that this function can/should be implemented in PyPy, Jython and
The new faulthandler module is now fully functional and it has no more
known issue. Its timeout feature is used on regrtest to dump the Python
backtrace and exit if a test takes more than 1 hour.
Using the regrtest timeout and faulthandler signal handlers (enable in
regrtest), I started to collect tracebacks of all timeouts.
* test_threading.test_notify() on Windows
Not analyzed yet. I am unable to reproduce it in my VM.
* test_mmap.test_large_offset() on Mac OS X
May be related (and fixed) by issue #11277 which has a patch.
* test_threading.test_3_join_in_forked_from_thread() on Ubuntu
Only seen once.
* test_mmap.test_big_buffer() on Mac OS X (it's a crash, bus error)
The origin of the problem was already identified, but the trace
proves that faulthandler is able to catch correctly SIGBUS ;-)
* test_ttk_guionly on Mac OS X (bus error)
Same as #11277 (the origin of the problem was already identified)
* test_io.test_interrupted_write_text() on FreeBSD
(there was already enough information without faulthandler)
* test_threadsignals.test_signals() on Mac OS X
Race condition (deadlock).
* test_multiprocessing.test_async_error_callback() on many OSes
I'm proud of #11768 (because I fixed it). The bug was a deadlock. It is
usually very hard to reproduce such issue (a deadlock) and without
faulthandler, the only available information was the name of the file.
With faulthandler, we have not only the name of the test function, but
also the full traceback of the hang, but also the traceback of all other
Thanks to the faulthandler trace of #8428, with the traceback of all
threads, Charles-Francois Natali was able to understand and fix another
complex race condition in multiprocessing (at shutdown).
I also fixed other issues (not using faulthandler) and so ALL OUR 3.X
BUILDBOTS ARE GREEN!
... ok ok, except:
- sparc Debian 3.x: offline since 21 days
- PPC Leopard 3.x : "hg clean" fails with
twisted.internet.error.ProcessExitedAlready, but I think that except
this buildbot specific issue, it must be green
- x86 Windows7 3.x: the master lost the connection with the slave on
test_cmd_line, but it should be a sporadic problem
Anyway, if you see a "Timeout (1:00:00)!" or "Fatal error" (with a
traceback) issue on a buildbot, please open a new issue (if it doesn't
exist, search a least the name of the test file). If you have other
problems related to regrtest timeout or faulthandler, contact me or open
Finally, I'm very happy to see that my faulthandler module was as useful
as I expected: with more informations, we are now able to identify race
conditions. I hope that we will fix all remaining threading, signal and
subprocess race conditions!