my_managers):
>>
>> without any good way to get rid of it.
>
> I actually almost asked for that to be changed to a
> PendingDeprecationWarning when it was first added - Benjamin, do you
> mind if I downgrade this warning to a pending one post rc2?
Yes, I think that's
except-statements
> which allows either individual exceptions or tuples of
> exceptions).
I think the question of extending the syntax later is orthogonal to
the issue of the DeprecationWarning.
--
Regards,
Benjamin
___
Python-Dev mailing list
Pytho
that are looked up via a PyType
> method usually raise AttributeError.
What's a PyType method?
--
Regards,
Benjamin
___
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
rn
> that is much better served by the new with-statement syntax.
+1 I think this should be done anyway.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://
l.pyc", line 1674, in read
> File "mercurial\httprepo.pyc", line 18, in zgenerator
> zlib.error: Error -3 while decompressing: incorrect header check
>
> Paul.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http:
>
> Also, if it's an oddity, it would be a good idea
> to mention this behaviour in the docs.
Yes, indeed.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
Backwards compatibility seems to be an issue that arises a lot here. I
think we all have an idea of it is, but we need some hard place to
point to. So here's my attempt:
PEP: 387
Title: Backwards Compatibility Policy
Version: $Revision$
Last-Modified: $Date$
Author: Benjamin Peterson
S
2009/6/19 Antoine Pitrou :
> Benjamin Peterson python.org> writes:
>>
>> This policy applys to all public APIs.
>
> applies?
Yes, thanks.
>
>> * The behavior of an API *must* not change between any two consecutive
>> releases.
>>
>> * A featu
e new version of Python that actually made them
> user-visible was released.
>>
>> 3. Wait for a release.
>
> How does this affect the parallel 2.x/3.x release cycle?
I just added something about this.
>>
>> 4. See if there's any feedback. Users not involved
t; after a long and thoughtful discussion; I don't think that decision making
> process could have been solved in advance by a bullet-point in a general
> purpose process PEP.
I would say that's pretty close to the procedure in the PEP actually:
"Discuss the change. Thi
2009/6/19 Georg Brandl :
> Benjamin Peterson schrieb:
>> Backwards compatibility seems to be an issue that arises a lot here. I
>> think we all have an idea of it is, but we need some hard place to
>> point to. So here's my attempt:
>
> Yet another rather pointless
erwise interested in Python development.
>>
>> And that won't generate a pile-on?
>
> Well, the etiquette for that specific list could be "keep this low- traffic
> unless you have a serious problem with this change". Or, better yet, make
> it an announce-o
to numbering or bike shedding?
--
Regards,
Benjamin
___
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
nk we can say anything about those cases before hand. We'll
have to decide on a case by case basis.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
he
release announcement should be the next day.
[1] http://bugs.python.org/issue6233
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opti
2009/6/26 Barry Warsaw :
> I'm sure this has been discussed but I missed it. Why was this change made?
> If nothing else, it breaks many years of tradition.
I assumed it was the tradition because all the 3.0 and 2.6 candidates had "rc".
Enjoy!
--
Benjamin Peterson
Release Manager
benjamin at python.org
(on behalf of the entire python-dev team and 3.1's contributors)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
preciated. Feel free to comment on my blog
> http://subdev.blogspot.com/ or reply to the last.
Have you talked with your mentor about these things?
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
ng they keep track of relations of changesets.
The problem is that Python is much more complicated than the average
project. We have many commits that are only applicable one maintenance
branch, or just 2.x, or just 3.x; the trunk and py3k will never be
subsets of each other. Regardless of where we make commits initially,
we need to ability to manage special cases like this easily.
--
Regards,
Benjamin
___
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
al is reached. Clearly, there are times when a language reaches
> only a local maximum, and must depart from itself to arrive at a more
> global optimum (an annealing problem in the minimization of
> frustration energy). If py3k wasn't kept, another term would
> eventually need t
(IOW, if __new__() is overridden or __init__() is not overridden).
However, for backwards compatibility, this breaks too much code.
Therefore, in 2.6, we'll *warn* about excess arguments when both
methods are overridden; for all other cases we'll use the above
r
2009/7/15 Peter Hanecak :
> So, my question is: In which Python release has been this fix distributed?
Python 2.6 and above.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
ting None was not warranted in Python 3.0? Otherwise I
> will do whatever work is necessary for this to happen.
I think it's still nice for the rare cases where you need to trick a
module into thinking another one doesn't exist.
--
Regards,
Benjamin
2009/7/23 Brett Cannon :
>
>
> On Thu, Jul 23, 2009 at 19:38, Benjamin Peterson
> wrote:
>>
>> 2009/7/23 Brett Cannon :
>> > None in Python 3.1 is really useless in terms of its semantics in
>> > relative
>> > imports; importlib doesn't
Once Subversion is back up (today, tomorrow?), I will tag the 3.1
maintence branch as 3.1.1rc1. The tree will remain frozen until
Saturday. If at that time, no one has found something wrong with the
RC, I will retag it as the final bugfix release.
--
Regards,
Benjamin
2009/8/10 Antoine Pitrou :
> Benjamin Peterson python.org> writes:
>>
>> Once Subversion is back up (today, tomorrow?), I will tag the 3.1
>> maintence branch as 3.1.1rc1. The tree will remain frozen until
>> Saturday. If at that time, no one has found something wron
e at it, you could improve that test
generally, since it's not exactly extensive.
Then, you might garner some more reviews by putting your patch up on
Rietveld; it makes reviewing much painful.
--
Regards,
Benjamin
___
Python-Dev mailing list
Pytho
http://www.python.org/download/releases/3.1/
The 3.1 documentation can be found at:
http://docs.python.org/3.1
Bugs can always be reported to:
http://bugs.python.org
Enjoy!
--
Benjamin Peterson
Release Manager
benjamin at python.org
(on behalf of the entire python-dev team and 3.
change that would be considered a backwards
> incompatibility? In other words, would patches like this be allowed
> in 2.6/3.1 or only in 2.7/3.2.
While I don't see a problem in backporting it to maintence branches, I
would personally only apply it to the current development branches.
2009/8/14 Frank Wierzbicki :
> On Fri, Aug 14, 2009 at 12:16 PM, Benjamin Peterson
> wrote:
>
>>> I have a local patch that changes the CPython col_offset to match
>>> Jython's, but before I submit a patch I thought I'd ask here if there
>>> is s
ally, unless the test is for a bug we are backporting, new tests
only go in the trunk and py3k.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
get off topic for python-dev.]
Why do you need to set Py_TPFLAGS_HEAPTYPE on your C type? Is a normal
static type not sufficient? The easiest way to create heaptypes is to
simply call PyType_Type.
--
Regards,
Benjamin
___
Python-Dev mailing list
Py
oming days.
To download Python 3.1.1 visit:
http://www.python.org/download/releases/3.1.1/
The 3.1 documentation can be found at:
http://docs.python.org/3.1
Bugs can always be reported to:
http://bugs.python.org
Enjoy!
--
Benjamin Peterson
Release Manager
benjamin at pytho
nd not have it type checked until it is compiled. This would be hard
to fix, though, and I think it is worth living with.
>
> BTW -- I *am* volunteering to attempt to implement these things in
> CPython if there is support :)
Very generous. :)
--
Regards,
Benjamin
al comments.
>
> I'd really like this fixed in the 2.x series if possible.
--
Regards,
Benjamin
___
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
2009/8/24 Chris Withers :
> Guido van Rossum wrote:
>>
>> Anyway it looks like if someone wants to try this, only the code in
>> runpy.py needs to be touched.
>
> Where is runpy.py to be found?
$ find . -name "runpy.py"
.
2009/8/25 Chris Withers :
> Anyway, so how is the stuff in runpy.py wired up to the command line options
> passed to the interpretter?
Modules/main.c
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
he case of just starting up an
> interpreter?
Because '' is prepended to sys.path then.
--
Regards,
Benjamin
___
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
z.
> This requires python 2.7, because it requires a newer version of 2to3 than
> what comes with 2.6.
Great work and congratulations on your first release!
Have you posted this to python-list and python-announce-list, too?
--
Regards,
Benjamin
___
tion to the stdlib.
I don't see why having it merged into Python's repo is a requirement
for contribution, since he's using Mecurial. :)
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
2009/8/27 Jesse Noller :
> On Thu, Aug 27, 2009 at 5:47 PM, Benjamin Peterson wrote:
>> 2009/8/27 Brett Cannon :
>>> What are the plans to merge this into Python's repository so we can
>>> all help out on this?
>>
>> None at the moment. I think the commu
dules in test
> are subject to the PEP's compatibility policy which is obviously
> absurd.
>
> -Brett
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Un
ootstrapping reasons in order to keep the possibility of using
> importlib as the implementation of import. But maybe I should not be
> worrying about that right at the moment and instead do what keeps the
> code simple.
You can use the C implementation of io, _io, which has a full
buffer
to specify the co_filename somewhere
>
> Why can't we simply make co_filename a writable attribute instead of inventing
> some complicated API?
Because code objects are supposed to be a immutable hashable object?
--
Regards,
Benjamin
_
TURN_VALUE's op argument.
--
Regards,
Benjamin
___
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
2009/8/31 xiaobing jiang :
> My idea is: here, the two functions (or maybe classes) should have the
> same behavior).
> so is this a bug or something I missing ?
I think they should both not check their arguments in __init__ to
allow for duck typing.
--
Regards,
2009/9/1 Brett Cannon :
> On Tue, Sep 1, 2009 at 07:21, Benjamin Peterson wrote:
>> 2009/8/31 xiaobing jiang :
>>> My idea is: here, the two functions (or maybe classes) should have the
>>> same behavior).
>>> so is this a bug or something I missing ?
>>
&
it just checks that there's something in the
> tp_call slot, which is reasonable -- if it's empty,
> there's no way that calling the object could ever
> succeed, so you might as well fail early.
It depends on whether you're keeping the "callable" object
gt;
> Should we copy Py_CmpToRich into our source tree?
> Otherwise we have fairly long cmp functions that have Py_CmpToRich inline.
>
> For C extension writers what is the suggested method for comparing
> types where Py_LT, Py_GT Py_GE etc are not useful?
Return Py_NotImplemented when you
arious sections.
BTW, it seems like you were trying to use reST formatting with the
text PEP layout. Double backquotes only mean something in reST.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
it is exactly what you want for
> something like string.Template.
Perhaps because it wasn't documented. :)
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
want to have a look at the archives of the last time this was
extensively discussed:
http://mail.python.org/pipermail/python-dev/2008-July/080886.html
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
hedule.
Are we still planning to make 3.3 the main development focus and start
the 5 years of 2.x maintenance after this release?
Additionally, I'm very apprehensive about doing any kind of release
without the buildbots running. Does anyone know when they might be up?
-
2009/9/23 Antoine Pitrou :
> Benjamin Peterson python.org> writes:
>>
>> Hi everyone,
>> I've started plotting the release of 2.7. I'd like to try for a final
>> release mid next summer. 3.2 should be released, if not at the same
>> time as 2.7, w
2009/9/23 Brett Cannon :
> On Wed, Sep 23, 2009 at 07:35, Benjamin Peterson wrote:
>> Hi everyone,
>> I've started plotting the release of 2.7. I'd like to try for a final
>> release mid next summer. 3.2 should be released, if not at the same
>> time as 2.7, w
2009/9/23 Michael Foord :
> Benjamin Peterson wrote:
>> As for burn out, I expected 2.7.x, as the last 2.x release,
>
> Are we definitely decided that 2.7 will be the last major release in the 2.x
> cycle?
No, but that's what we're planning for
2009/9/23 Brett Cannon :
> On Wed, Sep 23, 2009 at 13:34, Benjamin Peterson wrote:
>> As for burn out, I expected 2.7.x, as the last 2.x release, to be
>> different in that several people would do the maintenance releases
>> (perhaps on a 6 month schedule or so) for the 5
a platform.
--
Regards,
Benjamin
___
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
2009/9/23 Michael Foord :
> Benjamin Peterson wrote:
>>
>> 2009/9/23 Michael Foord :
>>
>>>
>>> Isn't that the real compatibility test *anyway* - how successful a new
>>> version of Python is at running all the existing Python code...
>>
ture I would
be more supportive of depreacting optparse, but more ways in which 2.x
and 3.x grow farther apart are not going to help jumping the great
version divide.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
2009/9/27 Steven Bethard :
> On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson
> wrote:
>> 2009/9/27 Steven Bethard :
>>> If you think getopt and optparse should stick around in 3.X, why is
>>> that? If you think there are things that getopt and optparse do bette
are possible to guess with mere static analysis.
--
Regards,
Benjamin
___
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 the '#' and ' '
> conversion flags.
Mine handles it differently for each type specifier.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
tarted a converter. It's here:
https://code.launchpad.net/~gutworth/+junk/mod2format
--
Regards,
Benjamin
___
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
hank you for avoiding the oxymoronic “Released: 2.6.3
> release candidate” or similar. I hope this signifies a trend toward
> using the more accurate term “available” for announcing availability of
> anything that's not an actual release.
Alphas, betas, and release candidat
t;bzr branch lp:~gutworth/+junk/mod2format".) It
should basically work except for some obscure cases like "%#.0f".
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
f"foo"
>
> This way's pros:
> * Many libraries can use one transition way.
> * Transition stage syncs to Python version. "library A uses {} and
> library B uses %" problem not happen in transition.
> * We have experien
2009/10/5 Nick Coghlan :
> So I would agree that method invocation on literals (particularly string
> literals) is an already established language idiom.
And who hasn't ever used 4.56.as_integer_ratio()? :)
--
Regards,
Benjamin
___
lan:
> n: Just add F prefix. And adding "format_string" in future.
> n+1: deprecate __mod__() without 'F'.
> n+2: libraries use .format() and deprecate __mod__() with 'F'
> n+3: remove __mod__()
-1 That requires keeping formatting information around in every strin
ssing
> from the list of known implementations)
That docstring should be updated then because I added support for PyPy
in 2.7 and 3.1.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
iding a transition path if it can't
> cover this case?
It's also really easy to just write 0{:o} like my translator does.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
ntaining the current scope's local variables.") is pretty
> unclear.
Yes, it does, and that's why the documentation says changing it is undefined. :)
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
implementation, for example "C", ".NET",
> "Java"
>
> runtime (required):
> lower case runtime library of the implementation, for example "libc",
> "msvcrt90", "java6", ".net"
>
> compiler (required):
>
2009/10/9 Christian Heimes :
> Benjamin Peterson wrote:
>>> sys.userdirsuffix
>>> -
>>
>> Why not site.userdirsuffix?
>
> Because all implementations of Python like to use the same, unpatched
> site module. The sys module is diffe
2009/10/9 Christian Heimes :
> Benjamin Peterson wrote:
>> I think we should make a semi-private (public to the stdlib) module
>> like _sys or _implementation part of the Python VM API. Then, instead
>> of stuffing everything into sys, we can provide this information in
>&g
in. Otherwise
> it's only a CPython/python.org perk.
As far as I am aware, all current Python implementations can build in modules.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
sily be accepted, but I'd like to see
> the sys module eventually split up in two parts, so it is very obvious
> to both implementers and users which system-specific features are
> portable and which are not:
I'm afraid this has already been proposed and rejected. See
http://www
2009/10/10 Vinay Sajip :
> Excuse my ignorance, but how come?
Because __builtins__ is a module in __main__ and a dict in other
places. You should always check __builtin__; __builtins__ is an
implementation detail.
--
Regards,
Benjamin
___
Python-
> Is it really that big of an issue that we have to discuss it
> ad-infinitum and potentially have a quoting cop? Sometimes top-posting
> happens. Sometimes people don't trim messages. Sometimes people argue
> about the color of a shed.
+1 This is really get
t Python-dev is opposed to it in
principle, but that someone has yet to submit a patch that doesn't
affect single thread preformance and remains compatible with the
C-API.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@pyth
ules (and their
states) can easily be finalized before the objects contained in them.
For example, when I tried to convert the _io module to use a state, it
resulted in segfaults when the dealloc methods of objects tried to use
objects in a state, which had already been deallocated.
--
Rega
2009/10/22 Barry Warsaw :
> So does anybody else think bug 7183 should be a release blocker for 2.6.4
> final, or is even a legitimate but that we need to fix?
I think it cannot hold up a release with out a reproducible code snippet.
--
Regards,
Be
es.
Those are all examples of states which are implementation details. The
proposed get() semantics would require that allow implementations keep
this state around.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
final 2010-06-26
--
Regards,
Benjamin
___
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
thing Python 3 (and 2to3) will like?
Not to my knowledge. I would prefer to not add a fixer for this
directly to 2to3 because it is not correct for most programs. However,
I think 2to3 should grow some sort of plugin system, so custom fixers
can easily be written and used.
--
Regards,
Benjamin
_
o move back the whole
schedule 6 months.
--
Regards,
Benjamin
___
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
than a separately built
> extension module.
I have another unpleasant but slightly less hacky solution. We put
detect_encoding in linecache where it is actually used.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
that case silently has absolutely no effect.
--
Regards,
Benjamin
___
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
2009/11/15 Brett Cannon :
> On Sat, Nov 14, 2009 at 20:01, Benjamin Peterson wrote:
>> 2009/11/14 Nick Coghlan :
>>> This does constrain where we can use itertools - if we want carte
>>> blanche to use it anywhere in the standard library, even those parts
>>&
After more thought, I think that separating the 2.7 and 3.2 releases
is not as big of an issue as I once thought. Therefore, I'd like to
adopt the schedule I posted a few weeks back for 2.7 only.
This only means some other lucky victi... I mean volunteer can do 3.2. :)
--
Regards,
Ben
I'm pleased to announce that Georg has (naively) volunteered to
shepherd the 3.2 release.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
2009/12/3 Ben Finney :
> Howdy all,
Hi Ben,
Could I ask why you cced this to python-dev, too? I thought the last
string of pypi related emails, we agreed the correct place for this
was the catalog-sig.
--
Regards,
Benjamin
___
Python-Dev mail
e 2.7 documentation can be found at:
http://docs.python.org/2.7
Please consider trying Python 2.7 with your code and reporting any bugs you may
notice to:
http://bugs.python.org
Have fun!
--
Benjamin Peterson
Release Manager
benjamin at python.org
(on behalf of the entire python-dev team and
My apologies. The whatsnew link is actually
http://docs.python.org/dev/whatsnew/2.7.
2009/12/5 Benjamin Peterson :
> On behalf of the Python development team, I'm pleased to announce the first
> alpha release of Python 2.7.
--
Regard
2009/12/9 Lennart Regebro :
> Is these changes necessary? It's going to be hell to test any form of
> testrunner under both 2.6 and 2.7 if the formatting of test results have
> changed.
Could you mention what specific changes are causing problems?
--
Reg
carry out its intent.
>
> Would this be considered bugfixy enough to get into 3.1-branch as well
> as 2.7? It really is damn annoying when you try to port doctests to
> Python 3, and it would be great if we wouldn't have to wait for 3.2.
I think a patch would be helpful before d
2009/12/11 Lennart Regebro :
> Should I start a bug report in the tracker for this?
Yes, please.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
2009/12/14 Dino Viehland :
> I’m not sure the best place to verify this so I’m starting here.
p...@python.org is better.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
2009/12/30 Martin (gzlist) :
> Hi Benjamin,
Hi!
>
> In rev 74094 of Python, you split the unittest module up, could you
> point me at any bug entries or discussion over this revision so I can
> catch up?
This was mostly a discussion on IRC between Michael Foord and myself.
>
already ;o)
>
> +0.5 for adding `__unittest_ignore_traceback` or something shorter
> (e.g. `__unittest_ignore`) too ...
>
> +1 for documenting that «hack»
Someone should probably file a tracker request about this.
--
Regards,
Benjamin
___
601 - 700 of 1550 matches
Mail list logo
