Re: python socket dns query will get the correct result while the dig will not.
On Wed, 2 Oct 2019 04:27:14 + (UTC)
Hongyi Zhao wrote:
> Hi,
>
> See my following test:
>
> With ipython:
>
> In [1]: import
> socket
>
> In [2]: socket.gethostbyname
> ('www.vpngate.net')
> Out[2]: '130.158.75.44'
>
I get '130.158.75.39' which is ok.
>
> With dig:
>
> $ dig www.vpngate.net @114.114.114.114 +short
This gives here:
130.158.75.48
130.158.75.42
130.158.75.35
130.158.75.36
130.158.75.44
130.158.75.40
130.158.75.39
130.158.75.38
--
Manfred
--
https://mail.python.org/mailman/listinfo/python-list
ipython in different loctions.
Hi,
I noticed that the ipython on my Debian box located in the following
locations:
werner@localhost:~$ ls .local/bin/ipython*
.local/bin/ipython .local/bin/ipython3
werner@localhost:~$ ls .pyenv/shims/ipython*
.pyenv/shims/ipython .pyenv/shims/ipython3
And, they are different:
werner@localhost:~$ diff .pyenv/shims/ipython3 .local/bin/ipython3
1,3c1
< #!/usr/bin/env bash
< set -e
< [ -n "$PYENV_DEBUG" ] && set -x
---
> #!/usr/bin/python3
5,18c3,5
< program="${0##*/}"
< if [[ "$program" = "python"* ]]; then
< for arg; do
< case "$arg" in
< -c* | -- ) break ;;
< */* )
< if [ -f "$arg" ]; then
< export PYENV_FILE_ARG="$arg"
< break
< fi
< ;;
< esac
< done
< fi
---
> # -*- coding: utf-8 -*-
> import re
> import sys
20,21c7,11
< export PYENV_ROOT="/home/werner/.pyenv"
< exec "/home/werner/.pyenv/libexec/pyenv" exec "$program" "$@"
---
> from IPython import start_ipython
>
> if __name__ == '__main__':
> sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
> sys.exit(start_ipython())
--
Any hints on this issue?
--
https://mail.python.org/mailman/listinfo/python-list
Re: pathlib
On 2/10/19 12:52 AM, Rhodri James wrote: On 01/10/2019 06:03, DL Neil via Python-list wrote: On 30/09/19 9:28 PM, Barry Scott wrote: On 30 Sep 2019, at 05:40, DL Neil via Python-list wrote: Should pathlib reflect changes it has made to the file-system? I think it should not. The term "concrete" is applied to Path(), PosixPath(), and WindowsPath() - whereas the others are differentiated with the prefix "Pure". I take "concrete" to mean 'existing in reality or real experience'. Thus, I saw the Pure* entities as supporting abstract paths, but the concrete entities as representing (and reflecting) real-world (file system) entities. Thus, there is no need for .exists() to be available in the Pure paths, but there is when utilising their concrete implementations. Sorry but your logic is inconsistent here. For starters, it's not that there's no need for .exists() in Pure paths, it's that .exists() is meaningless. Pure paths aren't related to any actual filing system (to paraphrase you), so existence isn't an option. However if you insist that "concrete" means "existing in reality", then .exists() is unnecessary because by your very definition the path must exist. The very act of creating the Path object would create the corresponding file or directory. So either pathlib does something horrific, or your definition is wrong. Very good! Yes, I'd picked-on .exists() purely (hah!) because it does not appear in PurePaths, but does in concrete Paths. 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? > Consider for a moment: > > rhodri@scrote:~$ cat /home/rhodri/foo.txt > cat: /home/rhodri/foo.txt: No such file or directory > > cat "concatenates files" to quote its man page. Does that mean it > creates them if they don't exist, just because I typed the name into the > command? No. I wouldn't expect it either. In exactly the same way I > don't expect a concrete file*name* to necessarily refer to an actual file. I haven't followed this point: throwing a non-existent file at cat produces an err.msg. Neither of us are surprised! However, we know exactly which path was/paths were used, and where (at least the first) error was found. In the case that sparked this enquiry, and in most others, there is no need for a path that doesn't actually lead somewhere. The paths that are used, identify files, open them, rename them, create directories, etc. The idea of a path that just 'exists' (sorry!), without being part of some purpose, seems odd. At this time (and assuming that after two (separate) incidents dragging me away to solve other people's problems, I intend to stick with trying to get my head around pathlib - even if I have to sub-class it (which my reading shows is another 'can of worms'). So, 'reading' is about all I've accomplished since the original post. Sadly, the majority of posts seem to have come from other confused-minds - many of whom seemed to be giving-up in disgust. If true, such represents TWO failures! I'm sure that the designer(s) had a clear vision (having watched previous attempts rise-and-fall), but per earlier in this discussion, maybe the explanation and 'vision' could be better communicated to us simple-boys? Regarding this discussion: I've been able to take points-raised and learn, even to decide on some tactics for future use. Thanks to all who have contributed wisdom... -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Recursive method in class
On 10/2/19 1:12 AM, ast wrote: > Le 01/10/2019 à 20:56, Timur Tabi a écrit : >> Could you please fix your email software so that it shows a legitimate >> email address in the From: line? Your emails all show this: >> >> From: ast >> >> All of your emails are being caught in my spam filter because of this >> address. I would email you privately, but I know [email protected] isn't >> your real email address. >> > > Do "legitimate" means and address with a dot ? > But your own email address doesn't have a dot. > > I don't want to show my real email address > because I don't want to be flooded with spam. > > I choose: [email protected] > Hope it will convenient for you > Legitimate means one that you 'own' or are authorized to use. If you have not registered with gmail this email address, then your use of it qualifies as abuse (as it may well be impersonation of someone else), and may be enough grounds for the service you are using for posting to permanently ban you from ever posting again. There are some domains specifically reserved so that purpose, like invalid. If you want to use an invalid email address, then you could use something like 'ast@invalid' or '[email protected]' and then you know that you can't be accidentally impersonating someone else. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Recursive method in class
On Wed, 2 Oct 2019 at 15:15, ast wrote: > Le 01/10/2019 à 20:56, Timur Tabi a écrit : > > Could you please fix your email software so that it shows a legitimate > > email address in the From: line? > I choose: [email protected] Hi ast, Please look here to see how your email looks on gmail: https://imgur.com/a/jqBNhLu This is how gmail shows you to everyone. gmail says: "ast uses a fake email address on our domain. It is a lie. So not trust him." The problem is that you use @gmail.com that is not owned by you and gmail tells the world about that. It makes you look bad. You should use .@invalid for this purpose. It will do what you want without making you look bad and annoying everyone that you try to talk with. -- https://mail.python.org/mailman/listinfo/python-list
Re: Recursive method in class
On Wed, Oct 2, 2019 at 9:01 PM David wrote: > > On Wed, 2 Oct 2019 at 15:15, ast wrote: > > Le 01/10/2019 à 20:56, Timur Tabi a écrit : > > > > Could you please fix your email software so that it shows a legitimate > > > email address in the From: line? > > > I choose: [email protected] > > Hi ast, > > Please look here to see how your email looks on gmail: > https://imgur.com/a/jqBNhLu > > This is how gmail shows you to everyone. gmail says: > "ast uses a fake email address on our domain. > It is a lie. So not trust him." > > The problem is that you use @gmail.com > > that is not owned by you and gmail tells the world > about that. It makes you look bad. > > You should use .@invalid for this purpose. > > It will do what you want without making you look > bad and annoying everyone that you try to > talk with. ... or, more likely: "without having all your posts silently discarded so people only notice when other people reply to you", which is how your posts appear - or don't - to me. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Recursive method in class
Le 02/10/2019 à 12:22, Richard Damon a écrit : On 10/2/19 1:12 AM, ast wrote: Le 01/10/2019 à 20:56, Timur Tabi a écrit : Could you please fix your email software so that it shows a legitimate email address in the From: line? Your emails all show this: From: ast All of your emails are being caught in my spam filter because of this address. I would email you privately, but I know [email protected] isn't your real email address. Do "legitimate" means and address with a dot ? But your own email address doesn't have a dot. I don't want to show my real email address because I don't want to be flooded with spam. I choose: [email protected] Hope it will convenient for you Legitimate means one that you 'own' or are authorized to use. If you have not registered with gmail this email address, then your use of it qualifies as abuse (as it may well be impersonation of someone else), and may be enough grounds for the service you are using for posting to permanently ban you from ever posting again. There are some domains specifically reserved so that purpose, like invalid. If you want to use an invalid email address, then you could use something like 'ast@invalid' or '[email protected]' and then you know that you can't be accidentally impersonating someone else. understood -- https://mail.python.org/mailman/listinfo/python-list
Re: pathlib
On 10/2/19 4:14 AM, DL Neil via Python-list wrote: In the case that sparked this enquiry, and in most others, there is no need for a path that doesn't actually lead somewhere. The paths that are used, identify files, open them, rename them, create directories, etc. The idea of a path that just 'exists' (sorry!), without being part of some purpose, seems odd. Think about preferences. Users can put preferences in (e.g.) ~/.config/prefs, admins might provide "local" preferences in /etc/prefs, and the developers might provide fallback preferences in /etc/prefs. When the application starts up, it could have a list of paths to files that may or may not exist. Or think about the shell in that failed "cat" command. It's possible that cat created a path from what the user typed and then tried to open it. For that brief moment, cat had a path to a file that didn't exist, however un-useful it may have been. At this time (and assuming that after two (separate) incidents dragging me away to solve other people's problems, I intend to stick with trying to get my head around pathlib - even if I have to sub-class it (which my reading shows is another 'can of worms'). So, 'reading' is about all I've accomplished since the original post. Sadly, the majority of posts seem to have come from other confused-minds - many of whom seemed to be giving-up in disgust. If true, such represents TWO failures! I'm sure that the designer(s) had a clear vision (having watched previous attempts rise-and-fall), but per earlier in this discussion, maybe the explanation and 'vision' could be better communicated to us simple-boys? I don't think anyone gave up in disgust. Yes, there was some disagreement, and now the discussion has slowed or stopped, but I think your original question was answered: Path objects, apparently by an arguably questionable design, fail to meet your expecation, and some simple changes end up breaking backwards compatibility. Maybe a documentation change could prevent others from experiencing the same expectation failure. Maybe you could implement one of the proposed changes in a private library function as a workaround? -- https://mail.python.org/mailman/listinfo/python-list
Re: pathlib
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.
--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list
Re: pymysql.err.InterfaceError after some hours of usage
Τη Τετάρτη, 2 Οκτωβρίου 2019 - 8:26:38 π.μ. UTC+3, ο χρήστης Inada Naoki έγραψε: > MySQL connection can be closed automatically by various reasons. > For example, `wait_timeout` is the most common but not only reason for > closing the connection. > > You should connect and close MySQL connection for each HTTP request. > > Or you can use more smart connection pool (e.g. Engine in SQLAlchemy). > It provides `pool_recycle` and `pool_pre_ping` options. > > https://docs.sqlalchemy.org/en/13/core/pooling.html#setting-pool-recycle You mean that every time i insrt/update and in general having a cur.execute() i then need to close the pymysql connection in order to not have this error? -- https://mail.python.org/mailman/listinfo/python-list
Re: pymysql.err.InterfaceError after some hours of usage
2019年10月3日(木) 0:56 Νίκος Βέργος : > Τη Τετάρτη, 2 Οκτωβρίου 2019 - 8:26:38 π.μ. UTC+3, ο χρήστης Inada Naoki > έγραψε: > > MySQL connection can be closed automatically by various reasons. > > For example, `wait_timeout` is the most common but not only reason for > > closing the connection. > > > > You should connect and close MySQL connection for each HTTP request. > > > > Or you can use more smart connection pool (e.g. Engine in SQLAlchemy). > > It provides `pool_recycle` and `pool_pre_ping` options. > > > > https://docs.sqlalchemy.org/en/13/core/pooling.html#setting-pool-recycle > > You mean that every time i insrt/update and in general having a > cur.execute() i then need to close the pymysql connection in order to not > have this error? > No, I meant one new DB connection for each HTTP request, not for each DB query. -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: pymysql.err.InterfaceError after some hours of usage
Τη Τετάρτη, 2 Οκτωβρίου 2019 - 7:11:52 μ.μ. UTC+3, ο χρήστης Inada Naoki έγραψε: > 2019年10月3日(木) 0:56 Νίκος Βέργος : > > > Τη Τετάρτη, 2 Οκτωβρίου 2019 - 8:26:38 π.μ. UTC+3, ο χρήστης Inada Naoki > > έγραψε: > > > MySQL connection can be closed automatically by various reasons. > > > For example, `wait_timeout` is the most common but not only reason for > > > closing the connection. > > > > > > You should connect and close MySQL connection for each HTTP request. > > > > > > Or you can use more smart connection pool (e.g. Engine in SQLAlchemy). > > > It provides `pool_recycle` and `pool_pre_ping` options. > > > > > > https://docs.sqlalchemy.org/en/13/core/pooling.html#setting-pool-recycle > > > > You mean that every time i insrt/update and in general having a > > cur.execute() i then need to close the pymysql connection in order to not > > have this error? > > > > No, I meant one new DB connection for each HTTP request, not for each DB > query. After seeing a stackoverflow link, it was stating that: This is caused by a global cursor. Try creating and closing the cursor within each method a raw query is needed. cursor = connection.cursor() cursor.execute(query) cursor.close() Does that mean that i have to create a cursor then execute the SQL statement and the close the cursor? And i must do that before and after executing each SQL statement in all of my scripts? Doesn't the DB Connection have a directive to autoclose the resources? -- https://mail.python.org/mailman/listinfo/python-list
Re: pathlib
> On 2 Oct 2019, at 09:14, DL Neil via Python-list > wrote: > > On 2/10/19 12:52 AM, Rhodri James wrote: >> On 01/10/2019 06:03, DL Neil via Python-list wrote: >>> On 30/09/19 9:28 PM, Barry Scott wrote: > On 30 Sep 2019, at 05:40, DL Neil via Python-list > wrote: > > Should pathlib reflect changes it has made to the file-system? I think it should not. >>> >>> The term "concrete" is applied to Path(), PosixPath(), and WindowsPath() - >>> whereas the others are differentiated with the prefix "Pure". >>> >>> I take "concrete" to mean 'existing in reality or real experience'. Thus, I >>> saw the Pure* entities as supporting abstract paths, but the concrete >>> entities as representing (and reflecting) real-world (file system) entities. >>> >>> Thus, there is no need for .exists() to be available in the Pure paths, but >>> there is when utilising their concrete implementations. >> Sorry but your logic is inconsistent here. For starters, it's not that >> there's no need for .exists() in Pure paths, it's that .exists() is >> meaningless. Pure paths aren't related to any actual filing system (to >> paraphrase you), so existence isn't an option. >> However if you insist that "concrete" means "existing in reality", then >> .exists() is unnecessary because by your very definition the path must >> exist. The very act of creating the Path object would create the >> corresponding file or directory. So either pathlib does something horrific, >> or your definition is wrong. > > > Very good! Yes, I'd picked-on .exists() purely (hah!) because it does not > appear in PurePaths, but does in concrete Paths. > > 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!). "concrete adj. Of or relating to an actual, specific thing or instance; particular. " > 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. Concrete means a specific operating system's filesystem rules, Windows or Posix. > > A definition/description would be useful. Any pointers? Barry -- https://mail.python.org/mailman/listinfo/python-list
Re: pathlib
On 3/10/19 6:25 AM, Barry Scott wrote: On 2 Oct 2019, at 09:14, DL Neil via Python-list mailto:[email protected]>> wrote: On 2/10/19 12:52 AM, Rhodri James wrote: On 01/10/2019 06:03, DL Neil via Python-list wrote: On 30/09/19 9:28 PM, Barry Scott wrote: On 30 Sep 2019, at 05:40, DL Neil via Python-list mailto:[email protected]>> wrote: Should pathlib reflect changes it has made to the file-system? I think it should not. The term "concrete" is applied to Path(), PosixPath(), and WindowsPath() - whereas the others are differentiated with the prefix "Pure". I take "concrete" to mean 'existing in reality or real experience'. Thus, I saw the Pure* entities as supporting abstract paths, but the concrete entities as representing (and reflecting) real-world (file system) entities. Thus, there is no need for .exists() to be available in the Pure paths, but there is when utilising their concrete implementations. Sorry but your logic is inconsistent here. For starters, it's not that there's no need for .exists() in Pure paths, it's that .exists() is meaningless. Pure paths aren't related to any actual filing system (to paraphrase you), so existence isn't an option. However if you insist that "concrete" means "existing in reality", then .exists() is unnecessary because by your very definition the path must exist. The very act of creating the Path object would create the corresponding file or directory. So either pathlib does something horrific, or your definition is wrong. Very good! Yes, I'd picked-on .exists() purely (hah!) because it does not appear in PurePaths, but does in concrete Paths. 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!). "concrete * adj. Of or relating to an actual, specific thing or instance; particular. " 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. Concrete means a specific operating system's filesystem rules, Windows or Posix. At last the gears have stopped grinding! (cement dust?) The distinction of "pure", as distinct from "concrete", was readily grasped. The idea that "concrete" refers to FS rules, cf files on the FS, has been what so many have been battling to lodge between my ears. Well done! Also, nicely stated. In view of my not being the only one to arrive with similar expectations, do you/we feel that this is carefully and sufficiently conveyed within the (PSL) documentation? -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: pathlib
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)!
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: pathlib
On 3/10/19 12:42 AM, Dan Sommers wrote: On 10/2/19 4:14 AM, DL Neil via Python-list wrote: In the case that sparked this enquiry, and in most others, there is no need for a path that doesn't actually lead somewhere. The paths that are used, identify files, open them, rename them, create directories, etc. The idea of a path that just 'exists' (sorry!), without being part of some purpose, seems odd. Think about preferences. Users can put preferences in (e.g.) ~/.config/prefs, admins might provide "local" preferences in /etc/prefs, and the developers might provide fallback preferences in /etc/prefs. When the application starts up, it could have a list of paths to files that may or may not exist. This is an excellent example. Without thinking I would have left such as-is. However, what I'm taking-in, is that in order to gain advantage from the semantic meaning inherent in the Path class(es), I shouldn't leave these as strings (the way they arrive from (current) config files*) but they should be defined as (Pure) Paths in the same way that numbers will probably be converted from string inputs. As you say, because system-defaults may be over-ridden by user-prefs, there's no point in 'proving' that such a file exists - such can wait until we actually issue the .open() That said, surely we would still use a 'concrete' class, in case? * in the case of YAML files, might we even be able to define those values as Path()-s... Or think about the shell in that failed "cat" command. It's possible that cat created a path from what the user typed and then tried to open it. For that brief moment, cat had a path to a file that didn't exist, however un-useful it may have been. At this time (and assuming that after two (separate) incidents dragging me away to solve other people's problems, I intend to stick with trying to get my head around pathlib - even if I have to sub-class it (which my reading shows is another 'can of worms'). So, 'reading' is about all I've accomplished since the original post. Sadly, the majority of posts seem to have come from other confused-minds - many of whom seemed to be giving-up in disgust. If true, such represents TWO failures! I'm sure that the designer(s) had a clear vision (having watched previous attempts rise-and-fall), but per earlier in this discussion, maybe the explanation and 'vision' could be better communicated to us simple-boys? I don't think anyone gave up in disgust. Yes, there was some Late at night: I used the word "posts" twice, to describe two quite different communications. Apologies The subject of that comment was the (other) research/reading I've been doing. No-one on THIS list has given the impression of wanting to dump pathlib (which encourages my persisting). 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! disagreement, and now the discussion has slowed or stopped, but > think your original question was answered: Path objects, apparently by an arguably questionable design, fail to meet your expecation, and some simple changes end up breaking backwards compatibility. Maybe a documentation change could prevent others from experiencing the same expectation failure. As discussed previously, and elsewhere (just now). 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). 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! 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... Thanks again! -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: ipython in different loctions.
On 02Oct2019 07:37, Hongyi Zhao wrote: I noticed that the ipython on my Debian box located in the following locations: werner@localhost:~$ ls .local/bin/ipython* .local/bin/ipython .local/bin/ipython3 werner@localhost:~$ ls .pyenv/shims/ipython* .pyenv/shims/ipython .pyenv/shims/ipython3 I would guess that the former came from "pip install ipython" and that the latter came from an an environment set up with pyenv. And, they are different: werner@localhost:~$ diff .pyenv/shims/ipython3 .local/bin/ipython3 1,3c1 < #!/usr/bin/env bash This is a small shell script wrapper, presumably hooking into your pyenv setup to find the "real" ipython. from IPython import start_ipython if __name__ == '__main__': sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0]) sys.exit(start_ipython()) This is the Python boilerplate wrapper with pip uses to install an ipython executable script in a bin directory. You may find that the shell script from .pyenv/shims eventually executes a python script like the one from .local/bin. Try going: bash -x ~/.pyenv/shims/ipython3 and see what its final command does. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: ipython in different loctions.
On Thu, 03 Oct 2019 10:19:23 +1000, Cameron Simpson wrote:
> bash -x ~/.pyenv/shims/ipython3
>
> and see what its final command does.
Tried as follows:
-
werner@localhost:~$ bash -x ~/.pyenv/shims/ipython3
+ set -e
+ '[' -n '' ']'
+ program=ipython3
+ [[ ipython3 = \p\y\t\h\o\n* ]]
+ export PYENV_ROOT=/home/werner/.pyenv
+ PYENV_ROOT=/home/werner/.pyenv
+ exec /home/werner/.pyenv/libexec/pyenv exec ipython3
Python 3.7.4 (default, Aug 29 2019, 06:59:32)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.8.0 -- An enhanced Interactive Python. Type '?' for help.
In [1]:
-
Also tried the follows:
werner@localhost:~$ bash -x ~/.local/bin/ipython3
+ import re
+ import sys
+ from IPython import start_ipython
from: can't read /var/mail/IPython
/home/werner/.local/bin/ipython3: line 10: syntax error near unexpected
token `('
/home/werner/.local/bin/ipython3: line 10: `sys.argv[0] = re.sub(r'(-
script\.pyw?|\.exe)?$', '', sys.argv[0])'
werner@localhost:~$
The former can start the ipython, while the latter will fail.
--
https://mail.python.org/mailman/listinfo/python-list
Basic python question
Hello, I am new to python and trying to do some basic things with python. I am writing a script that runs a df command and I need parts of that output saved in 2 different variables. Is this something that can be done? I can do this by running multiple df commands but would prefer to make only one call: -- inode_cmd = "/bin/df --output=pcent,ipcent /var| grep -v Use | tr '%' ' '" output = subprocess.check_output( inode_cmd, stderr=subprocess.STDOUT, shell=True ) -- But this would end up giving me the following: #df --output=pcent,ipcent /var | grep -v Use | tr '%' ' ' 5 1 I would like variable x to be 5 and variable y to be 1. Is there a easier way to do this? Thanks in advance for your guidance. -- https://mail.python.org/mailman/listinfo/python-list
Re: Basic python question
You could use: >>> x, y = set(output.split()) On Thu, Oct 3, 2019 at 11:44 AM Jagga Soorma wrote: > Hello, > > I am new to python and trying to do some basic things with python. I > am writing a script that runs a df command and I need parts of that > output saved in 2 different variables. Is this something that can be > done? I can do this by running multiple df commands but would prefer > to make only one call: > > -- > inode_cmd = "/bin/df --output=pcent,ipcent /var| grep -v Use | tr '%' ' '" > output = subprocess.check_output( inode_cmd, > stderr=subprocess.STDOUT, shell=True ) > -- > > But this would end up giving me the following: > > #df --output=pcent,ipcent /var | grep -v Use | tr '%' ' ' >5 1 > > I would like variable x to be 5 and variable y to be 1. Is there a > easier way to do this? > > Thanks in advance for your guidance. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Basic python question
Thanks Aldwin that helps but it looks like it is reversing the numbers for some reason: the df command returns the following: 7 2 I used your example and did: x,y = set(output.split()) My assumption would be that x should be 7 and y should be 2. However, when I print x and y it seems to be reversed (x is 2 and y is 7). Am I missing something? Thanks On Wed, Oct 2, 2019 at 8:49 PM Aldwin Pollefeyt wrote: > > You could use: > > >>> x, y = set(output.split()) > > On Thu, Oct 3, 2019 at 11:44 AM Jagga Soorma wrote: >> >> Hello, >> >> I am new to python and trying to do some basic things with python. I >> am writing a script that runs a df command and I need parts of that >> output saved in 2 different variables. Is this something that can be >> done? I can do this by running multiple df commands but would prefer >> to make only one call: >> >> -- >> inode_cmd = "/bin/df --output=pcent,ipcent /var| grep -v Use | tr '%' ' '" >> output = subprocess.check_output( inode_cmd, >> stderr=subprocess.STDOUT, shell=True ) >> -- >> >> But this would end up giving me the following: >> >> #df --output=pcent,ipcent /var | grep -v Use | tr '%' ' ' >>5 1 >> >> I would like variable x to be 5 and variable y to be 1. Is there a >> easier way to do this? >> >> Thanks in advance for your guidance. >> -- >> https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Basic python question
Oh, sorry .. please try this: >>> x,y = tuple(output.split()) On Thu, Oct 3, 2019 at 12:11 PM Jagga Soorma wrote: > Thanks Aldwin that helps but it looks like it is reversing the numbers > for some reason: > > the df command returns the following: > 7 2 > > I used your example and did: > x,y = set(output.split()) > > My assumption would be that x should be 7 and y should be 2. However, > when I print x and y it seems to be reversed (x is 2 and y is 7). Am > I missing something? > > Thanks > > On Wed, Oct 2, 2019 at 8:49 PM Aldwin Pollefeyt > wrote: > > > > You could use: > > > > >>> x, y = set(output.split()) > > > > On Thu, Oct 3, 2019 at 11:44 AM Jagga Soorma wrote: > >> > >> Hello, > >> > >> I am new to python and trying to do some basic things with python. I > >> am writing a script that runs a df command and I need parts of that > >> output saved in 2 different variables. Is this something that can be > >> done? I can do this by running multiple df commands but would prefer > >> to make only one call: > >> > >> -- > >> inode_cmd = "/bin/df --output=pcent,ipcent /var| grep -v Use | tr '%' ' > '" > >> output = subprocess.check_output( inode_cmd, > >> stderr=subprocess.STDOUT, shell=True ) > >> -- > >> > >> But this would end up giving me the following: > >> > >> #df --output=pcent,ipcent /var | grep -v Use | tr '%' ' ' > >>5 1 > >> > >> I would like variable x to be 5 and variable y to be 1. Is there a > >> easier way to do this? > >> > >> Thanks in advance for your guidance. > >> -- > >> https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Basic python question
Seems to work also: >>> [x,y] = output.split() On Thu, Oct 3, 2019 at 12:17 PM Aldwin Pollefeyt wrote: > Oh, sorry .. please try this: > > >>> x,y = tuple(output.split()) > > On Thu, Oct 3, 2019 at 12:11 PM Jagga Soorma wrote: > >> Thanks Aldwin that helps but it looks like it is reversing the numbers >> for some reason: >> >> the df command returns the following: >> 7 2 >> >> I used your example and did: >> x,y = set(output.split()) >> >> My assumption would be that x should be 7 and y should be 2. However, >> when I print x and y it seems to be reversed (x is 2 and y is 7). Am >> I missing something? >> >> Thanks >> >> On Wed, Oct 2, 2019 at 8:49 PM Aldwin Pollefeyt >> wrote: >> > >> > You could use: >> > >> > >>> x, y = set(output.split()) >> > >> > On Thu, Oct 3, 2019 at 11:44 AM Jagga Soorma wrote: >> >> >> >> Hello, >> >> >> >> I am new to python and trying to do some basic things with python. I >> >> am writing a script that runs a df command and I need parts of that >> >> output saved in 2 different variables. Is this something that can be >> >> done? I can do this by running multiple df commands but would prefer >> >> to make only one call: >> >> >> >> -- >> >> inode_cmd = "/bin/df --output=pcent,ipcent /var| grep -v Use | tr '%' >> ' '" >> >> output = subprocess.check_output( inode_cmd, >> >> stderr=subprocess.STDOUT, shell=True ) >> >> -- >> >> >> >> But this would end up giving me the following: >> >> >> >> #df --output=pcent,ipcent /var | grep -v Use | tr '%' ' ' >> >>5 1 >> >> >> >> I would like variable x to be 5 and variable y to be 1. Is there a >> >> easier way to do this? >> >> >> >> Thanks in advance for your guidance. >> >> -- >> >> https://mail.python.org/mailman/listinfo/python-list >> > -- https://mail.python.org/mailman/listinfo/python-list
Re: Basic python question
Thanks again Aldwin. This seems to work, guess it is the set that is flipping the numbers: x,y = (output.split()) Much appreciated! On Wed, Oct 2, 2019 at 9:19 PM Aldwin Pollefeyt wrote: > > Seems to work also: > > >>> [x,y] = output.split() > > On Thu, Oct 3, 2019 at 12:17 PM Aldwin Pollefeyt > wrote: >> >> Oh, sorry .. please try this: >> >> >>> x,y = tuple(output.split()) >> >> On Thu, Oct 3, 2019 at 12:11 PM Jagga Soorma wrote: >>> >>> Thanks Aldwin that helps but it looks like it is reversing the numbers >>> for some reason: >>> >>> the df command returns the following: >>> 7 2 >>> >>> I used your example and did: >>> x,y = set(output.split()) >>> >>> My assumption would be that x should be 7 and y should be 2. However, >>> when I print x and y it seems to be reversed (x is 2 and y is 7). Am >>> I missing something? >>> >>> Thanks >>> >>> On Wed, Oct 2, 2019 at 8:49 PM Aldwin Pollefeyt >>> wrote: >>> > >>> > You could use: >>> > >>> > >>> x, y = set(output.split()) >>> > >>> > On Thu, Oct 3, 2019 at 11:44 AM Jagga Soorma wrote: >>> >> >>> >> Hello, >>> >> >>> >> I am new to python and trying to do some basic things with python. I >>> >> am writing a script that runs a df command and I need parts of that >>> >> output saved in 2 different variables. Is this something that can be >>> >> done? I can do this by running multiple df commands but would prefer >>> >> to make only one call: >>> >> >>> >> -- >>> >> inode_cmd = "/bin/df --output=pcent,ipcent /var| grep -v Use | tr '%' ' >>> >> '" >>> >> output = subprocess.check_output( inode_cmd, >>> >> stderr=subprocess.STDOUT, shell=True ) >>> >> -- >>> >> >>> >> But this would end up giving me the following: >>> >> >>> >> #df --output=pcent,ipcent /var | grep -v Use | tr '%' ' ' >>> >>5 1 >>> >> >>> >> I would like variable x to be 5 and variable y to be 1. Is there a >>> >> easier way to do this? >>> >> >>> >> Thanks in advance for your guidance. >>> >> -- >>> >> https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
