[ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5
Bugs item #1391872, was opened at 2005-12-28 20:01 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&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.5 Status: Open Resolution: None Priority: 9 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: floating point literals don't work in non-US locale in 2.5 Initial Comment: According to reports on comp.lang.python, the current SVN trunk fails to handle floating point literals if the locale is changed: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'German_Germany.1252' >>> 3.141592 3.0 This works just fine in 2.4.2. See the later portions of the thread "build curiosities of svn head (on WinXP)" for more details: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/226584dd47047bb6/e609cb1a0d47e98f -- >Comment By: Hye-Shik Chang (perky) Date: 2005-12-29 17:22 Message: Logged In: YES user_id=55188 The new patch tests it along with other locale-dependent tests on test__locale. How about this? -- Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 04:00 Message: Logged In: YES user_id=38376 I'm not sure you can make too many assumptions about the locale in the test suite, but I'm pretty sure that it would be a good idea to let your "build robot" run the test suite twice; once with the standard C locale, and once with a non-US locale (e.g. sv_SE.utf8 which does include some odd characters, different date and money formats, and a decimal comma). -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-29 03:16 Message: Logged In: YES user_id=33168 Wow, I thought for sure I broke it with my recent patch to remove support for hex floats. But it looks like just an AST problem (which I can be blamed for too :-). The patch looks fine, but could you add tests so this doesn't happen again. Thanks! I'll be back in a week and try to fix it then if no one gets back to it. -- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 23:04 Message: Logged In: YES user_id=55188 Okay. Here's a fix. -- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 22:41 Message: Logged In: YES user_id=55188 This looks like a bug introduced by AST import; r39757 is okay but r39762 has such an error. -- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 20:02 Message: Logged In: YES user_id=38376 I just confirmed this on Unix: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) [GCC 2.96 2731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 3.14 3.1401 >>> import locale >>> locale.setlocale(locale.LC_ALL, "") 'sv_SE.utf8' >>> 3.14 3.0 >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1392915 ] build fails on BSD 3.8
Bugs item #1392915, was opened at 2005-12-30 00:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1392915&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: build fails on BSD 3.8 Initial Comment: There are several reports that python cannot be compiled in recent OpenBSD. The problem seems to be that configure script is not updated in sync with OpenBSD releases. Similar bug report can be found here:: www.python.org/sf/1026986 building on OpenBSD 3.5 Attached patch uses the same hack as this one. I didn't test it by myself, but the reporter said "it did the trick." -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1392915&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Bugs item #1153075, was opened at 2005-02-27 21:55 Message generated for change (Settings changed) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro Initial Comment: The functions PyInt_Check(), PyString_Check(), PyList_Check() etc. are used all over the core to check which typecasts are safe, from PyObject* to the various PyXxxObject*. But the macros themselves are implemented by inspecting the "tp_mro" tuple of the incoming object's type. As the latter can be completely controlled by the user, an object can pretend to inherit from anything and pass the PyXxx_Check() checks of its choice, even if its memory layout is actually completely wrong. See attached example. -- >Comment By: Armin Rigo (arigo) Date: 2005-12-29 17:08 Message: Logged In: YES user_id=4771 Checked in as r41845. -- Comment By: Armin Rigo (arigo) Date: 2005-12-14 14:41 Message: Logged In: YES user_id=4771 I'm getting confused. First note that the problem I mentioned about extra_ivars() triggering an assert() can only occur at start-up. Indeed, PyType_Ready() copies the tp_base->tp_basicsize if the subtype's tp_basicsize is 0. So we can probably ignore the problem -- no extra_ivars() call would trigger the assert after start-up. The check that your patch adds is that solid_base(A) must be a superclass of solid_base(T) for each A in the mro of T. For built-in mros, the A's are exactly the superclasses of T. So we have to prove [*]: if A is a superclass of T, then solid_base(A) is a superclass of solid_base(T). Irrespective of what extra_ivars() does, solid_base(T) is either exactly T, or solid_base(T->tp_base). Moreover, when a type T is created with immediate bases B1...Bn, we check that all solid_bases of B1...Bn form a linear order (i.e. are subclasses of each other), and we set T->tp_base to the first Bi such that solid_base(Bi) is a subclass of all the other solid_base(Bj). Let's approach [*] above by induction on the set of types in which A and T are chosen. This set of types can be ordered by creation time: T1, T2, T3, ... where classes with a higher index can only inherit from classes with lower indices. Assume that [*] holds if A and T are chosen among T1...Tn-1. Let's prove it if A and/or T can also be Tn. The only non-trivial case is if A is a strict superclass of T=Tn. As above, let write B1...Bn for the immediate bases of T, with T->tp_base=Bi. Pick j such that A is a superclass of Bj. By induction solid_base(A) is a superclass of solid_base(Bj) which is a superclass of solid_base(Bi=T->tp_base). Now solid_base(T) is either T or solid_base(Bi). In both cases, solid_base(T) is a subclass of solid_base(A). This concludes the proof -- or I am missing something :-) In other words, I don't think the patch can break anything, so it should definitely go in. -- Comment By: Michael Hudson (mwh) Date: 2005-03-15 13:22 Message: Logged In: YES user_id=6656 Please see the attached PDF for a proof of ... well, something in the area. I think this is what typeobject.c should be doing and what it's *trying* to do. I'm less confident that this is what it's actually doing (particularly wrt the subclassing two subclasses of str thing). -- Comment By: Michael Hudson (mwh) Date: 2005-03-14 11:41 Message: Logged In: YES user_id=6656 Well, emprically that can't happen because the patch passes test_descr, and far sillier things happen in that file than in real life. More theoretically... I'll think about it :) -- Comment By: Armin Rigo (arigo) Date: 2005-03-14 11:25 Message: Logged In: YES user_id=4771 I tried to convince myself that this check always accepts the default mro, but there are more implicit assumptions around than I can handle in a quick review... Instead, I modified the patch so that a debug build of Python always does the check in mro_internal(). This results in a shallow problem: the basestring type has tp_basicsize==0, which makes the computation of its solid_base trigger an assertion in extra_ivars(). If I hack around this problem, then I cannot quickly find an example of built-in mro that triggers a TypeError, but it doesn't mean there isn't one... ---
[ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5
Bugs item #1391872, was opened at 2005-12-28 12:01 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&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.5 Status: Open Resolution: None Priority: 9 Submitted By: Fredrik Lundh (effbot) >Assigned to: Fredrik Lundh (effbot) Summary: floating point literals don't work in non-US locale in 2.5 Initial Comment: According to reports on comp.lang.python, the current SVN trunk fails to handle floating point literals if the locale is changed: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'German_Germany.1252' >>> 3.141592 3.0 This works just fine in 2.4.2. See the later portions of the thread "build curiosities of svn head (on WinXP)" for more details: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/226584dd47047bb6/e609cb1a0d47e98f -- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 19:52 Message: Logged In: YES user_id=38376 Looks good to me. I'll check this in shortly. -- Comment By: Hye-Shik Chang (perky) Date: 2005-12-29 09:22 Message: Logged In: YES user_id=55188 The new patch tests it along with other locale-dependent tests on test__locale. How about this? -- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 20:00 Message: Logged In: YES user_id=38376 I'm not sure you can make too many assumptions about the locale in the test suite, but I'm pretty sure that it would be a good idea to let your "build robot" run the test suite twice; once with the standard C locale, and once with a non-US locale (e.g. sv_SE.utf8 which does include some odd characters, different date and money formats, and a decimal comma). -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-28 19:16 Message: Logged In: YES user_id=33168 Wow, I thought for sure I broke it with my recent patch to remove support for hex floats. But it looks like just an AST problem (which I can be blamed for too :-). The patch looks fine, but could you add tests so this doesn't happen again. Thanks! I'll be back in a week and try to fix it then if no one gets back to it. -- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 15:04 Message: Logged In: YES user_id=55188 Okay. Here's a fix. -- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 14:41 Message: Logged In: YES user_id=55188 This looks like a bug introduced by AST import; r39757 is okay but r39762 has such an error. -- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 12:02 Message: Logged In: YES user_id=38376 I just confirmed this on Unix: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) [GCC 2.96 2731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 3.14 3.1401 >>> import locale >>> locale.setlocale(locale.LC_ALL, "") 'sv_SE.utf8' >>> 3.14 3.0 >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1393109 ] cannot build SVN trunk on old systems
Bugs item #1393109, was opened at 2005-12-29 21:25 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=1393109&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: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: cannot build SVN trunk on old systems Initial Comment: Parser/asdl_c.py uses "/usr/bin/env python" to find a proper python, but the script don't work on old Pythons (at least it fails on 2.1 and older). iirc, various solutions to this were discussed on python-dev, but nobody seems to have done anything about it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1393109&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5
Bugs item #1391872, was opened at 2005-12-28 12:01 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&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.5 Status: Open Resolution: None >Priority: 5 Submitted By: Fredrik Lundh (effbot) >Assigned to: Neal Norwitz (nnorwitz) Summary: floating point literals don't work in non-US locale in 2.5 Initial Comment: According to reports on comp.lang.python, the current SVN trunk fails to handle floating point literals if the locale is changed: >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'German_Germany.1252' >>> 3.141592 3.0 This works just fine in 2.4.2. See the later portions of the thread "build curiosities of svn head (on WinXP)" for more details: http://groups.google.com/group/comp.lang.python/browse_ frm/thread/226584dd47047bb6/e609cb1a0d47e98f -- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 21:37 Message: Logged In: YES user_id=38376 Verified and fixed in SVN. Assinging to Neal, in case he wants to add an extra locale test pass to his build robot. -- Comment By: Fredrik Lundh (effbot) Date: 2005-12-29 19:52 Message: Logged In: YES user_id=38376 Looks good to me. I'll check this in shortly. -- Comment By: Hye-Shik Chang (perky) Date: 2005-12-29 09:22 Message: Logged In: YES user_id=55188 The new patch tests it along with other locale-dependent tests on test__locale. How about this? -- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 20:00 Message: Logged In: YES user_id=38376 I'm not sure you can make too many assumptions about the locale in the test suite, but I'm pretty sure that it would be a good idea to let your "build robot" run the test suite twice; once with the standard C locale, and once with a non-US locale (e.g. sv_SE.utf8 which does include some odd characters, different date and money formats, and a decimal comma). -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-28 19:16 Message: Logged In: YES user_id=33168 Wow, I thought for sure I broke it with my recent patch to remove support for hex floats. But it looks like just an AST problem (which I can be blamed for too :-). The patch looks fine, but could you add tests so this doesn't happen again. Thanks! I'll be back in a week and try to fix it then if no one gets back to it. -- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 15:04 Message: Logged In: YES user_id=55188 Okay. Here's a fix. -- Comment By: Hye-Shik Chang (perky) Date: 2005-12-28 14:41 Message: Logged In: YES user_id=55188 This looks like a bug introduced by AST import; r39757 is okay but r39762 has such an error. -- Comment By: Fredrik Lundh (effbot) Date: 2005-12-28 12:02 Message: Logged In: YES user_id=38376 I just confirmed this on Unix: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) [GCC 2.96 2731 (Red Hat Linux 7.2 2.96-112.7.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 3.14 3.1401 >>> import locale >>> locale.setlocale(locale.LC_ALL, "") 'sv_SE.utf8' >>> 3.14 3.0 >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1390608 ] split() breaks no-break spaces
Bugs item #1390608, was opened at 2005-12-26 16:03
Message generated for change (Comment added) made by effbot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&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: MvR (maxim_razin)
Assigned to: Nobody/Anonymous (nobody)
Summary: split() breaks no-break spaces
Initial Comment:
string.split(), str.split() and unicode.split() without
parameters break strings by the No-break space (U+00A0)
character. This character is specially intended not to
be a split border.
>>> u"Hello\u00A0world".split()
[u'Hello', u'world']
--
>Comment By: Fredrik Lundh (effbot)
Date: 2005-12-29 21:42
Message:
Logged In: YES
user_id=38376
split isn't a word-wrapping split, so I'm not sure that's
the right place to fix this. ("no-break space" is white-
space, according to the Unicode standard, and split breaks
on whitespace).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1349732 ] urllib.urlencode provides two features in one param
Bugs item #1349732, was opened at 2005-11-06 14:58
Message generated for change (Comment added) made by mike_j_brown
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349732&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: Ori Avtalion (salty-horse)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.urlencode provides two features in one param
Initial Comment:
Using the 2.4 distribution.
It seems that urlencode knows how to handle unicode
input with quote_plus and ascii encoding, but it only
does that when doseq is True.
1) There's no mention of that useful feature in the
documentation.
2) If I want to encode unicode data without doseq's
feature, there's no way to do so. Although it's rare to
use doseq's intended function, they shouldn't be connected.
Shouldn't values be checked with _is_unicode and
handled correctly in both modes of doseq?
One reason I see that *might* make the unicode check
cause problems is the comment says "preserve old
behavior" when doseq is False. Could such a check
affect the behaviour of old code?
If it can, the unicode handling could be another
optional parameter.
Also, the docstring is really unclear as to the purpose
of doseq.
Can an small example be added? (I saw no PEP guidelines
for how examples should be given in docstrings, or if
they're even allowed, so perhaps this fits just the
regular documentation)
With query={"key": ("val1", "val2")
doseq=1 yields: key=val1&key=val2
doseq=0 yields: key=%28%27val1%27%2C+%27val2%27%29
After the correct solution is settled, I'll gladly
submit a patch with the fixes.
--
Comment By: Mike Brown (mike_j_brown)
Date: 2005-12-29 16:32
Message:
Logged In: YES
user_id=371366
I understand why the implementation is the way it is. I
agree that it is not documented as ideally as it could be. I
also agree with your implication that ASCII-range unicode
input should be acceptable (and converted to ASCII bytes
internally before percent-encoding), regardless of doseq. I
would not go so far as to say non-ASCII-range unicode should
be accepted, since safe conversion to bytes before
percent-encoding would not be possible.
However, I was unable to reproduce your observation that
doseq=0 results in urlencode not knowing how to handle
unicode. The object is just passed to str(). Granted, that's
not *quite* the same as when doseq=1, where unicode objects
are specifically run through .encode('us-ascii','replace')),
but I wouldn't characterize it as not knowing how to handle
ASCII-range unicode. The results for ASCII-range unicode are
the same.
If you're going to make things more consistent, I would
actually tighten up the doseq=1 behavior, replacing
v = quote_plus(v.encode("ASCII","replace"))
with
v = quote_plus(v.encode("ASCII","strict"))
and then mention in the docs that any object type is
acceptable as a key or value, but if unicode is passed, it
must be all ASCII-range characters; if there is a risk of
characters above \u007f being passed, then the caller should
convert the unicode to str beforehand.
As for doseq's purpose and documentation, the doseq=1
behavior is ideal for almost all situations, since it takes
care not to treat str or unicode as a sequence of separate
1-character values. AFAIK, the only reason it isn't the
default is for backward compatiblity. It was introduced in
Python 2.0.1 and was trying to retain compatibility with
code written for Python 1.5.2 through 2.0.0. I suggest
deprecating it and making doseq=1 behavior the default, if
others (MvL?) approve.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349732&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1390608 ] split() breaks no-break spaces
Bugs item #1390608, was opened at 2005-12-27 00:03
Message generated for change (Comment added) made by perky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&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: MvR (maxim_razin)
Assigned to: Nobody/Anonymous (nobody)
Summary: split() breaks no-break spaces
Initial Comment:
string.split(), str.split() and unicode.split() without
parameters break strings by the No-break space (U+00A0)
character. This character is specially intended not to
be a split border.
>>> u"Hello\u00A0world".split()
[u'Hello', u'world']
--
>Comment By: Hye-Shik Chang (perky)
Date: 2005-12-30 09:30
Message:
Logged In: YES
user_id=55188
Python documentation says that it splits in "whitespace
characters" not "breaking characters". So, current
behavior is correct according to the documentation. And
even rationale among string methods are heavily depends on
ctype functions on libc. Therefore, we can't serve special
treatment for the NBSP.
However, I feel the need for the splitting function that
awares what character is breaking or not. How about to add
it as unicodedata.split()?
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-30 05:42
Message:
Logged In: YES
user_id=38376
split isn't a word-wrapping split, so I'm not sure that's
the right place to fix this. ("no-break space" is white-
space, according to the Unicode standard, and split breaks
on whitespace).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1390608&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1384175 ] random module - Provider DLL failed to initialize correctly
Bugs item #1384175, was opened at 2005-12-18 01:18 Message generated for change (Comment added) made by ghazel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1384175&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: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: random module - Provider DLL failed to initialize correctly Initial Comment: File "random.pyc", line 828, in ? File "random.pyc", line 95, in __init__ File "random.pyc", line 109, in seed WindowsError: [Errno -2146893795] Provider DLL failed to initialize correctly -- >Comment By: Greg Hazel (ghazel) Date: 2005-12-30 07:06 Message: Logged In: YES user_id=731668 Windows XP, python 2.4.2 Not sure how to reproduce it. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-18 11:00 Message: Logged In: YES user_id=1188172 Could you provide some more information? OS specs, Python version, reproducability etc. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1384175&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
