Sorry, I should have said some integers (like the ones from an integer slider), and some polylines (like the ones from the PolyLine component).
Right, this whole what-type-is-thing-when/type conversion hoopla I personally find frustrating and needlessly complex. What does “look-like” even mean? It doesn’t seem very explicit nor beginner-friendly IMO. I prefer to simply pass things, check their type() and act accordingly. That might not make for the most robust/generic Grasshopper components (but hey, at least they’ll be very explicitly documented in terms of what inputs expect to be passed), but that’s not my intention. It’s to solve design problems as fast and agile as I can. If my intention was to write “real” components I’d be in Visual Studio, following the standards devised by David.
My point is that these pipelines ARE precisely meant for me and my organisation. And as such follows the development standards I’ve been using over the years. Which would benefit from not using type hints. As a customer and longtime user I’m honestly a bit bummed that this doesn’t appear to carry much weight. It’s starting to feel like there’s only one sanctioned McNeel way of using GHPython (i.e. using rhinoscriptsyntax with type hints). Which is a real shame, considering precisely how flexible and agile it in fact is. like, I freaking love the thing right!