Namespaces: memory vs 'pollution'

[DL Neil]

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 not the expected exception!
> 
> I don't understand the significance of not importing PythonVersionError:
> 
> - PythonEnvironment does not need it to be imported
> 
> - when PythonEnvironment raises PythonVersionError you still get 
> PythonVersionError
> 
> - if your code says `except PythonVersionError` and you haven't imported 
> it you'll get a NameError
> 
> So, what's the issue?


Have I correctly understood the question?

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
	except PythonVersionError:
		print( more illuminating errmsg )

If I am 'the user' I'd be quite happy without the try...except; but mere 
mortals need/deserve something more. Accordingly, the PythonVersionError 
custom exception/class.

Yes, we could trap NameError, but that might also catch other 
name-errors (unlikely in this example, but 'just sayin'). Thus the 
greater specificity of the custom class.


NB please see alternative 'solution' proposed (for critique) as "Nesting 
Custom Errors in Classes" discussion topic.
-- 
Regards =dn