[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2018-07-05 Thread Pablo Galindo Salgado
Change by Pablo Galindo Salgado : -- Removed message: https://bugs.python.org/msg321110 ___ Python tracker ___ ___ Python-bugs-list

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2018-07-05 Thread Pablo Galindo Salgado
Change by Pablo Galindo Salgado : -- Removed message: https://bugs.python.org/msg32 ___ Python tracker ___ ___ Python-bugs-list

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2018-07-05 Thread Paul Ganssle
Paul Ganssle added the comment: Oops, that previous comment was intended for a completely different ticket. My mistake. -- ___ Python tracker ___

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2018-07-05 Thread Paul Ganssle
Paul Ganssle added the comment: Hmm. I never noticed this. In the past I have used the (undocumented) PyDateTimeAPI struct, which the official macros wrap. I'm not sure how official that struct is considering it doesn't show up in the documentation. I agree that it should be possible to

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2017-04-12 Thread Frank Blankenburg
Changes by Frank Blankenburg : -- nosy: +FrankBlabu ___ Python tracker ___ ___

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2017-03-15 Thread Nathan Jensen
Changes by Nathan Jensen : -- nosy: +Nathan Jensen ___ Python tracker ___ ___

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2017-02-01 Thread Nick Coghlan
Nick Coghlan added the comment: I've added Steve Dower to the nosy list, as he's done some work recently on making the Windows builds more embedding-friendly, and I believe at least some of that time may have been funded work. Unfortunately, we don't currently have anyone I'm aware of that's

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2017-02-01 Thread Christopher Schramm
Christopher Schramm added the comment: This issue should have a much higher priority as it basically breaks Python embedding unless the user either does not re-initialize the interpreter or avoid the use of _datetime.strptime. We're currently testing with a patch based on Christian and

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2017-01-31 Thread Christopher Schramm
Changes by Christopher Schramm : -- nosy: +cschramm ___ Python tracker ___ ___

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2017-01-16 Thread Denny Weinberg
Denny Weinberg added the comment: Any news here? 3.6.0 is also affected by this bug. -- ___ Python tracker ___

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2016-12-15 Thread Chi Hsuan Yen
Changes by Chi Hsuan Yen : -- nosy: +Chi Hsuan Yen ___ Python tracker ___ ___

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2016-09-21 Thread Jim Jewett
Jim Jewett added the comment: Having to (re-)fill the cache once per interpreter seems like a reasonable price to pay. Why is 3.5 not included? Did this not cause problems before the import change, or is it just that this bug is small enough that maybe it isn't worth backporting?

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2016-09-15 Thread Christian Heimes
Christian Heimes added the comment: Wouldn't it clear strptime_module when a subinterpreter shuts down, too? It's not a big deal because it can't cause a crash. -- ___ Python tracker

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2016-09-15 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: Yes, I think something like the attached patch may do the trick. -- assignee: -> belopolsky keywords: +patch versions: +Python 3.6, Python 3.7 -Python 3.5 Added file: http://bugs.python.org/file44678/issue27400.patch

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2016-09-15 Thread Christian Heimes
Christian Heimes added the comment: PEP 3121 is a big change. Can we use PyModuleDef->m_clear() for a clever hack? -- nosy: +christian.heimes ___ Python tracker

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2016-09-15 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: I am not sure this is possible to fix without refactoring the datetime module according to PEP 3121. See #15390. -- ___ Python tracker

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2016-09-15 Thread Josh Rosenberg
Josh Rosenberg added the comment: Hmm... On checking down some of the code paths and realizing there were some issues in 3.5 (redundant code, and what looked like two memory leaks), I checked tip (to avoid opening bugs on stale code), and discovered that #22557 rewrote the import code,

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2016-09-15 Thread Josh Rosenberg
Josh Rosenberg added the comment: Nick: Looks like it's quite a bit more work than just a dict lookup. That PyImport_ImportModuleNoBlock call (which seems odd; the implementation of NoBlock is just to wrap the blocking function; guess we don't allow non-blocking imports anymore and this is

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2016-09-15 Thread Roman Evstifeev
Changes by Roman Evstifeev : -- nosy: +Roman.Evstifeev ___ Python tracker ___ ___

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2016-07-06 Thread Nick Coghlan
Nick Coghlan added the comment: Aye, skipping the caching entirely would be an even simpler solution - the only thing it is saving in the typical case is a dictionary lookup in the modules cache. -- ___ Python tracker

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2016-07-06 Thread Ammar Askar
Ammar Askar added the comment: Is there any particular reason that datetime.strptime caches the imported module like that? >From a quick search, these two other examples don't bother with any caching:

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2016-07-02 Thread Nick Coghlan
Nick Coghlan added the comment: Thanks for the report Denny. Looking at https://hg.python.org/cpython/file/30099abdb3a4/Modules/datetimemodule.c#l3929, there's a problematic caching of the "_strptime" module that is almost certainly the cause of the problem - it will attempt to call

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2016-06-27 Thread Denny Weinberg
Denny Weinberg added the comment: Just to be clear: The error happens after these steps: 1. Call strptime 2. Call cpython function "Py_Finalize" and "Py_Initialize" 3. Call strptime again Now we get the error "attribute of type 'NoneType' is not callable" --

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2016-06-27 Thread Denny Weinberg
New submission from Denny Weinberg: After calling Py_Finalize and Py_Initialize I get the message "attribute of type 'NoneType' is not callable" on the datetime.strptime method. Example: from datetime import datetime s = '20160505 16' refdatim = datetime.strptime(s, '%Y%m%d %H%M%S') The