代写CSC1034: Lecture 3调试Python程序

日期：2024-08-13 02:08

CSC1034: Lecture 3

Intro

• This weeks programming topics

•  Programming

–  Modules

–  Generators

–  Named Tuples

–  Pizza (next weeks lecture!)

•  Development

– Testing

How to learn

• Important to read and to play

•  Don’t understand Python

–  Python Tutorial https://docs.python.org/3/tutorial/

•  Not clear on commits and pushing

–  Progit https://git-scm.com/book/en/v2

•  Markdown

– https://www.markdownguide.org

Stuck somewhere

• If you are stuck on the practials, read the online material

• If you are stuck on the online material, try more of the practical

• If neither make sense, use the internet!

On the Internet

• Wikipedia is a good source

•  StackOverflow

•  Can be hard to judge whether you should understand something

•  Be prepared to read what does not make sense now

• It might make sense later

•  But be prepared to move on - there is lots of rubbish out there

Use the material

•  Many of you are getting stuck with broken code

•  Read the error messages

•  Here statements are really good

•  Change your code carefully and thoughtfully

The Coursework

• What the coursework is

•  How you have to submit

NESS Submissions

•  Plenty of time left to submit!

•  Can submit more than once

•  Rigid timing – please submit early

Modules

•  So far, you have written code in one place

• That’s okay for small programs

•  But becomes unwieldly later on

•  Python provides a module system to split things up

•  Some of the terminology overlaps with other usages

Modules and Packages

• A module consists of a set of functions and objects

•  Defined in a single file

•  Related modules can be grouped into packages

• These are all in the same directory

• This usage of package is different the package we have seen earlier

•  Mostly, package means “a package on PyPI”

• This kind of terminology collision is unfortunate, but not really anyone’s fault.

Modules

• There is an important motivation beyond a neat set of files

•  Functions should be sensibly named

•  But they all share the same name space

• The names would clash

• We need a way to disambiguate

Modules

•  Similar to human names

• I currently working with three other people called “Phil”

• We have longer names to disambiguate

•  Likewise, Newcastle (-upon-Tyne, -under-Lyme)

Modules

•  Python knows about all the functions in the current module

•  Others must be import-ed into the current module

•  Consider this statement:

import  fred

•  Python looks for fred.py in the current directory

•  Loads it

– reads the file, all the definitions in it

– Also known as evaluating the file, or eval’ing

•  Makes all the definitions available

Modules

• There is more to say about modules

• I find Python modules simple in theory and error-prone in practice

• Try to keep it simple

•  Read the Manual

• If all else fails, use brute force and ignorance to figure out problems

Programming

•  Python is a high-level language

•  Comes with a significant degree of abstraction

•  Sometimes you need to know what is happening

Generators

•  range is a very useful function

• It returns a list of the appropriate size

for  i  in  [0 ,  1 ,  2 ,  3 ,  4 ,  5 ,  6 ,  7 ,  8 ,  9]:

print(i,  end= ' , ' ) print()

for  i  in  range(10):     print(i,  end= ' , ' )

0,1,2,3,4,5,6,7,8,9,

0,1,2,3,4,5,6,7,8,9,

Generators

• Actually, though, it doesn’t

• Try this

print([0 ,1 ,2 ,3 ,4 ,5 ,6 ,7 ,8 ,9])

print(range(10))

[0,  1,  2,  3,  4,  5,  6,  7,  8,  9] range(0,  10)

Generators

•  So, what range returns is not a list

• It doesn’t print out as one

• It actually behaves very differently

Generators

• To understand this, we need to understand memory

•  Python uses garbage collection for memory management

• What is memory management?

•  Consider this code:

for  i  in  range(1 ,100000):

x  =  [i]

Generators

• We create lots of lists, each with a single value

•  For each list, we must allocate some memory

• The computer has a fixed amount of memory

•  Eventually we are going to run out

•  So, we must deallocate or recover the memory

Generators

• What is memory management, and why do we care?

