Re: Custom logging function
[email protected] wrote: > Hi, > > I have a case in which I have to use custom function for logging. > For example, all messages should go to stderr and end with '\r\n'. > > Can I somehow use standard python logging module but send all message to > stderr with '\r\n' line endings? Isn't that the default for windows? For unix you can reconfigure stdout sys.stdout.reconfigure(newline="\r\n") or set the terminator attribute of the handler: >>> import logging Here we should build a stream handler explicitly -- but I'm lazy and modify the one created by basicConfig(). >>> logging.basicConfig() >>> [handler] = logging.getLogger().handlers >>> handler.terminator '\n' >>> logging.warning("Default line endings.") WARNING:root:Default line endings. Let's choose something fancy so that you can see the effect: >>> handler.terminator = " -- here be dragons\r\n" >>> logging.warning("Unusual line endings.") WARNING:root:Unusual line endings. -- here be dragons -- https://mail.python.org/mailman/listinfo/python-list
Behaviour of os.path.join
I came across an issue that I am wondering whether I should report as an issue. If I have a directory, say: base='C:\\Documents' and I use os.path.join() as follows: join(base, '..\\..\\', 'build', '') I obtain as expected from the documentation: 'C:\\Documents\\..\\..\\build\\' But if I try to make the directory myself (as I tried first): join(base, '..\\..\\', 'build', '\\') I obtain: 'C:\\' The documentation says that an absolute path in the parameter list for join will discard all previous parameters but '\\' is not an absoute path! Moreover, if I use join(base, '..\\..\\', 'build', os.sep) I get the same result. This seems to me to be a bug that I should report but to avoid wasting developer time I wanted to hear what others feel about this. -- https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
BlindAnagram writes: > I came across an issue that I am wondering whether I should report as an > issue. If I have a directory, say: > > base='C:\\Documents' > > and I use os.path.join() as follows: > > join(base, '..\\..\\', 'build', '') It rather defeats the purpose of os.sep if you include it in a part of the path. What you mean is better expressed as join(base, '..', '..', 'build', '') (and base includes it too, but I can't suggest an alternative because I don't know your intent is far as defaults go.) > The documentation says that an absolute path in the parameter list for > join will discard all previous parameters but '\\' is not an absoute > path! I think it is. The picture is messy on Windows (because of the drive letter) but absolute paths are usually taken to be those that start with a path separator. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 26/05/2020 16:22, Ben Bacarisse wrote: > BlindAnagram writes: > >> I came across an issue that I am wondering whether I should report as an >> issue. If I have a directory, say: >> >> base='C:\\Documents' >> >> and I use os.path.join() as follows: >> >> join(base, '..\\..\\', 'build', '') > > It rather defeats the purpose of os.sep if you include it in a part of > the path. What you mean is better expressed as > > join(base, '..', '..', 'build', '') > > (and base includes it too, but I can't suggest an alternative because I > don't know your intent is far as defaults go.) Thanks for your input but while that part of my path may not be to your liking, it works fine and does not seem to be relevant to my concern, which is that join appears to treat os.sep as an absolute path, which it is not. -- https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 26/05/2020 16:25, Stefan Ram wrote: > BlindAnagram writes: >> The documentation says that an absolute path in the parameter list for >> join will discard all previous parameters but '\\' is not an absoute path! > > The source code for "join" in "ntpath.py" does not seem to > bother to call "is_absolute". Instead it contains (simplified): > > seps = '\\/' > if p_path and p_path[0] in seps: > # Second path is absolute Thanks, that seems to confirm this as a bug. -- https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 5/26/20 8:56 AM, BlindAnagram wrote: > I came across an issue that I am wondering whether I should report as an > issue. If I have a directory, say: > > base='C:\\Documents' > > and I use os.path.join() as follows: > > join(base, '..\\..\\', 'build', '') > > I obtain as expected from the documentation: > > 'C:\\Documents\\..\\..\\build\\' > > But if I try to make the directory myself (as I tried first): > > join(base, '..\\..\\', 'build', '\\') > > I obtain: > > 'C:\\' > > The documentation says that an absolute path in the parameter list for > join will discard all previous parameters but '\\' is not an absoute path! But it is - an absolute path is one that starts with the pathname separator. The concept of paths is ugly in Windows because of the drive letter - a drive letter is not actually part of a path, it's an additional piece of context. If you leave out the drive letter, your path is relative or absolute within the current drive letter; if you include it your path is relative or absolute within the specified drive letter. So Python has behaved as documented here: the indicator for an absolute path has discarded everything (except the drive letter, which is necessary to maintain the context you provided) which came before it in the join. If indeed you're seeking a path that is terminated by the separator character, you need to do what you did in the first example - join an empty string at the end (this is documented). The terminating separator _usually_ isn't needed. Sadly, sometimes it appears to be... -- https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 2020-05-26 16:48, BlindAnagram wrote: On 26/05/2020 16:22, Ben Bacarisse wrote: BlindAnagram writes: I came across an issue that I am wondering whether I should report as an issue. If I have a directory, say: base='C:\\Documents' and I use os.path.join() as follows: join(base, '..\\..\\', 'build', '') It rather defeats the purpose of os.sep if you include it in a part of the path. What you mean is better expressed as join(base, '..', '..', 'build', '') (and base includes it too, but I can't suggest an alternative because I don't know your intent is far as defaults go.) Thanks for your input but while that part of my path may not be to your liking, it works fine and does not seem to be relevant to my concern, which is that join appears to treat os.sep as an absolute path, which it is not. If it starts with the path separator, then it's absolute (well, absolute on that drive). Open a Command Prompt window and it'll open in the %HOME% folder. Then type "cd \" and it'll put you in the root folder. -- https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 26/05/2020 16:59, Mats Wichmann wrote: > On 5/26/20 8:56 AM, BlindAnagram wrote: >> I came across an issue that I am wondering whether I should report as an >> issue. If I have a directory, say: >> >> base='C:\\Documents' >> >> and I use os.path.join() as follows: >> >> join(base, '..\\..\\', 'build', '') >> >> I obtain as expected from the documentation: >> >> 'C:\\Documents\\..\\..\\build\\' >> >> But if I try to make the directory myself (as I tried first): >> >> join(base, '..\\..\\', 'build', '\\') >> >> I obtain: >> >> 'C:\\' >> >> The documentation says that an absolute path in the parameter list for >> join will discard all previous parameters but '\\' is not an absoute path! > > But it is - an absolute path is one that starts with the pathname separator. On Windows, when part of a string representing a file or directory path, '\\' acts as a directory separator. It may imply, as you say, that it is a path on the current drive but it also behaves as a move to a sub-directory of what has appeared to its left. And this is how it is treated in other os.path functions. For example: base = "C:\\Documents\\Finance\\" abspath(base) 'C:\\Documents\\Finance' where it can be seen that '\\' is being treated as a directory separator. In my view it is not sensible to have some functions treating '\\' in one way and others differently. I would hence expect join() to accept '\\' as an addition to a file path on Windows and not a signal of an absolute path. > The concept of paths is ugly in Windows because of the drive letter - a > drive letter is not actually part of a path, it's an additional piece of > context. If you leave out the drive letter, your path is relative or > absolute within the current drive letter; if you include it your path is > relative or absolute within the specified drive letter. So Python has > behaved as documented here: the indicator for an absolute path has > discarded everything (except the drive letter, which is necessary to > maintain the context you provided) which came before it in the join. > > If indeed you're seeking a path that is terminated by the separator > character, you need to do what you did in the first example - join an > empty string at the end (this is documented). The terminating separator > _usually_ isn't needed. Sadly, sometimes it appears to be... I agree that handling file paths on Windows is very ugly, especially so if some of the directory/file names include spaces. But I don't see that as an excuse for this specific ambiguity in Python in the handling of '\\' when embedded in, or added to, paths. -- https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 26/05/2020 17:09, Stefan Ram wrote:
> Mats Wichmann writes:
>> an absolute path is one that starts with the pathname separator.
>
> The Python Library Reference does not use the term
> "pathname separator". It uses "directory separator"
> (os.sep) and "filename separator" ('/' on Unix).
>
> On Windows:
>
> |>>> import pathlib
> |>>> import os
> |>>> pathlib.PureWindowsPath('\\').is_absolute()
> |False
> |>>> pathlib.PureWindowsPath(os.sep).is_absolute()
> |False
> |>>> pathlib.PureWindowsPath('/').is_absolute()
> |False
Thanks, that seems to suggest that there is an issue and that I should
hence submit this as an issue.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 26/05/2020 17:46, MRAB wrote: > On 2020-05-26 16:48, BlindAnagram wrote: >> On 26/05/2020 16:22, Ben Bacarisse wrote: >>> BlindAnagram writes: >>> I came across an issue that I am wondering whether I should report as an issue. If I have a directory, say: base='C:\\Documents' and I use os.path.join() as follows: join(base, '..\\..\\', 'build', '') >>> >>> It rather defeats the purpose of os.sep if you include it in a part of >>> the path. What you mean is better expressed as >>> >>> join(base, '..', '..', 'build', '') >>> >>> (and base includes it too, but I can't suggest an alternative because I >>> don't know your intent is far as defaults go.) >> >> Thanks for your input but while that part of my path may not be to your >> liking, it works fine and does not seem to be relevant to my concern, >> which is that join appears to treat os.sep as an absolute path, which it >> is not. >> > If it starts with the path separator, then it's absolute (well, absolute > on that drive). Agreed. I did not think that I needed to add this exception to my comment as I thought from the the context that it would be clear that I was questioning how it worked at the end of a path, not when used at its start. -- https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 26/05/2020 18:01, BlindAnagram wrote:
On 26/05/2020 17:09, Stefan Ram wrote:
Mats Wichmann writes:
an absolute path is one that starts with the pathname separator.
The Python Library Reference does not use the term
"pathname separator". It uses "directory separator"
(os.sep) and "filename separator" ('/' on Unix).
On Windows:
|>>> import pathlib
|>>> import os
|>>> pathlib.PureWindowsPath('\\').is_absolute()
|False
|>>> pathlib.PureWindowsPath(os.sep).is_absolute()
|False
|>>> pathlib.PureWindowsPath('/').is_absolute()
|False
Thanks, that seems to suggest that there is an issue and that I should
hence submit this as an issue.
It is indeed most curious as to why this obviously absolute path is not
recognised as such :-)
--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 26/05/2020 18:07, BlindAnagram wrote: On 26/05/2020 17:46, MRAB wrote: On 2020-05-26 16:48, BlindAnagram wrote: On 26/05/2020 16:22, Ben Bacarisse wrote: BlindAnagram writes: I came across an issue that I am wondering whether I should report as an issue. If I have a directory, say: base='C:\\Documents' and I use os.path.join() as follows: join(base, '..\\..\\', 'build', '') It rather defeats the purpose of os.sep if you include it in a part of the path. What you mean is better expressed as join(base, '..', '..', 'build', '') (and base includes it too, but I can't suggest an alternative because I don't know your intent is far as defaults go.) Thanks for your input but while that part of my path may not be to your liking, it works fine and does not seem to be relevant to my concern, which is that join appears to treat os.sep as an absolute path, which it is not. If it starts with the path separator, then it's absolute (well, absolute on that drive). Agreed. I did not think that I needed to add this exception to my comment as I thought from the the context that it would be clear that I was questioning how it worked at the end of a path, not when used at its start. But you aren't talking about the end of the (finished) path, you are talking about the start of the final path component you pass to os.path.join(), "\\". As the documentation says, "If a component is an absolute path, all previous components are thrown away and joining continues from the absolute path component." Since "\\" is an absolute path component, all the previous components are thrown away and you are left with just "\\". -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 26/05/2020 16:59, Mats Wichmann wrote: > On 5/26/20 8:56 AM, BlindAnagram wrote: >> I came across an issue that I am wondering whether I should report as an >> issue. If I have a directory, say: >> >> base='C:\\Documents' >> >> and I use os.path.join() as follows: >> >> join(base, '..\\..\\', 'build', '') >> >> I obtain as expected from the documentation: >> >> 'C:\\Documents\\..\\..\\build\\' >> >> But if I try to make the directory myself (as I tried first): >> >> join(base, '..\\..\\', 'build', '\\') >> >> I obtain: >> >> 'C:\\' >> >> The documentation says that an absolute path in the parameter list for >> join will discard all previous parameters but '\\' is not an absoute path! > > But it is - an absolute path is one that starts with the pathname separator. In a string giving a file path on Windows '\\' is recognised as a separator between directories and not as an indicator that what follows is an absolute path based on the drive letter (although it might, as you say, imply a drive context). > The concept of paths is ugly in Windows because of the drive letter - a > drive letter is not actually part of a path, it's an additional piece of > context. If you leave out the drive letter, your path is relative or > absolute within the current drive letter; if you include it your path is > relative or absolute within the specified drive letter. So Python has > behaved as documented here: the indicator for an absolute path has > discarded everything (except the drive letter, which is necessary to > maintain the context you provided) which came before it in the join. This is not consistent with how other file management functions in os.path operate since they willingly accept '\\' as a directory separator. > If indeed you're seeking a path that is terminated by the separator > character, you need to do what you did in the first example - join an > empty string at the end (this is documented). The terminating separator > _usually_ isn't needed. Sadly, sometimes it appears to be... -- https://mail.python.org/mailman/listinfo/python-list
Issues regarding running of application.
I have tried and installed the python application a lot of times but after the installation get completed and I try to run the application, it say that api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer. Please tell me a way out. -- https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 5/26/20 10:57 AM, BlindAnagram wrote: > On 26/05/2020 16:59, Mats Wichmann wrote: >> On 5/26/20 8:56 AM, BlindAnagram wrote: >>> I came across an issue that I am wondering whether I should report as an >>> issue. If I have a directory, say: >>> >>> base='C:\\Documents' >>> >>> and I use os.path.join() as follows: >>> >>> join(base, '..\\..\\', 'build', '') >>> >>> I obtain as expected from the documentation: >>> >>> 'C:\\Documents\\..\\..\\build\\' >>> >>> But if I try to make the directory myself (as I tried first): >>> >>> join(base, '..\\..\\', 'build', '\\') >>> >>> I obtain: >>> >>> 'C:\\' >>> >>> The documentation says that an absolute path in the parameter list for >>> join will discard all previous parameters but '\\' is not an absoute path! >> >> But it is - an absolute path is one that starts with the pathname separator. > > On Windows, when part of a string representing a file or directory path, > '\\' acts as a directory separator. It may imply, as you say, that it > is a path on the current drive but it also behaves as a move to a > sub-directory of what has appeared to its left. And this is how it is > treated in other os.path functions. For example: > > base = "C:\\Documents\\Finance\\" > abspath(base) > 'C:\\Documents\\Finance' > > where it can be seen that '\\' is being treated as a directory > separator. In my view it is not sensible to have some functions > treating '\\' in one way and others differently. I would hence expect > join() to accept '\\' as an addition to a file path on Windows and not > a signal of an absolute path. Unlike the string join method, which would behave as you seem to want, the os.path.join method "knows" it is working on paths, so it's going to assign some meaning to the content of the pieces. If it was up to me I might not have chosen the approach Python did of "if we see a piece that looks like an absolute path, discard what came before", but that's the one that was chosen, presumably for good reasons, and it is so documented. And the pathlib library module chose to retain that behavior: "When several absolute paths are given, the last is taken as an anchor (mimicking os.path.join()’s behaviour)". So it's just something to get used to? -- https://mail.python.org/mailman/listinfo/python-list
Re: Issues regarding running of application.
On 5/26/20 8:45 AM, Meet Agrawal wrote: > I have tried and installed the python application a lot of times but after > the installation get completed and I try to run the application, it say > that api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer. > > Please tell me a way out. Install it? If you're not on Windows 10, this needs to be installed, and the side effect is that your install may need to take place with elevated privilege. === Recent versions of Python for Windows are built with a recent Microsoft build toolchain. Since the Python binary itself is a C-language application, it is automatically linked with the MS C runtime. That library, of the correct version, is a part of an up-to-date Windows 10, but has to be installed as an update on Win 7/8.1. Microsoft's package for that is included in the Python installer, but introduces a host of problems: it must be installed using elevated privilege (even though Python itself does not require this), and in general those kinds of packages only install if "everything is right" - if the MS installation subsystem thinks you are not up to date, for example, it may well give up. Sometimes it seems like if the phase of the moon is wrong, it gives up. This isn't unique to Python, by the way. Step one is to try an install with elevated privilege - the new Python installers default to installing at just user privilege level, so you need to go to advanced settings and tick a box. If that's not enough, look at this note from a different project suffering the same problems which proposes a solution: https://www.smartftp.com/support/kb/the-program-cant-start-because-api-ms-win-crt-runtime-l1-1-0dll-is-missing-f2702.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 26/05/2020 18:51, Mats Wichmann wrote: > On 5/26/20 10:57 AM, BlindAnagram wrote: >> On 26/05/2020 16:59, Mats Wichmann wrote: >>> On 5/26/20 8:56 AM, BlindAnagram wrote: I came across an issue that I am wondering whether I should report as an issue. If I have a directory, say: base='C:\\Documents' and I use os.path.join() as follows: join(base, '..\\..\\', 'build', '') I obtain as expected from the documentation: 'C:\\Documents\\..\\..\\build\\' But if I try to make the directory myself (as I tried first): join(base, '..\\..\\', 'build', '\\') I obtain: 'C:\\' The documentation says that an absolute path in the parameter list for join will discard all previous parameters but '\\' is not an absoute path! >>> >>> But it is - an absolute path is one that starts with the pathname separator. >> >> On Windows, when part of a string representing a file or directory path, >> '\\' acts as a directory separator. It may imply, as you say, that it >> is a path on the current drive but it also behaves as a move to a >> sub-directory of what has appeared to its left. And this is how it is >> treated in other os.path functions. For example: >> >> base = "C:\\Documents\\Finance\\" >> abspath(base) >> 'C:\\Documents\\Finance' >> >> where it can be seen that '\\' is being treated as a directory >> separator. In my view it is not sensible to have some functions >> treating '\\' in one way and others differently. I would hence expect >> join() to accept '\\' as an addition to a file path on Windows and not >> a signal of an absolute path. > > Unlike the string join method, which would behave as you seem to want, > the os.path.join method "knows" it is working on paths, so it's going to > assign some meaning to the content of the pieces. If it was up to me I > might not have chosen the approach Python did of "if we see a piece that > looks like an absolute path, discard what came before", but that's the > one that was chosen, presumably for good reasons, and it is so > documented. And the pathlib library module chose to retain that > behavior: "When several absolute paths are given, the last is taken as > an anchor (mimicking os.path.join()’s behaviour)". So it's just > something to get used to? I agree with much of what you say. But I believe that it is more natural and less 'dangerous' when a functions behaviour matches that which its name implies, that is, to join things together, not to throw one of them away! And, I don't presume that there were good reasons since it might simply have been an oversight, which is why I raised it (even Python developers are not perfect :-) -- https://mail.python.org/mailman/listinfo/python-list
Phyton 32 or 64 bit?
Good afternoon, Please forgive what may be a stupid question. I’m an absolute beginner and downloaded Python 3.8 for 32bits. I’m running Windows 10 on 64bit machine. Question 1 : is it OK to run Python (32 bits) on my machine ? Question 2 : The download went fine. How do I go from here to install and run Python ? Sorry for the dumb questions. Thanks for any help. -- https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 2020-05-26 16:52, Dennis Lee Bieber wrote: On Tue, 26 May 2020 16:22:27 +0100, Ben Bacarisse declaimed the following: I think it is. The picture is messy on Windows (because of the drive letter) but absolute paths are usually taken to be those that start with a path separator. The drive letter is only required if one needs to access something that is not on the "currently logged drive". Compare: [snip] I'd also like to point out that the nasty "\\" is not needed. Windows API understands "/" -- it is only the command line "DOS" shell that requires back-slash (since / is used for command options, Powershell is happy with / since options are prefixed with - ). Dialog windows, e.g. Open and Save dialogs, also require backslashes. [snip] -- https://mail.python.org/mailman/listinfo/python-list
Re: Phyton 32 or 64 bit?
On 2020-05-26 19:13, R. A. Hoffman via Python-list wrote: Good afternoon, Please forgive what may be a stupid question. I’m an absolute beginner and downloaded Python 3.8 for 32bits. I’m running Windows 10 on 64bit machine. Question 1 : is it OK to run Python (32 bits) on my machine ? The 32-bit version will run on both 32-bit and 64-bit machines. If you're intending to work with many gigs of RAM then you'd need the 64-bit version, otherwise the 32-bit version is fine. Question 2 : The download went fine. How do I go from here to install and run Python ? What exactly did you download? If it's the "executable installer", then just run it to install Python. Sorry for the dumb questions. Thanks for any help. -- https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 27/05/20 5:23 AM, BlindAnagram wrote: On 26/05/2020 16:59, Mats Wichmann wrote: On 5/26/20 8:56 AM, BlindAnagram wrote: I came across an issue that I am wondering whether I should report as an issue. If I have a directory, say: base='C:\\Documents' and I use os.path.join() as follows: join(base, '..\\..\\', 'build', '') I obtain as expected from the documentation: 'C:\\Documents\\..\\..\\build\\' But if I try to make the directory myself (as I tried first): join(base, '..\\..\\', 'build', '\\') I obtain: 'C:\\' The documentation says that an absolute path in the parameter list for join will discard all previous parameters but '\\' is not an absoute path! But it is - an absolute path is one that starts with the pathname separator. In a string giving a file path on Windows '\\' is recognised as a separator between directories and not as an indicator that what follows is an absolute path based on the drive letter (although it might, as you say, imply a drive context). [some of this answer may appear 'obvious' to you. If so, please understand that this conversation has the side-benefit of assisting other readers to understand Python, and that I would not presume to 'talk down' to you-personally] Using the docs: <<< os.path.join(path, *paths) Join one or more path components intelligently. The return value is the concatenation of path and any members of *paths with exactly one directory separator (os.sep) following each non-empty part except the last, meaning that the result will only end in a separator if the last part is empty. If a component is an absolute path, all previous components are thrown away and joining continues from the absolute path component. On Windows... [previously discussed] >>> https://docs.python.org/3/library/os.path.html Let's start with the word "intelligently". Some might assume this to mean that it will distinguish between "separator between directories" and "absolute path". However, what it means is that it will select either the POSIX or the MS-Windows character(s) - depending upon whether the final-application is running on your machine or mine! It also means, that it expects to handle the assembly of the parameters into a single path (utilising the appropriate separator). Please be advised that the pathlib library and pathlike interface were added quite recently, and largely because the os library is considered dated. Accordingly, please don't attempt to draw parallels or 'rules' by comparing the under-pinning philosophies of 'past' with 'future'. Remember that Python does not define files, paths, directories (folders), and backing-store structures; and as observed, they differ between OpSys. The os and os.path libraries exist to help us (poor, long-suffering coders) to cope with the differences. Accordingly, in Python, we do not deal with the file system itself, but we code to an abstraction of a file system! Python's interpreter handles 'the real situation' at run-time. (thank you Python!) Please review the os library (https://docs.python.org/3/library/os.html). There (amongst other very useful facilities) you will find such as os.sep (and various other os.*seps which illustrate how difficult it is to harmonise the abstraction to cope with the various realities). Note also, the warning (which applies both to 'construction' and 'separation' of paths from path-components). Further reading? Because Python doesn't really define "path", let's turn to https://en.wikipedia.org/wiki/Path_%28computing%29 - but keep a headache remedy to-hand! This article provides such understandings as "path", "root", and "device" (the latter not existing in POSIX systems), per a range of operating systems. OK, after all that, back to the question:- Please examine the 'signature' of -join(): os.path.join(path, *paths) notice that the arguments are path[s] - NOT file-names, NOT directories (folders), and NOT path-components. Remember also the word "intelligent". The objective of the function is to create a legal AND OpSys-appropriate path, by joining other *path(s)* together. Accordingly, the function considers each parameter to be a path. A path commencing with the symbol indicating the "root" is considered an "absolute path". A path commencing with a character (etc) is considered a "relative path". [Apologies, in that experienced pythonista will find this 'stating the obvious', but learners often do not find such differences, immediately apparent] This may explain why the OP's use of, or interpretation of, arguments to the function, differs from that of the library. Why a subsequent parameter, interpreted as an absolute-path, should cause all previous parameters to be 'thrown away' is an implementation detail - and I can't explain that choice, except to say that because some systems use the same character to represent the "root" directory as they do for the path-component separator, there
Re: Custom logging function
Is this OK?
import logging
LOG_LEVEL = logging.getLevelName('DEBUG')
logging.basicConfig(level=LOG_LEVEL,
format='%(asctime)s %(levelname)s %(name)s %(funcName)-20s
%(message)s',
datefmt='%d.%m.%Y %H:%M:%S')
stderr = logging.StreamHandler()
stderr.terminator = '\r\n'
logging.getLogger('').addHandler(stderr)
logging.info('Main script started')
--
https://mail.python.org/mailman/listinfo/python-list
Re: Custom logging function
Furthermore, I must disable logging to stdout. -- https://mail.python.org/mailman/listinfo/python-list
Re: Behaviour of os.path.join
On 2020-05-26, Dennis Lee Bieber wrote:
> I'd also like to point out that the nasty "\\" is not needed. Windows
> API understands "/" -- it is only the command line "DOS" shell that
> requires back-slash
Many, many applications also require that backslashes be used in path
arguments (whether or not they're being executed via the "DOS" shell).
Interestingly, the _real_ DOS shell from several decades ago let you
change the "option" character from "/" to anything you wanted ("-" is
one correct answer), and the shell would then be perfectly happy with
forwards slashes in paths. But, there were still plenty of
applications that whould choke on forward slashes in path
arguments. Apparently a lot of application developers were ignorant of
the fact that the system option character was configurable by the
user.
Thank Dog for the MKS toolkit.
> Powershell is happy with / since options are prefixed with - ).
One point to Microsoft on that one (they're still way behind).
--
Grant
--
https://mail.python.org/mailman/listinfo/python-list
Re: Phyton 32 or 64 bit?
To all: The only stupid question is one that wasn't asked ! Alex On Tue, May 26, 2020 at 12:42 PM MRAB wrote: > On 2020-05-26 19:13, R. A. Hoffman via Python-list wrote: > > > > Good afternoon, > > > > > > > > Please forgive what may be a stupid question. I’m an absolute beginner > and downloaded Python 3.8 for 32bits. I’m running Windows 10 on 64bit > machine. > > > > > > > > Question 1 : is it OK to run Python (32 bits) on my machine ? > > > The 32-bit version will run on both 32-bit and 64-bit machines. > > If you're intending to work with many gigs of RAM then you'd need the > 64-bit version, otherwise the 32-bit version is fine. > > > > > > Question 2 : The download went fine. How do I go from here to install > and run Python ? > > > What exactly did you download? If it's the "executable installer", then > just run it to install Python. > > > > > > Sorry for the dumb questions. Thanks for any help. > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Custom logging function
[email protected] wrote: > Is this OK? > > import logging > > LOG_LEVEL = logging.getLevelName('DEBUG') > > logging.basicConfig(level=LOG_LEVEL, > format='%(asctime)s %(levelname)s %(name)s > %(funcName)-20s %(message)s', datefmt='%d.%m.%Y > %H:%M:%S') > > stderr = logging.StreamHandler() > stderr.terminator = '\r\n' > logging.getLogger('').addHandler(stderr) > > logging.info('Main script started') You create two stream handlers that both log to stderr -- one with basicConfig() and one explicitly in your code. That's probably not what you want. -- https://mail.python.org/mailman/listinfo/python-list
Re: Custom logging function
On 26May2020 13:25, [email protected] wrote: Furthermore, I must disable logging to stdout. Normally logging does not happen to stdout. Do you have something which does? Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
yolov3 Real Time Object Detection in tensorflow 2.2
Hello, I would like to share with you my implementation of yolov3 object detector in tensorflow 2.2 https://github.com/emadboctorx/yolov3-keras-tf2 Features tensorflow-2.X--keras-functional-api cpu-gpu support Random weights and DarkNet weights support csv-xml annotation parsers. Anchor generator. `matplotlib` visualization of all stages. `tf.data` input pipeline. `pandas` & `numpy` data handling. `imgaug` augmentation pipeline `logging` coverage. All-in-1 custom trainer. Stop and resume training support. Fully vectorized mAP evaluation. `labelpix` support. Photo & video detection -- https://mail.python.org/mailman/listinfo/python-list
