Roger Binns added the comment:
I'm the APSW author. The reason why this apparent nonsense is done is due to
using readline and completion. That requires being able to write to standard
input when it is a terminal - something that Windows and Linux are happy to do.
In any event I
Roger Binns added the comment:
Is there any reason it doesn't show the function 'prototype' which is by far
the most the useful piece of information and is also a form of documentation
(plus fairly hard to work out). Convoluted technospeak is far harder to
understand. Comp
Roger Binns added the comment:
Obviously the prototype can't be provided when it isn't known. But the
pseudo-English text is trying to describe the prototype and is far less clear
than the actual prototype. ie the developer communicated the prototype to
Python in Python synta
Roger Binns added the comment:
Thanks for finding this problem. I can repeat it with the patch and am in the
process of fixing it.
--
___
Python tracker
<http://bugs.python.org/issue16
Roger Binns added the comment:
I'm the APSW author. You do not need SQLite installed - APSW's setup can fetch
the current SQLite and use it privately not affecting the rest of the system.
An easier way of testing is:
python3 setup.py fetch --sqlite --version 3.7.14 build_ext
Roger Binns added the comment:
(APSW author here). I haven't ported to the new Python 3.3 Unicode handling
yet but it is on my todo list. The PEPs and doc said the C API would remain
backwards compatible. The APSW code supports Python 2.3 onwards.
SQLite APIs support both UTF-8 and U
Roger Binns added the comment:
Roughly how long will it be before Python 3.3.1 comes out? This issue means my
users will get garbage or crashes, so I'll need to work around it if it will be
quite a while till 3.3.1.
--
___
Python tracker
Roger Binns added the comment:
This issue is highly annoying. The ultimate cause is the msi code using
the StrictVersion class to get the version number. StrictVersion is
documented to be constrained to numerical dot separated versions, and
there doesn't appear to be a way of providing
New submission from Roger Binns <[EMAIL PROTECTED]>:
My extension (apsw) builds and runs just fine on Linux, Mac and Windows
for Python 2.3, 2.4 and 2.5. For Linux and Mac Python 2.6 beta 1 and
Python 3.0 beta 1 also work just fine. However on Windows using MinGW
and Python 2.6 beta
Roger Binns <[EMAIL PROTECTED]> added the comment:
I figured maybe it was something to do with MSVC 90 dlls.
C:\apsw>dir \*msvc*90* /s
Volume in drive C has no label.
Volume Serial Number is F4A5-1661
Directory of C:\MinGW\lib
12/27/2007 08:23 AM 554,136 libmsvcr9
Roger Binns <[EMAIL PROTECTED]> added the comment:
I can't prove it since Python gives no further information than a
procedure cannot be found, but using a bunch of other tools I think this
may be due at least to the use of localtime() and it not being present
in the msvcr90.dll but i
Roger Binns <[EMAIL PROTECTED]> added the comment:
I cleared all event categories, and then ran Python followed by the
import (which fails). No events in any category appeared.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Roger Binns <[EMAIL PROTECTED]> added the comment:
I didn't have a copy of depends.exe since it doesn't appear to come with
MinGW. System is basically VirtualBox VM with fresh install of XP Pro
SP2, upgraded to SP3 and TortoiseSVN, Firefox, Xemacs, MinGW and Python
versions ins
Roger Binns <[EMAIL PROTECTED]> added the comment:
In MinGW's defense the MSVC 7 dll does include localtime. Since
Python/distutils only says that MSVC 9 dll is being used at link time,
how exactly is MinGW (or any other code) supposed to know that localtime
should be provided som
Roger Binns <[EMAIL PROTECTED]> added the comment:
I will ask on the MinGW lists. I am still curious as to how MinGW is
supposed to know which MSVC library will be used at compile time since
distutils doesn't tell it until link time.
As a seperate issue Python isn't too
Roger Binns <[EMAIL PROTECTED]> added the comment:
I guess you can close this now. Unfortunately SourceForge goes out of
its way to not make an easy link for the MinGW mailing list but you can
see the messages on 8th July 2008:
http://sourceforge.net/mailarchive/forum.php?forum_name
Roger Binns added the comment:
So is 3.3.1 with the fix ever going to be released? Georg did predict
mid-November and we are 4 months after that.
--
___
Python tracker
<http://bugs.python.org/issue16
17 matches
Mail list logo
