Nick Coghlan <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>> Option 1) Call PyEval_ThreadsInitialized() in PyGilState_Release().
>> Non-invasive, but bleh.
>
> Tim rejected this option back when PyEval_ThreadsInitialized() was
> added to the API [1].
Well, n
Tim Peters <[EMAIL PROTECTED]> writes:
> [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 in
Jp Calderone <[EMAIL PROTECTED]> writes:
> Does using the gc module to bypass this security count? If so:
>
> [EMAIL PROTECTED]:~$ python -i facet.py
> >>> import gc
> >>> c = readonly_facet.__getattr__.func_closure[1]
> >>> r = gc.get_referents(c)[0]
> >>> r.n = 'hax0r3d'
"Gregory P. Smith" <[EMAIL PROTECTED]> writes:
>> > Under "Limitations and Exclusions" it specifically disowns
>> > responsibility for worrying about whether Py_Initialize() and
>> > PyEval_InitThreads() have been called:
>> >
>> [snip quote]
>>
>> This suggests that I should call PyEval_InitThre
Bob Ippolito <[EMAIL PROTECTED]> writes:
> Is there a good reason to *not* call PyEval_InitThreads when using a
> threaded Python?
Well, it depends how expensive ones OS's locking primitives are, I
think. There were some numbers posted to the twisted list recently
that showed it didn't make a wh
James Y Knight <[EMAIL PROTECTED]> writes:
> On Apr 9, 2005, at 2:13 PM, Michael Hudson wrote:
>
>> The funniest I know is part of PyPy:
>>
>> def extract_cell_content(c):
>> """Get the value contained in a CPython 'cell',
Tim Peters <[EMAIL PROTECTED]> writes:
> 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.
>
James Y Knight <[EMAIL PROTECTED]> writes:
> On Apr 10, 2005, at 11:22 AM, Michael Hudson wrote:
>
>> Bob Ippolito <[EMAIL PROTECTED]> writes:
>>
>>> Is there a good reason to *not* call PyEval_InitThreads when using a
>>> threaded Python?
>&g
Bob Ippolito <[EMAIL PROTECTED]> writes:
> On Apr 10, 2005, at 2:48 PM, Michael Hudson wrote:
>
>> James Y Knight <[EMAIL PROTECTED]> writes:
>>
>>> Here's the numbers. It looks like something changed between python 2.2
>>> and 2.3 that mad
Tim Peters <[EMAIL PROTECTED]> writes:
> 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
Tim Peters <[EMAIL PROTECTED]> writes:
> [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 peop
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 recent call last):
File "", lin
My mail is experincing random delays of up to a few hours at the
moment. I wrote this before I saw your comments on my patch.
Tim Peters <[EMAIL PROTECTED]> writes:
> [Michael Hudson]
>> I've just submitted http://python.org/sf/1180995 which adds format
>> codes for bi
Tim Peters <[EMAIL PROTECTED]> writes:
> ...
>
> [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 int
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Are context diffs still favoured for patches?
If you want me to review it, yes, probably, but see below...
> The patch submission guidelines [1] still say that, but is it actually
> true these days? I personally prefer unified diffs, but have been
> gen
"Phil Thompson" <[EMAIL PROTECTED]> writes:
> In PyQt, wrapped types implement lazy access to the type dictionary
> through tp_getattro. If the normal attribute lookup fails, then private
> tables are searched and the attribute (if found) is created on the fly and
> returned. It is also put into t
"Phil Thompson" <[EMAIL PROTECTED]> writes:
>>> Questions...
>>>
>>> 1. What is the reason why it doesn't go via tp_getattro?
>>
>> Because it wouldn't work if it did? I'm not sure what you're
>> suggesting here.
>
> I'm asking for an explanation for the current implementation. Why wouldn't
> it
Barry Warsaw <[EMAIL PROTECTED]> writes:
> On Sun, 2005-04-17 at 14:36, Guido van Rossum wrote:
>
>> Personally, I think it would be fine to just change the TypeError to
>> AttributeError. I expect that very few people would be hurt by that
>> change (they'd be building *way* too much specific arc
> Summary Announcements
> ==
>
> ---
> New python-dev summary team
> ---
>
> This summary marks the first by the team of Steve Bethard, Tim Lesher,
> and Tony Meyer.
Nice work!
An update:
> -
> Improving GilState API Robustnes
Shannon -jj Behrens <[EMAIL PROTECTED]> writes:
> On 4/20/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
>> My use case for switch is that of a parser switching on tokens.
>>
>> mxTextTools applications would greatly benefit from being able
>> to branch on tokens quickly. Currently, there's only
Samuele Pedroni <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
[pattern matching]
>>Can you post a quick summary of how you think this would work?
>>
>>
> Well, Python lists are used more imperatively and are not made up
> with cons cells, we have dicti
Scott David Daniels <[EMAIL PROTECTED]> writes:
> What should marshal / unmarshal do with floating point NaNs (the case we
> are worrying about is Infinity) ? The current behavior is not perfect.
So, after a fair bit of hacking, I think I have most of a solution to
this, in two patches:
make
Facundo Batista <[EMAIL PROTECTED]> writes:
> Is there a document that details which objects are cached in memory
> (to not create the same object multiple times, for performance)?
No.
> If not, could please somebody point me out where this is implemented
> for strings?
In PyString_FromStringAn
Thomas Heller <[EMAIL PROTECTED]> writes:
> I always wondered why there usually is very sloppy error checking in
> init functions.
Laziness, I presume...
> The problem is that when one of these things fail (although they are
> probably supposed to NOT fail) you end up with a module missing
> som
Whew! This is a bit long...
On 25 Apr 2005, at 00:57, Guido van Rossum wrote:
After reading a lot of contributions (though perhaps not all -- this
thread seems to bifurcate every time someone has a new idea :-)
I haven't read all the posts around the subject, I'll have to admit.
I've read the on
On 26 Apr 2005, at 15:13, Michael Hudson wrote:
So, here's a counterproposal!
And a correction!
with expr as var:
... code ...
is roughly:
def _(var):
... code ...
try:
expr(_)
except Return, e:
return e.value
Cheers,
mwh
___
Pytho
Samuele Pedroni <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> The history of iterators and generators could be summarized by
>> saying that an API was invented, then it turned out that in practice
>> one way of implementing them -- generators -- wa
Greg Ewing <[EMAIL PROTECTED]> writes:
> Are there any objective reasons to prefer a generator
> implementation over a thunk implementation?
I, too, would like to see an answer to this question.
I'd like to see an answer in the PEP, too.
Cheers,
mwh
--
All obscurity will buy you is time eno
Guido van Rossum <[EMAIL PROTECTED]> writes:
> [Greg Ewing]
>> Elegant as the idea behind PEP 340 is, I can't shake
>> the feeling that it's an abuse of generators. It seems
>> to go to a lot of trouble and complication so you
>> can write a generator and pretend it's a function
>> taking a block
Brian Sabbey <[EMAIL PROTECTED]> writes:
> It is possible to implement thunks without them creating their own
> frame. They can reuse the frame of the surrounding function. So a new
> frame does not need to be created when the thunk is called, and, much
> like with a yield statement, the frame is
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Paul Svensson wrote:
>> On Tue, 3 May 2005, Nick Coghlan wrote:
>>
>>> I'd also suggest that the blocktemplate decorator accept any iterator,
>>> not just
>>> generators.
>>
>>
>> So you want decorators on classes now ?
>
> A decorator is just a funct
Nicholas Bastin <[EMAIL PROTECTED]> writes:
> The current documentation for Py_UNICODE states:
>
> "This type represents a 16-bit unsigned storage type which is used by
> Python internally as basis for holding Unicode ordinals. On platforms
> where wchar_t is available and also has 16-bits, P
"Edward C. Jones" <[EMAIL PROTECTED]> writes:
> Recently I needed some information about the floating point numbers on
> my machine. So I wrote a tiny C99 program with the line
>
> printf("%a\n", DBL_EPSILON);
>
> The answer was "0x1p-52".
>
> A search of comp.lang.python shows that I was not alo
"Shane Holloway (IEEE)" <[EMAIL PROTECTED]> writes:
> And per the PEP, I think the explaining that::
>
> try:
> A
> except:
> B
> else:
> C
> finally:
> D
>
> is *exactly* equivalent to::
>
> try:
> try:
> A
>
Chris Ryland <[EMAIL PROTECTED]> writes:
> In this case, "while" is the better time-related prefix, whether
Indeed.
while_execution_is_lexically_in_the_next_block lock(theLock):
...
Anyone? .
Cheers,
mwh
--
Every day I send overnight packages filled with rabid weasels to
people who u
Paul Moore <[EMAIL PROTECTED]> writes:
> On 5/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Well, Michael Hudson and Paul Moore are the current authors of PEP 310, so
>> updating it with any of my ideas would be their call.
>
> I'm willing to consider a
Jp Calderone <[EMAIL PROTECTED]> writes:
> If such a construct is to be introduced, the ideal spelling would seem to
> be:
>
> for [VAR in] EXPR:
> BLOCK1
> finally:
> BLOCK2
Does this mean that adding
finally:
pass
to a for block would make the for loop
Guido van Rossum <[EMAIL PROTECTED]> writes:
> Apologies if this has been discovered and rejected already; I've had
> to skip most of the discussions but this though won't leave my head...
>
> So PEP 310 proposes this:
>
> with VAR = EXPR:
> BLOCK
>
> translated to
>
>
Suleiman Souhlal <[EMAIL PROTECTED]> writes:
> Hello,
>
> While investigating why the script used in http://docs.freebsd.org/
> cgi/getmsg.cgi?fetch=148191+0+current/freebsd-stable used so much
> system time on FreeBSD 5, I noticed that python is continually
> calling sigprocmask(), as can be
Guido van Rossum <[EMAIL PROTECTED]> writes:
> [Steven Bethard]
>> I have a feeling that it might actually be easier to continue to
>> document try/except and try/finally separately and then just give the
>> semantics of try/except/finally in terms of the other semantics. Take
>> a look at the Ja
Guido van Rossum <[EMAIL PROTECTED]> writes:
> I just read Raymond Chen's rant against control flow macros:
> http://blogs.msdn.com/oldnewthing/archive/2005/01/06/347666.aspx
>
> I think this pretty much kills PEP 340, as well as Nick Coghlan's
> alternative: both proposals let you write a "templa
Guido van Rossum <[EMAIL PROTECTED]> writes:
> [Michael Hudson, after much thinking aloud]
Yeah, sorry about that :)
>> Oh, I guess the point is that with a decorated generator you can yield
>> a value to be used as VAR, rather than just discarding the value as
>>
Greg Ewing <[EMAIL PROTECTED]> writes:
> Guido van Rossum wrote:
>
>> PEP 340 is still my favorite, but it seems there's too much opposition
>> to it,
>
> I'm not opposed to PEP 340 in principle, but the
> ramifications seemed to be getting extraordinarily
> complicated, and it seems to be hamstru
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> 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,
Uh, that's not what he meant:
/>> class C:
|.. def __del__(self):
|.
Walter Dörwald <[EMAIL PROTECTED]> writes:
> Ka-Ping Yee wrote:
>
>> [...]
>> (a) ban string exceptions
>> (b) require all exceptions to derive from Exception
>> (c) ban bare "except:"
>> (d) eliminate sys.exc_*
>
> I think somewhere in this list should be:
>
>(?) Remove st
Skip Montanaro <[EMAIL PROTECTED]> writes:
> mwh> Fix test_site to not call open('...', 'wU'), as that now raises an
> mwh> error.
>
> mwh> Is anyone running the test suite regularly at the moment?
>
> Whoops. I obviously failed to run it after applying that change. My
> apologies.
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> There should be some greater care exercised in closing old bugs.
Possibly. OTOH, we have something like 900 open bugs to work on, and
it's not like bug reporters can't re-open a bug report if they think
it's been closed in error (this has happene
Nick Coghlan <[EMAIL PROTECTED]> writes:
> It also considers the possibility of using with statements in an RAII
> style by acquiring the resource in __init__ or __new__ rather than
> __enter__.
While you can probably do this (after all, most of the time
__new__/__init__ and __enter__ will be ca
Michael McLay <[EMAIL PROTECTED]> writes:
> I think this would be feature creep. It complicates the language
> for a very small gain. While the added syntax would be intuitive, it
> only saves a line or two over the existing syntax.
FWIW, this is my opinion too (and I've written a bunch of while
I've just fixed a bug where Py_INCREF wasn't called when it should
have been before a call to PyModule_AddObject (rev. 2.62 of
Modules/threadmodule.c).
So I went looking for other instances of the same problem. I didn't
find any (though I don't understand how _csv.c gets away with line
1579), but
Skip Montanaro <[EMAIL PROTECTED]> writes:
> Michael> So I went looking for other instances of the same problem. I
> Michael> didn't find any (though I don't understand how _csv.c gets away
> Michael> with line 1579)...
>
> Same reason the Py_INCREF of ProfileError isn't necessary I t
Armin Rigo <[EMAIL PROTECTED]> writes:
> Hi Michael,
>
> On Wed, Jun 15, 2005 at 01:35:35PM +0100, Michael Hudson wrote:
>> if (ProfilerError == NULL)
>> ProfilerError = PyErr_NewException("hotshot.ProfilerError",
>>
Armin Rigo <[EMAIL PROTECTED]> writes:
> Hi Skip,
>
> On Wed, Jun 15, 2005 at 06:35:10AM -0700, [EMAIL PROTECTED] wrote:
>> Why this worked is a bit mystical. Perhaps it never gets freed because the
>> object just happens never to be DECREF'd (but that seems unlikely).
>> /* Add the Dial
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> if (ProfilerError == NULL)
>> ProfilerError = PyErr_NewException("hotshot.ProfilerError",
>>
Steven Bethard <[EMAIL PROTECTED]> writes:
> On 6/15/05, Benji York <[EMAIL PROTECTED]> wrote:
>> Steven Bethard wrote:
>> > I would prefer that the alternate iter() form was broken off into
>> > another separate function, say, iterfunc(), that would let me write
>> > Jp's solution something like:
Jeremy Maxfield <[EMAIL PROTECTED]> writes:
> The current threadmodule.c does not seem to correctly support multiple
> (sub) interpreters.
This would seem to be an accurate statement.
A short history:
The GILState functions were implemented.
The way they work is that when you call PyGILState_E
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>> I've been looking at this area partly to try and understand this bug:
>>
>> [ 1163563 ] Sub threads execute in restricted mode
>>
>> but I'm not sure the who
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> I recommend that the proposed syntax be altered to be more parallel
> with the existing for-loop syntax to make it more parsable for both
> humans and for the compiler.
Although all your suggestions are improvments, I'm still -1 on the PEP.
Cheer
Keith Dart <[EMAIL PROTECTED]> writes:
> I am very concernced about something. The following code breaks with 2.4.1:
>
> fcntl.ioctl(self.rtc_fd, RTC_RD_TIME, ...)
>
> Where RTC_RD_TIME = 2149871625L
>
> In Python 2.3 it is -2145095671.
Well, you could always use "-2145095671"...
> Actually, thi
Greg Ewing <[EMAIL PROTECTED]> writes:
> Guido van Rossum wrote:
>
>> There's also the consideration for APIs that, informally, accept
>> either a string or a sequence of objects.
>
> My preference these days is not to design APIs that
> way. It's never necessary and it avoids a lot of
> problems.
Guido van Rossum <[EMAIL PROTECTED]> writes:
> OTOH, even if we didn't rename str/unicode to text, opentext would
> still be a good name for the function that opens a text file.
Hnnrgh, not really. You're not opening a 'text', nor are you
constructing something that might reasonably be called an
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> > OTOH, even if we didn't rename str/unicode to text, opentext would
>> > still be a good name for the function that opens a text file.
>>
>> Hnnrgh, not really.
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> It's only me that's allowed to top-post. :-)
At least you include attributions these days!
Cheers,
mwh
--
SPIDER: 'Scuse me. [scuttles off]
ZAPHOD: One huge spider.
FORD: Polite though.
-- The Hitch-Hikers Guide to
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> I'm torn. While trying to implement this I came across some ugliness
> in PyDict_GetItem() -- it would make sense if this also called
> on_missing(), but it must return a value without incrementing its
> refcount, and isn't supposed to raise excepti
This posting is entirely tangential. Be warned.
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> It's worse than that. The return *type* depends on the *value* of
> the argument. I think there is little precedence for that:
There's one extremely significant example where the *value* of
something
"Neal Norwitz" <[EMAIL PROTECTED]> writes:
> http://www.python.org/dev/buildbot/
Wow, that's very cool!
Cheers,
mwh
--
this "I hate c++" is so old
it's as old as C++, yes
-- from Twisted.Quotes
__
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> Martin v. Löwis wrote:
>> M.-A. Lemburg wrote:
> True. However, note that the .encode()/.decode() methods on
> strings and Unicode narrow down the possible return types.
> The corresponding .bytes methods should only allow bytes and
> U
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Tim Peters wrote:
>> Speaking of which, a number of test failures over the past few weeks
>> were provoked here only under -r (run tests in random order) or under
>> a debug build, and didn't look like those were specific to Windows.
>> Adding -r to
"Travis E. Oliphant" <[EMAIL PROTECTED]> writes:
> I'm seeing strange behavior in the Python 2.5a0 trunk that is causing
> the tests for numpy to fail. Apparently obj[...] = 1 is not calling
> PyObject_SetItem
>
> Here is a minimal example to show the error. Does anyone else see this?
>
> clas
[EMAIL PROTECTED] writes:
> Greg> except as :
>
> Baptiste> except with :
>
> Can I catch multiple exceptions with a single value in this case? Today, I
> write:
>
> try:
> foo()
> except (TypeError, KeyError), msg:
> print msg
>
> Either of the above seem like t
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> The ssize_t patch is the single most disruptive patch in
> Python 2.5, so it deserves special attention.
>From your POV, maybe: from mine, it's definitely the new compiler.
Cheers,
mwh
--
I reject that approach. It has a suspicious lack
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> > The ssize_t patch is the single most disruptive patch in
>> > Python 2.5, so it deserves special attention.
>>
>> From your POV, maybe: from mine, it's definitel
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> neal.norwitz wrote:
>
>> +Outstanding Issues
>> +==
>> +
>> +* Require C99, so we can use // comments, named initializers, declare
>> variables
>> + without introducing a new scope, among other benefits.
>
> gcc only, in other words ?
Armin Rigo <[EMAIL PROTECTED]> writes:
> Hi Neal,
>
> On Sun, Mar 26, 2006 at 11:39:50PM -0800, Neal Norwitz wrote:
>> test_pkg leaked [10, 10, 10] references
>
> This one at least appears to be caused by dummy (deleted) entries in the
> dictionary of interned strings. So it is not really a leak.
"Chris AtLee" <[EMAIL PROTECTED]> writes:
> On 3/28/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>> We've made a lot of improvement with testing over the years.
>> Recently, we've gotten even more serious with the buildbot, Coverity,
>> and coverage (http://coverage.livinglogic.de). However, in or
"Thomas Wouters" <[EMAIL PROTECTED]> writes:
> While we're at it, I would like for the new __del__ (which would
> probably have to be a new method) to disallow reviving self, just
> because it makes it unnecessarily complicated and it's rarely
> needed.
I'm not sure the problem is so much that an
Greg Ewing <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> And if we want to have a version of __del__ that can't reference
>> 'self', we have it already: weakrefs with callbacks.
>
> Does that actually work at the moment? Last I hear
"Tim Peters" <[EMAIL PROTECTED]> writes:
> [Michael Hudson]
>> ...
>> What happened to the 'get rid of __del__ in py3k' idea?
>
> Apart from its initial mention, every now & again someone asks what
> happened to it :-).
Good enough
"Neal Norwitz" <[EMAIL PROTECTED]> writes:
> On 4/3/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
>> Greg Ewing <[EMAIL PROTECTED]> writes:
>>
>> > Michael Hudson wrote:
>> >
>> >> And if we want to have a version of __d
"Tim Peters" <[EMAIL PROTECTED]> writes:
> _Perhaps_ it's the case that doubles are aligned to an 8-byte boundary
> when socketmodule.c is compiled, but (for some unknown reason) only to
> a 4-byte boundary when _ssl.c is compiled. Although that seems to
> match the details in the bug report, I h
"A.M. Kuchling" <[EMAIL PROTECTED]> writes:
> On Thu, Apr 20, 2006 at 07:53:55AM +0200, "Martin v. Löwis" quoted:
>> > It is flatly not possible to "fix" distutils and preserve backwards
>> > compatibility.
>
> Would it be possible to figure what parts are problematic, and
> introduce PendingDepr
"Neil Hodgson" <[EMAIL PROTECTED]> writes:
> Martin v. Löwis:
>
>> Apparently, the status of this changed right now: it seems that
>> the 2003 compiler is not available anymore; the page now says
>> that it was replaced with the 2005 compiler.
>>
>> Should we reconsider?
>
>I expect Microsoft
Gerhard Häring <[EMAIL PROTECTED]> writes:
> Currently I'm not subscribed to python-checkins and didn't see a need
> to. Is there a need to for Python core developers?
I would say it's "encouraged".
> I think there's no better way except subscribing and defining a
> filter for SQLite-related c
"Thomas Wouters" <[EMAIL PROTECTED]> writes:
> Neal and I wrote a few tests that exercise the Py_ssize_t code on 64bit
> hardware:
>
> http://python.org/sf/1471578
>
> Now that it's configurable and integrated with test_support and all, we
> think it's time to include it in the normal testsuite. I
"Neal Norwitz" <[EMAIL PROTECTED]> writes:
> Here's what's left for 2.5 after the most recent go around.
>
> There's no owner for these items. If no one takes them, they won't
> get done and I will move them to deferred within a week:
>
> * Add @decorator decorator to functional, rename to func
Sean Reifschneider <[EMAIL PROTECTED]> writes:
> We're working at the sprint on tracking this down. I want to provide some
> history first and then what we're looking for feedback on.
>
> Steve Holden found this on Sunday, the pybench try/except test shows a ~60%
> slowdown from 2.4.3 to 2.5a2.
"Thomas Wouters" <[EMAIL PROTECTED]> writes:
> Does 'a tuple containing two Nones, a string and an int' ring a bell to
> anyone? :)
I found this one on the train (look at SyntaxError_init, it's
obvious). I also found a number of other bugs in the new exceptions.c
code, from leaks:
>>> def f():
Georg Brandl <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> So I think I'll be reading through exceptions.c pretty carefully. I
>> don't think Sean and Richard have acquired as much paranoid
>> anal-mindedness and I have when hacking on Python
Georg Brandl <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>> Georg Brandl <[EMAIL PROTECTED]> writes:
>>
>>> Michael Hudson wrote:
>>>
>>>> So I think I'll be reading through exceptions.c pretty carefully. I
>>>
Michael Hudson <[EMAIL PROTECTED]> writes:
> I think I've fixed the refleaks too, but running regrtest -R :: takes
> rther a while.
I hadn't: test_codecs and test_codeccallbacks both leak, the latter
quite spectacularly (9000+ refleaks a run). The test_codecs le
Anthony Baxter <[EMAIL PROTECTED]> writes:
> On Friday 02 June 2006 02:21, Jack Diederich wrote:
>> The CCP Games CEO said they have trouble retaining talent from more
>> moderate latitudes for this reason. 18 hours of daylight makes
>> them a bit goofy and when the Winter Solstice rolls around t
Greg Ewing <[EMAIL PROTECTED]> writes:
> Tim Peters wrote:
>
>> I liked benchmarking on Crays in the good old days. ...
> > Test times were reproducible to the
>> nanosecond with no effort. Running on a modern box for a few
>> microseconds at a time is a way to approximate that, provided you
"Thomas Wouters" <[EMAIL PROTECTED]> writes:
> On 6/4/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
> [ For non-checkins readers: Martin Blais checked in un-unittestification
> of test_struct, which spawned questions form Neal and me about whether
> that'
"Neal Norwitz" <[EMAIL PROTECTED]> writes:
> It's June 9 in most parts of the world. The schedule calls for beta 1
> on June 14. That means there's less than 4 days until the expected
> code freeze. Please don't rush to get everything in at the last
> minute. The buildbots should remain green
Fredrik Lundh <[EMAIL PROTECTED]> writes:
> I just ran the PIL test suite using the current Python trunk, and the
> tests for a user-contributed plugin raised an interesting exception:
>
> ValueError: can't unpack IEEE 754 special value on non-IEEE platform
>
> fixing this is easy, but the error
Nick Maclaren <[EMAIL PROTECTED]> writes:
> As I have posted to comp.lang.python, I am not happy with Python's
> numerical robustness - because it basically propagates the 'features'
> of IEEE 754 and (worse) C99.
That's not really now I would describe the situation today.
> Yes, it's better, b
Anthony Baxter <[EMAIL PROTECTED]> writes:
> A question has been asked about branching release25-maint at the time
> of beta1. I was actually thinking about doing this for 2.5rc1 - once
> we're in release candidate stage we want to really be careful about
> checkins. I'm not sure it's worth bra
This mail never appeared on python-dev as far as I can tell, so I'm
not snipping anything.
On 19 Jun 2006, at 16:29, Nick Maclaren wrote:
> Michael Hudson <[EMAIL PROTECTED]> wrote:
>>
>>> As I have posted to comp.lang.python, I am not happy with Python's
>
Nick Maclaren <[EMAIL PROTECTED]> writes:
> Michael Hudson <[EMAIL PROTECTED]> wrote:
>>
>> This mail never appeared on python-dev as far as I can tell, so I'm
>> not snipping anything.
>
> And it still hasn't :-( I am on the list of recip
Nick Maclaren <[EMAIL PROTECTED]> writes:
>> > My intentions are to provide some numerically robust semantics,
>> > preferably of the form where straightforward numeric code (i.e. code
>> > that doesn't play any bit-twiddling tricks) will never invoke
>> > mathematically undefined behaviour withou
101 - 200 of 332 matches
Mail list logo