• Two main mechanisms:

•  Some languages do this explicitly

•  Some use Garbage Collection or GC

•  GC is automatic

•  So automatic you might not realise it’s there

Demo

Moving through a list

Generators

•  How does this relate to the range function?

• Imagine, we create a list

Generators

•  Now we iterate through this list 

• The list references all of its elements

• Including those we have used

• And those we have not go to yet

Generators

• A generator works differently

• Imagine it as a function with some data attached 

• It’s now cheap to create

• And costs them same regardless of the size

Generators

•  Python also has generator expressions

•  Like a list comprehension

•  Neat and succinct

• With a slightly odd “naked” syntax

## Status:  Shell

any([x>42  for  x  in  range(0 ,  10**2)])

any(x>42  for  x  in  range(0 ,  10**2**2**2))

def  gen():

return  (x>42  for  x  in  range(0 ,  10**2**2**2)) any(gen())

NamedTuples and Typing

• Will finish off programming section by introducing named tuples

• Also lead in to the next section

NamedTuples

• If you have been following the online material, we have dealt with trains earlier

•  One list

•  One dictionary

##  0  -  Name

##  1  -  Colour

## 2  -  Engine  Type ##  3  -  Train  Type   ## 4  -  Role

wilson  =  [ "wilson" ,  "red" ,  "diesel" ,  "EMD  F3" ,  "Trainee"]

print(wilson) wilson  =  {

"name" :  "wilson" ,

"colour" :  "red" ,

"engine" :  "diesel" , "type" :  "EMD  F3" ,

"role" :  "Trainee"

}

print(wilson)

NamedTuples

•  Lists are shorter to write

•  But easy to forget, or make mistakes

•  So, dictionaries solve the problems?

• What if we need several?

wilson  =  {

"name" :  "wilson" ,

"colour" :  "red" ,

"engine" :  "diesel" , "type" :  "EMD  F3" ,

"role" :  "Trainee"

}

brewster  =  {

"name" :  "brewster" , "colour" :  "blue" ,

"engine" :  "diesel" ,

"type" :  "BR  Class  55" , "role" :  "Trainee"

}

koko  =  {

"name" :  "koko" ,

"color" :  "green" ,

"engine" :  "electric" ,

"type" :  "0  Series  Shinkansen" , "role" :  "Trainee"

}

print(wilson[ "colour"]) red

NamedTuples

• We can create multiple instances of a similar dictionary

• Which is nice

•  But, still error prone

•  Possibly you saw the mistake

## Status:  Crash

wilson  =  {

"name" :  "wilson" ,

"colour" :  "red" ,

"engine" :  "diesel" , "type" :  "EMD  F3" ,

"role" :  "Trainee"

}

brewster  =  {

"name" :  "brewster" , "colour" :  "blue" ,

"engine" :  "diesel" ,

"type" :  "BR  Class  55" , "role" :  "Trainee"

}

koko  =  {

"name" :  "koko" ,

"color" :  "green" ,

"engine" :  "electric" ,

"type" :  "0  Series  Shinkansen" , "role" :  "Trainee"

}

print(wilson[ "colour"]) print(koko[ "colour"])

Traceback  (most  recent  call  last):

File  "/home/phillord/documents/teaching/2023-24/csc1034/dev-repo/lectures-1/python/train_ print(koko["colour"])

KeyError:  ' colour '

NamedTuples

•  Even, if we build our instances correctly

• We could (accidentally) change the keys after

•  Named tuples address both of these

import  collections

Train  =  collections.namedtuple( "Train" ,

[ "name" ,  "colour" ,  "engine" , "kind" ,  "role"])

wilson  =  Train(name= "wilson" ,  colour= "red" ,

engine= "diesel" ,  kind= "EMD  F3" , role= "Trainee")

brewster  =  Train(name= "brewster" ,  colour= "blue" ,

engine= "diesel" ,  kind= "BR  Classic  55" , role= "Trainee")

