Re: Friday Filosofical Finking: Import protections
On Thu, Apr 18, 2019 at 2:32 PM DL Neil wrote: > > On 18/04/19 8:29 AM, Chris Angelico wrote: > > On Thu, Apr 18, 2019 at 6:21 AM DL Neil > > wrote: > >> Do you bother with exception handling for import statements? > >> Can we assume that if such a catastrophic error occurs, it is quite > >> acceptable for the code to fall-over in a tumbling-fumble? > > > > I try/except around import statements only if it's possible for the > > program to recover from the exception. For instance, something that > ... > > User reactions have been covered elsewhere 'here'. You've given an example of how a user might respond to the exception traceback. But can you actually offer anything that your program could do that's BETTER than a traceback? If not, what's the point in catching the exception? > > For something that is absolutely required for the program to continue, > > what would be in your exception handler? Print a message to stderr and > > exit? That's exactly what not-catching-the-exception is for. I do > > sometimes annotate the imports, though: > > We disagree. Although I hasten to add, if the error is trapped, then > there should be some added-value over what is system-provided. > > Application's log? SysLog? Particularly in a centralised or server-based > application especially web-services. Or, you could stick with stderr, which means that the message will go whereever the message ought to be sent. If you're running a web service, you should be catching stderr and putting it somewhere. > > from dataclasses import dataclass # ImportError? Upgrade to Python 3.7 > > or pip install dataclasses > > > > If that bombs out, the entire line will get printed, comment and all, > > and there isn't really anything else that I would want to do with the > > exception. > > So I guess the best way to answer your question is with another > > question: If such a catastrophic error occurs, what ELSE would your > > code do than fall over? If there's an answer to that question, then > > sure, catch the ImportError. Otherwise don't. > > Kudos! To whom are you addressing such annotations? > Whoever might be running the script. I don't particularly discriminate :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Importing module from another subdirectory
Rich Shepard writes: > What is the proper syntax to import the model class in the model/ > subdirectory into a tkinter view module, e.g., activities.py? The syntax, > 'import model as m' fails because it is not in the same subdirectory as the > importing module. > > The program directory tree is: > > bustrac/ >README.rst >bustrac.py* >controller/ >model/ >scripts/ >views/ Python knows about 2 kinds of "regular" imports: absolute ones and relative ones. "Absolute" imports are guided by "sys.path" -- in the simple case, a sequence of folders containing modules and/or pacakges. Relative imports are guided in a similar way by the current packages's "__path__", which typically contains just one element - the folder from which the current package was loaded. When you start a script, Python adds the script's directory to "sys.path". This makes (absolute) imports of other modules/packages in this directory easy. Your structure, however, puts the infrastructure elsewhere. I see two options for you: 1. put your scripts directly into "bustrac" (rather than a subdirectory) 2. extend "sys.path" in your scripts to contain the "bustrac" folder ( before you try to import infrastructure modules/packages) Both options would allow you to import "model" via Python's "regular" import. Apart from that you can use "importlib" services (--> runtime library documentation) to import from any location you like. -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Filosofical Finking: Import protections
On 18Apr2019 16:05, DL Neil wrote: On 18/04/19 8:45 AM, MRAB wrote: On 2019-04-17 21:20, DL Neil wrote: Do you bother with exception handling for import statements? Can we assume that if such a catastrophic error occurs, it is quite acceptable for the code to fall-over in a tumbling-fumble? [snip] Catch only what you (well, the script) can fix. If it needs numpy, but can't import numpy, then when can it do? Might as well just let it fail. I suppose an alternative might be to try to download and install numpy and then retry, but what if it can't be downloaded, or the installation fails? No, you have to give up at some point. It's better just to report the problem and leave it to the user to fix it. Ah, but is that not the point - the user cannot fix it (and neither should he be allowed to do so: see later comments about Operations functions). I'm missing something here. To me there are usually 2 scenarios where a failed import obstructs the user: - the user is someone like you or I - a person using a programme from source they're fetched - trying to run some programme with a module dependency; here we can reasonably assuming some responsibility for obtaining the missing module; ideally the place we got the programme from might have some pointers - the user is running some kind of packaged app. With python that tends to be either something obtained via pip from PyPI or a downloaded package, such as a bundle Mac .app or a Windows .msi file or a package from a linux distro. Here the responsibility is with the person who made the package/bundle. In the latter case the source _should_ have resolvable dependencies. For example pip packages can name the modules they require and pip itself will fetch those in turn. Bundles apps (.app, .msi etc) tend to include the modules within the bundle. Linux distro packages should include dependencies as well, and the package programme should fetch those. All of these should fulfil the requirements at programme install time, not at programme run time. Do you have a third scenario you could detail? What the user faces (unless we more properly handle the exception) is: import davids_brains Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'davids_brains' You and I will think this fine - and 'here' on the list will even beg OPs to give us this much data. However, despite users who have been known to make other comments about my (?lack of) brains, they will tend to offer such helpful advice as: "we need the missing module"...! I think this case is usually the former of the 2 above: the user has fetched from somewhere random. That somewhere should at least identify what is required, even if the user needs to do some further legwork themselves. I think my stance here is that it is the person installing the app/module who needs to sort this, because they know the context in which the app/module is being installed. Do we use pip to get stuff? Do we use the OS package manager to get stuff? Are we in a managed environment where we have to ask the local sysadmins to do this? The point is that the app/module can't know how to obtain missing components. If they didn't come with it, there are many unknowns about the environment and plenty of legitimate circumstances where an automatic install is infeasible or actually undesirable. I think that _most_ ImportErrors should not be caught unless the recovery is extremely well defined. While I'm not a fan of the "import settings" scenario (executable settings files? scary), I do catch ImportErrors in several places in my personal kit. Like Chris I think this is only appropriate where there's a very well defined coping mechanism, in particular _not_ assuming one can fetch more software. So: Python 2/3 imports: personally I try the python 3 import and fall back to the python 2 if that fails. But if the python 2 import fails, _that_ import error gets out. No "install" style recovery. Optional modules: I've got a module which supports several possible index backends. So I've got some classes along these lines: class LMDBIndex(_Index): [...] @classmethod def is_supported(cls): ''' Test whether this index class is supported by the Python environment. ''' try: import lmdb except ImportError: return False return True and some code which looks for a working index class: for indexname, indexclass in indexclasses: if not indexclass.is_supported(): continue ... some other checks ... return indexclass ... raise ValueError( "no supported index classes available: tried %r" % (indexclasses,)) So: no recovery or autoinstall. It just chooses the first (== most preferred) index class and returns it, and raises an exception if none is available. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Function to determine list max without itertools
On 18/04/19 4:10 PM, Sayth Renshaw wrote: I have created a function that takes a list as an argument. Without using itertools I want to compare each item in the list to find the max. However instead of the max I keep getting the last item in the list. Where is my logic wrong here? ... Seems like it should work but doesn't. I'd recommend rethinking your algorithm first, and then thinking about debugging your actual code. You should be able to find the largest in a collection without making many many passes over the items - a single pass should be sufficient. Most I am finding either use the max function or itertools. Both of which I am trying not to use so that I actually do it myself. Did you understand the advice? Have you simply dropped the first-attempt and gone looking for another canned-solution? Whilst you seem to be on-the-right-track, there is a definite error in the algorithm/the code. What debugging did you perform? Do you only assume, or can you see example (pertinent) values during each "pass" (time through the loop)? If not, why not? -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Filosofical Finking: Import protections
On 18/04/19 1:24 PM, Cameron Simpson wrote: On 17Apr2019 21:45, MRAB wrote: On 2019-04-17 21:20, DL Neil wrote: Do you bother with exception handling for import statements? [...] Catch only what you (well, the script) can fix. If it needs numpy, but can't import numpy, then when can it do? Might as well just let it fail. I'm of this mind too, but... I suppose an alternative might be to try to download and install numpy and then retry, but what if it can't be downloaded, or the installation fails? As an example of what an open ended can of worms attempts recovery might be, yeah. How hard do you try? But also, "installation fails": that isn't always a clean situation: it can litter the install area with partial junk. But this is also a bad example: it is something an _invoked_ programme should never try to do. Except by specific deliberate design and request, a running application shouldn't presume it has rights to install additional things, or even to try. I have personally (though metaphorically) clipped devs across the ear for doing themselves the moral equivalent of the above: try thing, then just "sudo try thing" when it was forbidden. ... +1 Installing additional packages is the same as self modifying code: as a rule, the admins install packages, not the app. +1 Sorry, ranting now over. Not at all, an excellent point which needs to be taken out and dusted-off, every now-and-again - particularly for such ear-clipping training exercises! -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Filosofical Finking: Import protections
On 18/04/19 8:29 AM, Chris Angelico wrote: On Thu, Apr 18, 2019 at 6:21 AM DL Neil wrote: Do you bother with exception handling for import statements? Can we assume that if such a catastrophic error occurs, it is quite acceptable for the code to fall-over in a tumbling-fumble? I try/except around import statements only if it's possible for the program to recover from the exception. For instance, something that ... User reactions have been covered elsewhere 'here'. For something that is absolutely required for the program to continue, what would be in your exception handler? Print a message to stderr and exit? That's exactly what not-catching-the-exception is for. I do sometimes annotate the imports, though: We disagree. Although I hasten to add, if the error is trapped, then there should be some added-value over what is system-provided. Application's log? SysLog? Particularly in a centralised or server-based application especially web-services. from dataclasses import dataclass # ImportError? Upgrade to Python 3.7 or pip install dataclasses If that bombs out, the entire line will get printed, comment and all, and there isn't really anything else that I would want to do with the exception. So I guess the best way to answer your question is with another question: If such a catastrophic error occurs, what ELSE would your code do than fall over? If there's an answer to that question, then sure, catch the ImportError. Otherwise don't. Kudos! To whom are you addressing such annotations? -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Filosofical Finking: Import protections
On 18/04/19 8:44 AM, Grant Edwards wrote: On 2019-04-17, DL Neil wrote: Do you bother with exception handling for import statements? Sometimes. There are two cases when I do that: 1. When the module has different names under Python2 and Python3 and the program tries first one, then the other. Excellent example - and a lot easier than interrogating os.environ (for example), ie permission cf forgiveness. 2. When the program can still do something useful (if perhaps feature-limited) without the imported module by substituting something else in its place. Any (publishable) examples? Most of the code I read, both in books and during code review, eschews any form of ImportError check. Even data science people who 'clean' every data field towards inclusion/exclusion in the analysis, take for granted that numpy, scipy, pandas, et al, will be available to their code. You've omitted the second thing assumed by the authors: without numpy, scipy, pandas, et alia the program can do nothing useful. but... what of the third inherent assumption: that the user(s) will be able to handle the situation (discussed in another msg 'here')? Does such a check seem un-pythonic? [sto] (maybe 'forgiveness cf permission'?) It's probably rather unpythonic if you're not going to anything useful in the exception handler. Indisputable! Can we assume that if such a catastrophic error occurs, it is quite acceptable for the code to fall-over in a tumbling-fumble? It's certainly OK with me. I'm not sure why you refer to raising an exception as "fall-over in a tumbling fumble". Raising an exception is the normal way to indicate failure in Python. Apologies! Evidently a cultural reference that did not export well. To understand "tumbling fumble" perhaps think of dropping something, attempting to catch it with one hand, then having to make a second try with the other, and probably failing to intercede before the floor... I could have used other terms, but likely to be considered 'politically-INcorrect'. No, "tumbling fumble" describes having no exception handling and merely allowing the program to "crash". Thus the basic question: why do we (apparently) so seldom consider the possibility of an ImportError? Does it make a difference if operating in/out of a dev-ops environment? I have no idea what "a dev-ops environment means", and I plan on keeping it that way. :) I see that you value your sanity. On the other hand you don't seem so worried about your physical safety - please note that I'll be hiding behind you, should the (ever-so nice) dev-ops lady on one of my projects happen to read this... -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Function to determine list max without itertools
wrote: > > > > > > I have created a function that takes a list as an argument. > > Without using itertools I want to compare each item in the list to find the > > max. > > > > However instead of the max I keep getting the last item in the list. Where > > is my logic wrong here? > > > > def maximum(listarg): > > items = list(listarg) > > myMax = 0 > > for index, item in enumerate(items): > > for otheritem in items[index + 1 :]: > > if item < otheritem: > > myMax = otheritem > > elif item > otheritem: > > myMax = item > > else: > > myMax = myMax > > > > Seems like it should work but doesn't. > > > > I'd recommend rethinking your algorithm first, and then thinking about > debugging your actual code. You should be able to find the largest in > a collection without making many many passes over the items - a single > pass should be sufficient. > > ChrisA Most I am finding either use the max function or itertools. Both of which I am trying not to use so that I actually do it myself. This one on SO is where I was going https://stackoverflow.com/a/3990826/461887 def maxelements(seq): ''' Return list of position(s) of largest element ''' max_indices = [] if seq: max_val = seq[0] for i,val in ((i,val) for i,val in enumerate(seq) if val >= max_val): if val == max_val: max_indices.append(i) else: max_val = val max_indices = [i] return max_indices This is probably the nicest one but still uses Max. >>> a=[5,4,3,2,1] >>> def eleMax(items, start=0, end=None): ... return max(items[start:end]) Thanks Sayth -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Filosofical Finking: Import protections
On 18/04/19 8:45 AM, MRAB wrote: On 2019-04-17 21:20, DL Neil wrote: Do you bother with exception handling for import statements? Can we assume that if such a catastrophic error occurs, it is quite acceptable for the code to fall-over in a tumbling-fumble? [snip] Catch only what you (well, the script) can fix. If it needs numpy, but can't import numpy, then when can it do? Might as well just let it fail. I suppose an alternative might be to try to download and install numpy and then retry, but what if it can't be downloaded, or the installation fails? No, you have to give up at some point. It's better just to report the problem and leave it to the user to fix it. Ah, but is that not the point - the user cannot fix it (and neither should he be allowed to do so: see later comments about Operations functions). What the user faces (unless we more properly handle the exception) is: import davids_brains Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'davids_brains' You and I will think this fine - and 'here' on the list will even beg OPs to give us this much data. However, despite users who have been known to make other comments about my (?lack of) brains, they will tend to offer such helpful advice as: "we need the missing module"...! -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Filosofical Finking: Import protections
On 18/04/19 8:53 AM, Larry Martell wrote: On 2019-04-17 21:20, DL Neil wrote: Do you bother with exception handling for import statements? I often have to do something like this: try: from settings import SITE_WAFER_DIAMETER except ImportError: SITE_WAFER_DIAMETER = 300 That's an interesting application. Most of the multiple input configuration options examples (I've seen) start with a base of the least-prioritised values, and then 'add' higher-priority configuration option-values to that. In this case we: import the config file, but if it's not available use the stated fall-back value(s). Good one! -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Filosofical Finking: Import protections
On 17Apr2019 21:45, MRAB wrote: On 2019-04-17 21:20, DL Neil wrote: Do you bother with exception handling for import statements? [...] Catch only what you (well, the script) can fix. If it needs numpy, but can't import numpy, then when can it do? Might as well just let it fail. I'm of this mind too, but... I suppose an alternative might be to try to download and install numpy and then retry, but what if it can't be downloaded, or the installation fails? As an example of what an open ended can of worms attempts recovery might be, yeah. How hard do you try? But also, "installation fails": that isn't always a clean situation: it can litter the install area with partial junk. But this is also a bad example: it is something an _invoked_ programme should never try to do. Except by specific deliberate design and request, a running application shouldn't presume it has rights to install additional things, or even to try. I have personally (though metaphorically) clipped devs across the ear for doing themselves the moral equivalent of the above: try thing, then just "sudo try thing" when it was forbidden. Particularly in managed environments, the setup is often deliberately designed to not permit this. Consider the app behind a web service: those which are able to install code are in theory open to being manipulated from the outside to install and run code -malicious code. For this reason such enivoronments are deliberately designed so that an app has the barest minimum privileges to perform its task. So: the app _can't_ write to its code area or to the htdocs tree (in whatever form that may be) - that way lies site defacement and application subversion. It can't create tables in the database or modify schemas. It can't modify data it should not touch, or read data it should never see (think reading credential tables or modifying role definitions as some examples). Installing additional packages is the same as self modifying code: as a rule, the admins install packages, not the app. Sorry, ranting now over. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Importing module from another subdirectory
On Thursday, 18 April 2019 06:59:43 UTC+10, Rich Shepard wrote: > What is the proper syntax to import the model class in the model/ > subdirectory into a tkinter view module, e.g., activities.py? The syntax, > 'import model as m' fails because it is not in the same subdirectory as the > importing module. > > The program directory tree is: > > bustrac/ > README.rst > bustrac.py* > controller/ > model/ > scripts/ > views/ > > Running pdb in python3-3.7.3 produces the same error: > $ python3 > Python 3.7.3 (default, Mar 26 2019, 06:40:28) > [GCC 5.5.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import pdb > >>> import activities_data_entry > Traceback (most recent call last): >File "", line 1, in >File > "/home/rshepard/development/business_tracker/views/activities_data_entry.py", > line 1, in > import model.activities as act > ModuleNotFoundError: No module named 'model' > > My previous use of python has had all files in the same directory so I've > not before had to learn how to address this issue. Pointers appreciated. > > Regards, > > Rich Morning Apologies I don't know the answer but went looking. This guide should answer the question. Didn't know it was so difficult to be honest. https://chrisyeh96.github.io/2017/08/08/definitive-guide-python-imports.html#example-directory-structure Then there was this rather long list of traps. http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html Most guides say it was fixed in 3.3 but still seems quite confusing post 3.3 Cheers Sayth -- https://mail.python.org/mailman/listinfo/python-list
Re: Function to determine list max without itertools
On Thu, Apr 18, 2019 at 9:31 AM Sayth Renshaw wrote: > > > I have created a function that takes a list as an argument. > Without using itertools I want to compare each item in the list to find the > max. > > However instead of the max I keep getting the last item in the list. Where > is my logic wrong here? > > def maximum(listarg): > items = list(listarg) > myMax = 0 > for index, item in enumerate(items): > for otheritem in items[index + 1 :]: > if item < otheritem: > myMax = otheritem > elif item > otheritem: > myMax = item > else: > myMax = myMax > > Seems like it should work but doesn't. > I'd recommend rethinking your algorithm first, and then thinking about debugging your actual code. You should be able to find the largest in a collection without making many many passes over the items - a single pass should be sufficient. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Function to determine list max without itertools
I have created a function that takes a list as an argument. Without using itertools I want to compare each item in the list to find the max. However instead of the max I keep getting the last item in the list. Where is my logic wrong here? def maximum(listarg): items = list(listarg) myMax = 0 for index, item in enumerate(items): for otheritem in items[index + 1 :]: if item < otheritem: myMax = otheritem elif item > otheritem: myMax = item else: myMax = myMax Seems like it should work but doesn't. Cheers Sayth -- https://mail.python.org/mailman/listinfo/python-list
Importing module from another subdirectory
What is the proper syntax to import the model class in the model/ subdirectory into a tkinter view module, e.g., activities.py? The syntax, 'import model as m' fails because it is not in the same subdirectory as the importing module. The program directory tree is: bustrac/ README.rst bustrac.py* controller/ model/ scripts/ views/ Running pdb in python3-3.7.3 produces the same error: $ python3 Python 3.7.3 (default, Mar 26 2019, 06:40:28) [GCC 5.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. import pdb import activities_data_entry Traceback (most recent call last): File "", line 1, in File "/home/rshepard/development/business_tracker/views/activities_data_entry.py", line 1, in import model.activities as act ModuleNotFoundError: No module named 'model' My previous use of python has had all files in the same directory so I've not before had to learn how to address this issue. Pointers appreciated. Regards, Rich -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Filosofical Finking: Import protections
On 2019-04-17 21:20, DL Neil wrote: > Do you bother with exception handling for import statements? I often have to do something like this: try: from settings import SITE_WAFER_DIAMETER except ImportError: SITE_WAFER_DIAMETER = 300 -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Filosofical Finking: Import protections
On 2019-04-17 21:20, DL Neil wrote: (I know it's not Friday [exp], and after personal apologies[apo]) Do you bother with exception handling for import statements? Most of the code I read, both in books and during code review, eschews any form of ImportError check. Even data science people who 'clean' every data field towards inclusion/exclusion in the analysis, take for granted that numpy, scipy, pandas, et al, will be available to their code. Does such a check seem un-pythonic? [sto] (maybe 'forgiveness cf permission'?) Can we assume that if such a catastrophic error occurs, it is quite acceptable for the code to fall-over in a tumbling-fumble? Does it make a difference if operating in/out of a dev-ops environment? Might such only occur once, because once the environment has been correctly-built, it will/can *never* happen again? Can we assume Built-in and PSL modules *must* be present, so we only need to talk about covering in-house code and pip-ed (or similar) modules? Is it more/less important in __main__ than in an imported module? Do you handle each import separately, or all in a single try..except block? Do you try to anticipate and cover every import in the system at the top of __main__, eg imports inside imported modules? What about OpSys-specific imports (etc)? Do modules import-ed only in specific situations, deserve more, or less, attention? [snip] Catch only what you (well, the script) can fix. If it needs numpy, but can't import numpy, then when can it do? Might as well just let it fail. I suppose an alternative might be to try to download and install numpy and then retry, but what if it can't be downloaded, or the installation fails? No, you have to give up at some point. It's better just to report the problem and leave it to the user to fix it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Filosofical Finking: Import protections
On 2019-04-17, DL Neil wrote: > Do you bother with exception handling for import statements? Sometimes. There are two cases when I do that: 1. When the module has different names under Python2 and Python3 and the program tries first one, then the other. 2. When the program can still do something useful (if perhaps feature-limited) without the imported module by substituting something else in its place. > Most of the code I read, both in books and during code review, > eschews any form of ImportError check. Even data science people who > 'clean' every data field towards inclusion/exclusion in the > analysis, take for granted that numpy, scipy, pandas, et al, will be > available to their code. You've omitted the second thing assumed by the authors: without numpy, scipy, pandas, et alia the program can do nothing useful. > Does such a check seem un-pythonic? [sto] (maybe 'forgiveness cf > permission'?) It's probably rather unpythonic if you're not going to anything useful in the exception handler. > Can we assume that if such a catastrophic error occurs, it is quite > acceptable for the code to fall-over in a tumbling-fumble? It's certainly OK with me. I'm not sure why you refer to raising an exception as "fall-over in a tumbling fumble". Raising an exception is the normal way to indicate failure in Python. > Does it make a difference if operating in/out of a dev-ops > environment? I have no idea what "a dev-ops environment means", and I plan on keeping it that way. :) -- Grant Edwards grant.b.edwardsYow! WHOA!! Ken and Barbie at are having TOO MUCH FUN!! gmail.comIt must be the NEGATIVE IONS!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Friday Filosofical Finking: Import protections
On Thu, Apr 18, 2019 at 6:21 AM DL Neil wrote: > > (I know it's not Friday [exp], and after personal apologies[apo]) > > > Do you bother with exception handling for import statements? > > > Most of the code I read, both in books and during code review, eschews > any form of ImportError check. Even data science people who 'clean' > every data field towards inclusion/exclusion in the analysis, take for > granted that numpy, scipy, pandas, et al, will be available to their code. > > > Does such a check seem un-pythonic? [sto] (maybe 'forgiveness cf > permission'?) > > Can we assume that if such a catastrophic error occurs, it is quite > acceptable for the code to fall-over in a tumbling-fumble? I try/except around import statements only if it's possible for the program to recover from the exception. For instance, something that runs on Py2 and Py3 might attempt to import from a Py3 name (urllib comes to mind), and if it fails, redo the import from the Py2 name; or something might try to import an optional subroutine, and if it isn't present, set something to None, or to a null function. For something that is absolutely required for the program to continue, what would be in your exception handler? Print a message to stderr and exit? That's exactly what not-catching-the-exception is for. I do sometimes annotate the imports, though: from dataclasses import dataclass # ImportError? Upgrade to Python 3.7 or pip install dataclasses If that bombs out, the entire line will get printed, comment and all, and there isn't really anything else that I would want to do with the exception. So I guess the best way to answer your question is with another question: If such a catastrophic error occurs, what ELSE would your code do than fall over? If there's an answer to that question, then sure, catch the ImportError. Otherwise don't. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Friday Filosofical Finking: Import protections
(I know it's not Friday [exp], and after personal apologies[apo])
Do you bother with exception handling for import statements?
Most of the code I read, both in books and during code review, eschews
any form of ImportError check. Even data science people who 'clean'
every data field towards inclusion/exclusion in the analysis, take for
granted that numpy, scipy, pandas, et al, will be available to their code.
Does such a check seem un-pythonic? [sto] (maybe 'forgiveness cf
permission'?)
Can we assume that if such a catastrophic error occurs, it is quite
acceptable for the code to fall-over in a tumbling-fumble?
Does it make a difference if operating in/out of a dev-ops environment?
Might such only occur once, because once the environment has been
correctly-built, it will/can *never* happen again?
Can we assume Built-in and PSL modules *must* be present, so we only
need to talk about covering in-house code and pip-ed (or similar) modules?
Is it more/less important in __main__ than in an imported module?
Do you handle each import separately, or all in a single try..except block?
Do you try to anticipate and cover every import in the system at the top
of __main__, eg imports inside imported modules?
What about OpSys-specific imports (etc)?
Do modules import-ed only in specific situations, deserve more, or less,
attention?
Refs:
[apo] Change of season coughs and sniffles, duly shared with the CO (oops!)
[exp] Explanation: in the Christian calendar, this Friday is "Good
Friday" and thus a national/public holiday in much of the western world.
Thus, also next ("Easter") Monday and possibly Tuesday. To continue the
theme: next Thursday is also a holiday in New Zealand and Australia
("ANZAC Day": equating to Veterans' Day, Memorial Day, Independence Day,
etc)
[imp] 5. The import system https://docs.python.org/3.6/reference/import.html
[sto] A somewhat similar question:
https://stackoverflow.com/questions/3131217/error-handling-when-importing-modules
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: doctest random output?
On 28/08/2017 20:17, Leam Hall wrote: > On 08/28/2017 11:40 AM, Dennis Lee Bieber wrote: > > ... a bunch of good stuff ... > > I'm (re-)learning python and just trying make sure my function works. > Not at the statistical or cryptographic level. :) > > Thanks! > > Leam If it's supposed to generate values that follow a particular distribution, and they don't, then it doesn't work. I had a bunch of functions for generating values from various distributions. My line manager told me to just set the seed so that the outputs were deterministic. Worse than no test at all. It relied on my original implementation (that generated the values for comparison) working, and only tested if the implementation (of random.random() or my code) had changed. So I ignored my boss and simply generated samples of values and tested using a KS goodness of fit test. The tests should fail 5% of the time. Run them a few times and check that no individual test is failing consistently. I don't see how you can do much better than that. Of course, this doesn't relate directly to doctest. Duncan -- https://mail.python.org/mailman/listinfo/python-list
Re: immutability is not strictly the same as having an unchangeable value, it is more subtle
Hi All,
Thanks for explaining it so nice way. I got it now. What protocols I need to
learn, to define a custom immutable class ?
Thanks,
Arup Rakshit
a...@zeit.io
> On 16-Apr-2019, at 10:54 PM, Dennis Lee Bieber wrote:
>
> On Tue, 16 Apr 2019 13:13:18 +0530, Arup Rakshit declaimed the
> following:
>
>>
>> But what I don’t understand here is that what he said about the immutable
>> container objects. Why after changing the value of internal mutable objects
>> we still say the container object as mutable? Any examples to define what
>> the author meant will be helpful.
>>
>
>
> immTuple = ([], {})
>
> A tuple holding a list and a dictionary. You can not change which list
> or which dictionary -- that is fixed (immutable). But the way Python object
> bindings work is that the list and dictionary are not really IN the tuple
> -- the tuple, in the run time level, has references to the list and
> dictionary, with the those objects being stored somewhere else.
>
> Think of it as the tuple having strings that are tied to the content
> objects. You can not change the strings in the tuple -- they always lead
> from the tuple to the "contained" object. The list and dictionary are also
> containers -- you can add or remove objects (mutation) inside those
> containers, but they remain the same containers.
>
> To really understand this requires understanding Name Binding...
>
> aName = something
>
> binds "aName" to the object "something" (it does not copy something to a
> named variable -- unlike many classic languages; in C, FORTRAN, etc. that
> statement copies the contents of the memory address of "something" to the
> memory address of "aName"). Binding is more like writing "aName" on a
> post-it note, attaching that note to a string, and attaching the other end
> of the string to the object "something" (if "something" is another name,
> you follow the string to the actual object, and bind to the object).
>
> immTuple[0]
>
> accesses the first element (the list) of the tuple -- you can consider it
> to be a "name" bound to the first element..
>
> immTuple[0] = anything
>
> fails because tuples are immutable, and that statement says "change the
> string in the first element of the tuple to connect to a different object"
>
> immTuple[0].append(anything)
>
> works because it follows the string /to/ the list object, and that object
> is a container that allows modification of what it contains.
>
>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> wlfr...@ix.netcom.com
>
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Custom Python web development companies across the globe - ETG - Etisbew Technology Group
ETG one among the best custom Python web development companies across the globe, we cover a wide array of Python web app development services using latest framework like Django, CherryPy, Zope etc. https://bit.ly/2Maf8Hx #pythonwebdevelopmentcompany#djangowebdevelopmentcompany -- https://mail.python.org/mailman/listinfo/python-list
