Re: [Tutor] Trouble importing Paramiko

[Ufuk Eskici]

any help is appreciated, thanks...


2012/12/28 Ufuk Eskici 

> Hello,
> My Python version is 2.7.3 and it is installed in "C:\Python27 (on the
> web, it says Paramiko-1.7.4 is supported with Python 2.7)
> @Dave: Previous output was from IDLE which should be same with CLI.
>
> I'm getting this output now from Windows Command Line:
>
> 
> C:\Python27>python ufo.py
> Traceback (most recent call last):
>   File "ufo.py", line 1, in 
> import paramiko
> ImportError: No module named paramiko
>
> C:\Python27>
> 
>
> This is the output after addning .sys path:
> 
> C:\Python27>python ufo.py
> import path is  ['C:\\Python27', 'C:\\Windows\\system32\\python27.zip',
> 'C:\\Pyt
> hon27\\DLLs', 'C:\\Python27\\lib', 'C:\\Python27\\lib\\plat-win',
> 'C:\\Python27\
> \lib\\lib-tk', 'C:\\Python27', 'C:\\Python27\\lib\\site-packages']
> Traceback (most recent call last):
>   File "ufo.py", line 4, in 
> import paramiko
> ImportError: No module named paramiko
> 
>
>
> 2012/12/27 Francois Dion 
>
>> On Thu, Dec 27, 2012 at 8:48 AM, Ufuk Eskici 
>> wrote:
>> > I got this output with lots of errors:
>> >   File "build\bdist.win32\egg\paramiko\auth_handler.py", line 311
>> > except SSHException, e:
>> >^
>> > SyntaxError: invalid syntax
>>
>> Use Python 2.x, Python 3 is in the works, kindoff:
>>
>> https://github.com/paramiko/paramiko/issues/16
>> https://github.com/paramiko/paramiko/issues/123
>>
>> François
>>
>> --
>> www.pyptug.org  -  raspberry-python.blogspot.com
>>
>
>
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Trouble importing Paramiko

