Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Let's commit the capi patch but not expose instancemethod. Make it so.
--
resolution: -> accepted
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
r66948
--
nosy: +barry
resolution: -> accepted
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
r66949
--
resolution: -> accepted
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Rather than attach a full _pickle.c file, please generate a unified diff
with just your changes. The patch should include a test for the
crashing condition. If you can upload that I'll try to accept it for
rc3. Deferr
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
This issue does not seem close to resolution and the nntplib is not
critical enough to block the release, so I'm deferring this to rc3.
--
nosy: +barry
priority: release blocker -> de
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
r66950
--
nosy: +barry
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
r66950
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Brett, please apply and close the issue.
--
nosy: +barry
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Amaury, please apply the patch and close the issue. Thanks!
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
r66957. really. fer sher.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from Barry A. Warsaw <[EMAIL PROTECTED]>:
According to bug 1683368, Python 3.0's object.__init__() no longer
accepts arbitrary keyword arguments. What's new in Python 2.6 says the
same thing has been implemented in 2.6. However, type() no longer
accepts /any/ k
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
The assertion on line 813 is indented incorrectly. Please fix that.
I'm concerned we really need better test coverage for this code, but
it's doubtful we'll get that before 3.0 final is released. I think this
is the b
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Benjamin's reviewed this and the only thing that jumps out at me is some
funky indentation at about line 331. If you fix that, you can land this
patch.
--
keywords: -needs review
nosy: +barry
resolution:
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Please fix the test as Benjamin suggests ("network"). While I'd prefer
a more fleshed out test suite, I think in time you can add that. For
now, this is still an improvement and likely the best we're going to g
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Can you add some tests for this problem?
--
nosy: +barry
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Christian, if you like the patch go ahead and land it.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Small typo, conveyed to Crys_ in irc.
--
nosy: +barry
resolution: -> accepted
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
I don't see enough progress on this issue, and I'm not going to hold up
3.0rc2 for it, so I'm deferring.
--
nosy: +barry
priority: release blocker -> deferred blocker
__
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
This seems like a corner case to me. We should fix it before the final
release, but I don't think it's worth holding up 3.0rc2 for it. Deferring.
--
priority: release blocker -&g
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
This is really done, so closing.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Barry A. Warsaw <[EMAIL PROTECTED]>:
The Python 3.0 documentation is broken. This is blocking the 3.0rc2
release.
I'm too tired right now to figure out what the base problem is.
This was during the ".../release.py --export 3.0rc2" build phase.
pdflate
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Sorry, but this is still not fixed:
tnow using/cmdline Exception occurred:
File
"/private/tmp/py3k/dist/Python-3.0rc2/Doc/tools/docutils/parsers/rst/states.py",
line 2055, in run_directive
% (type_name, i, result[i])
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
r67136 is a workaround found by Christian. We'll go with this for the
3.9rc2 release and make this a deferred blocker for a proper fix for the
next rc.
--
priority: release blocker -> deferred blocker
res
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Raising to deferred blocker. This will definitely block 3.0rc3.
--
nosy: +barry
priority: high -> deferred blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
After consultation with MvL and Crys_ on irc, we've agreed that this
should be fixed someday but it's a pathological case that shouldn't hold
up the release. I'm lowering to critical because I don't think i
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
This example works though, and it also works in earlier Pythons.
from email.header import Header
def main():
# coding: utf8
ADDRESS = '[EMAIL PROTECTED]'
from email.mime.text import MIMEText
msg = MIMEText(
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
I'm rejecting the patch because the old way of making this work still
works in Python 3.0. Any larger changes to the API need to be made in
the context of redesigning the email package to be byte/str aware.
--
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
patch applied; r67299
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
I'm okay with the roundtrip not being supported. One thing I don't
quite understand is in the third test, where you're using "w+" mode and
testing f.buffer.mode and f.buffer.raw.mode is "r+"
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
r67300 (with after the fact whitespace normalization of
Lib/tests/test_io.py)
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 20, 2008, at 5:07 PM, STINNER Victor wrote:
> STINNER Victor <[EMAIL PROTECTED]> added the comment:
>
>> I'm rejecting the patch because the old way of makin
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
status: closed -> open
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4362>
___
__
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3741>
___
___
Python-bugs-list mailing list
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Deferring until 3.0 final is out.
--
nosy: +barry
priority: release blocker -> deferred blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Guido... ping?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2306>
___
___
Python
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Jesse, please apply so we can close this issue.
--
nosy: +barry
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
I agree with MvL and MAL. We can't change Python, so this is a
documentation issue. I'm lowering the priority so it doesn't block the
release.
--
nosy: +barry
priority: releas
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Since this is a Python 2.5.3 issue, I'm lowering to deferred blocker
until after 3.0 and 2.6.1 are released.
--
nosy: +barry
priority: release blocker -> deferred blocker
___
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Martin, the patch looks okay to me. I vote for applying it.
--
nosy: +barry
resolution: -> accepted
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Lowering priority since this is not a Python 3.0 or 2.6.1 issue.
--
nosy: +barry
priority: release blocker -> deferred blocker
___
Python tracker <[EMAIL PROTECTED]>
<http
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Go for it Martin.
--
resolution: -> accepted
versions: +Python 2.6, Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Guido, ETA? I think this will be one of the last things before we can
tag the tree for release.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Jesse, does this affect Python 3.0? If not, then I will lower the
priority and release 2.6.1 without it (there's always 2.6.2 :).
If so, then we need to know if 1) it's really a release blocker; 2) what
the ETA on a fix i
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
This looks like it only affects printing exceptions with implicit
chaining when the exception propagates to the top level. (Maybe it also
affects the traceback module?)
In that case, I agree with Antoine. Let's fix
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
I don't much like the
lock is True
lock is False
idioms much, but I don' thave a better suggestion, and it would be nice
to fix this for the releases.
--
resolution: -> accepted
___
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
I've changed my mind based on the API change. This should be discussed
on the mailing list and deferred until 2.6.2 at least.
--
resolution: accepted ->
___
Python tracker <
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
For 2.6.1, yes you can fix the comments if you can do it now :)
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
I thought we had fixed that :(
--
priority: -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Actually, it turns out that the doc build process leaves a few more pyc
turds now. I've updated release.py to remove them, though the script
really should complain loudly if it ever finds pycs in the distribution.
That'
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Withdrawn
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
Wait, should Doc/tools/sphinxext be included in the source tarball or
not? I thought it was a documentation build artifact. If so, then we
need to clean out the pycs it contains in a different way.
In any case, the 3.0 tarballs
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: deferred blocker -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: critical -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: high -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw <[EMAIL PROTECTED]>:
--
priority: high -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue16997>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue17330>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue14266>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
As I mentioned on python-dev, having a `pyunit` script is nice (whatever it's
called), but we need to keep the `-m invocation` which will probably be the
recommendation on distros such as Debian which provide multiple versions of
Python. We're no
Barry A. Warsaw added the comment:
On Mar 04, 2013, at 07:45 PM, Antoine Pitrou wrote:
>
>Antoine Pitrou added the comment:
>
>> We're not going to want to install all possible flavors of
>> `pyunit2.6`, `pyunit2.7`, `punit2.6-dbg`, `pyunit-3.2-dbg`, etc. etc.
>
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue17379>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Mar 07, 2013, at 03:58 PM, Antoine Pitrou wrote:
>Disagreed. This is the kind of sentence that cannot be correctly
>understood without the (missing) original context.
Plus, we fear change. ;)
--
___
Barry A. Warsaw added the comment:
On Mar 09, 2013, at 03:30 AM, Terry J. Reedy wrote:
>I think you are, in effect, asking for expansion of the 'PEP Header Preamble'
>section of PEP-0001. I have added some of the PEP editors listed in the PEP
>as nosy. I will let them decid
Barry A. Warsaw added the comment:
It seems to me that the right thing to add a related PEPs section to any PEP
which needs it, but I don't think we need an official header for it. Thus, I'm
closing this PEP as Won't Fix. Feel free to open new bugs for any specific PEP
that n
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue15806>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue15805>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue3982>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Barry A. Warsaw:
This came up at the Pycon 2013 Python 3 porting clinic. There are many cases
in the stdlib that claim (either explicitly or implicitly) to accept bytes or
strings, but that don't return the type of the arguments they accept. An
examp
Barry A. Warsaw added the comment:
On Mar 17, 2013, at 03:10 PM, R. David Murray wrote:
>There was a long thread about this on python-dev that might be worth going
>back over, where I had the same misconception (that functions should always
>return the same type as their arguments).
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue17527>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue17565>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue15867>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
You also end up with this nice bit of inconsistency:
>>> x = myint(7)
>>> from operator import index
>>> range(10)[6:x]
range(6, 7)
>>> range(10)[6:x.__index__()]
range(6, 8)
>>> range(10)[6:index(x)]
range(6, 7)
New submission from Barry A. Warsaw:
operator.index() is just a thin wrapper around PyNumber_Index(). The
documentation for operator.index() claims that it is equivalent to calling
obj.__index__() but for subclasses of int, this is not true. In fact,
PyNumber_Index() first does (e.g. in
Changes by Barry A. Warsaw :
--
title: PyNumber_Index() is not int-subclass friendly -> PyNumber_Index() is not
int-subclass friendly (or operator.index() docos lie)
___
Python tracker
<http://bugs.python.org/issu
Barry A. Warsaw added the comment:
On Mar 30, 2013, at 12:29 AM, Eric Snow wrote:
>Would it be okay to do a check on __index__ after the PyLong_Check()
>succeeds? Something like this:
>
>if (PyLong_Check(item) &&
>item->ob_type->tp_as_number->nb_inde
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue17579>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Apr 01, 2013, at 07:40 PM, Brett Cannon wrote:
>Barry, Eric: can you clarify why you made module_repr an abstractmethod and
>thus require its overloading?
Maybe Eric can, but I can't. ;) I honestly don't remember why we made it
abstract
Barry A. Warsaw added the comment:
On Apr 01, 2013, at 09:04 PM, Brett Cannon wrote:
>If Eric doesn't have anything to add then I would like to change
>importlib.abc.Loader.module_repr() to no longer be abstract and the default
>to be defined as ``return repr(module)``. Els
901 - 1000 of 1167 matches
Mail list logo