>>>>> "ARK" == Andrew Koenig <ark@research.att.com> writes:
Jeremy> Hard to say. I can read the code and see that the current
Jeremy> implementation will always return objects of the same type.
Jeremy> In fact, it's using type(sre_compile.compile("", 0))
Jeremy> internally to represent that type.
Jeremy> That's not a guarantee. Perhaps Fredrik wants to reserve
Jeremy> the right to change this in the future. It's not unusual
Jeremy> for Python modules to be under-specified in this way.
ARK> The real point is that this is an example of why a uniform way
ARK> of checking for such types would be nice. I shouldn't have to
ARK> read the source to figure out how to tell if something is a
ARK> compiled regular expression.
Let's assume for the moment that the re module wants to define an
explicit type of compiled regular expression objects. This seems a
sensible thing to do, and it already has such a type internally.
I'm not sure how this relates to your real point. You didn't have to
read the source code to figure out if something is a compiled regular
expression. Instead, I recommended that you use type(obj) where obj
was a compiled regular expression. It might have been convenient if
there was a module constant, such that re.CompiledRegexType ==
type(re.compile("")).
Then you asked if re.compile() was guaranteed to return an object of
the same type. That question is all about the contract of the re
module. The answer might have been: "No. In version X, it happens to
always return objects of the same type, but in version Z, I may want
to change this."
I suppose we could get at the general question of checking types by
assuming that re.compile() returned instances of two apparently
unrelated classes and that we wanted a way to declare their
relationship. I'm thinking of something like Haskell typeclasses
here.
Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4