<p dir="ltr">On Apr 19, 2016 5:48 AM, "Paul Moore" <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
> > You say "should"? Do you mean that it is likely, or do you mean that it is<br>
> > what would happen in an ideal world? My college had CS students SSH into the<br>
> > department's Linux server to compile and run their code, and many teachers<br>
> > don't believe that students should start with fancy IDE featues like, er,<br>
> > syntax highlighting.<br>
><br>
> I mean that that is what I hear people on lists like this saying as "a<br>
> reasonable beginner environment". It means that the people I've<br>
> introduced to Python (on Windows) have tended to end up using IDLE<br>
> (either from the start menu or via "edit with IDLE" from the right<br>
> click menu on a script).</p>
<p dir="ltr">But are they perhaps tending to use IDLE because you were the one introducing them to it? Whether it is a recommended environment by the consensus of mailing lists is hardly indicative that IDLE is what people will start on.<br></p>
<p dir="ltr">> My experience (in business, environments) is that people expect an IDE<br>
> when introduced to a new programming language, and IDLE, like it or<br>
> not, is what is available out of the box with Python.</p>
<p dir="ltr">They expect it => they know what an IDE is. Programmers are already half-intermediate, especially programmers who use IDEs.</p>
<p dir="ltr">> > You (and most regulars on this list) can adjust your shell to the way you<br>
> > like it, or use a more sophisticated shell, like IPython or bpython. On the<br>
> > other hand, changing shells and adding display hooks to site.py is not an<br>
> > option for those who don't know it's an option.<br>
><br>
> As a "scripting expert" and consultant, I typically get asked to knock<br>
> up scripts on a variety of environments. I do not normally have what<br>
> I'd describe as "my shell", just a series of basic "out of the box"<br>
> prompts people expect me to work at. So no, the luxury of configuring<br>
> the default experience is *not* something I typically have.</p>
<p dir="ltr">I suggested a command-line switch.<br></p>
<p dir="ltr">> >> I view the REPL as more<br>
> >> important for intermediate or advanced users who want to quickly test<br>
> >> out an idea (at least, that's *my* usage of the REPL).<br>
> ><br>
> > But that doesn't answer my question: would the proposed change hurt your<br>
> > workflow?<br>
><br>
> Yes. If I get a stack trace, I want it all. And if I print something<br>
> out, I want to see it by default. The REPL for me is an investigative<br>
> environment for seeing exactly what's going on.</p>
<p dir="ltr">And why is it an insufficient option for you to type, for example, "_exfull()" to get the full trace?<br></p>
<p dir="ltr">> (Also, having the REPL behave differently depending on what version of<br>
> Python I have would be a problem - backward compatibility applies here<br>
> as much as anywhere else).</p>
<p dir="ltr">This is a concern, but not one that is enough, by itself, to justify the status quo. I disagree that it applies *anywhere near as much* here, since I don't see how it could break existing code. It will add a little adjustment and a little more work sometimes, but it doesn't require, say, refactoring a module, or every site page you ever downloaded.</p>