On 4/20/2015 9:07 PM, Chris Angelico wrote:
On Tue, Apr 21, 2015 at 10:52 AM, Ben Finney wrote:
Jack is not complaining only about *writing* code. He's complaining
about the effect this will have on code that we all are expected to
*read*.
For reading, good function and parameter names and
On Mon, Apr 20, 2015 at 4:41 PM, Jack Diederich 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 ugly too."
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 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 (co
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
https://mail.python.org/mailman/listinfo/python-
On 20 Apr 2015 14:44, "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 encoura
On Tue, Apr 21, 2015 at 10:52 AM, Ben Finney wrote:
> Chris Angelico writes:
>
>> On Tue, Apr 21, 2015 at 9:41 AM, Jack Diederich 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
Chris Angelico writes:
> On Tue, Apr 21, 2015 at 9:41 AM, Jack Diederich 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
> > an
On Tue, Apr 21, 2015 at 9:41 AM, Jack Diederich 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
> certainly /not/
+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 *tru
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 t
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.
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 wrote:
> On Apr 20,
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 wrote:
> On Mon, Ap
On Mon, Apr 20, 2015 at 2:01 PM, Robert Collins
wrote:
> On 21 April 2015 at 08:50, Harry Percival
> 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 limit
On 21 April 2015 at 10:02, Ian Cordasco 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 designed to be compatible
On Apr 20, 2015, at 3:02 PM, Ian Cordasco 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 to use stub
> (or hin
On Mon, Apr 20, 2015 at 4:00 PM, Harry Percival
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 while."
>
> But I'm
@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
wrote:
> On Mon, 20 Apr 2015, Paul Moore wrote:
>
> On 20 April 2015 at 19:41, Barry Warsaw wrote:
>>
>>> tldr; type hints in python source are scary. Would reserving them for
>>
On Mon, Apr 20, 2015 at 1:50 PM, Harry Percival
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?
>
It's not fundame
On 21 April 2015 at 08:50, Harry Percival 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 its the fundamental
> 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 wrote:
> > "I hate stub files. [...] i
> "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
On Mon, Apr 20, 2015 at 12:51 PM, Nikolaus Rath wrote:
> On Apr 20 2015, Harry Percival 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],
>
On Mon, 20 Apr 2015, Paul Moore wrote:
On 20 April 2015 at 19:41, Barry Warsaw 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
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
On Mon, Apr 20, 2015 at 1:17 PM, Robert Collins
wrote:
> On 21 April 2015 at 08:10, Eric Snow 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 t
>
> 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 annotati
On Mon, Apr 20, 2015 at 1:15 PM, Robert Collins
wrote:
> On 21 April 2015 at 08:07, Guido van Rossum 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 s
On Apr 20 2015, Harry Percival 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, int]]:
>
> a
On 21 April 2015 at 08:10, Eric Snow 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 practices are
> naile
On 21 April 2015 at 08:07, Guido van Rossum 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 support Pytho
On Mon, Apr 20, 2015 at 1:35 PM, Łukasz Langa 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 it would ma
On Mon, Apr 20, 2015 at 12:49 PM, Paul Moore wrote:
>
> On 20 April 2015 at 20:35, Łukasz Langa 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 wi
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
Python-Dev@pyt
On 20 April 2015 at 20:35, Łukasz Langa 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 is something
On Apr 20, 2015, at 11:30 AM, Harry Percival 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 not happen.
>
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 p
On 20 April 2015 at 19:41, Barry Warsaw 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 many of the s
burn the witch..
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,
which seems to be more elegant and natu
On Mon, Apr 20, 2015 at 11:30 AM, Harry Percival 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,
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
___
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 commi
On 4/20/15 7:52 AM, Brett Cannon wrote:
On Mon, Apr 20, 2015 at 10:44 AM Saul Shanabrook
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
advantage of not having
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
> wrote:
>
>> I started trying some CPythong development a week ago at PyCon and first
>> got testing working us
-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,
>
On Mon, Apr 20, 2015 at 10:44 AM 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 also let me test on
> different P
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 laid
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", "robuff
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, a
51 matches
Mail list logo
