On Mon, Apr 20, 2015 at 4:00 PM, Harry Percival harry.perci...@gmail.com
wrote:
@Lukasz:
Of course you're right, ugly is a matter of perspective, and I'm sure I
could grow to love them, and they might evolve into a more polished
direction
they start to read more transparently after a
exactly. yay stub files! we all agree! everyone loves them! boo type
annotations inline in python source. only some people love them. and even
then, only after a while, and only tentatively... and some people fear
them, mightily...
On 20 April 2015 at 23:14, Łukasz Langa luk...@langa.pl
So I guess the main difference is that type annotations in stub files
wouldn't be available at runtime? Ie, they wouldn't magically appear in
__annotations__ (unless the python interpreter itself started to evaluate
stub files too)
On 20 April 2015 at 22:02, Guido van Rossum gu...@python.org
I hate stub files. [...] in my opinion, [it] just about guarantees a
maintenance burden that will fall by the side of the road.
I'm not so pessimistic. It's not like documentation or docstrings or
comments -- the whole point is that it should be very easy to have an
automated check for whether
I wrote a longer response and then realized it didn't really add much to
the discussion. So let me be short: type annotations do *not* appeal to
me, and I am not looking forward to the cognitive overhead of dealing
with them. Perhaps I will eventually grow to like them if the tools
that use them
Twelve years ago a wise man said to me I suggest that you also propose a
new name for the resulting language
I talked with many of you at PyCon about the costs of PEP 484. There are
plenty of people who have done a fine job promoting the benefits.
* It is not optional. Please stop saying that.
On Mon, Apr 20, 2015 at 1:17 PM, Robert Collins robe...@robertcollins.net
wrote:
On 21 April 2015 at 08:10, Eric Snow ericsnowcurren...@gmail.com wrote:
While it helps, this sort of best-practice is still unsettled (and
apparently not obvious). In the short term it would make more
@Lukasz:
Of course you're right, ugly is a matter of perspective, and I'm sure I
could grow to love them, and they might evolve into a more polished
direction
they start to read more transparently after a while.
But I'm still worried about beginners, and I'm even worried about me. I
like to
Only if you want Java users burning all written copies of the PEP...
On Mon, Apr 20, 2015 at 2:37 PM, Isaac Morland ijmor...@uwaterloo.ca
wrote:
On Mon, 20 Apr 2015, Paul Moore wrote:
On 20 April 2015 at 19:41, Barry Warsaw ba...@python.org wrote:
tldr; type hints in python source are
+1 to this from me too. I'm afraid that means I'm -1 on the PEP.
I didn't write this in my earlier email because I wasn't sure about it,
but my gut reaction after reading Harry's email was if type annotations
are used in the stdlib, I'll probably stop contributing. That doesn't
mean that's
On 20 Apr 2015 14:44, Barry Warsaw ba...@python.org wrote:
On Apr 20, 2015, at 07:30 PM, Harry Percival wrote:
tldr; type hints in python source are scary. Would reserving them for
stub
files be better?
I think so. I think PEP 8 should require stub files for stdlib modules
and
strongly
Sounds great right? Everybody will be happy! So let's nail it down! If I
was in charge, here's what I'd do:
* standardise the syntax for type hints in 3.5, as per PEP484
* but: recommend the use of stub files as the preferred place to store
hints
* and: deprecate function annotations in
stub files are only used to type-check *users* of a module. If you want a
module itself to be type-checked you have to use inline type hints
is this a fundamental limitation, or just the current state of tooling?
On 20 April 2015 at 21:48, Harry Percival harry.perci...@gmail.com wrote:
I
On 21 April 2015 at 10:02, Ian Cordasco graffatcolmin...@gmail.com wrote:
So I've generally stayed out of this but I feel there is some context that
people are missing in general.
First, allow me to provide some context: I maintain a /lot/ of Python
code[1] and nearly all of it is
On Mon, Apr 20, 2015 at 2:01 PM, Robert Collins robe...@robertcollins.net
wrote:
On 21 April 2015 at 08:50, Harry Percival harry.perci...@gmail.com
wrote:
stub files are only used to type-check *users* of a module. If you want
a
module itself to be type-checked you have to use inline type
Although I like the concept of type annotations and the PEP, I have to
agree with this. If I saw these type annotations when learning Python (I'm
self-taught), there's a 99% chance I would've freaked.
It's the same issue as with teaching C++: it's wrong to say, Hey, I taught
you the basics, but
On Mon, Apr 20, 2015 at 1:15 PM, Robert Collins robe...@robertcollins.net
wrote:
On 21 April 2015 at 08:07, Guido van Rossum gu...@python.org wrote:
The situation is possibly even bleaker (or happier, depending on your
position :-) for inline type hints in 3rd party packages -- few package
On 21 April 2015 at 08:50, Harry Percival harry.perci...@gmail.com wrote:
stub files are only used to type-check *users* of a module. If you want a
module itself to be type-checked you have to use inline type hints
is this a fundamental limitation, or just the current state of tooling?
AIUI
Chris Angelico ros...@gmail.com writes:
On Tue, Apr 21, 2015 at 9:41 AM, Jack Diederich jackd...@gmail.com wrote:
* It is not optional. Please stop saying that. The people promoting
it would prefer that everyone use it. If it is approved it will be
optional in the way that PEP8 is
On Mon, Apr 20, 2015 at 12:51 PM, Nikolaus Rath nikol...@rath.org wrote:
On Apr 20 2015, Harry Percival hj...@cantab.net wrote:
My first reaction to type hints was yuck, and I'm sure I'm not the only
one to think that. viz (from some pycon slides):
def zipmap(f: Callable[[int, int],
On Mon, 20 Apr 2015, Paul Moore wrote:
On 20 April 2015 at 19:41, Barry Warsaw ba...@python.org wrote:
tldr; type hints in python source are scary. Would reserving them for stub
files be better?
I think so. I think PEP 8 should require stub files for stdlib modules and
strongly encourage
On Mon, Apr 20, 2015 at 1:50 PM, Harry Percival harry.perci...@gmail.com
wrote:
stub files are only used to type-check *users* of a module. If you want
a module itself to be type-checked you have to use inline type hints
is this a fundamental limitation, or just the current state of tooling?
On Apr 20, 2015, at 3:02 PM, Ian Cordasco graffatcolmin...@gmail.com wrote:
I think while the authors are currently seeing stubs as a necessary *evil*
they're missing points where they're a better backwards compatible solution
for people who want to give users with capable IDEs the ability
On Tue, Apr 21, 2015 at 9:41 AM, Jack Diederich jackd...@gmail.com wrote:
* It is not optional. Please stop saying that. The people promoting it would
prefer that everyone use it. If it is approved it will be optional in the
way that PEP8 is optional. If I'm reading your annotated code it is
On Tue, Apr 21, 2015 at 10:52 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Chris Angelico ros...@gmail.com writes:
On Tue, Apr 21, 2015 at 9:41 AM, Jack Diederich jackd...@gmail.com wrote:
* It is not optional. Please stop saying that. The people promoting
it would prefer that everyone
On Mon, Apr 20, 2015 at 11:34:51PM +0100, Harry Percival wrote:
exactly. yay stub files! we all agree! everyone loves them!
Not even close.
--
Steve
___
Python-Dev mailing list
Python-Dev@python.org
On Mon, Apr 20, 2015 at 4:41 PM, Jack Diederich jackd...@gmail.com wrote:
Twelve years ago a wise man said to me I suggest that you also propose a
new name for the resulting language
The barrage of FUD makes me feel like the woman who asked her doctor for a
second opinion and was told you're
On Mon, Apr 20, 2015 at 07:30:39PM +0100, Harry Percival wrote:
Hi all,
tldr; type hints in python source are scary. Would reserving them for stub
files be better?
No no no, a thousand times no it would not!
Please excuse my extreme reaction, but over on the python-list mailing
list
On Mon, Apr 20, 2015 at 02:41:06PM -0400, Barry Warsaw wrote:
On Apr 20, 2015, at 07:30 PM, Harry Percival wrote:
tldr; type hints in python source are scary. Would reserving them for stub
files be better?
I think so. I think PEP 8 should require stub files for stdlib modules and
On Mon, Apr 20, 2015 at 12:49 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 20 April 2015 at 20:35, Łukasz Langa luk...@langa.pl wrote:
Since it was mentioned in a different e-mail in this thread: yes, the
standard library is not getting any type annotations. When we decide to
ship type
On Mon, Apr 20, 2015 at 1:35 PM, Łukasz Langa luk...@langa.pl wrote:
Yeah, so agreed, this is pretty busy. For such cases, reformatting makes
it less confusing (see: Screenshot 1).
While it helps, this sort of best-practice is still unsettled (and
apparently not obvious). In the short term
On 21 April 2015 at 08:07, Guido van Rossum gu...@python.org wrote:
The situation is possibly even bleaker (or happier, depending on your
position :-) for inline type hints in 3rd party packages -- few package
authors will be satisfied with supporting only Python 3.5 and later. True,
you can
On 21 April 2015 at 08:10, Eric Snow ericsnowcurren...@gmail.com wrote:
While it helps, this sort of best-practice is still unsettled (and apparently
not obvious). In the short term it would make more sense to recommend using
stub files for all the reason Harry enumerated. Once the best
On Apr 20 2015, Harry Percival hj...@cantab.net wrote:
My first reaction to type hints was yuck, and I'm sure I'm not the only
one to think that. viz (from some pycon slides):
def zipmap(f: Callable[[int, int], int], xx: List[int],
yy: List[int]) - List[Tuple[int, int,
On behalf of the Python development community and the Python 3.5 release
team, I'm thrilled to announce the availability of Python 3.5.0a4.
Python 3.5.0a4 is the fourth and alpha release of Python 3.5, which will
be the next major release of Python. Python 3.5 is still under
development,
On Apr 19, 2015, at 01:19 AM, Larry Hastings wrote:
We should rename types to accept. accept should takes a set of types;
these types specify the types of Python objects the Clinic parameter should
accept. For the funny pseudo-types needed in some Clinic declarations
(buffer, robuffer, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-04-20 15:52, Saul Shanabrook wrote:
I started trying some CPythong development a week ago at PyCon and
first got testing working using Docker on my mac. This had the
advantage of not having to worry about installing and dependencies,
and
I started trying some CPythong development a week ago at PyCon and first
got testing working using Docker on my mac. This had the advantage of not
having to worry about installing and dependencies, and also let me test on
different Python versions easily.
If you are interested in trying it, I
On Mon, Apr 20, 2015 at 10:44 AM Saul Shanabrook s.shanabr...@gmail.com
wrote:
I started trying some CPythong development a week ago at PyCon and first
got testing working using Docker on my mac. This had the advantage of not
having to worry about installing and dependencies, and also let me
On Mon, Apr 20, 2015 at 12:13 PM Carol Willing
willi...@willingconsulting.com wrote:
On 4/20/15 7:52 AM, Brett Cannon wrote:
On Mon, Apr 20, 2015 at 10:44 AM Saul Shanabrook s.shanabr...@gmail.com
wrote:
I started trying some CPythong development a week ago at PyCon and first
got testing
On 4/20/15 7:52 AM, Brett Cannon wrote:
On Mon, Apr 20, 2015 at 10:44 AM Saul Shanabrook
s.shanabr...@gmail.com mailto:s.shanabr...@gmail.com wrote:
I started trying some CPythong development a week ago at PyCon and
first got testing working using Docker on my mac. This had the
Hi all,
tldr; type hints in python source are scary. Would reserving them for stub
files be better?
For people that don't know me (most of you I think), I don't have a long
experience of programming (perhaps 5 years, barring a bit of messing about
with BASIC in the 80s), I've never made any
voice-from-audience
burn the witch..
/voice-from-audience
More seriously.. +1 to Harry voice. Adding type hints to function code is
so ugly that that i'm breaking silence and i'm expressing it here before
you, so:
It's ugly
Perhaps this question was asked a million times, but why not docstrings,
On Apr 20, 2015, at 07:30 PM, Harry Percival wrote:
tldr; type hints in python source are scary. Would reserving them for stub
files be better?
I think so. I think PEP 8 should require stub files for stdlib modules and
strongly encourage them for 3rd party code.
Cheers,
-Barry
On Mon, Apr 20, 2015 at 11:30 AM, Harry Percival hj...@cantab.net wrote:
My first reaction to type hints was yuck, and I'm sure I'm not the only
one to think that. viz (from some pycon slides):
def zipmap(f: Callable[[int, int], int], xx: List[int],
yy: List[int]) -
On 20 April 2015 at 19:41, Barry Warsaw ba...@python.org wrote:
tldr; type hints in python source are scary. Would reserving them for stub
files be better?
I think so. I think PEP 8 should require stub files for stdlib modules and
strongly encourage them for 3rd party code.
Agreed. I have
On 04/20, Barry Warsaw wrote:
On Apr 20, 2015, at 07:30 PM, Harry Percival wrote:
tldr; type hints in python source are scary. Would reserving them for stub
files be better?
I think so. I think PEP 8 should require stub files for stdlib modules and
strongly encourage them for 3rd party
On Apr 20, 2015, at 11:30 AM, Harry Percival hj...@cantab.net wrote:
I think:
- type hints are ugly
Making them work with the current Python syntax was a challenge. Granted, the
end result is not perfect. It can be improved *if* type hints prove to be
generally useful and popular. This might
On 20 April 2015 at 20:35, Łukasz Langa luk...@langa.pl wrote:
Since it was mentioned in a different e-mail in this thread: yes, the
standard library is not getting any type annotations. When we decide to
ship type hints with Python 3.6, they will be added as stubs.
Why is this? Surely this
Just another peanut from the gallery: I pretty much agree with everything
that harry said. My current response to type annotations is Yuck, that
kills readability. I hope no code I ever have to read uses this..
___
Python-Dev mailing list
50 matches
Mail list logo