Today I was trying to use `total_ordering` for the first time. I was
expecting that in order to implement e.g. `x > y` it would do `not x < y and
not x == y`, assuming that `__lt__` and `__eq__` are defined. But I see it
just does `y < x`, which is problematic. For example if you have a class
that is decorated by `total_ordering`, and implements only `__lt__` and
`__eq__`, then trying to do `x < y` will result in infinite recursion.
Why not have `total_ordering` work in the way I suggested?
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