[ python-Bugs-1729277 ] SVNVERSION redefined during compilation
Bugs item #1729277, was opened at 2007-06-01 02:28 Message generated for change (Comment added) made by krisvale You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj�n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. -- >Comment By: Kristj�n Valur (krisvale) Date: 2007-06-04 09:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-01 23:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented. Also, some of the projects that require external libraries need extra work to fully compile on x64. Kristjan, what was the rationale for making that specific change to getbuildinfo? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1729277 ] SVNVERSION redefined during compilation
Bugs item #1729277, was opened at 2007-05-31 19:28 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj�n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. -- >Comment By: Brett Cannon (bcannon) Date: 2007-06-04 12:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-06-04 02:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-01 16:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented. Also, some of the projects that require external libraries need extra work to fully compile on x64. Kristjan, what was the rationale for making that specific change to getbuildinfo? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1729277 ] SVNVERSION redefined during compilation
Bugs item #1729277, was opened at 2007-06-01 04:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj�n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-06-04 21:58 Message: Logged In: YES user_id=21627 Originator: NO SVNVERSION is passed on Unix. On Unix, there is no subwcrev program. Instead, there is an svnversion program which computes the same string as subwcrev, but prints it on stdout (rather than substituting it in some template file). Therefore, SVNVERSION needs to be passed on the command line. -- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 21:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-06-04 11:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-02 01:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented. Also, some of the projects that require external libraries need extra work to fully compile on x64. Kristjan, what was the rationale for making that specific change to getbuildinfo? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1729277 ] SVNVERSION redefined during compilation
Bugs item #1729277, was opened at 2007-05-31 19:28 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Kristj�n Valur (krisvale) Summary: SVNVERSION redefined during compilation Initial Comment: I sometimes get the following warning during a build: ./Modules/getbuildinfo.c:23:1: warning: "SVNVERSION" redefined :1:1: warning: this is the location of the previous definition It looks like SVNVERSION is defined in getbuildinfo.c, but a value is also passed in on the command-line in the Makefile when the module is built (line 460). I have no clue why this is being done. -- >Comment By: Brett Cannon (bcannon) Date: 2007-06-04 14:30 Message: Logged In: YES user_id=357491 Originator: YES I figure that much from my experiment. What I am wondering is if the #define in getbuildinfo.c is needed. Does the Windows build need it? Or is it that just to guarantee that the file is self-supported and won't fail to compile if the compile-time define is not passed in? If the #define in the file is required then I vote for the #ifndef solution with an explanation. -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-04 12:58 Message: Logged In: YES user_id=21627 Originator: NO SVNVERSION is passed on Unix. On Unix, there is no subwcrev program. Instead, there is an svnversion program which computes the same string as subwcrev, but prints it on stdout (rather than substituting it in some template file). Therefore, SVNVERSION needs to be passed on the command line. -- Comment By: Brett Cannon (bcannon) Date: 2007-06-04 12:41 Message: Logged In: YES user_id=357491 Originator: YES Well, when I remove the command-line def (the entire -D argument when building getbuildinfo.c) I get no subversion number out of sys.subversion. But when I comment out the SVNVERSION definition instead in getbuildinfo.c I do have the subversion number show up. And I just noticed that when both are defined I have no subversion number (as is the case in the trunk at the moment). I just wrapped the SVNVERSION definition in getbuildinfo.c in a #ifndef and that fixed the problem. but I don't know if doing that will just mask an issue where SVNVERSION should not be defined in getbuildinfo.c at all if it is being passed in during compilation. -- Comment By: Kristj�n Valur (krisvale) Date: 2007-06-04 02:46 Message: Logged In: YES user_id=1262199 Originator: NO The intent was to remove the reliance on the define SUBWCREV so to simplify the actions of make_buildinfo.c. It then only needs to either copy it or run it through subwcrev.exe. Now the code autodetects whether it was passed through subwcrev.exe or not by examining if the string was interpolated. What is the purpose of the SVNVERSION macro passed on the command line? If it has the same value, then maybe a conditional #define will fix this back? Otherwise, rolling back the change will mean that make_buildinfo.c will have to create some other info for the subsequent compilation of getbuildinfo.c to define or undefin SVNWCREV -- Comment By: Martin v. Löwis (loewis) Date: 2007-06-01 16:28 Message: Logged In: YES user_id=21627 Originator: NO This was broken in r55024 | kristjan.jonsson | 2007-04-30 17:17:46 +0200 (Mo, 30 Apr 2007) | 1 line Complete revamp of PCBuild8 directory. Use subdirectories for each project under the main pcbuild solution. Now make extensive use of property sheets to simplify project configuration. x64 build fully supported, and the process for building PGO version (Profiler Guided Optimization) simplified. All projects are now present, except _ssl, which needs to be reimplemented. Also, some of the projects that require external libraries need extra work to fully compile on x64. Kristjan, what was the rationale for making that specific change to getbuildinfo? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1729277&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mai
[ python-Bugs-1731068 ] Importing a submodule after unloading its parent
Bugs item #1731068, was opened at 2007-06-04 16: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=1731068&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 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Nobody/Anonymous (nobody) Summary: Importing a submodule after unloading its parent Initial Comment: It seems that if you import a submodule, cause its parent package to be destroyed, then attempt to re-import the submodule, the parent package is properly re-imported but the submodule does not get set on it. The session below demonstrates this. After the second xml.sax import, "xml" is the xml package module as expected, but xml.sax does not exist. I'm not familiar with all of the import semantics, but it seems odd to me that "foo.bar" could ever fail to exist right after an "import foo.bar". Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] o 32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, xml.sax >>> del xml, sys.modules["xml"] >>> import xml.sax >>> xml.sax Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'sax' >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731068&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1731068 ] Importing a submodule fails after unloading its parent
Bugs item #1731068, was opened at 2007-06-04 16:21 Message generated for change (Settings changed) made by blakeross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731068&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 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Nobody/Anonymous (nobody) >Summary: Importing a submodule fails after unloading its parent Initial Comment: It seems that if you import a submodule, cause its parent package to be destroyed, then attempt to re-import the submodule, the parent package is properly re-imported but the submodule does not get set on it. The session below demonstrates this. After the second xml.sax import, "xml" is the xml package module as expected, but xml.sax does not exist. I'm not familiar with all of the import semantics, but it seems odd to me that "foo.bar" could ever fail to exist right after an "import foo.bar". Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] o 32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, xml.sax >>> del xml, sys.modules["xml"] >>> import xml.sax >>> xml.sax Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'sax' >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731068&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1731068 ] Importing a submodule fails after unloading its parent
Bugs item #1731068, was opened at 2007-06-04 16:21 Message generated for change (Settings changed) made by blakeross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731068&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 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Nobody/Anonymous (nobody) Summary: Importing a submodule fails after unloading its parent Initial Comment: It seems that if you import a submodule, cause its parent package to be destroyed, then attempt to re-import the submodule, the parent package is properly re-imported but the submodule does not get set on it. The session below demonstrates this. After the second xml.sax import, "xml" is the xml package module as expected, but xml.sax does not exist. I'm not familiar with all of the import semantics, but it seems odd to me that "foo.bar" could ever fail to exist right after an "import foo.bar". Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] o 32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, xml.sax >>> del xml, sys.modules["xml"] >>> import xml.sax >>> xml.sax Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'sax' >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1731068&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1730480 ] dict init/update accesses internal items of dict derivative
Bugs item #1730480, was opened at 2007-06-03 20:59
Message generated for change (Settings changed) made by blakeross
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730480&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
Private: No
Submitted By: Blake Ross (blakeross)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict init/update accesses internal items of dict derivative
Initial Comment:
>>> class MyDict(dict):
... def keys(self): print "keys"
... def __getitem__(self, n): print "__getitem__"
...
>>> myDict = MyDict(a=1, b=2)
>>> dict(myDict)
{'a': 1, 'b': 2}
PyDict_Merge accesses the items of the dict to be merged directly rather than
going through the interface for any dict instance--even a dict derivative--by
virtue of using PyDict_Check rather than PyDict_CheckExact. I believe the logic
needs to be:
if type(d).__getitem__ is dict.__getitem__ and type(d).keys is dict.keys:
...okay to access items directly...
else:
...go through the methods...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730480&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
