On Wed, Sep 18, 2013 at 2:11 AM, Rotwang sg...@hotmail.co.uk wrote:
I don't know tkinter well enough either, but the fact that it behaves
differently on Linux and Windows suggests to me that at least one version is
bugging out. Do you think this is worth raising on bugs.python.org?
Possibly,
reloading the module and calling the function again, this time
the first of the two warnings raises the exception. Since I don't really
understand how the ttk.Style class works, I can't say whether this
behaviour is expected or not. But here's what's weird. Suppose that I
comment out the last
16.09.13 19:28, Rotwang написав(ла):
On Windows 7 (sys.version is '3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012,
10:57:17) [MSC v.1600 64 bit (AMD64)]') there's no problem; f() works
fine in the first place. Does anybody know what's going on?
What _root.wantobjects() returns?
--
On Tue, Sep 17, 2013 at 2:28 AM, Rotwang sg...@hotmail.co.uk wrote:
If I then uncomment those two lines, reload the module and call f() again
(by entering tkderp.reload(tkderp).f()), the function works like it was
supposed to in the first place: two warnings, no exceptions. I can reload
the
Changes by Phil Connell pconn...@gmail.com:
--
nosy: +pconnell
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17669
___
___
Python-bugs-list
Roundup Robot added the comment:
New changeset 516303f32bad by Benjamin Peterson in branch '3.3':
add a test for issue #17669 (closes #18565)
http://hg.python.org/cpython/rev/516303f32bad
--
___
Python tracker rep...@bugs.python.org
Raymond Hettinger added the comment:
Closing for the reasons lists above.
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11908
___
discovered something about lists that explains the very first weird
result I was observing, which I realized was because lists are mutable etc, but
more specifically:
This
a = [1, 2]
a += [3]
is equivalent to, AFAIK, this
a = [1, 2]
a.extend([3])
So to overcome that you just have to do
a = [1
I got it! One of the testcases was wrong,
([[1], [1]],[1],[1, 1]),
should be
([[1], [1]],[1],[1, 1, 1]),
And the working solution.
def supersum(sequence, start=0):
result = start
start = type(start)()
for item in sequence:
try:
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11908
___
___
Python-bugs-list
I know this is simple but I've been starring at it for half an hour and trying
all sorts of things in the interpreter but I just can't see where it's wrong.
def supersum(sequence, start=0):
result = start
for item in sequence:
try:
result += supersum(item, start)
Nevermind!
Stupid of me to forget that lists or mutable so result and start both point to
the same list.
--
http://mail.python.org/mailman/listinfo/python-list
Since I've already wasted a thread I might as well...
Does this serve as an acceptable solution?
def supersum(sequence, start=0):
result = type(start)()
for item in sequence:
try:
result += supersum(item, start)
except:
result += item
return
Russel Walker wrote:
Since I've already wasted a thread I might as well...
Does this serve as an acceptable solution?
def supersum(sequence, start=0):
result = type(start)()
for item in sequence:
try:
result += supersum(item, start)
except:
On Sat, Jul 6, 2013 at 10:37 PM, Russel Walker russ.po...@gmail.com wrote:
This works:
- - - - - -
x = [[1], [2], [3]]
supersum(x)
6
supersum(x, [])
[1, 2, 3]
This does not:
- - - - - - -
x = [[[1], [2]], [3]]
supersum(x, [])
[1, 2, 1, 2, 3]
You have a problem of specification
On 6 July 2013 13:59, Russel Walker russ.po...@gmail.com wrote:
Since I've already wasted a thread I might as well...
Does this serve as an acceptable solution?
def supersum(sequence, start=0):
result = type(start)()
for item in sequence:
try:
result +=
On 7/6/2013 8:37 AM, Russel Walker wrote:
I know this is simple but I've been starring at it for half an hour and trying
all sorts of things in the interpreter but I just can't see where it's wrong.
def supersum(sequence, start=0):
result = start
for item in sequence:
try:
On 06/07/2013 19:43, Joshua Landau wrote:
On 6 July 2013 13:59, Russel Walker russ.po...@gmail.com wrote:
Since I've already wasted a thread I might as well...
Does this serve as an acceptable solution?
def supersum(sequence, start=0):
result = type(start)()
for item in sequence:
On 06/07/2013 21:10, Rotwang wrote:
[...]
It's not quite clear to me what the OP's intentions are in the general
case, but calling supersum(item, start) seems odd - for example, is the
following desirable?
supersum([[1], [2], [3]], 4)
22
I would have thought that the correct answer would be
On Jun 18, 8:31 pm, zoom z...@yahoo.com wrote:
yes, that's the hing.
thanks a lot
FYI this happens because
shape(mean(m,1))
(4, 1)
shape(mean(array(m),1))
(4,)
thanks again
And thank you for the 'Thank you' !!
Given the noob-questions the list is currently dealing with, your
to reproduce the weird behavior that I'm about to describe.)
If i run it in terminal via python test.py command I get the following
output:
(4, 2)
[2, 1]
(1, 8)
.
--
Ran 1 test in 0.000s
OK
Now comes the funny part.
Let's try to run
that test.py, is just a simplification of my testing file,
sufficient to reproduce the weird behavior that I'm about to describe.)
If i run it in terminal via python test.py command I get the following
output:
(4, 2)
[2, 1]
(1, 8
= matrix(self.m)
print shape(m)
print [shape(m)[1],1]
print shape(tile(mean(m,1),[shape(m)**[1],1]).T)
if __name__ == '__main__':
unittest.main()
(Note that test.py, is just a simplification of my testing file,
sufficient to reproduce the weird behavior that I'm
of my testing file, sufficient to
reproduce the weird behavior that I'm about to describe.)
If i run it in terminal via python test.py command I get the following output:
(4, 2)
[2, 1]
(1, 8)
.
--
Ran 1 test in 0.000s
OK
Now
':
unittest.main()
(Note that test.py, is just a simplification of my testing file,
sufficient to reproduce the weird behavior that I'm about to describe.)
If i run it in terminal via python test.py command I get the following
output:
(4, 2)
[2, 1]
(1, 8
file,
sufficient to
reproduce the weird behavior that I'm about to describe.)
If i run it in terminal via python test.py command I get the
following output:
(4, 2)
[2, 1]
(1, 8)
.
--
Ran 1 test in 0.000s
OK
Now comes the funny
Eric Promislow added the comment:
I found a workaround in our debugger code, so you can lower the priority on
this, or even mark it Wontfix, although I still
think the frame stack is getting messed up.
One thing about our debugger, it essentially runs all the Python code in a big
exec
Benjamin Peterson added the comment:
If you ever find a Python bug, feel free to reopen.
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17971
http://bugs.activestate.com/show_bug.cgi?id=98951
--
components: Interpreter Core
messages: 189183
nosy: ericp
priority: normal
severity: normal
status: open
title: Weird interaction between Komodo Python debugger C module Python 3
type: behavior
versions: Python 3.2, Python 3.3
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +georg.brandl, ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17971
___
___
Benjamin Peterson added the comment:
Since this seems to be some sort of interaction between Komodo's code and
Python (it works for me with vanilla Python 3), it's going to be hard to debug
without seeing what this other thing is doing.
--
nosy: +benjamin.peterson
Eric Promislow added the comment:
I'm running it inside gdb to see if I can figure it out.
I don't see a way of isolating this from the whole product.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17971
Forafo San ppv.g...@gmail.com wrote:
OK, lesson learned: Take care not to have module names that conflict with
python's built ins. Sorry for being so obtuse.
You don't have to apologize. We've all been bitten by this at least once.
--
Tim Roberts, t...@probo.com
Providenza Boekelheide, Inc.
On Apr 26, 11:04 am, Tim Roberts t...@probo.com wrote:
Forafo San ppv.g...@gmail.com wrote:
OK, lesson learned: Take care not to have module names that conflict with
python's built ins. Sorry for being so obtuse.
You don't have to apologize. We've all been bitten by this at least once.
On Apr 26, 11:25 am, rusi rustompm...@gmail.com wrote:
To present these kind of errors, Erlang has a concept of sticky
modules -- those that come from the system…
??present?? should have been 'prevent'
--
http://mail.python.org/mailman/listinfo/python-list
')
TypeError: 'module' object is not callable
--
The file glob.py that the error refers to was run under another
screen session. It's a mystery why even that program threw an
error. Regardless, why should that session throw an import
error in this session? Weird
--
The file glob.py that the error refers to was run under another screen session.
It's a mystery why even that program threw an error. Regardless, why should
that session throw an import error in this session? Weird. Any help is
appreciated. Thanks,
-Premal
--
http://mail.python.org
even that program threw an
error. Regardless, why should that session throw an import
error in this session? Weird. Any help is appreciated. Thanks,
'Cause Python's import statement looks in the current directory
first for files to import. So you're importing your own
error
On Apr 21, 9:19 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Mon, 22 Apr 2013 10:56:11 +1000, Chris Angelico wrote:
You're running this under Windows. The convention on Windows is for
end-of-line to be signalled with \r\n, but the convention inside Python
is to use
On Tuesday, April 23, 2013 12:29:57 AM UTC+10, nn wrote:
Maybe it is related to this bug?
http://bugs.python.org/issue11272
I'm running Python 2.7.2 (on Windows) and that version doesn't appear to have
that bug:
Python 2.7.2 (default, Apr 23 2013, 11:49:52) [MSC v.1500 32 bit (Intel)] on
On Tue, Apr 23, 2013 at 9:06 AM, jus...@zeusedit.com wrote:
On Tuesday, April 23, 2013 12:29:57 AM UTC+10, nn wrote:
Maybe it is related to this bug?
http://bugs.python.org/issue11272
I'm running Python 2.7.2 (on Windows) and that version doesn't appear to have
that bug:
Python 2.7.2
On Mon, 22 Apr 2013 07:29:57 -0700, nn wrote:
On Apr 21, 9:19 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Mon, 22 Apr 2013 10:56:11 +1000, Chris Angelico wrote:
You're running this under Windows. The convention on Windows is for
end-of-line to be signalled with
Can someone please explain the following behaviour?
I downloaded and compiled the Python 2.7.2 code base.
I then created this simple c:\temp\test.py macro:
import sys
def main():
print(Please Input 120: )
input = raw_input()
print(Value Inputed: +
On Mon, Apr 22, 2013 at 10:37 AM, jus...@zeusedit.com wrote:
Can someone please explain the following behaviour?
If I run the macro using the -u (flush buffers) option the if statement
always fails:
C:\Temppython.exe -u c:\temp\test.py
Please Input 120:
120
Value
On Sun, 21 Apr 2013 17:37:18 -0700, jussij wrote:
Can someone please explain the following behaviour?
I downloaded and compiled the Python 2.7.2 code base.
I then created this simple c:\temp\test.py macro:
import sys
def main():
print(Please Input 120: )
On Monday, April 22, 2013 10:56:11 AM UTC+10, Chris Angelico wrote:
so your string actually contains '120\r', as will be revealed
by its repr().
Thanks Chris. That makes sense.
Cheers Jussi
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, Apr 22, 2013 at 11:05 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
I cannot confirm that behaviour. It works fine for me.
I should mention: Under Linux, there's no \r, so -u or no -u, the
program will work fine.
ChrisA
--
On Mon, 22 Apr 2013 10:56:11 +1000, Chris Angelico wrote:
You're running this under Windows. The convention on Windows is for
end-of-line to be signalled with \r\n, but the convention inside Python
is to use just \n. With the normal use of buffered and parsed input,
this is all handled for
On Monday, April 22, 2013 11:05:11 AM UTC+10, Steven D'Aprano wrote:
I cannot confirm that behaviour. It works fine for me.
As Chris pointed out there is a \r character at the end of the string and that
is causing the if to fail.
I can now see the \r :)
So this is *Windows only* behaviour.
Roundup Robot added the comment:
New changeset 35cb75b9d653 by Benjamin Peterson in branch '3.3':
don't run frame if it has no stack (closes #17669)
http://hg.python.org/cpython/rev/35cb75b9d653
New changeset 0b2d4089180c by Benjamin Peterson in branch 'default':
merge 3.3 (#17669)
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17669
___
2012, 10:55:48) [MSC v.1600 32
bit (Intel)] on win32
NOTES: If you get rid of import logging in generators.py, it only crashes if
there's no __pycache__
--
title: Segfault caused by - Segfault caused by weird combination of imports
and yield from
Added file: http://bugs.python.org
Frank Hamand added the comment:
The file contents so people dont have to download the zip:
generators.py:
---
def subgen():
yield
def other_gen(self):
move = yield from subgen()
game.py:
---
class Game(object):
def
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +benjamin.peterson, ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17669
___
___
R. David Murray added the comment:
The crashing version has 'import logging' at the top of generators.py. I did
not experience a crash when it was absent even if there was no __pycache__.
It also doesn't crash if the import is moved out of the body of first_gen.
FAULTHANDLER doesn't fair too
Benjamin Peterson added the comment:
This is the patch. I'll have to think about whether there's a self-contained
way to test this.
--
assignee: - benjamin.peterson
keywords: +patch
Added file: http://bugs.python.org/file29748/gen_fix.patch
___
Thomas Waldmann added the comment:
gave 2.7.4rc1 a try and was seeing a failing unit test that does not fail with
2.7.3.
see the attached file for some minimal code that succeeds on 2.7.3, but not on
2.7.4rc1.
it seems to have to do with being a subclass of Exception, it doesn't happen
for
Roundup Robot added the comment:
New changeset 391e3a7db1a3 by Benjamin Peterson in branch '2.7':
allow any type with __getitem__ to be a mapping for the purposes of % (#15801)
http://hg.python.org/cpython/rev/391e3a7db1a3
--
___
Python tracker
Benjamin Peterson added the comment:
Thanks for the report. Will be fixed in 2.7.4.
--
nosy: +benjamin.peterson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15801
___
Changes by Piotr Dobrogost p...@bugs.python.dobrogost.net:
--
nosy: +piotr.dobrogost
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17322
___
___
R. David Murray added the comment:
A crazy idea that occurred to me was to create an rfc822-style-header
management module, and share it between email, http, and urllib. We'd
probably break too many things backward-compatibility wise if we did that, but
I still think it is an interesting
karl added the comment:
R. David.:
A crazy idea that occurred to me was to create an rfc822-style-header
management module, and share it between email, http, and urllib.
Yes it is basically what I had in mind when I said:
Maybe the way forward in the future is to have a header factory
R. David Murray added the comment:
Aren't the folding rules are the same? The character set rules are different,
I think, but the email package is going to be flexible in that regard.
The email package also uses a data structure that is not a python dictionary
(it is actually a list with an
R. David Murray added the comment:
Given that this is an RFC violation it looks appropriate as a bug fix for all
active versions to me. The patch looks good, though I might decide to break up
the test.
--
nosy: +r.david.murray
stage: - commit review
type: - behavior
versions:
R. David Murray added the comment:
Ah, but that's a draft and not approved. Hmm. There is a possibility this
change would break code, if the code tries to look up a header by the same key
it used to set it. On the other hand, the key use for the set is already
modified by the existing
R. David Murray added the comment:
Here is a modified patch with the tests moved to test_urllib2. I'll give
people some time to comment on whether this should be applied at all, and if so
if it should be backported. I'm leaning toward doing both, at the moment.
Karl, thanks for the report
Senthil Kumaran added the comment:
David Karl -
I had been thinking on this. My understanding of the RFC implies that server
should reject when the headers contain the whitespace and I had a little
concern if the client library should feel free to cleanup a wrongly set
headers? Would it be
R. David Murray added the comment:
Good point. Seeing what curl does sounds like a good idea.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17322
___
Senthil Kumaran added the comment:
Looks like curl is sending the headers without removing spaces.
Check Raw here link here. (The link would probably be online a week)
http://requestb.in/1kfodmj1?inspect
$ curl --header X-MyHeader: 123 http://requestb.in/1kfodmj1
ok
$ curl --header
karl added the comment:
Hello,
So I tested a bit. The production rules defined by the specification are clear.
Spaces before and after are forbidden.
header-field = field-name : OWS field-value BWS
field-name = token
field-value= *( field-content / obs-fold )
Senthil Kumaran added the comment:
Oh wow. Thank you very much Karl for the care. I am having the same
inclination are you too, but determining a definite answer is really
helpful before going ahead into making the change.
--
___
Python tracker
Senthil Kumaran added the comment:
The curl example also suggest to think about pragamatic de-facto
stuff. Will removing the spaces cause any breakage? I can say for
sure. But if someone can think of it, it would be good for at least us
know.
--
___
karl added the comment:
OK. I'm inclined to think that we should both remove trailing and leading
spaces/tabs should be removed.
Reasons:
1. Production rules forbid them.
2. Trailing spaces
2.a Conformant servers will ignore with a 400 bad request (opportunity for
another bugs?)
2.b
R. David Murray added the comment:
It is a bug in the program, though, and not particularly in the client library.
As mentioned, it can even be useful for testing servers.
In the email package we faithfully reproduce such headers if they are passed
in. The only one we disallow is something
karl added the comment:
R. David Murray,
You are right it is not specific to the client library. HTTP headers are part
of the message (Request/Response) with both the same constraints. Constraints
are put on receivers (receiving a message) and senders (sending a message) of
the message
karl added the comment:
http://hg.python.org/cpython/file/3.3/Lib/urllib/request.py#l359
def add_header(self, key, val):
# useful for something like authentication
self.headers[key.capitalize()] = val
and http://hg.python.org/cpython/file/3.3/Lib/urllib/request.py#l271
in
karl added the comment:
I created 4 tests for testing trailing and leading spaces on
* add_unredirected_header()
* add_header()
and modified the functions.
Tests passed.
→ ./python.exe Lib/test/test_urllib2net.py
[…]
test_headers_with_spaces (__main__.OtherNetworkTests) ... ok
[…]
Changes by karl karl+pythonb...@la-grange.net:
--
title: urllib.request add_header() currently allows trailing spaces -
urllib.request add_header() currently allows trailing spaces (and other weird
stuff)
___
Python tracker rep...@bugs.python.org
karl added the comment:
Yet another one leading spaces :(
req = urllib.request.Request('http://www.example.com/')
req.header_items()
[]
req.add_header(' Foo3', 'Ooops')
req.header_items()
[(' foo3', 'Ooops')]
req.headers
{' foo3': 'Ooops'}
--
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: commit review -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11908
___
___
This is kind of weird (Python 2.7.3):
try:
print hello
except foo:
print foo
prints hello. The problem (IMHO) is that apparently the except clause
doesn't get evaluated until after some exception is caught. Which means
it never notices that foo is not defined until it's too late
On 2/12/12 18:25:22, Roy Smith wrote:
This is kind of weird (Python 2.7.3):
try:
print hello
except foo:
print foo
prints hello. The problem (IMHO) is that apparently the except clause
doesn't get evaluated until after some exception is caught. Which means
it never notices
On 12/2/2012 12:25 PM, Roy Smith wrote:
This is kind of weird (Python 2.7.3):
try:
print hello
except foo:
print foo
prints hello. The problem (IMHO) is that apparently the except clause
doesn't get evaluated until after some exception is caught. Which means
it never notices
On Sun, 02 Dec 2012 12:25:22 -0500, Roy Smith wrote:
This is kind of weird (Python 2.7.3):
try:
print hello
except foo:
print foo
prints hello. The problem (IMHO) is that apparently the except clause
doesn't get evaluated until after some exception is caught. Which means
:
recover()
Legal it may be, but are there times when you actually _need_ this
level of dynamism? It strikes me as a pretty weird way of going about
things.
I agree with the point you're making, but this feels like a contrived
example, and I'm curious as to whether it can be uncontrived.
ChrisA
= AnotherException
try:
spam(a, b, c)
except Err:
recover()
Legal it may be, but are there times when you actually _need_ this level
of dynamism? It strikes me as a pretty weird way of going about things.
I agree with the point you're making, but this feels like a contrived
example
On Mon, Dec 3, 2012 at 6:30 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Yeah, in hindsight it was a pretty crappy example. But this sort of
dynamism really is useful:
def testRaises(exc, func, *args):
try:
result = func(*args)
except exc:
return
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11908
___
___
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
priority: normal - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11908
___
___
Raymond Hettinger added the comment:
ysj: The equivalent means roughly equivalent not precisely equivalent.
The purpose of the code in the docs is to help communicate what islice() is all
about. Practicality beats purity in this regard. I know of no one who has
ever been mislead by the
Serhiy Storchaka added the comment:
LGTM. However note, that for 2.7 the patch should be modified (maxsize -
maxint, range - xrange).
--
nosy: +serhiy.storchaka
stage: needs patch - commit review
versions: +Python 3.4
___
Python tracker
Hi,
I have encountered some strange behavior of isinstance(/issubclass): depending
on the import path used for classes i get different output, while the classes i
compare are in the same file.
Basically if i import a class as:
from mod1.mod2 import A
or:
from mod0.mod1.mod2 import
On Fri, Nov 30, 2012 at 1:59 AM, lars van gemerden l...@rational-it.com wrote:
Basically if i import a class as:
from mod1.mod2 import A
or:
from mod0.mod1.mod2 import A
which both result in importing the same class, a call to isinstance(inst, A)
in another module can have a
On Thursday, November 29, 2012 3:59:37 PM UTC+1, lars van gemerden wrote:
Hi,
I have encountered some strange behavior of isinstance(/issubclass):
depending on the import path used for classes i get different output, while
the classes i compare are in the same file.
Basically
with
the corresponding .py file. That's not supposed to happen,
but if it does, you can get weird results.
One last idea: put these lines at the top of test_foo.py
import pdb
pdb.set_trace()
Running under nosetest should then drop you in the debugger.
Single step into the next statement (import pyza.models
On Thu, Nov 29, 2012 at 9:07 AM, lars van gemerden l...@rational-it.comwrote:
PS: this is somewhat simpler than the actual case i've encountered, and
i haven't tested this exact case, but for now i hope this is enough to get
some of your insight.
I know for sure that the imports both import
On 11/29/2012 9:59 AM, lars van gemerden wrote:
Hi,
I have encountered some strange behavior of isinstance(/issubclass): depending
on the import path used for classes i get different output, while the classes i
compare are in the same file.
Basically if i import a class as:
from
In article 50b78e26$0$6945$e4fe5...@news2.news.xs4all.nl,
Hans Mulder han...@xs4all.nl wrote:
That is baffling indeed. It looks like nose is adding some
directory to sys.path, which contains a module pyza.py instead
of a package.
We finally figured it out. As it turns out, that's pretty
I've got a minimal test script:
-
$ cat test_foo.py
import pyza.models
print pyza.models
def test_foo():
pass
-
pyza.models is a package. Under normal conditions, I can import it fine:
$ python
Python 2.7.3 (default, Aug 1 2012,
Roundup Robot added the comment:
New changeset 1d700e1aff33 by Benjamin Peterson in branch '3.3':
don't shadow the __qualname__ descriptor with __qualname__ in the class's
__dict__ (closes #16271)
http://hg.python.org/cpython/rev/1d700e1aff33
--
nosy: +python-dev
resolution: - fixed
401 - 500 of 1043 matches
Mail list logo
