[ python-Bugs-1545463 ] New-style classes fail to cleanup attributes
Bugs item #1545463, was opened at 2006-08-23 14:24
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: New-style classes fail to cleanup attributes
Initial Comment:
> cat x.py
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
class B:
x = X('old')
> python x.py
creating X('new')
creating X('old')
deleting X('old')
Python 2.4.2 (#2, Jan 13 2006, 12:00:38)
Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11)
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-30 09:22
Message:
Logged In: YES
user_id=764593
The funny interaction with modules is probably that the
module retains a reference to the class (and vice versa),
so the class can't go away until the module does -- and a
module in sys.modules can't go away.
The __del__ methods are not called if the interpreter can't
decide which to call first. For example, if
A.attr=B
B.attr=A
then A and B form a cycle (like the class and its defining
module). If only one has a __del__ method, it gets called,
but if both do, then python doesn't know which to call
first, so it never calls either.
You may have a cycle like
module <==> class <==>instanceA
\ <==>instanceB
So that it can't decide whether to take care of instanceA
or instanceB first.
Or it might be that the __del__ methods actually are being
called, but not until module teardown has begun, so they
don't work right.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 20:08
Message:
Logged In: YES
user_id=835142
I used __del__ just to illustrate the problem. In real life
application, X was a type defined in a C module and I've
noticed that it's tp_dealloc is not called on instances
assigned to class variables.
BTW, what are the circumstances when __del__() methods are
not called for objects that still exist when the interpreter
exits?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 19:18
Message:
Logged In: YES
user_id=849994
There's also this sentence in the __del__ docs:
"""
It is not guaranteed that __del__() methods are called for
objects that still exist when the interpreter exits.
"""
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 18:54
Message:
Logged In: YES
user_id=835142
Yes, I've found that (using gc.get_referrers!), but this
does not explain why A is not cleaned up when the program exits.
Note that if I put class A definition inside a function, it
does get cleaned up. Must be some funny interation between
module and new-style class objects.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 18:45
Message:
Logged In: YES
user_id=849994
Note that new-style classes are always part of a reference
cycle (you can find this out via gc.get_referrers).
Therefore, they will not be deleted instantly, but only
after gc collects them (you can trigger that via gc.collect).
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 18:01
Message:
Logged In: YES
user_id=835142
It looks like the class object is not deleted alltogether:
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
del A
Output:
creating X('new')
deleting X('new')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545463 ] New-style classes fail to cleanup attributes
Bugs item #1545463, was opened at 2006-08-23 14:24
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: New-style classes fail to cleanup attributes
Initial Comment:
> cat x.py
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
class B:
x = X('old')
> python x.py
creating X('new')
creating X('old')
deleting X('old')
Python 2.4.2 (#2, Jan 13 2006, 12:00:38)
Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11)
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-30 09:34
Message:
Logged In: YES
user_id=764593
Looking at your example code (as best I can guess about
indentation), it looks like
module x <==> class X
module x <==> class A ==> A's instance x ==> class X
module x <==> class B ==> B's instance x ==> class X
So the x instances can't go away until A and B do, which
means at module cleanup. But when the module cleans up, it
may well clean up X before A, so that A.x no longer has an
active class, so that it can't find its __del__ method.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-30 09:22
Message:
Logged In: YES
user_id=764593
The funny interaction with modules is probably that the
module retains a reference to the class (and vice versa),
so the class can't go away until the module does -- and a
module in sys.modules can't go away.
The __del__ methods are not called if the interpreter can't
decide which to call first. For example, if
A.attr=B
B.attr=A
then A and B form a cycle (like the class and its defining
module). If only one has a __del__ method, it gets called,
but if both do, then python doesn't know which to call
first, so it never calls either.
You may have a cycle like
module <==> class <==>instanceA
\ <==>instanceB
So that it can't decide whether to take care of instanceA
or instanceB first.
Or it might be that the __del__ methods actually are being
called, but not until module teardown has begun, so they
don't work right.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 20:08
Message:
Logged In: YES
user_id=835142
I used __del__ just to illustrate the problem. In real life
application, X was a type defined in a C module and I've
noticed that it's tp_dealloc is not called on instances
assigned to class variables.
BTW, what are the circumstances when __del__() methods are
not called for objects that still exist when the interpreter
exits?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 19:18
Message:
Logged In: YES
user_id=849994
There's also this sentence in the __del__ docs:
"""
It is not guaranteed that __del__() methods are called for
objects that still exist when the interpreter exits.
"""
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 18:54
Message:
Logged In: YES
user_id=835142
Yes, I've found that (using gc.get_referrers!), but this
does not explain why A is not cleaned up when the program exits.
Note that if I put class A definition inside a function, it
does get cleaned up. Must be some funny interation between
module and new-style class objects.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 18:45
Message:
Logged In: YES
user_id=849994
Note that new-style classes are always part of a reference
cycle (you can find this out via gc.get_referrers).
Therefore, they will not be deleted instantly, but only
after gc collects them (you can trigger that via gc.collect).
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 18:01
Message:
Logged In: YES
user_id=835142
It looks like the class object is not deleted alltogether:
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
del A
Output:
creating X('new')
deleting X('new')
[ python-Bugs-1545463 ] New-style classes fail to cleanup attributes
Bugs item #1545463, was opened at 2006-08-23 14:24
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: New-style classes fail to cleanup attributes
Initial Comment:
> cat x.py
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
class B:
x = X('old')
> python x.py
creating X('new')
creating X('old')
deleting X('old')
Python 2.4.2 (#2, Jan 13 2006, 12:00:38)
Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11)
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-30 09:36
Message:
Logged In: YES
user_id=764593
I suggest changing status to Pending Close - not a bug.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-30 09:34
Message:
Logged In: YES
user_id=764593
Looking at your example code (as best I can guess about
indentation), it looks like
module x <==> class X
module x <==> class A ==> A's instance x ==> class X
module x <==> class B ==> B's instance x ==> class X
So the x instances can't go away until A and B do, which
means at module cleanup. But when the module cleans up, it
may well clean up X before A, so that A.x no longer has an
active class, so that it can't find its __del__ method.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-30 09:22
Message:
Logged In: YES
user_id=764593
The funny interaction with modules is probably that the
module retains a reference to the class (and vice versa),
so the class can't go away until the module does -- and a
module in sys.modules can't go away.
The __del__ methods are not called if the interpreter can't
decide which to call first. For example, if
A.attr=B
B.attr=A
then A and B form a cycle (like the class and its defining
module). If only one has a __del__ method, it gets called,
but if both do, then python doesn't know which to call
first, so it never calls either.
You may have a cycle like
module <==> class <==>instanceA
\ <==>instanceB
So that it can't decide whether to take care of instanceA
or instanceB first.
Or it might be that the __del__ methods actually are being
called, but not until module teardown has begun, so they
don't work right.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 20:08
Message:
Logged In: YES
user_id=835142
I used __del__ just to illustrate the problem. In real life
application, X was a type defined in a C module and I've
noticed that it's tp_dealloc is not called on instances
assigned to class variables.
BTW, what are the circumstances when __del__() methods are
not called for objects that still exist when the interpreter
exits?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 19:18
Message:
Logged In: YES
user_id=849994
There's also this sentence in the __del__ docs:
"""
It is not guaranteed that __del__() methods are called for
objects that still exist when the interpreter exits.
"""
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 18:54
Message:
Logged In: YES
user_id=835142
Yes, I've found that (using gc.get_referrers!), but this
does not explain why A is not cleaned up when the program exits.
Note that if I put class A definition inside a function, it
does get cleaned up. Must be some funny interation between
module and new-style class objects.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 18:45
Message:
Logged In: YES
user_id=849994
Note that new-style classes are always part of a reference
cycle (you can find this out via gc.get_referrers).
Therefore, they will not be deleted instantly, but only
after gc collects them (you can trigger that via gc.collect).
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 18:01
Message:
Logged In: YES
user_id=835142
It looks like the class object is not deleted alltogether:
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)'
[ python-Bugs-1545463 ] New-style classes fail to cleanup attributes
Bugs item #1545463, was opened at 2006-08-23 14:24
Message generated for change (Comment added) made by belopolsky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: New-style classes fail to cleanup attributes
Initial Comment:
> cat x.py
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
class B:
x = X('old')
> python x.py
creating X('new')
creating X('old')
deleting X('old')
Python 2.4.2 (#2, Jan 13 2006, 12:00:38)
Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11)
--
>Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-30 09:53
Message:
Logged In: YES
user_id=835142
Is it true that a class retains reference to the module? The '__module__'
attribute
is a string, not a reference to the module. Maybe you are talking about
something else ...
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-30 09:36
Message:
Logged In: YES
user_id=764593
I suggest changing status to Pending Close - not a bug.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-30 09:34
Message:
Logged In: YES
user_id=764593
Looking at your example code (as best I can guess about
indentation), it looks like
module x <==> class X
module x <==> class A ==> A's instance x ==> class X
module x <==> class B ==> B's instance x ==> class X
So the x instances can't go away until A and B do, which
means at module cleanup. But when the module cleans up, it
may well clean up X before A, so that A.x no longer has an
active class, so that it can't find its __del__ method.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-30 09:22
Message:
Logged In: YES
user_id=764593
The funny interaction with modules is probably that the
module retains a reference to the class (and vice versa),
so the class can't go away until the module does -- and a
module in sys.modules can't go away.
The __del__ methods are not called if the interpreter can't
decide which to call first. For example, if
A.attr=B
B.attr=A
then A and B form a cycle (like the class and its defining
module). If only one has a __del__ method, it gets called,
but if both do, then python doesn't know which to call
first, so it never calls either.
You may have a cycle like
module <==> class <==>instanceA
\ <==>instanceB
So that it can't decide whether to take care of instanceA
or instanceB first.
Or it might be that the __del__ methods actually are being
called, but not until module teardown has begun, so they
don't work right.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 20:08
Message:
Logged In: YES
user_id=835142
I used __del__ just to illustrate the problem. In real life
application, X was a type defined in a C module and I've
noticed that it's tp_dealloc is not called on instances
assigned to class variables.
BTW, what are the circumstances when __del__() methods are
not called for objects that still exist when the interpreter
exits?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 19:18
Message:
Logged In: YES
user_id=849994
There's also this sentence in the __del__ docs:
"""
It is not guaranteed that __del__() methods are called for
objects that still exist when the interpreter exits.
"""
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 18:54
Message:
Logged In: YES
user_id=835142
Yes, I've found that (using gc.get_referrers!), but this
does not explain why A is not cleaned up when the program exits.
Note that if I put class A definition inside a function, it
does get cleaned up. Must be some funny interation between
module and new-style class objects.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 18:45
Message:
Logged In: YES
user_id=849994
Note that new-style classes are always part of a reference
cycle (you can find this out via gc.get_referrers).
Therefore, they will not be deleted instantly, but only
after gc collects them (you can trigg
[ python-Bugs-1545463 ] New-style classes fail to cleanup attributes
Bugs item #1545463, was opened at 2006-08-23 14:24
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: New-style classes fail to cleanup attributes
Initial Comment:
> cat x.py
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
class B:
x = X('old')
> python x.py
creating X('new')
creating X('old')
deleting X('old')
Python 2.4.2 (#2, Jan 13 2006, 12:00:38)
Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11)
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-30 10:30
Message:
Logged In: YES
user_id=764593
More precisely, it retains a reference to the module's
__dict__ as its globals. At the moment, I'm not finding
proof that this happens directly in the class, but it does
happen in class methods -- including __del__.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-30 09:53
Message:
Logged In: YES
user_id=835142
Is it true that a class retains reference to the module? The '__module__'
attribute
is a string, not a reference to the module. Maybe you are talking about
something else ...
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-30 09:36
Message:
Logged In: YES
user_id=764593
I suggest changing status to Pending Close - not a bug.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-30 09:34
Message:
Logged In: YES
user_id=764593
Looking at your example code (as best I can guess about
indentation), it looks like
module x <==> class X
module x <==> class A ==> A's instance x ==> class X
module x <==> class B ==> B's instance x ==> class X
So the x instances can't go away until A and B do, which
means at module cleanup. But when the module cleans up, it
may well clean up X before A, so that A.x no longer has an
active class, so that it can't find its __del__ method.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-30 09:22
Message:
Logged In: YES
user_id=764593
The funny interaction with modules is probably that the
module retains a reference to the class (and vice versa),
so the class can't go away until the module does -- and a
module in sys.modules can't go away.
The __del__ methods are not called if the interpreter can't
decide which to call first. For example, if
A.attr=B
B.attr=A
then A and B form a cycle (like the class and its defining
module). If only one has a __del__ method, it gets called,
but if both do, then python doesn't know which to call
first, so it never calls either.
You may have a cycle like
module <==> class <==>instanceA
\ <==>instanceB
So that it can't decide whether to take care of instanceA
or instanceB first.
Or it might be that the __del__ methods actually are being
called, but not until module teardown has begun, so they
don't work right.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 20:08
Message:
Logged In: YES
user_id=835142
I used __del__ just to illustrate the problem. In real life
application, X was a type defined in a C module and I've
noticed that it's tp_dealloc is not called on instances
assigned to class variables.
BTW, what are the circumstances when __del__() methods are
not called for objects that still exist when the interpreter
exits?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 19:18
Message:
Logged In: YES
user_id=849994
There's also this sentence in the __del__ docs:
"""
It is not guaranteed that __del__() methods are called for
objects that still exist when the interpreter exits.
"""
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 18:54
Message:
Logged In: YES
user_id=835142
Yes, I've found that (using gc.get_referrers!), but this
does not explain why A is not cleaned up when the program exits.
Note that if I put class A definition inside a function, it
does get cleaned up. Must be some funny interation between
module and new-styl
[ python-Bugs-1549499 ] bug in classlevel variabels
Bugs item #1549499, was opened at 2006-08-30 20:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549499&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Dybdahl Ahle (thomasda) Assigned to: Nobody/Anonymous (nobody) Summary: bug in classlevel variabels Initial Comment: class A: js = [] def add (self, j): self.js.append(j) def clone (self): c = A() for j in self.js: c.add(j) return c a = A() b = a.clone() b.add(3) print a.js print b.js The above code should print "[]\n[3]", but instead it prints "[3]\n[3]"! It works as expected, if you change "js = []" to "def __init__ (self): self.js = []" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549499&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1549499 ] bug in classlevel variabels
Bugs item #1549499, was opened at 2006-08-30 18:44 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549499&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Thomas Dybdahl Ahle (thomasda) Assigned to: Nobody/Anonymous (nobody) Summary: bug in classlevel variabels Initial Comment: class A: js = [] def add (self, j): self.js.append(j) def clone (self): c = A() for j in self.js: c.add(j) return c a = A() b = a.clone() b.add(3) print a.js print b.js The above code should print "[]\n[3]", but instead it prints "[3]\n[3]"! It works as expected, if you change "js = []" to "def __init__ (self): self.js = []" -- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-30 19:28 Message: Logged In: YES user_id=849994 This is not a bug. The "js" list exists in the class's namespace and exists only once, and if you don't rebind the name, "self.js" always refers to this. Therefore it is shared between instances. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549499&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1549574 ] Pdb parser bug
Bugs item #1549574, was opened at 2006-08-30 16:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549574&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pdb parser bug
Initial Comment:
>>> import pdb
>>> pdb.set_trace()
--Return--
> (1)()->None
(Pdb) p ";;"
*** SyntaxError: SyntaxError('EOL while scanning
single-quoted string', ('', 1, 1, '"'))
*** SyntaxError: EOL while scanning single-quoted
string (, line 1)
Still present in trunk:51513M
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549574&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1549589 ] urlparse return exchanged values
Bugs item #1549589, was opened at 2006-08-30 21:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549589&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Oscar Acena (oscarah)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse return exchanged values
Initial Comment:
The urlparser module is used to split an url into 6
fields, acording to the pertinent spec.
The fields are:
- scheme
- net location
- path
- params
- query
- frag id
The netloc of http://www.google.es/index.html is:
"www.google.es" and the path is "/index.html", ok?
But if you try this:
>>> urlparse("www.google.es")
the answer is:
('', '', 'www.google.es', '', '', '')
instead of
('', 'www.google.es', '', '', '', '')
On the other hand, if you try this:
>>> urlparse("http://www.google.es";)
the answer is:
('http', 'www.google.es', '', '', '', '')
which is correct.
The pytho header is: Python 2.4.4c0 (#2, Jul 30 2006,
15:43:58)
[GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on
linux2
and I downloaded the latest version of that lib
(urlparse.py, at 2006 08 30)
Thats all. Thanks.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549589&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1549589 ] urlparse return exchanged values
Bugs item #1549589, was opened at 2006-08-30 21:19
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549589&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Oscar Acena (oscarah)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse return exchanged values
Initial Comment:
The urlparser module is used to split an url into 6
fields, acording to the pertinent spec.
The fields are:
- scheme
- net location
- path
- params
- query
- frag id
The netloc of http://www.google.es/index.html is:
"www.google.es" and the path is "/index.html", ok?
But if you try this:
>>> urlparse("www.google.es")
the answer is:
('', '', 'www.google.es', '', '', '')
instead of
('', 'www.google.es', '', '', '', '')
On the other hand, if you try this:
>>> urlparse("http://www.google.es";)
the answer is:
('http', 'www.google.es', '', '', '', '')
which is correct.
The pytho header is: Python 2.4.4c0 (#2, Jul 30 2006,
15:43:58)
[GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on
linux2
and I downloaded the latest version of that lib
(urlparse.py, at 2006 08 30)
Thats all. Thanks.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-08-31 05:43
Message:
Logged In: YES
user_id=849994
Duplicate of #754016.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549589&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
