Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #79747 > unrolled thread

Classes and the command line

Back to article view | Back to comp.lang.python

Contents

  Classes and the command line Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-26 22:27 -0400
    Re: Classes and the command line Rustom Mody <rustompmody@gmail.com> - 2014-10-26 20:05 -0700
      Re: Classes and the command line Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-26 23:28 -0400
        Re: Classes and the command line Terry Reedy <tjreedy@udel.edu> - 2014-10-28 00:14 -0400
    Re: Classes and the command line Ben Finney <ben+python@benfinney.id.au> - 2014-10-27 14:06 +1100
      Re: Classes and the command line Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-26 23:32 -0400
        Re: Classes and the command line alister <alister.nospam.ware@ntlworld.com> - 2014-10-27 11:17 +0000
          Re: Classes and the command line Chris Angelico <rosuav@gmail.com> - 2014-10-27 22:33 +1100
        Re: Classes and the command line Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-27 09:34 -0400
    Re: Classes and the command line Chris Angelico <rosuav@gmail.com> - 2014-10-27 14:10 +1100
      Re: Classes and the command line Rustom Mody <rustompmody@gmail.com> - 2014-10-26 20:18 -0700
        Re: Classes and the command line Chris Angelico <rosuav@gmail.com> - 2014-10-27 14:24 +1100
        Re: Classes and the command line Rustom Mody <rustompmody@gmail.com> - 2014-10-26 20:30 -0700
        Re: Classes and the command line Terry Reedy <tjreedy@udel.edu> - 2014-10-28 00:08 -0400
        Re: Classes and the command line Chris Angelico <rosuav@gmail.com> - 2014-10-28 15:57 +1100
      Re: Classes and the command line Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-26 23:33 -0400

#79747 — Classes and the command line

I am trying to learn classes.
I am currently using Python 2.7 at the command line.
If you try to type commands at the command line and make the slightest
mistake you have to start over.
I was trying to copy and paste these instructions into the command
prompt. 

http://en.wikibooks.org/wiki/Python_Programming/Classes
>>> class Foo:
...     def setx(self, x):
...         self.x = x
...     def bar(self):
...         print self.x

There is really no way to do that without pasting line by line is
there and adding deleting spaces?  And if you use spaces and tabs,
they are not the same.

http://imgur.com/a/XTkAm

[toc] | [next] | [standalone]

#79752

On Monday, October 27, 2014 8:00:04 AM UTC+5:30, Seymore4Head wrote:
> I am trying to learn classes.
> I am currently using Python 2.7 at the command line.

Why not idle?
And if in general you are at python 3, why 2.7 here?
There are enough factor to learn ( and get confused)!
Please dont add new ones gratuitously!

> If you try to type commands at the command line and make the slightest
> mistake you have to start over.
> I was trying to copy and paste these instructions into the command
> prompt. 
> 
> http://en.wikibooks.org/wiki/Python_Programming/Classes
> >>> class Foo:
> ...     def setx(self, x):
> ...         self.x = x
> ...     def bar(self):
> ...         print self.x
> 
> There is really no way to do that without pasting line by line is
> there and adding deleting spaces?  And if you use spaces and tabs,
> they are not the same.
> 
> http://imgur.com/a/XTkAm

Let me repeat and elaborate what I have already told you --
- you should write mostly expressions at the interpreter prompt
- you should write definitions in the file

Rough distinctions:

1. Things like 1+2, lst.append(3) etc are expressions
2. Things like assignment, if, while are statements
3. class and def statements are special; and called definitions

Notes
a. theres an inclusion 1 'sits inside' 2 'sits inside' 3
b. Its easiest if you try 1 in the interpreter; 3 in the python file
c. 2 is a bit clumsy. Short ones can be tried at the interpreter
   Longer than 3 (max 4) lines should go into files.
   May require a bit of thought how to package a statement into  
   a definition to try out
d. 2 is clumsy in files for a different reason; you will need
   to write prints judiciously
e. Since def itself goes into class, if youve not yet worked out
   a comfortable 'tryin-out' model, stay with defs for now

In short:
For a while people here have been advising you "Use the Interpreter"
Now I will add slightly to that:
Use the interpreter in idle, along with a python file

[toc] | [prev] | [next] | [standalone]

#79760

Your message showed up as unavailable on my server I have to cut and
paste Google Groups to reply.  (I am going to change news servers
probably tomorrow to try to fix that)  So the quoting is going to be
bad.

----
Why not idle?
And if in general you are at python 3, why 2.7 here?
There are enough factor to learn ( and get confused)!
Please don't add new ones gratuitously! 
-------

