From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/3] graph-depends: split off get_version/get_depends into pkgutil.py
Date: Sun, 5 Feb 2017 22:31:39 +0100 [thread overview]
Message-ID: <20170205213139.GD3562@free.fr> (raw)
In-Reply-To: <CAAXf6LW+NGB4HrotxM8YCuW=UHDxkvL7bf2RNycJt=souyZ27A@mail.gmail.com>
Thomas DS, All,
On 2017-02-05 22:27 +0100, Thomas De Schampheleire spake thusly:
> On Sun, Feb 5, 2017 at 10:13 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > Thomas DS, All,
> >
> > On 2017-02-03 21:57 +0100, Thomas De Schampheleire spake thusly:
> > [--SNIP--]
> >> +import pkgutil
> >
> > So, I always claimed I was not a Python expoert, but should we not do:
> >
> > from okgutil import get_versions get_depends
> >
> > of something similar?
>
> Both methods are technically possible, and I think this is partially a
> matter of personal/project preference, and partially some general
> guidelines.
Ok for me, then.
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Regards,
Yann E. MORIN.
> When using 'import foo', any symbol used from foo needs to be
> qualified explicitly, i.e. foo.one, foo.two. You could consider it as
> making a namespace accessible but keeping everything inside that
> namespace.
>
> With 'from foo import one, two' you allow future usages to be done
> without referring to foo anymore. I consider it as 'using namespace
> foo' in C++ terminology.
>
> One could argue about performance of one vs the other, but I think it
> hardly matters (although I did never measure that).
>
> Personally, I'm more in favor of 'import foo' and keeping explicit
> references for following reasons:
> 1. it makes it clear inside the code where a symbol comes from -- in
> general I consider 'using namespace foo' a bad thing.
> 2. maintainability: if more functions are added to foo and used from a
> script, the list in the import statement becomes larger and larger, to
> possibly ridiculous proportions.
>
> There is one case where I do use 'from Foo import Foo' and that is
> when Foo is a class that is saved in its own equally-named file
> Foo.py. In this case, Foo.Foo seems a bit redundant and it makes sense
> to make the class Foo directly accessible.
>
> I found the following 100% reliable reference (ahum) about the topic:
> http://stackoverflow.com/questions/710551/import-module-or-from-module-import
>
>
> >
> > [--SNIP--]
> >> @@ -204,7 +157,7 @@ def get_all_depends(pkgs):
> >> if len(filtered_pkgs) == 0:
> >> return []
> >>
> >> - depends = get_depends(filtered_pkgs, rule)
> >> + depends = pkgutil.get_depends(filtered_pkgs, rule)
> >
> > And then just use get_depends here?
> >
> >> deps = set()
> >> for pkg in filtered_pkgs:
> >> @@ -377,7 +330,7 @@ if check_only:
> >> sys.exit(0)
> >>
> >> dict_deps = remove_extra_deps(dict_deps)
> >> -dict_version = get_version([pkg for pkg in allpkgs
> >> +dict_version = pkgutil.get_version([pkg for pkg in allpkgs
> >
> > Ditto?
> >
> >> if pkg != "all" and not pkg.startswith("root")])
> >>
> >> # Print the attributes of a node: label and fill-color
> >> diff --git a/support/scripts/pkgutil.py b/support/scripts/pkgutil.py
> >> new file mode 100644
> >> index 0000000..a911123
> >> --- /dev/null
> >> +++ b/support/scripts/pkgutil.py
> >> @@ -0,0 +1,55 @@
> >> +#!/usr/bin/env python
> >
> > As I understand it, this file is not supposed to be standalone, but just
> > a "library" of functions?
> >
> > So it should not need to have the sha-bang line, yes?
>
> Yes, you are right, that line is not necessary.
>
> >
> > Otherwise, I'm not opposed to this.
>
> Thanks!
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2017-02-05 21:31 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-03 20:57 [Buildroot] [PATCH 0/3] graph-depends: split off some functions to pkgutil.py Thomas De Schampheleire
2017-02-03 20:57 ` [Buildroot] [PATCH 1/3] graph-depends: avoid use of global var 'rule' in get_depends Thomas De Schampheleire
2017-02-05 14:20 ` Thomas Petazzoni
2017-02-05 20:37 ` Thomas De Schampheleire
2017-02-03 20:57 ` [Buildroot] [PATCH 1/1] support/scripts: split off get_version/get_depends into pkgutil.py Thomas De Schampheleire
2017-02-05 13:52 ` Thomas De Schampheleire
2017-02-03 20:57 ` [Buildroot] [PATCH 2/3] graph-depends: " Thomas De Schampheleire
2017-02-05 21:13 ` Yann E. MORIN
2017-02-05 21:27 ` Thomas De Schampheleire
2017-02-05 21:31 ` Yann E. MORIN [this message]
2017-02-06 12:49 ` Thomas Petazzoni
2018-11-07 18:07 ` Yann E. MORIN
2018-11-07 19:06 ` Thomas De Schampheleire
2018-11-07 19:39 ` Yann E. MORIN
2018-11-07 20:41 ` Thomas De Schampheleire
2018-11-07 21:06 ` Yann E. MORIN
2018-11-07 21:14 ` Thomas De Schampheleire
2018-11-07 22:26 ` Arnout Vandecappelle
2018-11-07 22:45 ` Yann E. MORIN
2018-11-08 8:01 ` Arnout Vandecappelle
2018-11-11 19:00 ` Yann E. MORIN
2017-02-03 20:57 ` [Buildroot] [PATCH 3/3] graph-depends: split off get_rdepends from get_depends Thomas De Schampheleire
2017-02-05 21:14 ` Yann E. MORIN
2017-02-06 12:50 ` Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170205213139.GD3562@free.fr \
--to=yann.morin.1998@free.fr \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox