[ python-Bugs-1560327 ] copy() method of dictionaries is not "deep"
Bugs item #1560327, was opened at 2006-09-17 20:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&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: None Priority: 5 Submitted By: daniel hahler (blueyed) Assigned to: Nobody/Anonymous (nobody) Summary: copy() method of dictionaries is not "deep" Initial Comment: Unlike copy.deepcopy() the copy() method of a dictionary does not copy objects in the dict, but seem to use them by reference. I'm not sure, if this is really a bug - but I would have expected it to behave like copy.deepcopy(), according to http://www.python.org/infogami-faq/programming/how-do-i-copy-an-object-in-python/ -- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 07:23 Message: Logged In: YES user_id=849994 The infogami FAQ is "interactive", so if you find the text misleading, please add a comment yourself via the "add comment" link. (You may have to login to infogami to do that.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560179 ] Better/faster implementation of os.path.basename/dirname
Bugs item #1560179, was opened at 2006-09-17 14:55
Message generated for change (Settings changed) made by einsteinmg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&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: None
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Michael Gebetsroither (einsteinmg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better/faster implementation of os.path.basename/dirname
Initial Comment:
hi,
basename/dirname could do better (especially on long
pathnames)
def basename(p):
return split(p)[1]
def dirname(p):
return split(p)[0]
both construct base and dirname and discard the unused
one.
what about that?
def basename(p):
i = p.rfind('/') + 1
return p[i:]
def dirname(p):
i = p.rfind('/') + 1
return p[:i]
greets,
michael
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560161 ] Better/faster implementation of os.path.split
Bugs item #1560161, was opened at 2006-09-17 14:09
Message generated for change (Comment added) made by einsteinmg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560161&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: Invalid
Priority: 5
Submitted By: Michael Gebetsroither (einsteinmg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better/faster implementation of os.path.split
Initial Comment:
hi,
os.path.split is quite bad regarding performance on
long pathnames:
def split(p):
i = p.rfind('/') + 1
head, tail = p[:i], p[i:]
if head and head != '/'*len(head):
head = head.rstrip('/')
return head, tail
especially this: '/'*len(head)
this constructs an unnecessary string sometimes
thousands of chars long.
better would be:
if head and len(head) != head.count('/')
BUT:
what is this 'if head and head != '/'*len(head):' for?
this if is imho useless, because
if head exists and is not all '/' => rstrip '/'
imho better would be:
rstrip '/' from head and if head is empty add a '/'
would be the same effect, because a singel '/' is just
the same as a path as '/'*len(head).
def split(p):
i = p.rfind('/') + 1
head, tail = p[:i], p[i:]
head = head.rstrip('/')
if not head:
head = '/'
return head, tail
such a implementation would be ways faster for long
pathnames.
greets,
michael
--
>Comment By: Michael Gebetsroither (einsteinmg)
Date: 2006-09-18 11:08
Message:
Logged In: YES
user_id=1600082
sorry, haven't benchmarked my solution
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560161&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560161 ] Better/faster implementation of os.path.split
Bugs item #1560161, was opened at 2006-09-17 14:09
Message generated for change (Comment added) made by einsteinmg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560161&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: Michael Gebetsroither (einsteinmg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better/faster implementation of os.path.split
Initial Comment:
hi,
os.path.split is quite bad regarding performance on
long pathnames:
def split(p):
i = p.rfind('/') + 1
head, tail = p[:i], p[i:]
if head and head != '/'*len(head):
head = head.rstrip('/')
return head, tail
especially this: '/'*len(head)
this constructs an unnecessary string sometimes
thousands of chars long.
better would be:
if head and len(head) != head.count('/')
BUT:
what is this 'if head and head != '/'*len(head):' for?
this if is imho useless, because
if head exists and is not all '/' => rstrip '/'
imho better would be:
rstrip '/' from head and if head is empty add a '/'
would be the same effect, because a singel '/' is just
the same as a path as '/'*len(head).
def split(p):
i = p.rfind('/') + 1
head, tail = p[:i], p[i:]
head = head.rstrip('/')
if not head:
head = '/'
return head, tail
such a implementation would be ways faster for long
pathnames.
greets,
michael
--
>Comment By: Michael Gebetsroither (einsteinmg)
Date: 2006-09-18 11:25
Message:
Logged In: YES
user_id=1600082
patch passes all unittests for posixpath.
basename( 310 ) means basename called with path of length
310
sum = 0.0453672409058 min = 4.19616699219e-05
posixpath.basename( 310 )
sum = 0.15571641922 min = 0.000146865844727
posixpath_orig.basename( 310 )
sum = 0.0432558059692 min = 4.10079956055e-05
posixpath.basename( 106 )
sum = 0.128361940384 min = 0.000113964080811
posixpath_orig.basename( 106 )
sum = 0.0422701835632 min = 4.10079956055e-05
posixpath.basename( 21 )
sum = 0.118340730667 min = 0.000111818313599
posixpath_orig.basename( 21 )
so this optimized basename is about 3 times faster as the
old one and gets even faster for longer paths.
sum = 0.124966621399 min = 0.000120878219604
posixpath.dirname( 310 )
sum = 0.156893730164 min = 0.000144958496094
posixpath_orig.dirname( 310 )
sum = 0.0986065864563 min = 9.10758972168e-05
posixpath.dirname( 106 )
sum = 0.117443084717 min = 0.000113964080811
posixpath_orig.dirname( 106 )
sum = 0.0905299186707 min = 8.89301300049e-05
posixpath.dirname( 21 )
sum = 0.118889808655 min = 0.00003057861
posixpath_orig.dirname( 21 )
optimized dirname is also faster but not that much.
but it saves an allocation which could save a few cycles
later.
--
Comment By: Michael Gebetsroither (einsteinmg)
Date: 2006-09-18 11:08
Message:
Logged In: YES
user_id=1600082
sorry, haven't benchmarked my solution
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560161&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560161 ] Better/faster implementation of os.path.split
Bugs item #1560161, was opened at 2006-09-17 14:09
Message generated for change (Comment added) made by einsteinmg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560161&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: Deleted
Resolution: None
Priority: 5
Submitted By: Michael Gebetsroither (einsteinmg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better/faster implementation of os.path.split
Initial Comment:
hi,
os.path.split is quite bad regarding performance on
long pathnames:
def split(p):
i = p.rfind('/') + 1
head, tail = p[:i], p[i:]
if head and head != '/'*len(head):
head = head.rstrip('/')
return head, tail
especially this: '/'*len(head)
this constructs an unnecessary string sometimes
thousands of chars long.
better would be:
if head and len(head) != head.count('/')
BUT:
what is this 'if head and head != '/'*len(head):' for?
this if is imho useless, because
if head exists and is not all '/' => rstrip '/'
imho better would be:
rstrip '/' from head and if head is empty add a '/'
would be the same effect, because a singel '/' is just
the same as a path as '/'*len(head).
def split(p):
i = p.rfind('/') + 1
head, tail = p[:i], p[i:]
head = head.rstrip('/')
if not head:
head = '/'
return head, tail
such a implementation would be ways faster for long
pathnames.
greets,
michael
--
>Comment By: Michael Gebetsroither (einsteinmg)
Date: 2006-09-18 11:29
Message:
Logged In: YES
user_id=1600082
@#&[EMAIL PROTECTED] webformular :(
--
Comment By: Michael Gebetsroither (einsteinmg)
Date: 2006-09-18 11:25
Message:
Logged In: YES
user_id=1600082
patch passes all unittests for posixpath.
basename( 310 ) means basename called with path of length
310
sum = 0.0453672409058 min = 4.19616699219e-05
posixpath.basename( 310 )
sum = 0.15571641922 min = 0.000146865844727
posixpath_orig.basename( 310 )
sum = 0.0432558059692 min = 4.10079956055e-05
posixpath.basename( 106 )
sum = 0.128361940384 min = 0.000113964080811
posixpath_orig.basename( 106 )
sum = 0.0422701835632 min = 4.10079956055e-05
posixpath.basename( 21 )
sum = 0.118340730667 min = 0.000111818313599
posixpath_orig.basename( 21 )
so this optimized basename is about 3 times faster as the
old one and gets even faster for longer paths.
sum = 0.124966621399 min = 0.000120878219604
posixpath.dirname( 310 )
sum = 0.156893730164 min = 0.000144958496094
posixpath_orig.dirname( 310 )
sum = 0.0986065864563 min = 9.10758972168e-05
posixpath.dirname( 106 )
sum = 0.117443084717 min = 0.000113964080811
posixpath_orig.dirname( 106 )
sum = 0.0905299186707 min = 8.89301300049e-05
posixpath.dirname( 21 )
sum = 0.118889808655 min = 0.00003057861
posixpath_orig.dirname( 21 )
optimized dirname is also faster but not that much.
but it saves an allocation which could save a few cycles
later.
--
Comment By: Michael Gebetsroither (einsteinmg)
Date: 2006-09-18 11:08
Message:
Logged In: YES
user_id=1600082
sorry, haven't benchmarked my solution
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560161&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560179 ] Better/faster implementation of os.path.basename/dirname
Bugs item #1560179, was opened at 2006-09-17 14:55
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&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: None
Group: None
>Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Gebetsroither (einsteinmg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better/faster implementation of os.path.basename/dirname
Initial Comment:
hi,
basename/dirname could do better (especially on long
pathnames)
def basename(p):
return split(p)[1]
def dirname(p):
return split(p)[0]
both construct base and dirname and discard the unused
one.
what about that?
def basename(p):
i = p.rfind('/') + 1
return p[i:]
def dirname(p):
i = p.rfind('/') + 1
return p[:i]
greets,
michael
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560179 ] Better/faster implementation of os.path.basename/dirname
Bugs item #1560179, was opened at 2006-09-17 14:55
Message generated for change (Comment added) made by einsteinmg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Gebetsroither (einsteinmg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better/faster implementation of os.path.basename/dirname
Initial Comment:
hi,
basename/dirname could do better (especially on long
pathnames)
def basename(p):
return split(p)[1]
def dirname(p):
return split(p)[0]
both construct base and dirname and discard the unused
one.
what about that?
def basename(p):
i = p.rfind('/') + 1
return p[i:]
def dirname(p):
i = p.rfind('/') + 1
return p[:i]
greets,
michael
--
>Comment By: Michael Gebetsroither (einsteinmg)
Date: 2006-09-18 12:42
Message:
Logged In: YES
user_id=1600082
posixpath with this patch passes all test from
test_posixpath cleanly.
benchmark:
basename( 310 ) means basename called with a 310 chars long
path
sum = 0.0435626506805 min = 4.19616699219e-05
posixpath.basename( 310 )
sum = 0.152147769928 min = 0.00014591217041
posixpath_orig.basename( 310 )
sum = 0.0436658859253 min = 4.07695770264e-05
posixpath.basename( 106 )
sum = 0.117312431335 min = 0.000112771987915
posixpath_orig.basename( 106 )
sum = 0.0426909923553 min = 4.07695770264e-05
posixpath.basename( 21 )
sum = 0.113305330276 min = 0.000110864639282
posixpath_orig.basename( 21 )
sum = 0.12392115593 min = 0.000121831893921
posixpath.dirname( 310 )
sum = 0.152860403061 min = 0.00014591217041
posixpath_orig.dirname( 310 )
sum = 0.0942873954773 min = 9.08374786377e-05
posixpath.dirname( 106 )
sum = 0.114937067032 min = 0.000111818313599
posixpath_orig.dirname( 106 )
sum = 0.0918889045715 min = 8.79764556885e-05
posixpath.dirname( 21 )
sum = 0.114675760269 min = 0.000109910964966
posixpath_orig.dirname( 21 )
greets
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560794 ] strftime('%z') behaving differently with/without time arg.
Bugs item #1560794, was opened at 2006-09-18 16:53
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=1560794&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: Knut Aksel Røysland (knutroy)
Assigned to: Nobody/Anonymous (nobody)
Summary: strftime('%z') behaving differently with/without time arg.
Initial Comment:
According to the documentation, time.strftime will use
time.localtime, when no time tuple is provided as
argument. So, I wonder if it is desired behavior that
%z returns different values in the following two cases:
Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import time
>>> time.strftime('%Y-%m-%dT%H:%M:%S%z')
'2006-09-18T16:12:05+0200'
>>> time.strftime('%Y-%m-%dT%H:%M:%S%z', time.localtime())
'2006-09-18T16:12:05+'
The first behavior is what I am looking for.
I realize that %z is not documented, so maybe it should
be rejected instead of giving surprising results, like
above.
This behavior is observed on different Linux systems
under different versions of Python, e.g. on Ubuntu
Dapper Drake running Python 2.4.3.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560794&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560327 ] copy() method of dictionaries is not "deep"
Bugs item #1560327, was opened at 2006-09-17 22:35 Message generated for change (Comment added) made by blueyed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&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: None Priority: 5 Submitted By: daniel hahler (blueyed) Assigned to: Nobody/Anonymous (nobody) Summary: copy() method of dictionaries is not "deep" Initial Comment: Unlike copy.deepcopy() the copy() method of a dictionary does not copy objects in the dict, but seem to use them by reference. I'm not sure, if this is really a bug - but I would have expected it to behave like copy.deepcopy(), according to http://www.python.org/infogami-faq/programming/how-do-i-copy-an-object-in-python/ -- >Comment By: daniel hahler (blueyed) Date: 2006-09-18 19:26 Message: Logged In: YES user_id=663176 So it's not a bug? Then please change the "Resolution" accordingly. -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 09:23 Message: Logged In: YES user_id=849994 The infogami FAQ is "interactive", so if you find the text misleading, please add a comment yourself via the "add comment" link. (You may have to login to infogami to do that.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560327 ] copy() method of dictionaries is not "deep"
Bugs item #1560327, was opened at 2006-09-17 20:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&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: daniel hahler (blueyed) Assigned to: Nobody/Anonymous (nobody) Summary: copy() method of dictionaries is not "deep" Initial Comment: Unlike copy.deepcopy() the copy() method of a dictionary does not copy objects in the dict, but seem to use them by reference. I'm not sure, if this is really a bug - but I would have expected it to behave like copy.deepcopy(), according to http://www.python.org/infogami-faq/programming/how-do-i-copy-an-object-in-python/ -- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 17:49 Message: Logged In: YES user_id=849994 Sure, if you like... -- Comment By: daniel hahler (blueyed) Date: 2006-09-18 17:26 Message: Logged In: YES user_id=663176 So it's not a bug? Then please change the "Resolution" accordingly. -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 07:23 Message: Logged In: YES user_id=849994 The infogami FAQ is "interactive", so if you find the text misleading, please add a comment yourself via the "add comment" link. (You may have to login to infogami to do that.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560327 ] copy() method of dictionaries is not "deep"
Bugs item #1560327, was opened at 2006-09-17 22:35 Message generated for change (Comment added) made by blueyed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&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: daniel hahler (blueyed) Assigned to: Nobody/Anonymous (nobody) Summary: copy() method of dictionaries is not "deep" Initial Comment: Unlike copy.deepcopy() the copy() method of a dictionary does not copy objects in the dict, but seem to use them by reference. I'm not sure, if this is really a bug - but I would have expected it to behave like copy.deepcopy(), according to http://www.python.org/infogami-faq/programming/how-do-i-copy-an-object-in-python/ -- >Comment By: daniel hahler (blueyed) Date: 2006-09-18 20:39 Message: Logged In: YES user_id=663176 I cannot comment on infogami. It says the following is spam: """ Please note that olddict.copy() does not "deepcopy" the dictionary. So if you have a dictionary of objects, those will still be copied by reference. """ I've tried rephrasing it slightly, to no avail. Can you update the wiki page directly? Thanks. -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 19:49 Message: Logged In: YES user_id=849994 Sure, if you like... -- Comment By: daniel hahler (blueyed) Date: 2006-09-18 19:26 Message: Logged In: YES user_id=663176 So it's not a bug? Then please change the "Resolution" accordingly. -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 09:23 Message: Logged In: YES user_id=849994 The infogami FAQ is "interactive", so if you find the text misleading, please add a comment yourself via the "add comment" link. (You may have to login to infogami to do that.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560327 ] copy() method of dictionaries is not "deep"
Bugs item #1560327, was opened at 2006-09-17 20:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&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: daniel hahler (blueyed) >Assigned to: A.M. Kuchling (akuchling) Summary: copy() method of dictionaries is not "deep" Initial Comment: Unlike copy.deepcopy() the copy() method of a dictionary does not copy objects in the dict, but seem to use them by reference. I'm not sure, if this is really a bug - but I would have expected it to behave like copy.deepcopy(), according to http://www.python.org/infogami-faq/programming/how-do-i-copy-an-object-in-python/ -- >Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 18:53 Message: Logged In: YES user_id=849994 Sorry, I can't since I don't have any privileges there too. Assigning to AMK, perhaps he can do something about it. -- Comment By: daniel hahler (blueyed) Date: 2006-09-18 18:39 Message: Logged In: YES user_id=663176 I cannot comment on infogami. It says the following is spam: """ Please note that olddict.copy() does not "deepcopy" the dictionary. So if you have a dictionary of objects, those will still be copied by reference. """ I've tried rephrasing it slightly, to no avail. Can you update the wiki page directly? Thanks. -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 17:49 Message: Logged In: YES user_id=849994 Sure, if you like... -- Comment By: daniel hahler (blueyed) Date: 2006-09-18 17:26 Message: Logged In: YES user_id=663176 So it's not a bug? Then please change the "Resolution" accordingly. -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-18 07:23 Message: Logged In: YES user_id=849994 The infogami FAQ is "interactive", so if you find the text misleading, please add a comment yourself via the "add comment" link. (You may have to login to infogami to do that.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560327&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560984 ] python 2.5 fails to build with --as-needed
Bugs item #1560984, was opened at 2006-09-18 19:57 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=1560984&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: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Chaza (masterdriverz) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.5 fails to build with --as-needed Initial Comment: Passing -Wl,--as-needed to gcc in LDFLAGS gives an error, patch currently in the works. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560984&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
