subject:"\[Python\-ideas\] Re\: For\-expression\/throwaway comprehension"

On Sat, Aug 3, 2019 at 3:44 PM Steven D'Aprano  wrote:
>
> On Sat, Aug 03, 2019 at 03:52:31AM +1000, Chris Angelico wrote:
>
> > Also a bit old-school (it took me many years to learn the value of
> > syntax highlighting), and an educator, and I've seen students start
> > out with Jupyter. As an alternative to the vanilla REPL, I think it's
> > awesome
> [...]
> > But for discoverability, incl tab completion? It's great
>
> *scratches head*

Yeah, you kinda edited me to having a quite different meaning there.
That wasn't what I said, thank you.

> Do people forget that the vanilla Python REPL has come with tab
> completion for nearly 20 years, and on by default for something like
> seven years?
>
> https://hg.python.org/cpython/rev/d5ef330bac50
> https://docs.python.org/release/2.0/lib/module-rlcompleter.html
>
> (At least on Linux/POSIX systems. I don't know if it works on Windows
> or Macs.)

1) I don't trust it on arbitrary (mostly Windows) systems, so when I'm
recommending to other people, I can't be confident of it.

2) Until recently, tab completion conflicted with tab indentation,
making the default REPL very annoying.

3) In many terminals, tab completion of an entire module's contents is
impractical. It's fine when you already have the beginning of what
you're looking for (eg 1.1.as  to get as_integer_ratio), but this
thread is about discoverability, and a lot of modules have enough in
them that modulename. is just going to spam your terminal.
GUI tools tend to do better at this.

I'm not discounting the value of the vanilla REPL's tab completion,
but it is not the ultimate in discoverability.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KA7NG5DYM5RVN2IP4IUTWMJWUPYSS5FU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

On Sat, Aug 03, 2019 at 03:52:31AM +1000, Chris Angelico wrote:

> Also a bit old-school (it took me many years to learn the value of
> syntax highlighting), and an educator, and I've seen students start
> out with Jupyter. As an alternative to the vanilla REPL, I think it's
> awesome 
[...]
> But for discoverability, incl tab completion? It's great

*scratches head* 

Do people forget that the vanilla Python REPL has come with tab 
completion for nearly 20 years, and on by default for something like 
seven years?

https://hg.python.org/cpython/rev/d5ef330bac50
https://docs.python.org/release/2.0/lib/module-rlcompleter.html

(At least on Linux/POSIX systems. I don't know if it works on Windows 
or Macs.)

I've had Linux-using Python programmers tell me that they couldn't 
imagine not using Jupyter specifically because of tab completion. They 
weren't even aware that the standard interpreter has it as a feature.

-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LYROBC6QVZZ32SPOWQ4UTEGEP7KN5TPY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

On Sat, Aug 03, 2019 at 10:02:39AM +1000, Chris Angelico wrote:
> On Sat, Aug 3, 2019 at 9:48 AM Steven D'Aprano  wrote:
> >
> > On Fri, Aug 02, 2019 at 07:52:37AM +1000, Chris Angelico wrote:
> >
> > > Maybe there needs to be a
> > > second-tier recommendation, where a list of packages can be given that
> > > aren't category killers, but have been given the blessing of the
> > > Python devs as "this is a good-quality, well-maintained package, and
> > > can be depended on"?
> >
> > Which of the core devs will have the responsibility for checking that
> > something which is a good-quality, well-maintained, dependable package
> > today remains so a year from now?
> 
> Nobody. The recommendation would simply be "this is good NOW".

Sure. And "NOW" means *now* when I'm reading the docs, right? *wink*

How is the reader supposed to know whether a recommendation made in 2012 
is still valid, or if the state of the art has moved on to something 
else? Any such recommendation is subject to bit-rot. Doc-rot? If its not 
actively maintained by somebody, it won't be long before the docs are 
doing the equivalent of recommending that people use Psyco:

https://wiki.python.org/moin/UsefulModules#Platform-Specific

Psyco has been unmaintained for more than seven years.

Now, something like Psyco is not too bad. At least when you go to 
install it, you can't help but notice the great big notice saying that 
its unmaintained. But what happens when a recommended package is still 
actively maintained, but has been overtaken as "best of breed" by 
another package?

The point is, if the core devs are to take on the responsibility for 
listing "best of breed" third-party libraries, somebody has to accept 
the responsibility for actively maintaining that list, or it will rot.

[...]
> > There are third-party libraries like numpy, nltk etc which are too
> > specialised, big and complex for anyone to duplicate in their own code.
> 
> And it's "common knowledge" that numpy, ntlk, etc are all
> well-respected pieces of software, but how is that common knowledge to
> be acquired?

The same way any common knowledge is acquired: by interacting with 
people who already have that knowledge, whether they are mentors, 
trainers, more experienced work-mates, bloggers that you read, people 
who answer Stackoverflow questions, etc.

There's a whole community of people capable of passing on this 
knowledge, the core devs don't have to take it on too. It isn't as if 
nobody can find out which third-party libraries to use if they aren't 
listed in the official Python docs.

