Tony Meyer [EMAIL PROTECTED] writes:
--
Adding zlib module to python25.dll
--
Thomas Heller and Martin Heller had been discussing whether the zlib
Should be 'Martin v. Löwis', as we all know.
module should become builtin, at
Brett Cannon wrote:
Hmm. It's an idea. I also thought of Python - JavaScript compiler
since JavaScript is not fun and getting to test using Python might be
cool. But not sure how useful that would be. Plus I bet someone has
does this with Java or something.
There's a Python project that
Opps. I just sent out the draft summary for the first half of
December (which might only make it to the list after this one, since
it's very long) but forgot to say anything at the top.
No-doubt everyone knows the pitch by now, but if anyone is able to
take a look at the summary (or parts of it)
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 both
Scott David Daniels wrote:
OK I carried the code I offered earlier in this whole thread (tweaked in
reaction to some comments) over to comp.lang.python, gathered some
feedback, and put up a recipe on the cookbook. After a week or so for
more comment, I'll be happy to submit a patch to include
Crutcher Dunnavant wrote:
I sorta disagree about it not being broken. Adding a feature which
works for eval but not for exec seems pretty broken.
You seem to have a different notion of to be broken, then.
Python is broken, if and only if
- the interpreter crashes, for any Python input
- the
Tony Meyer wrote:
Fredrik Lundh kicked off a surprisingly long thread when he proposed
that typing quit or exit in the interactive prompt actually exit
(i.e. raises SystemError)
SystemExit
def exit():
... print bye
# what is it?
exit
$ oops!
(However, one
David Goodger wrote:
On 1/12/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
I know, but I wouldn't expect SVN to query other servers
than svn.python.org inside the standard repository
directories.
AFAIK, this is a first in the Python repository.
True, and worth discussing. Luckily the PEPs
OK I carried the code I offered earlier in this whole thread (tweaked in
reaction to some comments) over to comp.lang.python, gathered some
feedback, and put up a recipe on the cookbook. After a week or so for
more comment, I'll be happy to submit a patch to include the broken_test
decorator
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
What if x64 has a 64-bit value ? How do you catch
and process the truncation error ?
We were *both* discussing a scenario where no sizes
exceed 2**31, right?
Right, but I don't see the point of each and every
extension having to go through these
On 1/12/06, Dennis Allison [EMAIL PROTECTED] wrote:
Brett,
Where are you doing your Phd and who will be your likely supervisor?
It does make a difference.
University of British Columbia under Eric Wohlstadter in the Software
Practices Lab.
Your dissertation idea list seems to me to focus
Barry Warsaw wrote:
On Wed, 2006-01-04 at 22:01 +0100, Reinhold Birkenfeld wrote:
Recently, someone on dclpy posted about an error he got
when he tried to unpack the Python distribution tarball
with Sparc Solaris 9's tar:
tar: directory checksum error
With GNU tar, it worked correctly.
Is
M.-A. Lemburg wrote:
Sure. However, most users will compile it on 32-bit
systems. If they find they cannot get it to work on
a 64-bit system, they should ask the author for help,
or just use it in 32-bit mode (as 64-bit mode won't
gain them anything, anyway).
I wonder how you are going to
Patch / Bug Summary
___
Patches : 384 open ( +2) / 3016 closed (+13) / 3400 total (+15)
Bugs: 909 open ( +6) / 5500 closed (+21) / 6409 total (+27)
RFE : 208 open ( +5) / 196 closed ( +1) / 404 total ( +6)
New / Reopened Patches
__
add
M.-A. Lemburg wrote:
Right, but I don't see the point of each and every
extension having to go through these hoops when you
could add support for these checks (including error
reporting) to the few APIs in question, in particular
the PyArg_ParseTuple() API.
I don't want to rename the
Fredrik Lundh wrote:
Scott David Daniels wrote:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/466288
my main nit is the name: the test isn't broken in itself, and doesn't need
to be fixed; it's just not expected to succeed at this time.
the usual term for this is expected
Scott David Daniels wrote:
Fredrik Lundh wrote:
Scott David Daniels wrote:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/466288
my main nit is the name: the test isn't broken in itself, and doesn't need
to be fixed; it's just not expected to succeed at this time.
the usual
Scott David Daniels wrote:
Would expect_fail, expect_failure, expected_fail, or
expected_failure, work for you?
None of these use the same naming convention as the other unittest object
attributes. Perhaps something like failureExpected?
I'd definately prefer something that reads cleanly;
18 matches
Mail list logo
