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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.