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
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.
>>
>>
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 "ex
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 exi
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 suppo
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
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 co
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 t
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
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 funct
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. Luck
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
>
>
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
- t
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 incl
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
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 inc
Fabien Schwob wrote:
> Hello,
>
> I've often read new PEP that are published, and they are often about new
> additions to the core language. Why not using them with the standard
> library.
PEPs are used to make changes to the Standard Library - there's a bunch of
them listed in PEP 0. However,
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)
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 th
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 built
20 matches
Mail list logo
