Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue19888>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
Note that just iterating over namespace doesn't trigger the problem, e.g.
instead of
for name, value in namespace.items(): pass
using
list(namespace.items())
seems to work.
--
___
Python tracker
Barry A. Warsaw added the comment:
Also seems to be triggered on 2.7 (with appropriate syntax adjustments in
bug.py)
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue19
Barry A. Warsaw added the comment:
D'oh! Should have looked closer. ;)
--
___
Python tracker
<http://bugs.python.org/issue19888>
___
___
Python-bugs-list m
Changes by Barry A. Warsaw :
--
title: possible memory corruption caused by for-loop iteration over
namespace.items() in a metaclass defining __new__ -> type.__new__() name
argument is ignored
___
Python tracker
<http://bugs.python.org/issu
Changes by Barry A. Warsaw :
--
resolution: invalid ->
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue19888>
___
___
Python-bugs-
Changes by Barry A. Warsaw :
--
versions: +Python 3.3, Python 3.4 -Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue19888>
___
___
Python-bug
Barry A. Warsaw added the comment:
At best, this is an undocumented (afaict) change in behavior in 3.3. Let's
boil it down:
-snip snip-
class Type(type):
def __new__(mcls, name, bases, namespace):
return super().__new__(mcls, 'foo', bases, namespace)
clas
Barry A. Warsaw added the comment:
I think this is due to the switch from Subversion to Mercurial, which if I'm
reading PEP 385 and remembering correctly, happened about the time of Python
2.6.7. IIRC, we released that source tarball from Subversion so you're seeing
svn build num
Changes by Barry A. Warsaw :
Added file: http://bugs.python.org/file33000/qualname-19888.py
___
Python tracker
<http://bugs.python.org/issue19888>
___
___
Python-bug
Barry A. Warsaw added the comment:
I don't see the value in opening a new bug. Now that we understand what's
going on, let's just repurpose and retitle this one.
Run qualname-19888.py with Python 3.3 and you'll get:
Obj.__name__ foo
Obj.__qualname__ Obj
repr(Obj)
Barry A. Warsaw added the comment:
Oops, correct!
--
___
Python tracker
<http://bugs.python.org/issue19888>
___
___
Python-bugs-list mailing list
Unsubscribe:
On 08.07.2014 11:40, Stefano Borini wrote:
>
> You can't use subprocess. platform is used during build. subprocess needs
> select, but select is a compiled module and at that specific time in the
> build process is not compiled yet.
Good point :-)
--
Marc-Andre L
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue21044>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue21041>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
Aren't negative indexes well defined in Python? E.g.
>>> p = Path('/tmp/tmp123/foo/bar/baz.xz')
>>> p.parents[len(p.parents)-2]
PosixPath('/tmp')
p.parents[-2] should == p.parents[len(p.parents)-2]
--
___
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue22123>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I'm not in favor of changing object() but exposing types.SimpleNamespace as
built-in namespace() doesn't seem like such a bad idea, especially given Tim's
penultimate Zen aphorism.
--
___
Python
Barry A. Warsaw added the comment:
I like it. Thanks for the contribution! Assigning to myself since I plan on
working to land this in 3.5.
--
assignee: -> barry
___
Python tracker
<http://bugs.python.org/issu
Changes by Barry A. Warsaw :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue21539>
___
___
Python-bugs-list
Barry A. Warsaw added the comment:
On Aug 06, 2014, at 09:43 PM, Nick Coghlan wrote:
>I'd be +1 on a PEP to also expose it as a "namespace" builtin.
Is a PEP necessary? Seems like a rather isolated and simple enhancement.
--
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue22195>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue22257>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Aug 30, 2014, at 07:34 PM, Ethan Furman wrote:
>In other words, this was a bug that no one noticed for many many releases,
>and I'm not sure we should fix it in 2.7 now.
>
>Arguments for fixing?
-1 on fixing it, but we *can* document wor
New submission from Barry A. Warsaw:
Lots of them, just like this:
==
FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with NULL ob_type is handled gracefully
Changes by Barry A. Warsaw :
--
versions: +Python 3.4
___
Python tracker
<http://bugs.python.org/issue22327>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/issue16662>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
assignee: michael.foord -> barry
___
Python tracker
<http://bugs.python.org/issue16662>
___
___
Python-bugs-list mailing list
Un
Changes by Barry A. Warsaw :
--
versions: -Python 3.4
___
Python tracker
<http://bugs.python.org/issue16662>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
One thing I really do not like about Rob's last patch is that it exacerbates
the documentation discrepancy for loadTestsFromModule(). As previously
mentioned, use_load_tests arg was already not documented, and now the patch
adds another undocumented pa
Barry A. Warsaw added the comment:
pattern will have to be documented and accepted as official API
--
___
Python tracker
<http://bugs.python.org/issue16
Barry A. Warsaw added the comment:
So, I think what I'm going to do is change the sig of the method to:
def loadTestsFromModule(self, module, *args, pattern=None, **kws):
I.e. the new `pattern` arg will be keyword-only. *args and **kws will be parsed
for use_load_tests usage
Changes by Barry A. Warsaw :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue16662>
___
___
Python-bugs-list
New submission from Barry A. Warsaw:
redirect_stdout is almost exactly what I want, except I want to redirect
stderr! redirect_stdout.__init__() should take a 'stream_name' argument
(possibly keyword-only) which could be set to 'stderr'. I propose it's
i
Barry A. Warsaw added the comment:
On Sep 11, 2014, at 02:25 PM, STINNER Victor wrote:
>Why not adding a new redirect_stderr() function?
With a little refactoring redirect_stdout into a subclass, that would work
too.
--
___
Python tracker
&l
Barry A. Warsaw added the comment:
On Sep 11, 2014, at 07:23 AM, STINNER Victor wrote:
>The changeset d0ff527c53da5b925b61a8a70afc686ca6e05960 related to this issue
>introduced a regression in test_unittest. The test now fails on
>Windows.
Darn. I don't have Windows handy to
Barry A. Warsaw added the comment:
Note that this change broke eventlet:
https://github.com/eventlet/eventlet/issues/135
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue21
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue22438>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I tend to agree. I don't even think it was documented. I wonder though if it
makes sense to at least mention this in the PEP and/or release notes for 2.7.9.
--
___
Python tracker
<http://bugs.py
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue9951>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Changes by Andrej A Antonov :
--
nosy: +polymorphm
___
Python tracker
<http://bugs.python.org/issue21356>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
1901 - 2000 of 2582 matches
Mail list logo