I am taking two courses in Python 2 so I think I am going to forget
using Python 3 until I finish the courses.  One of the course
instructors suggests we try the command like way.

Your other explanations on the distinctions are helpful, but for now I
am going with Python 2.  Final answer.  :)  (A few more weeks)  They
are teaching Python 2.  I have to use Python 2 to learn it.

Thanks

I am going to be flexible on IDLE in the near future, but I wanted to
try it the old fashion way.  I already know using IDLE is better, but
I am not sure using IDLE will invoke Python 2 and I am not sure how to
change that at the moment.

[toc] | [prev] | [next] | [standalone]

#79821

On 10/26/2014 11:28 PM, Seymore4Head wrote:

> I am going to be flexible on IDLE in the near future, but I wanted to
> try it the old fashion way.  I already know using IDLE is better, but
> I am not sure using IDLE will invoke Python 2 and I am not sure how to
> change that at the moment.

Currently, Idle executes user code with the same interpreter it is 
running on.

Now that user code is executed in a subprocess, there is the possibility 
of using a different python in the subprocess.  But this is for the future.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#79753

Seymore4Head <Seymore4Head@Hotmail.invalid> writes:

> I am trying to learn classes.
> I am currently using Python 2.7 at the command line.

(I think you mean “the interactive Python interpreter”, or just “the
Python shell”.)

Since you are learning Python, I will strongly recommend you ignore
Python 2 unless it becomes unavoidable.

Instead, learn Python 3 primarily; it is much better because it omits a
bunch of legacy behaviour you don't need.

> If you try to type commands at the [interactive shell] and make the
> slightest mistake you have to start over.

Right. There is line-by-line history, and editing enabled with the
“readline” plug-in. (This is an advantage of using a programmer-friendly
operating system, which MS Windows sadly is not.)

> I was trying to copy and paste these instructions into the
> [interactive Python shell].
>
> http://en.wikibooks.org/wiki/Python_Programming/Classes
> >>> class Foo:
> ...     def setx(self, x):
> ...         self.x = x
> ...     def bar(self):
> ...         print self.x
>
> There is really no way to do that without pasting line by line is
> there and adding deleting spaces?  And if you use spaces and tabs,
> they are not the same.

Right on all counts.

The interactive Python shell is good for very quickly experimenting and
demonstrating how Python actually behaves, statement by statement. But
as you point out, it is not a good choice for anything more complex. It
is a good learning and debugging tool.

When you start to write larger units of code, like a class or a
function, you can trade immediacy for flexibility: write your code into
a text editor, save it to a file ‘foo.py’, then run that code at a
separate OS command prompt by invoking ‘python foo.py’ in the terminal.

That way, you can continue to adjust and tweak the code as you learn how
your changes affect the code. You do need to keep invoking the actions
separately – edit the file, save the file, run the file with Python –
but this is what's needed when you want to run a program more than once
anyway, so it's a good step to take.

Find a good, *general-purpose* programmer's editor. Preferably licensed
under free software terms, with a strong community supporting it, and
available on all major platforms for when you switch to a decent
programmer-friendly operating system.

