On Thu, Oct 19, 2017 at 9:10 PM, TazMainiac <tazmain...@gmail.com> wrote: > > > On Thu, Oct 19, 2017 at 2:25 PM, Jonathan Vanasco <jonat...@findmeon.com> > wrote: >> >> On Thursday, October 19, 2017 at 11:55:49 AM UTC-4, Taz Mainiac wrote: >>> >>> So - a morning spent googling does not turn up any information about >>> Python classes having a different id depending on context (script vs >>> module). I'm probably not googling for the right thing? Can anyone point >>> me to information? >>> >> >> The Python classes have a different id on each run not because of the >> context (script vs module), but because they are run in different processes. >> The "id" , like the object, is only local to the process. >> >> The attributes of your custom enum class are instances of enum objects. >> which have attributes like name and value. > > > I understand this. The id is the address of the object under CPython (so it > says in the docs). > >> If you ran two scripts or two modules, it would also almost always fail >> (IIRC, it is remotely possible but highly unlikely, to generate the same id >> in another process). > > > I am not doing that. > >> >> You should be storing/comparing the enum's 'name' or 'value' attributes -- >> not the enum object itself. The enum object will always be different. > > > I'm following the established documentation on how to use an enum with > SQLAlchemy (with Postgres DB backend) - almost exactly as described in the > doc under the Enum type: > > http://docs.sqlalchemy.org/en/rel_1_1/core/type_basics.html > > (except I'm using declarative style). > > The problem is apparently that the enumerated type gets a different id > depending on the context in which it is used (from a script vs from a module > import). This is very surprising to me, and I have not seen anything like > it before (hence my question above asking for any references to this > behavior). > > In any case, this causes SQL Alchemy to not recognize that the enumerated > value assigned to a field (in another file) is not the same type as what is > expected. Clearly the ' is ' relationship is failing (since the id's are > different). > > So - need to reorganize code a bit to avoid this... > > Taz
This is a subtle python gotcha based on how the import system works. It doesn't have anything to do with SQLAlchemy. <http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html#executing-the-main-module-twice> When you import a module, it gets cached in sys.modules under its "fully qualified module name", so it doesn't matter how many times you run "import foo", the module is only loaded once. However, the script that you initially *execute* gets the special name "__main__". If it gets subsequently imported via an "import" statement, it is not found in the cache, so it is executed again, meaning you get duplicate definitions of everything in the module. Hope that helps, Simon -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
