mirror of
https://github.com/spotipy-dev/spotipy.git
synced 2026-04-26 16:15:51 +03:00
[GH-ISSUE #621] Garbage collection sets requests.Session to None before __del__ is called (TypeError) #370
Labels
No labels
api-bug
bug
dependencies
documentation
duplicate
enhancement
external-ide
headless-mode
implicit-grant-flow
invalid
missing-endpoint
pr-welcome
private-api
pull-request
question
spotipy3
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/spotipy#370
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @RobinReborn on GitHub (Dec 3, 2020).
Original GitHub issue: https://github.com/spotipy-dev/spotipy/issues/621
Describe the bug
Exception raised after Django migration, ie
python manage.py migratewithin a pipenvYour code
I can share my django models and migrations and Pipfile if necessary
Expected behavior
A clear and concise description of what you expected to happen.
Output
Exception ignored in: <function Spotify.__del__ at 0x7fb96d7d4680> Traceback (most recent call last): File "/home/robin/.virtualenvs/moodstream-django-EtsEGWRm/lib/python3.7/site-packages/spotipy/client.py", line 188, in __del__ TypeError: isinstance() arg 2 must be a type or tuple of types Exception ignored in: <function SpotifyAuthBase.__del__ at 0x7fb96d8088c0> Traceback (most recent call last): File "/home/robin/.virtualenvs/moodstream-django-EtsEGWRm/lib/python3.7/site-packages/spotipy/oauth2.py", line 136, in __del__ TypeError: isinstance() arg 2 must be a type or tuple of typesEnvironment:
Additional context
Add any other context about the problem here.
@stephanebruckert commented on GitHub (Dec 8, 2020):
I cannot think of anything obvious, it would be useful to get a bit more context:
__del__yourself?@menef0124 commented on GitHub (Jun 30, 2021):
I also get the same exact exceptions raised just from having the line
import flaskin one of my scripts. I haven't actually written anything using Flask yet and the script works fine but the exceptions still occur.@succinct commented on GitHub (Mar 20, 2022):
I'm seeing this same issue when I compile to an executable via nuitka, e.g.:
python -m nuitka --follow-imports --standalone program.pyThe exact same program.py throws no errors when I run it normally, but once it's migrated to an executable I get the following errors which essentially mirror the above description:
This is with Python 2.10.3 and Spotipy 2.19.0 on Windows 10
@zlonghofer commented on GitHub (Mar 2, 2025):
@stephanebruckert I'm experiencing this in a simple Python script.
Specifically, when I save the above block of code to test.py, I run the following commands in Powershell using Python 3.13.0 and Spotipy 2.25.1:
py test.pyresults in no error message.py -i test.pyfollowed immediately byquit()results in the error message shown above.This is likely due to the garbage collection mechanism differences in an interactive session.
Spotipy.__del__references the module variablerequests.Sessionafter it has been deleted by the Python interpreter during cleanup. It is likely that differences in cleanup order from the compiled executable and the django migration.Since
requests.Sessionhas already been deleted, itstypeis<NoneType>, which throws the error.Unfortunately, the same cleanup mechanism is also present in
SpotifyOAuth.__del__(and quite probably in other locations throughout the codebase). Comprehensive resolution of this issue would probably require checking the__del__methods on each object throughout the codebase and adding a check that therequests.Sessionmodule-level import hasn't yet been deleted.@dieser-niko commented on GitHub (Mar 3, 2025):
Finally something to reproduce this bug. But yes, I have to agree, it's probably Python's garbage collector. The easiest fix would be to just catch the
TypeErrorlike we're already doing with theAttributeError.Alternatively, we could just "rescue" the
requests.Sessionobject by storing it as a variable or something.Oddly enough, I had to install Python 3.13.0 to get this error. By default I have 3.12.6 installed, where I didn't get the error.
Also, it's possible to minimize the script even more:
@zlonghofer commented on GitHub (Mar 3, 2025):
Wouldn't "rescuing" the
requests.Sessionobject be cleaner?resolves both the
AttributeErrorand theTypeErrorrelying on Python's short-circuiting. If we're checking that the_sessionattribute exists, the Pythonic way to do this is withgetattr.@dieser-niko commented on GitHub (Mar 3, 2025):
I guess that would be one way to do it. Relying on catching errors isn't really a good idea if there are other alternatives IMO.