> It must be good, because it's the very first search result, right?

Learning to have a healthy skepticism of Google and the internet is a 
necessary part of the gaining of experience.

-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZVYEBWYECFCHSIK4ELFGZ3IO25PJXRVT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

On Aug 2, 2019, at 19:22, Brendan Barnwell  wrote:
> 
>> On 2019-08-02 19:16, Andrew Barnert wrote:
>> 
>> So, that’s the way forward. You could port the recipes to C and
>> change the docs recipes to be “roughly equivalent” Python code in the
>> help for each function. Or you could port itertools to Python plus C
>> accelerator and then just copy-paste the recipes into the Python
>> part. I suspect the latter would be easier to get accepted, but I
>> have no idea whether it’s more or less work.
> 
>Does "port itertools to Python plus C accelerator" include "write a thin 
> Python wrapper around the existing C"?  

No. PEP 399 doesn’t say that would be accepted. But all that means is that 
there’s no PEP saying there should be a presumption in favor of your patch 
being accepted. i suspect that makes it the same situation as 99% of the other 
patches on b.p.o. And it would certainly be a lot less work.

So if you want to try it and see what Raymond says, I’d say go for it. Sure, 
it’s possible he’ll say no, or ask some follow up questions, or say it should 
go back to -ideas or -dev for more discussion, or whatever, but the easiest way 
to find out (unless he joins this thread) is to just file the bug and add the 
patch.

(By the way, why not just read PEP 399 instead of asking and then relying on 
the interpretation of some random guy on the internet?)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/D3OWQXXOBAKQSFSSUHQYSRXWKETBQAMT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

On Aug 2, 2019, at 11:34, Christopher Barker  wrote:
> 
> The other issue here, in the context of the OP's proposal, is that it's less 
> than obvious that that's what a user would want when they want to operate on 
> all the items in a iterable without creating a new iterable. To Guido's 
> point, the way to do this now is:
> 
> for i in an_iterable: act_on(i)
> 
> Is simple, obvious and compact, though not "functional" or "using the 
> comprehension syntax".

Where I find consume useful is when I already have an iterator. I have a long 
chain of functional-style iterable transforms (mostly genexprs and itertools 
calls) leaving me with a final thing that represents the whole computation, but 
it’s lazy and I need it strictly evaluated now (generally because it has side 
effects, or because I don’t know from inspection whether it does).

If I don’t already have an iterator, I wouldn’t create one just to pass to 
consume to run some side effects; I’d write your example the same way Guido 
suggested. The OP’s only problem is that he created an unnecessary genexpr, and 
the solution is to just not create the unnecessary genexpr. It’s one of those 
“Doctor, Doctor, it hurts when I punch myself in the neck” “OK, so don’t punch 
yourself in the neck” cases.

But… when someone really does seem to be looking for consume, even in a place 
where I wouldn’t use it. I may tell them why I wouldn’t use it, but I’ll still 
tell them that the function they’re looking for is named consume, and where to 
find and/or how to write it.

In fact, looking back at the message that started this whole side track, that’s 
exactly what I did. If it had already been in itertools, I’d still have 
explained why I think his #3 is better than his #2, but the rest would just be 
one line: “But if you really want that run function, it already exists: `from 
itertools import consume as run`”.

I don’t think that’s a big enough win on its own to be worth someone rewriting 
itertools so consume can be added. But maybe consume plus grouper plus some of 
the less trivial recipes (or, more simply, just all of them, to avoid 
bikeshedding arguments on each one) is.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OHWZNEAFOX7MP237O3FXIUUICZEPQQ7Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

On 2019-08-02 19:16, Andrew Barnert wrote:

PEP 399 says all _new_ modules (that don’t have a good reason for a
special dispensation) have to have a pure Python implementation. But
it explicitly says that pre-existing modules in the stdlib didn’t
need to be rewritten, and most of them haven’t been. (Raymond wrote
itertools long before 3.2, even long before the discussion around 3.0
that eventually led to the PEP.) It also says that if someone like
the PyPy developers wants to rewrite an existing C module to be a
pure-Python module with a C accelerator it should/will probably be
accepted, but that only applies if someone does the rewrite and
submits it.

So, that’s the way forward. You could port the recipes to C and
change the docs recipes to be “roughly equivalent” Python code in the
help for each function. Or you could port itertools to Python plus C
accelerator and then just copy-paste the recipes into the Python
part. I suspect the latter would be easier to get accepted, but I
have no idea whether it’s more or less work.

Does "port itertools to Python plus C accelerator" include "write a
thin Python wrapper around the existing C"? That is, would it be
possible to write a pure-Python wrapper around the existing C itertools
(renaming that existing C module to _itertools or whatever), and add the
recipes as pure Python in the wrapper but without a C implementation?
Or would that not be accepted?

--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/XRLA2ICKKCCBY6YBXCQQDQEBYUEI2RXR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

On Aug 2, 2019, at 15:45, Steven D'Aprano  wrote:
> 
> Are infinite for-loops that common that people get excited by cycle? 
> That sounds like the "here's a hammer, now every problem is a nail" 
> issue. "itertools.cycle is cool, I must use it as often as possible!"

