[ python-Bugs-1143895 ] inspect.getsource() breakage in 2.4
Bugs item #1143895, was opened at 2005-02-18 17:26 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143895&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Armin Rigo (arigo) >Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getsource() breakage in 2.4 Initial Comment: In a real-life case, inspect.getsource() used to produce the correct result on 2.3 but no longer does on 2.4: def somefunc(x, y): # comments ...body... With 2.4 (and 2.5 CVS) the body is completely skipped because the first line doesn't end with a colon. In my opinion that's a critical problem for any code relying on getsource(), even though such code can be considered as relying on a large pile of fragile hacks in the first place... Attached is a patch for test_inspect.py, showing the problem (also includes a different, much more convoluted bug example). It seems that looking for and around ':' in the first line isn't such a good idea; relying more fully on the tokenizer would probably be a better solution. Assigned to jlgijsbers, as the author of the changes that broke this (Dec 12th, 2004). (No blame intended, the change was meant to fix a different bug, and it did so.) -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-03-09 12:26 Message: Logged In: YES user_id=469548 Well, I'm sorry, but I can't make the time after all. I've asked the author of the original patch to take a look at this patch. Note that this code isn't yet in a 2.4 release, so we could also back this out before 2.4.1. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-02-18 20:11 Message: Logged In: YES user_id=469548 Right now I don't have time to look into this bug deeply, but I will do so this week. I'll note that the convoluted example doesn't seem to be working under 2.3, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143895&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1143895 ] inspect.getsource() breakage in 2.4
Bugs item #1143895, was opened at 2005-02-18 17:26 Message generated for change (Comment added) made by percivall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143895&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getsource() breakage in 2.4 Initial Comment: In a real-life case, inspect.getsource() used to produce the correct result on 2.3 but no longer does on 2.4: def somefunc(x, y): # comments ...body... With 2.4 (and 2.5 CVS) the body is completely skipped because the first line doesn't end with a colon. In my opinion that's a critical problem for any code relying on getsource(), even though such code can be considered as relying on a large pile of fragile hacks in the first place... Attached is a patch for test_inspect.py, showing the problem (also includes a different, much more convoluted bug example). It seems that looking for and around ':' in the first line isn't such a good idea; relying more fully on the tokenizer would probably be a better solution. Assigned to jlgijsbers, as the author of the changes that broke this (Dec 12th, 2004). (No blame intended, the change was meant to fix a different bug, and it did so.) -- Comment By: Simon Percivall (percivall) Date: 2005-03-09 16:40 Message: Logged In: YES user_id=329382 Patch http://www.python.org/sf/1159931 fixes this problem. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-03-09 12:26 Message: Logged In: YES user_id=469548 Well, I'm sorry, but I can't make the time after all. I've asked the author of the original patch to take a look at this patch. Note that this code isn't yet in a 2.4 release, so we could also back this out before 2.4.1. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-02-18 20:11 Message: Logged In: YES user_id=469548 Right now I don't have time to look into this bug deeply, but I will do so this week. I'll note that the convoluted example doesn't seem to be working under 2.3, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1143895&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-834452 ] python and lithuanian locales
Bugs item #834452, was opened at 2003-11-02 08:41 Message generated for change (Comment added) made by sorlov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834452&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mantas (mantaz) Assigned to: Nobody/Anonymous (nobody) Summary: python and lithuanian locales Initial Comment: python's locale.py file contains only one lithuanian locale Iso 8859-4 which is obsolete. Now almost all uses iso 8859-13. Lithuanian locale is called lt, and i think it must be named lt_lt. -- Comment By: Serge Orlov (sorlov) Date: 2005-03-09 19:56 Message: Logged In: YES user_id=1235914 The fix is in Python 2.5. For 2.4 and 2.3 it is discussed in patch 1118341 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834452&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1160187 ] Setup file needs entries for collections, itertools, strop
Bugs item #1160187, was opened at 2005-03-09 15:37 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=1160187&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Niraj Bajpai (nbajpai) Assigned to: Nobody/Anonymous (nobody) Summary: Setup file needs entries for collections, itertools, strop Initial Comment: For static builds in python2.4, Setup file under Modules directory needs entries for collections, itertools, strop and _random modules. I have made following entries in my Setup file for static python build (which can work in self served / isolated environments) _random _randommodule.c collections collectionsmodule.c itertools itertoolsmodule.c strop stropmodule.c Thanks, Niraj -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160187&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1158005 ] unixccompiler.py should deal with env in linker
Bugs item #1158005, was opened at 2005-03-06 16:42 Message generated for change (Comment added) made by edwardmoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Edward Moy (edwardmoy) Assigned to: Nobody/Anonymous (nobody) Summary: unixccompiler.py should deal with env in linker Initial Comment: When the linker command begins with env, plus some environment settings, and when the target is c++, the modified linker command should place the c++ command in the proper place, which is not the first element of the linker array. The following seems to be fix the problem: --- unixccompiler.py.orig 2004-08-29 09:45:13.0 -0700 +++ unixccompiler.py2005-03-06 16:36:05.0 -0800 @@ -172,7 +172,12 @@ else: linker = self.linker_so[:] if target_lang == "c++" and self.compiler_cxx: -linker[0] = self.compiler_cxx[0] +i = 0 +if os.path.basename(linker[0]) == "env": +i = 1 +while '=' in linker[i]: +i = i + 1 +linker[i] = self.compiler_cxx[0] self.spawn(linker + ld_args) except DistutilsExecError, msg: raise LinkError, msg -- >Comment By: Edward Moy (edwardmoy) Date: 2005-03-09 13:42 Message: Logged In: YES user_id=1233904 I was trying to build wxPython on Mac OS X. Without the change, it would compile all .c files, then when it tried to link, it would execute a command that looked like: g++ MACOSX_DEPLOYMENT_TARGET=10.3 c++ ... and fail. This is because it overwrote "env" with "g++". It needs to skip the env and its arguments, and replace (in this case) the c++. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-08 07:08 Message: Logged In: YES user_id=21627 Can you please give a specific example of what you did, what you expected to happen, and what happened instead (precise error messages, etc)? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1158005 ] unixccompiler.py should deal with env in linker
Bugs item #1158005, was opened at 2005-03-07 01:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Edward Moy (edwardmoy) Assigned to: Nobody/Anonymous (nobody) Summary: unixccompiler.py should deal with env in linker Initial Comment: When the linker command begins with env, plus some environment settings, and when the target is c++, the modified linker command should place the c++ command in the proper place, which is not the first element of the linker array. The following seems to be fix the problem: --- unixccompiler.py.orig 2004-08-29 09:45:13.0 -0700 +++ unixccompiler.py2005-03-06 16:36:05.0 -0800 @@ -172,7 +172,12 @@ else: linker = self.linker_so[:] if target_lang == "c++" and self.compiler_cxx: -linker[0] = self.compiler_cxx[0] +i = 0 +if os.path.basename(linker[0]) == "env": +i = 1 +while '=' in linker[i]: +i = i + 1 +linker[i] = self.compiler_cxx[0] self.spawn(linker + ld_args) except DistutilsExecError, msg: raise LinkError, msg -- >Comment By: Martin v. Löwis (loewis) Date: 2005-03-10 00:03 Message: Logged In: YES user_id=21627 Hmm. Where does the "env MACOSX_DEPLOYMENT_TARGET" come from? I cannot find it in the Python build process or distutils. So if it is in the wxPython setup.py, it sure must be a bug in that setup.py, no? -- Comment By: Edward Moy (edwardmoy) Date: 2005-03-09 22:42 Message: Logged In: YES user_id=1233904 I was trying to build wxPython on Mac OS X. Without the change, it would compile all .c files, then when it tried to link, it would execute a command that looked like: g++ MACOSX_DEPLOYMENT_TARGET=10.3 c++ ... and fail. This is because it overwrote "env" with "g++". It needs to skip the env and its arguments, and replace (in this case) the c++. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-08 16:08 Message: Logged In: YES user_id=21627 Can you please give a specific example of what you did, what you expected to happen, and what happened instead (precise error messages, etc)? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1158005 ] unixccompiler.py should deal with env in linker
Bugs item #1158005, was opened at 2005-03-06 16:42 Message generated for change (Comment added) made by edwardmoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Edward Moy (edwardmoy) Assigned to: Nobody/Anonymous (nobody) Summary: unixccompiler.py should deal with env in linker Initial Comment: When the linker command begins with env, plus some environment settings, and when the target is c++, the modified linker command should place the c++ command in the proper place, which is not the first element of the linker array. The following seems to be fix the problem: --- unixccompiler.py.orig 2004-08-29 09:45:13.0 -0700 +++ unixccompiler.py2005-03-06 16:36:05.0 -0800 @@ -172,7 +172,12 @@ else: linker = self.linker_so[:] if target_lang == "c++" and self.compiler_cxx: -linker[0] = self.compiler_cxx[0] +i = 0 +if os.path.basename(linker[0]) == "env": +i = 1 +while '=' in linker[i]: +i = i + 1 +linker[i] = self.compiler_cxx[0] self.spawn(linker + ld_args) except DistutilsExecError, msg: raise LinkError, msg -- >Comment By: Edward Moy (edwardmoy) Date: 2005-03-09 15:22 Message: Logged In: YES user_id=1233904 I don't know the internal of python all that well, but I know that python (and perl as well) use "env MACOSX_DEPLOYMENT_TARGET=10.3 cc" as the link command, because this environment variable is required to enable the dynamic lookup symbol resolution feature in the linker (used with two-level namespaces). This is all rather Mac OS X specific, but I'm assuming since the python distributed with Mac OS X does this, that wxWidgets is picking that up and doing the same thing, as it should. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-09 15:03 Message: Logged In: YES user_id=21627 Hmm. Where does the "env MACOSX_DEPLOYMENT_TARGET" come from? I cannot find it in the Python build process or distutils. So if it is in the wxPython setup.py, it sure must be a bug in that setup.py, no? -- Comment By: Edward Moy (edwardmoy) Date: 2005-03-09 13:42 Message: Logged In: YES user_id=1233904 I was trying to build wxPython on Mac OS X. Without the change, it would compile all .c files, then when it tried to link, it would execute a command that looked like: g++ MACOSX_DEPLOYMENT_TARGET=10.3 c++ ... and fail. This is because it overwrote "env" with "g++". It needs to skip the env and its arguments, and replace (in this case) the c++. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-08 07:08 Message: Logged In: YES user_id=21627 Can you please give a specific example of what you did, what you expected to happen, and what happened instead (precise error messages, etc)? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1160187 ] Setup file needs entries for collections, itertools, strop
Bugs item #1160187, was opened at 2005-03-09 15:37 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160187&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Niraj Bajpai (nbajpai) Assigned to: Nobody/Anonymous (nobody) Summary: Setup file needs entries for collections, itertools, strop Initial Comment: For static builds in python2.4, Setup file under Modules directory needs entries for collections, itertools, strop and _random modules. I have made following entries in my Setup file for static python build (which can work in self served / isolated environments) _random _randommodule.c collections collectionsmodule.c itertools itertoolsmodule.c strop stropmodule.c Thanks, Niraj -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-09 18:48 Message: Logged In: YES user_id=80475 Fixed. See Modules/Setup.dist 1.50 and 1.48.2.1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160187&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1160187 ] Setup file needs entries for collections, itertools, strop
Bugs item #1160187, was opened at 2005-03-09 15:37 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160187&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Niraj Bajpai (nbajpai) Assigned to: Nobody/Anonymous (nobody) Summary: Setup file needs entries for collections, itertools, strop Initial Comment: For static builds in python2.4, Setup file under Modules directory needs entries for collections, itertools, strop and _random modules. I have made following entries in my Setup file for static python build (which can work in self served / isolated environments) _random _randommodule.c collections collectionsmodule.c itertools itertoolsmodule.c strop stropmodule.c Thanks, Niraj -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-09 18:48 Message: Logged In: YES user_id=80475 Fixed. See Modules/Setup.dist 1.50 and 1.48.2.1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160187&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1158005 ] unixccompiler.py should deal with env in linker
Bugs item #1158005, was opened at 2005-03-07 01:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Edward Moy (edwardmoy) Assigned to: Nobody/Anonymous (nobody) Summary: unixccompiler.py should deal with env in linker Initial Comment: When the linker command begins with env, plus some environment settings, and when the target is c++, the modified linker command should place the c++ command in the proper place, which is not the first element of the linker array. The following seems to be fix the problem: --- unixccompiler.py.orig 2004-08-29 09:45:13.0 -0700 +++ unixccompiler.py2005-03-06 16:36:05.0 -0800 @@ -172,7 +172,12 @@ else: linker = self.linker_so[:] if target_lang == "c++" and self.compiler_cxx: -linker[0] = self.compiler_cxx[0] +i = 0 +if os.path.basename(linker[0]) == "env": +i = 1 +while '=' in linker[i]: +i = i + 1 +linker[i] = self.compiler_cxx[0] self.spawn(linker + ld_args) except DistutilsExecError, msg: raise LinkError, msg -- >Comment By: Martin v. Löwis (loewis) Date: 2005-03-10 00:58 Message: Logged In: YES user_id=21627 Can you find out where it does pick it up *from*, please? Search the distutils and config directories of Python, and the wxWindows directories for clues; also print your env. -- Comment By: Edward Moy (edwardmoy) Date: 2005-03-10 00:22 Message: Logged In: YES user_id=1233904 I don't know the internal of python all that well, but I know that python (and perl as well) use "env MACOSX_DEPLOYMENT_TARGET=10.3 cc" as the link command, because this environment variable is required to enable the dynamic lookup symbol resolution feature in the linker (used with two-level namespaces). This is all rather Mac OS X specific, but I'm assuming since the python distributed with Mac OS X does this, that wxWidgets is picking that up and doing the same thing, as it should. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-10 00:03 Message: Logged In: YES user_id=21627 Hmm. Where does the "env MACOSX_DEPLOYMENT_TARGET" come from? I cannot find it in the Python build process or distutils. So if it is in the wxPython setup.py, it sure must be a bug in that setup.py, no? -- Comment By: Edward Moy (edwardmoy) Date: 2005-03-09 22:42 Message: Logged In: YES user_id=1233904 I was trying to build wxPython on Mac OS X. Without the change, it would compile all .c files, then when it tried to link, it would execute a command that looked like: g++ MACOSX_DEPLOYMENT_TARGET=10.3 c++ ... and fail. This is because it overwrote "env" with "g++". It needs to skip the env and its arguments, and replace (in this case) the c++. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-08 16:08 Message: Logged In: YES user_id=21627 Can you please give a specific example of what you did, what you expected to happen, and what happened instead (precise error messages, etc)? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1160328 ] urllib2 post error when using httpproxy
Bugs item #1160328, was opened at 2005-03-10 01:37
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=1160328&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: small tiger (xhchen111)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 post error when using httpproxy
Initial Comment:
==
program
==
# -*- coding: gbk -*-
import httplib, urllib, urllib2#, cookielib
proxy = urllib2.ProxyHandler
({'http':'http://pic:[EMAIL PROTECTED]:8080'})
opener = urllib2.build_opener(proxy)
urllib2.install_opener(opener)
f = urllib2.urlopen
("http://192.168.10.177:8080/price/login.do?
method=list")
print f.read()
postdata = urllib.urlencode
({'userId':'admin', 'password':'admin'})
request = urllib2.Request
('http://192.168.10.177:8080/price/login.do?
method=login')
response = urllib2.urlopen(request, postdata)
print response.read()
out put
E:\jt>c:\python24\python t.py
Traceback (most recent call last):
File "t.py", line 13, in ?
response = urllib2.urlopen(request, postdata)
File "c:\python24\lib\urllib2.py", line 130, in urlopen
return _opener.open(url, data)
File "c:\python24\lib\urllib2.py", line 358, in open
response = self._open(req, data)
File "c:\python24\lib\urllib2.py", line 376, in _open
'_open', req)
File "c:\python24\lib\urllib2.py", line 337, in _call_chain
result = func(*args)
File "c:\python24\lib\urllib2.py", line 1021, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "c:\python24\lib\urllib2.py", line 996, in do_open
raise URLError(err)
urllib2.URLError:
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160328&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1160383 ] digit-only tag values are mishandled in Tkinter
Bugs item #1160383, was opened at 2005-03-09 20:32
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=1160383&group_id=5470
Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Martin v. Löwis (loewis)
Summary: digit-only tag values are mishandled in Tkinter
Initial Comment:
It appears that most Tkinter tag operations fail on
digit-only tag values
>>> from Tkinter import *
>>> root=Tk()
>>> c=Canvas(root)
>>> c.create_line(0,0,100,100, tags="123")
1
>>> c.gettags(1)
('123',)
>>> c.pack()
>>> c.find_withtag("123")
()
tkinter docs:
http://www.pythonware.com/library/tkinter/introduction/x2017-concepts.htm
only say this about tag values:
"Tags are ordinary strings, and they can contain
anything except whitespace."
So this behaviour seems like a bug.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160383&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1160383 ] digit-only tag values are mishandled in Tkinter
Bugs item #1160383, was opened at 2005-03-09 20:32
Message generated for change (Settings changed) made by isandler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160383&group_id=5470
Category: Tkinter
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Martin v. Löwis (loewis)
Summary: digit-only tag values are mishandled in Tkinter
Initial Comment:
It appears that most Tkinter tag operations fail on
digit-only tag values
>>> from Tkinter import *
>>> root=Tk()
>>> c=Canvas(root)
>>> c.create_line(0,0,100,100, tags="123")
1
>>> c.gettags(1)
('123',)
>>> c.pack()
>>> c.find_withtag("123")
()
tkinter docs:
http://www.pythonware.com/library/tkinter/introduction/x2017-concepts.htm
only say this about tag values:
"Tags are ordinary strings, and they can contain
anything except whitespace."
So this behaviour seems like a bug.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1160383&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1158005 ] unixccompiler.py should deal with env in linker
Bugs item #1158005, was opened at 2005-03-06 16:42 Message generated for change (Comment added) made by edwardmoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Edward Moy (edwardmoy) Assigned to: Nobody/Anonymous (nobody) Summary: unixccompiler.py should deal with env in linker Initial Comment: When the linker command begins with env, plus some environment settings, and when the target is c++, the modified linker command should place the c++ command in the proper place, which is not the first element of the linker array. The following seems to be fix the problem: --- unixccompiler.py.orig 2004-08-29 09:45:13.0 -0700 +++ unixccompiler.py2005-03-06 16:36:05.0 -0800 @@ -172,7 +172,12 @@ else: linker = self.linker_so[:] if target_lang == "c++" and self.compiler_cxx: -linker[0] = self.compiler_cxx[0] +i = 0 +if os.path.basename(linker[0]) == "env": +i = 1 +while '=' in linker[i]: +i = i + 1 +linker[i] = self.compiler_cxx[0] self.spawn(linker + ld_args) except DistutilsExecError, msg: raise LinkError, msg -- >Comment By: Edward Moy (edwardmoy) Date: 2005-03-09 23:34 Message: Logged In: YES user_id=1233904 OK, looks like my problem was with 2.3.4, so I made that patch. Now that 2.3.5 is out, I didn't notice that this patch doesn't seem to be necessary anymore. Sorry for wasting your time. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-09 15:58 Message: Logged In: YES user_id=21627 Can you find out where it does pick it up *from*, please? Search the distutils and config directories of Python, and the wxWindows directories for clues; also print your env. -- Comment By: Edward Moy (edwardmoy) Date: 2005-03-09 15:22 Message: Logged In: YES user_id=1233904 I don't know the internal of python all that well, but I know that python (and perl as well) use "env MACOSX_DEPLOYMENT_TARGET=10.3 cc" as the link command, because this environment variable is required to enable the dynamic lookup symbol resolution feature in the linker (used with two-level namespaces). This is all rather Mac OS X specific, but I'm assuming since the python distributed with Mac OS X does this, that wxWidgets is picking that up and doing the same thing, as it should. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-09 15:03 Message: Logged In: YES user_id=21627 Hmm. Where does the "env MACOSX_DEPLOYMENT_TARGET" come from? I cannot find it in the Python build process or distutils. So if it is in the wxPython setup.py, it sure must be a bug in that setup.py, no? -- Comment By: Edward Moy (edwardmoy) Date: 2005-03-09 13:42 Message: Logged In: YES user_id=1233904 I was trying to build wxPython on Mac OS X. Without the change, it would compile all .c files, then when it tried to link, it would execute a command that looked like: g++ MACOSX_DEPLOYMENT_TARGET=10.3 c++ ... and fail. This is because it overwrote "env" with "g++". It needs to skip the env and its arguments, and replace (in this case) the c++. -- Comment By: Martin v. Löwis (loewis) Date: 2005-03-08 07:08 Message: Logged In: YES user_id=21627 Can you please give a specific example of what you did, what you expected to happen, and what happened instead (precise error messages, etc)? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
