& 0x8
...and I suspect (experimentation seems to confirm this) that if you mangle
these then the code object won't work correctly. If anyone's got a
suggestion for fixing this, I'd love to hear it.
-- Michael Chermside
___
Python-De
"Edward C. Jones" <[EMAIL PROTECTED]> writes:
> I had
>
> PyArg_ParseTuple(args, "s#s#i:compare", &p1, &bytes1, &p2, &bytes2)
>
> in a program. There are not enough arguments to PyArg_ParseTuple. Does
> PyArg_ParseTuple know how many arguments it is getting?
I don't think so.
> If so, I suggest
s (besides which, we'd still need to handle the empty list). So
I'm in favor of REMOVING the second argument of sum() for python 3000,
unless it was kept purely for "backward compatibility" reasons, which
would be defeated by changing it&#x
h generic types:
def sum(seq: sequence[T], initial: T = T()) -> T.
Cheers,
Michael
___
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
e perfectly acceptable
to make require an argument for union types T. Maybe T() should only
be valid for non-union types. Several questions like "when should T()
be evaluated" [1], "how can we avoid ': T = T()' leading to a type
error" and "how about optional
On Thu, 17 Mar 2005 14:34:23 +1300, Greg Ewing
<[EMAIL PROTECTED]> wrote:
> Not to mention that if the seq is empty, there's no
> way of knowing what T to instantiate...
You just use the same T as inferred for seq : sequence[T] .
Michael
_
people normally want to do with classes (like support
for inheritance.
But a few *good* use cases would change my mind.
-- Michael Chermside
___
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
Adam MacBeth <[EMAIL PROTECTED]> writes:
> Has anyone ever considered using SCons to build Python?
Well, er, there's an obvious problem here somewhere...
> SCons is a great build tool written in Python that provides some
> Autoconf-like functionality (http://www.scons.org). It seems like
> this
[EMAIL PROTECTED] writes:
> Update of /cvsroot/python/python/dist/src/Modules
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10274
>
> Modified Files:
> readline.c
> Log Message:
> Fixes for
>
> [ 110 ] The readline module can cause python to segfault
>
> It seems to me that th
Asking mostly for curiousity, how hard would it be to have longs store
their sign bit somewhere less aggravating? It seems to me that the
top bit of ob_digit[0] is always 0, for example, and I'm sure this
would result no less convolution in longobject.c it'd be considerably
more localized convolut
Tim Peters <[EMAIL PROTECTED]> writes:
> [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[
Michael Hudson <[EMAIL PROTECTED]> writes:
> Tim Peters <[EMAIL PROTECTED]> writes:
>
>> [Michael Hudson]
>>> Asking mostly for curiousity, how hard would it be to have longs store
>>> their sign bit somewhere less aggravating?
>>
>> Dep
I recently redid how the readline module handled threads around
callbacks into Python (the previous code was insane).
This resulted in the following bug report:
http://www.python.org/sf/1176893
Which is correctly assigned to me as it's clearly a result of my
recent checkin. However, I think
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
code
>
> Would it be useful for anything other than mutex-locking? And wouldn't
> it be better to make a function of the block wrapped in a
> block-decorator and then use a normal decorator?
Yes. Check how blocks in Smalltalk and Ruby are used for starters.
Regards,
Michael
_
xpr_33.p
* L-System definition: http://www.cerenity.org/SWP/progs/expr_34.p
* SML-like: http://www.cerenity.org/SWP/progs/expr_35.p
* Amiga E/Algol like: http://www.cerenity.org/SWP/progs/expr_37.p
Needs the modified version of PLY installed first, and the tests can be run
using
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
before I could begin to consider it.
If I understand it properly, pattern matching in Haskell relies
primarily on Haskell's excellent typing system, which is absent in
Python.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
htt
On 4/21/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Michael Chermside wrote:
> > Now the pattern matching is more interesting, but again, I'd need to
> > see a proposed syntax for Python before I could begin to consider it.
> > If I understand it properly, pa
at your syntax lacks most of the power of Haskell's pattern matching.
First of all, it can only match tuples ... most things in Python are
NOT tuples. Secondly (as Michael Walter explained) it doesn't allow
name binding to parts of the pattern.
Honestly, while I understand that pattern match
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
t make it easier to evaluate syntax suggestions. And
if the answer is that we want to prohibit nothing, then the right
solution is macros.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
I'd be happy with a function-call like syntax
for including the macro.
Well, that's a lot of "wanting"... now I all I need to do is invent a
clever syntax that allows these in an elegant fashion while also solving
Guido's point about imports (hint: the answer is that it ALL happens at
runtime). I'll go think some while you guys zoom past me again.
-- Michael Chermside
___
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
y prove someone's point that the
language designer shouldn't allow people to do such things. I'm sure
other people are more mature or at least less tired than me, though,
so I beg to differ :-),
Michael
On 4/25/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> It seems that
surely all of
these tricks (hacks) are way harder to use than a EDSL would be.
Regards,
Michael
___
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
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
default() |y = 4
is the repetition of "x ==" and of "y =". As my earlier example
demonstrates, a structure like this in which the "x ==" or the
"y =" VARIES has a totally different *meaning* to the programmer
than one in which the "x =="
:
> abnormal case...
> else:
> ...edge case...
>
> The salient example! If it's no accident that those conditions are
> mutually exclusive and exhaustive, doesn't that code require at least
> a comment saying so, and maybe even an assertion to tha
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
ttp://python.org/peps/pep-0340.html";)
print f.read()
5. It is possible to nest blocks and combine templates:
try with_lock(myLock):
try opening("/etc/passwd") as f:
for line in f:
print line.rstrip()
Michael
__
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
>>
ed convince me that allowing the use of generators
instead of classes with the "do_template" decorator is quite nice in
practice, even though it gets confusing (for beginners anyhow) if you
start to think about it too much.
-- Michael Chermside
# = SAMPLE #1: increasing preci
be done with higher precision, AND causes any variables set during
the block will retain their higher precision. (It's because context
controls OPERATIONS but changing context never affects individual
Decimal OBJECTS.) So I fear that the whole with_extra_precision()
idea is just likely to tempt
If you need a volunteer to code this - should it go through, I'm willing to
have a go at this. (I can't do this though for 3 weeks or so though due to a
crunch at work, and I might be in over my head in offering this.)
Michael.
--
Michael Sparks, Senior R&D Engineer, Digit
thought "Well, what's the harm in letting the variable
survive the 'with' statement?" I'm a big fan of keeping namespaces
"clean", but it's just not important enough to incurr other penalties.
So in this case, I (reluctantly, after givin
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
oing nothing. I CLEARLY intended to
do the appropriate cleanup (or locking, or whatever), but it doesn't
happen.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
"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
ct context precision?
(By the way... even if other constructors begin to respect context
precision, the constructor from tuple should NOT -- it exists to provide
low-level access to the implementation. I'll express no opinion on the
constructor from Decimal, because I don't understand the
an't make more time for this now.
I understand!
> The short course is that
> a module purporting to implement an external standard should not
> deviate from that standard without very good reasons
Yes, but should we think of the constructor-from-string
object:
>>> import decimal
>>> decimal.getcontext().prec = 4
>>> decimal.getcontext().create_decimal("1.234567890")
Decimal("1.235")
Frankly, I have no idea WHAT purpose is served by passing a context
to the decimal constructor... I didn
ds, make FULL use of the context in the constructor if a context
is provided, but make NO use of the thread context when no context is
provided.
--
One final point... Thanks to Mike Cowlishaw for chiming in with a detailed
and well-considered explanation of his thoughts on the matter.
-- M
ver something new
goes wrong. This is the only way I've found to work around the
problem in Java. Wouldn't it be nice if Python could do better?
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
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
and there are only 5-10 open bugs, we
can send intrepid volunteers digging through the archives to examine
bugs that got closed without proper investigation. I'm not holding my
breath.
-- Michael Chermside
___
Python-Dev mailing list
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
e side effect going on here, I don't see it. What
am I missing?
-- Michael Chermside
___
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
4-10 values though, so
O(1) and O(n) may not be THAT different. It's one of those cases where the
only thing I'd really believe was experiments done on real code. But it's
a cool optimization if it actually pays off.
-- Michael Chermside
___
Py
On Monday 13 June 2005 08:07, Nick Coghlan wrote:
> Raymond Hettinger wrote:
> > [BJörn Lindqvist]
> >
> >>I would like to have do-while's like this:
> >>
> >>do:
> >>
> >>until
> >>
> >>But I'm sure that has problems too.
> >
> > That looks nice to me.
>
> And this could easily be extende
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'v
I'm attempting to switch from 2.3.2 to 2.4.1 on our AIX 4.3 development system.
I have no problems building Python 2.3.2. I build Python 2.4.1 using
'configure --without-threads; gmake; gmake test', and always get a coredump
during the tests on 'test_exceptions'. I've searched for any reports of
code I immediately thought that it WAS the
straightforward way to write that code, and that I was just not
smart enough to have realized it until he showed me.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
> f2.write(chunk)
What ever happened to "Not every 3 line function needs to be a builtin"?
It's a common pattern. It's easy to do. Where's the problem?
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@py
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
he last
three years and have loved almost every minute of it. I've written
sequence alignment algorithms in Pyrex, glue to genome database APIs
in Jython, and a whole lot of other stuff using CPython. We run Python
on a 1145-CPU compute farm that consists of Alpha/Tru64 and
Intel/Linux boxes.
--
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_
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
ps if you're taking the approach for generator
composition if you're using twisted.flow (though I'll defer a good example
for that to someone else since although I've been asked for a comparison in
the past, I don't think I'm sufficiently twisted to do so!).
Michael.
1401 - 1500 of 1850 matches
Mail list logo