Well, they’re probably excited that the function they spent the last three 
hours debugging some fence post error on can be replaced by a single line, not 
that every program for the rest of their life will be similarly improved.

(Once you get the itertools way of doing things, a whole lot of programs for 
the rest of your life _are_ similarly improved. But I don’t think cycle is 
enough to get that across. If someone wants to learn more, I usually point them 
to… I don’t have the links with me, but it’s Generator Tools for Systems 
Programmers v2, and something that was part of the pitch for yield from that I 
can’t remember.)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ALMCUV32DZF25EQMH6P24KDVJV2LQGAN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

On Sat, Aug 3, 2019 at 9:48 AM Steven D'Aprano  wrote:
>
> On Fri, Aug 02, 2019 at 07:52:37AM +1000, Chris Angelico wrote:
>
> > Maybe there needs to be a
> > second-tier recommendation, where a list of packages can be given that
> > aren't category killers, but have been given the blessing of the
> > Python devs as "this is a good-quality, well-maintained package, and
> > can be depended on"?
>
> Which of the core devs will have the responsibility for checking that
> something which is a good-quality, well-maintained, dependable package
> today remains so a year from now?

Nobody. The recommendation would simply be "this is good NOW".
Anything can change in the future, and if someone sees something
saying "as of 2012, that was a good package", it's up to them to see
if it's still good. Of course, any core dev can go tag something and
say "still good".

> There are third-party libraries like numpy, nltk etc which are too
> specialised, big and complex for anyone to duplicate in their own code.

And it's "common knowledge" that numpy, ntlk, etc are all
well-respected pieces of software, but how is that common knowledge to
be acquired?

> But I think that anyone who pip installs more-itertools *solely* to
> avoid copying and pasting the "grouper" receipe from the docs is doing
> themselves, and the users of their software, a disservice. It's three
> lines of code. Adding a third-party dependency of 2000+ sloc to avoid a
> three liner is not as bad as the Node.js LeftPad debarcle, but it's
> heading into the same ballpark.

This is true, but only because we're talking about a single three-line
function...

> (Of course the calculus changes if you are a heavy consumer of
> iterators, and the extra tools in more-itertools are useful for you.)

... and the best way to BECOME a heavy consumer of iterators is to
flip through itertools and more-itertools, find that this is way
easier than what you were doing previously, and start using more of
the functions. So even if you start out by getting more-itertools as
an alternative to copying and pasting a three-line function, you may
find that you end up using a lot more of it.

But there's still a *huge* difference between "import itertools" and
"import some-package-nobody-knows-of". I just want to narrow that gap
a little by giving recognition to those packages which are dependable
and high quality. I did a PyPI search for "itertools" and this was
what came up first:

https://pypi.org/project/itertools-s/

It must be good, because it's the very first search result, right?
I'll just pip-install it and start using it. Or should I look
somewhere else for an enhanced itertools? How would I know? With a
published list of known-excellent packages, there could be three or
four itertoolses, not ten pages of search results, and you could know
for sure that each and every one of them is worthy of at least a bit
of a look.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/36RVI6M4JSW7CGJWFBALGDHZ47LUQ5UD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

On Fri, Aug 02, 2019 at 07:52:37AM +1000, Chris Angelico wrote:

> Maybe there needs to be a
> second-tier recommendation, where a list of packages can be given that
> aren't category killers, but have been given the blessing of the
> Python devs as "this is a good-quality, well-maintained package, and
> can be depended on"?

Which of the core devs will have the responsibility for checking that 
something which is a good-quality, well-maintained, dependable package 
today remains so a year from now?

There are third-party libraries like numpy, nltk etc which are too 
specialised, big and complex for anyone to duplicate in their own code. 
But I think that anyone who pip installs more-itertools *solely* to 
avoid copying and pasting the "grouper" receipe from the docs is doing 
themselves, and the users of their software, a disservice. It's three 
lines of code. Adding a third-party dependency of 2000+ sloc to avoid a 
three liner is not as bad as the Node.js LeftPad debarcle, but it's 
heading into the same ballpark.

(Of course the calculus changes if you are a heavy consumer of 
iterators, and the extra tools in more-itertools are useful for you.)

-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/G6TPH6MESITYI2F6MTPWWWASXULO4H6T/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

On Thu, Aug 01, 2019 at 12:31:48PM -0700, Andrew Barnert via Python-ideas wrote:

> Plus, there is another potential argument for adding at least some of 
> the recipes to the module. When I show a novice how to import and use 
> cycle, they they get excited and go off and use it.

Are infinite for-loops that common that people get excited by cycle? 
That sounds like the "here's a hammer, now every problem is a nail" 
issue. "itertools.cycle is cool, I must use it as often as possible!"

I think I've used it once or twice, but I don't remember why.

> When I show them
> how to copy and paste grouper, they sometimes seem reluctant—I’m 
> encouraging them to put code they don’t understand into their source 
> files.