[Steven D'Aprano]

On 02/01/13 20:22, Ufuk Eskici wrote:

any help is appreciated, thanks...



Have you successfully installed it yet? Last time you tried to install,
you tried to install the Python 2 version of Paramiko with Python 3,
and got many SyntaxErrors.

Until you actually install Paramiko using Python 2, there is no point
trying to import it.


--
Steven
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Trouble importing Paramiko

[Ufuk Eskici]

Hello Steven,

I've written this before:

"My Python version is 2.7.3 and it is installed in "C:\Python27 (on the
web, it says Paramiko-1.7.4 is supported with Python 2.7)"

so I'm using the correct Python verion (2.7.3). But I dont know why I'm
getting errors during Paramiko installation as I mentioned before.


2013/1/2 Steven D'Aprano 

> On 02/01/13 20:22, Ufuk Eskici wrote:
>
>> any help is appreciated, thanks...
>>
>
>
> Have you successfully installed it yet? Last time you tried to install,
> you tried to install the Python 2 version of Paramiko with Python 3,
> and got many SyntaxErrors.
>
> Until you actually install Paramiko using Python 2, there is no point
> trying to import it.
>
>
>
> --
> Steven
> __**_
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/**mailman/listinfo/tutor
>
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Trouble importing Paramiko

[Steven D'Aprano]

On 02/01/13 20:48, Ufuk Eskici wrote:

Hello Steven,

I've written this before:

"My Python version is 2.7.3 and it is installed in "C:\Python27 (on the
web, it says Paramiko-1.7.4 is supported with Python 2.7)"



How do you know it is installed in C:\Python27?

What is the output of


dir C:\Python27\paramiko*


from the Windows command.com or cmd.exe (?) shell?




so I'm using the correct Python verion (2.7.3). But I dont know why I'm
getting errors during Paramiko installation as I mentioned before.



If you got errors during installation, then Paramiko is NOT installed, or
at best it is installed in a broken state and cannot be used. You must
SUCCESSFULLY install Paramiko with no errors, or at least no important
errors.

If Paramiko was installed successfully, then "import paramiko" would work.
Since it doesn't work, you have to go back and look at the installation.



--
Steven
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Trouble importing Paramiko

[Hugo Arts]

On Wed, Jan 2, 2013 at 10:48 AM, Ufuk Eskici  wrote:

> Hello Steven,
>
> I've written this before:
>
> "My Python version is 2.7.3 and it is installed in "C:\Python27 (on the
> web, it says Paramiko-1.7.4 is supported with Python 2.7)"
>
> so I'm using the correct Python verion (2.7.3). But I dont know why I'm
> getting errors during Paramiko installation as I mentioned before.
>
>
That is very interesting, because when you tried my earlier suggestion to
use "python setup.py install" the error messages you gave us came very
clearly from python 3.3, not python 2.7.3. Look more closely at some of
those error messages:

> File "c:\python33\lib\site-packages\paramiko-1.7.4-py3.3.
egg\paramiko\transport.py", line 353
>out = '
   ^
> SyntaxError: invalid syntax

C:\python33 is definitely not C:\python27. That looks to me like you have
two versions of python installed on your machine, both python 3.3 and
python 2.7. I an only make an educated guess at this, but probably when you
invoke python on your command line, it's actually python 3.3 that is
started. You can verify this by simply starting a command line, going to
your C:\ directory, typing in python, and looking at the version number
that comes up. If it is indeed true you have two versions of python
installed, try the installation step again, but now make absolutely sure
you use the correct version of python to run the setup script, like this:

C:\python27\python.exe setup.py install

That will use python 2.7 to run the installation script, and *that* in turn
will make sure paramiko is actually installed for the correct python
version.

HTH,
Hugo
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] HELP- Regarding working with python

[Alan Gauld]

On 02/01/13 07:20, Gayathri S wrote:

Hi..
  I am using python 2.7 and scikit-learn for machine learning.
And OS is Windows 7. Wanna know how to import our own data sets  in
scikit-learn?



Hi,

This list is for learning Python and its standard library.

Your question looks to be specific to scikit-learn so will likely get 
more success asking on a scikit-learn forum or by contacting the author 
of scikit-learn.


If you are very lucky some of the folks on this list might just happen 
to have scikit-learn experience, but it isn't guaranteed.


--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] HELP- Regarding working with python

[Alan Gauld]

On 02/01/13 07:20, Gayathri S wrote:

Hi..
  I am using python 2.7 and scikit-learn for machine learning.
And OS is Windows 7. Wanna know how to import our own data sets  in
scikit-learn?


Further to my last mail there is a gmane group

gmane.comp.python.scikit-learn

I'd try looking there, or wherever it is sourced originally.


--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Limitation of int() in converting strings

[Oscar Benjamin]

On 1 January 2013 05:07, Steven D'Aprano  wrote:
> On 23/12/12 04:38, Oscar Benjamin wrote:
>>
>> On 22 December 2012 01:34, Steven D'Aprano  wrote:
>>>
>>> On 18/12/12 01:36, Oscar Benjamin wrote:
>>>
 I think it's unfortunate that Python's int() function combines two
 distinct behaviours in this way. In different situations int() is used
 to:
 1) Coerce an object of some type other than int into an int without
 changing the value of the integer that the object represents.
>>>
> [SNIP]
>
> Yes. And it is a demonstrable fact that int is *not* intended to coerce
> objects to int "without changing the value of the number", because
> changing the value of the number is precisely what int() does, in some
> circumstances.

I wonder how often the int() function is used in a situation where the
dual behaviour is actually desired. I imagine that the common uses for
int are (in descending order or prevalence):
1) Parse a string as an integer
2) Convert an integer-valued numeric object of some other type, to the int type.
3) Truncate a non-integer valued object from a numeric type.

The int() function as it stands performs all three operations. I would
describe 1) and 2) as changing type but not value and 3) as a value
changing operation. I can see use cases where 1) and 2) go together. I
can't really envisage a case in which 1) and 3) are wanted at the same
time in some particular piece of code. In other words I can't imagine
a use case that calls for a function that works precisely as the int()
function currently does.

>
> If you would like to argue that it would have been better if int did
> not do this, then I might even agree with you.

That's exactly what I would argue.

> There is certainly
> precedence: if I remember correctly, you cannot convert floating point
> values to integers directly in Pascal, you first have to truncate them
> to an integer-valued float, then convert.
>
> # excuse my sloppy Pascal syntax, it has been a few years
> var
>   i: integer;
>   x: real;
> begin
>   i = integer(trunc(x));
> end;

 When the idea was discussed in the run up to Python 3, Guido raised
exactly this case and said
"""
I still really wish I had followed Pascal's lead instead of C's here:
Pascal requires you to use trunc() to convert a real to an integer.
(BTW Pascal also had the division operator right, unlike C, and we're
finally fixing this in Py3k by following Pascal's nearly-40-year-old
lead.) If we had done it that way, we wouldn't have had to introduce
the index() builtin and the corresponding infrastructure (__index__
and a whole slew of C APIs).
"""
http://mail.python.org/pipermail/python-dev/2008-January/076546.html

> So I'm not entirely against the idea that Python should have had separate
> int() and trunc() functions, with int raising an exception on (non-whole
> number?) floats.

It's possible that the reason the idea was rejected before is because
it was suggested that int(1.0) would raise an error, analogous to the
way that float(1+0j) raises an error even though in both cases the
conversion can exactly preserve value.

> But back to Python as it actually is, rather than how it might have been.
> There's no rule that int() must be numerically lossless. It is lossless
> with strings, and refuses to convert strings-that-look-like-floats to ints.
> And that makes sense: in an int, the "." character is just as illegal as
> the characters "k" or "&" or "Ω", int will raise on "123k456", so why
> wouldn't it raise on "123.456"?

I agree. To be fair string handling is not my real complaint. I
referred to that initially since the OP asked about that case.

>
> But that (good, conservative) design decision isn't required or enforced.
> Hence my reply that you cannot safely make the assumption that int() on a
> non-numeric type will be numerically exact.

This is precisely my complaint. The currently available functions are
int, operator.index, trunc, math.ceil, math.floor and round.
Conspicuously absent is the function that simply converts an object to
an integer type at the same time as refusing to change its numeric
value. i.e. I would like the special rounding mode that is "no
rounding", just an error for non-integral values. It's probably to do
with the kind of code I write but I seem to often find myself
implementing a (lazy and bug-prone) function for this task.

>> [SNIP]
>>
>> This is precisely my point. I would prefer if if int(obj) would fail
>> on non-integers leaving me with the option of calling an appropriate
>> rounding function. After catching RoundError (or whatever) you would
>> know that you have a number type object that can be passed to round,
>> ceil, floor etc.
>
> Well, I guess that comes down to the fact that Python is mostly aimed at
> mathematically and numerically naive users who would be scared off at a
> plethora of rounding modes :-)

That's true but I think there are some conceptual points that any user
of any programming language should be forced to conside

Re: [Tutor] Limitation of int() in converting strings

[Alan Gauld]

This is going somewhat off-topic but my curiosity is roused...

On 02/01/13 15:16, Oscar Benjamin wrote:
>   When the idea was discussed in the run up to Python 3, Guido raised

exactly this case and said
"""...
(BTW Pascal also had the division operator right, unlike C, and we're
... If we had done it that way, we wouldn't have had to introduce
the index() builtin and the corresponding infrastructure (__index__
and a whole slew of C APIs).


I don't get the reference to index here.
Why would adopting Pascal style division remove the need for index?

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Limitation of int() in converting strings

[Steven D'Aprano]

On 03/01/13 03:18, Alan Gauld wrote:

This is going somewhat off-topic but my curiosity is roused...

On 02/01/13 15:16, Oscar Benjamin wrote:

 When the idea was discussed in the run up to Python 3, Guido raised
exactly this case and said
"""...
(BTW Pascal also had the division operator right, unlike C, and we're
... If we had done it that way, we wouldn't have had to introduce
the index() builtin and the corresponding infrastructure (__index__
and a whole slew of C APIs).


I don't get the reference to index here.
Why would adopting Pascal style division remove the need for index?


No, the comment about division was a parenthetical aside:

"(BTW Pascal also had the division operator right, unlike C, and we're
finally fixing this in Py3k by following Pascal's nearly-40-year-old
lead.)"


The bit about __index__ refers to using trunc():

"I still really wish I had followed Pascal's lead instead of C's here:
Pascal requires you to use trunc() to convert a real to an integer. ...
If we had done it that way, we wouldn't have had to introduce the
index() builtin and the corresponding infrastructure (__index__
and a whole slew of C APIs)."


I don't know what this "index() builtin" is, it doesn't appear to exist.
But __index__ is a special method that converts to int without rounding
or truncating, intended only for types that emulate ints but not other
numeric types:


py> (123).__index__()
123
py> (123.0).__index__()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'float' object has no attribute '__index__'


The purpose is to allow you to use custom integer-types in sequence
indexing, e.g. if n = MyInteger(42), you can use mylist[n] and Python
will call n.__index__() to convert to a proper int. In the past,
Python would only allow actual ints or longs for indexing.

Python cannot use the int() builtin or the regular __int__ method to do
the conversion because they will happily convert floats and strings, and
you don't want to allow mylist['42'] or mylist[42.0] to succeed. So
there needs to be a second special method for converting integer-types
to real ints.

As is often the case, this need was driven by the numpy community, if I
remember correctly, which has int8, int16, int32 and int64 types that
don't inherit from int.



--
Steven
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Limitation of int() in converting strings

[Dave Angel]

On 01/02/2013 11:41 AM, Steven D'Aprano wrote:
> 
>
> The bit about __index__ refers to using trunc():
>
> "I still really wish I had followed Pascal's lead instead of C's here:
> Pascal requires you to use trunc() to convert a real to an integer. ...
> If we had done it that way, we wouldn't have had to introduce the
> index() builtin and the corresponding infrastructure (__index__
> and a whole slew of C APIs)."
>
>
> I don't know what this "index() builtin" is, it doesn't appear to exist.
> But __index__ is a special method that converts to int without rounding
> or truncating, intended only for types that emulate ints but not other
> numeric types:

I suspect that at one time, an index() built-in was intended.  It's now
available as an operator, and simply calls the __index__() as you say.

import operator
print operator.index(myobject)

works, at least in 2.7 and 3.x



-- 

DaveA

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Limitation of int() in converting strings

[Alan Gauld]

On 02/01/13 16:55, Dave Angel wrote:

On 01/02/2013 11:41 AM, Steven D'Aprano wrote:



The bit about __index__ refers to using trunc():


OK, that partially solves it :-)



I don't know what this "index() builtin" is, it doesn't appear to exist.


That was also what confused me. The only indexz() I could find was the 
one that found the index of an item in a collection


>>> [1,2,3].index(2)
1

And I didn't see how trunc() or division helped there...


But __index__ is a special method that converts to int without rounding
or truncating, intended only for types that emulate ints but not other
numeric types:


And this was the new bit I didn't know about.


import operator
print operator.index(myobject)


But I did try

>>> import operator as op
>>> help(op.index)
Help on built-in function index in module operator:

index(...)
index(a) -- Same as a.__index__()

Which was no help at all, so I tried

>>> help(a.__index__)
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'a' is not defined

Which was what I expected!

So now with your input I can try:

>>> help(int.__index__)
Help on wrapper_descriptor:

__index__(...)
x[y:z] <==> x[y.__index__():z.__index__()]


Bingo! Although still doesn't anything explicitly about the need for an 
integer!


But that was harder than it should have been! :-(

Thanks guys,

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

[Tutor] writing effective unittests

[Luke Thomas Mergner]

Hi,

I am trying to learn a bit of test-driven programming using unittests and 
nosetests. I am having trouble finding resources that explain how to write 
effective tests. I am not a programmer or a student, so I do not have access to 
collegues or classes. I'm hoping that someone knows of a good tutorial that 
I've missed. Based on the O'Reilly 2-Part introduction, I hope that learning to 
write tests will make my code better. 

Thanks,

-- 
Luke Thomas Mergner
Glendale, CA

Sent from Mutt.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] writing effective unittests

[Alan Gauld]

On 02/01/13 20:43, Luke Thomas Mergner wrote:

I am trying to learn a bit of test-driven programming using unittests and 
nosetests.


Well done, thats a good idea.


I am having trouble finding resources that explain how to write effective tests.


Thee are whole books on the subject of testing. If you stick to unit 
test level its not too bad there are some useful resources around.


This is more of a reference sheet than a tutorial but I find it useful...

http://geosoft.no/development/unittesting.html

The main things to remember are that in testing you are trying to break 
your code. Which is a hard thing for any programmer to do because he 
wrote it and loves it and doesn't want to hear that its broken! TDD 
helps get over that because you think about testing before that 
sentimental attachment has fully formed. But the philosophy is the same 
you are trying to think of every which way your  code could break.



Other related topics you could research are
- preconditions
- postconditions
- invariants
- programming by contract

And always remember that just because all your unit tests pass that 
doesn't mean the system as a whole works, it's just more likely to,

and probably easier to fix when it does break.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

[Tutor] Python Programming for Absolute Beginners, 3rd Edition

[Conor Grevlos]

I recently bought and starting reading the Python Programming for Absolute 
Beginners, 3rd Edition by Michael Dawson.

I got through the first chapter fine, no problems. But when I got to the second 
chapter I realized that I did not know how
to do the first programming lesson, Game Over 2.0

With the code not being on the page, I went to the directed website and got the 
downloads, yet I couldn't find the source code
anywhere to be found. Am I missing something plainly obvious? I do not 
understand how to get the cool looking Game Over
to show up, nor do I have any idea how to try. I understand that there is some 
of the code on the page, but the other programs 
have no source code to go by either, it is as if you are left to your own 
knowledge and being this is a beginners book, that seems
pretty stupid. Any help would be awesome thanks!___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Python Programming for Absolute Beginners, 3rd Edition

[Matthew Ngaha]

> With the code not being on the page, I went to the directed website and got
> the downloads, yet I couldn't find the source code
> anywhere to be found. Am I missing something plainly obvious?

what exactly did you download? all the source code for every chapter
is included in the download
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] writing effective unittests

[Steven D'Aprano]

On 03/01/13 07:43, Luke Thomas Mergner wrote:

Hi,

I am trying to learn a bit of test-driven programming using
unittests and nosetests. I am having trouble finding resources
that explain how to write effective tests. I am not a programmer
or a student, so I do not have access to collegues or classes.


If you program, you are a programmer. And we are your colleagues :)



I'm hoping that someone knows of a good tutorial that I've missed.
 Based on the O'Reilly 2-Part introduction, I hope that learning to
write tests will make my code better.



There are many resources on the web that talk about "Test Driven
Development". The basic idea is, you incrementally write the test first,
check that it fails, and then fix the code so the test passes. Then
write the next test, see that this one fails, then fix the code so that
it passes, and repeat until your code is done.

If you google for "Python test driven development tutorial", you will
find many resources:

https://duckduckgo.com/?q=python%20test%20driven%20development%20tutorial


Personally, I don't bother with the strict "write one test at a time"
rule, nor do I bother with "always write the test before the code". I am
quite happy to write a bunch of code first, and then write half a dozen
tests. The important part is to have the tests, not the order in which
they get written.

For example, suppose you have a function called "spam" that is supposed
to return a string:

def spam(n):
"""Return n lots of a yummy meat-like substance."""
return ' '.join("spam")*n



So the first thing that I do is decide what sort of behaviour spam should
have. It should always return a string; it should only accept a single int
argument; if no argument is given, the result should be the same as
calling spam(1). So here are my first three unittests.


import unittest

class SpamTests(unittest.TestCase):
# Tests related to the spam function.

def testAlwaysReturnString(self):
# Test that spam always returns a string.
for n in (-5, -2, 0, 1, 2, 3, 15, 100):
self.assertTrue(isinstance(spam(n), str))

def testFailOnWrongArgumentCount(self):
# Test that spam takes at most one argument.
self.assertRaises(TypeError, spam, 1, 2)
self.assertRaises(TypeError, spam, 1, 2, 3)

def testDefaultArgIsOne(self):
# Test that spam with no args is like spam(1).
self.assertEqual(spam(), spam(1))



Notice that tests are not necessarily definitive. I haven't tested that
spam(n) returns a string for every imaginable integer n, because there
are too many. Instead, I just test a small, representative sample.

Likewise I haven't tested that spam() might succeed when given four
arguments, or forty-four. I trust that if it fails with two arguments,
and fails with three arguments, it will fail with more than three too.

Don't make the mistake of thinking that tests need to cover EVERYTHING
or else they are useless. 10% test coverage is better than nothing,
50% is better still, and 90% is better still. (100% is, of course,
impossible.)

At this point, I will run the unittests, and see whether they work or
not. I haven't actually done so, but I expect that testDefaultArgIsOne
will fail (to be precise, it will actually raise an exception). So I
then go back to my spam() function and add in a default argument:

def spam(n=1):
... # as above


Let's add some more tests to SpamTests:

def testHasDocString(self):
# Test that the spam function has a docstring.
doc = spam.__doc__
self.assertTrue(doc is not None)

def testFailOnWrongArgumentType(self):
# Test that the argument must not be a non-int.
for bad_arg in (None, "hello", "42", 23.0, [], {}):
self.assertRaises(TypeError, spam, bad_arg)

def testReturnResult(self):
# Test that spam returns the correct result.
self.assertEqual(spam(1), "spam")
self.assertEqual(spam(2), "spam spam")
self.assertEqual(spam(3), "spam spam spam")
self.assertEqual(spam(44), "spam spam spam spam")

def testEmpty(self):
# Test that spam returns an empty string when appropriate.
for n in (0, -1, -2, -99):
self.assertEqual(spam(n), "")


Then I run the tests. If any fail, I have to either fix the test (perhaps
the test is buggy) or fix the function.

Once those tests pass, I might decide that I'm finished -- I have enough
tests for spam, and can go on to the next part of my code. Or I might
decide that I don't actually like the behaviour of spam as it is now. For
instance, I might change the function to this:


def spam(n=3):
"""Return n lots of a yummy meat-like substance."""
if n < 0:
return "No spam for YOU!!!"
return ' '.join("spam")*n


Now I run my tests again. I expect that now two tests will fail. Can you
see which ones? So I modify the tests, or add new tests as needed, and
continue until I'm happy with the results. And then mov

[Tutor] Python Programming for Absolute Beginner

[Conor Grevlos]

I downloaded the python source folder, with chapters 1 through 12 I think. But 
it just opens up the program that is already built, not one that shows me the 
code.

Sent from my iPhone
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Python Programming for Absolute Beginner

[Robert Sjoblom]

On Jan 3, 2013 2:22 a.m., "Conor Grevlos"  wrote:
>
> I downloaded the python source folder, with chapters 1 through 12 I
think. But it just opens up the program that is already built, not one that
shows me the code.

Open the files in an editor of your choice, don't run them.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Python Programming for Absolute Beginner

[Dave Angel]

On 01/02/2013 08:20 PM, Conor Grevlos wrote:
> I downloaded the python source folder, with chapters 1 through 12 I think. 
> But it just opens up the program that is already built, not one that shows me 
> the code.
>

Starting a new thread with each message is unproductive and impolite.

If you actually want help, how about being a tad more specific about
what you actually did?  What file did you download (exact filename
including extension, not an approximation), and from what link?


-- 

DaveA

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Python Programming for Absolute Beginner

[Ryan Macy]

Conor Grevlos wrote:


I downloaded the python source folder, with chapters 1 through 12 I 
think. But it just opens up the program that is already built, not one 
that shows me the code.


Sent from my iPhone
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor



Open the file in a text editor, you're OS is likely executing the source 
code when you double click it :)
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor