Re: Basic python question

[Peter Otten]

Jagga Soorma wrote:

> Thanks again Aldwin.  This seems to work, guess it is the set that is
> flipping the numbers:
> 
> x,y = (output.split())

The parens on the right are superfluous:

>>> a, b = "foo bar".split()
>>> a
'foo'
>>> b
'bar'

> inode_cmd = "/bin/df --output=pcent,ipcent /var| grep -v Use | tr '%' ' '"
> output  = subprocess.check_output( inode_cmd,
> stderr=subprocess.STDOUT, shell=True )

You may also do the post-processing in Python, which allows you to avoid the 
shell completely:

>>> output = subprocess.check_output(["/bin/df", "--output=pcent,ipcent", 
"/var"])
>>> output
b'Use% IUse%\n 85%   16%\n'
>>> a, b = output.replace(b"%", b"").split()[-2:]
>>> a
b'85'
>>> b
b'16'

If you want integers:

>>> a, b = [int(v) for v in output.replace(b"%", b"").split()[-2:]]
>>> a
85
>>> b
16


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pathlib

[Dan Sommers]

On 10/2/19 6:58 PM, DL Neil via Python-list wrote:
> On 3/10/19 12:42 AM, Dan Sommers wrote:

> Certainly, although some may have quietly given-up talking to a
> non-OOP native - and one so 'slow', I am appreciative of all
> help-given!

I also speak OO as a second language (usually kicking, screaming, and
spouting expletives, but that's my personal perspective and a separate
issue).  Hold this thought.

>> Maybe you could implement one of the proposed changes in a private
>> library function as a workaround?

> In my mind, I'm wondering if it will come to that (having 'got past'
> the original observation/issue, I'm concerned by .rename()'s silent
> errors, for example). However, that 'outside' research, eg
> StackOverflow, shows that sub-classing pathlib is problematic, and
> quite possibly not part of the design (this is repeating 'gossip' -
> I'm not going to try to justify the comment or the claim) ...

So don't subclass anything.  :-)

One non-OO option would be to write a function that takes a Path
instance and a new name, calls Path.rename, and returns a new Path
instance with the new name, something like this (untested):

def path_rename(path, target):
new_path = pathlib.Path(target)
path.rename(new_path)
return new_path

Because it returns a new Path instance rather than mutating an existing
one, you may have to re-think parts of your application that depend on a
specific Path instance being mutated.

The usual OO option that doesn't involve subclassing is Delegation, with
a capital D.  See ,
and see Mhttps://softwareengineering.stackexchange.com/questions/381140>
for python-specific objections.

> ... That said, last night my code sub-classing Path() seemed to work
> quite happily (albeit only tested on a 'Posix' box). The yawning
> chasm/gaping jaws below, however, are that I've probably made yet
> another 'assumption' about how things 'should' work.  Run for the
> hills!

Your caution regarding an assumption is a Good Thing.  Tests, tests, and
more tests.  Document (in large, friendly lettering) that you haven't
tested in a non-Posix environment.

> This was supposed to be a simple, down-time task; a
> learning-opportunity re-factoring code to use a new (er, um, as of
> v3.4) library...

The best laid plans  :-)
--
https://mail.python.org/mailman/listinfo/python-list

Re: pathlib

[Richard Damon]