I expect that the average novice has *vast* amounts of code they don't 
understand in their source files, some of it borrowed from Stackoverflow 
or copied and pasted from elsewhere. On the tutor mailing list, 
debugging by random perturbation until it stops raising an exception is 
a very common trap for novices, so often they don't understand their own 
code. I am skeptical that reluctance to use code they don't understand 
is the reason for their reluctance to copy and paste.

In any case, why is "copy and paste three lines of code I don't 
understand" worse than "add a dependency of a third-party library you 
download from the Internet of hundreds, maybe thousands, of lines I 
don't understand"?

-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JS6X2YXVTOYC5NQBFEBWHOGGXQXMJN7Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread David Mertz

There *is* also the '%load' magic. But 'from my_stuff import *' is almost
always a better idea.

On Fri, Aug 2, 2019, 2:49 PM Christopher Barker  wrote:

> Getting really OT now, but quickly:
>
> On Fri, Aug 2, 2019 at 11:28 AM Chris Angelico  wrote:
>
>> On Sat, Aug 3, 2019 at 4:19 AM Ricky Teachey  wrote:
>> > Remember that Jupyter has a pretty nice text editor
>
>
> Actually, I think it's pretty darn crappy -- at least compared to any
> "proper" coding editor...
>
>
>> Although I didn't know you could import a .py file into a cell.
>
>
> I think he means putting:
>
> import my_python_file
>
> in a cell, like any other python code.
>
> And yes, you can do that, and students should, but the fact is that
> Jupyter encourages people to write al their code in the notebook.
>
> -CHB
>
> --
> Christopher Barker, PhD
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/ANBYE6ID5MAQAJXXGFVNT42HUNGYKWGO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VXVRFZ5BHNMJUDLV2R5A2RLBLVJQ5DUF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Barry Scott

> On 1 Aug 2019, at 19:11, Guido van Rossum  > wrote:
> 
> This is an interesting phenomenon. I'm not saying it's good or bad, I'm just 
> observing it (because it surprised me). Here is someone declaring that the 
> docs are less accessible than the code. I personally am disappointed, given 
> the amount of effort that we put in those docs. But maybe this is true. If we 
> can't get people to peruse the docs, should we bother?

Personally I use the docs first, then the code. I do this because I expect to 
get from the docs the API I can depend on.
If I find something useful from read the code that is not documented, I use a 
my own risk.

I have worked with engineers that would not look at the source code if the docs 
are insufficient.

For a product I worked on at a small company we had the "is it worth having 
docs? No one reads them right?"
discussion. The argument that won the day was that reasonable docs reduces 
support costs.
Tech support can point the user at the docs and move on to the next problem.
QA team could say all documented features work at each release.

Barry

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QLYXIDWIYWLZTFAHWPUCRDWUNELC6YYM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension


On 2019-08-02 10:11, Andrew Barnert wrote:

Honestly, I think a lot of the resistance is the implementation
issue, or at least it’s the reason the resistance is hard to
overcome. If someone isn’t sure whether the benefit of having
itertools.consume is worth the cost of implementing and maintaining
it, the fact that the implementation would have to be in C pushes
them hard in the no direction. Especially since consume is at least
as important as sample code as usable code, so you’d still need to
maintain the pure Python “equivalent” in the docs, as with most of
the core itertools functions. (And notice that, unlike a Python
module with optional C accelerator; a C module with Python equivalent
in the docs can’t easily be unit tested to verify that
equivalence—and many itertools functions would fail, which is why the
docs say “roughly equivalent”.)


This is perhaps getting away from the main topic, but wait --- earlier
in the thread someone said PEP 399 says all modules have to have a pure
Python implementation.  But now you say everything in itertools MUST be
implemented in C?  Why is that?  Why can't we just put the Python
implementations of the recipes as-is directly into itertools?

--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no
path, and leave a trail."
   --author unknown
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MIBXK7NM2C7MYQBXH7TZM7KREU2VXZZJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Ricky Teachey

>
> > I think he means putting:
> >
> > import my_python_file
> >
> > in a cell, like any other python code.
>

Yes, that is all I meant.

My super powered text editor experience is limited to Notepad++. Perhaps I
have a lot to learn about what makes a good text editor for code. And I'm
always willing to learn.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/25ORPJZ26SA22TBU7EYRR64T7HEX3RAU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

On Sat, Aug 3, 2019 at 4:39 AM Christopher Barker  wrote:
>
> Getting really OT now, but quickly:

Off-list because it really is.

> On Fri, Aug 2, 2019 at 11:28 AM Chris Angelico  wrote:
>>
>> On Sat, Aug 3, 2019 at 4:19 AM Ricky Teachey  wrote:
>> > Remember that Jupyter has a pretty nice text editor
>
>
> Actually, I think it's pretty darn crappy -- at least compared to any 
> "proper" coding editor...
>
>>
>> Although I didn't know you could import a .py file into a cell.
>
>
> I think he means putting:
>
> import my_python_file
>
> in a cell, like any other python code.
>

Ahh. I thought that there was another cell type that was a reference
to a .py file. You can have a Python cell, a Markdown cell, etc, etc,
and I thought maybe it had a "file reference cell". Which would be a
cool feature.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VOBGSK5RRI6SEKSXV4MERBXQTUPPAJGQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Christopher Barker

