Re: What is the problem with my code?
On Mon, Apr 27, 2020 at 4:26 PM wrote:
>
> def is_positive_int(int):
> x = int[0]
> if int == "":
> return Flase
> elif int != "":
> print(True)
> if int[0] < 1:
> return false
> else:
> print(True)
> for x in int:
> if x > 0 and x < 10:
> print(True)
> x = x + 1
> else:
> return False
> if "." in int:
> return False
> else:
> print(True)
> return "int is True"
> print(is_positive_int("1 2 3 4 5 6 7 8 9"))
Lots of things. Have you tried running the code to see what Python
says about it? Never ask a human something you could more easily learn
from a computer.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
What is the problem with my code?
def is_positive_int(int):
x = int[0]
if int == "":
return Flase
elif int != "":
print(True)
if int[0] < 1:
return false
else:
print(True)
for x in int:
if x > 0 and x < 10:
print(True)
x = x + 1
else:
return False
if "." in int:
return False
else:
print(True)
return "int is True"
print(is_positive_int("1 2 3 4 5 6 7 8 9"))
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to test?
If I have understood correctly, the objective is to check a dir-tree to ensure that specific directory/file-permissions are in-effect/have not been changed. The specifications come from a .JSON file and may be over-ridden by command-line arguments. Correct? Yes. How to test this in the best way? The best way to prepare for unit-testing is to have 'units' of code (apologies!). An effective guide is to break the code into functions and methods, so that each performs exactly one piece/unit of work - and only the one. A better guide is that if you cannot name the procedure using one description and want to add an "and" an "or" or some other conjunction, perhaps there should be more than one procedure! For example: >for cat in cats: > ... > for d in scantree(cat.dir): > # if `keep_fs` was specified then we must > # make sure the file is on the same device > if cat.keep_fs and devid != get_devid(d.path): > continue > > cat.check(d) Above is part of the main() function. But I could make some part of the main() function into its own function. Then the call to check a directory could be a function argument. For testing I could reuse that function by providing a different function for the check (now it is cat.checkid(d) ) There is no $charge for the number of functions used. Don't hesitate! Whilst I haven't heard the phrase used recently, we used to talk about systems- and program-design being a process of "step-wise decomposition". It was likened to peeling layers off an onion, or Russian nesting dolls - as one takes 'off' the outer layer, there is more inside. In programming then, the main() calls a bunch of other functions. Each of those, calls its own set of sub-functions, and so-on. At first, we are talking 'higher levels' of control - and a good choice of function names summarises what's going-on/provides the 'plan of attack' and thus good "documentation"! As control passes to the 'lower level' of functions, the level of detail increases. You might think of it like a microscope - the more powerful the magnification, the more detail is seen; but the field of view has narrowed/become more focussed. The idea of having one function perform one (and only one) function is known as "encapsulation". Another term which was a new 'buzz-word', decades ago, is "modular programming" - instead of having one long program, splitting it up into functional components. Yet another traditional phrase describing computer programs is: "input, process, output". This can also be applied, at the successive levels of detail, to functions - they 'take in' parameter-values, 'process' them in some way, and then return, or 'output' the result. In a simplistic world, one function's output would become input to the next function. However, back in the real-world, it is more likely that several 'outputs' from earlier functions are used as 'input' by some successive procedure. Which is why we are paid 'the big bucks' (maybe). Earlier functions should only influence or affect the behavior of later functions by passing data (output from one, becoming input to another). The complex ways in which functions can 'feed' or 'affect' each other is called "cohesion". If each function is dependent only upon its input data, this is held as an ideal. If a function is not independent, that is likely to be and/or become a source of friction and bugs. Again, in an ideal world... There's a lot of follow-through, if you'd care to do some reading using such key-words... If this were a function, how would you name it? First of all we are processing every category, then we are scanning a dir-tree, and finally we are doing something to each directory found. If we split these into separate routines, eg (sub-setting the above): > for d in scantree(cat.dir): do_something_with_directory( d ) and you devise a (much) more meaningful name than mine, it will actually help readers (others - but also you!) to understand the steps within the logic. Now if we have a function which checks a single fileNM for 'whatever', the code will start something like: def stat_file( fileNM ): '''Gather stat information for nominated file.''' etc So, we can now write a test-function because we don't need any "categories", we don't need all the dir-tree, and we don't need to have performed a scan - all we need is a (valid and previously inspected) file-path. Thus (using Pytest): def test_stat_file( ... ): '''Test file stat.''' assert stat_file( "...file-path" ) == ...its known-stat def test_stat_dir( ... ): '''Test file stat.''' assert stat_file( "...dir-path" ) == ...its known-stat There is no need to test for a non-existent file, if you are the only user! In case you
Re: Function to avoid a global variable
On Mon, Apr 27, 2020 at 1:39 PM Bob van der Poel wrote: > > Does this make as much sense as anything else? I need to track calls to a > function to make sure it doesn't get called to too great a depth. I had a > global which I inc/dec and then check in the function. Works fine, but I do > need to keep a global around just for this. > > So ... instead I wrote a short function: > > def parseStack(inc, depth=[0]): > if depth[0] > 50: > ... report error and die nicely > depth[0] += inc > > This gets rid of the global, and it moves my error check out of the main > code as well. But, I never feel all that great about using a list in the > function call for static storage. That's not really any different from a global. If globals bother you, this should as well. But it's also reasonable to NOT be bothered by it - it's not that big a problem. If this is directly recursive (if there's a call to parseStack inside parseStack itself, as opposed to being mutually recursive with one or more other functions), the easiest way to avoid the global is to just pass the parameter down - something like this: def spaminate(x, y, depth=0): ... spaminate(newx, newy, depth+1) ... But that can be harder if you have other things happening, eg if your function calls something else, which calls something else, which calls your function again. If it's that complex, I would just accept the global, honestly - globals (module-level variables) aren't the worst thing that can happen. You won't end up with code reviews like https://xkcd.com/1513/ just because of one global (or if you do, you REALLY need to find better code reviewers!). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Function to avoid a global variable
Does this make as much sense as anything else? I need to track calls to a function to make sure it doesn't get called to too great a depth. I had a global which I inc/dec and then check in the function. Works fine, but I do need to keep a global around just for this. So ... instead I wrote a short function: def parseStack(inc, depth=[0]): if depth[0] > 50: ... report error and die nicely depth[0] += inc This gets rid of the global, and it moves my error check out of the main code as well. But, I never feel all that great about using a list in the function call for static storage. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Problems
On 27/04/20 11:29 AM, Mats Wichmann wrote: On 4/26/20 2:06 AM, helal uddin wrote: https://drive.google.com/open?id=1DCciLNPkARXnVIHFhXmijRTbFEC9Xsa- Please visit this link to see my problem I'm facing some problems to installlibraries like 'torch library' My Operating System is Windows 10 64bit. I don't think anyone is going to go visit a random link like that. Thanks Mats - you are correct though, I'm not just "anyone"! (and have a reasonably-secure system! No browsers were harmed in the clicking of this link - but large numbers of electrons became considerably excited!) -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Problems
On 4/26/20 2:06 AM, helal uddin wrote: > https://drive.google.com/open?id=1DCciLNPkARXnVIHFhXmijRTbFEC9Xsa- > Please visit this link to see my problem > I'm facing some problems to installlibraries like 'torch library' > My Operating System is Windows 10 64bit. > I don't think anyone is going to go visit a random link like that. Please describe the problem in words. An error traceback would probably be helpful. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Problems
On 26/04/20 8:06 PM, helal uddin wrote: https://drive.google.com/open?id=1DCciLNPkARXnVIHFhXmijRTbFEC9Xsa- Please visit this link to see my problem I'm facing some problems to installlibraries like 'torch library' My Operating System is Windows 10 64bit. <<< 404. That’s an error. The requested URL was not found on this server. That’s all we know. >>> -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Python Problems
https://drive.google.com/open?id=1DCciLNPkARXnVIHFhXmijRTbFEC9Xsa- Please visit this link to see my problem I'm facing some problems to installlibraries like 'torch library' My Operating System is Windows 10 64bit. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to test?
On Sun, 26 Apr 2020 15:26:58 +1200 DL Neil wrote: > On 25/04/20 7:53 PM, Manfred Lotz wrote: > > On Sat, 25 Apr 2020 18:41:37 +1200 > > DL Neil wrote: > > > >> On 25/04/20 5:16 PM, Manfred Lotz wrote: > >>> On Fri, 24 Apr 2020 19:12:39 -0300 > >>> Cholo Lennon wrote: > >>> > On 24/4/20 15:40, Manfred Lotz wrote: > > I have a command like application which checks a directory tree > > for certain things. If there are errors then messages will be > > written to stdout. > > > What I do here specifically is to check directory trees' file > > objects for user and group ownerships as well as permissions > > according to a given policy. There is a general policy and there > > could be exceptions which specify a specific policy for a certain > > file. > > If I have understood correctly, the objective is to check a dir-tree > to ensure that specific directory/file-permissions are in-effect/have > not been changed. The specifications come from a .JSON file and may > be over-ridden by command-line arguments. Correct? > Yes. > There must be a whole 'genre' of programs which inspect a > directory-tree and doing 'something' to the files-contained. I had a > few, and needing another, decided to write a generic 'scanner' which > would then call a tailored-function to perform the particular > 'something' - come to think of it, am not sure if that was ever quite > finished. Sigh! > > > > One idea was for the error situations to write messages to > > files and then later when running the tests to compare the > > error messages output to the previously saved output. > > > > Is there anything better? > > The next specification appears to be that you want a list of files > and their stats, perhaps reporting only any exceptions which weren't > there 'last time'. > I just want to report violations against the policy(ies) given in the JSON file. > In which case, an exception could be raised, or it might be simpler > to call a reporting-function when a file should be 'reported'. > > I'm still a little confused about the difference between > printing/logging/reporting some sort of exception, and the need to > compare with 'history'. > There is no compare with history. I just want to see current violations (I think I phrased things badly in my previous post so that it looked like I want to see history.) > > The problem with the "previously saved output" is the process of > linking 'today's data' with that from the last run. I would use a > database (but then, that's my background/bias) to store each file's > stat. > As said above I phrased things badly here in my previous post. > Alternately, if you only need to store exceptions, and that number is > likely to be small, perhaps output only the exceptions from 'this > run' to a .JSON/.yaml file - which would become input (and a dict for > easy look-ups) next time? > > > Maybe I am wrong because I don't understand your scenario: If > your application is like a command, it has to return an error > code to the system, a distinct number for each error condition. > The error code is easier to test than the stdout/stderr. > > Either way, you might decrease the amount of data to be stored by > reducing the file's stat to a code. > > > > How to test this in the best way? > > The best way to prepare for unit-testing is to have 'units' of code > (apologies!). > > An effective guide is to break the code into functions and methods, > so that each performs exactly one piece/unit of work - and only the > one. A better guide is that if you cannot name the procedure using > one description and want to add an "and" an "or" or some other > conjunction, perhaps there should be more than one procedure! > > For example: > > >for cat in cats: > > ... > > for d in scantree(cat.dir): > > # if `keep_fs` was specified then we must > > # make sure the file is on the same device > > if cat.keep_fs and devid != get_devid(d.path): > > continue > > > > cat.check(d) > Above is part of the main() function. But I could make some part of the main() function into its own function. Then the call to check a directory could be a function argument. For testing I could reuse that function by providing a different function for the check (now it is cat.checkid(d) ) > If this were a function, how would you name it? First of all we are > processing every category, then we are scanning a dir-tree, and > finally we are doing something to each directory found. > > If we split these into separate routines, eg (sub-setting the above): > > > for d in scantree(cat.dir): > do_something_with_directory( d ) > > and you devise a (much) more meaningful name than mine, it will > actually help readers (others - but also you!) to understand the > steps within the logic. >
