[Eric Nieuwland]
>> Perhaps the second argument should not be optional to emphasise this.
>> After all, there's much more to sum() than numbers.
[Greg Ewing]
> I think practicality beats purity here. Using it on
> numbers is surely an extremely common case.
I'd personally be delighted if sum() ne
[Guido van Rossum]
> Um, Python doesn't provide a lot of special support for numbers apart
> from literals -- sum() should support everything that supports the "+"
> operator, just like min() and max() support everything that supports
> comparison, etc.
The discussion in the patch that introduced
[Alex Martelli]
> I'm reasonably often using sum on lists of datetime.timedelta
> instances, "durations", which ARE summable just like numbers even
> though they aren't numbers. I believe everything else for which I've
> used sum in production code DOES come under the general concept of
> "numbers
[Jack Jansen]
> On a platform I won't mention here I'm running into problems compiling
> Python, because of it defining _POSIX_C_SOURCE.
...
> Does anyone know what the real meaning of this define is?
LOL. Here's the Official Story:
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_cha
[Jeremy Hylton]
> Are the thread semantics for file objecst documented anywhere?
No. At base level, they're inherited from the C stdio implementation.
Since the C standard doesn't even mention threads, that's all
platform-dependent. POSIX defines thread semantics for file I/O, but
fat lot of go
[Jeremy Hylton]
...
> Universal newline reads and get_line() both lock the stream if the
> platform supports it. So I expect that they are atomic on those
> platforms.
Well, certainly not get_line(). That locks and unlocks the stream
_inside_ an enclosing for-loop. Looks quite possible for diff
[Brett C.]
> Make sure "AST" is used in the subject line; e.g., "[AST]" at the beginning.
> Unfortunately the AST group is only available for patches; not listed for bug
> reports (don't know why; can this be fixed?).
Your wish is my command: there's an AST group in Python's bug tracker
now. FYI
[Michael Hudson]
> Asking mostly for curiousity, how hard would it be to have longs store
> their sign bit somewhere less aggravating?
Depends on where that is.
> It seems to me that the top bit of ob_digit[0] is always 0, for example,
Yes, the top bit of ob_digit[i], for all relevant i, is 0 on
[Fred Drake]
>> Would anyone here object to renaming the file to developers.txt, though?
[Barry Warsaw]
> +1, please!
I voted with my DOS box.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
[EMAIL PROTECTED]
> Modified Files:
>mathmodule.c
> Log Message:
> Add a comment explaining the import of longintrepr.h.
>
> Index: mathmodule.c
...
> #include "Python.h"
> -#include "longintrepr.h"
> +#include "longintrepr.h" // just for SHIFT
The intent is fine, but please use a standar
[Michael Hudson]
> ...
> Point the first is that I really think this is a bug in the GilState
> APIs: the readline API isn't inherently multi-threaded and so it would
> be insane to call PyEval_InitThreads() in initreadline, yet it has to
> cope with being called in a multithreaded situation. If y
[Raymond Hettinger]
> Does anyone know what has become of the following developers and perhaps
> have their current email addresses?
How about we exploit that if someone is a Python developer on SF, they
necessarily have an SF email address ($(SFNAME)@users.sourceforge.net,
like I'm [EMAIL PROTECT
[Jeremy]
>> Eric Price did some of the work on the decimal package, which was only
>> two summers ago. He wasn't an intern at CNRI.
[Fred]
> A different Eric Price, then. Mea culpa.
>
> (Or am I misremembering the intern's name? Hmm.)
Yes, Eric Price was "the PythonLabs intern", for the brief
...
[Uncle "Bad Cop" Timmy]
>> Then, IMO, if someone with SF commit privs can't be reached via their
>> SF address, they shouldn't have SF commit privs.
[Raymond "Good Cop" Hettinger]
> I'm taking a lighter approach and making every effort to get in contact.
> If they respond, I'll ask them to up
[Scott David Daniels]
> What should marshal / unmarshal do with floating point NaNs (the case we
> are worrying about is Infinity) ? The current behavior is not perfect.
All Python behavior in the presence of a NaN, infinity, or signed zero
is a platform-dependent accident. This is because C89 h
[Raymond Hettinger wrote:
>> I used those addresses and sent notes to everyone who hasn't made a
>> recent checkin.
[Fredrik Lundh]
> where recent obviously was defined as "after 2.4" for checkins, and "last
> week"
> for tracker activities.
Raymond didn't mention tracker activity above, and tha
marshal shouldn't be representing doubles as decimal strings to begin
with. All code for (de)serialing C doubles should go thru
_PyFloat_Pack8() and _PyFloat_Unpack8(). cPickle (proto >= 1) and
struct (std mode) already do; marshal is the oddball.
But as the docs (floatobject.h) for these say:
[mwh]
> OTOH, the implementation has this comment:
>
> /*
> * _PyFloat_{Pack,Unpack}{4,8}. See floatobject.h.
> *
> * TODO: On platforms that use the standard IEEE-754 single and double
> * formats natively, these routine
[Fredrik Lundh]
> is changing the marshal format really the right thing to do at this
> point?
I don't see anything special about "this point" -- it's just sometime
between 2.4.1 and 2.5a0. What do you have in mind?
Like pickle formats, I expect a change to marshal would add a new
format code, n
[Tim]
>> The 754 standard doesn't say anything about how the difference between
>> signaling and quiet NaNs is represented. So it's possible that a qNaN
>> on one box would "look like" an sNaN on a different box, and vice
>> versa. But since most people run with all FPU traps disabled, and
>> Pyt
...
[mwh]
> OK, so the worst that could happen here is that moving marshal data
> from one box to another could turn one sort of NaN into another?
Right. Assuming source and destination boxes both use 754 format, and
the implementation adjusts endianess if necessary.
Heh. I have a vague half-m
[Michael Hudson]
> I've just submitted http://python.org/sf/1180995 which adds format
> codes for binary marshalling of floats if version > 1, but it doesn't
> quite have the effect I expected (see below):
> >>> inf = 1e308*1e308
> >>> nan = inf/inf
> >>> marshal.dumps(nan, 2)
> Traceback (most re
...
[mwh]
>>> I recall stories of machines that stored the bytes of long in some
>>> crazy order like that. I think Python would already be broken on such
>>> a system, but, also, don't care.
[Tim]
>> Python does very little that depends on internal native byte order,
>> and C hides it in the ab
Seeing three seemingly related test failures today, on CVS HEAD:
test_csv
test test_csv failed -- errors occurred; run in verbose mode for details
test_descr
test test_descr crashed -- exceptions.AttributeError: attribute
'__dict__' of 'type' objects is not writable
test_file
test test_file crashe
[Raymond]
It would be great if we could point to some code in the standard library
or in a major Python application that would be better (cleaner, faster,
or clearer) if re-written using blocks and block-iterators
[Guido]
>>> look more closely at Queue, and you'll find that the two
...
[Jim Jewett]
>> qsize, empty, and full could be done with a lockself decorator.
>> Effectively, they *are* lockself decorators for the _xxx functions
>> that subclasses are told to override.
[Guido]
> Actually you're pointing out a bug in the Queue module: these *should*
> be using a try/fin
[Tim]
>> Because Queue does use condvars now instead of plain locks, I wouldn't
>> approve of any gimmick purporting to hide the acquire/release's in
>> put() or get(): that those are visible is necessary to seeing that
>> the _condvar_ protocol is being followed ("must acquire() before
>> wait();
[Guido]
> I'm +1 on accepting this now -- anybody against?
I'm curious to know if you (Guido) remember why you removed this
feature in Python 0.9.6? From the HISTORY file:
"""
New features in 0.9.6:
- stricter try stmt syntax: cannot mix except and finally clauses on 1 try
"""
IIRC (and I may w
[Reinhold Birkenfeld]
> ...
> I think the behaviour of the "else" clause is much harder to guess,
> mainly when used with the looping constructs.
No, that's obvious .
What about `else` mixed with try/except/finally?
try:
A
except:
B
else:
C
finally:
D
If A executes without excep
[Shane Holloway]
> And per the PEP, I think the explaining that::
>
> try:
> A
> except:
> B
> else:
> C
> finally:
> D
>
> is *exactly* equivalent to::
>
> try:
> try:
> A
> except:
> B
> else:
>
[Guido]
> ...
> I wonder how many folks call their action methods do() though.
A little Google(tm)-ing suggests it's not all that common, although it
would break Zope on NetBSD:
http://www.zope.org/Members/tino/ZopeNetBSD
I can live with that .
___
[Guido, on string exceptions]
> ...
> Last I looked Zope 2 still depended on them (especially in the
> bowels of ZODB); maybe Tim Peters knows if that's still the
> case.
Certainly none of that in ZODB, or in ZRS. Definitely some in Zope 2.6:
<http://mail.zope.org/pipermail
[Raymond Hettinger]
> ...
> One more change: The final "return +s" should be unindented. It should
> be at the same level as the "do with_extra_precision()". The purpose of
> the "+s" is to force the result to be rounded back to the *original*
> precision.
>
> This nuance is likely to be the ban
[Guido]
> ...
> I think in the past I've unsuccessfully tried to argue that if a
> cycle contains exactly one object with a Python-invoking finalizer,
> that finalizer could be invoked before breaking the cycle. I still
> think that's a sensible proposal, and generators may be the use case
> to fin
[Phillip J. Eby]
> ...
> However, Tim's new post brings up a different issue: if the collector can't
> tell the difference between a cycle participant and an object that's only
> reachable from a cycle, then the mere existence of a generator __del__ will
> prevent the cycle collection of the entire
[Phillip J. Eby]
> Now you've shaken my faith in Uncle Timmy. :)
Now, now, a mere technical matter is no cause for soul-damning heresy!
> Seriously, he did *say*:
>
> """For example, it doesn't know the difference between an object
> that's in a trash cycle, and an object that's not in a trash
[Raymond Hettinger]
> For brevity, the above example used the context free
> constructor, but the point was to show the consequence
> of a precision change.
Yes, I understood your point. I was making a different point:
"changing precision" isn't needed _at all_ to get surprises from a
constructo
Sorry, I simply can't make more time for this. Shotgun mode:
[Raymond]
> I have no such thoughts but do strongly prefer the current
> design.
How can you strongly prefer it? You asked me whether I typed floats
with more than 28 significant digits. Not usually . Do you?
If you don't either, h
[Greg Ewing]
> I don't see it's because of that. Even if D(whatever)
> didn't ignore the context settings, you'd get the same
> oddity if the numbers came from somewhere else with a
> different precision.
Most users don't change context precision, and in that case there is
no operation defined in
[Guido van Rossum]
> I know I should stay out of here,
Hey, it's still your language .
> but isn't Decimal() with a string literal as argument a rare
> case (except in examples)? It's like float() with a string
> argument -- while you *can* write float("1.01"), nobody does
> that. What people do
[Michael Chermside]
> Tim, I find Raymond's arguments to be much more persuasive.
> (And that's even BEFORE I read his 11-point missive.) I
> understood the concept that *operations* are context-
> dependent, but decimal *objects* are not, and thus it made
> sense to me that *constructors* were not
[Tim Peters]
> ...
> Other important implementations of the standard didn't
> make this mistake; for example, Java's BigDecimal
> (java.lang.String) constructor follows the rules here:
>
>http://www2.hursley.ibm.com/decimalj/deccons.html
Hmm -- or maybe it doesn
[Raymond Hettinger]
> The word deviate inaccurately suggests that we do not have
> a compliant method which, of course, we do. There are two
> methods, one context aware and the other context free. The
> proposal is to change the behavior of the context free version,
> treat it as a bug, and alte
[Guido]
> It looks like if you pass in a context, the Decimal constructor
> still ignores that context:
>
> >>> import decimal as d
> >>> d.getcontext().prec = 4
> >>> d.Decimal("1.234567890123456789012345678901234567890123456789",
> d.getcontext())
> Decimal("1.2345678901234567890123456789012
[A.M. Kuchling]
> Looking at bug #1209880, the following function from threadmodule.c is
> referenced. I think the args==NULL case, which can return None
> instead of a Boolean value, can never be reached because
> PyArg_ParseTuple() will fail if args==NULL.
It would assert-fail in a debug build.
[Raymond Hettinger]
>> While the majority of Python users deem this to be a nice-to-have
>> feature
[Barry Warsaw]
> Really? Where's the supporting poll data?
We've run IV polls since this PEP was introduced, and the geometric
mean of those shows LXVIII% of Python users strongly in favor (+I),
a
[Raymond Hettinger]
> After nine months, no support has grown beyond the original poster.
Never will, either -- even Roman numeral literals are more Pythonic
than this one.
More Pythonic: make integers callable: i(arglist) returns the i'th
argument. So, e.g., people who find it inconvenient to
About PEP 303, I use divmod for lots (and lots) of things, but I've
got no real use for an extended divmod() either. -1: it would be
low-use, confusing clutter.
[Barry]
> Interesting. Just yesterday I wrote a simple stopwatch-like timer
> script and I found that I needed three divmod calls to c
[Anthony Baxter]
> I'm still catching up on the hundreds of python-dev messages from the
> last couple of days, but a quick note first that I'm ok to do release
> management for 2.5
I, for one, am delighted to see that Australian millionaires don't
give up tech work after winning an Olympic gold m
[Travis Oliphant]
> Maybe I have the wrong version of code. In my pyport.h (checked out
> from svn trunk) I have.
>
> #define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)>>1))
>
> What is size_t?
size_t is an unsigned integral type defined by, required by, and used
all over the place in standard C.
This started failing since last night:
C:\Code\python\PCbuild>python ..\lib\test\test_fileinput.py
1. Simple iteration (bs=0)
2. Status variables (bs=0)
3. Nextfile (bs=0)
4. Stdin (bs=0)
5. Boundary conditions (bs=0)
6. Inplace (bs=0)
7. Simple iteration (bs=30)
8. Status variables (bs=30)
9. Nex
Never mind -- repaired it.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Aahz]
> If you're willing to commit to running a buildbot, and the only thing
> preventing you is shelling out $$$ to Microsoft, send me e-mail. I'll
> compile a list to send to the PSF and we'll either poke Microsoft to
> provide some more free licenses or pay for it ourselves. This is what
> t
[Guido]
> ...
> What's the practical use case for not wanting __contains__() to
> function?
I don't know. I have practical use cases for wanting __contains__()
to function, but there's been no call for those. For an example,
think of any real use ;-)
For example, I often use dicts to represent
[Martin v. Löwis]
> So what is your recipe:
I don't have one. I personally always use -uall and -r, and then run
the tests 8 times, w/ and w/o -O, under debug and release builds, and
w/ and w/o deleting .py[co] files first. Because that last one almost
never finds problems anymore, perhaps it wo
[Neal Norwitz]
> ...
> I also think I know how to do the "double builds" (one release and one
> debug). But it's too late for me to change it tonight without
> screwing it up.
I'm not mad :-). The debug build is more fruitful than the release
build for finding problems, so doing two debug-build
[Neal Norwitz]
>> Martin and I were talking about dropping support for older versions of
>> Windows (of the non-NT flavor). We both thought that it was
>> reasonable to stop supporting Win9x (including WinME) in Python 2.6.
>> I updated PEP 11 to reflect this.
It's OK by me, but I have the same q
The buildbot shows that the debug-build test_grammar is dying with a C
assert failure on all boxes.
In case it helps, in a Windows release build test_transformer is also failing:
test_transformer
test test_transformer failed -- Traceback (most recent call last):
File "C:\Code\python\lib\test\te
[1/24/06, Tim Peters]
>> ...
>> test_rude_shutdown() is dicey, relying on a sleep() instead of proper
>> synchronization to make it probable that the `listener` thread goes
>> away before the main thread tries to connect, but while that race may
>> account for bogus
test test_pep352 failed -- Traceback (most recent call last):
File "C:\Code\python\lib\test\test_pep352.py", line 54, in test_inheritance
self.fail("%s not a built-in exception" % exc_name)
AssertionError: WindowsError (Windows) not a built-in exception
___
These .py and .txt files don't have the svn:eol-style property set.
I'm not sure they all _should_, though. Some of them are particularly
bizarre, e.g. Lib\email\test\data\msg_26.txt has the svn:mime-type
property set to application/octet-stream (WTF?), and then svn refuses
to set the eol-style p
[Alex Martelli]
>> We stole list comprehensions and genexps from Haskell
[Greg Ewing]
> The idea predates Haskell, I think. I first saw it in
> Miranda, and it may have come from something even
> earlier -- SETL, maybe?
Haskell indeed took list comprehensions from SETL. SETL in turn took
them fr
[Alex Martelli]
>> We stole list comprehensions and genexps from Haskell
[Greg Ewing]
> The idea predates Haskell, I think. I first saw it in
> Miranda, and it may have come from something even
> earlier -- SETL, maybe?
Haskell indeed took list comprehensions from SETL. SETL in turn
adopted them
I spent most of my PyCon sprint time so far working on Evan Jones's
arena-freeing obmalloc patch:
http://www.python.org/sf/1123430
It's ready to test now! The work is on a branch:
svn+ssh://svn.python.org/python/branches/tim-obmalloc
Only obmalloc.c is changed in that branch, and you c
[Tim Peters]
...
> Only obmalloc.c is changed in that branch, and you can get it directly from:
>
>
> <http://svn.python.org/view/python/branches/tim-obmalloc/Objects/obmalloc.c?rev=42760&view=log>
Heck no -- sorry, that pins it to an out-of-date revision.
[Tim Peters]
>> ...
>> However, the new branch isn't predictable, so who knows?
[Nick Craig-Wood]
> When compiling with gcc at least you could give the compiler a hint,
> eg
>
> http://kerneltrap.org/node/4705
By "the new branch isn't predictable&quo
[Oleg Broytmann[
>My experience shows that if the developers use different OSes (our team
> uses Linux and Windows) it helps very much to set svn:eol-style to native
> for all text files - *.py, *.txt, etc, except for files with special
> requirements.
Yes.
> So I use the following shell scri
[Martin Maly]
> The Python spec states that the "from __future__ import …" statement can
> only occur at the beginning of the file, preceded only by doc strings,
> comments, empty lines or other future statements. The following code
> snippets, however, don't raise Syntax error in Python 2.4.2. Is
[Tim]
>> Doesn't look like Guido responded, so I'll channel him and declare
>> that he intended to agree with me after all ;-)
[Guido]
> It was so obvious that you were right I didn't bother to agree at the
> time. But yes, I agree.
Of course you do. It was obvious to you, and therefore-- as you
[Anna Ravenscroft]
I think this is a really good point. next() is supposed to get used, by
coders, in regular code - so it shouldn't be __next__. I can understand the
desire for both forms, although that seems it would clutter things up
unnecessarily - particularly if the two do
[Ben Chelf <[EMAIL PROTECTED]>]
> ...
> I'd ask that if you are interested in really digging into the results a bit
> further for your project, please have a couple of core maintainers (or
> group nominated individuals) reach out to me to request access.
Didn't we set up a "security swat team" som
[Barry]
> Yep, it's called [EMAIL PROTECTED] (with a semi-secret backing mailing
> list, which I'd be happy for you to join!).
If guessing the right Mailman URL was the semi-secret test, I passed :-)
> I definitely think that group of folks at the least should review the results.
Yup!
_
[Jim Jewett]
>>> I think that adding parentheses would help, by at least signalling that
>>> the logic is longer than just the next (single) expression.
>>>
>>> level = (0 if "absolute_import" in self.futures else -1)
[Steve Holden]
>> Contrast with the bleeding obvious:
>>
>> level = 0
>>
[Tim]
>> Neal plugged another hole later, but-- alas --I have seen the same shy
>> failure since then on WinXP. One of the most recent buildbot test
>> runs saw it too, on a non-Windows box:
>>
>> http://www.python.org/dev/buildbot/trunk/g5%20osx.3%20trunk/builds/204/step-test/0
>>
>> test_socket_
[Georg Brandl]
> I know, PyCon's just been, but not many bugs were closed
Ya, it was very much a development sprint this year -- "new features".
> and there really ought to be some issues resolved before 2.4.3 happens.
> The number of open bugs is again crawling to 900.
>
> I myself are looking a
[Tim Peters]
>> Added:
>>python/trunk/Tools/scripts/svneol.py (contents, props changed)
>> Log:
>> Simple utility to add svn:eol-style to text files under
>> SVN control. Like reindent.py, I expect to run this
>> mindlessly from time to time, chec
[Thomas Heller]
> ...
> And I never had tried it before on a sparc machine - all the intel and ppc
> processors
> seem to have no problems with it.
Pentiums don't enforce "natural" alignment restrictions, but run much
slower on unaligned access (varying by specific chip model, and
generally more
[Thomas Heller]
> ...
> I could do that myself, but only for x86, while other .pyd files also have
> build
> settings for Itanium and x86_64. (I find it always very painful to click
> through
> the settings dialog in MSVC - isn't there any other way to create these
> files?)
Under VC 6 I gener
[Thomas Heller]
> ...
> The Linux-head is the release manager, prepaing the release on
> a unixish platform, in combination with the windows guy who downloads
> the source distribution and tries to compile that on Windows.
That sounds like an artificial (process-created) problem, then. Since
a re
[Martin v. Löwis]
> Last I tried, VS 2003 would tolerate \n line endings in vcproj files
> (these being plain XML files). I don't remember whether it would
> tolerate them in .sln files (as these are *not* XML files); this is
> why the .sln file is set to binary.
FYI, I tried changing pcbuild.sln
Compiling...
unicodedata.c
\Code\python\Modules\unicodedata.c(74) : error C2133:
'unicodedata_functions' : unknown size
It's griping about this:
/* Forward declaration */
static PyMethodDef unicodedata_functions[];
___
Python-Dev mailing list
Python-De
[Thomas Heller]
> ...
> In the meantime, please: If anyone is going to make fixes to the ctypes source
> code (apart from Tim's regular whitespace cleanup), please do this in the
> ctypes CVS repository on sourceforge, in the trunk.
FYI, my regular whitespace cleanup consists of running reindent.p
[Thomas Heller]
> Are there any estimates how much network traffic a buildbot would generate?
It should be trivial except for the initial checkout of the Python code base.
> And how must it be connected to the internet - I assume it must be reachable
> from the outside.
The slave opens a socket
[Trent Mick]
> I'm keen. However, it looks like Tim is most of the way there already:
The first 100% clean (ignoring _ctypes warnings) Windows builbot test
run just finished. Yippee! Setup is hellish, although you've already
done the worst of it if you regularly build+test full Python on
Windows
[Martin v. Löwis]
> It seems like the buildbot needs even more hand-holding on Windows:
> it apparently doesn't survive a master stop/start cycle. While the
> Unix buildbots reconnect, the Windows one doesn't.
What makes us believe that? My box was hibernating from 03:12 to
11:54 EST today, and c
[Tim]
>> Setup is hellish,
[Trent]
> Agreed, though I have everything going with my own testing buildbot
> master (everything for the trunk build that is). My only remaining
> problem is that I can't connect to python.org's master. (Following up
> with Martin.)
Looks like that got fixed.
>> The
[Trent Mick]
> I have a patch in the works that defaults to "yes, this machine does
> have a soundcard" if cscript.exe cannot be found on the PATH.
>
> However, one wrinkle: test_winsound.py is made up of three test cases:
> BeepTest
> MessageBeepTest
> PlaySoundTest
> only the last nee
[Mark Hammond]
> Maybe the following VBScript "port" of the above will work:
>
> -- check_soundcard.vbs
> rem Check for a working sound-card - exit with 0 if OK, 1 otherwise.
> set wmi = GetObject("winmgmts:")
> set scs = wmi.InstancesOf("win32_sounddevice")
> for each sc in scs
> set status =
[Raymond Hettinger]
>> FWIW, the new with-statement makes the above fragment even more
>> readable:
>>
>> with atomic_transaction():
>> # do a series of steps without interruption
[Phillip J. Eby]
> +1 on the idea, -1000 on the name. It's neither atomic nor a
> transaction. I believe
[Raymond Hettinger]
> ...
> I disagree that the need is rare. My own use case is that I sometimes
> add some debugging print statements that need to execute
> atomically -- it is a PITA because PRINT_ITEM and PRINT_NEWLINE
> are two different opcodes and are not guaranteed to pair atomically.
Wel
[Phillip J. Eby]
> Well, I'm showing my age here, but in the good ol' days of the 8086
> processor, I recall it frequently being used to describe a block of
> assembly code which ran with interrupts disabled - ensuring that no task
> switching would occur.
According to Wikipedia's current article
[Trent Mick, on test_winsound]
> I'll do this tonight or tomorrow.
Cool!
I see that your Win2K buildbot slave always dies in the compile step now, with
"""
-- Build started: Project: pythoncore, Configuration: Debug Win32 --
Compiling resources...
generate buildinfo
cl.exe -c -D_WIN32 -
[Raymond Hettinger]
> FWIW, I've been working on a way to simplify the use of queues with
> daemon consumer threads
>
> Sometimes, I launch one or more consumer threads that wait for a task
> to enter a queue and then work on the task. A recurring problem is that
> I sometimes need to know if all o
[Trent Mick]
> Yes I've noticed it too. I've had to kill python_d.exe a few times. I
> haven't yet had the chance to look into it. I am NOT getting this error
> on another Windows Python build slave that I am running in-house for
> play.
The last run on your Win2K slave that got beyond the compile
[Uncle Timmy]
...
> Looks like it was running test_bsddb at the time, and the test
> framework gave up after waiting 20 minutes for more output. I had one
> of those "recently" that waited 20 minutes for output after starting
> test_shelve, but it's scrolled off the page. Berkeley DB is fishy.
W
[M.-A. Lemburg]
>> Why do you add these things to the xx module and not the
>> _testcapi module where these things should live ?
[Neal Norwitz]
> Because I'm an idiot?
Ah, so _that's_ why you were made the release coordinator ;-)
> Thanks for pointing it out, I moved the code.
Or maybe that was
[Thomas Wouters]
> I did the same narrowing-down last week, and submitted a patch to add
> cycle-GC support to itertools.tee . It really needs it.
I agree.
> Come to think of it, now that I remember how to properly do GC, I think
> the patch cuts some corners, but it solved the problem.
You mean
[Neal Norwitz]
> ...
> The public report says 15, but the current developer report shows 12.
> I'm not sure why there is a discrepancy. All 12 are in ctypes which
> was recently imported.
I'm having a really hard time making sense of the UI on this. When I
looked at the Python project just now (
>> Author: thomas.heller
>> Date: Tue Mar 14 21:39:27 2006
>> New Revision: 43028
>>
>> Modified:
>>python/trunk/Modules/_ctypes/cfield.c
>> Log:
>> Cast an Py_ssize_t to int, to avoid a compiler warning.
>>
>> Modified: python/trunk/Modules/_ctypes/cfield.c
>> =
[tim.peters]
>> CField_repr(): PyString_FromFormat() understands the
>> C99 "z" qualifier on all platforms.
[Martin v. Löwis]
> Unfortunately, only so in Python 2.5. If the code is also
> meant to be used for earlier versions, it won't work there
> at all.
Does that matter? I checked the patch
601 - 700 of 1049 matches
Mail list logo
