Chris McDonough <chrism(a)plope.com> wrote:
> Would adding an API for sigprocmask help here?
No. sigprocmask is a large part of the problem.
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Tel.: +44 1223 334761 Fax: +44 1223 334679
I tried building python 2.5c1 using VC8.
Getting the following errors while building pythoncore_pgo:
Creating library pythoncore_pgo/python25.lib and object
config.obj : error LNK2001: unresolved external symbol _init_types
.\pythoncore_pgo/python25.dll : fatal error LNK1120: 1 unresolved externals
I checked pythoncore_pgo.vcproj file, it alreadu contains:
Can anyone give me some clue to solve this issue.
Thanks & Regards,
> Please review the patch and make a comment. I did a diff between HEAD
> and 2.4 and am fine with this going in once you are happy.
I fixed a couple of documentation nits in rev 51688.
The patch is ready-to-go.
Nick, please go ahead and backport.
The "x86 XP trunk" build slave will be down for a bit longer,
unfortunately. Tropical storm Ernesto got in the way of my DSL
installation - I don't have a new install date yet, but I'm assuming
it's going to be Tuesday or later.
I would like to see the changes to the decimal module reverted for the
Currently, the code in the decimal module implements the context manager
as a separate class instead of incorporating it directly in
decimal.Context. This makes the API unnecessarily complex and is not
pretty compared to the code it was intended to replace.
Worse still, the implementation saves a reference to the context instead
of making a copy of it. Remember decimal.Context objects are mutable --
the current implementation does not fulfill its contract to restore the
context to its original state at the conclusion of the with-statement.
The right way to do it was presented in PEP343. The implementation was
correct and the API was simple.
* The examples in WhatsNew don't work because the implementation uses a
different method name to fetch to context (this is a shallow error
except that the name in WhatsNew is better and we don't really want to
have a new method for this). It doesn't bode well that none of the
release candidate end users noticed this discrepancy -- it means they
are not trying out the examples.
* The implementation's doc string examples were not tested and don't
work (this is a deep error). One reads:
with decimal.getcontext() as ctx:
ctx.prec += 2
s = ...
To get this to work with the current implementation, it should read
with decimal.getcontext().copy().get_manager() as ctx:
ctx.prec += 2
s = ...
This is horrid. Please either revert the patch or fix it to match PEP-343.
Currently, both the partition() and rpartition() methods return a (head,
sep, tail) tuple and the only difference between the two is whether the
partition element search starts from the beginning or end of the
string. When no separator is found, both methods return the string S
and two empty strings so that 'a'.partition('x') == 'a'.rpartition('x')
== ('a', '', '').
For rpartition() the notion of head and tail are backwards -- you
repeatedly search the tail, not the head. The distinction is vital
because the use cases for rpartition() are a mirror image of those for
partition(). Accordingly, rpartition()'s result should be interpreted
as (tail, sep, head) and the partition-not-found endcase needs change so
that 'a'.rpartition('x') == ('', '', 'a') .
The test invariant should be:
For every s and p: s.partition(p) == s[::-1].rpartition(p)[::-1]
The following code demonstrates why the current choice is problematic:
line = 'a.b.c.d'
field, sep, line = line.partition('.')
line = 'a.b.c.d'
line, sep, field = line.rpartition('.')
The second fragment never terminates.
Since this is a critical API flaw rather than a implementation bug, I
think it should get fixed right away rather than waiting for Py2.5.1.
This 8 vs 4 is getting cruftier and cruftier. (And does it deal
properly with existing code that already has four spaces because it
was written recently?)
"Tim" regularly fixes whitespace already, with little damage.
Would it make sense to do a one-time cutover on the 2.6 trunk?
How about the bugfix branches?
If it is ever going to happen, then immediately after a release,
before unfreezing, is probably the best time.
---------- Forwarded message ----------
From: brett.cannon <python-checkins(a)python.org>
Date: Aug 31, 2006 6:42 PM
Subject: [Python-checkins] r51674 - python/trunk/Misc/Vim/vimrc
Date: Fri Sep 1 00:42:37 2006
New Revision: 51674
Have pre-existing C files use 8 spaces indents (to match old PEP 7 style), but
have all new files use 4 spaces (to match current PEP 7 style).
--- python/trunk/Misc/Vim/vimrc (original)
+++ python/trunk/Misc/Vim/vimrc Fri Sep 1 00:42:37 2006
@@ -19,9 +19,10 @@
" Number of spaces to use for an indent.
" This will affect Ctrl-T and 'autoindent'.
" Python: 4 spaces
-" C: 4 spaces
+" C: 8 spaces (pre-existing files) or 4 spaces (new files)
au BufRead,BufNewFile *.py,*pyw set shiftwidth=4
-au BufRead,BufNewFile *.c,*.h set shiftwidth=4
+au BufRead *.c,*.h set shiftwidth=8
+au BufNewFile *.c,*.h set shiftwidth=4
" Number of spaces that a pre-existing tab is equal to.
" For the amount of space used for a new tab use shiftwidth.
Python-checkins mailing list
I've just uploaded a trio of unittest-related patches:
#1550272 (http://python.org/sf/1550272) is a test suite for the
mission-critical parts of unittest.
#1550273 (http://python.org/sf/1550273) fixes 6 issues uncovered while
writing the test suite. Several other items that I raised earlier
were judged to be either non-issues or behaviours that, while
suboptimal, people have come to rely on.
#1550263 (http://python.org/sf/1550263) follows up on an earlier patch
I submitted for unittest's docs. This new patch corrects and clarifies
numerous sections of the module's documentation.
I'd appreciate it if these changes could make it into 2.5-final or at
What follows is a list of the issues fixed in patch #1550273:
1) TestLoader.loadTestsFromName() failed to return a
suite when resolving a name to a callable that returns
a TestCase instance.
2) Fix a bug in both TestSuite.addTest() and
TestSuite.addTests() concerning a lack of input
checking on the input test case(s)/suite(s).
3) Fix a bug in both TestLoader.loadTestsFromName() and
TestLoader.loadTestsFromNames() that had ValueError
being raised instead of TypeError. The problem occured
when the given name resolved to a callable and the
callable returned something of the wrong type.
4) When a name resolves to a method on a TestCase
subclass, TestLoader.loadTestsFromName() did not return
a suite as promised.
5) TestLoader.loadTestsFromName() would raise a
ValueError (rather than a TypeError) if a name resolved
to an invalid object. This has been fixed so that a
TypeError is raised.
6) TestResult.shouldStop was being initialised to 0 in
TestResult.__init__. Since this attribute is always
used in a boolean context, it's better to use the False