Getting really OT now, but quickly:

On Fri, Aug 2, 2019 at 11:28 AM Chris Angelico  wrote:

> On Sat, Aug 3, 2019 at 4:19 AM Ricky Teachey  wrote:
> > Remember that Jupyter has a pretty nice text editor

Actually, I think it's pretty darn crappy -- at least compared to any
"proper" coding editor...

> Although I didn't know you could import a .py file into a cell.

I think he means putting:

import my_python_file

in a cell, like any other python code.

And yes, you can do that, and students should, but the fact is that Jupyter
encourages people to write al their code in the notebook.

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ANBYE6ID5MAQAJXXGFVNT42HUNGYKWGO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Christopher Barker

This has gotten a bit OT, but I’ll roll with it.


But what about `pip install more-itertools`? Hopefully you become
>> comfortable with that a lot faster than 3 years in.
>
>
more-itertools Is kind of a special case (or at least different case), as
it’s a collection of handy general purpose utilities, rather than a package
designed to address particular problems, like , say requests or pytest
(probably the first two packages I suggest newbies install)

In fact, itertools itself is a bit odd that way — it’s not clear what types
of problems it might address:

You want to look In itertools If you need to iterate through something in a
non-trivial, but probably common enough that others need to do it too way.

Honestly, I often forget to look there when I should.

Which brings us back to the OP's question:

What is a good way to loop through and iterable and apply an operation to
it when you don't want to create a new iterable?

I doubt anyone is going to find consume() in itertools (even if it was
built in) and know it use it to solve this use case.

-CHB

>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RHWZ6RYOUBGGOADY5GD7AR5ERKE4FOLH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

On 2019-08-02 06:37, Rhodri James wrote:

On 02/08/2019 06:26, Brendan Barnwell wrote:

It is massively more discoverable, for one simple reason:
autocomplete.

In teaching people to program, I often use Jupyter notebook, which
has great autocomplete functionality that can also bring up the
documentation on any function. You can type itertools.[TAB] and get a
list, and then you can scroll down the list looking for a likely
function, and when you get to it you can hit Shift-Tab and see the
documentation. Certainly other IDEs have similar functionality.

This is a colossal win over having to go the documentation and look
through the text for a recipe that is not "addressable" in any way. You
can't even link to it, for heaven's sake! The function docs in all the
modules have permalinks but the recipes are just unstructured text.

I'd have to challenge that "colossal win". I am very uncomfortable with
IDEs that try to do my thinking for me, and I start turning things off
on those occasions when I am forced to use them. It would even occur to
me to try autocompletion. Reading the documentation is so much easier,
and far more likely to point me at what the right answer actually is,
rather than just what I think it might be.

Don't get me wrong, I have my own issues with "smart" IDEs. My go-to
tool for my own work isn't even Jupyter but this thing called DreamPie
(http://www.dreampie.org/), which is old and not really maintained and
requires me to keep Python 2.7 and specific libraries installed just to
run it, but I do it because I really like the very simple level of
interpreter-wrapping interface it provides (which does, however, include
autocomplete :-).

But the question was "does having the recipes as functions make them
more discoverable than having them only as textual recipes in the docs".
The answer is yes. It doesn't matter whether you or I or anyone else
has a particular preference for or against autocomplete. The fact is
that autocomplete exists in widely-used tools and it makes modules and
their contents strictly more discoverable (because they remain
discoverable in every way they currently are, plus autocomplete). If
we're concerned with discoverability it surely makes sense to take that
into account.

--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."

--author unknown
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/TJGRGML3NAU6CALHXWKD7P4JVP5O5XQV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Christopher Barker

On Fri, Aug 2, 2019 at 10:54 AM Chris Angelico  wrote:

> Also a bit old-school (it took me many years to learn the value of
> syntax highlighting), and an educator, and I've seen students start
> out with Jupyter. As an alternative to the vanilla REPL, I think it's
> awesome if a little expensive on low-end machines; but as an
> alternative to a text editor, it's an attractive nuisance.

I agree here, and don't recommend it to newbies -- a bit less for your
reasons than that it encourages really horrible software development
practices -- cutting and pasting utility functions from one notebook to a
new one, and essentially impossible to unit test..

But I do use, and recommend the iPython repl, and completion is really
handy there, too :-)

However, I"m not sure "you could find it with completion" is really the
reason to put something in a module rather than as a recipe.

Implementation aside, I think the criteria should be something like:

If it's generally useful and not totally trivial (i.e. one line of code),
then put it in.

If it's a generally useful *pattern*, but individual use cases are likely
to need to specialize it a bit, then it should be a recipe.

As for "consume" -- I think it very much meets the requirement of
non-trivial and generally useful.

The other issue here, in the context of the OP's proposal, is that it's
less than obvious that that's what a user would want when they want to
operate on all the items in a iterable without creating a new iterable. To
Guido's point, the way to do this now is:

for i in an_iterable: act_on(i)

