Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue22385>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Sep 27, 2014, at 02:40 PM, Ram Rachum wrote:
>I'd like Enum objects to expose their serial numbers.
Can you please provide some motivating use cases?
--
___
Python tracker
<http://bugs.python.org
Barry A. Warsaw added the comment:
On Sep 27, 2014, at 02:28 PM, Ram Rachum wrote:
>I suggest making Enum members orderable, according to their order in the enum
>type.
Can you please provide a motivating use case?
--
nosy: +barry
___
Barry A. Warsaw added the comment:
On Sep 27, 2014, at 03:35 PM, Ram Rachum wrote:
>Just because I want to be able to get the `int` value of an enum object,
>doesn't mean I want the enum object to *be* an `int`, which is what `IntEnum`
>means. I don't want it to be comparable
Barry A. Warsaw added the comment:
https://docs.python.org/3/library/enum.html#orderedenum
--
___
Python tracker
<http://bugs.python.org/issue22504>
___
___
Pytho
Barry A. Warsaw added the comment:
On Sep 27, 2014, at 02:59 PM, Ram Rachum wrote:
>Right now I want it for this:
>
>http://bugs.python.org/issue22504
https://docs.python.org/3/library/enum.html#orderedenum
>Another use case I can think of is that if you store enum values in
Barry A. Warsaw added the comment:
On Sep 27, 2014, at 04:15 PM, Ram Rachum wrote:
>The main principle is: If something has an important property (in this case
>an enum object's numerical value), it should be publicly exposed.
I think this is a misunderstanding. Only IntEnum mem
Barry A. Warsaw added the comment:
On Sep 27, 2014, at 09:05 PM, R. David Murray wrote:
>There is no longer a concept of a separate 'email' release from the stdlib
>release. The __version__ string didn't get updated in either 3.3 or 3.4 (my
>fault). I propose t
Barry A. Warsaw added the comment:
On Oct 03, 2014, at 04:19 PM, Tshepang Lekhonkhobe wrote:
>Looks like a safe change. There is only one user in all Debian sources, and
>it's on Python 2:
>
>http://codesearch.debian.net/search?q=email.__version__
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue22555>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue22562>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue19642>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
components: +Library (Lib)
___
Python tracker
<http://bugs.python.org/issue22570>
___
___
Python-bugs-list mailing list
Unsub
New submission from Barry A. Warsaw:
pathlib is really nice, but currently it's rather inconvenient to use due to
the lack of support in other parts of the stdlib for Path objects. For
historical reasons, everything accepts string paths, but few places accept
Paths. As an ex
Changes by Barry A. Warsaw :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue22570>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Oct 06, 2014, at 03:43 PM, Georg Brandl wrote:
>I'd rather write str(path) all over the place than having to look up in the
>docs each time if that specific API happens to support passing Paths
>directly.
Have you tried to write a large-i
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue19984>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
Thanks for the patch! I don't care if the old email address is retained in the
test data (maybe it's even a good thing those point to nonexistent addresses
:). Definitely change the one in py
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue20096>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
It seems a little unfortunate that you lose the symbolic default, especially
since the expanded number just appears random.
>>> print(inspect.signature(os.stat))
(path, *, dir_fd=None, follow_symlinks=True, fake=9223372036854775807)
>&g
Barry A. Warsaw added the comment:
On Jan 06, 2014, at 08:23 PM, Larry Hastings wrote:
>Could you live with this being checked in to 3.4?
For sure!
--
___
Python tracker
<http://bugs.python.org/issu
New submission from Barry A. Warsaw:
I've been debugging a crash in nose 1.3.0, the root cause of which turned out
to be an instance containing an attribute which itself was an instance of the
following class (boiled down):
class Picky:
def __getstate__(self):
return {}
Barry A. Warsaw added the comment:
Hmm, actually, this is a regression in Python 3.4. Let's amend the test class
to include a __getnewargs__():
class Picky(object):
"""Options container that returns None for all options.
"""
def __getstate_
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue16251>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I'll go ahead and dupe this to 16251, but will note the __getnewargs__()
regression in 3.4.
--
superseder: -> pickle special methods are looked up on the instance rather
than the type
___
Python tracke
Barry A. Warsaw added the comment:
I ran into this recently while porting nose to 3.4. I duped
http://bugs.python.org/issue20261 to this issue, but note that in
http://bugs.python.org/issue20261#msg208109 I notice that the presence or
absence of __getnewargs__() regresses the specific
Barry A. Warsaw added the comment:
On Jan 20, 2014, at 05:10 PM, Gerrit Holl wrote:
>This is potentially confusing. The documentation in this section has not
>made any mention of %-based substitutions. Rather, a novel reader may, at
>this point, think that {}-based substitution is n
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue20309>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Barry A. Warsaw:
Run the attached file under Python 3.3 and you get:
No JSON object could be decoded
Run the same file under Python 3.4 and you get:
Expecting value: line 1 column 1 (char 0)
So a couple of things:
Since the error message changed, it makes it difficult to
Barry A. Warsaw added the comment:
What do you think of combining the error messages, e.g.
No JSON object could be decoded, expecting value: line 1 column 1 (char 0)
?
--
___
Python tracker
<http://bugs.python.org/issue20
Barry A. Warsaw added the comment:
So, here's a patch that should work. One thing I'm not positive about is that
this is a more expansive change then just merging the two messages in the one
case in the original description. But it probably makes sense to be
consistent. Or sho
Barry A. Warsaw added the comment:
On Jan 31, 2014, at 04:23 PM, R. David Murray wrote:
>If backward compatibility is the concern, I'd think you'd just want to
>restore that one message.
Yeah. I think the tests are a little more difficult to adjust in that case,
and of course,
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue20534>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Feb 17, 2014, at 07:03 AM, Serhiy Storchaka wrote:
>
>Currently enums are pickled by values. It means that if the value of enum is
>platform depending, pickling one enum you can unpickle other enum on other
>platform.
It's probably a good
Barry A. Warsaw added the comment:
On Feb 18, 2014, at 07:57 PM, Serhiy Storchaka wrote:
>This is sad. Because after a release, change it will be much harder.
OTOH, if default-pickling-by-name could be overridden, so can
default-pickling-by-va
Barry A. Warsaw added the comment:
We just discovered that this change breaks testtools. I will file a new bug on
that.
--
___
Python tracker
<http://bugs.python.org/issue16
New submission from Barry A. Warsaw:
The change for issue #16997 82844:5c09e1c57200 introduced a regression with
testtools. See attached file and instructions for reproducing it (it requires
the testtools package).
--
components: Library (Lib)
files: test_expected_failure.py
keywords
Barry A. Warsaw added the comment:
See issue #20687
--
___
Python tracker
<http://bugs.python.org/issue16997>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +rbcollins
___
Python tracker
<http://bugs.python.org/issue20687>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
Bumping to release blocker so Larry can make a determination.
--
nosy: +larry
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issu
Barry A. Warsaw added the comment:
On Feb 20, 2014, at 06:13 AM, Larry Hastings wrote:
>Benjamin, Barry: I take it #20261 should go in to 3.4.0?
Yes please!
--
title: 3.4 cherry-pick: b328f8ccbccf pickle shouldn't look up dunder methods on
instances -> 3.4 cherry-pick: b
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue20770>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
We're seeing this in Ubuntu now that 3.4 is the default.
https://bugs.launchpad.net/python/+bug/1284469
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/is
Barry A. Warsaw added the comment:
On Feb 27, 2014, at 03:46 PM, STINNER Victor wrote:
>Serhiy fixed the issue #19255 with the changeset 6a1711c96fa6, but this
>changeset will wait Python 3.4.1.
Okay, thanks. I was reviewing and rather liked the less invasive patch, but
if this one is
Barry A. Warsaw added the comment:
If this fixes the problem, shouldn't the issue be closed and a NEWS item added?
I'm going to test the patch locally.
--
___
Python tracker
<http://bugs.python.o
Barry A. Warsaw added the comment:
On Feb 27, 2014, at 07:23 PM, Antoine Pitrou wrote:
>Hmm... if this *already* affects Ubuntu users, shouldn't this be fixed in 3.4
>proper? It's extremely likely that someone else will be affec
Barry A. Warsaw added the comment:
I've testing this patch on Ubuntu, and it seems to fix the problem. My quick
testing doesn't show any new problems, but we'll only know for sure once the
new Python 3.4 package hits the archive and folks start updating to it. So far
so good
Barry A. Warsaw added the comment:
Nosying Doko, since I think he may want to get this fix into Debian, if Larry
does not cherry pick it into 3.4.0 final.
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/issue19
New submission from Barry A. Warsaw:
This commit fixes the traceback we're seeing on Ubuntu with Python 3.4, in
Popen.__del__ on interpreter shutdown.
--
assignee: larry
components: Interpreter Core
messages: 212443
nosy: barry, doko, larry
priority: release blocker
severity: n
Barry A. Warsaw added the comment:
http://bugs.python.org/issue19021
--
___
Python tracker
<http://bugs.python.org/issue20808>
___
___
Python-bugs-list mailin
Barry A. Warsaw added the comment:
On Feb 28, 2014, at 09:42 PM, Serhiy Storchaka wrote:
>Note that the changeset 6a1711c96fa6 introdused several errors (mostly tests
>failures), so it needs other changesets to fix it. Related changesets which
>should be cherry picked: 6a1
Changes by Barry A. Warsaw :
--
priority: normal -> release blocker
___
Python tracker
<http://bugs.python.org/issue19021>
___
___
Python-bugs-list mai
Barry A. Warsaw added the comment:
On Mar 06, 2014, at 05:31 PM, Larry Hastings wrote:
>Larry Hastings added the comment:
>
>According to #19021, this actually requires six revisions:
>
>6a1711c96fa6
>fa160c8145e5
>efaf12106d68
>7ecee9e0dc58
>10ea3125d7b8
>488ccbe
Barry A. Warsaw added the comment:
On Mar 06, 2014, at 06:41 PM, Serhiy Storchaka wrote:
>
>I thought that 6a1711c96fa6 is already in RC1, that is why I hadn't opened
>cherrypick issue for this. 6a1711c96fa6 is critical change because it not
>only fixes one annoying warning,
Barry A. Warsaw added the comment:
On Mar 06, 2014, at 05:43 PM, Larry Hastings wrote:
>What do you want me to do? Hold off while you determine the correct set of
>changes, or proceed with these six?
I have just verified that if you take the rc2 tarball and apply these six
changesets
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue20884>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue20890>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue20899>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I agree w/Raymond. string + flags
--
___
Python tracker
<http://bugs.python.org/issue6630>
___
___
Python-bugs-list mailin
Barry A. Warsaw added the comment:
Note that the headers in the subpart don't matter at all. I'm sure this
is not a problem with MIME parsing, but with line ending issues. It
might be related to mixing line endings, but we know that the email
package has some line endin
Barry A. Warsaw added the comment:
Please, please, please contact the email-sig and help pitch in. For
many reasons I simply haven't had the cycles to work on this and I don't
see that happening any time soon. There are folks willing to work on
the package in the email-sig and I w
Barry A. Warsaw added the comment:
I agree that this is a release blocker for 2.6.3
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue6844>
___
___
Barry A. Warsaw added the comment:
Agreed this should be a release blocker for 2.6.3
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue6
Barry A. Warsaw added the comment:
Agreed this should be a release blocker for 2.6.3
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue6
Barry A. Warsaw added the comment:
I'm willing to leave this as a release blocker for 2.6.3, but I will
re-evaluate it if no progress is made on it.
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/i
New submission from Barry Alan Scott :
Many Python API functions are causing GCC to rightly complain
that const char * strings are being passed to python functions
that take char * but do not need to modify the args.
g++ reports example.cxx:633: warning: deprecated conversion from string
Barry Alan Scott added the comment:
I'd guess that this change can first be made against 2.7 and 3.2
so that API's do not change.
Where do I find the source code to generate the patch against
for 2.7 and 3.2?
--
___
Python trac
Barry A. Warsaw added the comment:
I'll make this a release blocker, but I agree a test would be useful to
have. Let's try to get this in for 2.6.3.
--
nosy: +barry
priority: -> release blocker
___
Python tracker
<http://bugs.pyth
Changes by Barry A. Warsaw :
--
priority: -> release blocker
___
Python tracker
<http://bugs.python.org/issue6990>
___
___
Python-bugs-list mailing list
Un
Barry A. Warsaw added the comment:
Moving to deferred blocker to get this out of the way for 2.6.3
--
nosy: +barry
priority: release blocker -> deferred blocker
___
Python tracker
<http://bugs.python.org/iss
Barry A. Warsaw added the comment:
Since we do not yet have a patch for this, I'm knocking it off the list
for 2.6.3. It seems like an annoying loss of compatibility, but do we
have any reports of it breaking real-world code?
--
nosy: +barry
priority: release blocker -&
Changes by Barry A. Warsaw :
--
assignee: -> pjenvey
keywords: -needs review
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/
Barry A. Warsaw added the comment:
I'd like to accept this for 2.6.3, but I'd also really like a test for
this change. Giampaolo, do you think you could whip up a test for this.
I know it's short notice.
--
___
Python
Barry A. Warsaw added the comment:
Gaimpaolo thanks. Please give it a try.
--
___
Python tracker
<http://bugs.python.org/issue3890>
___
___
Python-bugs-list m
Barry A. Warsaw added the comment:
Please apply this for 2.6.3rc1
--
priority: -> release blocker
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/
Barry A. Warsaw added the comment:
Thanks for the feedback Giampaolo. It sounds like this patch is not yet
fully baked so I'll defer it to Python 2.6.4.
--
priority: release blocker -> high
___
Python tracker
<http://bugs.python.or
Barry A. Warsaw added the comment:
We'll need tests to include it in 2.6.3.
--
priority: high -> release blocker
___
Python tracker
<http://bugs.python.or
Barry A. Warsaw added the comment:
Not gonna make it for 2.6.3rc1
--
priority: release blocker -> high
___
Python tracker
<http://bugs.python.org/iss
Barry A. Warsaw added the comment:
I'm afraid so. Please consider this for landing after 2.6.3 is released.
--
assignee: barry ->
___
Python tracker
<http://bugs.python.or
Barry A. Warsaw added the comment:
yes. rc1 on 6 oct 2009 and final on 18 oct 2009 (tentative)
--
___
Python tracker
<http://bugs.python.org/issue7064>
___
___
Barry A. Warsaw added the comment:
Tarek, please commit this fix before 2.6.4rc1 (i.e. asap :)
--
priority: -> release blocker
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/
Barry A. Warsaw added the comment:
Sorry, 2.6.4 will be solely to remove the brown paper bag of 2.6.3 from
our heads. This can go in 2.6.5 though.
--
___
Python tracker
<http://bugs.python.org/issue5
Barry A. Warsaw added the comment:
Tarek,
Can you please look at this for 2.6.4? We might need another rc and it
would be better to do that sooner rather than later.
Thanks!
--
priority: -> release blocker
status: closed -> open
___
Barry A. Warsaw added the comment:
Please apply this for 2.6.4rc2
--
priority: -> release blocker
resolution: fixed -> accepted
status: pending -> open
___
Python tracker
<http://bugs.python.o
Barry A. Warsaw added the comment:
Agreed this is a release blocker for 2.6.4rc2.
I plan on tagging the release some time Saturday, probably around 1600
UTC. Do you think you can add a test and apply the patch by then?
--
___
Python tracker
<h
Barry A. Warsaw added the comment:
Making this a deferred blocker so as not to clutter 2.6.4 release.
--
nosy: +barry
priority: release blocker -> deferred blocker
___
Python tracker
<http://bugs.python.org/iss
New submission from Barry A. Warsaw :
Try this:
>>> from urllib2 import build_opener
>>> build_opener().handlers
In Python 2.4, you will see ProxyHandler as the first handler, but this
handler is missing from the list in Python 2.5, 2.6, and 2.7, despite this
text in
Barry A. Warsaw added the comment:
This may end up being just a documentation issue. If the environment
has http_proxy set, you do get a ProxyHandler automatically.
>>> import os
>>> os.environ['http_proxy'] = 'localhost'
>>> from urllib2
Barry Alan Scott added the comment:
Here is my 1st patch to allow const char * and const Py_UNICODE *
It is agsinst http://svn.python.org/projects/python/trunk.
What I have attempted to do is stop the public API of python needing
char * or Py_UNICODE * where the API clearly does not need to
Barry A. Warsaw added the comment:
Ronald, please apply asap. This is the last thing I'm waiting on before
I tag 2.6.4rc2.
--
resolution: -> accepted
___
Python tracker
<http://bugs.python.or
Barry Alan Scott added the comment:
I was trying to avoid changing the const ness of output parameters.
Given the advice not to go mad on putting const everywhere.
1) I can comment the casts to maintain this goal.
2) Or change the output paramter const ness.
Given your feedback I'm gue
Barry A. Warsaw added the comment:
I think this is caused by the fix for bug 5890 and isn't a regression.
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/i
Barry A. Warsaw added the comment:
Apparently this affects more than just Boost. lifeless (Robert Collins)
tells me that "__doc__ becoming readonly buggered some code of ours in
bzr too, IIRC".
He thinks it was in pure Python (i.e. not extension code). Does anybody
have a p
Barry A. Warsaw added the comment:
Robert indicated later that this probably did /not/ affect Bazaar.
--
___
Python tracker
<http://bugs.python.org/issue7
Barry A. Warsaw added the comment:
Thanks David, that's what I suspect too (that's its a problem with
extension types). Unless we get more information, I'm not inclined to
hold up the 2.6.4 release for this.
--
___
Python
Barry A. Warsaw added the comment:
After discussion on python-dev, this will not block 2.6.4
--
priority: release blocker -> high
___
Python tracker
<http://bugs.python.org/iss
Barry Alan Scott added the comment:
Updated patch with comment explaining cast.
--
Added file: http://bugs.python.org/file15184/const_api_r75619.patch
___
Python tracker
<http://bugs.python.org/issue6
Changes by Barry A. Warsaw :
--
assignee: -> barry
priority: -> high
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.pytho
New submission from Barry A. Warsaw :
It would be very useful to have an environment variable $PYTHONWARNINGS,
tied to the -W option for silencing various warnings (most importantly,
DeprecationWarnings).
Use case: a test suite running many subprocesses, testing that those
subproc output is
Barry A. Warsaw added the comment:
Robert's patch looks fine to me. My concern is changing this in a point
release (e.g. 2.6.5). I know Guido said he was fine for this going into
2.6 but that was in January 08, before 2.6 final was released in October
08. At this point, the questi
2201 - 2300 of 2726 matches
Mail list logo