koko  =  Train(name= "name" ,  colour= "green" ,

engine= "electric" ,  kind= "0  Series  Shinkansen" , role= "Trainee")

print(koko)

Train(name= ' name ' ,  colour= ' green ' ,  engine= ' electric ' ,  kind= ' 0  Series  Shinkansen ' ,  role= ' Tra

NamedTuples

• We cannot misname a field

• And, it’s a tuple, so it’s immutable

## Status:  Crash

import  collections

Train  =  collections.namedtuple( "Train" ,

[ "name" ,  "colour" ,  "engine" , "kind" ,  "role"])

wilson  =  Train(name= "wilson" ,  colour= "red" ,

engine= "diesel" ,  kind= "EMD  F3" , role= "Trainee")

brewster  =  Train(name= "brewster" ,  colour= "blue" ,

engine= "diesel" ,  kind= "BR  Classic  55" , role= "Trainee")

koko  =  Train(name= "name" ,  color= "green" ,

engine= "electric" ,  kind= "0  Series  Shinkansen" , role= "Trainee")

Traceback  (most  recent  call  last):

File  "/home/phillord/documents/teaching/2023-24/csc1034/dev-repo/lectures-1/python/train_ koko  =  Train(name="name",  color="green",

TypeError:  Train .__new__ ()  got  an  unexpected  keyword  argument  ' color '

NamedTuples

•  Named tuples use a different syntax for accessing values import  collections

Train  =  collections.namedtuple( "Train" ,

[ "name" ,  "colour" ,  "engine" , "kind" ,  "role"])

wilson  =  Train(name= "wilson" ,  colour= "red" ,

engine= "diesel" ,  kind= "EMD  F3" , role= "Trainee")

print(wilson.name)     print(wilson.colour) print(wilson.engine)

wilson red

diesel

NamedTuples

• This is actually generic syntax

•  Called “field” or “attribute” access

• It’s possible to introspect on attributes

• The tuple knows all of its attributes

•  Use dir and hasattr

• Also, getattr and setattr

import  collections

Train  =  collections.namedtuple( "Train" ,

[ "name" ,  "colour" ,  "engine" , "kind" ,  "role"])

wilson  =  Train(name= "wilson" ,  colour= "red" ,

engine= "diesel" ,  kind= "EMD  F3" , role= "Trainee")

print(dir(wilson))

print(hasattr(wilson,  "name"))

[ ' __add__ ' ,  ' __class__ ' ,  ' __class_getitem__ ' ,  ' __contains__ ' ,  ' __delattr__ ' ,  ' __dir__ ' ,  ' __ True

NamedTuples

•  Named tuples are fantastic for data-centric apps

• Which is a lot of apps in Python

• Will see an example in a minute

Testing

•  Remember our minimum function

• There is a difficulty

• I’ve gone to all this effort, but it cannot remain in the final code

• If I added this to a module, we would run our tests

•  But if remove, we have lost the test cases

• Which we probably did by hand

• Also, test_minimum might be more generally useful def minimum(lst):

if  len(lst)  ==  0 :

raise  ValueError ("Cannot  find minimum  of  an  empty  sequence")

lowest  =  lst[0]     for  i  in  lst[1 :]:

if  i  <  lowest: lowest  =  i

return  lowest

def  test_minimum(expected,  lst):

print( "Should  be" ,  expected,  ":" , minimum(lst))

test_minimum(-100,  [-100 ,  0 ,  100])

test_minimum(-100,  [100 ,  0 ,  -100])

test_minimum(-1000,  [-1000 ,  0 ,  1000]) test_minimum(-10,  [-10 ,  0 ,  10])

test_minimum(1000 ,  [1000 ,  10000])

Testing

• We can check whether we are running the file

•  Or python is loading it as a module def minimum(lst):

if  len(lst)  ==  0 :

raise  ValueError ("Cannot  find minimum  of  an  empty  sequence")

lowest  =  lst[0]     for  i  in  lst[1 :]:

if  i  <  lowest: lowest  =  i

return  lowest

def  test_minimum(expected,  lst):

print( "Should  be" ,  expected,  ":" , minimum(lst))

if  __name__  ==   ' __main__ ' :

test_minimum(-100,  [-100 ,  0 ,  100])

test_minimum(-100,  [100 ,  0 ,  -100])

test_minimum(-1000,  [-1000 ,  0 ,  1000]) test_minimum(-10,  [-10 ,  0 ,  10])

test_minimum(1000 ,  [1000 ,  10000])

Testing

• What we need it Test Driven Development

•  Like version control, Testing is an essential tool for the programmer

• In the last 15 years, become routine

• This has rather upended development

Testing

• The process of writing code:

•  Have a problem

•  Define a set of requirements

• Write some code to fulfil the requirements

• Test to see if you have solved the problem

•  Or, alternatively

–  Have a problem

–  Define a set of requirements

– Turn the requirements into a computational runnable test

– Write some code, till the tests run

–  Stop

Testing

• The latter is called Test-Driven Development

• Write your tests before your code

• If you cannot write a test, you do not understand the problem

• There are limitations

•  For large datasets - where you do not know the answer

•  Or highly computational tasks

•  Or where tests are not automatable

–  Especially GUIs

– Where there is human interpretation

Testing

• Assume that we have the following code

• In a file called stats .py def minimum(lst):

if  len(lst)  ==  0 :

raise  ValueError ("Cannot  find minimum  of  an  empty  sequence")

lowest  =  lst[0]     for  i  in  lst[1 :]:

if  i  <  lowest: lowest  =  i

return  lowest

Testing

• To test this, we add a new file called test_stats .py

• The test part of the name is important

• The stats can be anything

import  stats

def  test_minimum():

assert  stats.minimum([-100 ,  0 ,  100])  ==  -100

Testing

• We use the Python assert keyword

• It says “I claim that the following must be true”

• We also need to ensure pytest is installed

•  Now run pytest

•  If our test succeeds, we get a nice short message

=============================  test  session  starts  ============================== platform  linux  --  Python  3.10.12,  pytest-7.4.2,  pluggy-1 .3 .0

rootdir:  /home/phillord/documents/teaching/2023-24/csc1034/dev-repo/lectures-1/python collected  1  item

test_stats .py  .                                                                                                                   [100%]

==============================  1  passed  in  0 .01s  ===============================

Testing

• If you’re tests fail, we get something longer telling us the problem

import  pytest import  stats

def  test_success_minimum():

assert  stats.minimum([-100 ,  0 ,  100])  ==  -200

=============================  test  session  starts  ============================== platform  linux  --  Python  3.10.12,  pytest-7.4.2,  pluggy-1 .3 .0

rootdir:  /home/phillord/documents/teaching/2023-24/csc1034/dev-repo/lectures-1/python collected  1  item

test_stats_fail.py  F                                                                                                         [100%]

===================================  FAILURES  ===================================

test_success_minimum                                                         

def  test_success_minimum():

>            assert  stats.minimum([-100,  0,  100])  ==  -200

E             assert  -100  ==  -200

E              +    where  -100  =  <function  minimum  at  0x7f83b84cb0a0>([-100,  0,  100]) E               +       where  <function  minimum  at  0x7f83b84cb0a0>  =  stats .minimum

test_stats_fail .py:5:  AssertionError

===========================  short  test  summary  info  ============================ FAILED  test_stats_fail.py::test_success_minimum  -  assert  -100  ==  -200

==============================  1  failed  in  0 .02s  ===============================

• A formal test harness is a big improvement on what we said before

• The output shows us what we need and nothing else

•  Our expectations for correct results are clear

• We can keep tests forever

•  But not have them in deployed code

Testing

•  Can change the way that you code

• It’s a hard practice to adopt

•  But one that will make life easier as you move on

Conclusions

• We are nearing the end of the taught material for this section

•  But there is a week to go: take the time to read!

• If you have anything you want me to cover next week, please email!