On 10/2/19 6:27 PM, DL Neil via Python-list wrote:
> On 3/10/19 3:07 AM, Rhodri James wrote:
>> On 02/10/2019 09:14, DL Neil via Python-list wrote:
>>> That said, it is one of the ways that a path can be shown to
>>> transition from some 'pure' state to become 'concrete'.
>>>
>>> However, A.N.Other has suggested that I might be mis-applying the
>>> word "concrete", so maybe not. On which topic, I went looking for a
>>> decent technical definition of the word, but instead of coming-out
>>> smiling, I've been left somewhat stony-faced (hah, hah!).
>>>
>>> A definition/description would be useful. Any pointers?
>>
>> I think we're looking at a philosophical split, so I'd look in that
>> direction rather than for technical terminology.
>>
>> My rough and ready definition *in this instance* relies on observing
>> that we are supposed to contrast "pure" and "concrete" and going from
>> there.
>>
>> The overriding thing for me is that paths are names.  Just names. 
>> They have a particular syntax, but that's all.  This is obviously
>> true for pure paths, which are clearly abstractions.
>> PurePath("/home/rhodri/foo.txt") cannot refer to a real file because
>> it has no mechanisms for relating to reality.  It can only be a name,
>> and all the PurePath class gives us is convenient mechanisms for
>> manipulating that name within its syntactic rules.
>>
>> Concrete paths are not pure paths.  Literally, in logic terms.  Pure
>> paths cannot refer to real file, concrete paths can refer to real
>> files.   They don't necessarily do so otherwise we have a massive
>> excluded middle.  Path("/home/rhodri/foo.txt") may or may not
>> actually exist on any computer.  It may refer to a file, and by the
>> end of this sentence it may refer to a different file to what it was
>> at the start.  The only sensible interpretation I can see is that it
>> is still a name, just one that may transiently be related to a real
>> object.
>>
>> Concrete may not be the best term for this, but I can't think of a
>> better one.
>
>
> Nor I, but had assumed (having seen it before) that it was a
> generally-accepted term in OOP that I have yet to learn. Was slightly
> surprised not to find it in any of the/my usual tech.dictionaries.
>
> Obviously, my assumptions/expectations of its meaning were inaccurate
> or incomplete, but I appreciate your efforts to straighten-out it (and
> me)!

My experience is that Concrete is generally thought of as the opposite
of Abstract, you can make an object of a Concrete type, but not one of
an Abstract type. That doesn't quite apply here as PurePath isn't an
Abstract class in this sense, as you CAN create objects of type
PurePath. An Abstract class would be something like Iterable which is
(as far as I know) an Abstract Base Class which objects can have as a
'base' but can't be just of that type.

I am not sure that Concrete is really the right term here, but the
beginning of the documentation for Pathlib does sort of define what it
means here:

Path classes are divided between pure paths
, which
provide purely computational operations without I/O, and concrete paths
, which
inherit from pure paths but also provide I/O operations.

So for Pathlib, Concrete means that it provides access to I/O operations
and thus can only handle paths of the flavor of the OS the program is
running on.

-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list

uses both shell and python codes in one script.

[Hongyi Zhao]

See this file:

https://github.com/hongyi-zhao/dotbot/blob/master/bin/dotbot

It uses both shell and python codes in one script, is this good practice? 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: uses both shell and python codes in one script.

[Chris Angelico]

On Thu, Oct 3, 2019 at 10:51 PM Hongyi Zhao  wrote:
>
> See this file:
>
> https://github.com/hongyi-zhao/dotbot/blob/master/bin/dotbot
>
> It uses both shell and python codes in one script, is this good practice?

Seems fine. Most of the code is elsewhere, and presumably has been
written to support both Py2 and Py3; the file you're linking to is
*just* a wrapper that finds an interpreter to use.

Though this should be unnecessary. A simple shebang of "/usr/bin/env
python3" will suffice for many many situations (and then if someone
specifically wants to run it in a legacy interpreter, an explicit
"python2 scriptname.py" or "python scriptname.py" will work).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: uses both shell and python codes in one script.

[Hongyi Zhao]

On Thu, 03 Oct 2019 23:12:45 +1000, Chris Angelico wrote:


> Seems fine. Most of the code is elsewhere, and presumably has been
> written to support both Py2 and Py3; the file you're linking to is
> *just* a wrapper that finds an interpreter to use.
> 
> Though this should be unnecessary. A simple shebang of "/usr/bin/env
> python3" will suffice for many many situations (and then if someone
> specifically wants to run it in a legacy interpreter, an explicit
> "python2 scriptname.py" or "python scriptname.py" will work).

I'm very confusing on the following part in this script:


''':' # begin python string; this line is interpreted by the shell as `:`
which python  >/dev/null 2>&1 && exec python  "$0" "$@"
which python3 >/dev/null 2>&1 && exec python3 "$0" "$@"
which python2 >/dev/null 2>&1 && exec python2 "$0" "$@"
>&2 echo "error: cannot find python"
exit 1
'''


Any hints for the meaning of several ' used above?

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: uses both shell and python codes in one script.

[Chris Angelico]

