Re: Transistion from module to package and __init__.py
Chris Nyland wrote at 2021-5-4 22:20 -0400: > ... >So for a while now I have taken to converting >my module, in this example database.py, to the __init__.py of the package. >I remember reading years back that having code in the __init__.py was bad >practice but I can't remember reading for any specific reason. If your package is not a so called "namespace package" (this is a package components of which are stored in different places and can be installed independent from one another), then I see no reason not to put code into `__init__.py`. When I transform a module into a package, I start by using the former module as the new package's `__init__.py`. Later refactoring steps may move things out into separate modules/subpackages. -- https://mail.python.org/mailman/listinfo/python-list
Re: Transistion from module to package and __init__.py
On 5/4/21 7:20 PM, Chris Nyland wrote: > Here is > where I my primary design question comes in. As organized now as described > to import and use the package I need > > from database import database > > or I have to put in the init file > > from database import * > > Either of these still leaves a database.database namespace laying about and > to me it just seems untidy. So for a while now I have taken to converting > my module, in this example database.py, to the __init__.py of the package. > So I was hoping to get > feed back from a wider audience about if there are any issues with this > type of design that I just haven't encounter yet or find out what other > people do with this same problem. This is the same method I use, and it works fine for smaller packages. I do have one package, dbf, that I am in the process of converting to multiple files simply because there is so much (10k lines for me, YMMV). -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Transistion from module to package and __init__.py
Hello, I have a design question that for me primarily occurs when I have a module that needs to transition to a package. Lets assume I have module that services a database. Initially the module just has some functions to pull data out of the database format them etc. As the project grows I add tables some of the tables have static data or initialization data that are stored in CSVs. I build functions that initialize the database a schema file is now used. Now my module is still the only Python code file I have but I have these other data files the module needs, time to make a package. So naturally I make a package folder called database, put and empty __init__.py, in goes my database module and all resource files. Here is where I my primary design question comes in. As organized now as described to import and use the package I need from database import database or I have to put in the init file from database import * Either of these still leaves a database.database namespace laying about and to me it just seems untidy. So for a while now I have taken to converting my module, in this example database.py, to the __init__.py of the package. I remember reading years back that having code in the __init__.py was bad practice but I can't remember reading for any specific reason. So then I ask is there anything in fact wrong with this practice? I have probably a dozen packages now that are used internal to my organization that follow this pattern and I haven't encountered any issues. So I was hoping to get feed back from a wider audience about if there are any issues with this type of design that I just haven't encounter yet or find out what other people do with this same problem. Thanks Chris -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not being able to call modules from lib folder into test folder although I have __init__.py file both?
On 26/04/19 11:14 AM, dieter wrote: Arup Rakshit writes: I am not able to call modules from lib folder in my test folder, but outside of tests folder I can access them. How should I fix this? Mocks$ tree . . ├── lib │ ├── __init__.py │ ├── __pycache__ │ │ ├── __init__.cpython-37.pyc │ │ └── product.cpython-37.pyc │ └── product.py └── tests ├── __init__.py └── product_test.py 3 directories, 6 files Mocks$ python3 ... from lib.product import ProductionKlass ... ProductionKlass() ... Mocks$ python3 tests/product_test.py Traceback (most recent call last): File "tests/product_test.py", line 4, in from lib.product import ProductionKlass ModuleNotFoundError: No module named 'lib' Python's import is controlled by "sys.path" -- typically a sequence of folders where Python should look for modules/packages to import. When you start a Python script, it puts the folder containing the script automatically on "sys.path" (to facilitate imports by this script). When you start Python interactively, it puts the current working directory on "sys.path". These differences explain your observations. In the first case, "lib" can be imported because the current working directory has been put on "sys.path". In the second case, "lib" cannot be imported because the subfolder "tests" has been put on "sys.path" (not the current working directory itself). A modern approach to avoid such situations looks like: * make your project into a package (see "https://packaging.python.org/";) * use either package relative imports or absolute imports with the package as prefix to access modules in your package * install your package into a Python installation (use "virtualenv" to get a light weight local Python installation, if necessary) * have tiny script wrappers for scripts in your package. Packageing tools (such as "setuptools" --> "https://setuptools.readthedocs.io/en/latest/";) can create thoses wrappers for you on installation. Thanks for explaining this. I read this and couple of internet blogs on this, one of them is https://alex.dzyoba.com/blog/python-import/ . I get it. -- Thanks, Arup Rakshit -- https://mail.python.org/mailman/listinfo/python-list
Re: Why not being able to call modules from lib folder into test folder although I have __init__.py file both?
Arup Rakshit writes: > I am not able to call modules from lib folder in my test folder, but outside > of tests folder I can access them. How should I fix this? > > Mocks$ tree . > . > ├── lib > │ ├── __init__.py > │ ├── __pycache__ > │ │ ├── __init__.cpython-37.pyc > │ │ └── product.cpython-37.pyc > │ └── product.py > └── tests > ├── __init__.py > └── product_test.py > > 3 directories, 6 files > Mocks$ python3 > ... >>>> from lib.product import ProductionKlass > ... >>>> ProductionKlass() > > ... > Mocks$ python3 tests/product_test.py > Traceback (most recent call last): > File "tests/product_test.py", line 4, in > from lib.product import ProductionKlass > ModuleNotFoundError: No module named 'lib' Python's import is controlled by "sys.path" -- typically a sequence of folders where Python should look for modules/packages to import. When you start a Python script, it puts the folder containing the script automatically on "sys.path" (to facilitate imports by this script). When you start Python interactively, it puts the current working directory on "sys.path". These differences explain your observations. In the first case, "lib" can be imported because the current working directory has been put on "sys.path". In the second case, "lib" cannot be imported because the subfolder "tests" has been put on "sys.path" (not the current working directory itself). A modern approach to avoid such situations looks like: * make your project into a package (see "https://packaging.python.org/";) * use either package relative imports or absolute imports with the package as prefix to access modules in your package * install your package into a Python installation (use "virtualenv" to get a light weight local Python installation, if necessary) * have tiny script wrappers for scripts in your package. Packageing tools (such as "setuptools" --> "https://setuptools.readthedocs.io/en/latest/";) can create thoses wrappers for you on installation. -- https://mail.python.org/mailman/listinfo/python-list
Why not being able to call modules from lib folder into test folder although I have __init__.py file both?
I am not able to call modules from lib folder in my test folder, but outside of tests folder I can access them. How should I fix this? Mocks$ tree . . ├── lib │ ├── __init__.py │ ├── __pycache__ │ │ ├── __init__.cpython-37.pyc │ │ └── product.cpython-37.pyc │ └── product.py └── tests ├── __init__.py └── product_test.py 3 directories, 6 files Mocks$ python3 Python 3.7.3 (default, Mar 27 2019, 09:23:15) [Clang 10.0.1 (clang-1001.0.46.3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from lib.product import ProductionKlass >>> ProductionKlass() >>> exit() Mocks$ python3 tests/product_test.py Traceback (most recent call last): File "tests/product_test.py", line 4, in from lib.product import ProductionKlass ModuleNotFoundError: No module named 'lib' Mocks$ The file product_test.py has content like: from unittest import mock import unittest from lib.product import ProductionKlass class TesProductKlass(unittest.TestCase): def setUp(self): self.real = ProductionKlass() self.real.something = mock.MagicMock() def test_method(self): self.real.method() self.real.something.assert_called_once_with(1, 2, 3) if __file__ == "__main__": unittest.main() Thanks, Arup Rakshit a...@zeit.io -- https://mail.python.org/mailman/listinfo/python-list
Re: Using __init__.py
https://www.youtube.com/watch?v=pNe1wWeaHOU&list=PLYI8318YYdkCsZ7dsYV01n6TZhXA6Wf9i&index=1 Thank you, -Alex Goretoy http://launchpad.net/~a1g On Wed, Sep 6, 2017 at 6:42 PM, Steve D'Aprano wrote: > On Wed, 6 Sep 2017 07:30 pm, Kryptxy wrote: > >> I am working on a (cross-platform) project. On linux system, the imprts work >> fine, but in windows I get imort error (I have no idea why. I tried searching >> everywhere, but couldn't get it to work). Anyways, the issue seem to be >> resolved by adding project directory to sys.path(). >> >> I wanted to know that can I use __init__.py file for adding a project >> directory to sys.path (sys.path.insert(0, directory))? > > That is the wrong way to fix this problem. It might work, for a little while, > but then something will change, or you will do something just a tiny bit > different, and it will break again. > > The first step is to debug why you are getting the import error. You cannot > fix > a problem until you know what it is: what you fix by accident will break by > accident. > > Start by telling us the full path to your project directory, and the full > contents of sys.path. > > Do not try to retype them from memory. Accuracy is essential: copy and paste > the > paths so that they are accurate. > > > Thank you. > > > > -- > Steve > “Cheer up,” they said, “things could be worse.” So I cheered up, and sure > enough, things got worse. > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Using __init__.py
On Wed, 6 Sep 2017 07:30 pm, Kryptxy wrote: > I am working on a (cross-platform) project. On linux system, the imprts work > fine, but in windows I get imort error (I have no idea why. I tried searching > everywhere, but couldn't get it to work). Anyways, the issue seem to be > resolved by adding project directory to sys.path(). > > I wanted to know that can I use __init__.py file for adding a project > directory to sys.path (sys.path.insert(0, directory))? That is the wrong way to fix this problem. It might work, for a little while, but then something will change, or you will do something just a tiny bit different, and it will break again. The first step is to debug why you are getting the import error. You cannot fix a problem until you know what it is: what you fix by accident will break by accident. Start by telling us the full path to your project directory, and the full contents of sys.path. Do not try to retype them from memory. Accuracy is essential: copy and paste the paths so that they are accurate. Thank you. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Using __init__.py
I am working on a (cross-platform) project. On linux system, the imprts work fine, but in windows I get imort error (I have no idea why. I tried searching everywhere, but couldn't get it to work). Anyways, the issue seem to be resolved by adding project directory to sys.path(). I wanted to know that can I use __init__.py file for adding a project directory to sys.path (sys.path.insert(0, directory))? -- https://mail.python.org/mailman/listinfo/python-list
Re: How to import all things defined the files in a module directory in __init__.py?
On Sat, Sep 24, 2016 at 9:32 PM, Brendan Abel <007bren...@gmail.com> wrote: >> Splitting it up would make it slower to load. > > It's usually the opposite. When packages are split up, you only have to > load the specific portions you need. Putting it all in a single module > forces you to always load everything. This can be true ONLY if they're sufficiently separate that most users can pick and choose. If the bulk of users are going to need every piece, the split will slow it down significantly. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to import all things defined the files in a module directory in __init__.py?
> Splitting it up would make it slower to load. It's usually the opposite. When packages are split up, you only have to load the specific portions you need. Putting it all in a single module forces you to always load everything. On Fri, Sep 23, 2016 at 11:59 PM, Lawrence D’Oliveiro < lawrenced...@gmail.com> wrote: > On Saturday, September 24, 2016 at 2:11:09 PM UTC+12, Chris Angelico wrote: > > It's a large and complex module, and about at the boundary of being > > broken up a bit. > > Splitting it up would make it slower to load. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: How to import all things defined the files in a module directory in __init__.py?
On Sat, 24 Sep 2016 04:59 pm, Lawrence D’Oliveiro wrote: > On Saturday, September 24, 2016 at 2:11:09 PM UTC+12, Chris Angelico > wrote: >> It's a large and complex module, and about at the boundary of being >> broken up a bit. > > Splitting it up would make it slower to load. Would it? You've bench marked it and found that it makes a significant difference? In any case, you're missing the point. Size carries its own cost to the human reader, never mind whether or not the interpreter can deal with it: https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two The decimal module is approaching a size where it is no longer comfortable to read or edit: - 6450 lines in the source file (include comments, blanks, etc); - 27 top-level functions; - 54 global variables/constants; - 19 classes, which isn't too bad on its own, but: - one of those classes has 83 methods; - and another has 127 methods; - the Decimal class itself is 3311 lines alone; excluding blanks, comments and docstrings, it is 2013 SLOC. This a partly a matter of taste, and to my taste, the decimal module is about as big as I would like to see a module before I split it into submodules purely on the basis of size. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to import all things defined the files in a module directory in __init__.py?
On Saturday, September 24, 2016 at 2:11:09 PM UTC+12, Chris Angelico wrote: > It's a large and complex module, and about at the boundary of being > broken up a bit. Splitting it up would make it slower to load. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to import all things defined the files in a module directory in __init__.py?
On Sat, Sep 24, 2016 at 11:42 AM, Lawrence D’Oliveiro wrote: > On Friday, September 23, 2016 at 4:25:21 AM UTC+12, Chris Angelico wrote: >> For reference, the Decimal module (ignoring the C accelerator) is over six >> thousand lines of code, as a single module. Now, that might be pushing the >> boundaries a bit ... > > What “boundaries” do you think that might be pushing? 6000 lines doesn’t > sound unreasonable to me at all. It's a large and complex module, and about at the boundary of being broken up a bit. So it's likely to be the largest file in the stdlib (not counting tests). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to import all things defined the files in a module directory in __init__.py?
On Friday, September 23, 2016 at 4:25:21 AM UTC+12, Chris Angelico wrote: > For reference, the Decimal module (ignoring the C accelerator) is over six > thousand lines of code, as a single module. Now, that might be pushing the > boundaries a bit ... What “boundaries” do you think that might be pushing? 6000 lines doesn’t sound unreasonable to me at all. -- https://mail.python.org/mailman/listinfo/python-list
Automated refactoring tools (was: How to import all things defined the files in a module directory in __init__.py?)
Peng Yu writes: > Is there such a good automated tool for python refactoring? This sounds like a job for — Bicycle Repair Man! Watch him extract jumbled code into well ordered classes. Gasp, as he renames all occurrences of a method. Thank You Bicycle Repair Man! http://bicyclerepair.sourceforge.net/> There is also Rope https://pypi.python.org/pypi/rope> which is a library used in numerous programming environments, including Emacs https://pypi.python.org/pypi/ropemacs>. -- \ “I just got out of the hospital; I was in a speed-reading | `\ accident. I hit a bookmark and flew across the room.” —Steven | _o__) Wright | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: How to import all things defined the files in a module directory in __init__.py?
On Thu, Sep 22, 2016 at 8:35 PM, Ben Finney wrote: > Peng Yu writes: > >> On Wed, Sep 21, 2016 at 11:14 PM, Ben Finney >> wrote: >> > [Importing ‘*’ from a module] will also make the names in the code >> > impossible to automatically match against where they came from. >> > Explicit is better than implicit; you are proposing to make an >> > unknown horde of names in the code implicit and untraceable. >> >> This will make refactoring easy. If everything is explicit, when one >> do refactoring, at two places need to be changed which can be a >> burden. > > That's completely backward: Importing ‘*’ from the module makes > refactoring significantly *more* difficult. > > With explicit ‘import foo; foo.lorem()’, an automated tool can know that > when ‘lorem’ changes to a different name, this module's use of > ‘foo.lorem’ should also change. Is there such a good automated tool for python refactoring? > With non-explicit ‘from foo import *; lorem()’, then an automated too > has *no way* of knowing that ‘lorem’ should change when you alter that > name in the ‘foo’ module. > > So no, what you say above is the opposite of correct. Instead, using > star import makes a rename *more* difficult to do correctly. > > -- > \ “Faith is generally nothing more than the permission religious | > `\ people give to one another to believe things strongly without | > _o__) evidence.” —Sam Harris, _Letter to a Christian Nation_ 2006 | > Ben Finney > > -- > https://mail.python.org/mailman/listinfo/python-list -- Regards, Peng -- https://mail.python.org/mailman/listinfo/python-list
Re: How to import all things defined the files in a module directory in __init__.py?
Peng Yu writes: > On Wed, Sep 21, 2016 at 11:14 PM, Ben Finney > wrote: > > [Importing ‘*’ from a module] will also make the names in the code > > impossible to automatically match against where they came from. > > Explicit is better than implicit; you are proposing to make an > > unknown horde of names in the code implicit and untraceable. > > This will make refactoring easy. If everything is explicit, when one > do refactoring, at two places need to be changed which can be a > burden. That's completely backward: Importing ‘*’ from the module makes refactoring significantly *more* difficult. With explicit ‘import foo; foo.lorem()’, an automated tool can know that when ‘lorem’ changes to a different name, this module's use of ‘foo.lorem’ should also change. With non-explicit ‘from foo import *; lorem()’, then an automated too has *no way* of knowing that ‘lorem’ should change when you alter that name in the ‘foo’ module. So no, what you say above is the opposite of correct. Instead, using star import makes a rename *more* difficult to do correctly. -- \ “Faith is generally nothing more than the permission religious | `\ people give to one another to believe things strongly without | _o__) evidence.” —Sam Harris, _Letter to a Christian Nation_ 2006 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: How to import all things defined the files in a module directory in __init__.py?
On Fri, Sep 23, 2016 at 1:50 AM, Peng Yu wrote: > > This will make refactoring easy. If everything is explicit, when one > do refactoring, at two places need to be changed which can be a > burden. So you want it to be easy to move stuff around between files in a package? Sounds like you don't actually have a package at all - you have a single module that you're splitting across several files. How big would this file be if you simply put it all into one .py file and got rid of the package altogether? For reference, the Decimal module (ignoring the C accelerator) is over six thousand lines of code, as a single module. Now, that might be pushing the boundaries a bit, but certainly there's no reason to split a file that's under a thousand lines of code. Just keep it all in one file, and organize it using marker comments - that way, there's no API change as you reorder stuff. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to import all things defined the files in a module directory in __init__.py?
On Wed, Sep 21, 2016 at 11:14 PM, Ben Finney wrote: > Peng Yu writes: > >> I want to import all the thing (or the ones available in the >> respective __all__) defined in each of the file by putting the >> following lines in __init__.py >> >> from file1 import * >> >> from filen import * >> >> However, I don't want to hardcode the file names in __init__.py. Is >> there an automatic way of doing it? > > Why do you want to do that? It will defeat static analysis of the code, > which is one of the more important tools to make your code reliable. > > It will also make the names in the code impossible to automatically > match against where they came from. Explicit is better than implicit; > you are proposing to make an unknown horde of names in the code implicit > and untraceable. > > Why? What problem are you trying to solve that you believe needs this > approach? This will make refactoring easy. If everything is explicit, when one do refactoring, at two places need to be changed which can be a burden. -- Regards, Peng -- https://mail.python.org/mailman/listinfo/python-list
Re: How to import all things defined the files in a module directory in __init__.py?
Peng Yu writes: > I want to import all the thing (or the ones available in the > respective __all__) defined in each of the file by putting the > following lines in __init__.py > > from file1 import * > > from filen import * > > However, I don't want to hardcode the file names in __init__.py. Is > there an automatic way of doing it? Why do you want to do that? It will defeat static analysis of the code, which is one of the more important tools to make your code reliable. It will also make the names in the code impossible to automatically match against where they came from. Explicit is better than implicit; you are proposing to make an unknown horde of names in the code implicit and untraceable. Why? What problem are you trying to solve that you believe needs this approach? -- \ “Anything that we scientists can do to weaken the hold of | `\religion should be done and may in the end be our greatest | _o__) contribution to civilization.” —Steven Weinberg | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
How to import all things defined the files in a module directory in __init__.py?
Hi, Suppose that I have file1.py, ..., filen.py in a module directory. I want to import all the thing (or the ones available in the respective __all__) defined in each of the file by putting the following lines in __init__.py from file1 import * from filen import * However, I don't want to hardcode the file names in __init__.py. Is there an automatic way of doing it? -- Regards, Peng -- https://mail.python.org/mailman/listinfo/python-list
Re: Python: package root, root-node, __init__.py in the package root
Veek M writes: > I have a package structured like so on the file system: > PKG LIBS are stored here: /usr/lib/python3.2/ > Pkg-name: foo-1.0.0 > > 1. What is the root directory, or root-node or 'root' of my package? My > understanding is that it's: /usr/lib/python3.2/foo-1.0.0/ on the file-system > and this is referred to the root of the pkg. > > 2. Can, foo-1.0.0 contain __init__.py or do i have to do: > foo-1.0.0/foo/__init__.py ? > > > Take a look at what this guy is saying on his blog: > http://blog.habnab.it/blog/2013/07/21/python-packages-and-you/ > > --- > (bottom of the page) > "Your project root should contain a python package, not be a package itself. > If you do this, your setup.py will be very confusing (or not work at all) > and it will be very difficult to run your code." The blog author distinguishes between a project and a package and *recommends* that the package is in a subfolder of its project -- in order to get a simpler "setup.py". Let me clarify the terms "package" and "project" a bit. The "package" is what is used in a Python installation - what is imported into your application. In order to get the "package" installed, other resources are typically required (e.g. installation documentation, dependency specification, "setup.py", ...). The "project" contains the package sources and (most of) the required resources to get the package installed by standard means (e.g. "pip", "easy_install", ...). -- https://mail.python.org/mailman/listinfo/python-list
Python: package root, root-node, __init__.py in the package root
I have a package structured like so on the file system: PKG LIBS are stored here: /usr/lib/python3.2/ Pkg-name: foo-1.0.0 1. What is the root directory, or root-node or 'root' of my package? My understanding is that it's: /usr/lib/python3.2/foo-1.0.0/ on the file-system and this is referred to the root of the pkg. 2. Can, foo-1.0.0 contain __init__.py or do i have to do: foo-1.0.0/foo/__init__.py ? Take a look at what this guy is saying on his blog: http://blog.habnab.it/blog/2013/07/21/python-packages-and-you/ --- (bottom of the page) "Your project root should contain a python package, not be a package itself. If you do this, your setup.py will be very confusing (or not work at all) and it will be very difficult to run your code." (top of the page) passacre/__init__.py passacre/__main__.py 3. Could someone elucidate, explain what it is he's talking about? - Don?t directly run modules inside packages "What I mean specifically is doing python passacre/__main__.py, or python passacre/test/test_application.py, or anything else that starts with python passacre/. This will prevent python from knowing where the root of your package is, and so absolute imports and explicit relative imports will fail, or not import the code you think it should be importing." 4. In this particular case, how does the interpreter determine pkg-root? -- https://mail.python.org/mailman/listinfo/python-list
Re: opposite of __init__.py
Tamer Higazi wrote: > Hi people! > > I have asked myself a question, if there is a opposite of "__init__.py" > like "__del__.py" ?! Others have answered your question, but I wanted to correct a misunderstanding: > > I want, that when the application ends, certain functions are executed. > I know I could make a constructor and a destructor, Not sure what you're talkiing about, but you cannot be sure that an object's destructor ( __del__() ) will ever be called. If you want to make sure that a particular object gets processed, one approach is the with- syntax. > but I simply want to > know if there is a opposite > -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: opposite of __init__.py
On Mon, 19 Aug 2013 18:48:19 +0200, Tamer Higazi wrote: > Hi people! > > I have asked myself a question, if there is a opposite of "__init__.py" > like "__del__.py" ?! No. If you want to run code when your application is shutting down, run it just before your code finishes: def main(): do_this() do_that() if __name__ == '__main__': main() shutdown() If you care about code running even if an exception takes place: if __name__ == '__main__': try: main() finally: shutdown() -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: opposite of __init__.py
Yes, see the atexit module: http://docs.python.org/3/library/atexit.html On Mon, Aug 19, 2013 at 10:48 AM, Tamer Higazi wrote: > Hi people! > > I have asked myself a question, if there is a opposite of "__init__.py" > like "__del__.py" ?! > > I want, that when the application ends, certain functions are executed. > I know I could make a constructor and a destructor, but I simply want to > know if there is a opposite > > > Thanks > > > > Tamer > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
opposite of __init__.py
Hi people! I have asked myself a question, if there is a opposite of "__init__.py" like "__del__.py" ?! I want, that when the application ends, certain functions are executed. I know I could make a constructor and a destructor, but I simply want to know if there is a opposite Thanks Tamer -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessing variables in __init__.py
On Tuesday, October 16, 2012 3:41:55 PM UTC+5:30, Marco Nawijn wrote:
> On Tuesday, October 16, 2012 10:48:17 AM UTC+2, Gaudha wrote:
>
> > my_package/
>
> >
>
> > __init__.py
>
> >
>
> > my_module1.py
>
> >
>
> > my_module2.py
>
> >
>
> > variables.py
>
> >
>
> >
>
> >
>
> > I want to define common variables in __init__.py and use the namespace in
> > my_module1.py or my_module2.py. Defining it is not a problem. How can call
> > it from my modules?
>
> >
>
> >
>
> >
>
> > If I define them in a module (say, variables.py), I can call them by
> > importing variables.py in other modules. How can it be done if I define it
> > in __init__.py?
>
> >
>
> >
>
> >
>
> > It may be a silly query as I am newbie in Python. But, I would be grateful
> > to get help.
>
>
>
> Hi,
>
>
>
> If you store the variables in __init__.py, you can import them from the
> package. So in your case suppose __init__.py contains:
>
> a = 10
>
> b = {1 :"Hello", 2: "World" }
>
>
>
> Than if you import my_package, you can access the variables as follows
> (interactive IPython session):
>
>
>
> In [1]: import my_package
>
>
>
> In [2]: my_pack
>
> my_package my_package/
>
>
>
> In [2]: my_package.
>
> my_package.a my_package.b
>
>
>
> In [2]: my_package.a
>
> Out[2]: 10
>
>
>
> In [3]: my_package.b
>
> Out[3]: {1: 'Hello', 2: 'World'}
>
>
>
> In [4]:
Yea. I got it. It was a new information for me. A module in a package can
import its own mother package to call the variables in __init__.
Is it funny or an extraordinary feature? Anyway. I felt it as something weird.
Guido should have done it something like how 'self' behaves in classes.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Accessing variables in __init__.py
On Tuesday, October 16, 2012 10:48:17 AM UTC+2, Gaudha wrote:
> my_package/
>
> __init__.py
>
> my_module1.py
>
> my_module2.py
>
> variables.py
>
>
>
> I want to define common variables in __init__.py and use the namespace in
> my_module1.py or my_module2.py. Defining it is not a problem. How can call it
> from my modules?
>
>
>
> If I define them in a module (say, variables.py), I can call them by
> importing variables.py in other modules. How can it be done if I define it in
> __init__.py?
>
>
>
> It may be a silly query as I am newbie in Python. But, I would be grateful to
> get help.
Hi,
If you store the variables in __init__.py, you can import them from the
package. So in your case suppose __init__.py contains:
a = 10
b = {1 :"Hello", 2: "World" }
Than if you import my_package, you can access the variables as follows
(interactive IPython session):
In [1]: import my_package
In [2]: my_pack
my_package my_package/
In [2]: my_package.
my_package.a my_package.b
In [2]: my_package.a
Out[2]: 10
In [3]: my_package.b
Out[3]: {1: 'Hello', 2: 'World'}
In [4]:
--
http://mail.python.org/mailman/listinfo/python-list
Accessing variables in __init__.py
my_package/ __init__.py my_module1.py my_module2.py variables.py I want to define common variables in __init__.py and use the namespace in my_module1.py or my_module2.py. Defining it is not a problem. How can call it from my modules? If I define them in a module (say, variables.py), I can call them by importing variables.py in other modules. How can it be done if I define it in __init__.py? It may be a silly query as I am newbie in Python. But, I would be grateful to get help. -- http://mail.python.org/mailman/listinfo/python-list
Re: from import and __init__.py
egbert wrote: Yes, you are right. And I can reach everything with modules['some_package'] or variants thereof. Although note that the usual way to get it would be to simply do import some_package -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: from import and __init__.py
On Thu, Mar 25, 2010 at 12:43:13PM -0400, Terry Reedy wrote: > On 3/25/2010 6:16 AM, egbert wrote: > >When I do 'from some_package import some_module' > >the __init__.py of some_package will be run. > >However, there will not be anything like a package-module, > >and the effects of __init__.py seem all to be lost. Is that true ? > > No. If you do > > from sys import modules > print(modules.keys()) > > you will see both some_package and some_package.some_module among > the entries. Yes, you are right. And I can reach everything with modules['some_package'] or variants thereof. Thanks, egbert -- Egbert Bouwman - Keizersgracht 197 II - 1016 DS Amsterdam - 020 6257991 -- http://mail.python.org/mailman/listinfo/python-list
Re: from import and __init__.py
On 3/25/2010 6:16 AM, egbert wrote: When I do 'from some_package import some_module' the __init__.py of some_package will be run. However, there will not be anything like a package-module, and the effects of __init__.py seem all to be lost. Is that true ? No. If you do from sys import modules print(modules.keys()) you will see both some_package and some_package.some_module among the entries. The first is the result of executing some_package/__init__.py. As usual, that code will *not* be re-exectured on subsequent imports involving some_package. > Or can I still do something useful with __init__.py ? > e Some packages put something like 'from _default_stuff import *' in __init__.py with the intention that the package by used as import package perhaps [optionally] followed by import package.specialized_stuff Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: from import and __init__.py
egbert wrote: > When I do 'from some_package import some_module' > the __init__.py of some_package will be run. > However, there will not be anything like a package-module, > and the effects of __init__.py seem all to be lost. Is that true ? > Or can I still do something useful with __init__.py ? > e If I understand correctly what you mean byt a "package-module" then __init__.py is exactly what you are looking for. Many packages are built with an empty __init__.py because they are intended mostly to build a tree-like set of namespaces, but __init__.py *is* run when the package is imported, and its namespace is bound to the name of the package within the importing program. So if you have code you want to run when the package is imported, put it there. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
from import and __init__.py
When I do 'from some_package import some_module' the __init__.py of some_package will be run. However, there will not be anything like a package-module, and the effects of __init__.py seem all to be lost. Is that true ? Or can I still do something useful with __init__.py ? e -- Egbert Bouwman - Keizersgracht 197 II - 1016 DS Amsterdam - 020 6257991 -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Problem with __init__.py in Python3.1
For finnished the subject i resolve the problem using the PEP-328, i was using the old kind of imports :s On Feb 4, 2010 10:10pm, Hidura wrote: Thanks i middle resolve the problem, and i going to read the PEP-366 i've been read the 328, i will kept informed of the progresses. Thanks again for the help On Thu, Feb 4, 2010 at 6:47 PM, Ben Finney ben+pyt...@benfinney.id.au> wrote: "Gabriel Genellina" gagsl-...@yahoo.com.ar> writes: > If you directly run a script from inside a package, Python does not > know that it belongs to a package, and treats it as a simple, lonely > script. In that case, relative imports won't work. Which I consider to be a bug. Fortunately, it's already addressed in PEP 366 http://www.python.org/dev/peps/pep-0366/>. Unfortunately, it involves more hackish boilerplate at the top of the program, and is only available in Python 2.6+. -- \ “Ignorance more frequently begets confidence than does | `\ knowledge.” —Charles Darwin, _The Descent of Man_, 1871 | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list -- Hidura -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with __init__.py in Python3.1
Thanks i middle resolve the problem, and i going to read the PEP-366 i've been read the 328, i will kept informed of the progresses. Thanks again for the help [?] On Thu, Feb 4, 2010 at 6:47 PM, Ben Finney > wrote: > "Gabriel Genellina" writes: > > > If you directly run a script from inside a package, Python does not > > know that it belongs to a package, and treats it as a simple, lonely > > script. In that case, relative imports won't work. > > Which I consider to be a bug. Fortunately, it's already addressed in PEP > 366 http://www.python.org/dev/peps/pep-0366/>. Unfortunately, it > involves more hackish boilerplate at the top of the program, and is only > available in Python 2.6+. > > -- > \ “Ignorance more frequently begets confidence than does | > `\ knowledge.” —Charles Darwin, _The Descent of Man_, 1871 | > _o__) | > Ben Finney > -- > http://mail.python.org/mailman/listinfo/python-list > -- Hidura <<330.png>>-- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with __init__.py in Python3.1
"Gabriel Genellina" writes: > If you directly run a script from inside a package, Python does not > know that it belongs to a package, and treats it as a simple, lonely > script. In that case, relative imports won't work. Which I consider to be a bug. Fortunately, it's already addressed in PEP 366 http://www.python.org/dev/peps/pep-0366/>. Unfortunately, it involves more hackish boilerplate at the top of the program, and is only available in Python 2.6+. -- \ “Ignorance more frequently begets confidence than does | `\ knowledge.” —Charles Darwin, _The Descent of Man_, 1871 | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with __init__.py in Python3.1
En Thu, 04 Feb 2010 12:40:41 -0300, Hidura escribió: Thanks, I read it and try to put my code in the correct form, but now give me another error, inside the Writer Package says: "ValueError: Attempted relative import in non-package", if somebody knows a clue of how fix it i will glad to read opinions. [?] You say that Writer is a package, but apparently Python disagrees. A package is not just "a directory containing an __init__.py file", this is half the truth. Python must be *aware* of such file, and this happens when you import the package. If you directly run a script from inside a package, Python does not know that it belongs to a package, and treats it as a simple, lonely script. In that case, relative imports won't work. Put the "main" script (the one that you directly execute) outside the package. It can be as small as this, if you want: from some.package import main main() -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with __init__.py in Python3.1
Thanks, I read it and try to put my code in the correct form, but now give me another error, inside the Writer Package says: "ValueError: Attempted relative import in non-package", if somebody knows a clue of how fix it i will glad to read opinions. [?] On Thu, Feb 4, 2010 at 2:11 AM, Gabriel Genellina wrote: > En Thu, 04 Feb 2010 01:00:56 -0300, Hidura escribió: > > > Good evening list, I have a really big trouble with the imports in the 3.1 >> version(Notes: In the older 2.64 theres no problems), I have two packages, >> the first package Utilities who contains Writer the second package, >> Writers >> contain the module tagmanip(What is imported in the best way inside the >> __init__.py of the Writer), when i make the import inside the writer >> everything is ok, but from the Utilities package the errors says: >> "ImportError: No module named tagsmanip". >> I don't understand why this is happening, if somebody could help me i will >> glad to hear any suggestion. >> > > In Python 3.x, "absolute" import is enabled by default (2.6 uses a mix of > relative and absolute imports). > To import sibling modules in a package, or modules in a subpackage, you > have to use relative imports: > > from . import tagmanip > from .Writers import tagmanip > > See PEP328 http://www.python.org/dev/peps/pep-0328/ > > -- > Gabriel Genellina > > -- > http://mail.python.org/mailman/listinfo/python-list > -- Hidura <<330.png>>-- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with __init__.py in Python3.1
En Thu, 04 Feb 2010 01:00:56 -0300, Hidura escribió: Good evening list, I have a really big trouble with the imports in the 3.1 version(Notes: In the older 2.64 theres no problems), I have two packages, the first package Utilities who contains Writer the second package, Writers contain the module tagmanip(What is imported in the best way inside the __init__.py of the Writer), when i make the import inside the writer everything is ok, but from the Utilities package the errors says: "ImportError: No module named tagsmanip". I don't understand why this is happening, if somebody could help me i will glad to hear any suggestion. In Python 3.x, "absolute" import is enabled by default (2.6 uses a mix of relative and absolute imports). To import sibling modules in a package, or modules in a subpackage, you have to use relative imports: from . import tagmanip from .Writers import tagmanip See PEP328 http://www.python.org/dev/peps/pep-0328/ -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Problem with __init__.py in Python3.1
Good evening list, I have a really big trouble with the imports in the 3.1 version(Notes: In the older 2.64 theres no problems), I have two packages, the first package Utilities who contains Writer the second package, Writers contain the module tagmanip(What is imported in the best way inside the __init__.py of the Writer), when i make the import inside the writer everything is ok, but from the Utilities package the errors says: "ImportError: No module named tagsmanip". I don't understand why this is happening, if somebody could help me i will glad to hear any suggestion. Atte. -- Diego I. Hidalgo D. -- http://mail.python.org/mailman/listinfo/python-list
Re: imports in __init__.py
On Dec 18, 12:34 pm, Ben Finney wrote: > Phil writes: > > From an arbitrary python module, I 'import packagename'. > > At that point, you have all the names that were defined within > ‘packagename’, available inside the namespace ‘packagename’. Since > ‘modulename’ is a module in that package, the module's namespace is > available to you via ‘packagename.modulename’. it looks that one need put the "import modulename" line in __init__.py or "import packagename.modulename" in the user clent script explicitly. or else, just 'import packagename' is not enough to use packagename.modulename. -- http://mail.python.org/mailman/listinfo/python-list
Re: imports in __init__.py
Phil wrote: > I wrote my last message late last night. When I said "I am unable to > import a module from the package without an import error.", I did mean > the 'modulename' module. > > However, I just set up a Debian VM with Python 2.5.2 and what I was > trying to do works. So it is either something that changed with Python > 3.1.1, or a problem with Windows. In Python 3.x absolute import is on by default. Change from application import * to from .application import * to indicate that the application module is located within the current package. Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: imports in __init__.py
I wrote my last message late last night. When I said "I am unable to import a module from the package without an import error.", I did mean the 'modulename' module. However, I just set up a Debian VM with Python 2.5.2 and what I was trying to do works. So it is either something that changed with Python 3.1.1, or a problem with Windows. -- http://mail.python.org/mailman/listinfo/python-list
Re: imports in __init__.py
I wrote my last message late last night. When I said "I am unable to import a module from the package without an import error.", I did mean the 'modulename' module. However, I just set up a Debian VM with Python 2.5.2 and what I was trying to do works. So it is either something that changed with Python 3.1.1, or a problem with Windows. -- http://mail.python.org/mailman/listinfo/python-list
Re: imports in __init__.py
I understand all of the above, including the reasons as to why this is bad. For purposes of experimenting, I would still like to do it. I guess I'm (still) wondering how it is done in webpy. I recall seeing it done elsewhere too. All I noticed was that in webpy's package 'web', it defines the 'application' class in 'application.py'. And in web's __init__.py it has... from application import * And in whatever app you are creating, it has... import web app = web.application(params) That being said, I can't get similar functionality with my own package. Is there more to this? Within my package's __init__.py, I am unable to import a module from the package without an import error. Thanks again! -- http://mail.python.org/mailman/listinfo/python-list
Re: imports in __init__.py
Phil writes: > I use distutils / setup.py to install 'packagename', where... > /packagename > __init__.py > modulename.py > > modulename.py has a class named 'classname'. As per PEP 8, it's best if user-defined classes are named with TitleCase, so ‘ClassName’. > From an arbitrary python module, I 'import packagename'. At that point, you have all the names that were defined within ‘packagename’, available inside the namespace ‘packagename’. Since ‘modulename’ is a module in that package, the module's namespace is available to you via ‘packagename.modulename’. > In said module, I want to use the 'classname' class from > 'packagename.modulename', by doing 'packagename.classname(params)'. The name ‘ClassName’ is not in the namespace ‘packagename’. It is in the namespace ‘packagename.modulename’, so you'll need to access it there:: import packagename.modulename packagename.modulename.ClassName(params) You can import the class from that namespace explicitly:: from packagename.modulename import ClassName ClassName(params) or you can import the module from the package namespace:: from packagename import modulename modulename.ClassName(params) > I have seen this done by having either 'import modulename' and/or > 'from modulename import *' in 'packagename's __init__.py. Importing the module in the package would mean you would not have to import the module yourself when using the package; it would not change the qualification necessary of the namespace. Importing using the ‘from foo import *’ form is usually a bad idea, since it clobbers namespaces and makes it impossible to tell by looking at the import code where the name ‘ClassName’ appeared from. Best to import only explicit names, as above. If you want to abbreviate, you can use the ability to rename while importing:: import packagename.modulename as foo foo.ClassName(params) which keeps the names explicit and traceable. -- \ “Give a man a fish, and you'll feed him for a day; give him a | `\religion, and he'll starve to death while praying for a fish.” | _o__) —Anonymous | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
imports in __init__.py
I use distutils / setup.py to install 'packagename', where...
/packagename
__init__.py
modulename.py
modulename.py has a class named 'classname'.
>From an arbitrary python module, I 'import packagename'.
In said module, I want to use the 'classname' class from
'packagename.modulename', by doing 'packagename.classname(params)'.
I have seen this done by having either 'import modulename' and/or
'from modulename import *' in 'packagename's __init__.py. I don't
really know which one or combination of them would work, but I can't
get it to work either way. Unless I am missing something, webpy does
this with, among other things, its application class that is in
application.py. From a new web app, you would just use web.application
(params).
I am using Python 3.1.1, although I don't think that should matter.
Any help is appreciated. Thanks!
--
http://mail.python.org/mailman/listinfo/python-list
Function states [was Re: How to import only one module in a package when the package __init__.py has already imports the modules?]
On Sun, 01 Nov 2009 08:07:37 -0600, Peng Yu wrote: > It is > reasonable to assume the log of the number of states of a function or a > class is proportional to it length. Hence, when a function or a > class is long, you will never be able to test all its states. def f(n): return n + 5 def g(n): x = n + 1 x += 1 x += 1 x += 1 return x + 1 Function g() has five times the length (in lines) as f(). Does it require five times the testing? Obviously not. In fact, there's no easy way to test the internal state of the function from outside, because x is local to g(). You can't test the value of x from outside, because x is not exposed to the outside. The complexity of testing functions is roughly proportional to the number of paths through the function, not the number of lines. Both f() and g() have a single path through the function and therefore require the same amount of testing. The simplest estimate of the number of paths in a function is the number of if...else statements. Each pair *doubles* the number of paths: def func(): if cond1: A else: B if cond2: C else: D if cond3: E else: F There are 2**3 paths that need testing: ACE ACF ADE ADF BCE BCF BDE BDF Or consider this example: def func(x, cond): for f in [A, B, C, D, E, F]: if cond(x): x = f(x) This function has two lines only, but clearly there could be as many as 128 paths that need testing. Ideally your test data should visit each one of these paths. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sun, 01 Nov 2009 13:46:42 -0600, Robert Kern wrote: > Peng Yu wrote: >> On Sat, Oct 31, 2009 at 11:40 PM, Steven D'Aprano >> wrote: > >>> Oh wait, I get it... you want to do a global search-and-replace over >>> the entire file. *face-palm* >> >> Yes. You get it. > > In any capable programmer's editor, it should not be hard to do a local > search-and-replace over just the one function. Given the OP's stated claim that all his functions are less than a screen in size, Notepad could do it, with just the tiniest amount of manual effort. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
Peng Yu wrote: On Sat, Oct 31, 2009 at 11:43 PM, Steven D'Aprano wrote: On Sat, 31 Oct 2009 22:54:47 -0500, Peng Yu wrote: So python would not be able to accommodate my preference one class/function per file? Of course it does! You can do that RIGHT NOW -- just put one class per file. I.e., I have to use something like 'from spam import spam' or 'spam.spam()', How else do you expect to use the class if you don't import it? or accept that the filename is not the same as the class/function name. So let me see... You don't want to write "import spam; spam.spam()" You don't want to write "from spam import spam; spam()" You don't want to write "from Spam import spam; spam()" You don't want to write "from spam import Spam; Spam()" What exactly do you want? When I define class spam in file spam.py, I want to call it by import spam spam() If spam.py is in dir/, then I want to call it by import dir.spam dir.spam() That's just not how Python imports work. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
Peng Yu wrote: On Sat, Oct 31, 2009 at 11:40 PM, Steven D'Aprano wrote: Oh wait, I get it... you want to do a global search-and-replace over the entire file. *face-palm* Yes. You get it. In any capable programmer's editor, it should not be hard to do a local search-and-replace over just the one function. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, Oct 31, 2009 at 11:40 PM, Steven D'Aprano wrote: > On Sat, 31 Oct 2009 22:48:10 -0500, Peng Yu wrote: > >>> Variables in a function are already private. How can the names in one >>> function be affected by other functions in the same module? >> >> You misunderstood me. >> >> If there are multiple functions or classes in a file, when I change >> variables in a function/class, I have to make sure that they are not in >> other functions or classes. > > No you don't. > > def f(x): > return x+1 > > def g(x): > return x-1 > > > If I choose to refactor f() and change "x" to "y", why do I care about > the internal variable inside g()? What I mean was, for example, I only want to change 'x' in f() to 'y', but not 'x' in g() to 'y', because the meaning of 'x' in f() and 'x' in g() may represent different things. If both f() and g() are in the same file, I have to make sure that I only replace 'x' in f() but not in g(). However, if I only have f() in a file, I can simply replace all x in the file without worrying replacing 'x' in g(). Is this clear? > Oh wait, I get it... you want to do a global search-and-replace over the > entire file. *face-palm* Yes. You get it. > If your functions are less than one-screen full, why do you need a global > replacement? Global replacement risks changing words in docstrings, > comments etc that it shouldn't. My variables in general are not as short as a single letter, like 'x', and is descriptive. In general, they will not appear in docstrings, unless the ones in docstrings mean the same thing, in which case it is OK to replace the variable and the one in docstrings. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, Oct 31, 2009 at 11:43 PM, Steven D'Aprano wrote: > On Sat, 31 Oct 2009 22:54:47 -0500, Peng Yu wrote: > >> So python would not be able to accommodate my preference one >> class/function per file? > > Of course it does! You can do that RIGHT NOW -- just put one class per > file. > >> I.e., I have to use something like 'from spam >> import spam' or 'spam.spam()', > > How else do you expect to use the class if you don't import it? > > >> or accept that the filename is not the >> same as the class/function name. > > So let me see... > > You don't want to write "import spam; spam.spam()" > You don't want to write "from spam import spam; spam()" > You don't want to write "from Spam import spam; spam()" > You don't want to write "from spam import Spam; Spam()" > > What exactly do you want? When I define class spam in file spam.py, I want to call it by import spam spam() If spam.py is in dir/, then I want to call it by import dir.spam dir.spam() -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, Oct 31, 2009 at 11:34 PM, Steven D'Aprano wrote: > On Sat, 31 Oct 2009 22:29:12 -0500, Peng Yu wrote: > >>>> In my question, module A and B exist just for the sake of >>>> implementation. Even if I have module A and B, I don't want the user >>>> feel the existence of module A and B. I want them feel exact like >>>> class A and B are defined in module 'test' instead of feeling two >>>> modules A and B are in package 'test'. >>> >>> >>> Inside test/__init__.py: >>> >>> from A import A # class A from file A.py >>> from B import B # class B from file B.py >> >> I can not use the above approach as I mentioned its problem in my >> previous message. > > Either I have not seen it, or I have not understood it, but I don't > understand why you can not use this approach. The problem is when you test a package you want to 'import test.A' rather than 'import test'. Having such __init__.py does not allow you to import only 'test.A'. This cause artificial dependence. >>> or better still: >>> >>> from a import A # class A from file a.py >>> from b import B # class B from file b.py >> >> This artificially introduces the constraint that the file name can not >> be the same as the class/function name. There is no constraint like this >> if I can C++. > > It is not a constraint, it is a convention. You are free to ignore it if > you like. I'm ignoring this convention now. But I have to call a function like glob.glob, which I also feel inconvenient. > Some people don't like writing "glob.glob" (for example). Some people > would like to see Python ban modules with the same name as objects inside > them, to avoid this error: > >>>> import datetime > ... much later >>>> from datetime import datetime >>>> datetime.datetime() > Traceback (most recent call last): > File "", line 1, in > AttributeError: type object 'datetime.datetime' has no attribute > 'datetime' > > > You seem to be inconsistent -- you say you want to name the file the same > as the function in it, so you know which file to look for a function, but > then you complain about writing: > > test.A.A > > so when we suggest naming A.py a.py, so you can write: > > test.a.A > > you complain about that too. Frankly, I think you are just complaining > because Python isn't C++. I'm not complaining. I just wish there is a walkaround. In C++, I still have to write some script to make sure the directory hierarchy is consistent with the namespace, because C++ doesn't impose the constraint that the directory hierarchy is the same as the namespace. But it seems that is no such walkaround in python for my case, because python binds namespace to directory hierarchy. >>>> I know that module names should be in lower cases, in general. >>>> However, it is OK to have the module name capitalized in this case >>>> since the end users don't see them. >>> >>> Of course they do. >> >> This sentence is confusing. Can you spell out what you mean? > > If you supply a package > > test/ > +-- __init__.py > +-- A.py > +-- B.py > > > there is nothing stopping your users from doing this: > > import test.A as A > import test.B as SomethingElse First, this is a redudancy---'A' appears twice. Second, you can not do something like the following, because name A from the two name space is conflict. import test.A as A import test2.A as A > [...] >> I have defined 'long' in one of my previous message. I consider a file >> long, when it does not fit in one or two screen. Basically, I want to >> get a whole picture of the file after glancing of the file. > > You must only write incredibly trivial programs then. > > There is more to understanding a program than understanding one single > function. Any serious function will call other functions. To get the > whole picture, you have to understand them too. Your requirement simply > shifts the burden from "open one file, and read ten functions" to "open > ten files, and read ten functions". I insist on having screen long functions or classes, because they have less number of states compare with long ones. This allows me to test all the states of them to make sure they are bug free. It is reasonable to assume the log of the number of states of a function or a class is proportional to it length. Hence, when a function or a class is long, you will never be able to test all its states. I don't have to put all related functions in a single file. With vim and ctags, you should be able to jump to the definition of any function or class from the place where it is used. So putting single class/function in a file does not give me any extra 'burden' than if I put them in the same file. -- http://mail.python.org/mailman/listinfo/python-list
Identifiers exposed by a package (was: How to import only one module in a package when the package __init__.py has already imports the modules?)
Robert Kern writes:
> If you are going to expose symbols in your __init__.py, they should
> not have the same name as any of the modules in the package.
Would I be correct in assuming you make an exception for the package
importing one of the modules in the package, and thereby making that
module's identifier exposed?
package_foo/
__init__.py
module_bar.py
$ cat foo/__init__.py
import module_bar
Now the name ‘package_foo.module_bar’ will get the identifier already
assigned within ‘package_foo/__init__.py’, but that identifier is the
module anyway.
--
\ “We demand rigidly defined areas of doubt and uncertainty!” |
`\—Vroomfondel, _The Hitch-Hiker's Guide To The Galaxy_, Douglas |
_o__)Adams |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, 31 Oct 2009 22:54:47 -0500, Peng Yu wrote: > So python would not be able to accommodate my preference one > class/function per file? Of course it does! You can do that RIGHT NOW -- just put one class per file. > I.e., I have to use something like 'from spam > import spam' or 'spam.spam()', How else do you expect to use the class if you don't import it? > or accept that the filename is not the > same as the class/function name. So let me see... You don't want to write "import spam; spam.spam()" You don't want to write "from spam import spam; spam()" You don't want to write "from Spam import spam; spam()" You don't want to write "from spam import Spam; Spam()" What exactly do you want? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, 31 Oct 2009 22:48:10 -0500, Peng Yu wrote: >> Variables in a function are already private. How can the names in one >> function be affected by other functions in the same module? > > You misunderstood me. > > If there are multiple functions or classes in a file, when I change > variables in a function/class, I have to make sure that they are not in > other functions or classes. No you don't. def f(x): return x+1 def g(x): return x-1 If I choose to refactor f() and change "x" to "y", why do I care about the internal variable inside g()? Oh wait, I get it... you want to do a global search-and-replace over the entire file. *face-palm* If your functions are less than one-screen full, why do you need a global replacement? Global replacement risks changing words in docstrings, comments etc that it shouldn't. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, 31 Oct 2009 22:29:12 -0500, Peng Yu wrote: >>> In my question, module A and B exist just for the sake of >>> implementation. Even if I have module A and B, I don't want the user >>> feel the existence of module A and B. I want them feel exact like >>> class A and B are defined in module 'test' instead of feeling two >>> modules A and B are in package 'test'. >> >> >> Inside test/__init__.py: >> >> from A import A # class A from file A.py >> from B import B # class B from file B.py > > I can not use the above approach as I mentioned its problem in my > previous message. Either I have not seen it, or I have not understood it, but I don't understand why you can not use this approach. >> or better still: >> >> from a import A # class A from file a.py >> from b import B # class B from file b.py > > This artificially introduces the constraint that the file name can not > be the same as the class/function name. There is no constraint like this > if I can C++. It is not a constraint, it is a convention. You are free to ignore it if you like. Some people don't like writing "glob.glob" (for example). Some people would like to see Python ban modules with the same name as objects inside them, to avoid this error: >>> import datetime ... much later >>> from datetime import datetime >>> datetime.datetime() Traceback (most recent call last): File "", line 1, in AttributeError: type object 'datetime.datetime' has no attribute 'datetime' You seem to be inconsistent -- you say you want to name the file the same as the function in it, so you know which file to look for a function, but then you complain about writing: test.A.A so when we suggest naming A.py a.py, so you can write: test.a.A you complain about that too. Frankly, I think you are just complaining because Python isn't C++. >>> I know that module names should be in lower cases, in general. >>> However, it is OK to have the module name capitalized in this case >>> since the end users don't see them. >> >> Of course they do. > > This sentence is confusing. Can you spell out what you mean? If you supply a package test/ +-- __init__.py +-- A.py +-- B.py there is nothing stopping your users from doing this: import test.A as A import test.B as SomethingElse [...] > I have defined 'long' in one of my previous message. I consider a file > long, when it does not fit in one or two screen. Basically, I want to > get a whole picture of the file after glancing of the file. You must only write incredibly trivial programs then. There is more to understanding a program than understanding one single function. Any serious function will call other functions. To get the whole picture, you have to understand them too. Your requirement simply shifts the burden from "open one file, and read ten functions" to "open ten files, and read ten functions". -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
Peng Yu wrote: On Sat, Oct 31, 2009 at 10:35 PM, Robert Kern wrote: Peng Yu wrote: I have defined 'long' in one of my previous message. I consider a file long, when it does not fit in one or two screen. Basically, I want to get a whole picture of the file after glancing of the file. I think you are going to have to get used to the fact that you have very strange personal preferences and that Python is designed for the vast majority of programmers who do not share them. So python would not be able to accommodate my preference one class/function per file? I.e., I have to use something like 'from spam import spam' or 'spam.spam()', or accept that the filename is not the same as the class/function name. Inside test/__init__.py: from a import A # class A from file a.py from b import B # class B from file b.py If you are going to expose symbols in your __init__.py, they should not have the same name as any of the modules in the package. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, Oct 31, 2009 at 10:35 PM, Robert Kern wrote: > Peng Yu wrote: > >> I have defined 'long' in one of my previous message. I consider a file >> long, when it does not fit in one or two screen. Basically, I want to >> get a whole picture of the file after glancing of the file. > > I think you are going to have to get used to the fact that you have very > strange personal preferences and that Python is designed for the vast > majority of programmers who do not share them. So python would not be able to accommodate my preference one class/function per file? I.e., I have to use something like 'from spam import spam' or 'spam.spam()', or accept that the filename is not the same as the class/function name. Inside test/__init__.py: from a import A # class A from file a.py from b import B # class B from file b.py -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, Oct 31, 2009 at 9:18 PM, Dave Angel wrote: > Peng Yu wrote: >> >> On Sat, Oct 31, 2009 at 5:45 PM, Wolodja Wentland >> wrote: >> >>> >>> On Sat, Oct 31, 2009 at 16:53 -0500, Peng Yu wrote: >>> On Sat, Oct 31, 2009 at 4:14 PM, Robert Kern wrote: >>> >>> [ snip ] >>> >>> I know that multiple classes or functions are typically defined in one file (i.e. module in python). However, I feel this make the code not easy to read. Therefore, I insist on one class or function per file (i.e module in python). >>> >>> Are you serious? Do you *really* put each function in its own file? How >>> exactly does this enhance the readability of the source code? Especially >>> if you compare that to a (sic!) modularisation scheme that groups >>> classes and functions together by task or semantic relatedness. >>> >> >> >> One advantage is on refactoring. When each function has its own file, >> I can change variable names, etc., for a give function without >> worrying accidentally change variable names in other functions. When I >> find a function is more appropriate to put in another namespace, I can >> just move the file around. >> >> > > Variables in a function are already private. How can the names in one > function be affected by other functions in the same module? You misunderstood me. If there are multiple functions or classes in a file, when I change variables in a function/class, I have to make sure that they are not in other functions or classes. This makes the refactoring process tedious. If I have a single class/function in a file, I can safely change variable names without worrying broken other classes or functions. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, Oct 31, 2009 at 9:34 PM, Steven D'Aprano wrote: > On Sat, 31 Oct 2009 18:29:35 -0500, Peng Yu wrote: > >> If two functions are too long to put in file, I generally put them in >> two different files. > > If two functions are too long for a single file, the functions are too > big and need to be broken up into ten or thirty sub-functions each! > > Ideally, no function should be more than ten or twenty lines (plus > docstring), certainly no more than a page. In a language like Python that > is so compact, monster functions that are hundreds of lines long is > almost certainly inexcusable. > > >> And I always put a single class in a file. > > An unnecessary and silly restriction. It is reasonable for large > complicated classes, but not a rule for all classes, some of which might > be as small as two lines. > > >> Suppose that I have many functions in one file, it is not clear to see >> how many functions are in the file at first glance. > > So what? Why is it import to see how many functions are in the file? > > > >> If I put each function in its >> own file, just by looking at the directory structure, I can easily see >> how many functions there are. > > Why do you care how many functions there are? Because I want to easily see what functions are there. >> One advantage is on refactoring. When each function has its own file, I >> can change variable names, etc., for a give function without worrying >> accidentally change variable names in other functions. > > Do you understand that each function has it's own local namespace? Unless > you are foolish enough to use global variables for everything, you can > refactor any given function without effecting other functions in the same > file. > > >> When I find a >> function is more appropriate to put in another namespace, I can just >> move the file around. > > A module is a namespace. This is a constrain imposed by python. C++ does not have this constraint, so I can have each class in a file without any complication in calling classes. Because of this constraint in python. I have do something from spam import spam or call spam.spam. >> Another advantage is on testing. I can have associated test dir for each >> class or function. By this way I can easily locate the definition and >> the test to track any potential problems. > > You can do this when functions share the same file. > > >> You can use package rather than module to group semantic related classes >> and functions. > > Python makes available many namespaces: > > Function > Module > Package > > You are artificially restricting yourself to use: > > Function = Module > Package > > and that's supposed to be an advantage??? Since Module = file, by making Function = Module and Class = Module, it simplifies the search of a function and a class. I also put the testing code along with the module, which make it easier to move module across packages (when I do refactoring, sometime I found some module is not appropriate to put in a package anymore, so I need to move it to a better package). -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
Peng Yu wrote: I have defined 'long' in one of my previous message. I consider a file long, when it does not fit in one or two screen. Basically, I want to get a whole picture of the file after glancing of the file. I think you are going to have to get used to the fact that you have very strange personal preferences and that Python is designed for the vast majority of programmers who do not share them. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, Oct 31, 2009 at 9:42 PM, Steven D'Aprano wrote: > On Sat, 31 Oct 2009 20:03:29 -0500, Peng Yu wrote: > >>> If it should ever happen that two functions are too long to put in a >>> single file you should refactor your code. It is usually a good idea of >>> breaking problems down into single steps (ie functions) so you never >>> end up with a 5000 SLOC *function*. >> >> My definition of long is more than one screen. >> >>> How do functions of this length enhance the readability of your source >>> code? >> >> If the code is of one screen, you can easily see what it does without >> having to scroll back and forth. > > Far enough, but you exchange scrolling back and forth from function to > function with tabbing through editor tabs from file to file. I don't see > that this is an advantage. > > You also complicate calling functions. Instead of: > > > def parrot(): > spam() > ham() > cheeseshop() > > > you need: > > > from spam import spam > from ham import ham > from import cheeseshop > > def parrot(): > spam() > ham() > cheeseshop() > > > This is not an advantage! I would say this is the disadvantage of python, if there is no walkaround to avoid using 'from spam import spam'. As this can be handled in C++ with walkaround. So far the best solution is: Inside test/__init__.py: from a import A # class A from file a.py from b import B # class B from file b.py However, this is not satisfactory enough because this artificially introduces the constraint that the file name can not be the same as the class/function name. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, Oct 31, 2009 at 10:03 PM, Steven D'Aprano wrote: > On Sat, 31 Oct 2009 16:53:50 -0500, Peng Yu wrote: > >> I know that multiple classes or functions are typically defined in one >> file (i.e. module in python). However, I feel this make the code not >> easy to read. Therefore, I insist on one class or function per file (i.e >> module in python). >> >> When one class per module is strictly enforced, there will be no need to >> have different capitalization conventions for modules and classes. >> Developers should be able to tell whether it is a class or a module from >> the context. > > Classes and modules are first-class objects in Python, so you can't > necessarily tell what they are from context. I frequently have code like > this: > > > def verify(test_func, objects_to_process, expected_results): > for obj, result in zip(objects_to_process, expected_results): > print "Testing %r..." % obj, > r = test_func(obj) > if r == result: > print "verified" > else: > print "expected %r but got %s" % (result, r) This example doesn't invalidate my statement. When I say "Developers should be able to tell whether it is a class or a module from the context", I mean the case of defining them or creating objects. In the above case, you still can enforce one class/function per module. > objects_to_process could be a list of floats, strings, functions, > modules, or anything else. Having a naming convention is still useful for > distinguishing (say) factory functions from classes, or modules from > classes. > > >> In my question, module A and B exist just for the sake of >> implementation. Even if I have module A and B, I don't want the user >> feel the existence of module A and B. I want them feel exact like class >> A and B are defined in module 'test' instead of feeling two modules A >> and B are in package 'test'. > > > Inside test/__init__.py: > > from A import A # class A from file A.py > from B import B # class B from file B.py I can not use the above approach as I mentioned its problem in my previous message. > or better still: > > from a import A # class A from file a.py > from b import B # class B from file b.py This artificially introduces the constraint that the file name can not be the same as the class/function name. There is no constraint like this if I can C++. >> I know that module names should be in lower >> cases, in general. However, it is OK to have the module name capitalized >> in this case since the end users don't see them. > > Of course they do. This sentence is confusing. Can you spell out what you mean? >> I looked at python library, there are quite a few __init__.py files are >> not empty. In fact, they are quite long. I agree with you that >> '__init__.py' should not be long. But I'm wondering why in python >> library __init__.py are quite long. > > Define "quite long". > > In Python 2.6, I have: > > [st...@sylar python2.6]$ for file in */__init__.py; do echo "$file" `cat > $file | wc -l` ; done > bsddb/__init__.py 450 > compiler/__init__.py 29 > ctypes/__init__.py 546 > curses/__init__.py 59 > distutils/__init__.py 26 > email/__init__.py 123 > encodings/__init__.py 157 > hotshot/__init__.py 78 > idlelib/__init__.py 1 > json/__init__.py 318 > lib2to3/__init__.py 1 > logging/__init__.py 1490 > multiprocessing/__init__.py 271 > sqlite3/__init__.py 24 > test/__init__.py 1 > wsgiref/__init__.py 23 > xml/__init__.py 47 > > > > With the exception of logging, I don't see any of those as quite long. I have defined 'long' in one of my previous message. I consider a file long, when it does not fit in one or two screen. Basically, I want to get a whole picture of the file after glancing of the file. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, 31 Oct 2009 16:53:50 -0500, Peng Yu wrote: > I know that multiple classes or functions are typically defined in one > file (i.e. module in python). However, I feel this make the code not > easy to read. Therefore, I insist on one class or function per file (i.e > module in python). > > When one class per module is strictly enforced, there will be no need to > have different capitalization conventions for modules and classes. > Developers should be able to tell whether it is a class or a module from > the context. Classes and modules are first-class objects in Python, so you can't necessarily tell what they are from context. I frequently have code like this: def verify(test_func, objects_to_process, expected_results): for obj, result in zip(objects_to_process, expected_results): print "Testing %r..." % obj, r = test_func(obj) if r == result: print "verified" else: print "expected %r but got %s" % (result, r) objects_to_process could be a list of floats, strings, functions, modules, or anything else. Having a naming convention is still useful for distinguishing (say) factory functions from classes, or modules from classes. > In my question, module A and B exist just for the sake of > implementation. Even if I have module A and B, I don't want the user > feel the existence of module A and B. I want them feel exact like class > A and B are defined in module 'test' instead of feeling two modules A > and B are in package 'test'. Inside test/__init__.py: from A import A # class A from file A.py from B import B # class B from file B.py or better still: from a import A # class A from file a.py from b import B # class B from file b.py > I know that module names should be in lower > cases, in general. However, it is OK to have the module name capitalized > in this case since the end users don't see them. Of course they do. > I looked at python library, there are quite a few __init__.py files are > not empty. In fact, they are quite long. I agree with you that > '__init__.py' should not be long. But I'm wondering why in python > library __init__.py are quite long. Define "quite long". In Python 2.6, I have: [st...@sylar python2.6]$ for file in */__init__.py; do echo "$file" `cat $file | wc -l` ; done bsddb/__init__.py 450 compiler/__init__.py 29 ctypes/__init__.py 546 curses/__init__.py 59 distutils/__init__.py 26 email/__init__.py 123 encodings/__init__.py 157 hotshot/__init__.py 78 idlelib/__init__.py 1 json/__init__.py 318 lib2to3/__init__.py 1 logging/__init__.py 1490 multiprocessing/__init__.py 271 sqlite3/__init__.py 24 test/__init__.py 1 wsgiref/__init__.py 23 xml/__init__.py 47 With the exception of logging, I don't see any of those as quite long. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, 31 Oct 2009 20:03:29 -0500, Peng Yu wrote: >> If it should ever happen that two functions are too long to put in a >> single file you should refactor your code. It is usually a good idea of >> breaking problems down into single steps (ie functions) so you never >> end up with a 5000 SLOC *function*. > > My definition of long is more than one screen. > >> How do functions of this length enhance the readability of your source >> code? > > If the code is of one screen, you can easily see what it does without > having to scroll back and forth. Far enough, but you exchange scrolling back and forth from function to function with tabbing through editor tabs from file to file. I don't see that this is an advantage. You also complicate calling functions. Instead of: def parrot(): spam() ham() cheeseshop() you need: from spam import spam from ham import ham from import cheeseshop def parrot(): spam() ham() cheeseshop() This is not an advantage! -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, 31 Oct 2009 18:29:35 -0500, Peng Yu wrote: > If two functions are too long to put in file, I generally put them in > two different files. If two functions are too long for a single file, the functions are too big and need to be broken up into ten or thirty sub-functions each! Ideally, no function should be more than ten or twenty lines (plus docstring), certainly no more than a page. In a language like Python that is so compact, monster functions that are hundreds of lines long is almost certainly inexcusable. > And I always put a single class in a file. An unnecessary and silly restriction. It is reasonable for large complicated classes, but not a rule for all classes, some of which might be as small as two lines. > Suppose that I have many functions in one file, it is not clear to see > how many functions are in the file at first glance. So what? Why is it import to see how many functions are in the file? > If I put each function in its > own file, just by looking at the directory structure, I can easily see > how many functions there are. Why do you care how many functions there are? > One advantage is on refactoring. When each function has its own file, I > can change variable names, etc., for a give function without worrying > accidentally change variable names in other functions. Do you understand that each function has it's own local namespace? Unless you are foolish enough to use global variables for everything, you can refactor any given function without effecting other functions in the same file. > When I find a > function is more appropriate to put in another namespace, I can just > move the file around. A module is a namespace. > Another advantage is on testing. I can have associated test dir for each > class or function. By this way I can easily locate the definition and > the test to track any potential problems. You can do this when functions share the same file. > You can use package rather than module to group semantic related classes > and functions. Python makes available many namespaces: Function Module Package You are artificially restricting yourself to use: Function = Module Package and that's supposed to be an advantage??? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
Peng Yu wrote: On Sat, Oct 31, 2009 at 5:45 PM, Wolodja Wentland wrote: On Sat, Oct 31, 2009 at 16:53 -0500, Peng Yu wrote: On Sat, Oct 31, 2009 at 4:14 PM, Robert Kern wrote: [ snip ] I know that multiple classes or functions are typically defined in one file (i.e. module in python). However, I feel this make the code not easy to read. Therefore, I insist on one class or function per file (i.e module in python). Are you serious? Do you *really* put each function in its own file? How exactly does this enhance the readability of the source code? Especially if you compare that to a (sic!) modularisation scheme that groups classes and functions together by task or semantic relatedness. One advantage is on refactoring. When each function has its own file, I can change variable names, etc., for a give function without worrying accidentally change variable names in other functions. When I find a function is more appropriate to put in another namespace, I can just move the file around. Variables in a function are already private. How can the names in one function be affected by other functions in the same module? DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, Oct 31, 2009 at 7:21 PM, Wolodja Wentland wrote: > On Sat, Oct 31, 2009 at 18:29 -0500, Peng Yu wrote: >> On Sat, Oct 31, 2009 at 5:45 PM, Wolodja Wentland >> wrote: >> > On Sat, Oct 31, 2009 at 16:53 -0500, Peng Yu wrote: > >> > Are you serious? Do you *really* put each function in its own file? How >> > exactly does this enhance the readability of the source code? Especially >> > if you compare that to a (sic!) modularisation scheme that groups >> > classes and functions together by task or semantic relatedness. > >> If two functions are too long to put in file, I generally put them in >> two different files. > > If it should ever happen that two functions are too long to put in a > single file you should refactor your code. It is usually a good idea of > breaking problems down into single steps (ie functions) so you never end > up with a 5000 SLOC *function*. My definition of long is more than one screen. > How do functions of this length enhance the readability of your source > code? If the code is of one screen, you can easily see what it does without having to scroll back and forth. >> And I always put a single class in a file. > > Why? What do you gain by that? It makes me easier to look for an class. I can just search the filename to get a class. By looking at the packages imported in the file, I can easily see what packages a class depends. If there are multiple classes in a file, I will not know which packages a class actually depends on. >> Suppose that I have many functions in one file, it is not clear to see >> how many functions are in the file at first glance. > > Use a better editor/IDE for that. What editor you use? I use vim. I'm sure there is a way to configure vim to fold the definition of a class. But I don't use it because I feel folding and unfolding code is not convenient. > [snip] > > I thought about answering your post in greater detail, but i would like > to evaluate your style of work first. Is there any place where I can > have a look at some of your source code? It would be perfect if it is a > medium sized project with said unit tests, packages and > function-modules and the rest you described. I just started writing python code. So I don't have much code to show you now. But I have written a project of 25,000 lines of code in C++. In this project, I always have a file for a class. My directory structure looks like the following (toward the end). But having this structure it is every easy to navigate to any class or function. Please let me know if you need any more information. src/ has all the source code and testing code. Because I usually need to change source code and the corresponding test code at the same time, I put them close to each other. include/ has links to all the header files and maintains the directory structure (include/ is generated automatically based on the content of src/). All .cpp files are linked to lib/, where the library file is made. The unit test for divide is in main.cpp. | |-- divide.cpp | |-- divide.hpp | `-- main.cpp When test cases become big, I separate them into multiple main.cpp files like below. | |-- half | | |-- Makefile | | |-- cap | | | |-- Makefile | | | `-- main.cpp | | |-- half.hpp | | |-- is_interleaved | | | |-- Makefile | | | `-- main.cpp | | |-- less_than | | | |-- Makefile | | | `-- main.cpp | | `-- main | | |-- Makefile | | `-- main.cpp The namespace is defined accordingly. For example, class divide.hpp is in numerical/divide.hpp, therefore, I use numerical::divide to refer it. ### example directory structure . |-- include | `-- numerical | |-- divide.hpp -> ../../src/divide/divide.hpp | |-- interval | | |-- combine_half.hpp -> ../../../src/interval/combine_half/combine_half.hpp | | |-- half.hpp -> ../../../src/interval/half/half.hpp | | |-- linear.hpp -> ../../../src/interval/linear/linear.hpp | | `-- rotated.hpp -> ../../../src/interval/rotated/rotated.hpp | `-- smart_increment.hpp -> ../../src/smart_increment/smart_increment.hpp |-- lib | |-- Makefile | |-- libnumerical.so -> libnumerical.so.1 | |-- libnumerical.so.1 -> libnumerical.so.1.0.0 | `-- numerical | `-- divide.cpp -> ../../src/divide/divide.cpp `-- src |-- Makefile |-- divide | |-- Makefile | |-- divide.cpp | |-- divide.hpp | `-- main.cpp |-- interval | |-- Makefile | |-- combine_half | | |-- Makefile | | |-- combine_half.hpp | | `-- main.cpp | |-- half | | |-- Makefile | | |-- cap | | | |-- Makefile | | | `-- main.cpp | | |-- half.hpp | | |-- is_interleaved | | | |-- Makefile | | | `-- main.cpp | | |-- less_than | | | |-- Makefile | | | `-- main.
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On 2009-10-31 19:21 PM, Wolodja Wentland wrote: On Sat, Oct 31, 2009 at 18:29 -0500, Peng Yu wrote: And I always put a single class in a file. Why? What do you gain by that? While it's never a good idea to follow the rule slavishly, it's often a good idea. Many classes are themselves a semantic unit of functionality enough to justify their own module. I've certainly seen the rule overapplied, though. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, Oct 31, 2009 at 18:29 -0500, Peng Yu wrote: > On Sat, Oct 31, 2009 at 5:45 PM, Wolodja Wentland > wrote: > > On Sat, Oct 31, 2009 at 16:53 -0500, Peng Yu wrote: > > Are you serious? Do you *really* put each function in its own file? How > > exactly does this enhance the readability of the source code? Especially > > if you compare that to a (sic!) modularisation scheme that groups > > classes and functions together by task or semantic relatedness. > If two functions are too long to put in file, I generally put them in > two different files. If it should ever happen that two functions are too long to put in a single file you should refactor your code. It is usually a good idea of breaking problems down into single steps (ie functions) so you never end up with a 5000 SLOC *function*. How do functions of this length enhance the readability of your source code? > And I always put a single class in a file. Why? What do you gain by that? > Suppose that I have many functions in one file, it is not clear to see > how many functions are in the file at first glance. Use a better editor/IDE for that. [snip] I thought about answering your post in greater detail, but i would like to evaluate your style of work first. Is there any place where I can have a look at some of your source code? It would be perfect if it is a medium sized project with said unit tests, packages and function-modules and the rest you described. Why does not a single module in in the stdlib follow your code layout scheme? regards Wolodja signature.asc Description: Digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, Oct 31, 2009 at 5:45 PM, Wolodja Wentland wrote: > On Sat, Oct 31, 2009 at 16:53 -0500, Peng Yu wrote: >> On Sat, Oct 31, 2009 at 4:14 PM, Robert Kern wrote: > > [ snip ] > >> I know that multiple classes or functions are typically defined in one >> file (i.e. module in python). However, I feel this make the code not >> easy to read. Therefore, I insist on one class or function per file >> (i.e module in python). > > Are you serious? Do you *really* put each function in its own file? How > exactly does this enhance the readability of the source code? Especially > if you compare that to a (sic!) modularisation scheme that groups > classes and functions together by task or semantic relatedness. If two functions are too long to put in file, I generally put them in two different files. And I always put a single class in a file. Suppose that I have many functions in one file, it is not clear to see how many functions are in the file at first glance. If I put each function in its own file, just by looking at the directory structure, I can easily see how many functions there are. One advantage is on refactoring. When each function has its own file, I can change variable names, etc., for a give function without worrying accidentally change variable names in other functions. When I find a function is more appropriate to put in another namespace, I can just move the file around. Another advantage is on testing. I can have associated test dir for each class or function. By this way I can easily locate the definition and the test to track any potential problems. You can use package rather than module to group semantic related classes and functions. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQIcBAEBCAAGBQJK7L38AAoJEIt/fTDK8U78Pv4P/icEwsmSLcuINWZHj4Shs0A/ > 1/TZcuP5VwuR6gZ0WsywKzbKJqL0WDahUi4o3VkwFuM2mKskXzch3buZ5NvlwOp6 > I+NqBn9jCTb3nXiVb5wHdF6uYf84BPZe1WccRIDJLIoGRWX/V6tmMH1LtLGnBeVi > RGOd6Mz2KGr1cgisyYJ2h4Qm5tzKNuZ1KDtzXoOG4DYzwEEZBITFOwDNXy5tihJz > v/NcAZOa4aBfJZtKxA7Ikl+30nDV8ZZhEU7Br/rIus2JrSqMp6gAh4f+zTz9jQzL > Sp7O3bTQiHoghej+G4YW+/eMDTiNDSKm1u8++V5svwednp/mmYBnzA8aIPKFSoN6 > vn4D0Q2XVGQAoWyY7pT9zyRKBJnn63xXD5h9T6JimEz7uMWGzTebIuxFRHsd1vkt > TYTW1kJDH8aIsy51egBezZx8o6sntBFu3D+D3itqDW2D2sZ75sPiblgkLCWHvZMR > RaBjCkvhVjOaiJOZ64mRmkW3RUJzY6lGvEqfQqW1bRpHxLEUKaWLy6rWa0sQTTut > rIZ/5TdnjPec1Dx+9v6V7sW8bZtCttpb7j4k+DBAMjRpW7mocnGfuxGN/57Y/uD0 > gFOURpMz1rjEdPCiYZuUQX+joS3tl9IxnBZL7gTRl3slSWoVlGuhcqsew3nAkrGB > Fx8iwKUAwwRULxzigHHB > =n3s3 > -END PGP SIGNATURE- > > -- > http://mail.python.org/mailman/listinfo/python-list > > -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
o compile or link step. You can't think of import statements as #include statements and need to use different patterns. Of course, to really take advantage of that feature in C++ requires some careful coding and use of patterns like pimpl. That often negates any readability benefits. You could probably hack something (and people have), but it makes your code harder to understand because it is non-standard. Personally, I like to keep my __init__.py files empty such that I can import exactly what I need from the package. This allows me to import exactly the module that I need. In large packages with extension modules that can be expensive to load, this is useful. We usually augment this with an api.py that exposes the convenient "public API" of the package, the A and B classes in your case. I looked at python library, there are quite a few __init__.py files are not empty. In fact, they are quite long. I agree with you that '__init__.py' should not be long. But I'm wondering why in python library __init__.py are quite long. For the most part, it's just not an issue. If you are seeing serious problems, this may just be exposing deeper issues with your code and your process that will come to bite you in other contexts sooner or later. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, Oct 31, 2009 at 16:53 -0500, Peng Yu wrote: > On Sat, Oct 31, 2009 at 4:14 PM, Robert Kern wrote: [ snip ] > I know that multiple classes or functions are typically defined in one > file (i.e. module in python). However, I feel this make the code not > easy to read. Therefore, I insist on one class or function per file > (i.e module in python). Are you serious? Do you *really* put each function in its own file? How exactly does this enhance the readability of the source code? Especially if you compare that to a (sic!) modularisation scheme that groups classes and functions together by task or semantic relatedness. regards Wolodja signature.asc Description: Digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, Oct 31, 2009 at 4:14 PM, Robert Kern wrote: > On 2009-10-31 15:31 PM, Peng Yu wrote: > >> The original problem comes from the maintenance of the package. When A >> and B are large classes, it is better to put them in separate files >> under the directory 'test' than put them in the file 'test.py'. The >> interface 'test.A' is used by end users. However, there will be a >> problem if 'import test' is used for developers, because both A and B >> are imported, which cause dependence between A and B. For example, >> during the modification of B (not finished), 'import A' would not >> work. This is means that modifications of A and B are not independent, >> which cause a lot of problem when maintaining the package. > > To be frank, that development process is going to cause you a lot of > problems well beyond these import entanglements. Developers should have > their own workspace! They shouldn't push things into production until the > system is working. Checking something into source control shouldn't > automatically deploy things into production. I don't quite agree with your opinion. But please don't take it too personaly. Even in the developer's work space, it is possible to change multiple classes simultaneously. So the import entanglement problem still exists. >> Naming the filename different from the class is a solution, but it is >> a little bit annoying. >> >> I'm wondering how people handle this situation when they have to >> separate a module into multiple modules. > > Even if we organize things along the lines of "one class per module", we use > different capitalization conventions for modules and classes. In part, this > helps solve your problem, but it mostly saves the developer thought-cycles > from having to figure out which you are referring to when reading the code. I know that multiple classes or functions are typically defined in one file (i.e. module in python). However, I feel this make the code not easy to read. Therefore, I insist on one class or function per file (i.e module in python). When one class per module is strictly enforced, there will be no need to have different capitalization conventions for modules and classes. Developers should be able to tell whether it is a class or a module from the context. In my question, module A and B exist just for the sake of implementation. Even if I have module A and B, I don't want the user feel the existence of module A and B. I want them feel exact like class A and B are defined in module 'test' instead of feeling two modules A and B are in package 'test'. I know that module names should be in lower cases, in general. However, it is OK to have the module name capitalized in this case since the end users don't see them. In C++, what I am asking can be easily implemented, because the namespace and the directory hierachy is not bind to each other. However, the binding between the namespace and the directory hierachy make this difficult to implement. I don't know if it is not impossible, but I'd hope there is a way to do so. > Personally, I like to keep my __init__.py files empty such that I can import > exactly what I need from the package. This allows me to import exactly the > module that I need. In large packages with extension modules that can be > expensive to load, this is useful. We usually augment this with an api.py > that exposes the convenient "public API" of the package, the A and B classes > in your case. I looked at python library, there are quite a few __init__.py files are not empty. In fact, they are quite long. I agree with you that '__init__.py' should not be long. But I'm wondering why in python library __init__.py are quite long. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On 2009-10-31 15:31 PM, Peng Yu wrote: The original problem comes from the maintenance of the package. When A and B are large classes, it is better to put them in separate files under the directory 'test' than put them in the file 'test.py'. The interface 'test.A' is used by end users. However, there will be a problem if 'import test' is used for developers, because both A and B are imported, which cause dependence between A and B. For example, during the modification of B (not finished), 'import A' would not work. This is means that modifications of A and B are not independent, which cause a lot of problem when maintaining the package. To be frank, that development process is going to cause you a lot of problems well beyond these import entanglements. Developers should have their own workspace! They shouldn't push things into production until the system is working. Checking something into source control shouldn't automatically deploy things into production. Naming the filename different from the class is a solution, but it is a little bit annoying. I'm wondering how people handle this situation when they have to separate a module into multiple modules. Even if we organize things along the lines of "one class per module", we use different capitalization conventions for modules and classes. In part, this helps solve your problem, but it mostly saves the developer thought-cycles from having to figure out which you are referring to when reading the code. Personally, I like to keep my __init__.py files empty such that I can import exactly what I need from the package. This allows me to import exactly the module that I need. In large packages with extension modules that can be expensive to load, this is useful. We usually augment this with an api.py that exposes the convenient "public API" of the package, the A and B classes in your case. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
On Sat, Oct 31, 2009 at 12:47 PM, Duncan Booth wrote: > Peng Yu wrote: > >> I'm wondering if there is a way to make the following two things hold. >> Thank you1 >> 1. When I 'import test', I can refer to class A as 'test.A'. >> 2. When I 'import test.A', I can refer to class A as 'test.A.A' and >> class B shall not be imported. >> > No. Either import adds the name 'test' to the current namespace. That name > in each case references the same thing. > > Your simplest solution would be to give the sub-modules lowercase > filenames, then you can do: > > import test > test.A() > > or > > import test.a > test.a.A() > > or even > > import test.a > test.b.B() > > It would probably be best though just to be consistent as to how you > reference the classes: define a public interface for your package and stick > to it. The original problem comes from the maintenance of the package. When A and B are large classes, it is better to put them in separate files under the directory 'test' than put them in the file 'test.py'. The interface 'test.A' is used by end users. However, there will be a problem if 'import test' is used for developers, because both A and B are imported, which cause dependence between A and B. For example, during the modification of B (not finished), 'import A' would not work. This is means that modifications of A and B are not independent, which cause a lot of problem when maintaining the package. Naming the filename different from the class is a solution, but it is a little bit annoying. I'm wondering how people handle this situation when they have to separate a module into multiple modules. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to import only one module in a package when the package __init__.py has already imports the modules?
Peng Yu wrote: > I'm wondering if there is a way to make the following two things hold. > Thank you1 > 1. When I 'import test', I can refer to class A as 'test.A'. > 2. When I 'import test.A', I can refer to class A as 'test.A.A' and > class B shall not be imported. > No. Either import adds the name 'test' to the current namespace. That name in each case references the same thing. Your simplest solution would be to give the sub-modules lowercase filenames, then you can do: import test test.A() or import test.a test.a.A() or even import test.a test.b.B() It would probably be best though just to be consistent as to how you reference the classes: define a public interface for your package and stick to it. -- http://mail.python.org/mailman/listinfo/python-list
How to import only one module in a package when the package __init__.py has already imports the modules?
I have the following files, which are in the directory 'test'. The parent directory of 'test' is in $PYTHONPATH. I have 'from A import A' and 'from B import B' in '__init__.py', because I want to use 'test.A' and 'test.B' to refer to classes A and B rather than 'test.A.A' and 'test.B.B'. $ll -g total 24 -rw-r--r-- 1 staff 32 2009-10-31 10:41:47 __init__.py -rw-r--r-- 1 staff 235 2009-10-31 10:45:24 __init__.pyc -rw-r--r-- 1 staff 550 2009-10-31 10:45:24 B.pyc -rw-r--r-- 1 staff 550 2009-10-31 10:45:24 A.pyc -rw-r--r-- 1 staff 54 2009-10-31 10:46:03 A.py -rw-r--r-- 1 staff 54 2009-10-31 10:46:14 B.py $cat __init__.py from A import A from B import B $cat A.py class A: def __init__(self): print '__init__ A' $cat B.py class B: def __init__(self): print '__init__ B' Then I have the following python files to call the modules. However, because I have 'import A from A' in '__init__.py', I can not call 'test.A.A()' anymore. Even I only have 'import test.A', both modules 'A' and 'B' are imported. So 'import test.A' is essentially the same as 'import test'. I'm wondering if there is a way to make the following two things hold. Thank you1 1. When I 'import test', I can refer to class A as 'test.A'. 2. When I 'import test.A', I can refer to class A as 'test.A.A' and class B shall not be imported. $cat fail.py import test.A test.A.A() $python fail.py Traceback (most recent call last): File "fail.py", line 2, in test.A.A() AttributeError: class A has no attribute 'A' $cat main.py import test test.A() test.B() $python main.py __init__ A __init__ B $cat fail2.py import test.A test.A() test.B() $python fail2.py __init__ A __init__ B -- http://mail.python.org/mailman/listinfo/python-list
Re: PyQt4.__file__ gives PyQt4/__init__.py as value
On Aug 15, 2:19 pm, Christian Heimes wrote: > wgw wrote: > > I don't understand why the __file__ value in my installation of PyQt > > would not give a proper, full path. > > > I'm guessing that I did not install pyqt properly (I'm on Ubuntu > > Hardy, trying to install QT4.5), but before redoing the install, I > > want to see if there is a quicker fix. > > Some versions of Debian and Ubuntu used to compile Python files with a > relative path. Try this: > > python2.5 /usr/lib/python2.5/compileall.py -f /usr/lib/python2.5 > python2.5 -o /usr/lib/python2.5/compileall.py -f /usr/lib/python2.5 > > Christian python2.5 /usr/lib/python2.5/compileall.py -f /usr/lib/python2.5 didn't change anything, and there is no -o option (-O exists, but would that be useful?) thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: PyQt4.__file__ gives PyQt4/__init__.py as value
wgw wrote: I don't understand why the __file__ value in my installation of PyQt would not give a proper, full path. I'm guessing that I did not install pyqt properly (I'm on Ubuntu Hardy, trying to install QT4.5), but before redoing the install, I want to see if there is a quicker fix. Some versions of Debian and Ubuntu used to compile Python files with a relative path. Try this: python2.5 /usr/lib/python2.5/compileall.py -f /usr/lib/python2.5 python2.5 -o /usr/lib/python2.5/compileall.py -f /usr/lib/python2.5 Christian -- http://mail.python.org/mailman/listinfo/python-list
PyQt4.__file__ gives PyQt4/__init__.py as value
I don't understand why the __file__ value in my installation of PyQt would not give a proper, full path. I'm guessing that I did not install pyqt properly (I'm on Ubuntu Hardy, trying to install QT4.5), but before redoing the install, I want to see if there is a quicker fix. Also, though PyQt4/ is in the site-packages directory, and loads properly into the interactive environment. Yolk does not list it. ??? Something strange here! Any suggestions? -- http://mail.python.org/mailman/listinfo/python-list
Re: Code in __init__.py, is it bad form?
On Feb 23, 5:41 pm, Michael Crute wrote: > Is it bad form (i.e. non-pythonic) to have code in your __init__.py > files? I know this is subjective so I'm just looking for the general > consensus. I've heard both sides of the story and I personally feel > its okay if the code pertains to the whole module but have an open > mind about the matter. If you object to code in __init__.py why, and > what alternatives do you propose? Well, I don't like when __init__ "helpfully" imports stuff I don't need. However, most single modules have lots of code I don't need, too, and I never concern myself with them, so it's probably a misplaced irk. Go ahead and use it. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Code in __init__.py, is it bad form?
On Mon, Feb 23, 2009 at 9:41 PM, Benjamin Peterson wrote: > Michael Crute gmail.com> writes: >> On Mon, Feb 23, 2009 at 9:03 PM, Steve Holden holdenweb.com> >> wrote: >> > No, it's absolutely fine. One common usage is to import symbols from >> > sub-modules so that they are available from a simple import of the package. >> >> Yeah, I use it often for that I'm talking more about stuff like >> utility functions, main methods, etc... > > There's no overarching Python doctrine forbidding you to do it. It has simply > become a matter of taste. Personally, I tend to put utility functions in their > own module (eg. util), but I do use __init__ for main methods and such. Okay, so assuming I have decent judgment it sounds like I'm not doing anything patently wrong. Thanks for the input. -mike -- Michael E. Crute http://mike.crute.org God put me on this earth to accomplish a certain number of things. Right now I am so far behind that I will never die. --Bill Watterson -- http://mail.python.org/mailman/listinfo/python-list
Re: Code in __init__.py, is it bad form?
On Feb 24, 12:21 pm, Michael Crute wrote: > Yeah, I use it often for that I'm talking more about stuff like > utility functions, main methods, etc... Personally, I use it only for those tasks related to 'initialising' the package, a la the importing of various modules for convenience sake (as mentioned by Steve). I don't expect a class to define its method within its __init__, so I'd find it unusual for a package to be defining any kind of functionality within its __init__.py. I wouldn't _not_ use your code, but I might eye it warily... :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Code in __init__.py, is it bad form?
Michael Crute writes: > Is it bad form (i.e. non-pythonic) to have code in your __init__.py > files? No, it's good form, but *only* for code that truly pertains to the entire package. Anything that can reasonably be in a module other than ‘__init__’, should be. That leaves the following things suitable for code in ‘__init__’, OTTOMH: * Metadata attributes for the package (e.g. version string). * Docstring for the package * ‘from foo import bar’ to present attributes of the package that are actually implemented in a module, which should be just about everything in the package. > If you object to code in __init__.py why I object only to code that isn't clearly “relates to the entire package and can't reasonably be implemented in a separate module”. If you're going to the effort of making a package (rather than just coding the namespace as a single module), then the implementation should be in modules other than ‘__init__’ to allow easier re-use, re-factoring, and testing. -- \ “When I wake up in the morning, I just can't get started until | `\ I've had that first, piping hot pot of coffee. Oh, I've tried | _o__)other enemas...” —Emo Philips | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Code in __init__.py, is it bad form?
Michael Crute gmail.com> writes: > On Mon, Feb 23, 2009 at 9:03 PM, Steve Holden holdenweb.com> > wrote: > > No, it's absolutely fine. One common usage is to import symbols from > > sub-modules so that they are available from a simple import of the package. > > Yeah, I use it often for that I'm talking more about stuff like > utility functions, main methods, etc... There's no overarching Python doctrine forbidding you to do it. It has simply become a matter of taste. Personally, I tend to put utility functions in their own module (eg. util), but I do use __init__ for main methods and such. -- http://mail.python.org/mailman/listinfo/python-list
Re: Code in __init__.py, is it bad form?
On Mon, Feb 23, 2009 at 9:03 PM, Steve Holden wrote: > Michael Crute wrote: >> Is it bad form (i.e. non-pythonic) to have code in your __init__.py >> files? I know this is subjective so I'm just looking for the general >> consensus. I've heard both sides of the story and I personally feel >> its okay if the code pertains to the whole module but have an open >> mind about the matter. If you object to code in __init__.py why, and >> what alternatives do you propose? >> > No, it's absolutely fine. One common usage is to import symbols from > sub-modules so that they are available from a simple import of the package. Yeah, I use it often for that I'm talking more about stuff like utility functions, main methods, etc... -mike -- Michael E. Crute http://mike.crute.org God put me on this earth to accomplish a certain number of things. Right now I am so far behind that I will never die. --Bill Watterson -- http://mail.python.org/mailman/listinfo/python-list
Re: Code in __init__.py, is it bad form?
Michael Crute wrote: > Is it bad form (i.e. non-pythonic) to have code in your __init__.py > files? I know this is subjective so I'm just looking for the general > consensus. I've heard both sides of the story and I personally feel > its okay if the code pertains to the whole module but have an open > mind about the matter. If you object to code in __init__.py why, and > what alternatives do you propose? > No, it's absolutely fine. One common usage is to import symbols from sub-modules so that they are available from a simple import of the package. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Code in __init__.py, is it bad form?
Is it bad form (i.e. non-pythonic) to have code in your __init__.py files? I know this is subjective so I'm just looking for the general consensus. I've heard both sides of the story and I personally feel its okay if the code pertains to the whole module but have an open mind about the matter. If you object to code in __init__.py why, and what alternatives do you propose? -- Michael E. Crute http://mike.crute.org God put me on this earth to accomplish a certain number of things. Right now I am so far behind that I will never die. --Bill Watterson -- http://mail.python.org/mailman/listinfo/python-list
Re: __init__.py and package help
Thanks
J. Cliff Dyer wrote:
> On Mon, 2009-01-05 at 11:49 -0800, TechieInsights wrote:
> > Ok I have read all of the tutorials and documents I could find. I am
> > running Python 2.6 on windows. The problem I am having with packages
> > is that they don't show up!
> >
> > Simple example of what isn't working...
> > Structure-
> >
> > pytest/ Root directory of package
> > __init__.py- code: __all__ = ['folder']
> > folder/ Another folder in the package
> > __init__.py- code: __all__ = ['hello']
> > hello.py- code: print('Hello World')
> >
> > Then I append the path to sys.path, and try and import...
> >
> > >>> sys.path.append(r'E:\dev\test\pytest')
> > >>> from pytest.folder import hello
> > Traceback (most recent call last):
> > File "", line 1, in
> > ImportError: No module named pytest.folder
> >
> > What am I doing wrong! It's driving me crazy.
> > Thanks in advance,
> > Greg
>
> You want
>
> >>> sys.path.append(r'E:\dev\test')
>
> unless your code is in E:\dev\test\pytest\pytest\folder\hello.py
>
>
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> >
--
http://mail.python.org/mailman/listinfo/python-list
Re: __init__.py and package help
On Mon, 2009-01-05 at 11:49 -0800, TechieInsights wrote:
> Ok I have read all of the tutorials and documents I could find. I am
> running Python 2.6 on windows. The problem I am having with packages
> is that they don't show up!
>
> Simple example of what isn't working...
> Structure-
>
> pytest/ Root directory of package
> __init__.py- code: __all__ = ['folder']
> folder/ Another folder in the package
> __init__.py- code: __all__ = ['hello']
> hello.py- code: print('Hello World')
>
> Then I append the path to sys.path, and try and import...
>
> >>> sys.path.append(r'E:\dev\test\pytest')
> >>> from pytest.folder import hello
> Traceback (most recent call last):
> File "", line 1, in
> ImportError: No module named pytest.folder
>
> What am I doing wrong! It's driving me crazy.
> Thanks in advance,
> Greg
You want
>>> sys.path.append(r'E:\dev\test')
unless your code is in E:\dev\test\pytest\pytest\folder\hello.py
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: __init__.py and package help
Ok... I figured it out... you can only import packages via the __all__
= ['subpackage/folder']... if you include a module such as hello.py,
it will fail.
Go figures I'd find this right after posting here...
Greg
TechieInsights wrote:
> Ok I have read all of the tutorials and documents I could find. I am
> running Python 2.6 on windows. The problem I am having with packages
> is that they don't show up!
>
> Simple example of what isn't working...
> Structure-
>
> pytest/ Root directory of package
> __init__.py- code: __all__ = ['folder']
> folder/ Another folder in the package
> __init__.py- code: __all__ = ['hello']
> hello.py- code: print('Hello World')
>
> Then I append the path to sys.path, and try and import...
>
> >>> sys.path.append(r'E:\dev\test\pytest')
> >>> from pytest.folder import hello
> Traceback (most recent call last):
> File "", line 1, in
> ImportError: No module named pytest.folder
>
> What am I doing wrong! It's driving me crazy.
> Thanks in advance,
> Greg
--
http://mail.python.org/mailman/listinfo/python-list
__init__.py and package help
Ok I have read all of the tutorials and documents I could find. I am
running Python 2.6 on windows. The problem I am having with packages
is that they don't show up!
Simple example of what isn't working...
Structure-
pytest/ Root directory of package
__init__.py- code: __all__ = ['folder']
folder/ Another folder in the package
__init__.py- code: __all__ = ['hello']
hello.py- code: print('Hello World')
Then I append the path to sys.path, and try and import...
>>> sys.path.append(r'E:\dev\test\pytest')
>>> from pytest.folder import hello
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named pytest.folder
What am I doing wrong! It's driving me crazy.
Thanks in advance,
Greg
--
http://mail.python.org/mailman/listinfo/python-list
Re: getting error...... Traceback (most recent call last): File "", line 1, in File "C:\Python25\Lib\site-packages\xlrd\__init__.py", line 370, in open_workbook biff_version = bk.getb
On Dec 8, 9:02 pm, John Machin <[EMAIL PROTECTED]> wrote:
> On Dec 9, 12:19 pm, JodyGnumeric <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Dec 8, 5:54 am, John Machin <[EMAIL PROTECTED]> wrote:
>
> > > On Dec 8, 6:48 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
>
> > > > En Fri, 05 Dec 2008 02:31:01 -0200, pk sahoo <[EMAIL PROTECTED]>
> > > > escribió:
>
> > > > > hallo everybody,
> > > > > when i am running the following command
>
> > > > >>>> import xlrd
> > > > >>>> book=xlrd.open_workbook("C:\\a.xls")
>
> > > > > i am getting the following error..
>
> > > > > *Traceback (most recent call last):
> > > > > File "", line 1, in
> > > > > File "C:\Python25\Lib\site-packages\xlrd\__init__.py", line 370, in
> > > > > open_workb
> > > > > ook
> > > > > biff_version = bk.getbof(XL_WORKBOOK_GLOBALS)
> > > > > File "C:\Python25\Lib\site-packages\xlrd\__init__.py", line 1323, in
> > > > > getbof
> > > > > raise XLRDError('Expected BOF record; found 0x%04x' % opcode)
> > > > > xlrd.biffh.XLRDError: Expected BOF record; found 0x3f3c*
>
> > > > Looks like your a.xls file is not an Excel file (one of the formats
> > > > supported by xlrd).
> > > > As 0x3f3c corresponds to the characters ' > > > file.
>
> > > This can be verified easily by opening the file with a simple-minded
> > > text editor (e.g. Notepad) ... if the first two lines are
> > > """
> > >
> > >
> > > """
> > > then it's an Excel 2003 XML Spreadsheet that's been manually(?)
> > > renamed from .xml to .xls.
>
> > > The current xlrd release supports only the binary ("BIFF") format .xls
> > > files created by Excel 3.0 to Excel 2003. The next release (due out
> > > Real Soon Now) will support Excel 2.1 and 2.0 formats [don't ask].
> > > Very soon after that will come support for Excel 2007 .xlsx which is a
> > > bunch of XML files inside a ZIP file. Support for Excel 2003
> > > "SpreadsheetML" is way down the to-do list.
>
> > > If the OP wants to be able to read the file with xlrd:
> > > (1) Open it with Excel 200[37] and save as a .xls file
> > > or (2) rename it to .xml, start OpenOffice.org Calc, click on File,
> > > click on Open, click on "Files of type", choose "Microsoft Excel 2003
> > > XML (*.xml)" from the (long, unsorted) drop-down list, ..., and save
> > > as etc etc. Gnumeric is not an option.
>
> > > HTH,
> > > John
>
> > Gnumeric can read this format. 'MS Excel (tm) 2003 SpreadsheetML'
>
> [Gnumeric 1.9.1 on Windows XP]
>
> I'm sorry; I thought I'd exhausted every possible way of trying to
> open it. After looking at the file open dialogue box again, I've
> spotted the "Advanced" button. Here is what you need to do:
>
> Have the file named whatever.xls. Click on File / Open , navigate to
> correct directory, click on Advanced, choose 'MS Excel (tm) 2003
> SpreadsheetML' from the File-type drop-down list, choose the file,
> click on OK. Anything else (Simple (non-Advanced), naming it
> whatever.xml, ...) produces no response, yes that's zero bits of
> information, not even a Bt! noise :-(
>
> *AND* when it does open up, a date cell defined by
>
> <NumberFormat ss:Format="Short Date"/>
>
> ...
> ss:Type="DateTime">1999-12-31T00:00:00.000
>
> is displayed as "00ort 31at1999" :-(
Please send the file to bugzilla.gnome.org it sounds like I need to
improve the probe function function for this format and add support
for the magic named formats.
--
http://mail.python.org/mailman/listinfo/python-list
Re: getting error...... Traceback (most recent call last): File "", line 1, in File "C:\Python25\Lib\site-packages\xlrd\__init__.py", line 370, in open_workbook biff_version = bk.getb
On Dec 9, 12:19 pm, JodyGnumeric <[EMAIL PROTECTED]> wrote:
> On Dec 8, 5:54 am, John Machin <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Dec 8, 6:48 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
>
> > > En Fri, 05 Dec 2008 02:31:01 -0200, pk sahoo <[EMAIL PROTECTED]>
> > > escribió:
>
> > > > hallo everybody,
> > > > when i am running the following command
>
> > > >>>> import xlrd
> > > >>>> book=xlrd.open_workbook("C:\\a.xls")
>
> > > > i am getting the following error..
>
> > > > *Traceback (most recent call last):
> > > > File "", line 1, in
> > > > File "C:\Python25\Lib\site-packages\xlrd\__init__.py", line 370, in
> > > > open_workb
> > > > ook
> > > > biff_version = bk.getbof(XL_WORKBOOK_GLOBALS)
> > > > File "C:\Python25\Lib\site-packages\xlrd\__init__.py", line 1323, in
> > > > getbof
> > > > raise XLRDError('Expected BOF record; found 0x%04x' % opcode)
> > > > xlrd.biffh.XLRDError: Expected BOF record; found 0x3f3c*
>
> > > Looks like your a.xls file is not an Excel file (one of the formats
> > > supported by xlrd).
> > > As 0x3f3c corresponds to the characters ' > > file.
>
> > This can be verified easily by opening the file with a simple-minded
> > text editor (e.g. Notepad) ... if the first two lines are
> > """
> >
> >
> > """
> > then it's an Excel 2003 XML Spreadsheet that's been manually(?)
> > renamed from .xml to .xls.
>
> > The current xlrd release supports only the binary ("BIFF") format .xls
> > files created by Excel 3.0 to Excel 2003. The next release (due out
> > Real Soon Now) will support Excel 2.1 and 2.0 formats [don't ask].
> > Very soon after that will come support for Excel 2007 .xlsx which is a
> > bunch of XML files inside a ZIP file. Support for Excel 2003
> > "SpreadsheetML" is way down the to-do list.
>
> > If the OP wants to be able to read the file with xlrd:
> > (1) Open it with Excel 200[37] and save as a .xls file
> > or (2) rename it to .xml, start OpenOffice.org Calc, click on File,
> > click on Open, click on "Files of type", choose "Microsoft Excel 2003
> > XML (*.xml)" from the (long, unsorted) drop-down list, ..., and save
> > as etc etc. Gnumeric is not an option.
>
> > HTH,
> > John
>
> Gnumeric can read this format. 'MS Excel (tm) 2003 SpreadsheetML'
[Gnumeric 1.9.1 on Windows XP]
I'm sorry; I thought I'd exhausted every possible way of trying to
open it. After looking at the file open dialogue box again, I've
spotted the "Advanced" button. Here is what you need to do:
Have the file named whatever.xls. Click on File / Open , navigate to
correct directory, click on Advanced, choose 'MS Excel (tm) 2003
SpreadsheetML' from the File-type drop-down list, choose the file,
click on OK. Anything else (Simple (non-Advanced), naming it
whatever.xml, ...) produces no response, yes that's zero bits of
information, not even a Bt! noise :-(
*AND* when it does open up, a date cell defined by
<NumberFormat ss:Format="Short Date"/>
...
1999-12-31T00:00:00.000
is displayed as "00ort 31at1999" :-(
--
http://mail.python.org/mailman/listinfo/python-list
