Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
Cory Benfield "[email protected]" On Tue, Apr 21, 2015 at 8:47 AM, Cory Benfield wrote: > I'm talking from the position of being a library author, where supporting > versions of Python lower than 3.5 will be a reality for at least 5 more years. > I will not be able to inline my type hints, so they'll have to go in > stub files, and now we've got the same problem: type hints can go out > of step just as easily as documentation can. I imagine authors interested in both type hinting and backwards compatibility could write their code using the 3.0+ annotation syntax, while using the various backwards compatibility packages and schemes, then "split" the source file using some inevitably-available tool to generate both annotation-free source and associated stub files. The author maintains (directly, at least) files on a 1-to-1 ratio -- the fact that they are split prior to distribution is transparent (much like generating documentation from source / comments). Running such a preprocessing step may not be ideal, but it is certainly an option that the motivated package author would seem to have, if they were so inclined. -- FWIW, my gut reaction was the same as many on the list (the syntax can get verbose and negatively impact readability), but I think we're only seeing one side of the eventual coin, looking at individual, sometimes specifically chosen examples. In theory, if this "takes off", IDEs could do a lot to help reduce the burden. Maybe they provide a "read-only" view of functions/methods where annotations are hidden until you put the caret inside the block, at which point the hints are revealed. Maybe even inside the block they're hidden, until you attempt to edit the arguments. Maybe they're just always gathered up by the IDE and accessible through some panel widget. Some of these approaches may sound helpful to some, others not so much, but the point is that there are a lot of creative ways that IDEs *could* help ease the transition, if type hinting becomes of significant interest to the community. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEPs from non-core devs now need a sponsor
I have to say, this is sort of surprising for what seems like the first official action of the steering committee. Are there really *that many *PEPs that a team that is now, what, 5x the size of the BFDL model is worried that they'll be able to keep up? As a long-time lurker, this hardly seems to be the case. Despite the seemingly-well-intentioned rationale, this seems like an ominous sign. On Tue, Mar 5, 2019 at 8:33 AM Jeroen Demeyer wrote: > On 2019-03-05 14:05, Calvin Spealman wrote: > > I'm worried this creates a gatekeeping perception that will scare away > > contributors. > > +1 > > I also expressed this worry at https://github.com/python/peps/pull/903 > > You could keep the positive part of the sponsoring idea (somebody acting > as mentor) but drop the negative part (make it a hard requirement to > find a sponsor supporting the proposal before the proposal can even > become a draft PEP). > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/jheiv%40jheiv.com > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: pathlib.Path: inconsistent symlink_to() and link_to()
Despite the bug being closed as WONTFIX, at the very least this seems like a valid docs issue. But (for whatever a non-core-dev opinion is worth), I'm +1 both on the proposed solution and deprecation.of `link_to()` Jim On Wed, Mar 11, 2020 at 10:45 AM Barney Gale wrote: > Hi, > > Pathlib's symlink_to() and link_to() methods have different argument > orders, so: > > a.symlink_to(b) # Creates a symlink from A to B > a.link_to(b) # Creates a hard link from B to A > > I don't think link_to() was intended to be implemented this way, as the > docs say "Create a hard link pointing to a path named target.". It's also > inconsistent with everything else in pathlib, most obviously symlink_to(). > > Bug report here: https://bugs.python.org/issue39291 > > This /really/ irks me. Apparently it's too late to fix link_to(), so I'd > like to suggest we add a new hardlink_to() method that matches the > symlink_to() argument order. link_to() then becomes deprecated/undocumented. > > Any thoughts? > > Barney > ___ > Python-Dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/7QPLYW36ZK6QTW4SV4FI6C343KYWCPAT/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/5T2D3CUEC6E5PG3ZMLHMAI4N2B2NL7TI/ Code of Conduct: http://python.org/psf/codeofconduct/