On Thu, Oct 3, 2019 at 11:41 PM Hongyi Zhao  wrote:
>
> On Thu, 03 Oct 2019 23:12:45 +1000, Chris Angelico wrote:
>
>
> > Seems fine. Most of the code is elsewhere, and presumably has been
> > written to support both Py2 and Py3; the file you're linking to is
> > *just* a wrapper that finds an interpreter to use.
> >
> > Though this should be unnecessary. A simple shebang of "/usr/bin/env
> > python3" will suffice for many many situations (and then if someone
> > specifically wants to run it in a legacy interpreter, an explicit
> > "python2 scriptname.py" or "python scriptname.py" will work).
>
> I'm very confusing on the following part in this script:
>
> 
> ''':' # begin python string; this line is interpreted by the shell as `:`
> which python  >/dev/null 2>&1 && exec python  "$0" "$@"
> which python3 >/dev/null 2>&1 && exec python3 "$0" "$@"
> which python2 >/dev/null 2>&1 && exec python2 "$0" "$@"
> >&2 echo "error: cannot find python"
> exit 1
> '''
> 
>
> Any hints for the meaning of several ' used above?
>

The hint is there in that line, and stems from the way two different
parsers (Python and sh) interpret the line. In Python, three single
quote characters start a triple-quoted string, which doesn't end till
you get three more; since nothing is done with this string, Python
parses it and then ignores it. In the shell, the first two are an
empty string, then ':' is a colon, which introduces a label (the fact
that it's in quotes is irrelevant to the shell). So there's an empty
label followed by a shell comment. The shell parses this line and does
nothing with it. Then it moves on to the next lines, and runs the
shell script. Since this shell script ends with 'exit 1', it's
guaranteed to halt execution (and usually it'll exec to python, which
also halts execution), so the Python code won't be executed.

This is a common trick when writing polyglot code. You make the
relevant code for one language appear as a comment or string literal
in another. For instance, you can open a C program with "#if 0", which
will cause the following text to be ignored by the C preprocessor; but
since that line begins with a hash, Python will ignore it (but
continue executing).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: uses both shell and python codes in one script.

[James Lu]

I would use IPython as a scripting language. It has a slow startup time
though.

On Thu, Oct 3, 2019 at 9:59 AM Chris Angelico  wrote:

> On Thu, Oct 3, 2019 at 11:41 PM Hongyi Zhao  wrote:
> >
> > On Thu, 03 Oct 2019 23:12:45 +1000, Chris Angelico wrote:
> >
> >
> > > Seems fine. Most of the code is elsewhere, and presumably has been
> > > written to support both Py2 and Py3; the file you're linking to is
> > > *just* a wrapper that finds an interpreter to use.
> > >
> > > Though this should be unnecessary. A simple shebang of "/usr/bin/env
> > > python3" will suffice for many many situations (and then if someone
> > > specifically wants to run it in a legacy interpreter, an explicit
> > > "python2 scriptname.py" or "python scriptname.py" will work).
> >
> > I'm very confusing on the following part in this script:
> >
> > 
> > ''':' # begin python string; this line is interpreted by the shell as `:`
> > which python  >/dev/null 2>&1 && exec python  "$0" "$@"
> > which python3 >/dev/null 2>&1 && exec python3 "$0" "$@"
> > which python2 >/dev/null 2>&1 && exec python2 "$0" "$@"
> > >&2 echo "error: cannot find python"
> > exit 1
> > '''
> > 
> >
> > Any hints for the meaning of several ' used above?
> >
>
> The hint is there in that line, and stems from the way two different
> parsers (Python and sh) interpret the line. In Python, three single
> quote characters start a triple-quoted string, which doesn't end till
> you get three more; since nothing is done with this string, Python
> parses it and then ignores it. In the shell, the first two are an
> empty string, then ':' is a colon, which introduces a label (the fact
> that it's in quotes is irrelevant to the shell). So there's an empty
> label followed by a shell comment. The shell parses this line and does
> nothing with it. Then it moves on to the next lines, and runs the
> shell script. Since this shell script ends with 'exit 1', it's
> guaranteed to halt execution (and usually it'll exec to python, which
> also halts execution), so the Python code won't be executed.
>
> This is a common trick when writing polyglot code. You make the
> relevant code for one language appear as a comment or string literal
> in another. For instance, you can open a C program with "#if 0", which
> will cause the following text to be ignored by the C preprocessor; but
> since that line begins with a hash, Python will ignore it (but
> continue executing).
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: uses both shell and python codes in one script.

[Michael Torrie]

On 10/3/19 8:15 AM, James Lu wrote:
> I would use IPython as a scripting language. It has a slow startup time
> though.

Lately I've been using Xonsh, which is a much more comfortable
application of Python to shell scripting than anything else I've tried.
Occasionally subprocess mode selection vs Python mode might seem a bit
magical, and that bothers me a bit. But overall I've begun using it for
many of my shell scripts now.  I don't find startup to be any slower
than any other python script I've written.

I've thought about using Xonsh as my main shell, but for now I'm still
using Zsh.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: uses both shell and python codes in one script.

[Chris Angelico]

On Fri, Oct 4, 2019 at 12:15 AM James Lu  wrote:
>
> I would use IPython as a scripting language. It has a slow startup time 
> though.
>
And how, in the messy world of cross-platform scripting, would you
locate the interpreter? The whole point of this script is to attempt
three different shebangs, effectively.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

how can i run python script in spamassassin

[Doris Marca Guaraca]

Hello, I'm sorry to bother you, I just reviewed this post, the Python beginner, 
the Linux beginner, needs to run spamassassin, and now I'm trying to do 
something very similar with a Python script is for a project, maybe you can 
help me thanks.

I appreciate it a lot.

Regards
Doris

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how can i run python script in spamassassin

[Michael Torrie]

On 10/3/19 1:10 PM, Doris Marca Guaraca wrote:
> 
> Hello, I'm sorry to bother you, I just reviewed this post, the Python 
> beginner, the Linux beginner, needs to run spamassassin, and now I'm trying 
> to do something very similar with a Python script is for a project, maybe you 
> can help me thanks.

I haven't looked deeply at Spamassassin for a long time (nearly 10
years), but last time I worked with it, it was written entirely in Perl
and at that time there was no built-in facility to call out to external
programs or scripts.  The only way to do that would be to write an
extension module for Spamassassin in Perl that would run the external
script and communicate with it somehow.

