[ python-Bugs-1205544 ] urllib has spurious print statement
Bugs item #1205544, was opened at 2005-05-20 10:26 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=1205544&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: Stuart Wray (drcw) Assigned to: Nobody/Anonymous (nobody) Summary: urllib has spurious print statement Initial Comment: In Python 2.4.1, the procedure getproxies_environment() in urllib.py has a spurious print statement on line 1188: print proxies This was presumably used for testing, but not commented out. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205544&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1205568 ] Compile fails on Darwin8 with --with-cxx=g++
Bugs item #1205568, was opened at 2005-05-20 07:05 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=1205568&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Robert M. Zigweid (rzigweid) Assigned to: Nobody/Anonymous (nobody) Summary: Compile fails on Darwin8 with --with-cxx=g++ Initial Comment: As has been previously reported and fixed in some portions of the build process, building on Darwin 8 with gcc-4.0 requires some extra libraries to be passed. When --with-cxx=g++ is specified to configure, and possibly for other flags that make the build process be conscious of C++. Tail of error: gcc -u _PyMac_Error -o python.exe Modules/ccpython.o libpython2.4.a -ldl /usr/bin/ld: Undefined symbols: ___gxx_personality_v0 collect2: ld returned 1 exit status make: *** [python.exe] Error 1 Fix: Add -lSystem and -lSystemStubs for Darwin 8 to the linker where appropriate. I haven't identified all these spots though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1205736 ] wrong location for math lib with --prefix
Bugs item #1205736, was opened at 2005-05-20 17:21 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=1205736&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Richter (thorfdbg) Assigned to: Nobody/Anonymous (nobody) Summary: wrong location for math lib with --prefix Initial Comment: If python2.3 or 2.4 get configured with --prefix, the math libraries (and other binary libraries) are check for in the wrong location. Specifically, the prefix will be will be used twice, giving the wrong path for the binary object. How to reproduce: Configure python with ./configure --prefix=/foo ;or whatever, make make install This will place libraries etc. correctly in /foo/lib/python2.4. Afterwards, setup pythonpath accordingly export PYTHONPATH="/foo/lib/python2.4:/foo/lib/python2.4/site-packages" If you start then python, try >> import math The result will be that pyhon will not find the math module. Debugging with strace reveals that python checks for binary libraries now in /foo/lib/python2.4/lib/python2.4 instead of /foo/lib/python2.4 Setting a softlink in the lib directory works around this and brings python back to working. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205736&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1205568 ] Compile fails on Darwin8 with --with-cxx=g++
Bugs item #1205568, was opened at 2005-05-20 13:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Robert M. Zigweid (rzigweid) Assigned to: Nobody/Anonymous (nobody) Summary: Compile fails on Darwin8 with --with-cxx=g++ Initial Comment: As has been previously reported and fixed in some portions of the build process, building on Darwin 8 with gcc-4.0 requires some extra libraries to be passed. When --with-cxx=g++ is specified to configure, and possibly for other flags that make the build process be conscious of C++. Tail of error: gcc -u _PyMac_Error -o python.exe Modules/ccpython.o libpython2.4.a -ldl /usr/bin/ld: Undefined symbols: ___gxx_personality_v0 collect2: ld returned 1 exit status make: *** [python.exe] Error 1 Fix: Add -lSystem and -lSystemStubs for Darwin 8 to the linker where appropriate. I haven't identified all these spots though. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-05-20 23:13 Message: Logged In: YES user_id=21627 Can you check whether just linking with g++ (instead of linking with gcc, and still not adding -lSystem) also solves the problem? configure is supposed to detect that g++ is needed for linking; if linking with g++ solves the problem, then configure.in must be enhanced to properly auto-detect this case. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205568&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-16 01:43
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: a bunch of infinite C recursions
Initial Comment:
There is a general way to cause unchecked infinite recursion at the C level,
and I have no clue at the moment how it could be reasonably fixed. The idea is
to define special __xxx__ methods in such a way that no Python code is actually
called before they invoke more special methods (e.g. themselves).
>>> class A: pass
>>> A.__mul__=new.instancemethod(operator.mul,None,A)
>>> A()*2
Segmentation fault
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-05-20 23:22
Message:
Logged In: YES
user_id=21627
Wouldn't adding Py_EnterRecursiveCall into many places solve
the problem?
--
Comment By: Armin Rigo (arigo)
Date: 2005-05-19 17:05
Message:
Logged In: YES
user_id=4771
This is not about the new module. The same example can be written as:
import types
class A: pass
A.__mul__ = types.MethodType(operator.mul, None, A)
If this still looks essentially like an indirect way of using the new module,
here is another example:
class A(str): __get__ = getattr
a = A('a')
A.a = a
a.a
Or, as I just found out, new-style classes are again vulnerable to the older
example based __call__, which was fixed for old-style classes:
class A(object): pass
A.__call__ = A()
A()()
I'm not denying that these examples look convoluted :-)
My point here is that we can basically build a lot of examples based only on
core (if not necessarily widely understood) language features. It appears to
go against the basic hope that CPython cannot be crashed as long as you don't
use features explicitely marked as dangerous.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-19 04:02
Message:
Logged In: YES
user_id=593130
On Windows, this caused the interactive window to just
disappear.so I suspect something similar occurred.
New is a known dangerous, use at your own risk, implementation
specific module whose use, like byte code hacking, is outside
the language proper. Both bypass normal object creation syntax
and its checks and both can create invalid objects. A hold-your-
hand inplementation would not give such access to internals.
Lib Ref 3.28 says "This module provides a low-level interface to
the interpreter, so care must be exercised when using this
module. It is possible to supply non-sensical arguments which
crash the interpreter when the object is used." Should more or
different be said?
If not, I suspect this should be closed as 'won't fix', as in 'won't
remove the inherently dangerous new module'.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1200287 ] Windows msi installer fails on virtual drives
Bugs item #1200287, was opened at 2005-05-12 02:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200287&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: Installation >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: bartgrantham (bartgrantham) Assigned to: Nobody/Anonymous (nobody) Summary: Windows msi installer fails on virtual drives Initial Comment: The MSI installer for 2.4.1 failed to install from a virtual drive under windows (ie. a drive created with subst). It would error out without an error code, immediately after package selection and before "thinking...". Not sure if this also applies to network mapped drives. Moving installer to genuine C: drive and running from there fixed the problem. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-05-20 23:23 Message: Logged In: YES user_id=21627 It is not a bug in Python, but an MSI limitation; closing as third-party. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 03:03 Message: Logged In: YES user_id=593130 This is almost certainly not a Python bug. See http://python.org/sf/1199947 Please close unless you see a particular bug with Python. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200287&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1199947 ] Python 2.4.1 Installer ended prematurely
Bugs item #1199947, was opened at 2005-05-11 18:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199947&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: Installation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4.1 Installer ended prematurely Initial Comment: Similar symptom to bug 105470 http://sourceforge.net/tracker/index.php? func=detail&aid=1085208&group_id=5470&atid=105470 Running python-2.4.1.msi with all default setting. It ends quickly with a dialogbox titled "Python 2.4.1 Installer ended prematurely". Same problem running the 2.4 msi. Machine information: Windows XP Professional V2002 SP2 Dell Latitude D600 640MB RAM Symantec Antivirus 9.0.1.1000 (disable it does not help) cscript.exe version 5.6.0.8825 (upgraded from 8820?) The workaround mentioned in 105470 does not help. Running x.vbs gives me 0. Doing regsvr32 c:\windows\system32\scrrun.dll makes no difference. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-05-20 23:25 Message: Logged In: YES user_id=21627 Closing the problem as fixed. -- Comment By: Wai Yip Tung (tungwaiyip) Date: 2005-05-16 22:32 Message: Logged In: YES user_id=561546 Problem solved: I copied the msi file to the root directory (e.g. c:\) and launch from there. it works prefectly. I found that not only Python installer gave me problem, any msi installer gave me problem on this machine. Then I found the clue from Ultramon's FAQ: http://www.realtimesoft.com/ultramon/support.asp#2 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199947&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1199808 ] installation problem with python 2.4.1 on Win2k system
Bugs item #1199808, was opened at 2005-05-11 14:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&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: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: mmkobayashi (mmkobayashi) Assigned to: Nobody/Anonymous (nobody) Summary: installation problem with python 2.4.1 on Win2k system Initial Comment: After several attempts to install python2.4.1 on a win2k systems with doing all windows updates, we have been unable to install python2.4.1 on this system. We have attached an error logfile. The main thing that happens is that the install proceeds as normal but at some point the install decides that something has gone wrong and uninstalls itself. Any help in this matter would be greatly appreciated. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-05-20 23:35 Message: Logged In: YES user_id=21627 The log file appears to be manually truncated. Can you please provide the full log file? Are you by any chance running the MSI file from a SUBSTed drive? -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 03:01 Message: Logged In: YES user_id=593130 You might also check out http://python.org/sf/1199947 -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 02:48 Message: Logged In: YES user_id=593130 Help questions should better be directed to comp.lang.python == python mailing list == gmane.comp.python.general. The answers you get should help determine whether there is a bug in the install file distributed by PSF that should be reported here. Given that the install appeared to go ok until it tried to remove the existing files, I wonder whether there is a process running in the background that is using the existing install. That issue has been discussed on the python group recently. -- Comment By: mmkobayashi (mmkobayashi) Date: 2005-05-12 07:53 Message: Logged In: YES user_id=1273313 add file -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199808&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1200804 ] enhancing os.chown functionality
Feature Requests item #1200804, was opened at 2005-05-12 18:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1200804&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: Extension Modules Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: gyrof (gyrof) Assigned to: Nobody/Anonymous (nobody) Summary: enhancing os.chown functionality Initial Comment: Hi, I don't think it is currently possible (with os.chown or any other Python library function) to change the groupId of a file without specifying the userId (like posix 'chgrp' does), or to change the userId without specifying the groupId. I would suggest adding the option of having os.chown accept None as either the userId or groupId, and having the function change only the 'non-None' portion of the file ownership. Thanks for your consideration. -g -- >Comment By: Martin v. Löwis (loewis) Date: 2005-05-20 23:41 Message: Logged In: YES user_id=21627 Jeff already provided the right analysis: It *is* currently possibly with os.chown to only change the groupid without specifying the userid: just pass -1 as the userid. The requested feature is already there, so I'm rejecting this request. -- Comment By: Jeff Epler (jepler) Date: 2005-05-19 00:49 Message: Logged In: YES user_id=2772 the posix (os) module is intended as a thin wrapper around operating system services. The chown(2) syscall requires that owner and group both be specified. Possibly an enhanced chownonly/chgrp would find a home in the 'shutil' module. Possibly translating a parameter of None into -1 (which means 'no change') would be accepted as a patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1200804&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1157901 ] xml.dom.minidom.Node.removeChild() doesn't remove
Bugs item #1157901, was opened at 2005-03-06 22:17 Message generated for change (Comment added) made by mkempka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157901&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: XML Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Matthias Kempka (mkempka) Assigned to: Nobody/Anonymous (nobody) Summary: xml.dom.minidom.Node.removeChild() doesn't remove Initial Comment: There seems to be a constellation where xml.dom.minidom.Node.removeChild() doesn't remove childs properly. I found this bug in 2.3.4 and it is still in: Python 2.3.5 (#2, Feb 9 2005, 00:38:15) [GCC 3.3.5 (Debian 1:3.3.5-8)] on linux2 I attached 3 files, the dombug.py demonstrates the problem: First, I iterate over all children of a specific element, check their tag name and remove them using removeChild() and then child.unlink(). After the elements are removed I iterate again, do the same check for a tag and find there are still elements in there. That is, there are still elements in there when I parse the file errorintroducer.xml. When I parse the file errorfree.xml the elements are all removed. The difference between the xml files is the carriage return after each closing tag. Since to my knowledge both xml files are well-formed I would expect in both cases that all elements are removed. -- >Comment By: Matthias Kempka (mkempka) Date: 2005-05-20 23:44 Message: Logged In: YES user_id=736381 well then, invalid. -- Comment By: Andrew Clover (bobince) Date: 2005-03-11 09:25 Message: Logged In: YES user_id=311085 Bug should be marked INVALID. childNodes lists are 'live'. You are iterating over a list you are destroying at the same time. The code is equivalent to the more obviously broken: foo= [1, 2, 3, 4] i= 0 while i>> [2, 4] The 'working' example only works because it has extra whitespace nodes in, so when you delete child number i, the child i+1 that is skipped over is a Text node containing only whitespace. BTW, there's a separate bug tracker for the PyXML project from which minidom is taken. You may get better results by submitting there (and discussing on the XML-SIG list). -- Comment By: Matthias Kempka (mkempka) Date: 2005-03-06 22:24 Message: Logged In: YES user_id=736381 so.. this form posts the error report with uploading files...interesting... Anyway, the output I get when running the program with errorintroducer.xml is: > python dombug.py found element 1 .. removed found element 3 .. removed found element 5 .. removed ---everything removed from timerList[0]--- found Element2 found Element4 found Element6 imho it should be, as it is with errorfree.xml: found element 1 .. removed found element 2 .. removed found element 3 .. removed found element 4 .. removed found element 5 .. removed found element 6 .. removed ---everything removed from timerList[0]--- -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157901&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 23:43
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: a bunch of infinite C recursions
Initial Comment:
There is a general way to cause unchecked infinite recursion at the C level,
and I have no clue at the moment how it could be reasonably fixed. The idea is
to define special __xxx__ methods in such a way that no Python code is actually
called before they invoke more special methods (e.g. themselves).
>>> class A: pass
>>> A.__mul__=new.instancemethod(operator.mul,None,A)
>>> A()*2
Segmentation fault
--
>Comment By: Armin Rigo (arigo)
Date: 2005-05-20 21:46
Message:
Logged In: YES
user_id=4771
Yes, but I'm concerned that we would need to add it really really many places,
and probably forget some even then. E.g. I just thought about:
lst = [apply]
lst.append(lst)
apply(*lst)
It seems a bit hopeless, honestly...
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-05-20 21:22
Message:
Logged In: YES
user_id=21627
Wouldn't adding Py_EnterRecursiveCall into many places solve
the problem?
--
Comment By: Armin Rigo (arigo)
Date: 2005-05-19 15:05
Message:
Logged In: YES
user_id=4771
This is not about the new module. The same example can be written as:
import types
class A: pass
A.__mul__ = types.MethodType(operator.mul, None, A)
If this still looks essentially like an indirect way of using the new module,
here is another example:
class A(str): __get__ = getattr
a = A('a')
A.a = a
a.a
Or, as I just found out, new-style classes are again vulnerable to the older
example based __call__, which was fixed for old-style classes:
class A(object): pass
A.__call__ = A()
A()()
I'm not denying that these examples look convoluted :-)
My point here is that we can basically build a lot of examples based only on
core (if not necessarily widely understood) language features. It appears to
go against the basic hope that CPython cannot be crashed as long as you don't
use features explicitely marked as dangerous.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-19 02:02
Message:
Logged In: YES
user_id=593130
On Windows, this caused the interactive window to just
disappear.so I suspect something similar occurred.
New is a known dangerous, use at your own risk, implementation
specific module whose use, like byte code hacking, is outside
the language proper. Both bypass normal object creation syntax
and its checks and both can create invalid objects. A hold-your-
hand inplementation would not give such access to internals.
Lib Ref 3.28 says "This module provides a low-level interface to
the interpreter, so care must be exercised when using this
module. It is possible to supply non-sensical arguments which
crash the interpreter when the object is used." Should more or
different be said?
If not, I suspect this should be closed as 'won't fix', as in 'won't
remove the inherently dangerous new module'.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1184678 ] "replace" function should accept lists.
Feature Requests item #1184678, was opened at 2005-04-17 18:05
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1184678&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: Closed
Resolution: Rejected
Priority: 5
Submitted By: Poromenos (poromenos)
Assigned to: Nobody/Anonymous (nobody)
Summary: "replace" function should accept lists.
Initial Comment:
It would be nice if the "replace" function accepted lists/
tuples and replaced each item in the "old" list with the
corresponding item in the "new" list.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-05-20 23:48
Message:
Logged In: YES
user_id=21627
I'm rejecting this request, noticing that even the
*specification* of the requested feature is tricky:
Would
"foobarfoo".replace([("foo","baz"), ("barf", "")]
produce
"bazbarbaz"
or
"bazfoo"
IOW, would it first replace all occurrences of the first
pair, then all occurrences of the second pair, or would it
iterate over the list, replacing everything it can replace,
and then start all over until nothing needs to be done?
In the face of doubt, refuse the temptation to guess.
--
Comment By: Poromenos (poromenos)
Date: 2005-05-01 11:55
Message:
Logged In: YES
user_id=267121
Ah, okay.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-30 14:30
Message:
Logged In: YES
user_id=80475
Sorry, am not going to gum up the API for this. It doesn't
come up much and when it does it is an easy problem.
Each additional option on a function makes it harder to
learn, use, and remember. Likewise, it complicates maintenance.
Also, this one has its own complexities that make it worth
avoiding (examples can be contrived when the for-loop
version produces a different result than replacing each
match as found).
A good implementation would take time. It would involve
regexps and have to be done for unicode objects.
--
Comment By: Poromenos (poromenos)
Date: 2005-04-30 11:48
Message:
Logged In: YES
user_id=267121
That is true, the alternative loop is quite usable, but the API
change would be backwards-compatible, and the
implementation is not very difficult... I just see this as a nice
feature of replace, it's not really necessary if it'll break other
stuff.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-29 16:10
Message:
Logged In: YES
user_id=80475
Given the multiple alternative input matches, this is a job
for regular expressions. See the string.substitute() source
code for an approach to making the transformation you outlined.
I do not think multi-replace is sufficiently common to
warrant a change to the API. If needed and if the regexp
solution is too hard, then a regular for-loop is a
reasonable alternative:
for old, new in zip(oldlist, newlist):
s = s.replace(old, new)
--
Comment By: Poromenos (poromenos)
Date: 2005-04-29 15:03
Message:
Logged In: YES
user_id=267121
There was an oversight on my part... Translate can only be
used to change individual characters, what I am proposing
could replace strings of multiple characters, essentially
concatenating multiple replace()s in one:
>>> "h.w".replace(["h", ".", "w"], ["Hello", " ", "World!"])
'Hello, World!'
--
Comment By: Poromenos (poromenos)
Date: 2005-04-19 00:23
Message:
Logged In: YES
user_id=267121
Ah, I did not know that... The docs are a bit complicated on .
translate, but since it can do that, yes, it would be unwise to
implement my suggestion.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-19 00:20
Message:
Logged In: YES
user_id=80475
I'm -1 on complicating str.replace()'s API for functionality
that substantially duplicates that offered by str.translate():
>>> "Hello world".translate(string.maketrans('ed', 'ae'))
'Hallo worle'
--
Comment By: Poromenos (poromenos)
Date: 2005-04-18 23:15
Message:
Logged In: YES
user_id=267121
Hmm, actually I was requesting that string.replace() accepted
lists of substitutions, like so:
>>> "Hello world".replace(["e", "d"], ["a", "e"])
'Hallo worle'
But your suggestion would also be very useful.
[ python-Feature Requests-1184678 ] "replace" function should accept lists.
Feature Requests item #1184678, was opened at 2005-04-17 19:05
Message generated for change (Comment added) made by poromenos
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1184678&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: Closed
Resolution: Rejected
Priority: 5
Submitted By: Poromenos (poromenos)
Assigned to: Nobody/Anonymous (nobody)
Summary: "replace" function should accept lists.
Initial Comment:
It would be nice if the "replace" function accepted lists/
tuples and replaced each item in the "old" list with the
corresponding item in the "new" list.
--
>Comment By: Poromenos (poromenos)
Date: 2005-05-21 00:52
Message:
Logged In: YES
user_id=267121
Actually it would accept two lists, and replace item n in the
first list with item n in the second list, in that order (so that
you can condense multiple replace lines into one), but this
feature is not that important anyway.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-05-21 00:48
Message:
Logged In: YES
user_id=21627
I'm rejecting this request, noticing that even the
*specification* of the requested feature is tricky:
Would
"foobarfoo".replace([("foo","baz"), ("barf", "")]
produce
"bazbarbaz"
or
"bazfoo"
IOW, would it first replace all occurrences of the first
pair, then all occurrences of the second pair, or would it
iterate over the list, replacing everything it can replace,
and then start all over until nothing needs to be done?
In the face of doubt, refuse the temptation to guess.
--
Comment By: Poromenos (poromenos)
Date: 2005-05-01 12:55
Message:
Logged In: YES
user_id=267121
Ah, okay.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-30 15:30
Message:
Logged In: YES
user_id=80475
Sorry, am not going to gum up the API for this. It doesn't
come up much and when it does it is an easy problem.
Each additional option on a function makes it harder to
learn, use, and remember. Likewise, it complicates maintenance.
Also, this one has its own complexities that make it worth
avoiding (examples can be contrived when the for-loop
version produces a different result than replacing each
match as found).
A good implementation would take time. It would involve
regexps and have to be done for unicode objects.
--
Comment By: Poromenos (poromenos)
Date: 2005-04-30 12:48
Message:
Logged In: YES
user_id=267121
That is true, the alternative loop is quite usable, but the API
change would be backwards-compatible, and the
implementation is not very difficult... I just see this as a nice
feature of replace, it's not really necessary if it'll break other
stuff.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-29 17:10
Message:
Logged In: YES
user_id=80475
Given the multiple alternative input matches, this is a job
for regular expressions. See the string.substitute() source
code for an approach to making the transformation you outlined.
I do not think multi-replace is sufficiently common to
warrant a change to the API. If needed and if the regexp
solution is too hard, then a regular for-loop is a
reasonable alternative:
for old, new in zip(oldlist, newlist):
s = s.replace(old, new)
--
Comment By: Poromenos (poromenos)
Date: 2005-04-29 16:03
Message:
Logged In: YES
user_id=267121
There was an oversight on my part... Translate can only be
used to change individual characters, what I am proposing
could replace strings of multiple characters, essentially
concatenating multiple replace()s in one:
>>> "h.w".replace(["h", ".", "w"], ["Hello", " ", "World!"])
'Hello, World!'
--
Comment By: Poromenos (poromenos)
Date: 2005-04-19 01:23
Message:
Logged In: YES
user_id=267121
Ah, I did not know that... The docs are a bit complicated on .
translate, but since it can do that, yes, it would be unwise to
implement my suggestion.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-19 01:20
Message:
Logged In: YES
user_id=80475
I'm -1 on complicating str.replace()'s API for functionality
that substantially duplicates that offered by str.translate():
>>> "Hello world".translate(string.maketrans('ed', 'ae'))
'Hallo worle'
-
