Neal Norwitz gmail.com> writes:
>
> Can you call PyMem_FREE() without the GIL held? I couldn't find it
> documented either way.
Nope. See comments at the top of Python/pystate.c.
Cheers,
mwh
___
Python-Dev mailing list
Python-Dev@python.org
http:/
Giovanni Bajo <[EMAIL PROTECTED]> writes:
> On 23/01/2007 10.20, Brian Warner wrote:
>
Do I miss something here, or is the buildbot hit by spammers now?
>>> It looks like it is. If that continues, we have to disable the web
>>> triggers.
>>
>> Good grief. If anyone has any bright ideas about
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Bug #1579370 reports a crash when accessing the thread state of
> a terminated thread, when releasing a generator object.
>
> In analysing the problem, I found that f_tstate doesn't have much
> utility: it is used in very few places, and in these pla
Nick Coghlan <[EMAIL PROTECTED]> writes:
> Neil Toronto wrote:
>> I imagine this would be important to someone expecting system resources
>> to be cleaned up, closed, deallocated, or returned inside of __del__
>> methods. Someone coming from C++ might expect LIFO behavior because
>> common idio
[EMAIL PROTECTED] writes:
> On 10:12 am, [EMAIL PROTECTED] wrote:
>
>>For practical reasons (we have enough work to be getting on with) PyPy
>>is more-or-less ignoring Python 2.5 at the moment. After funding and
>>so on, when there's less pressure, maybe it will seem worth it. Not
>>soon though.
Georg Brandl <[EMAIL PROTECTED]> writes:
> Armin Rigo schrieb:
>> Hi Paul,
>>
>> On Wed, Jan 10, 2007 at 11:10:10PM +, Paul Moore wrote:
>>> How many other projects/packages anticipate *not* migrating to Py3K, I
>>> wonder?
>>
>> FWIW: Psyco.
>
> What will PyPy do? It will certainly support
Giovanni Bajo <[EMAIL PROTECTED]> writes:
> Hello,
>
> I spent my last couple of hourse reading several past threads about fpectl.
> If
> I'm correct
>
> 1) fpectl is scheduled for deletion in 2.6.
> 2) The biggest problem is that the C standard says that it's undefined to
> return from a SIGFP
Hopefully by now you have heard of the "Summer of PyPy", our program
for funding the expenses of attending a sprint for students. If not,
you've just read the essence of the idea :-)
However, the PyPy EU funding period is drawing to an end and there is
now only one sprint left where we can sponso
"Mike Klaas" <[EMAIL PROTECTED]> writes:
> [http://sourceforge.net/tracker/index.php?func=detail&aid=1579370&group_id=5470&atid=105470]
>
> Hello,
>
> I'm managed to provoke a segfault in python2.5 (occasionally it just a
> "invalid argument to internal function" error). I've posted a
> traceback
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Kristján V. Jónsson schrieb:
>> I can't see how this situation is any different from the re-use of
>> low ints. There is no fundamental law that says that ints below 100
>> are more common than other, yet experience shows that this is so,
>> and so
[EMAIL PROTECTED] writes:
> I hope that eventually Python will include some form of OO
> filesystem access, but I am equally hopeful that the current PEP 355
> path.py is not it.
I think I agree with this too. For another source of ideas there is
the 'py.path' bit of the py lib, which, um, doesn
"Neal Norwitz" <[EMAIL PROTECTED]> writes:
> I ignored these as I'm not certain all the platforms we run on accept
> free(NULL).
It's mandated by C99, and I don't *think* it changed from the previous
version (I only have a bootleg copy of C99 :).
Cheers,
mwh
--
TRSDOS: Friendly old lizard. O
Milan Krcmar <[EMAIL PROTECTED]> writes:
> I would like to run Python scripts on an embedded MIPS Linux platform
> having only 2 MiB of flash ROM and 16 MiB of RAM for everything.
>
> Current (2.5) stripped and gzipped (I am going to use a compressed
> filesystem) CPython binary, compiled with def
Anthony Baxter <[EMAIL PROTECTED]> writes:
> I'd like to propose that the AST format returned by passing PyCF_ONLY_AST to
> compile() get the same guarantee in maintenance branches as the bytecode
> format - that is, unless it's absolutely necessary, we'll keep it the same.
> Otherwise anyone t
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Michael Hudson schrieb:
>>> According to [1], all python needs to do to avoid this problem is
>>> block all signals in all but the main thread;
>>
>> Argh, no: then people who call system() from non
On 11 Sep 2006, at 09:34, Neal Norwitz wrote:
> Michael,
>
> In Python/pystate.c, you made this checkin:
>
> """
> r39044 | mwh | 2005-06-20 12:52:57 -0400 (Mon, 20 Jun 2005) | 8 lines
>
> Fix bug: [ 1163563 ] Sub threads execute in restricted mode
> basically by fixing bug 1010677 in a non-brok
"Michael Urman" <[EMAIL PROTECTED]> writes:
> Hi folks,
>
> Between 2.4 and 2.5 the behavior of file or open with the mode 'wU'
> has changed. In 2.4 it silently works. in 2.5 it raises a ValueError.
> I can't find any more discussion on it in python-dev than tangential
> mentions in this thread:
"Gustavo Carneiro" <[EMAIL PROTECTED]> writes:
> On 9/4/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
>> "Gustavo Carneiro" <[EMAIL PROTECTED]> wrote:
>> > I am now thinking of something along these lines:
>> > typedef void (*PyPendingCallNotify)(void *user_data);
>> > PyAPI_FUNC(void) Py_AddPend
"Gustavo Carneiro" <[EMAIL PROTECTED]> writes:
> According to [1], all python needs to do to avoid this problem is
> block all signals in all but the main thread;
Argh, no: then people who call system() from non-main threads end up
running subprocesses with all signals masked, which breaks other
"A.M. Kuchling" <[EMAIL PROTECTED]> writes:
> On Mon, Aug 21, 2006 at 12:24:54PM -0700, Brett Cannon wrote:
>> As for the docs, they just need a thorough updating.
>
> Michael Hudson was working on a new guide to extending/embedding
> Python. Incorporating
"Jim Jewett" <[EMAIL PROTECTED]> writes:
>> It wasn't my idea to stop ignoring exceptions in dict lookups; I would
>> gladly have put this off until Py3k, where the main problem
>> (str-unicode __eq__ raising UnicodeError) will go away.
>
>> But since people are adamant that they want this in soon
Neal Becker <[EMAIL PROTECTED]> writes:
> 1) Should assignment to a temporary object be allowed?
The question doesn't make sense: in Python, you assign to a name,
an attribute or a subscript, and that's it.
Cheers,
mwh
--
I think there's a rather large difference between a stale
Michael Chermside <[EMAIL PROTECTED]> writes:
> I'm changing the subject line because I want to convince everyone that
> the problem being discussed in the "unicode hell" thread has nothing
> to do with unicode and strings. It's all about dicts.
I'd say it's more to do with __eq__. It's a strang
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> The point here is that a typical user won't expect any comparisons
> to be made when dealing with dictionaries, simply because the fact
> that you do need to make comparisons is an implementation detail.
Of course looking things up in a dictionary inv
Duncan Booth <[EMAIL PROTECTED]> writes:
> Does Coverity recognise objects on Python's internal pools as deallocated?
Coverity doesn't work on that level; it analyzes source code, and
knows about Python's INCREFs and DECREFs.
> The moral is to regard the reference counting rules as law: no matt
David Hopwood <[EMAIL PROTECTED]> writes:
> Armin Rigo wrote:
>> Hi,
>>
>> There is an oversight in the design of __index__() that only just
>> surfaced :-( It is responsible for the following behavior, on a 32-bit
>> machine with >= 2GB of RAM:
>>
>> >>> s = 'x' * (2**100) # works!
>
Anthony Baxter <[EMAIL PROTECTED]> writes:
> On Friday 28 July 2006 15:32, Raymond Hettinger wrote:
>> I suggest that there be a third beta release and that we then wait
>> just a bit before going final.
>>
>> The bugs that were found and fixed in the first two beta releases
>> suggest that Py2.5
"Neal Norwitz" <[EMAIL PROTECTED]> writes:
> On 7/25/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> >
>> > Yes, I definitely think dropping the X would make the warning go away.
>> > Do we want to check for a NULL pointer and raise an exception? The
>> > docs don't address the issue, so I th
The next PyPy sprint will happen in the nice city of
Limerick in Ireland from 21st till 27th August.
(Most people intend to arrive 20th August).
The main focus of the sprint will be on JIT compiler works,
various optimization works, porting extension modules,
infrastructure works like a buil
[EMAIL PROTECTED] writes:
> I just would have appreciated the opportunity to participate in the
> discussion before the betas were out and the featureset frozen.
I think something that has happened to some extent with this release
is that there was a long-ish period where stuff got discussed and
No real time to respond in detail here, but one small comment.
[EMAIL PROTECTED] writes:
> I see some responses to that post which indicate that the specific bug will be
> fixed, and that's good, but there is definitely a pattern he's talking about
> here, not just one issue. I think there is a
"A.M. Kuchling" <[EMAIL PROTECTED]> writes:
> On Mon, Jul 10, 2006 at 05:13:53PM +0200, Armin Rigo wrote:
>> didn't draw much applause. It certainly gave me the impression that
>> many changes in Python are advocated and welcomed by only a small
>> fraction of users.
>
> The benefits of changes a
Ka-Ping Yee <[EMAIL PROTECTED]> writes:
> Client-side web scripting tends to have a callback/continuation-ish
> concurrency style because it has to deal with network transactions
> (which can stall for long periods of time) in a user interface that
> is expected to stay always responsive. The Fir
Michael Chermside <[EMAIL PROTECTED]> writes:
> Phillip Eby writes:
>> I don't see a problem with requiring '.x' to be used for both
>> reading and writing of outer-scope names; it just shouldn't be
>> required for an outer-scope name that you don't rebind in the
>> current scope.
>>
>>
Ka-Ping Yee <[EMAIL PROTECTED]> writes:
> On Fri, 30 Jun 2006, Neal Norwitz wrote:
>> The current list of serious bugs are in the PEP:
>>
>> http://www.python.org/dev/peps/pep-0356/
>
> Among them is this one:
>
> Incorrect LOAD/STORE_GLOBAL generation
> http://python.org/sf/1501934
>
>
"Brett Cannon" <[EMAIL PROTECTED]> writes:
> If you look at that crasher, you will notice that recursion depth is set
> to 1 << 30 before any code is run. If you remove that setting high
> setting and go with the default then the test doesn't crash and raises the
> appropriate RuntimeError.
>
> S
Benji York <[EMAIL PROTECTED]> writes:
> Nick Coghlan wrote:
>> Perhaps ImportWarning should default to being ignored, the same way
>> PendingDeprecationWarning does?
>>
>> Then -Wd would become 'the one obvious way' to debug import problems
>
> +1
I'm not sure what this would achieve -- people
James Y Knight <[EMAIL PROTECTED]> writes:
> On Jun 24, 2006, at 1:29 PM, Ralf W. Grosse-Kunstleve wrote:
>
>> --- Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>>> I think it is safe to say that Twisted is more widely used than
>>> anything
>>> Google has yet released. Twisted also has a reas
t
from numerous people. Please feel free to give feedback and
raise questions.
contact points: http://codespeak.net/pypy/dist/pypy/doc/contact.html
have fun,
the pypy team, (Armin Rigo, Samuele Pedroni,
Holger Krekel, Christian Tismer,
Carl Friedrich Bolz, Michael Hudson,
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
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
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
>
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
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
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
"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
"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'
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
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
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
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
>>>
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
"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():
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.
"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
"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
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
"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
"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
"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
"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:
> [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
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
"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
"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
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.
"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 ?
"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
"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
[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
"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
"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
"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
"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
__
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
"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
"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
"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:
> 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
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.
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 12:21 PM 2/10/2006 -0800, Guido van Rossum wrote:
>> >PEP 343: The "with" Statement
>>
>>Didn't Michael Hudson have a patch?
>
> PEP 343's "Accepted" status was revert
The next PyPy sprint is scheduled to take place right after
PyCon 2006 in Dallas, Texas, USA.
We hope to see lots of newcomers at this sprint, so we'll give
friendly introductions. Note that during the Pycon conference
we are giving PyPy talks which serve well as preparation.
Goals and topi
Guido van Rossum <[EMAIL PROTECTED]> writes:
> On 2/8/06, Patrick Collison <[EMAIL PROTECTED]> wrote:
>> And to think that people thought that keeping "lambda", but changing
>> the name, would avoid all the heated discussion... :-)
>
> Note that I'm not participating in any attempts to "improve" l
Jean-Paul Calderone <[EMAIL PROTECTED]> writes:
> On Fri, 3 Feb 2006 07:00:26 -0800, Alex Martelli <[EMAIL PROTECTED]> wrote:
>>
>>On Feb 3, 2006, at 6:47 AM, Giovanni Bajo wrote:
>>...
>>> use itemgetter and friends but the "correct" way of doing a
>>> defferred "x[1]"
>>> *should* let you wr
Alex Martelli <[EMAIL PROTECTED]> writes:
> I was recently reviewing a lot of the Python 2.4 code I have written,
> and I've noticed one thing: thanks to the attrgetter and itemgetter
> functions in module operator, I've been using (or been tempted to use)
> far fewer lambdas, particularly but not
Thomas Wouters <[EMAIL PROTECTED]> writes:
> On Wed, Feb 01, 2006 at 11:29:16AM -0500, Tim Peters wrote:
>> [Thomas Wouters]
>> > Well, I said 4.0.3, and that was wrong. It's actually a pre-release of
>> > 4.0.3
>> > (in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release)
>> >
Scott Dial <[EMAIL PROTECTED]> writes:
> So, either the GCC people have not noticed this problem, or (more
> likely) have decided that this is acceptable, but clearly it will cause
> spurious warnings. Hey, after all, they are just warnings.
Well, indeed, but "no warnings" is a useful policy --
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> The source distribution would contain aclocal.m4; it would not
> contain the autoconf/autoheader tools themselves.
To a rather different point, do we need aclocal.m4 at all? This is
the log for aclocal.m4:
-
BJörn Lindqvist <[EMAIL PROTECTED]> writes:
> [M.-A. Lemburg]
>> I don't see why this is critical for the success of the Path
>> object. I agree with Thomas that interfaces should be made
>> compatible to Path object.
>
> See the steps I mentioned. Unless step #1 is completed there is no way
> to
"Gregory P. Smith" <[EMAIL PROTECTED]> writes:
> Using BerkeleyDB 3.2 often segfaults for me; using 3.3 often hangs in
> the test suite. Both are so old I don't see much motivation to track
> the issues down.
My goal is to not have http://www.python.org/dev/buildbot/ go red
randomly because of e
Tim Peters <[EMAIL PROTECTED]> writes:
> [Gabriel Becedillas]
>> Can anybody tell me if the patch I suggested is ok ?
>> That will be to add the following code at the end of PyThreadState_Delete:
>>
>> if (autoTLSkey && PyThread_get_key_value(autoTLSkey) == tstate)
>> PyThread_delete_key_valu
Donovan Baarda <[EMAIL PROTECTED]> writes:
> I personally think %b would be adding enough. The other suggestions are
> just me being silly :-)
Yeah, the whole area is just crying out for the simplicity and
restraint that is common lisp's #'format function :)
Cheers,
mwh
--
INEFFICIENT CAPIT
Gabriel Becedillas <[EMAIL PROTECTED]> writes:
> Hi,
> At the company I work for, we've embedded Python in C++ application we
> develop. Since our upgrade to Python 2.4.2 from 2.4.1 we started hitting
> Py_FatalError("Invalid thread state for this thread") when using debug
> builds.
> We use bo
Guido van Rossum <[EMAIL PROTECTED]> writes:
> On 1/10/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>> Sorry, I missed the point I was aiming at, I guess. I wasn't aiming for
>> fixable bugs; I see these things as, with great effort, holding up your foot
>> at an awkward angle so that it ends up
Georg Brandl <[EMAIL PROTECTED]> writes:
>> Well, this still has the faint whiff of impossibility about it. Are
>> you sure it's setupterm() that's doing the damage? Can you reproduce
>> interactively?
>
> Yep.
> Alone, the setupterm call [curses.setupterm(sys.__stdout__.fileno())] does
> nothin
Georg Brandl <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>> Georg Brandl <[EMAIL PROTECTED]> writes:
>>
>>> The call to curses.setupterm() leaves my terminal in a bad state.
>>
>> Hmm.
>>
>>> The reset program
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Well, you know that LOAD_CONST only supports 2**31 constants, so
> truncation to int is currently safe (I hope that the compiler detects
> cases where somebody tries to create more than 2**16 constants).
Easy enough to check:
>>> eval(repr(range
Georg Brandl <[EMAIL PROTECTED]> writes:
> The call to curses.setupterm() leaves my terminal in a bad state.
Hmm.
> The reset program outputs:
> Erase set to delete.
> Kill set to control-U (^U).
> Interrupt set to control-C (^C).
It always says that :) (unless you've messed with stty, I guess)
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Currently, my buildbot isn't connected to IRC at all. If I ever
> enable that aspect, I'll use allowForce=False again to disable
> remotely invoking builds.
#python-dev on freenode is ready and waiting should you decide to
activate this :)
Cheers,
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> In other news, clever hacks with tb_next and so on also seem
>> excessive. Why not have the equivalent of "if input.rstrip() ==
>> 'exit': sys.exit()" in the impl
1 - 100 of 332 matches
Mail list logo