Actually I'm not even sure what you're asking.  Are you trying to run a
python script from Spamassassin? If so, what are you trying to accomplish?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how can i run python script in spamassassin

[Skip Montanaro]

Check out SpamBayes. It runs on Linux and is written in Python. Like
Spamassasin, it has no plugin architecture, but perhaps you'll discover you
don't need it, or can more easily tweak SpamBayes to call your external
script.

Skip


On Thu, Oct 3, 2019, 2:15 PM Doris Marca Guaraca 
wrote:

>
> Hello, I'm sorry to bother you, I just reviewed this post, the Python
> beginner, the Linux beginner, needs to run spamassassin, and now I'm trying
> to do something very similar with a Python script is for a project, maybe
> you can help me thanks.
>
> I appreciate it a lot.
>
> Regards
> Doris
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: uses both shell and python codes in one script.

[Cameron Simpson]

On 03Oct2019 23:55, Chris Angelico  wrote:

On Thu, Oct 3, 2019 at 11:41 PM Hongyi Zhao  wrote:

I'm very confusing on the following part in this script:


''':' # begin python string; this line is interpreted by the shell as `:`
which python  >/dev/null 2>&1 && exec python  "$0" "$@"
which python3 >/dev/null 2>&1 && exec python3 "$0" "$@"
which python2 >/dev/null 2>&1 && exec python2 "$0" "$@"
>&2 echo "error: cannot find python"
exit 1
'''


Any hints for the meaning of several ' used above?


The hint is there in that line, and stems from the way two different
parsers (Python and sh) interpret the line. [...]

