On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras [EMAIL PROTECTED] wrote:
On 2/21/08, Martin v. Löwis [EMAIL PROTECTED] wrote:
- no selection -118
wont fix189
works for me62
accepted310
fixed 611
duplicate 75
later 17
invalid 73
On 21 Feb, 12:30, Virgil Dupras [EMAIL PROTECTED] wrote:
Hi devs,
Specifically, I'd like to know about files managements in tests. Is
every test expected to clean after itself, or is there an automatic
cleanup mechanism in place?
I have usually seen a lot of tests implemented like this:
2008/2/20, Martin v. Löwis [EMAIL PROTECTED]:
- no selection -118
wont fix189
works for me62
accepted310
fixed 611
duplicate 75
later 17
invalid 73
postponed 6
out of date 193
remind 1
rejected180
This is the result
On Thu, Feb 21, 2008 at 08:59:51AM +0100, Virgil Dupras wrote:
Thanks for running it. The rate is better than I expected, so I was
wrong in my assumption.
What would be the difference between accepted and fixed for a closed ticket?
'accepted' is probably used more for patches, while 'fixed'
Guido van Rossum wrote:
On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras [EMAIL PROTECTED] wrote:
On 2/21/08, Martin v. Löwis [EMAIL PROTECTED] wrote:
- no selection -118
wont fix189
works for me62
accepted310
fixed 611
duplicate 75
Virgil Dupras wrote:
On 2/21/08, Virgil Dupras [EMAIL PROTECTED] wrote:
Hi devs,
Being a python dev newbie, I look in http://www.python.org/dev/ for
some guide to write unit tests in python and I can't find any.
Specifically, I'd like to know about files managements in tests. Is
every
2008/2/21, Virgil Dupras [EMAIL PROTECTED]:
I don't see why would want to run this query on open tickets. What
would it tell you? How many old issue there is? You can already know
that with a simple search. The goal of this script is to know the
resolution of tickets that had a 6+ month
On 2/21/08, Steve Holden [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras [EMAIL PROTECTED]
wrote:
What would be the difference between accepted and fixed for a closed
ticket?
I don't know what others do, but I use accepted for a patch
On 2/21/08, Nick Coghlan [EMAIL PROTECTED] wrote:
Virgil Dupras wrote:
On 2/21/08, Virgil Dupras [EMAIL PROTECTED] wrote:
Hi devs,
Being a python dev newbie, I look in http://www.python.org/dev/ for
some guide to write unit tests in python and I can't find any.
Specifically,
On 2/21/08, Facundo Batista [EMAIL PROTECTED] wrote:
This is the result for the open status issues? I guess not, because
the rejected, fixed, etc, should be closed.
Could you run this again, please, but filtering by open tickets?
I don't see why would want to run this query on open tickets.
2008/2/21, Gregory P. Smith [EMAIL PROTECTED]:
That sounds eminently sensible. So sensible there should be
documentation that tells us to do that. Drat it, where's Brett Cannon
when you need him? :-)
I'm always faced with a tiny quandry when closing a fixed bug that had a
patch to fix it
Guido van Rossum wrote:
I don't think so.
You could create a directory in setUp method by using tempfile.mkdtemp
and then remove it in tearDown.
Specifically, clean it up with shutil.rmtree()
And make sure you have closed all files before you rmtree() the
directory. Otherwise the unit
Barry Warsaw wrote:
Why should docstrings and comments be limited to 72 characters when
code is limited to 79 characters? I ask because there is an ongoing
debate at my company about this.
I'm not sure if this is the main reason, but when using pydoc to view
docstrings, the 72
On Thu, Feb 21, 2008 at 9:15 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
Why should docstrings and comments be limited to 72 characters when
code is limited to 79 characters? I ask because there is an ongoing
debate at my company about this.
People in your company have too much time on their
Everything in this aspect would be simpler if we have one word for
what I just meant.
If you think it should be fixed, please submit a report in the meta
tracker, ideally specifying precisely how you want to see it changed.
It's possible to retire objects in Roundup: certain resolution values
[Eric Smith]
I'm going to work on backporting PEP 3127, specifically
the hex, oct(), and bin() builtins.
IMO, these should not be backported. They are strongly
associated with 3.0's new literal syntax. They don't
don't really fit in with 2.6 and don't make 2.6 any more
attractive.
Raymond
André Malo wrote:
* Eric Smith wrote:
But now that I look at time.strftime in py3k, it's converting the entire
unicode string to a char string with PyUnicode_AsString, then converting
back with PyUnicode_Decode.
Looks wrong to me, too... :-)
nd
I don't understand Unicode
On Feb 15, 9:18 pm, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Raymond]
Should dir(module) use __all__ when defined?
[GvR]
It's not consistent with what dir() of a class or instance does though.
-1.
Perhaps there is another solution. Have dir() exclude objects
which are modules.
Raymond Hettinger wrote:
[Eric Smith]
Speaking for myself, these features are generally useful,
and are so even without the new integer literal syntax.
I'm curious how these are useful to you in Py2.6 where
they are not invertible. In Py3.0, we can count on
x == int(bin(x), 2)
x ==
Raymond Hettinger wrote:
[Eric Smith]
I'm going to work on backporting PEP 3127, specifically
the hex, oct(), and bin() builtins.
IMO, these should not be backported. They are strongly
associated with 3.0's new literal syntax. They don't
don't really fit in with 2.6 and don't make 2.6
On Thu, Feb 21, 2008 at 2:26 PM, Eric Smith
[EMAIL PROTECTED] wrote:
I'm going to work on backporting PEP 3127, specifically the hex, oct(),
and bin() builtins. I have bin() completed, and I'll check it in
shortly. oct() will require a future import. Does anyone have any
pointers for
21 matches
Mail list logo
