No Appropriate Import Module Found 3ds Max

[Kylee Mccandrew]

Thestatement from calc import ... will not work because it tries to use an implicit relative import which is no longer supported by Python (it was removed for being ambiguous and the cause of common problems).

If planet.py was found by an import, then it knows it is in a package.

If you invoke planet.py directly, I believe it does not consider it

part of a package, and therefore the relative import path .calc would

not work.

My only question remaining is, when I run poetry build I see only files inside src are taking. In other words, only files inside src folder get uploaded to PyPi which I guess it means that someone trying to download from there this package would get something broken (calc.py missing as shown below). Is this correct?

Not quite; what @cameron means is that it presumes calc.py is a top-level module inside your src directory, from which it is presumed that your modules/import packages are installed or is visible to Python (via one of many possible ways). I.e.

Hello, I am having issues launching my first web app using Flask. I believe I properly setup (manually) the web app using python 3.7, entered the proper directories for my virtualenv and my flask app.

I have also verified that the modules were installed in the correct virtualenv directory with the proper python version (3.7). I also checked while inside my virtualenv directory that my pip -V is also 3.7 and checked if there are any accidental pymongo module installed using pip2.7 as well. The only pymongo installed using pip2.7 is done locally and not in my web app virtualenv directory (not sure if that affects anything but I'm guess no). I'm totally stuck here and any help would be greatly appreciated.

On a different problem... I ran my flask app using python3.7 and it gave me another error with another module (flask_mail)! sigh... Am I doing something wrong? I read the link provided to me thoroughly. The flask_mail.py file is in my virtualenv folder (not in it's own folder though) so I assume "import flask_mail" should work?

It looks like you've got a lot of things you need to install -- for example dnspython -- and it will probably take a while to track them down. A better option might be to use a requirements file. I'm guessing that you created the site locally or somewhere else, and are now trying to deploy it on PythonAnywhere. Is that right? If so, did you use a virtualenv for the original setup? Or do you happen to have a requirements.txt file that you created?

Also -- if you're connecting to a Mongo instance from inside PythonAnywhere, you'll need a paid account -- free accounts only have restricted Internet access, and can't use MongoDB's protocol to connect outwards.

Yes, I have noticed i posted my password for mongodb :x I changed it like 10 seconds after I posted all the pictures lol. And yes, I have created my web app locally and as this is my first project, I did the grave mistake of installing all my packages/modules in the main python folder (not using virtualenv).

Nvm. I am still stuck with the same issue. My website was able to launch BUT only a few installed modules CANNOT be imported/used. I do not understand why. The rest of the modules work. To be specific...

Once you've set up a website on the "Web" page, your site is up and running. There's no need to run it from anywhere else -- either from a console or from the editor. It will be started up as soon as you set it up, and restarted when you reload it. Sometimes it might be shut down due to system maintenance, but it will always start up again automatically as soon as it receives a hit. If there are problems with the site, you can see the error stacktraces in the error log, which is linked from the "Web" page. The most recent error will be at the bottom.

Now, as to how this explains the errors you're getting when you run it (I think unnecessarily) from the editor -- because you could have multiple websites, each of which used a different virtualenv, the save and run button in the editor does not try to run it in any virtualenv -- it just doesn't know which one it should pick for the specific file you have open. So, it runs it outside the env -- hence the error message.

If you do need to run the website's code from the editor, perhaps for debugging purposes, then you can do so by clicking the "Bash console here" button that appears at the bottom of the file when it is freshly opened, and then using workon to access your virtualenv, and then python /path/to/script.py.

Ah, that makes total sense. I guess I was just concerned when I saw that after running into this issue "POST 500 (INTERNAL SERVER ERROR)" (as shown in chrome dev tool) while I tried to use my login/create user/other features that requires access to MongoDB Atlas. The picture below will show the error logs. I'm not sure if it has to do anything with connecting to MongoDB Atlas or not? The reason I am concerned is because I am also hosting locally and it works like a charm but hosting on Pythonanywhere, this problem occurs.

Here is my MongoDB Atlas setup as I found in other forum posts. Let me know if this is correct or not. If this is not a Pythonanywhere issue, let me know so I will direct my questions to stack overflow.

I'd certainly read that as an error connecting to MongoDB, yes. I see you've got all of the right stuff from our MongoDB help page in your connection code, so that all looks good to me. Is there some kind of IP whitelisting you need to do for your Mongo instance?

Yes, I realized I need to whitelist Pythonanywhere but I cannot locate my webapp's ip address anywhere. Any idea how to access that or other ways to whitelist? MongoDB accepts IP Address or CIDR Notation.

Right now we don't many any guarantees about the IP address you'll be using, apart from it being within the list of AWS addresses (which is a huge set of CIDRs and changes frequently -- not something you could usefully whitelist!).

If a module is already loaded then it won't be loaded again. you will just get a reference to it. If you don't plan to use this class locally and just want to satisfy the typehinter then you can do the following

The most pythonic way to import something is to do so at the beginning of file. Unless you have special needs, like import different modules depending on some condition, eg. platform (windows, linux).

I did make functions named spam and eggs in their appropriate modules. Naturally, it didn't work. The answer is apparently in the 4th URL I listed, but it's all alumni to me. There was this response on one of the URLs I visited:

Relative imports use a module's name attribute to determine that module's position in the package hierarchy. If the module's name does not contain any package information (e.g. it is set to 'main') then relative imports are resolved as if the module were a top level module, regardless of where the module is actually located on the file system.

Here's an explanation. The short version is that there is a big difference between directly running a Python file, and importing that file from somewhere else. Just knowing what directory a file is in does not determine what package Python thinks it is in. That depends, additionally, on how you load the file into Python (by running or by importing).

There are two ways to load a Python file: as the top-level script, or as amodule. A file is loaded as the top-level script if you execute it directly, for instance by typing python myfile.py on the command line. It is loaded as a module when an import statement is encountered inside some other file. There can only be one top-level script at a time; the top-level script is the Python file you ran to start things off.

When a file is loaded, it is given a name (which is stored in its __name__ attribute). If it was loaded as the top-level script, its name is __main__. If it was loaded as a module, its name is the filename, preceded by the names of any packages/subpackages of which it is a part, separated by dots.

if you imported moduleX (note: imported, not directly executed), its name would be package.subpackage1.moduleX. If you imported moduleA, its name would be package.moduleA. However, if you directly run moduleX from the command line, its name will instead be __main__, and if you directly run moduleA from the command line, its name will be __main__. When a module is run as the top-level script, it loses its normal name and its name is instead __main__.

There is an additional wrinkle: the module's name depends on whether it was imported "directly" from the directory it is in or imported via a package. This only makes a difference if you run Python in a directory, and try to import a file in that same directory (or a subdirectory of it). For instance, if you start the Python interpreter in the directory package/subpackage1 and then do import moduleX, the name of moduleX will just be moduleX, and not package.subpackage1.moduleX. This is because Python adds the current directory to its search path when the interpreter is entered interactively; if it finds the to-be-imported module in the current directory, it will not know that that directory is part of a package, and the package information will not become part of the module's name.

Now here is the crucial thing for your error message: if a module's name has no dots, it is not considered to be part of a package. It doesn't matter where the file actually is on disk. All that matters is what its name is, and its name depends on how you loaded it.

Relative imports use a module's name attribute to determine that module's position in the package hierarchy. If the module's name does not contain any package information (e.g. it is set to 'main') then relative imports are resolved as if the module were a top-level module, regardless of where the module is actually located on the file system.

Relative imports use the module's name to determine where it is in a package. When you use a relative import like from .. import foo, the dots indicate to step up some number of levels in the package hierarchy. For instance, if your current module's name is package.subpackage1.moduleX, then ..moduleA would mean package.moduleA. For a from .. import to work, the module's name must have at least as many dots as there are in the import statement.

3a8082e126