[ python-Bugs-1569084 ] External codecs no longer usable
Bugs item #1569084, was opened at 2006-10-02 08:42
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569084&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: Unicode
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Ivan Vilata i Balaguer (ivilata)
Assigned to: M.-A. Lemburg (lemburg)
Summary: External codecs no longer usable
Initial Comment:
Up to Python 2.5, external codec packages could be used
just by dropping them somewhere in the $PYTHONPATH, as
long as they provided a ``getregentry()`` function and
the normalised encoding name matched the name of the
package. For instance, having a ``myencoding`` package
with a ``getregentry()`` function in it made possible
executing::
>>> u'something'.encode('myencoding')
without even importing ``myencoding``. It was the
``__import__(modname, ...)`` statement in
``encodings.search_function()`` which made this possible.
However, in Python 2.5 the previous statement was
changed to the absolute one ``__import('encodings.' +
modname, ...)``, which makes external codec packages no
longer reachable in the way described above. Is this a
bug, or has this been made on purpose? In the later
case, what do you recommend to use external codecs as
transparently as possible? I now manually enter the
registry tuple/CodecInfo into the encodings cache, but
tampering with it doesn't seem right (and it also means
that some initialisation code must be explicitly run).
By the way, this bug may be related with #223642.
Maybe it should be reopened.
Thank you very much!
(I know, I should have checked the betas and release
candidates in case this was a bug. I didn't have the
time, sorry!)
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-10-02 10:43
Message:
Logged In: YES
user_id=38388
The encodings package codec search function was never
intended to be used by codecs other than the encodings package.
The 'encodings.' part for the module name was added to
prevent importing arbitrary modules as a result of looking
up a codec that's not defined in the encodings package which
could result in a security problem.
If you want to use your own codecs, please register a codec
search function with the codecs module first. It is
recommended to place the codecs into a package of its own -
again to prevent accidental import of non-codec modules.
See http://docs.python.org/lib/module-codecs.html for details.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569084&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568897 ] http redirect does not pass 'post' data
Bugs item #1568897, was opened at 2006-10-01 23:08 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568897&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: hans_moleman (hans_moleman) Assigned to: Nobody/Anonymous (nobody) Summary: http redirect does not pass 'post' data Initial Comment: A HTTP(S) redirect does not pass POST 'data'. Currently: If a redirect is required, a new Request is created with a URL that the redirect response has provided. This new Request has the original headers. Required: For the new Request the data too will be copied from the original Request. I believe the following one line change is required in 'urllib2.HTTPRedirectHandler.redirect_request': return Request(url = newurl, headers = req.headers, data= req.data, ... Environment: Linux Python 2.5 -- Comment By: Wummel (calvin) Date: 2006-10-02 11:14 Message: Logged In: YES user_id=9205 Automatic redirects are only allowed for GET and HEAD[1]. Sending POST data automatically to other hosts than the original one is a security flaw. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 So I think the current behaviour of urllib2 is correct, and should not be changed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568897&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568243 ] init_types
Bugs item #1568243, was opened at 2006-09-30 11:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&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: 6 Submitted By: Bosko Vukov (bvukov) Assigned to: Martin v. Löwis (loewis) Summary: init_types Initial Comment: I tried to build the final version of Python 2.5, and found that function init_types in file Python-ast.c is created as int init_types(void) but in file config.c it's declared as extern void init_types(void); Visual Studio 2005 didn't want to build the project until I changed the config.c to be the same... extern int init_types(void); Nothing big ;) Regards, Bosko -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-02 16:00 Message: Logged In: YES user_id=21627 Notice that the PCbuild8 directory isn't really supported... In any case, the bug is that PCbuild8 does not have the reference to _typesmodule, not that init_types in Python-ast.c is static. If you revert your change to Python-ast.c, and change pythoncore.vcproj, it should build fine. This is already fixed in r51751 in the trunk; not sure whether backporting it is necessary. -- Comment By: Bosko Vukov (bvukov) Date: 2006-09-30 19:50 Message: Logged In: YES user_id=1292849 I opened solution file from folder PCbuild8, and inside project file pythoncore.vcproj there is no reference to _typesmodule.c. It exists in pythoncore.vcproj in the PBbuild folder ( for older version's ). I added the missing _typesmodule.c inside, and returned back the changes I made, and aft er that linker reported 'Python-ast.obj : error LNK2005: _init_types already defined in _typesmodule.obj' -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 13:27 Message: Logged In: YES user_id=849994 The problem is another one: The config.c init_types function belongs to the _types module, while the Python-ast.c init_types is an internal function. They shouldn't clash. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563630 ] IDLE doesn't load - apparently without firewall problems
Bugs item #1563630, was opened at 2006-09-22 17:19 Message generated for change (Comment added) made by daniboy22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: dani (daniboy22) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE doesn't load - apparently without firewall problems Initial Comment: I've installed Python in Windows XP, SP2. When I ran IDLE for the first times, it worked ok. But then I redefined some shorcuts (history-previous, history-next, and expand-word). This also worked ok, but there was a problem I wasn't expecting: I changed the history-previous to the short-cut + P, and when I use it for the first time it printed the content of the window... I forgot that this shorcut was already in use... Then came the real problem. I went to redefine the history-previous to another key set, but each time I clicked for "oK" for the new keys, the shell wrote some errors in red (-/+ 7/8 lines). I did that a few times until I closed IDLE and tried to restarted it again. Then it stop working. The only thing it does now is to show the hourglass logo in the mouse pointer for a few seconds and then it does not do anything else. I've installed Python in its default path (C:\Python25), and tried to switch off all the firewalls I remembered (Windows Firewall and disabled McAfee Virus Scan). None of that worked. I tried several times to reinstall the software, but that didn't work either. I even tried to install a previous version of Python (v2.4.3), but it had exactly the same problem. I haven't found any similar problem on the web. Thanks, Dani -- >Comment By: dani (daniboy22) Date: 2006-10-02 14:12 Message: Logged In: YES user_id=1604341 Dear kbk, I tried your solution and everything seems to work fine. I even recreated the problem (with the details that I still remember), and everything is OK. Many thanks! Dani P.S. For jordanramz: the .idlerc folder can be found in the directory c:\Documents and Settings (assuming you installed Windows on C:), and then selecting the folder corresponding to your ID (say, "jordanramz"). -- Comment By: jordanramz (jordanramz) Date: 2006-10-01 16:42 Message: Logged In: YES user_id=1604497 What is the .idlerc customization folder? -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-10-01 02:38 Message: Logged In: YES user_id=149084 Use the task manager to kill all Python processes. Then set aside your .idlerc customization folder (i.e. rename it). Now IDLE should start. Try to recreate the problem and post any error messages you see here. -- Comment By: jordanramz (jordanramz) Date: 2006-09-22 21:15 Message: Logged In: YES user_id=1604497 I am having the same problem. When I first installed it, it ran okay. Now everytime I go back to run it, the hourglass on my mouse shows up for a few seconds and then nothing. At first I had v2.4.3 because that's what we're using in my class, but I tried v2.5(final) thinking it would help, but it didn't, so I reinstalled v2.4.3. I noticed that with my task manager in view, when I click the IDLE program my processes jump up one number for a few seconds also, then goes back. So apparently it's running but then ending before it loads up? I tried messing with my firewall and stuff also, with no success, so I'm in the same boat as you. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563630 ] IDLE doesn't load - apparently without firewall problems
Bugs item #1563630, was opened at 2006-09-22 17:19 Message generated for change (Comment added) made by daniboy22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: dani (daniboy22) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE doesn't load - apparently without firewall problems Initial Comment: I've installed Python in Windows XP, SP2. When I ran IDLE for the first times, it worked ok. But then I redefined some shorcuts (history-previous, history-next, and expand-word). This also worked ok, but there was a problem I wasn't expecting: I changed the history-previous to the short-cut + P, and when I use it for the first time it printed the content of the window... I forgot that this shorcut was already in use... Then came the real problem. I went to redefine the history-previous to another key set, but each time I clicked for "oK" for the new keys, the shell wrote some errors in red (-/+ 7/8 lines). I did that a few times until I closed IDLE and tried to restarted it again. Then it stop working. The only thing it does now is to show the hourglass logo in the mouse pointer for a few seconds and then it does not do anything else. I've installed Python in its default path (C:\Python25), and tried to switch off all the firewalls I remembered (Windows Firewall and disabled McAfee Virus Scan). None of that worked. I tried several times to reinstall the software, but that didn't work either. I even tried to install a previous version of Python (v2.4.3), but it had exactly the same problem. I haven't found any similar problem on the web. Thanks, Dani -- >Comment By: dani (daniboy22) Date: 2006-10-02 14:13 Message: Logged In: YES user_id=1604341 Dear kbk, I tried your solution and everything seems to work fine. I even recreated the problem (with the details that I still remember), and everything is OK. Many thanks! Dani P.S. For jordanramz: the .idlerc folder can be found in the directory c:\Documents and Settings (assuming you installed Windows on C:), and then selecting the folder corresponding to your ID (say, "jordanramz"). -- Comment By: dani (daniboy22) Date: 2006-10-02 14:12 Message: Logged In: YES user_id=1604341 Dear kbk, I tried your solution and everything seems to work fine. I even recreated the problem (with the details that I still remember), and everything is OK. Many thanks! Dani P.S. For jordanramz: the .idlerc folder can be found in the directory c:\Documents and Settings (assuming you installed Windows on C:), and then selecting the folder corresponding to your ID (say, "jordanramz"). -- Comment By: jordanramz (jordanramz) Date: 2006-10-01 16:42 Message: Logged In: YES user_id=1604497 What is the .idlerc customization folder? -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-10-01 02:38 Message: Logged In: YES user_id=149084 Use the task manager to kill all Python processes. Then set aside your .idlerc customization folder (i.e. rename it). Now IDLE should start. Try to recreate the problem and post any error messages you see here. -- Comment By: jordanramz (jordanramz) Date: 2006-09-22 21:15 Message: Logged In: YES user_id=1604497 I am having the same problem. When I first installed it, it ran okay. Now everytime I go back to run it, the hourglass on my mouse shows up for a few seconds and then nothing. At first I had v2.4.3 because that's what we're using in my class, but I tried v2.5(final) thinking it would help, but it didn't, so I reinstalled v2.4.3. I noticed that with my task manager in view, when I click the IDLE program my processes jump up one number for a few seconds also, then goes back. So apparently it's running but then ending before it loads up? I tried messing with my firewall and stuff also, with no success, so I'm in the same boat as you. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565797 ] 'all' documentation missing online
Bugs item #1565797, was opened at 2006-09-26 17:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565797&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: Documentation Group: None >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: 'all' documentation missing online Initial Comment: http://docs.python.org/lib/built-in-funcs.html is missing a description of the new built-in 'all' function. On a separate note, contrary to the statement on the bugs page, the search dialogue is not in the left margin ... -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-02 16:26 Message: Logged In: YES user_id=21627 Thanks for the update; the text on the SF bug submission page is now fixed. -- Comment By: Alan (aisaac0) Date: 2006-10-02 05:23 Message: Logged In: YES user_id=1025672 For reasons unknown to me my browser was displaying a cached version of the Built-In Functions page. Very sorry for the noise. As for the other matter: the page is http://sourceforge.net/tracker/?func=add&group_id=5470&atid=105470 where the first full line of text is "Please try to see if the bug you are about to submit hasn't already been submitted before. The search box in the left margin can be used for this purpose." But the search box is above this text, to the right. fwiw -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-26 18:06 Message: Logged In: YES user_id=21627 Could it be that you had been looking at an old version of the documentation (the new version wasn't online shortly after the release). I can clearly see 'all' documented as all(iterable) Return True if all elements of the iterable are true. Equivalent to: ... As for the separate note: what bugs page are you referring to? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565797&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568842 ] Test for uintptr_t seems to be incorrect
Bugs item #1568842, was opened at 2006-10-01 20:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568842&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: Closed >Resolution: Fixed Priority: 6 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: Test for uintptr_t seems to be incorrect Initial Comment: Someone reported on the pythonmac list that HAVE_UINTPTR_T wasn't defined in pyconfig.h while it should have been defined. I'm looking into this and am now wondering whether the configure snipped below is correct: AC_MSG_CHECKING(for uintptr_t support) have_uintptr_t=no AC_TRY_COMPILE([], [uintptr_t x; x = (uintptr_t)0;], [ AC_DEFINE(HAVE_UINTPTR_T, 1, [Define this if you have the type uintptr_t.]) have_uintptr_t=yes ]) AC_MSG_RESULT($have_uintptr_t) if test "$have_uintptr_t" = yes ; then AC_CHECK_SIZEOF(uintptr_t, 4) fi This seems to check for uintptr_t as a builtin type. Isn't one supposed to include to get this type? Chaning the AC_TRY_COMPILE line to the line below fixes the issue for me on OSX and Linux: AC_TRY_COMPILE([#include ], [uintptr_t x; x = (uintptr_t)0;], [ BTW. This issue is also present in Python 2.4. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-02 16:57 Message: Logged In: YES user_id=21627 Thanks for the report. fixed in r52086, 52087, 52088. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568842&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568429 ] broken info files generation
Bugs item #1568429, was opened at 2006-09-30 20:49
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568429&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: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Arkadiusz Miskiewicz (arekm)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken info files generation
Initial Comment:
Hi,
Currently make -C Doc/info will not work. There are bugs
in *.tex files which prevent py2texinfo from working.
Also even after fixing these there are some weird
constructs which later make makeinfo go mad.
Take a look at
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/python-
info.patch
which has some fixes for that.
This one is important:
-level=1\optional{, parent\optional\{,
directory\optional{,
-attributes=0
+level=1\optional{, parent\optional{,
directory\optional{,
+attributes=0}
- unmatched {} + one wrongly quoted {
The other thing is using quote enviroment which is
unknown to py2texinfo - change it to quotation.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-10-02 17:06
Message:
Logged In: YES
user_id=21627
Can you please attach your proposed change as an "svn diff"
for the version you are referring to?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568429&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568897 ] http redirect does not pass 'post' data
Bugs item #1568897, was opened at 2006-10-01 23:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568897&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: Invalid Priority: 5 Submitted By: hans_moleman (hans_moleman) Assigned to: Nobody/Anonymous (nobody) Summary: http redirect does not pass 'post' data Initial Comment: A HTTP(S) redirect does not pass POST 'data'. Currently: If a redirect is required, a new Request is created with a URL that the redirect response has provided. This new Request has the original headers. Required: For the new Request the data too will be copied from the original Request. I believe the following one line change is required in 'urllib2.HTTPRedirectHandler.redirect_request': return Request(url = newurl, headers = req.headers, data= req.data, ... Environment: Linux Python 2.5 -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-02 17:08 Message: Logged In: YES user_id=21627 I agree with calvin; this is not a bug. -- Comment By: Wummel (calvin) Date: 2006-10-02 11:14 Message: Logged In: YES user_id=9205 Automatic redirects are only allowed for GET and HEAD[1]. Sending POST data automatically to other hosts than the original one is a security flaw. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 So I think the current behaviour of urllib2 is correct, and should not be changed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568897&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569356 ] sys.settrace cause curried parms to show up as attributes
Bugs item #1569356, was opened at 2006-10-02 11: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=1569356&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: applebucks (scott_marks)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.settrace cause curried parms to show up as attributes
Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not.
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail.
Reported v 2.4, but the same behavior on 2.5. Any ideas?
""" Demonstrace that tracing messes up curried class
definitions """
# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys
def usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
sys.exit( 1 )
if 1 == len( sys.argv ):
pass
elif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
def trace ( frame, event, arg ):
# print frame, event, arg
return trace
sys.settrace( trace )
else:
usage( )
else:
usage( )
# The test: define a class factory with a curried
member function
def the_factory( parm1 ):
class the_class( object ):
def curried( self ): return parm1
return the_class
x = the_factory( 42 )
y = x( )
try:
x.parm1
print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
print "Success with the manufactured class!"
try:
y.parm1
print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569374 ] sys.settrace cause curried parms to show up as attributes
Bugs item #1569374, was opened at 2006-10-02 11:48
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=1569374&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: applebucks (scott_marks)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.settrace cause curried parms to show up as attributes
Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not.
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail.
Reported v 2.4, but the same behavior on 2.5. Any ideas?
""" Demonstrace that tracing messes up curried class
definitions """
# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys
def usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
sys.exit( 1 )
if 1 == len( sys.argv ):
pass
elif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
def trace ( frame, event, arg ):
# print frame, event, arg
return trace
sys.settrace( trace )
else:
usage( )
else:
usage( )
# The test: define a class factory with a curried
member function
def the_factory( parm1 ):
class the_class( object ):
def curried( self ): return parm1
return the_class
x = the_factory( 42 )
y = x( )
try:
x.parm1
print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
print "Success with the manufactured class!"
try:
y.parm1
print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569374&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569374 ] sys.settrace cause curried parms to show up as attributes
Bugs item #1569374, was opened at 2006-10-02 11:48
Message generated for change (Settings changed) made by scott_marks
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569374&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: Duplicate
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.settrace cause curried parms to show up as attributes
Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not.
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail.
Reported v 2.4, but the same behavior on 2.5. Any ideas?
""" Demonstrace that tracing messes up curried class
definitions """
# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys
def usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
sys.exit( 1 )
if 1 == len( sys.argv ):
pass
elif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
def trace ( frame, event, arg ):
# print frame, event, arg
return trace
sys.settrace( trace )
else:
usage( )
else:
usage( )
# The test: define a class factory with a curried
member function
def the_factory( parm1 ):
class the_class( object ):
def curried( self ): return parm1
return the_class
x = the_factory( 42 )
y = x( )
try:
x.parm1
print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
print "Success with the manufactured class!"
try:
y.parm1
print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569374&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569374 ] sys.settrace cause curried parms to show up as attributes
Bugs item #1569374, was opened at 2006-10-02 11:48
Message generated for change (Comment added) made by scott_marks
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569374&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: Duplicate
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.settrace cause curried parms to show up as attributes
Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not.
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail.
Reported v 2.4, but the same behavior on 2.5. Any ideas?
""" Demonstrace that tracing messes up curried class
definitions """
# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys
def usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
sys.exit( 1 )
if 1 == len( sys.argv ):
pass
elif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
def trace ( frame, event, arg ):
# print frame, event, arg
return trace
sys.settrace( trace )
else:
usage( )
else:
usage( )
# The test: define a class factory with a curried
member function
def the_factory( parm1 ):
class the_class( object ):
def curried( self ): return parm1
return the_class
x = the_factory( 42 )
y = x( )
try:
x.parm1
print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
print "Success with the manufactured class!"
try:
y.parm1
print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
--
>Comment By: applebucks (scott_marks)
Date: 2006-10-02 11:57
Message:
Logged In: YES
user_id=120857
Please ignore this refresh-button-generated duplicate.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569374&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569356 ] sys.settrace cause curried parms to show up as attributes
Bugs item #1569356, was opened at 2006-10-02 11:26
Message generated for change (Comment added) made by scott_marks
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&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: applebucks (scott_marks)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.settrace cause curried parms to show up as attributes
Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not.
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail.
Reported v 2.4, but the same behavior on 2.5. Any ideas?
""" Demonstrace that tracing messes up curried class
definitions """
# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys
def usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
sys.exit( 1 )
if 1 == len( sys.argv ):
pass
elif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
def trace ( frame, event, arg ):
# print frame, event, arg
return trace
sys.settrace( trace )
else:
usage( )
else:
usage( )
# The test: define a class factory with a curried
member function
def the_factory( parm1 ):
class the_class( object ):
def curried( self ): return parm1
return the_class
x = the_factory( 42 )
y = x( )
try:
x.parm1
print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
print "Success with the manufactured class!"
try:
y.parm1
print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
--
>Comment By: applebucks (scott_marks)
Date: 2006-10-02 12:02
Message:
Logged In: YES
user_id=120857
This bug actually causes a failure in a system that heavily
uses function-level programming and member delegation. The
bug occurred when a class factory function formal parameter
name was the same as a field delegated by instances of the
generated class to a member -- when run in a debugger (i.e.
after a non-None call to sys.settrace) the delegating
descriptor was over-written by the value of the factory
function parameter.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569374 ] sys.settrace cause curried parms to show up as attributes
Bugs item #1569374, was opened at 2006-10-02 15:48
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569374&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: Duplicate
Priority: 5
Submitted By: applebucks (scott_marks)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.settrace cause curried parms to show up as attributes
Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not.
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail.
Reported v 2.4, but the same behavior on 2.5. Any ideas?
""" Demonstrace that tracing messes up curried class
definitions """
# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys
def usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
sys.exit( 1 )
if 1 == len( sys.argv ):
pass
elif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
def trace ( frame, event, arg ):
# print frame, event, arg
return trace
sys.settrace( trace )
else:
usage( )
else:
usage( )
# The test: define a class factory with a curried
member function
def the_factory( parm1 ):
class the_class( object ):
def curried( self ): return parm1
return the_class
x = the_factory( 42 )
y = x( )
try:
x.parm1
print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
print "Success with the manufactured class!"
try:
y.parm1
print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
--
Comment By: applebucks (scott_marks)
Date: 2006-10-02 15:57
Message:
Logged In: YES
user_id=120857
Please ignore this refresh-button-generated duplicate.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569374&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568243 ] init_types
Bugs item #1568243, was opened at 2006-09-30 09:34 Message generated for change (Comment added) made by coatimundi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&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: 6 Submitted By: Bosko Vukov (bvukov) Assigned to: Martin v. Löwis (loewis) Summary: init_types Initial Comment: I tried to build the final version of Python 2.5, and found that function init_types in file Python-ast.c is created as int init_types(void) but in file config.c it's declared as extern void init_types(void); Visual Studio 2005 didn't want to build the project until I changed the config.c to be the same... extern int init_types(void); Nothing big ;) Regards, Bosko -- Comment By: Coatimundi (coatimundi) Date: 2006-10-02 18:28 Message: Logged In: YES user_id=1611513 I am expereincing the problem described by the original poster. I undertand that MSVC8 is not officially supported, and I'm trying anyway. I downloaded the 2.5.0 final tarball and began working in the PCbuild8 directory. Firts off, I found that I had to build two projects before pythoncore would build: make_versioninfo make_buildinfo When I tried to build pythoncore, I got the linker error saying that _init_types could not be found. So I added _typesmodule.c to the pythoncore project. Finally, pythoncore built cleanly. Next up, I wanted to build pythoncore_pgo. So I added _typesmodule to this project also. But try as I might, every attempt to build pythoncore_pgo produces the link error on _init_types. (I also did a 'clean' on pythoncore just to be safe.) I do not understand this. Unlike the original poster, I have not modified any source. It seems like the definition of pyMODINIT_FUNC as extern "C" void might be involved, but I agree with gbrandl that the static int in Python-ast.c is not the issue, because that is a different scope. So the linkage problem with pythoncore_pgo remains a mystery to me. I hope someone has more clues than me. -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-02 14:00 Message: Logged In: YES user_id=21627 Notice that the PCbuild8 directory isn't really supported... In any case, the bug is that PCbuild8 does not have the reference to _typesmodule, not that init_types in Python-ast.c is static. If you revert your change to Python-ast.c, and change pythoncore.vcproj, it should build fine. This is already fixed in r51751 in the trunk; not sure whether backporting it is necessary. -- Comment By: Bosko Vukov (bvukov) Date: 2006-09-30 17:50 Message: Logged In: YES user_id=1292849 I opened solution file from folder PCbuild8, and inside project file pythoncore.vcproj there is no reference to _typesmodule.c. It exists in pythoncore.vcproj in the PBbuild folder ( for older version's ). I added the missing _typesmodule.c inside, and returned back the changes I made, and aft er that linker reported 'Python-ast.obj : error LNK2005: _init_types already defined in _typesmodule.obj' -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 11:27 Message: Logged In: YES user_id=849994 The problem is another one: The config.c init_types function belongs to the _types module, while the Python-ast.c init_types is an internal function. They shouldn't clash. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568243 ] init_types
Bugs item #1568243, was opened at 2006-09-30 11:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&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: 6 Submitted By: Bosko Vukov (bvukov) Assigned to: Martin v. Löwis (loewis) Summary: init_types Initial Comment: I tried to build the final version of Python 2.5, and found that function init_types in file Python-ast.c is created as int init_types(void) but in file config.c it's declared as extern void init_types(void); Visual Studio 2005 didn't want to build the project until I changed the config.c to be the same... extern int init_types(void); Nothing big ;) Regards, Bosko -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-02 21:08 Message: Logged In: YES user_id=21627 I think you should avoid building pythoncore_pgo; it's of no use. Or else, study all documentation you can find on Microsoft's profile-guided-optimization for a few days, read all web logs about the bugs in this software, and perhaps you can succeed in building it, by deleting the right files in the right order. -- Comment By: Coatimundi (coatimundi) Date: 2006-10-02 20:28 Message: Logged In: YES user_id=1611513 I am expereincing the problem described by the original poster. I undertand that MSVC8 is not officially supported, and I'm trying anyway. I downloaded the 2.5.0 final tarball and began working in the PCbuild8 directory. Firts off, I found that I had to build two projects before pythoncore would build: make_versioninfo make_buildinfo When I tried to build pythoncore, I got the linker error saying that _init_types could not be found. So I added _typesmodule.c to the pythoncore project. Finally, pythoncore built cleanly. Next up, I wanted to build pythoncore_pgo. So I added _typesmodule to this project also. But try as I might, every attempt to build pythoncore_pgo produces the link error on _init_types. (I also did a 'clean' on pythoncore just to be safe.) I do not understand this. Unlike the original poster, I have not modified any source. It seems like the definition of pyMODINIT_FUNC as extern "C" void might be involved, but I agree with gbrandl that the static int in Python-ast.c is not the issue, because that is a different scope. So the linkage problem with pythoncore_pgo remains a mystery to me. I hope someone has more clues than me. -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-02 16:00 Message: Logged In: YES user_id=21627 Notice that the PCbuild8 directory isn't really supported... In any case, the bug is that PCbuild8 does not have the reference to _typesmodule, not that init_types in Python-ast.c is static. If you revert your change to Python-ast.c, and change pythoncore.vcproj, it should build fine. This is already fixed in r51751 in the trunk; not sure whether backporting it is necessary. -- Comment By: Bosko Vukov (bvukov) Date: 2006-09-30 19:50 Message: Logged In: YES user_id=1292849 I opened solution file from folder PCbuild8, and inside project file pythoncore.vcproj there is no reference to _typesmodule.c. It exists in pythoncore.vcproj in the PBbuild folder ( for older version's ). I added the missing _typesmodule.c inside, and returned back the changes I made, and aft er that linker reported 'Python-ast.obj : error LNK2005: _init_types already defined in _typesmodule.obj' -- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 13:27 Message: Logged In: YES user_id=849994 The problem is another one: The config.c init_types function belongs to the _types module, while the Python-ast.c init_types is an internal function. They shouldn't clash. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1567910 ] missing _typesmodule.c, Visual Studio 2005 pythoncore.vcproj
Bugs item #1567910, was opened at 2006-09-29 19:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567910&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: everbruin (everbruin) Assigned to: Nobody/Anonymous (nobody) Summary: missing _typesmodule.c,Visual Studio 2005 pythoncore.vcproj Initial Comment: Python 2.5's Visual Studio 2005 pythoncore.vcproj (in PCBuild8 folder) is missing Modules/_typesmodule.c (note the VS 2003 pythoncore.vcproj in PCBuild correctly has it). The bug is that binaries built w/o the file will give a SystemError when "import _types" is done (eg by types.py). -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-02 21:10 Message: Logged In: YES user_id=21627 I find it hard to believe that you get this precise error; I would have expected that the pythoncore project would fail to build instead. Notice that PCbuild8 is not really supported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567910&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1568243 ] init_types
Bugs item #1568243, was opened at 2006-09-30 09:34 Message generated for change (Comment added) made by coatimundi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568243&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: 6 Submitted By: Bosko Vukov (bvukov) Assigned to: Martin v. Löwis (loewis) Summary: init_types Initial Comment: I tried to build the final version of Python 2.5, and found that function init_types in file Python-ast.c is created as int init_types(void) but in file config.c it's declared as extern void init_types(void); Visual Studio 2005 didn't want to build the project until I changed the config.c to be the same... extern int init_types(void); Nothing big ;) Regards, Bosko -- Comment By: Coatimundi (coatimundi) Date: 2006-10-02 19:22 Message: Logged In: YES user_id=1611513 Thanks, loewis. I take your advice. I see that things have changed in SVN anyway. I like the new approach of using Visual STudio's configuration management. When I (try to) build PGIRelease to instrument the python dll, I get a curious error: 1>Compiling... 1>zlibmodule.c 1>Compiling resources... 1>Linking... 1> Creating library Win32\PGIRelease\pythoncore/python26.lib and object Win32\PGIRelease\pythoncore/python26.exp 1>Generating code 1>c:\Documents and Settings\kferrio\My Documents\Dev\Python-2.5\Modules\zipimport.c : fatal error C1350: error loading dll 'pgodb80.dll': dll not found 1>LINK : fatal error LNK1257: code generation failed 1>Build log was saved at "file://c:\Documents and Settings\kferrio\My Documents\Dev\Python-2.5\PCbuild8\Win32\PGIRelease\pythoncore\BuildLog.htm" 1>pythoncore - 2 error(s), 2 warning(s) == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == I definitely do not understand this -- yet. Meanwhile, any clues would be welcome. Thanks. -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-02 19:08 Message: Logged In: YES user_id=21627 I think you should avoid building pythoncore_pgo; it's of no use. Or else, study all documentation you can find on Microsoft's profile-guided-optimization for a few days, read all web logs about the bugs in this software, and perhaps you can succeed in building it, by deleting the right files in the right order. -- Comment By: Coatimundi (coatimundi) Date: 2006-10-02 18:28 Message: Logged In: YES user_id=1611513 I am expereincing the problem described by the original poster. I undertand that MSVC8 is not officially supported, and I'm trying anyway. I downloaded the 2.5.0 final tarball and began working in the PCbuild8 directory. Firts off, I found that I had to build two projects before pythoncore would build: make_versioninfo make_buildinfo When I tried to build pythoncore, I got the linker error saying that _init_types could not be found. So I added _typesmodule.c to the pythoncore project. Finally, pythoncore built cleanly. Next up, I wanted to build pythoncore_pgo. So I added _typesmodule to this project also. But try as I might, every attempt to build pythoncore_pgo produces the link error on _init_types. (I also did a 'clean' on pythoncore just to be safe.) I do not understand this. Unlike the original poster, I have not modified any source. It seems like the definition of pyMODINIT_FUNC as extern "C" void might be involved, but I agree with gbrandl that the static int in Python-ast.c is not the issue, because that is a different scope. So the linkage problem with pythoncore_pgo remains a mystery to me. I hope someone has more clues than me. -- Comment By: Martin v. Löwis (loewis) Date: 2006-10-02 14:00 Message: Logged In: YES user_id=21627 Notice that the PCbuild8 directory isn't really supported... In any case, the bug is that PCbuild8 does not have the reference to _typesmodule, not that init_types in Python-ast.c is static. If you revert your change to Python-ast.c, and change pythoncore.vcproj, it should build fine. This is already fixed in r51751 in the trunk; not sure whether backporting it is necessary. -- Comment By: Bosko Vukov (bvukov) Date: 2006-09-30 17:50 Message: Logged In: YES user_id=1292849 I opened solution file from folder PCbuild8, and inside project file pythoncore.vcproj there is no reference to _typesmodule.c. It exists in pythoncore.vcproj in the PBbuild folder ( for older version's ). I added the missing _typesmodule.c inside, and returned back the changes
[ python-Bugs-1569517 ] PGIRelease linkage fails on pgodb80.dll
Bugs item #1569517, was opened at 2006-10-02 19:54 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=1569517&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 Submitted By: Coatimundi (coatimundi) Assigned to: Nobody/Anonymous (nobody) Summary: PGIRelease linkage fails on pgodb80.dll Initial Comment: Hi. I'm interested in learning how to optimize Python for Windows. I have made a similar report as a follow-on to Bug 1568243, but it's really a separate issue. Let me emphasize that what I am about to describe this is *not* a bug in the Python build system. But it may be worth calling out in the README file for PCbuild8. When building PGIRelease to instrument the pythoncore DLL, the linker fails because it cannot find pgodb80.dll. This file is required for PGO with Visual C++ under Visual Studio 2005 and is shipped with the Professional version, but not with the Express version or (apparently) the Standard version I have. Looks like upgrade time... I hope this helps someone else. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569517&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1232947 ] non-admin install may fail (win xp pro)
Bugs item #1232947, was opened at 2005-07-05 20:31 Message generated for change (Comment added) made by pvrijlandt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1232947&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Patrick Vrijlandt (pvrijlandt) Assigned to: Martin v. Löwis (loewis) Summary: non-admin install may fail (win xp pro) Initial Comment: concerns: python 2.4.1 msi When trying to do a non-admin install on Windows XP Pro, the installer probably tries to make shortcuts in a non-accessible directory. The status-window is displaying: creating shortcuts A messagebox appears and says the installer lacks priveliges on a certain directory: please try again as an administrator, (which i am obviously not). The cancel-option now leads to a rollback of the installation. -- >Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2006-10-02 23:48 Message: Logged In: YES user_id=1307917 This bug still exists with 2.5 As a workaround, I found out that I could install for all users. -- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-08-11 21:14 Message: Logged In: YES user_id=1307917 These are difficult questions for me. I don't know if my ACL (access control list?) is on that folder. I'm almost certain the sysadmins did this for us. They try to get as much userfiles as possible on the network. They are also pretty restrictive (and understaffed) Backup is done only for network drives. The advantage is that I can access my user files from different computers (without using a server OS) My start menu is almost empty. All programs we are able to use, are accessible through a shortcut on the desktop. I probably can read the startmenu folder but not write it. "My documents" refers to a networked directory. I have full access there and can run programs from there. I suppose a patch would be to make more configuration options in the installer (Do you want to make shortcuts? Do you want to make them here?). I would make shortcuts on my desktop. (Yes, I can write there. Files sometimes go to c:\windows\desktop, and sometimes to a networked drive) What would be needed to run python (and pythonwin) from a memory-stick or cd-rom? If that would work, my problem would be solved too. Even better: one installation would make python accessible from any computer on our network I would login to. BTW: some drives (like C:) are hidden from explorer. I cannot do start -> run (but I can make a shortcut to cmd on my desktop, and run from there). I'm not sure I can get to regedit and/or do anything useful there. -- Comment By: Patrick Vrijlandt (pvrijlandt) Date: 2005-08-11 21:11 Message: Logged In: YES user_id=1307917 These are difficult questions for me. I don't know if my ACL (access control list?) is on that folder. I'm almost certain the sysadmins did this for us. They try to get as much userfiles as possible on the network. They are also pretty restrictive (and understaffed) Backup is done only for network drives. The advantage is that I can access my user files from different computers (without using a server OS) My start menu is almost empty. All programs we are able to use, are accessible through a shortcut on the desktop. I probably can read the startmenu folder but not write it. "My documents" refers to a networked directory. I have full access there and can run programs from there. I suppose a patch would be to make more configuration options in the installer (Do you want to make shortcuts? Do you want to make them here?). I would make shortcuts on my desktop. (Yes, I can write there. Files sometimes go to c:\windows\desktop, and sometimes to a networked drive) What would be needed to run python (and pythonwin) from a memory-stick or cd-rom? If that would work, my problem would be solved too. Even better: one installation would make python accessible from any computer on our network I would login to. BTW: some drives (like C:) are hidden from explorer. I cannot do start -> run (but I can make a shortcut to cmd on my desktop, and run from there). I'm not sure I can get to regedit and/or do anything useful there. -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-06 14:58 Message: Logged In: YES user_id=21627 According to the log file, there was an error accessing \\bw2\snelkop\2003\info\programma's\Python 2.4 How come your Menu folder is on a network drive? What is the ACL on that folder? ---
[ python-Bugs-1563630 ] IDLE doesn't load - apparently without firewall problems
Bugs item #1563630, was opened at 2006-09-22 12:19 Message generated for change (Comment added) made by jordanramz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563630&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: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: dani (daniboy22) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE doesn't load - apparently without firewall problems Initial Comment: I've installed Python in Windows XP, SP2. When I ran IDLE for the first times, it worked ok. But then I redefined some shorcuts (history-previous, history-next, and expand-word). This also worked ok, but there was a problem I wasn't expecting: I changed the history-previous to the short-cut + P, and when I use it for the first time it printed the content of the window... I forgot that this shorcut was already in use... Then came the real problem. I went to redefine the history-previous to another key set, but each time I clicked for "oK" for the new keys, the shell wrote some errors in red (-/+ 7/8 lines). I did that a few times until I closed IDLE and tried to restarted it again. Then it stop working. The only thing it does now is to show the hourglass logo in the mouse pointer for a few seconds and then it does not do anything else. I've installed Python in its default path (C:\Python25), and tried to switch off all the firewalls I remembered (Windows Firewall and disabled McAfee Virus Scan). None of that worked. I tried several times to reinstall the software, but that didn't work either. I even tried to install a previous version of Python (v2.4.3), but it had exactly the same problem. I haven't found any similar problem on the web. Thanks, Dani -- Comment By: jordanramz (jordanramz) Date: 2006-10-02 17:15 Message: Logged In: YES user_id=1604497 Thanks for that, I found it. However, I guess I'm not as skilled with the computer as I thought... It won't let me change the name, open the folder etc. It says access is denied. Know why it's doing that when I try to modify it? -- Comment By: dani (daniboy22) Date: 2006-10-02 09:13 Message: Logged In: YES user_id=1604341 Dear kbk, I tried your solution and everything seems to work fine. I even recreated the problem (with the details that I still remember), and everything is OK. Many thanks! Dani P.S. For jordanramz: the .idlerc folder can be found in the directory c:\Documents and Settings (assuming you installed Windows on C:), and then selecting the folder corresponding to your ID (say, "jordanramz"). -- Comment By: dani (daniboy22) Date: 2006-10-02 09:12 Message: Logged In: YES user_id=1604341 Dear kbk, I tried your solution and everything seems to work fine. I even recreated the problem (with the details that I still remember), and everything is OK. Many thanks! Dani P.S. For jordanramz: the .idlerc folder can be found in the directory c:\Documents and Settings (assuming you installed Windows on C:), and then selecting the folder corresponding to your ID (say, "jordanramz"). -- Comment By: jordanramz (jordanramz) Date: 2006-10-01 11:42 Message: Logged In: YES user_id=1604497 What is the .idlerc customization folder? -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-09-30 21:38 Message: Logged In: YES user_id=149084 Use the task manager to kill all Python processes. Then set aside your .idlerc customization folder (i.e. rename it). Now IDLE should start. Try to recreate the problem and post any error messages you see here. -- Comment By: jordanramz (jordanramz) Date: 2006-09-22 16:15 Message: Logged In: YES user_id=1604497 I am having the same problem. When I first installed it, it ran okay. Now everytime I go back to run it, the hourglass on my mouse shows up for a few seconds and then nothing. At first I had v2.4.3 because that's what we're using in my class, but I tried v2.5(final) thinking it would help, but it didn't, so I reinstalled v2.4.3. I noticed that with my task manager in view, when I click the IDLE program my processes jump up one number for a few seconds also, then goes back. So apparently it's running but then ending before it loads up? I tried messing with my firewall and stuff also, with no success, so I'm in the same boat as you. -- You can respond by visiting: https://sourceforge.net/tracker/?f
[ python-Bugs-1569622 ] Backward incompatibility in logging.py
Bugs item #1569622, was opened at 2006-10-02 16:10 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=1569622&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: Backward incompatibility in logging.py Initial Comment: LogRecord.__init__ changed in a backward incompatible way in python 2.5 (added one parameter). There is no mention of this breakage in the release notes, nor has the documentation of the module been updated (http://docs.python.org/lib/node424.html) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569623 ] datetime.datetime subtraction bug
Bugs item #1569623, was opened at 2006-10-02 23:16 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=1569623&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: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: David Fugate (dfugate_ms) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.datetime subtraction bug Initial Comment: Python version: 2.5 OS name and version: Windows XP SP2 Email: [EMAIL PROTECTED] The datetime.datetime subtraction operator seems to have a bug in it: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> x = datetime.datetime(2006, 9, 29, 15, 37, 28, 686001) >>> y = datetime.datetime(2006, 9, 29, 15, 37, 28, 686000) >>> x - y datetime.timedelta(0, 0, 1) >>> y - x datetime.timedelta(-1, 86399, 99) Here, the result of y - x should be timedelta(0, 0, -1). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569623&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569623 ] datetime.datetime subtraction bug
Bugs item #1569623, was opened at 2006-10-02 19:16 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569623&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: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: David Fugate (dfugate_ms) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.datetime subtraction bug Initial Comment: Python version: 2.5 OS name and version: Windows XP SP2 Email: [EMAIL PROTECTED] The datetime.datetime subtraction operator seems to have a bug in it: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> x = datetime.datetime(2006, 9, 29, 15, 37, 28, 686001) >>> y = datetime.datetime(2006, 9, 29, 15, 37, 28, 686000) >>> x - y datetime.timedelta(0, 0, 1) >>> y - x datetime.timedelta(-1, 86399, 99) Here, the result of y - x should be timedelta(0, 0, -1). -- >Comment By: Tim Peters (tim_one) Date: 2006-10-02 19:27 Message: Logged In: YES user_id=31435 Sorry, nope. As the timedelta docs say: """ ... days, seconds and microseconds are then normalized so that the representation is unique, with 0 <= microseconds < 100 0 <= seconds < 3600*24 (the number of seconds in one day) -9 <= days <= 9 ... If the normalized value of days lies outside the indicated range, OverflowError is raised. Note that normalization of negative values may be surprising at first. For example, >>> d = timedelta(microseconds=-1) >>> (d.days, d.seconds, d.microseconds) (-1, 86399, 99) """ Which is exactly what you're seeing. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569623&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569622 ] Backward incompatibility in logging.py
Bugs item #1569622, was opened at 2006-10-02 23:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Mike Klaas (mklaas) >Assigned to: Vinay Sajip (vsajip) Summary: Backward incompatibility in logging.py Initial Comment: LogRecord.__init__ changed in a backward incompatible way in python 2.5 (added one parameter). There is no mention of this breakage in the release notes, nor has the documentation of the module been updated (http://docs.python.org/lib/node424.html) -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-03 06:11 Message: Logged In: YES user_id=849994 I don't see why adding one parameter is backwards incompatible, but it's true that the docs must be updated. Assigning to Vinay. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569356 ] sys.settrace cause curried parms to show up as attributes
Bugs item #1569356, was opened at 2006-10-02 15:26
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&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: applebucks (scott_marks)
>Assigned to: Martin v. Löwis (loewis)
Summary: sys.settrace cause curried parms to show up as attributes
Initial Comment:
The code below exhibits different behavior depending on
whether it invokes sys.settrace ('-t' option) or not.
This means that (in a more complicated case) debugging
the code (which uses sys.settrace) makes it fail.
Reported v 2.4, but the same behavior on 2.5. Any ideas?
""" Demonstrace that tracing messes up curried class
definitions """
# Some simple command line parsing: -t or --trace means
trace, nothing means don't trace
import sys
def usage( ):
print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
sys.exit( 1 )
if 1 == len( sys.argv ):
pass
elif 2 == len( sys.argv ):
if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
def trace ( frame, event, arg ):
# print frame, event, arg
return trace
sys.settrace( trace )
else:
usage( )
else:
usage( )
# The test: define a class factory with a curried
member function
def the_factory( parm1 ):
class the_class( object ):
def curried( self ): return parm1
return the_class
x = the_factory( 42 )
y = x( )
try:
x.parm1
print "Failure: x (the manufactured class) has
attribute parm1?!"
except AttributeError:
print "Success with the manufactured class!"
try:
y.parm1
print "Failure: y (the instance) has attribute parm1?!"
except AttributeError:
print "Success with the instance!"
assert y.curried( ) == 42, "Currying didn't work?!"
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-03 06:49
Message:
Logged In: YES
user_id=849994
I'm afraid that this cannot be fixed.
In normal execution, the variable "parm1" is stored by the
compiler in the "fast locals" (that are referenced by index
into a list) for the function that is used to build the
class, which means that it is not in the dict of "normal
locals" (that are referenced by their name in the dict) that
is returned at the end.
If you set a trace function, on each call to the trace
function the "fast locals" are merged into the "normal
locals" in order to give the trace function full control
over the execution frame. This means that after the trace
function has been executed for the class' frame, the locals
will contain "parm1" which will then show up as an attribute
of that class.
Martin, do you you have an additional opinion?
--
Comment By: applebucks (scott_marks)
Date: 2006-10-02 16:02
Message:
Logged In: YES
user_id=120857
This bug actually causes a failure in a system that heavily
uses function-level programming and member delegation. The
bug occurred when a class factory function formal parameter
name was the same as a field delegated by instances of the
generated class to a member -- when run in a debugger (i.e.
after a non-None call to sys.settrace) the delegating
descriptor was over-written by the value of the factory
function parameter.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569356&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
