# Path: web/core/compat.py



from webob.multidict import MultiDict
from marrow.package.canonical import name
from marrow.package.host import PluginManager
from .compat import py3, pypy
			
			if isinstance(result, kind):
				yield candidate
	
	# ### Plugin Registration
	
	def register(self, kind, handler):
		"""Register a handler for a given type, class, interface, or abstract base class.
		
		View registration should happen within the `start` callback of an extension.  For example, to register the
		previous `json` view example:
		
			class JSONExtension:
				def start(self, context):
					context.view.register(tuple, json)
		
		The approach of explicitly referencing a view handler isn't very easy to override without also replacing the
		extension originally adding it, however there is another approach. Using named handlers registered as discrete
		plugins (via the `entry_point` argument in `setup.py`) allows the extension to easily ask "what's my handler?"
		
			class JSONExtension:
				def start(self, context):
					context.view.register(
							tuple,
							context.view.json
						)
		
		Otherwise unknown attributes of the view registry will attempt to look up a handler plugin by that name.
		"""
		if __debug__:  # In production this logging is completely skipped, regardless of logging level.

# Path: web/core/compat.py



# Path: web/core/view.py
from webob.multidict import MultiDict
from marrow.package.canonical import name
from marrow.package.host import PluginManager
from .compat import py3, pypy

			
			if isinstance(result, kind):
				yield candidate
	
	# ### Plugin Registration
	
	def register(self, kind, handler):
		"""Register a handler for a given type, class, interface, or abstract base class.
		
		View registration should happen within the `start` callback of an extension.  For example, to register the
		previous `json` view example:
		
			class JSONExtension:
				def start(self, context):
					context.view.register(tuple, json)
		
		The approach of explicitly referencing a view handler isn't very easy to override without also replacing the
		extension originally adding it, however there is another approach. Using named handlers registered as discrete
		plugins (via the `entry_point` argument in `setup.py`) allows the extension to easily ask "what's my handler?"
		
			class JSONExtension:
				def start(self, context):
					context.view.register(
							tuple,
							context.view.json
						)
		
		Otherwise unknown attributes of the view registry will attempt to look up a handler plugin by that name.
		"""
		if __debug__:  # In production this logging is completely skipped, regardless of logging level.

			if py3 and not pypy:  # Where possible, we shorten things to just the cannonical name.