Is simple, obvious and compact, though not "functional" or "using the
comprehension syntax". Indeed, I proposed a couple years ago that some sort
of "make nothing comprehension" would be good, and the idea was rejected,
and I was pointed to that simple for loop as "the one obvious way to do
it". At that time no one pointed me to consume, or anything like it, but I
still think that:

consume(act_on(i) for i in an_iterable)

wouldn't be what I recommend, even if consume was built in to itertools.

while yes, performant and using comprehension syntax is nice, it's still
uglier, less obvious, and less discoverable than the simple for loop.

Back to consume() as a built in to itertools -- looking at the recipe, it's
good to have that recipe, as it takes advantage of a hidden performance
trick in deque -- hardly anyone is going to come up with that on their own!
But frankly, given that itertools is written in C anyway, it seems a high
performance written-in-C implementation would be a fine idea. It just seem
pretty basic to be -- something that should be a building block, rather
than a wrapper around what looks like a higher level class.

Not that I'm offering to write the code ... But if "someone would need to
write the code" is the only stumbling block, maybe I would (or I'd bet
someone would step up).

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GFZREZRX4QNHXW7QI6JID76ZHIWV7UHD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Dan Sommers

On 8/2/19 1:18 PM, David Mertz wrote:

> I'm definitely on the old side of the distribution of programmers ...

Throw me into that bucket, too.  I use autocomplete to save typing
rather than to discover new functionality.

Autocompletion is great, if you know where to start.  In the case that
started this thread, there wasn't a place to start.  When I'm looking
for an alternative to an if statement or a list comprehension, how would
I even guess to start with itertools, let alone more-itertools?

> ... that kind of reminder of e.g. "what's in itertools again?" is very
> helpful to me, both when I wrote programs and when I teach them.

I agree, but that's assuming that you "know" what's there and just have
to be reminded.  IMO, it helps less with discovering new functions, and
even less than that when it comes to discovering "new" python modules.

Dan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IZG6Y4UWMHCF2L67SBZWRWNN4UAHWPBW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

On Sat, Aug 3, 2019 at 4:19 AM Ricky Teachey  wrote:
>>
>> as an
>> alternative to a text editor, it's an attractive nuisance. Yes, you
>> can try things out and see the results instantly, AND you can save it,
>> edit, rerun, etc; the cost is that debugging becomes a nightmare.
>
>
> Remember that Jupyter has a pretty nice text editor (with syntax 
> highlighting! but no autocomplete or discovery... yet), and there's nothing 
> stopping you from teaching a student how to write a .py file in the Jupyter 
> interface and then import it in a cell. And then showing them how they can do 
> the same thing with ANY old text editor.
>

Of course. But I'm not the primary instructor for most of them - I'm
just the TA that they come to when they have questions. So most of the
time, they haven't been using any-old-text-editor.

Although I didn't know you could import a .py file into a cell. Will
have to look into that; maybe that would help them hybridize.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CYEWWP7YDMNTXZL5EVN6HVJJSZRLPUUK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Ricky Teachey

>
> as an
> alternative to a text editor, it's an attractive nuisance. Yes, you
> can try things out and see the results instantly, AND you can save it,
> edit, rerun, etc; the cost is that debugging becomes a nightmare.
>

Remember that Jupyter has a pretty nice text editor (with syntax
highlighting! but no autocomplete or discovery... yet), and there's nothing
stopping you from teaching a student how to write a .py file in the Jupyter
interface and then import it in a cell. And then showing them how they can
do the same thing with ANY old text editor.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XTIQSHJNCNFGM3UEIFWKTEBIMFH45PLY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

On Sat, Aug 3, 2019 at 12:48 AM Ricky Teachey  wrote:
>
> Notebooks in particular-- more than IDEs, I think-- are changing the way 
> people learn. if I were teaching someone new today, I'd have them use Jupyter 
> right away, probably not the repl.
>
> But I still use the docs a lot too.

Also a bit old-school (it took me many years to learn the value of
syntax highlighting), and an educator, and I've seen students start
out with Jupyter. As an alternative to the vanilla REPL, I think it's
awesome if a little expensive on low-end machines; but as an
alternative to a text editor, it's an attractive nuisance. Yes, you
can try things out and see the results instantly, AND you can save it,
edit, rerun, etc; the cost is that debugging becomes a nightmare. But
for discoverability, incl tab completion? It's great, and I probably
should start using it more.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NMOOSIAZ2TWYWOY6UC3344I6RJPJMN5U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread David Mertz

I'm definitely on the old side of the distribution of programmers, and I
strongly appreciate tab expansion in tools like Jupyter and vim. I never
used a full "IDE", whatever the boundary line is. But exactly that kind of
reminder of e.g. "what's in itertools again?" is very helpful to me, both
when I wrote programs and when I teach them.

... But Raymond will always remain a month and a half older than me :-).

On Fri, Aug 2, 2019, 10:25 AM Guido van Rossum  wrote:

