Good programming style

Discussion in 'Python' started by Astley Le Jasper, Sep 12, 2008.

  1. I'm still learning python and would like to know what's a good way of
    organizing code.

    I am writing some scripts to scrape a number of different website that
    hold similar information and then collating it all together. Obviously
    each site needs to be handled differently, but once the information is
    collected then more generic functions can be used.

    Is it best to have it all in one script or split it into per site
    scripts that can then be called by a manager script? If everything is
    in one script would you have per site functions to extract the data or
    generic function that contain vary slightly depending on the site, for
    example

    import firstSiteScript
    import secondSiteScript

    firstsitedata = firstSiteScript.getData('search_str)
    secondsitedata = secondSiteScript.getData('search_str)
    etc etc

    OR

    def getFirstSiteData(search_str):
    etc etc
    def getSecondSiteData(search_str):
    etc etc

    OR

    def getdata(search_str, website):
    if website == 'firstsite':
    ....
    elif website =='secondsite':

    etc
     
    Astley Le Jasper, Sep 12, 2008
    #1
    1. Advertising

  2. Astley Le Jasper a écrit :
    > I'm still learning python and would like to know what's a good way of
    > organizing code.
    >
    > I am writing some scripts to scrape a number of different website that
    > hold similar information and then collating it all together. Obviously
    > each site needs to be handled differently, but once the information is
    > collected then more generic functions can be used.
    >
    > Is it best to have it all in one script or split it into per site
    > scripts that can then be called by a manager script?
    > If everything is
    > in one script would you have per site functions to extract the data or
    > generic function that contain vary slightly depending on the site,


    As far as I'm concerned, I'd choose the first solution. Decoupling
    what's varying (here, site-specific stuff) from "invariants" is so far
    the best way I know to keep complexity manageable.

    > for
    > example
    >
    > import firstSiteScript
    > import secondSiteScript
    >
    > firstsitedata = firstSiteScript.getData('search_str)
    > secondsitedata = secondSiteScript.getData('search_str)
    > etc etc


    Even better :

    - put generic functions in a 'generic' module
    - put all site-specific stuff each in it's own module in a specific
    'site_scripts' directory
    - in your 'main' script, scan the site_scripts directory to loop over
    site-specific modules, import them and run them (look for the __import__
    function).

    This is kind of a Q&D lightweight plugin system, that avoids having to
    hard-code imports and calls in the main script, so you just have to
    add/remove site-specific script to/from the site_scripts directory .

    Also, imported modules are not recompiled on each import - only when
    they change - while the 'main' script get recompiled on each invocation.

    (snip)

    > OR
    >
    > def getdata(search_str, website):
    > if website == 'firstsite':
    > ....
    > elif website =='secondsite':


    This one is IMHO the very worst thing to do.

    My 2 cents...
     
    Bruno Desthuilliers, Sep 12, 2008
    #2
    1. Advertising

  3. On 12 Sep, 12:44, Bruno Desthuilliers <bruno.
    > wrote:
    > Astley Le Jasper a écrit :
    >
    > > I'm still learning python and would like to know what's a good way of
    > > organizing code.

    >
    > > I am writing some scripts to scrape a number of different website that
    > > hold similar information and then collating it all together. Obviously
    > > each site needs to be handled differently, but once the information is
    > > collected then more generic functions can be used.

    >
    > > Is it best to have it all in one script or split it into per site
    > > scripts that can then be called by a manager script?
    > > If everything is
    > > in one script would you have per site functions to extract the data or
    > > generic function that contain vary slightly depending on the site,

    >
    > As far as I'm concerned, I'd choose the first solution. Decoupling
    > what's varying (here, site-specific stuff) from "invariants" is so far
    > the best way I know to keep complexity manageable.
    >
    > > for
    > > example

    >
    > > import firstSiteScript
    > > import secondSiteScript

    >
    > > firstsitedata = firstSiteScript.getData('search_str)
    > > secondsitedata = secondSiteScript.getData('search_str)
    > > etc etc

    >
    > Even better :
    >
    > - put generic functions in a 'generic' module
    > - put all site-specific stuff each in it's own module in a specific
    > 'site_scripts' directory
    > - in your 'main' script, scan the site_scripts directory to loop over
    > site-specific modules, import them and run them (look for the __import__
    > function).
    >
    > This is kind of a Q&D lightweight plugin system, that avoids having to
    > hard-code imports and calls in the main script, so you just have to
    > add/remove site-specific script to/from the site_scripts directory .
    >
    > Also, imported modules are not recompiled on each import - only when
    > they change - while the 'main' script get recompiled on each invocation.
    >
    > (snip)
    >
    > > OR

    >
    > > def getdata(search_str, website):
    > >   if website == 'firstsite':
    > >     ....
    > >   elif website =='secondsite':

    >
    > This one is IMHO the very worst thing to do.
    >
    > My 2 cents...


    Excellent, thanks for that.
     
    Astley Le Jasper, Sep 12, 2008
    #3
  4. Grant Edwards wrote:
    > When packages as significant as wxPython use naming conventions
    > other than PEP 8, I find it hard to make a case that the PEP 8
    > naming convention is any better than any other.


    This relates to a question I was thinking about...

    I'm looking at porting a library that was written for COM and .Net to
    work as a Python module, and was wondering whether it would be better to
    stick to the library's current naming convention so that the API is as
    similar as possible on each platform, or to adopt a "when in Rome..."
    policy and follow the "most mainstream" naming pattern for each
    platform/language.

    Adelle.
     
    Adelle Hartley, Sep 15, 2008
    #4
  5. Astley Le Jasper

    Sean DiZazzo Guest

    On Sep 14, 7:10 pm, Grant Edwards <> wrote:
    > On 2008-09-15, Ben Finney <> wrote:
    >
    >
    >
    > > Grant Edwards <> writes:
    > >> On 2008-09-14, Ben Finney <> wrote:

    >
    > >>> Second: please do yourself a favour and drop the
    > >>> camelCaseNames. Follow PEP 8
    > >>> <URL:http://www.python.org/dev/peps/pep-0008> for style and
    > >>> naming in your Python code.

    >
    > >> If he finds camelcase more readable and easier to type (as do
    > >> I), how is switching to underscores "doing himself a favor"?

    >
    > >> I'm generally in favor of using a consistent naming style
    > >> throughout a project, but I don't see why the naming style
    > >> used in my source code should be subject to somebody else's
    > >> arbitrary standard.

    >
    > > Because the code we write rarely stays isolated from other
    > > code. There is an existing convention,

    >
    > There are many existing conventions.
    >
    > > and it's better to pick a (sufficiently sane) style convention
    > > and stick to it than argue about what the convention should
    > > be.

    >
    > I suppose if everybody agreed to pick one, and all the source
    > code in the world was changed to meet it, that would "a good
    > thing".  It just seems like a goal so unrealistic as to make it
    > a bit of an overstatement to tell people they're better off
    > following convention X than following convention Y.
    >
    > When packages as significant as wxPython use naming conventions
    > other than PEP 8, I find it hard to make a case that the PEP 8
    > naming convention is any better than any other.
    >
    > >> When it comes to writing code intended for the standard
    > >> library in the main Python distribution, I would certainly
    > >> defer to the existing standard as defined in PEP 8.  However,
    > >> I don't see any reason that style should be imposed on all
    > >> everybody else.

    >
    > > Who's imposing? I'm saying it's a good idea for everyone to do
    > > it, and going so far as to say that one is doing oneself a
    > > favour by following the convention. I have no more power than
    > > you to "impose" convention on anyone.

    >
    > My apologies -- "impose" was too strong a word to use.
    >
    > If we were starting from scratch and there was no extant source
    > code in the world, then it would make sense to encourage
    > everybody to pick one convention. [I still think it would be
    > rather quixotic.] But, there are so many projects out there
    > with naming conventions other than PEP 8, that I don't see how
    > there's an advantage to picking one over another (except for
    > the obvious also-rans like "all upper case, no vowels, and a
    > maximum length of 6 characters").
    >
    > I'll agree that sticking with a single convention within a
    > project is definitely a good thing.
    >
    > I'm personally aware of mixed/camel-case projects from 25+
    > years ago, so I'm afraid PEP 8 came along a bit too late...
    >
    > --
    > Grant


    +1

    CamelCase FTW!

    ~Sean
     
    Sean DiZazzo, Sep 15, 2008
    #5
  6. On Sep 14, 9:07 pm, Grant Edwards <> wrote:
    > On 2008-09-15, Adelle Hartley <> wrote:
    >
    > > Grant Edwards wrote:

    >
    > >> When packages as significant as wxPython use naming
    > >> conventions other than PEP 8, I find it hard to make a case
    > >> that the PEP 8 naming convention is any better than any other.

    >
    > > This relates to a question I was thinking about...

    >
    > > I'm looking at porting a library that was written for COM and
    > > .Net to work as a Python module, and was wondering whether it
    > > would be better to stick to the library's current naming
    > > convention so that the API is as similar as possible on each
    > > platform, or to adopt a "when in Rome..." policy and follow
    > > the "most mainstream" naming pattern for each
    > > platform/language.

    >
    > If all that is would change is naming, then my advice would be
    > to keep the existing naming.  That way it matches existing
    > documentation and examples.  But, it does violate PEP 8.
    >
    > If the API itself is going to be changed significantly so that
    > it's unique to the Python port (different to the point where
    > existing documentation and examples are no longer useful), then
    > using standard PEP 8 naming conventions is probably a good choice.


    +1. Another factor is whether the original library's API is reasonably
    stable or it's expected to change significantly in the future. In the
    former case you may want to provide a more pythonic API, otherwise
    you'll have to do more work to keep in sync two separate APIs with
    every new version.

    George
     
    George Sakkis, Sep 15, 2008
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Fredrik Lundh
    Replies:
    4
    Views:
    428
  2. Sensei

    Good C programming style

    Sensei, Oct 7, 2005, in forum: C Programming
    Replies:
    43
    Views:
    1,209
    Chris Dollin
    Oct 11, 2005
  3. Ken Varn
    Replies:
    0
    Views:
    505
    Ken Varn
    Apr 26, 2004
  4. Vincent Foley
    Replies:
    2
    Views:
    140
    Ilmari Heikkinen
    Apr 29, 2005
  5. Replies:
    52
    Views:
    1,112
    88888 Dihedral
    Apr 6, 2013
Loading...

Share This Page