«

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 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...

On 12 Sep, 12:44, Bruno Desthuilliers <bruno.
42.desthuilli...@websiteburo.invalid> 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.

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.

On Sep 14, 7:10*pm, Grant Edwards <gra...@visi.com> wrote:
> On 2008-09-15, Ben Finney <bignose+hates-s...@benfinney.id.au> wrote:
>
>
>
> > Grant Edwards <gra...@visi.com> writes:
> >> On 2008-09-14, Ben Finney <bignose+hates-s...@benfinney.id.au> 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

On Sep 14, 9:07*pm, Grant Edwards <gra...@visi.com> wrote:
> On 2008-09-15, Adelle Hartley <ade...@akemi.com.au> 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