> On Fri, Aug 2, 2019 at 6:38 AM Rhodri James  wrote:
>
>> On 02/08/2019 06:26, Brendan Barnwell wrote:
>> >  It is massively more discoverable, for one simple reason:
>> > autocomplete.
>> >
>> >  In teaching people to program, I often use Jupyter notebook, which
>> > has great autocomplete functionality that can also bring up the
>> > documentation on any function.  You can type itertools.[TAB] and get a
>> > list, and then you can scroll down the list looking for a likely
>> > function, and when you get to it you can hit Shift-Tab and see the
>> > documentation.  Certainly other IDEs have similar functionality.
>> >
>> >  This is a colossal win over having to go the documentation and
>> look
>> > through the text for a recipe that is not "addressable" in any way.
>> You
>> > can't even link to it, for heaven's sake!  The function docs in all the
>> > modules have permalinks but the recipes are just unstructured text.
>>
>> I'd have to challenge that "colossal win".  I am very uncomfortable with
>> IDEs that try to do my thinking for me, and I start turning things off
>> on those occasions when I am forced to use them.  It would even occur to
>> me to try autocompletion.  Reading the documentation is so much easier,
>> and far more likely to point me at what the right answer actually is,
>> rather than just what I think it might be.
>>
>
> There seems to be a clash of generations here, or perhaps a clash of
> different educational paths. I'm in the same boat as you, but Python's
> recent success is definitely driven by things like IPython and Jupyter
> Notebooks which are optimized for exactly the approach to learning that
> Brendan describes. (And make no mistake about it, it is a form of
> learning!) I wonder what Raymond thinks (he's the maintainer of itertools
> and also an educator).
>
> PS. Raymond, if you're not reading python-ideas, Brandon's message is
> here, and it's well-written:
>
> https://mail.python.org/archives/list/python-ideas@python.org/message/URV4E3M6MPP7QZWITYYJZ66ZY3HSSTXH/
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him/his **(why is my pronoun here?)*
> 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/B5FUOWFXAA3I2P4TFIAL26DH7LU2OWQZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KSL6FK2QQTVDQH2TSUZYILDOSTREIFOZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

On Aug 1, 2019, at 22:26, Brendan Barnwell  wrote:
> 
>> On 2019-08-01 12:31, Andrew Barnert via Python-ideas wrote:
>>> On Aug 1, 2019, at 10:48, Eli Berkowitz  wrote:
>>> >
>>> >In terms of an argument for why it should be included, for most Python 
>>> >users the itertools recipes remain unseen.
>> Sure. But do you also know all of the functions in the module? Would you 
>> notice or a new one got added? In practical terms, how much more 
>> discoverable is groupby than grouper?
> 
>It is massively more discoverable, for one simple reason: autocomplete.

I already mentioned, in that same post you’re replying to, that I sometimes 
find functions by autocomplete, especially when I can guess at the name. But I 
rarely use autocomplete to view the entire contents of a module.

Maybe using Jupyter in a notebook vs. iPython in a terminal window is different 
enough that I would autocomplete `itertools.` more often. Or maybe it’s just 
because I’m old, as others have pointed out about themselves. At any rate, if a 
lot of other people do autocomplete `itertools.` rather than just using 
autocomplete to confirm a guess or a vague memory, then it doesn’t matter if 
I’m not one of those people, so, point taken.

>This is a colossal win over having to go the documentation and look 
> through the text for a recipe that is not "addressable" in any way.  You 
> can't even link to it, for heaven's sake!  The function docs in all the 
> modules have permalinks but the recipes are just unstructured text.

That’s a separate issue. There’s nothing inherent in the docs that disallows a 
link to each recipe, it’s just not the way they’re written. I suspect if 
someone filed a bug to fix that and submitted a patch, Raymond Hettinger 
wouldn’t object (or others might override him if he did).

>I don't fully understand the resistance to adding these functions to 
> itertools itself.

Honestly, I think a lot of the resistance is the implementation issue, or at 
least it’s the reason the resistance is hard to overcome. If someone isn’t sure 
whether the benefit of having itertools.consume is worth the cost of 
implementing and maintaining it, the fact that the implementation would have to 
be in C pushes them hard in the no direction. Especially since consume is at 
least as important as sample code as usable code, so you’d still need to 
maintain the pure Python “equivalent” in the docs, as with most of the core 
itertools functions. (And notice that, unlike a Python module with optional C 
accelerator; a C module with Python equivalent in the docs can’t easily be unit 
tested to verify that equivalence—and many itertools functions would fail, 
which is why the docs say “roughly equivalent”.)

But if someone did the work to rewrite itertools as a 
Python-plus-optional-accelerator module (as it would have been if it had been 
submitted after PEP 399(, or at least as a hybrid Python-re-exporting-from-C, 
then adding consume or grouper or a set of recipes or even all of them only 
faces the same hurdle as adding a new function to any already-in-Python module, 
which is a lower hurdle.

But nobody who wants the recipes ever volunteers to tackle that rewrite, prove 
that it doesn’t break any tests or hurt any benchmarks, etc. And nobody else 
has any motivation to do the rewrite.

>From some other posts in the thread I get the impression some people think 
> there is (or should be) some sort of multi-tiered system along the lines of:
> 
> 1) in the stdlib
> 2) in a "recipe" in the stdlib but you have to copy and paste it
> 3) in an "officially sanctioned" third-party lib which is a "category killer" 
> (like requests)
> 4) in a "somewhat less officially sanctioned" third-party lib which isn't a 
> "category killer" (like toolz?)
> 5) in an ordinary third-party lib of which the documentation makes no mention

