On Wed, Apr 22, 2015 at 11:30 AM, Skip Montanaro <skip.montanaro at gmail.com> wrote: > > > On Wed, Apr 22, 2015 at 11:26 AM, Ian Cordasco <graffatcolmingov at gmail.com > > wrote: > >> On a separate thread Cory provided an example of what the hints would >> look like for *part* of one function in the requests public functional API. >> > > Thanks. That encouraged me to look around for recent posts from Cory. > Wow... > You're welcome! And yeah. That union that Cory posted was for *one* parameter if I remember correctly. I won't speak for Cory, but I'm not against the type hints in 484 but they will be difficult for us as a project. They'll be marginally less difficult for me in a different project of mine. I also wonder about importing type definitions from other packages. The Requests-Toolbelt adds a few features that are enhanced versions of what's already in Requests. I can think of a few type hints that we might create to represent certain parameters, but I don't want to have to copy those for the features in the Requests-Toolbelt. I would expect this to "Just Work", but I wonder if anyone else has considered the possibility of this being a need. Cheers, Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150422/08198f01/attachment.html>
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