[ python-Bugs-1472695 ] 32/64bit pickled Random incompatiblity
Bugs item #1472695, was opened at 2006-04-18 18:10
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Maxwell (pm67nz)
Assigned to: Nobody/Anonymous (nobody)
Summary: 32/64bit pickled Random incompatiblity
Initial Comment:
The unsigned long integers which make up the state of a Random
instance are converted to Python integers via a cast to long in
_randommodule.c's random_getstate function, so on a 32bit platform
Random.getstate() returns a mix of postitive and negative integers, while
on a 64bit platform the negative numbers are replaced by larger positive
numbers, their 32bit-2s-complement equivalents.
As a result, unpicking a Random instance from a 64bit machine on a 32bit
platform produces the error "OverflowError: long int too large to convert
to int". Unpickling a 32bit Random on a 64bit machine succeeds, but the
resulting object is in a slightly confused state:
>>> r32 = cPickle.load(open('r32_3.pickle'))
>>> for i in range(3):
... print r64.random(), r32.random()
...
0.237964627092 4292886520.32
0.544229225296 0.544229225296
0.369955166548 4292886520.19
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 00:02
Message:
Logged In: YES
user_id=33168
Peter, thanks for the report. Do you think you could work
up a patch to correct this problem?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472695&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472566 ] import module with .dll extension
Bugs item #1472566, was opened at 2006-04-18 13:06
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&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: svenn (sven_nystrom)
>Assigned to: Martin v. Löwis (loewis)
Summary: import module with .dll extension
Initial Comment:
In previous versions, extension modules with the file
extension '.dll' could be imported using a
single 'import' statement.
In 2.5a1 this seems to have changed - here's an
example:
>>> import minx # Implemented in a .dll - fails
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named minx
>>> import imp# Workaround
>>> import os
>>> minx = imp.load_dynamic('minx', os.getcwd()
+ '\\minx.dll')
I would really like this to remain the same; if that's
not possible, it would be helpful if the change itself
and a suggested approach were to be included in the
documentation.
/Sven
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 00:13
Message:
Logged In: YES
user_id=33168
I believe this was an intentional change in rev 43622. I
don't see any doc associated with the change however. I
also thought it was mentioned on python-dev. Martin,
shouldn't this be documented at least in Misc/NEWS? I
couldn't find anything.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472827 ] xml.sax.saxutils.XMLGenerator mangles \r\n\t in attributes
Bugs item #1472827, was opened at 2006-04-19 15:29
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=1472827&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mikhail Gusarov (gusarov)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.saxutils.XMLGenerator mangles \r\n\t in attributes
Initial Comment:
xml.sax.saxutils.XMLGenerator does not escape \r, \n,
\t symbols when they are present in the attribute:
startElement("name", {"attrib": "value\nvalue"}) will
result in
which will be normalized by XML parser to
According to the XML specs, to preserve this symbols in
the attribute values, they should be replaced with \xD;
\xA; \x9;
Trivial fix is to replace those characters in
xml.sax.saxutils.writeattr
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472827&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472173 ] interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian
Bugs item #1472173, was opened at 2006-04-18 11:20 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&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: None Status: Open >Resolution: Works For Me Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian Initial Comment: cursors , ctrl-a ctrl-e ... not recognized? worked with previous pythons vs:/usr/src/Python-2.5a1# make altinstall ... vs:/usr/src/Python-2.5a1# python2.5 Python 2.5a1 (r25a1:43589, Apr 15 2006, 21:51:42) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> abcd^E^A^[[1~^[[4~ -- >Comment By: kxroberto (kxroberto) Date: 2006-04-19 11:11 Message: Logged In: YES user_id=972995 oops, is ok after: apt-get install libreadline5-dev -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-19 06:16 Message: Logged In: YES user_id=33168 Hmmm, it's possible some of the configure magic changed. It might have been inadvertant. Can you attach your config.log? When you did a ./configure it should have printed out some things about readline and searching for it. That might help you diagnose the problem. -- Comment By: Michael Hudson (mwh) Date: 2006-04-18 11:32 Message: Logged In: YES user_id=6656 You might need to install readline-devel or some such package. I don't think anything has changed in python here... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1472176 ] "idna" encoding (drawing unicodedata) necessary in httplib?
Feature Requests item #1472176, was opened at 2006-04-18 11:28
Message generated for change (Comment added) made by kxroberto
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: "idna" encoding (drawing unicodedata) necessary in httplib?
Initial Comment:
httplib employs the "idna" encoding. that leads to
errors in py2exe/cxfreeze. And if forced into the
installer, it draws the 400kB+ unicodedata.pyd (on Win)
in innocent small apps. Otherwise no normal technical
modules draw the unicodedata.
Is that really necessary?
--
>Comment By: kxroberto (kxroberto)
Date: 2006-04-19 11:41
Message:
Logged In: YES
user_id=972995
a patch attached
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-04-18 11:59
Message:
Logged In: YES
user_id=38388
I agree - in most cases, ASCII will be used for hostnames
(where the idna encoding is being used in httplib).
A little helper function to first try .encode('ascii') and
then revert to .encode('idna') would do wonders.
Patches are welcome !
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1472176&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472877 ] Tix: Subwidget names
Bugs item #1472877, was opened at 2006-04-19 10:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472877&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: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Kievernagel (mkiever)
Assigned to: Martin v. Löwis (loewis)
Summary: Tix: Subwidget names
Initial Comment:
My system information:
--
uname -a:
Linux linux 2.6.4-52-default #1 Wed Apr 7 02:08:30 UTC
2004 i686 athlon i386 GNU/Linux
Python:
Python 2.4.1 (#4, Jan 10 2006, 10:53:14)
[GCC 3.3.3 (SuSE Linux)] on linux2
and
Python 2.3.5 (#1, Sep 12 2005, 14:56:24)
[GCC 3.3.3 (SuSE Linux)] on linux2
--
Using Tix you can produce the following exception:
---
>>> from Tix import *
>>> tk = Tk ()
>>> b = Balloon ()
>>> b.subwidget ( 'label' )
Traceback (most recent call last):
File "", line 1, in ?
File "/home/mkiever/pro/Python-2.4.1/Lib/lib-tk/Tix.
py", line 340, in subwidget
return self._nametowidget(n)
File "/home/mkiever/pro/Python-2.4.1/Lib/lib-tk/
Tkinter.py", line 1015, in nametowidget
w = w.children[name]
KeyError: 'lab'
>>>
---
I found a commentary in Tix.py:TixWidget:__init__
stating that 'subwidget_list' should contain
Tix names. But in Tix.py:TixSubWidget:__init__
the python names are used, not the names returned
by Tix.
I was successful with the following two
small additions (+++) near lines 400-450:
-
class TixSubWidget(TixWidget):
...
def __init__(self, master, name,
destroy_physically=1,
check_intermediate=1):
...
if (not check_intermediate) or len(plist) < 2:
# immediate descendant
if check_intermediate:+++
name = plist [0] +++
TixWidget.__init__(self, master, None, None,
{'name' : name})
else:
...
name = plist [-1] +++
TixWidget.__init__(self, parent, None, None,
{'name' : name})
self.destroy_physically = destroy_physically
...
-
This replaces the python name by the name
returned from Tix.
I have not extensively tested this (sorry).
Hope this helps.
Matthias Kievernagel ([EMAIL PROTECTED])
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472877&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472949 ] shutil.copytree debug message problem
Bugs item #1472949, was opened at 2006-04-19 14:42 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=1472949&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: Christophe DUMEZ (hydr0g3n) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copytree debug message problem Initial Comment: I noticed a problem in shutil.copytree : try: if symlinks and os.path.islink(srcname): linkto = os.readlink(srcname) os.symlink(linkto, dstname) elif os.path.isdir(srcname): copytree(srcname, dstname, symlinks) else: copy2(srcname, dstname) # XXX What about devices, sockets etc.? except (IOError, os.error), why: errors.append((srcname, dstname, why)) 'why' isn't displayed in tuple, maybe this line would be better for debug : "errors.append((srcname, dstname, why.strerror))" then, it will display something (for example: 'permission denied'). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472949&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1473000 ] valgrind detects problems in PyObject_Free
Bugs item #1473000, was opened at 2006-04-19 14:12 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=1473000&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: Jaime Torres Amate (jtajta2002) Assigned to: Nobody/Anonymous (nobody) Summary: valgrind detects problems in PyObject_Free Initial Comment: I just compiled python 2.4.3 with gcc 4.1.0, using glibc-2.4, and the COPTS = -g -O2 I just run valgrind (version 3.1.1) python -v And I get a lot of errors complaying about PyObject_Free: Conditional jump or move depends on uninitialised value(s) at 0x40B66A4: PyObject_Free (obmalloc.c:735) by 0x40B1E71: dictresize (dictobject.c:495) by 0x40B204D: PyDict_SetItemString (dictobject.c:1988) by 0x41048E3: Py_InitModule4 (modsupport.c:82) by 0x4116364: initposix (posixmodule.c:7895) by 0x40FF281: init_builtin (import.c:1765) by 0x40FF511: load_module (import.c:1694) by 0x40FFB3F: import_submodule (import.c:2266) by 0x40FFFEE: load_next (import.c:2086) by 0x41001D6: PyImport_ImportModuleEx (import.c:1921) by 0x40E23AD: builtin___import__ (bltinmodule.c:45) by 0x40B2FCC: PyCFunction_Call (methodobject.c:108) Invalid read of size 4 at 0x40B669F: PyObject_Free (obmalloc.c:735) by 0x4103B7E: PyMarshal_ReadLastObjectFromFile (marshal.c:768) by 0x40FCE53: read_compiled_module (import.c:723) by 0x40FED89: load_source_module (import.c:891) by 0x40FFB3F: import_submodule (import.c:2266) by 0x40FFFEE: load_next (import.c:2086) by 0x41001D6: PyImport_ImportModuleEx (import.c:1921) by 0x40E23AD: builtin___import__ (bltinmodule.c:45) by 0x40B2FCC: PyCFunction_Call (methodobject.c:108) by 0x408BB36: PyObject_Call (abstract.c:1795) by 0x40E580A: PyEval_CallObjectWithKeywords (ceval.c:3430) by 0x40E87D1: PyEval_EvalFrame (ceval.c:2020) Address 0x4339010 is 232 bytes inside a block of size 352 free'd at 0x4022E9D: free (vg_replace_malloc.c:235) by 0x41FBD1B: __fopen_internal (in /lib/libc-2.4.so) by 0x41FE569: fopen64 (in /lib/libc-2.4.so) by 0x40FD626: find_module (import.c:1316) by 0x40FFC64: import_submodule (import.c:2256) by 0x40FFFEE: load_next (import.c:2086) by 0x41001D6: PyImport_ImportModuleEx (import.c:1921) by 0x40E23AD: builtin___import__ (bltinmodule.c:45) by 0x40B2FCC: PyCFunction_Call (methodobject.c:108) by 0x408BB36: PyObject_Call (abstract.c:1795) by 0x40E580A: PyEval_CallObjectWithKeywords (ceval.c:3430) by 0x40E87D1: PyEval_EvalFrame (ceval.c:2020) - Invalid read of size 4 at 0x40B669F: PyObject_Free (obmalloc.c:735) by 0x4085A12: PyGrammar_RemoveAccelerators (acceler.c:47) by 0x41070DC: Py_Finalize (pythonrun.c:436) by 0x410E2C4: Py_Main (main.c:513) by 0x8048559: main (in /usr/bin/python) Address 0x4364010 is 104 bytes inside a block of size 640 free'd at 0x4022E9D: free (vg_replace_malloc.c:235) by 0x40B66C0: PyObject_Free (obmalloc.c:798) by 0x4085BA1: PyGrammar_AddAccelerators (acceler.c:124) by 0x40866A7: PyParser_New (parser.c:77) by 0x4086722: parsetok (parsetok.c:109) by 0x4086C9E: PyParser_ParseStringFlags (parsetok.c:31) by 0x4105FF3: PyParser_SimpleParseStringFlags (pythonrun.c:1365) by 0x410644A: PyRun_StringFlags (pythonrun.c:1222) by 0x40E1CBA: builtin_eval (bltinmodule.c:527) by 0x40B2FCC: PyCFunction_Call (methodobject.c:108) by 0x40EAE9B: PyEval_EvalFrame (ceval.c:3563) by 0x40EA6AA: PyEval_EvalFrame (ceval.c:3645) -- ERROR SUMMARY: 9678 errors from 111 contexts (suppressed: 36 from 1) malloc/free: in use at exit: 715,180 bytes in 251 blocks. malloc/free: 1,822 allocs, 1,571 frees, 1,552,763 bytes allocated. For counts of detected errors, rerun with: -v searching for pointers to 251 not-freed blocks. checked 664,740 bytes. LEAK SUMMARY: definitely lost: 10 bytes in 2 blocks. possibly lost: 0 bytes in 0 blocks. still reachable: 715,170 bytes in 249 blocks. suppressed: 0 bytes in 0 blocks. Best regards and many thanks for such an incredible language. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473000&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472710 ] Bug in threadmodule.c:local_traverse
Bugs item #1472710, was opened at 2006-04-18 22:34 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&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: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in threadmodule.c:local_traverse Initial Comment: threadmodule.c's local_traverse function does not call Py_VISIT on self->key. Attached is a one-line patch against r45556 to add the call. -- >Comment By: Collin Winter (collinwinter) Date: 2006-04-19 10:44 Message: Logged In: YES user_id=1344176 Aha. In which case, I'll work up a patch for the docs instead. Thanks for the clairification. I'll go ahead and close this report. -- Comment By: Tim Peters (tim_one) Date: 2006-04-19 00:42 Message: Logged In: YES user_id=31435 It doesn't really matter: self->key is either NULL or a Python string object, and neither can be involved in a cycle, so for purposes of cyclic gc it's just a waste of time to pass the key to a visit() callback. The docs could be clearer about this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472710 ] Bug in threadmodule.c:local_traverse
Bugs item #1472710, was opened at 2006-04-18 22:34 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&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: Deleted >Resolution: Invalid Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in threadmodule.c:local_traverse Initial Comment: threadmodule.c's local_traverse function does not call Py_VISIT on self->key. Attached is a one-line patch against r45556 to add the call. -- Comment By: Collin Winter (collinwinter) Date: 2006-04-19 10:44 Message: Logged In: YES user_id=1344176 Aha. In which case, I'll work up a patch for the docs instead. Thanks for the clairification. I'll go ahead and close this report. -- Comment By: Tim Peters (tim_one) Date: 2006-04-19 00:42 Message: Logged In: YES user_id=31435 It doesn't really matter: self->key is either NULL or a Python string object, and neither can be involved in a cycle, so for purposes of cyclic gc it's just a waste of time to pass the key to a visit() callback. The docs could be clearer about this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472710&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1473048 ] SimpleXMLRPCServer responds to any path
Bugs item #1473048, was opened at 2006-04-19 11:45 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=1473048&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: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer responds to any path Initial Comment: SimpleXMLRPCServer and DocXMLRPCServer don't look at the path of the HTTP request at all; you can POST or GET from / or /RPC2 or /blahblahblah with the same results. One minor problem with this liberality is that a security scanner that looks for vulnerable scripts such as /cgi-bin/phf will report the server as vulnerable. Nessus, for example, reports dozens of security holes on a SimpleXMLRPCServer for this reason. Fix: add a check that only allows '/' or '/RPC2' (maybe just /RPC2?). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1473048&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472566 ] import module with .dll extension
Bugs item #1472566, was opened at 2006-04-18 16:06
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&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: svenn (sven_nystrom)
Assigned to: Martin v. Löwis (loewis)
Summary: import module with .dll extension
Initial Comment:
In previous versions, extension modules with the file
extension '.dll' could be imported using a
single 'import' statement.
In 2.5a1 this seems to have changed - here's an
example:
>>> import minx # Implemented in a .dll - fails
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named minx
>>> import imp# Workaround
>>> import os
>>> minx = imp.load_dynamic('minx', os.getcwd()
+ '\\minx.dll')
I would really like this to remain the same; if that's
not possible, it would be helpful if the change itself
and a suggested approach were to be included in the
documentation.
/Sven
--
>Comment By: Tim Peters (tim_one)
Date: 2006-04-19 13:16
Message:
Logged In: YES
user_id=31435
Note that rev 43622 added a comment to dynload_win.c
explaining why it was done:
"""
/* Temporarily disable .dll, to avoid conflicts between
sqlite3.dll and the sqlite3 package. If this needs to
be reverted for 2.5, some other solution for the
naming conflict must be found.
"""
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 03:13
Message:
Logged In: YES
user_id=33168
I believe this was an intentional change in rev 43622. I
don't see any doc associated with the change however. I
also thought it was mentioned on python-dev. Martin,
shouldn't this be documented at least in Misc/NEWS? I
couldn't find anything.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