In the shell, the first two are an
empty string, then ':' is a colon, which introduces a label (the fact
that it's in quotes is irrelevant to the shell). So there's an empty
label followed by a shell comment.


No. ":" is a synonym for "true". (Like "[" is a synonym for "test".)

There aren't labels in the shell. This is just a dummy "true" command, 
with a comment.


Since I'm here, I'll seize the opportunity to endorse Chris' earlier 
statement: just use "#!/usr/bin/env python3" as the opening shebang line 
and don't worry about embedding complex shell to "locate" python.  
Instead, expect the caller's environment to be correctly set up, and 
therefore for the "python3" command to find the preferred python 
interpreter.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: uses both shell and python codes in one script.

[Cameron Simpson]

On 04Oct2019 03:34, Chris Angelico  wrote:

On Fri, Oct 4, 2019 at 12:15 AM James Lu  wrote:
I would use IPython as a scripting language. It has a slow startup 
time though.



And how, in the messy world of cross-platform scripting, would you
locate the interpreter? The whole point of this script is to attempt
three different shebangs, effectively.


Well, yes, but personally I'd prefer to just run with "#!/usr/bin/env 
python3". Then the command line will say "python3: not found" or 
similar, I can fix my environment, and thereafter everything works 
better. Rather than complex magic inside a script.


If we're going to accept the approach though, I'd rather the shebang was 
just "#!/bin/sh". There's _always_ a /bin/sh, and a number of BSDish 
systems do not have a /usr/bin/env (it tends to land in /bin instead).


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: uses both shell and python codes in one script.

[Chris Angelico]

On Fri, Oct 4, 2019 at 9:08 AM Cameron Simpson  wrote:
>
> On 03Oct2019 23:55, Chris Angelico  wrote:
> >On Thu, Oct 3, 2019 at 11:41 PM Hongyi Zhao  wrote:
> >> I'm very confusing on the following part in this script:
> >>
> >> 
> >> ''':' # begin python string; this line is interpreted by the shell as `:`
> >> which python  >/dev/null 2>&1 && exec python  "$0" "$@"
> >> which python3 >/dev/null 2>&1 && exec python3 "$0" "$@"
> >> which python2 >/dev/null 2>&1 && exec python2 "$0" "$@"
> >> >&2 echo "error: cannot find python"
> >> exit 1
> >> '''
> >> 
> >>
> >> Any hints for the meaning of several ' used above?
> >
> >The hint is there in that line, and stems from the way two different
> >parsers (Python and sh) interpret the line. [...]
> >
> >In the shell, the first two are an
> >empty string, then ':' is a colon, which introduces a label (the fact
> >that it's in quotes is irrelevant to the shell). So there's an empty
> >label followed by a shell comment.
>
> No. ":" is a synonym for "true". (Like "[" is a synonym for "test".)
>
> There aren't labels in the shell. This is just a dummy "true" command,
> with a comment.

My bad. I remember using a leading colon-space as a multi-shell
comment, and in at least some of them, it's a label (probably old
MS-DOS batch files or something, given what my background is). In any
case, that one line does nothing, but the subsequent lines are
meaningful.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: uses both shell and python codes in one script.

[Chris Angelico]

On Fri, Oct 4, 2019 at 9:13 AM Cameron Simpson  wrote:
>
> On 04Oct2019 03:34, Chris Angelico  wrote:
> >On Fri, Oct 4, 2019 at 12:15 AM James Lu  wrote:
> >> I would use IPython as a scripting language. It has a slow startup
> >> time though.
> >>
> >And how, in the messy world of cross-platform scripting, would you
> >locate the interpreter? The whole point of this script is to attempt
> >three different shebangs, effectively.
>
> Well, yes, but personally I'd prefer to just run with "#!/usr/bin/env
> python3". Then the command line will say "python3: not found" or
> similar, I can fix my environment, and thereafter everything works
> better. Rather than complex magic inside a script.
>
> If we're going to accept the approach though, I'd rather the shebang was
> just "#!/bin/sh". There's _always_ a /bin/sh, and a number of BSDish
> systems do not have a /usr/bin/env (it tends to land in /bin instead).

My point was that ipython solves nothing. The whole point of merging
shell and Python was to prepare the environment for the REAL app,
which is pure Python; so using ipython would add a costly dependency
without actually helping in any way. Just run it in Python and that's
that.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: uses both shell and python codes in one script.

[Cameron Simpson]

On 04Oct2019 09:17, Chris Angelico  wrote:

On Fri, Oct 4, 2019 at 9:13 AM Cameron Simpson  wrote:
If we're going to accept the approach though, I'd rather the shebang 
was

just "#!/bin/sh". There's _always_ a /bin/sh, and a number of BSDish
systems do not have a /usr/bin/env (it tends to land in /bin instead).


My point was that ipython solves nothing. The whole point of merging
shell and Python was to prepare the environment for the REAL app,
which is pure Python; so using ipython would add a costly dependency
without actually helping in any way. Just run it in Python and that's
that.


+1

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list