<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 7 Apr 2016 at 12:36 Random832 <<a href="mailto:random832@fastmail.com">random832@fastmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Apr 7, 2016, at 15:17, Brett Cannon wrote:<br>
> How do you make Python 3.3 code work with this when the ABC will simply<br>
> not<br>
> be available to you unless you're running Python 3.4.3, 3.5.2, or 3.6.0<br>
> (under the assumption that the ABC is put in pathlib and backported<br>
> thanks<br>
> to its provisional status)? The ternary operator one-liner is<br>
> backwards-compatible while the ABC is only forward-compatible.<br>
<br>
If it's not available to you, then it's not available to anyone to<br>
register either, so you obviously act as if no objects are StringLike if<br>
you get an ImportError when trying to use it. Isn't this just the<br>
standard dance for using *any* function that's new to a new version of<br>
Python?<br></blockquote><div><br></div><div>Yes, but the lack of a magic method is not as severe as a lack of an ABC you will be using in an isinstance() check.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
try:<br>
from pathlib import StringLike # if it's in pathlib why is it called<br>
StringLike?<br></blockquote><div><br></div><div>I called it StringLike because I was replying to Chris' proposal of a generic string-like protocol (which wouldn't live in pathlib).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
def is_StringLike(x): return isinstance(x, StringLike)<br>
except ImportError:<br>
def is_StringLike(x): return False<br></blockquote><div> <br></div><div>That would cut out all third-party libraries no matter what their Python version support was.</div><div><br></div><div>My point is that if I wanted this to work in Python 3.3.x, Python 3.4.2, or Python 3.5.1 then the ABC solution is out as the ABC won't exist. The magic method, though, would still work with the one-liner all the way back to Python 2.5 when conditional expressions were added to the language.</div><div><br></div><div>For instance, let's say I'm the author of a library that uses file paths that wants to support Python 3.3 and newer. How do I add support for using pathlib.Path and Ethan's path library? With the magic method solution I can use:</div><div><br></div><div> def ospath(path):</div><div> return path.__ospath__() if hasattr(path, '__ospath__') else path</div><div><br></div><div>If I really wanted to I could just embed that wherever I want to work with paths.</div><div><br></div><div>Now how about the ABC?</div><div><br></div><div> # In pathlib.</div><div> class StringPath(abc.ABC):</div><div> @abstractmethod</div><div> def __str__(self): ...</div><div><br></div><div> StringPath.register(pathlib.PurePath, str) # Maybe not cover str?</div><div><br></div><div> # In my library trying to support Python 3.3 and newer, pathlib and Ethan's path library.</div><div> try:</div><div> from importlib import StringPath</div><div> except ImportError:</div><div> StringPath = None</div><div><br></div><div> def ospath(path):</div><div> if StringPath is None:</div><div> if isinstance(path, StringPath):</div><div> return str(path)</div><div> # What am I supposed to do here?</div><div><br></div><div>Now you could set `StringPath = object`, but that starts to negate the point of not subclassing strings as you're now accepting anything that defines __str__() in that case unless you're on a version of Python "new" enough to have pathlib w/ the ABC defined. And if you go some other route, what would you want to do if StringPath wasn't available?</div><div><br></div><div>So the ABC vs magic method discussion comes down to whether we think third-party libraries will use whatever approach is decided upon and whether they care about how good the support is for Python 3.3.x, 3.4.2, and 3.5.1.</div></div></div>