Well, there already _is_ such a hierarchy, but it’s missing the (4) case. 
That’s why more-itertools is in the less discoverable category 5 today. Whoever 
proposed that (Chris?) was trying to make things more accessible, not less.

>Some of those may be good ideas, but I don't see the use of the 
> distinction between tiers 1 and 2.

It’s partly historical, but not entirely. There’s plenty of recipes in the docs 
that are aren’t like itertools.consume. Look at the HOWTOs full of recipes for 
the more complicated modules; they’d become a lot more complicated if you had 
to make them configurable after import instead of tweakable after copy-paste. 
And thing about things like the threaded URL downloader—that might be useful, 
but not in the concurrent.futures library. So eliminating category 2 seems like 
a bad idea. 

And it also seems unnecessary for your point. You don’t need to eliminate case 
2, or even move the bar between cases 1 and 2, you just need to move the 
itertools recipes, which are already close to the bar, over it.
___
Python-ideas mailing list --

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Rhodri James


On 02/08/2019 15:22, Guido van Rossum wrote:

There seems to be a clash of generations here, or perhaps a clash of
different educational paths.


Very likely.  I did my computer science learning on an IBM mainframe, 
with a local front-end over MVS.  A full-screen editor was introduced 
during the year :-)  I think as a result I don't trust tools that I 
can't take apart and put back together myself; if I don't know roughly 
how something works, I tend not to use it at all.  This isn't just 
prejudice, I've had far too many occasions when I've had to undo 
something clever a "helpful" tool has done for me.


Cue the Yorkshiremen sketch...

--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5RYVAJY5LLULW7GJI2FHUHMB2EXTELZT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Stefan Krah

On Fri, Aug 02, 2019 at 10:48:26AM -0400, Ricky Teachey wrote:
> I agree it is more a clash of learning paths/training. I started out-- with
> ZERO knowledge-- in 2014 just before Jupyter started to be popular, and the
> more I have used it (as well as VSCode and Pycharm), the more I have found
> myself thinking "OH MAN-- if I had had THIS when I was learning, I would
> have learned so much faster with these code/feature discovery tools".
> 
> Notebooks in particular-- more than IDEs, I think-- are changing the way
> people learn. if I were teaching someone new today, I'd have them use
> Jupyter right away, probably not the repl.

I think Smalltalk and Lisp had similar environments.  Also the tradeoffs
of "living in the environment" vs. "knowing the code base by reading and
maintaining a mental map of files and documentation" are well known.

The latter is probably required for larger code bases.


Stefan Krah


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7ITNDOUZD4677325GIWOMEJULIKVHZX5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Ricky Teachey

>
> >  It is massively more discoverable, for one simple reason:
>> > autocomplete.
>>
>> I am very uncomfortable with
>> IDEs that try to do my thinking for me, and I start turning things off
>> on those occasions when I am forced to use them.  It would even occur to
>> me to try autocompletion.
>>
>
> There seems to be a clash of generations here, or perhaps a clash of
> different educational paths.
>

I agree it is more a clash of learning paths/training. I started out-- with
ZERO knowledge-- in 2014 just before Jupyter started to be popular, and the
more I have used it (as well as VSCode and Pycharm), the more I have found
myself thinking "OH MAN-- if I had had THIS when I was learning, I would
have learned so much faster with these code/feature discovery tools".

Notebooks in particular-- more than IDEs, I think-- are changing the way
people learn. if I were teaching someone new today, I'd have them use
Jupyter right away, probably not the repl.

But I still use the docs a lot too.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DIYQV3DNEQ2W7QQBQATAKESTNA7AOYNC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Rhodri James


On 02/08/2019 06:26, Brendan Barnwell wrote:
 It is massively more discoverable, for one simple reason: 
autocomplete.


 In teaching people to program, I often use Jupyter notebook, which 
has great autocomplete functionality that can also bring up the 
documentation on any function.  You can type itertools.[TAB] and get a 
list, and then you can scroll down the list looking for a likely 
function, and when you get to it you can hit Shift-Tab and see the 
documentation.  Certainly other IDEs have similar functionality.


 This is a colossal win over having to go the documentation and look 
through the text for a recipe that is not "addressable" in any way.  You 
can't even link to it, for heaven's sake!  The function docs in all the 
modules have permalinks but the recipes are just unstructured text.


I'd have to challenge that "colossal win".  I am very uncomfortable with 
IDEs that try to do my thinking for me, and I start turning things off 
on those occasions when I am forced to use them.  It would even occur to 
me to try autocompletion.  Reading the documentation is so much easier, 
and far more likely to point me at what the right answer actually is, 
rather than just what I think it might be.


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZKV4G3QLJSNRZUZLWZM2ZBP5VMYFYNBT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: For-expression/throwaway comprehension