-- 
 \        “When you go in for a job interview, I think a good thing to |
  `\                  ask is if they ever press charges.” —Jack Handey |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#79761

On Mon, 27 Oct 2014 14:06:11 +1100, Ben Finney
<ben+python@benfinney.id.au> wrote:

>Seymore4Head <Seymore4Head@Hotmail.invalid> writes:
>
>> I am trying to learn classes.
>> I am currently using Python 2.7 at the command line.
>
>(I think you mean “the interactive Python interpreter”, or just “the
>Python shell”.)
>
>Since you are learning Python, I will strongly recommend you ignore
>Python 2 unless it becomes unavoidable.
>
At the moment, it is unavoidable.  The instructors are teaching Python
2 so I have to learn Python 2, for now.

>Instead, learn Python 3 primarily; it is much better because it omits a
>bunch of legacy behaviour you don't need.
>
>> If you try to type commands at the [interactive shell] and make the
>> slightest mistake you have to start over.
>
>Right. There is line-by-line history, and editing enabled with the
>“readline” plug-in. (This is an advantage of using a programmer-friendly
>operating system, which MS Windows sadly is not.)
>
>> I was trying to copy and paste these instructions into the
>> [interactive Python shell].
>>
>> http://en.wikibooks.org/wiki/Python_Programming/Classes
>> >>> class Foo:
>> ...     def setx(self, x):
>> ...         self.x = x
>> ...     def bar(self):
>> ...         print self.x
>>
>> There is really no way to do that without pasting line by line is
>> there and adding deleting spaces?  And if you use spaces and tabs,
>> they are not the same.
>
>Right on all counts.
>
>The interactive Python shell is good for very quickly experimenting and
>demonstrating how Python actually behaves, statement by statement. But
>as you point out, it is not a good choice for anything more complex. It
>is a good learning and debugging tool.
>
>When you start to write larger units of code, like a class or a
>function, you can trade immediacy for flexibility: write your code into
>a text editor, save it to a file ‘foo.py’, then run that code at a
>separate OS command prompt by invoking ‘python foo.py’ in the terminal.
>
>That way, you can continue to adjust and tweak the code as you learn how
>your changes affect the code. You do need to keep invoking the actions
>separately – edit the file, save the file, run the file with Python –
>but this is what's needed when you want to run a program more than once
>anyway, so it's a good step to take.
>
>Find a good, *general-purpose* programmer's editor. Preferably licensed
>under free software terms, with a strong community supporting it, and
>available on all major platforms for when you switch to a decent
>programmer-friendly operating system.

I am actually using Notepad some too.

Thanks

[toc] | [prev] | [next] | [standalone]

#79777

On Sun, 26 Oct 2014 23:32:08 -0400, Seymore4Head wrote:

> On Mon, 27 Oct 2014 14:06:11 +1100, Ben Finney
> <ben+python@benfinney.id.au> wrote:
> 
>>Seymore4Head <Seymore4Head@Hotmail.invalid> writes:
>>
>>> I am trying to learn classes.
>>> I am currently using Python 2.7 at the command line.
>>
>>(I think you mean “the interactive Python interpreter”, or just “the
>>Python shell”.)
>>
>>Since you are learning Python, I will strongly recommend you ignore
>>Python 2 unless it becomes unavoidable.
>>
> At the moment, it is unavoidable.  The instructors are teaching Python 2
> so I have to learn Python 2, for now.
> 
>>Instead, learn Python 3 primarily; it is much better because it omits a
>>bunch of legacy behaviour you don't need.
>>
>>> If you try to type commands at the [interactive shell] and make the
>>> slightest mistake you have to start over.
>>
>>Right. There is line-by-line history, and editing enabled with the
>>“readline” plug-in. (This is an advantage of using a programmer-
friendly
>>operating system, which MS Windows sadly is not.)
>>
>>> I was trying to copy and paste these instructions into the
>>> [interactive Python shell].
>>>
>>> http://en.wikibooks.org/wiki/Python_Programming/Classes
>>> >>> class Foo:
>>> ...     def setx(self, x):
>>> ...         self.x = x ...     def bar(self):
>>> ...         print self.x
>>>
>>> There is really no way to do that without pasting line by line is
>>> there and adding deleting spaces?  And if you use spaces and tabs,
>>> they are not the same.
>>
>>Right on all counts.
>>
>>The interactive Python shell is good for very quickly experimenting and
>>demonstrating how Python actually behaves, statement by statement. But
>>as you point out, it is not a good choice for anything more complex. It
>>is a good learning and debugging tool.
>>
>>When you start to write larger units of code, like a class or a
>>function, you can trade immediacy for flexibility: write your code into
>>a text editor, save it to a file ‘foo.py’, then run that code at a
>>separate OS command prompt by invoking ‘python foo.py’ in the 
terminal.
>>
>>That way, you can continue to adjust and tweak the code as you learn how
>>your changes affect the code. You do need to keep invoking the actions
>>separately – edit the file, save the file, run the file with Python –
>>but this is what's needed when you want to run a program more than once
>>anyway, so it's a good step to take.
>>
>>Find a good, *general-purpose* programmer's editor. Preferably licensed
>>under free software terms, with a strong community supporting it, and
>>available on all major platforms for when you switch to a decent
>>programmer-friendly operating system.
> 
> I am actually using Notepad some too.
> 
> Thanks

notepad is not a programmer friendly editor

personally I like Geany as it is nice and basic but still offers a lot of 
programmer friendly features such as syntax highlighting, a small 
terminal window which I use to run the interactive terminal for testing 
quick one-liners & pressing f5 will save & run the current file being 
edited.

www.geany.org

Notepad+ is also often suggested along with many other programmer editors/
Integrated development environments (IDE).

I would advise you keep away from the more complex IDE's for now as you 
do not want to overload your learning requirements.


-- 
Who the mad would destroy, first they make Gods.
		-- Bernard Levin

[toc] | [prev] | [next] | [standalone]

#79779

On Mon, Oct 27, 2014 at 10:17 PM, alister
<alister.nospam.ware@ntlworld.com> wrote:
> Notepad+ is also often suggested along with many other programmer editors/
> Integrated development environments (IDE).

That would be Notepad++, and yes, it's fairly well recommended. It's
based on the same edit component as SciTE, another good editor (and
the one I use).

ChrisA

[toc] | [prev] | [next] | [standalone]

#79783

On Sun, 26 Oct 2014 23:32:08 -0400, Seymore4Head
<Seymore4Head@Hotmail.invalid> wrote:

>On Mon, 27 Oct 2014 14:06:11 +1100, Ben Finney
><ben+python@benfinney.id.au> wrote:
>
>>Seymore4Head <Seymore4Head@Hotmail.invalid> writes:
>>
>>> I am trying to learn classes.
>>> I am currently using Python 2.7 at the command line.
>>
>>(I think you mean “the interactive Python interpreter”, or just “the
>>Python shell”.)
>>
>>Since you are learning Python, I will strongly recommend you ignore
>>Python 2 unless it becomes unavoidable.
>>
>At the moment, it is unavoidable.  The instructors are teaching Python
>2 so I have to learn Python 2, for now.
>
>>Instead, learn Python 3 primarily; it is much better because it omits a
>>bunch of legacy behaviour you don't need.
>>
>>> If you try to type commands at the [interactive shell] and make the
>>> slightest mistake you have to start over.
>>
>>Right. There is line-by-line history, and editing enabled with the
>>“readline” plug-in. (This is an advantage of using a programmer-friendly
>>operating system, which MS Windows sadly is not.)
>>
>>> I was trying to copy and paste these instructions into the
>>> [interactive Python shell].
>>>
>>> http://en.wikibooks.org/wiki/Python_Programming/Classes
>>> >>> class Foo:
>>> ...     def setx(self, x):
>>> ...         self.x = x
>>> ...     def bar(self):
>>> ...         print self.x
>>>
>>> There is really no way to do that without pasting line by line is
>>> there and adding deleting spaces?  And if you use spaces and tabs,
>>> they are not the same.
>>
>>Right on all counts.
>>
>>The interactive Python shell is good for very quickly experimenting and
>>demonstrating how Python actually behaves, statement by statement. But
>>as you point out, it is not a good choice for anything more complex. It
>>is a good learning and debugging tool.
>>
>>When you start to write larger units of code, like a class or a
>>function, you can trade immediacy for flexibility: write your code into
>>a text editor, save it to a file ‘foo.py’, then run that code at a
>>separate OS command prompt by invoking ‘python foo.py’ in the terminal.
>>
>>That way, you can continue to adjust and tweak the code as you learn how
>>your changes affect the code. You do need to keep invoking the actions
>>separately – edit the file, save the file, run the file with Python –
>>but this is what's needed when you want to run a program more than once
>>anyway, so it's a good step to take.
>>
>>Find a good, *general-purpose* programmer's editor. Preferably licensed
>>under free software terms, with a strong community supporting it, and
>>available on all major platforms for when you switch to a decent
>>programmer-friendly operating system.
>
>I am actually using Notepad some too.
>
>Thanks

I meant Notepad ++

[toc] | [prev] | [next] | [standalone]

#79755

On Mon, Oct 27, 2014 at 2:06 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Right. There is line-by-line history, and editing enabled with the
> “readline” plug-in. (This is an advantage of using a programmer-friendly
> operating system, which MS Windows sadly is not.)

You can get block-by-block history by using Idle. I find that fairly
convenient for manipulating class/function definitions.

ChrisA

[toc] | [prev] | [next] | [standalone]

#79757

On Monday, October 27, 2014 8:40:48 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Oct 27, 2014 at 2:06 PM, Ben Finney  wrote:
> > Right. There is line-by-line history, and editing enabled with the
> > "readline" plug-in. (This is an advantage of using a programmer-friendly
> > operating system, which MS Windows sadly is not.)
> 
> You can get block-by-block history by using Idle. I find that fairly
> convenient for manipulating class/function definitions.
> 
> ChrisA

Umm... Nice!
A bit inconsistent in that the '...' does not appear.
But thats good; makes copy|cut-pasting from interpreter to file
a mostly trivial operation.

[toc] | [prev] | [next] | [standalone]

#79758

On Mon, Oct 27, 2014 at 2:18 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Monday, October 27, 2014 8:40:48 AM UTC+5:30, Chris Angelico wrote:
>> On Mon, Oct 27, 2014 at 2:06 PM, Ben Finney  wrote:
>> > Right. There is line-by-line history, and editing enabled with the
>> > "readline" plug-in. (This is an advantage of using a programmer-friendly
>> > operating system, which MS Windows sadly is not.)
>>
>> You can get block-by-block history by using Idle. I find that fairly
>> convenient for manipulating class/function definitions.
>>
>> ChrisA
>
> Umm... Nice!
> A bit inconsistent in that the '...' does not appear.
> But thats good; makes copy|cut-pasting from interpreter to file
> a mostly trivial operation.

It's inconsistent only because the default sys.ps2 is those dots,
which aren't necessary in Idle. You could make it consistent by simply
changing sys.ps2.

ChrisA

[toc] | [prev] | [next] | [standalone]

#79759

On Monday, October 27, 2014 8:48:52 AM UTC+5:30, Rustom Mody wrote:
> On Monday, October 27, 2014 8:40:48 AM UTC+5:30, Chris Angelico wrote:
> > On Mon, Oct 27, 2014 at 2:06 PM, Ben Finney  wrote:
> > > Right. There is line-by-line history, and editing enabled with the
> > > "readline" plug-in. (This is an advantage of using a programmer-friendly
> > > operating system, which MS Windows sadly is not.)
> > 
> > You can get block-by-block history by using Idle. I find that fairly
> > convenient for manipulating class/function definitions.
> > 
> > ChrisA
> 
> Umm... Nice!
> A bit inconsistent in that the '...' does not appear.
> But thats good; makes copy|cut-pasting from interpreter to file
> a mostly trivial operation.

No not quite so nice...
Does not respect the current indent level :-(
[which an emacs 'rectangle' copy-paste will]

[toc] | [prev] | [next] | [standalone]

#79820

On 10/26/2014 11:24 PM, Chris Angelico wrote:
> On Mon, Oct 27, 2014 at 2:18 PM, Rustom Mody <rustompmody@gmail.com> wrote:
>> On Monday, October 27, 2014 8:40:48 AM UTC+5:30, Chris Angelico wrote:

>>> You can get block-by-block history by using Idle. I find that fairly
>>> convenient for manipulating class/function definitions.
>>>
>>> ChrisA
>>
>> Umm... Nice!
>> A bit inconsistent in that the '...' does not appear.
>> But thats good; makes copy|cut-pasting from interpreter to file
>> a mostly trivial operation.

One of the differences between console interpreter and Idle Shell is 
that the former is line oriented whereas Shell is statement oriented. 
In the console interpreter, you cannot edit a line after it is entered. 
  In Shell, you can edit any line until you enter an entire statment. 
Similarly, c. i. history recalls a line at a time.  Recalling an 
multiline statment has to be done a line at a time, in order.  Shell 
history recalls an entire statement, even if multiple lines (this is 
what Chris means by 'blocks').  Explaining this difference as the reason 
for no ... is on my todo list.

> It's inconsistent only because the default sys.ps2 is those dots,
> which aren't necessary in Idle. You could make it consistent by simply
> changing sys.ps2.

Nope.  User code is executed in the user process.  Its only effect on 
the Idle process is to write to stdout or stderr for display.  There is 
  tracker issue about letting users change sys.ps1 *in the Idle 
process*, but it would have to be through the menu or config dialog.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#79823

On Tue, Oct 28, 2014 at 3:08 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>> It's inconsistent only because the default sys.ps2 is those dots,
>> which aren't necessary in Idle. You could make it consistent by simply
>> changing sys.ps2.
>
>
> Nope.  User code is executed in the user process.  Its only effect on the
> Idle process is to write to stdout or stderr for display.  There is  tracker
> issue about letting users change sys.ps1 *in the Idle process*, but it would
> have to be through the menu or config dialog.

I knew that, honest I did... umm, let's just pretend I was talking
about changing sys.ps2 in the console interpreter. Yeah. Because I
totally knew that changing it in Idle wouldn't work. Plus, I tested it
before posting, like everyone should. Honest!

Changing it in the console interpreter does work, though.

Python 3.5.0a0 (default:301b9a58021c, Oct  2 2014, 09:20:24)
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.ps2="    "
>>> def x():
        pass

>>>

And if you want consistency, that's a good way to get it.

ChrisA

[toc] | [prev] | [next] | [standalone]

#79762

On Mon, 27 Oct 2014 14:10:01 +1100, Chris Angelico <rosuav@gmail.com>
wrote:

>On Mon, Oct 27, 2014 at 2:06 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
>> Right. There is line-by-line history, and editing enabled with the
>> “readline” plug-in. (This is an advantage of using a programmer-friendly
>> operating system, which MS Windows sadly is not.)
>
>You can get block-by-block history by using Idle. I find that fairly
>convenient for manipulating class/function definitions.
>
>ChrisA

Thanks
BTW I am using XP some and Win7 some too.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web