On 07/22/2019 08:12 PM, DL Neil wrote:
On 22/07/19 9:40 PM, Thomas Jollans wrote:
Just FYI, in the scientific Python community certain short abbreviations
are the norm. Many modules have a ‘standard’ abbreviation that most
people use, minimizing confusion.
import numpy as np
import matplotlib
On 07/22/2019 07:27 PM, DL Neil wrote:
NameError conveys nothing to the user.
PythonVersionError is more communicative - and speaks volumes to 'us'.
The mainline code is something like:
p = PythonEnvironment()
try:
p.compatibility( ...spec... ) # eg must be Py3 not 2.n
On 23/07/2019 04.27, DL Neil wrote:
> On 23/07/19 11:00 AM, Ethan Furman wrote:
>> On 07/20/2019 05:02 PM, DL Neil wrote:
>>
>>> Upon closer inspection, I realised it didn't just fail; it failed
>>> badly! Some silly, little, boy had imported the PythonEnvironment
>>> class but failed to ALSO impor
On 23/07/2019 03:27, DL Neil wrote:
On 23/07/19 11:00 AM, Ethan Furman wrote:
On 07/20/2019 05:02 PM, DL Neil wrote:
Upon closer inspection, I realised it didn't just fail; it failed
badly! Some silly, little, boy had imported the PythonEnvironment
class but failed to ALSO import PythonVersio
On 22/07/19 9:40 PM, Thomas Jollans wrote:
On 22/07/2019 07.06, DL Neil wrote:
Current thoughts:
import environment_module as em
- so, even more of an abbreviation than suggested!?
- I rarely need to write a long list of import statements, so there
won't be many.
- not normally using suc
On 23/07/19 11:00 AM, Ethan Furman wrote:
On 07/20/2019 05:02 PM, DL Neil wrote:
Upon closer inspection, I realised it didn't just fail; it failed
badly! Some silly, little, boy had imported the PythonEnvironment
class but failed to ALSO import PythonVersionError. So, the reported
error was n
On 22/07/2019 07.06, DL Neil wrote:
>
> Current thoughts:
>
> import environment_module as em
>
> - so, even more of an abbreviation than suggested!?
> - I rarely need to write a long list of import statements, so there
> won't be many.
> - not normally using such abbreviations in my code, they
On 07/20/2019 05:02 PM, DL Neil wrote:
Upon closer inspection, I realised it didn't just fail; it failed badly! Some
silly, little, boy had imported the PythonEnvironment class but failed to ALSO
import PythonVersionError. So, the reported error was not the expected
exception!
I don't under
On 22/07/19 5:30 AM, Roel Schroeven wrote:
DL Neil schreef op 21/07/2019 om 2:02:
How do you remember to from-import- 'everything' that is needed?
... > Upon closer inspection, I realised it didn't just fail; it
failed badly!
Some silly, little, boy had imported the PythonEnvironment class but
DL Neil schreef op 21/07/2019 om 2:02:
How do you remember to from-import- 'everything' that is needed?
... > Upon closer inspection, I realised it didn't just fail; it failed badly!
Some silly, little, boy had imported the PythonEnvironment class but
failed to ALSO import PythonVersionError. So,
On 2019-07-21 12:02:27 +1200, DL Neil wrote:
> What do you do to (respecting purism) ensure 'everything' (necessary) is
> imported (and nothing more), preferably without relying upon (faulty, in my
> case) human-memory or reading through volumes of code/documentation?
I write tests (not as consist
How do you remember to from-import- 'everything' that is needed?
I have a 'utility module' which contains a bunch of classes which
examine/check/log aspects of the execution environment. One of which is
PythonEnvironment, another relates to the HostSystem (as examples). They
are most-frequent
12 matches
Mail list logo
