On Tue, Jun 23, 2020 at 6:58 AM Victor Stinner wrote:
>
> Hi INADA-san,
>
> First of all, thanks for writing down a PEP!
>
> Le jeu. 18 juin 2020 à 11:42, Inada Naoki a écrit :
> > To support legacy Unicode object created by
> > ``PyUnicode_FromUnicode(NULL, length)``, many Unicode APIs has
> > `
Hi Victor,
Thanks for putting work into this. I support the idea of slowly
evolving the C API. It must be done carefully so as to not
unnecessarily break 3rd party extensions. Changes must be made for
well founded reasons and not just because we think it makes a
"cleaner" API. I believe you ar
Hi INADA-san,
First of all, thanks for writing down a PEP!
Le jeu. 18 juin 2020 à 11:42, Inada Naoki a écrit :
> To support legacy Unicode object created by
> ``PyUnicode_FromUnicode(NULL, length)``, many Unicode APIs has
> ``PyUnicode_READY()`` check.
I don't see PyUnicode_READY() removal in t
On 6/22/20, Steve Dower wrote:
>
> What is likely happening here is that _sqlite3.pyd is being imported
> before _mapscript, and so there is already a SQLITE3 module in memory.
> Like Python, Windows will not attempt to import a second module with the
> same name, but will return the original one.
It's still a problem, even if it's a problem in the opposite direction than
you first thought (Python has a newer sqlite, rather than older). Updating
your API fixes the problem now, but you still need to decide how you check
for and handle newer, potentially incompatible library versions.
On Mon,
Thanks Ned.
I did double check the docs for sqlite3 after posting and wondering why the
versions were so different.
I guess the clue should have been the sqlite-3 !
Reading the history of the module I presume sqlite3 has its own module version
number as it was integrated from a separate project
Thanks Steve for the clarifications.
As a workaround placing the older sqlite3.dll in the same folder as the
_mapscript.pyd file while leaving all the other DLLs in a different folder
referenced by add_dll_directory allows for a successful import.
For a less hacky fix - after checking the versi
On Jun 22, 2020, at 05:39, Seth G wrote:
> However, there is one feature of using the Windows PATH that I can't seem to
> replicate with add_dll_directory.
> The MapServer DLL builds are linked to sqlite3 3.24.0, whereas Python 3.8.2
> is linked to 2.6.0. Building with matching versions is not s
On 22Jun2020 1646, Steve Dower wrote:
DLLs should not be in the search path at all - it's searched by sys.path
when importing .pyd files, which are loaded by absolute path and their
dependencies found adjacent.
To clarify this - by "DLLs" I meant the DLLs directory, not DLLs in
general (hence
On 22Jun2020 1039, Seth G wrote:
However, there is one feature of using the Windows PATH that I can't seem to
replicate with add_dll_directory.
The MapServer DLL builds are linked to sqlite3 3.24.0, whereas Python 3.8.2 is
linked to 2.6.0. Building with matching versions is not something I can
Victor Stinner schrieb am 17.06.20 um 13:25:
> Le mer. 17 juin 2020 à 12:38, Petr Viktorin a écrit :
>>> There is an ongoing discussion about always requiring to run Cython
>>> when installing a C extension which uses Cython.
>>
>> Do you have a link to that discussion?
Yeah, I was wondering, too.
Hi list,
I've been trying to get new Python 3.8 builds for the MapServer project - these
are SWIG-generated bindings that require many DLLs to import in Python. Up
until now this worked by adding a folder to the top of the Windows PATH.
I've read through the discussions at https://bugs.python.
Thanks, Victor for awesome PEP
I am a big +1 on this proposal since some of the core developers
already need the evolution of C API.
I believe this proposal is not only for alternative python compiler
implementation but also gives a chance for enhancing CPython
performance.
And I love this proposa
Hi,
PEP available at: https://www.python.org/dev/peps/pep-0620/
This PEP is the result of 4 years of research work on the C API:
https://pythoncapi.readthedocs.io/
It's the third version. The first version (2017) proposed to add a
"new C API" and advised C extensions maintainers to opt-in for i
On Thu., 18 Jun. 2020, 6:06 am Eric Snow,
wrote:
> On Wed, Jun 17, 2020 at 11:42 AM Emily Bowman
> wrote:
> > So most likely there wouldn't be any way to share something like a
> bytearray or another
> > buffer interface-compatible type for some time. That's too bad, I was
> hoping to have
> > s
15 matches
Mail list logo
