Re: [Tutor] How do I test file operations (Such as opening, reading, writing, etc.)?
On 28/01/16 04:23, boB Stepp wrote: > I don't want to mess with what will become the program's *real* > classifiers.txt (And other needed text files to come, that will > likewise be editable.), so how do I simulate these various needed file > operations in a way that tests the actual program code, but without > touching the actual data files? Danny has shown you one way using a mocked filesystem. But for your case can't you just specify a file location as an environment variable or argv? That way you get the advantage of using real files, which can be an important factor in timing issues, especially if you plan on having any concurrency going on. And it's simple to do... -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Change datatype for specific columns in an 2D array & computing the mean
On 27 January 2016 at 23:00, Ek Esawi wrote:
> Ops..here is the text file.; previously i copied and pasted from either
> Word or Excel.
>
>
> AA,BB,CC,DD,EE
> 1,A1,B1,11.2,11/20/2011
> 2,A2,B2,2.5,10/21/2011
> 3,A3,B3,13.67,9/21/2011
> 4,A4,B4,14.2,8/22/2011
> 5,A5,B5,20,7/23/2011
Finally! That's what I expect to see in a csv file. Do the first,
second and third columns just count up like that? I thought that you
were expecting some rows to have the same values in the second and
third columns.
I'm not sure that it's really worth using numpy for this. I'd just use
the csv module:
import csv
with open('test.csv') as csvfile:
reader = csv.reader(csvfile)
next(reader, None) # Ignore first line of file
for line in reader:
index, col2, col3, col4, date = line
col4 = float(col4) # Convert 4th column value to float
print([col2, col3, col4])
Running this I get:
$ python3 test.py
['A1', 'B1', 11.2]
['A2', 'B2', 2.5]
['A3', 'B3', 13.67]
['A4', 'B4', 14.2]
['A5', 'B5', 20.0]
--
Oscar
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
[Tutor] lc_ctype and re.LOCALE
Hi,
Out of curiosity, I wrote the throw-away script below to find a character that
is classified (--> LC_CTYPE) as digit in one locale, but not in another.
I ran it with 5000 locale combinations in Python 2 but did not find any
(somebody shut down my computer!). I just modified the code so it also
runs in Python 3. Is this the correct way to find such locale-dependent regex
matches?
albertjan@debian:~/Downloads$ uname -a && python --version && python3 --version
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)
x86_64 GNU/Linux
Python 2.7.9
Python 3.3.4
albertjan@debian:~/Downloads$ cat lc_ctype.py
# -*- coding: utf-8 -*-
"""
Find two locales where a different character classification causes a regex
to match a given character in one locale, but fail in another.
This is to demonstrate the effect that re.LOCALE (in particular the LC_CTYPE
locale category) might have on locale-aware regexes like \w or \d.
E.g., a character might be classified as digit in one locale but not in another.
"""
from __future__ import print_function, division
import subprocess
import locale
import itertools
import sys
import re
try:
xrange
except NameError:
xrange = range
unichr = chr
if sys.version_info.major> 2:
unicode = str
proc = subprocess.Popen("locale -a", stdout=subprocess.PIPE, shell=True)
locales = proc.communicate()
locales = sorted(locales[0].split(b"\n")) # this is the list:
http://pastebin.com/FVxUnrWK
if sys.version_info.major> 2:
locales = [loc.decode("utf-8") for loc in locales]
regex = re.compile(r"\d+", re.LOCALE) # is this the correct place?
total = len(list(itertools.combinations(locales, 2)))
for n, (locale1, locale2) in enumerate(itertools.combinations(locales, 2), 1):
if not locale1 or not locale2:
continue
if n % 10 == 0 or n == 1:
sys.stdout.write(" %d (%3.2f%%) ... " % (n, (n / total * 100) ))
sys.stdout.flush() # python 2 print *function* does not have flush
param
for i in xrange(sys.maxunicode + 1): # 1114111
s = unichr(i) #.encode("utf8")
try:
locale.setlocale(locale.LC_CTYPE, locale1)
m1 = bool(regex.match(s))
locale.setlocale(locale.LC_CTYPE, locale2)
m2 = bool(regex.match(s))
if m1 ^ m2: # m1 != m2
msg = ("@@ ordinal: %s | character: %s (%r) | "
" digit in locale '%s': %s | digit in locale '%s': %s ")
print(msg % (i, unichr(i), unichr(i), locale1, m1, locale2, m2))
break
except locale.Error as e:
#print("Error: %s with %s and/or %s" % (e, locale1, locale2))
continue
print("---Done---")
Thank you!
Albert-Jan
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How do I test file operations (Such as opening, reading, writing, etc.)?
On Thu, Jan 28, 2016 at 12:44 AM, Alan Gauld wrote: > On 28/01/16 04:23, boB Stepp wrote: > >> I don't want to mess with what will become the program's *real* >> classifiers.txt (And other needed text files to come, that will >> likewise be editable.), so how do I simulate these various needed file >> operations in a way that tests the actual program code, but without >> touching the actual data files? > > Danny has shown you one way using a mocked filesystem. > But for your case can't you just specify a file location > as an environment variable or argv? That way you get the > advantage of using real files, which can be an important > factor in timing issues, especially if you plan on having > any concurrency going on. And it's simple to do... Just to emphasize what I think is an essential point: the basic approach we're doing is here parameterization: to take something that used to be hardcoded, and turn it into a parameter that allows us to substitute with something else. As Alan says, you can also parameterize in a different way: by the directory location where files are being read. Then you can use a temporary directory for your unit tests, and prepare the testing environment that way. If you take this approach, the tempfile module can help with this. https://docs.python.org/3.5/library/tempfile.html https://docs.python.org/3.5/library/tempfile.html#tempfile.TemporaryDirectory The mocking approach is one where we're doing this parameterization at a behavioral level. When we started to program, we may have initially thought that a parameter could only be numbers, since that's what algebra traditionally uses as its domain. When we program, we find that domain of values expanded to a richer set, and not just to inactive values like strings or dictionaries or images, but now we can pass entire collections of behavior as a parameter. That's one of the lessons of OOP: values are not just inert data: they can define dynamic behavior. (Aside: this is somewhat why I think the topic of inheritance and inheritance hierarchies are entirely the wrong things to focus on when we're teaching OOP. Those topics are often used as a shortcut mechanism to do code sharing, and although that's convenient, my opinion is that it misses the forest for the trees. What I think OOP's heart is beating is in the ability to parameterize behavior.) ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How do I test file operations (Such as opening, reading, writing, etc.)?
This is a problem I have come up against often, and I don't think I have a good answer, so if anyone else does, I would be glad to hear it! I would be tempted to generate a 'test data.CSV" file, and run the tests on that. It means that as you write the code, and find some edge cases, you can alter your code and add the edge cases to the test data. That way, the test data acts to cover the space of various oddities in your work. I would be very keen to hear other ideas, BW, Matt On Thu, 28 Jan 2016 20:12 Danny Yoo wrote: > On Thu, Jan 28, 2016 at 12:44 AM, Alan Gauld > wrote: > > On 28/01/16 04:23, boB Stepp wrote: > > > >> I don't want to mess with what will become the program's *real* > >> classifiers.txt (And other needed text files to come, that will > >> likewise be editable.), so how do I simulate these various needed file > >> operations in a way that tests the actual program code, but without > >> touching the actual data files? > > > > Danny has shown you one way using a mocked filesystem. > > But for your case can't you just specify a file location > > as an environment variable or argv? That way you get the > > advantage of using real files, which can be an important > > factor in timing issues, especially if you plan on having > > any concurrency going on. And it's simple to do... > > > Just to emphasize what I think is an essential point: the basic > approach we're doing is here parameterization: to take something that > used to be hardcoded, and turn it into a parameter that allows us to > substitute with something else. > > As Alan says, you can also parameterize in a different way: by the > directory location where files are being read. Then you can use a > temporary directory for your unit tests, and prepare the testing > environment that way. If you take this approach, the tempfile module > can help with this. > > https://docs.python.org/3.5/library/tempfile.html > > https://docs.python.org/3.5/library/tempfile.html#tempfile.TemporaryDirectory > > > The mocking approach is one where we're doing this parameterization at > a behavioral level. When we started to program, we may have initially > thought that a parameter could only be numbers, since that's what > algebra traditionally uses as its domain. When we program, we find > that domain of values expanded to a richer set, and not just to > inactive values like strings or dictionaries or images, but now we can > pass entire collections of behavior as a parameter. That's one of the > lessons of OOP: values are not just inert data: they can define > dynamic behavior. > > (Aside: this is somewhat why I think the topic of inheritance and > inheritance hierarchies are entirely the wrong things to focus on when > we're teaching OOP. Those topics are often used as a shortcut > mechanism to do code sharing, and although that's convenient, my > opinion is that it misses the forest for the trees. What I think > OOP's heart is beating is in the ability to parameterize behavior.) > ___ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > https://mail.python.org/mailman/listinfo/tutor > ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How do I test file operations (Such as opening, reading, writing, etc.)?
On 28/01/16 20:03, Danny Yoo wrote: > (Aside: this is somewhat why I think the topic of inheritance and > inheritance > hierarchies are entirely the wrong things to focus on when we're > teaching OOP. Absolutely. I always try to focus on the objects passing, and responding to, *messages* as the key feature. Inheritance is a convenience, often abused to do code reuse. The thing to focus on is polymorphism which just happens to be implemented by inheritance heirarchies in most languages (although not in python!) One of the things I like about Objective C is the fact that it has a separate notation for sending messages to objects compared to calling a function(*). It really emphasises the different concepts at work - sending a message is not the same as simply calling a function, there is a layer of magic in between! > What I think OOP's heart is beating is in the ability to parameterize behavior.) That's a by-product of encapsulation and polymorphism which are the beating heart of pure OOP (sorry Steve ;-). (*) In ObjectiveC: result = [anObject aMessage:aParameter]; // send a message to an object result2 = aFunction(anObject, aParameter); // call a function -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Why is an OrderedDict not sliceable?
> Date: Wed, 27 Jan 2016 02:24:35 +1100
> From: st...@pearwood.info
> To: tutor@python.org
> Subject: Re: [Tutor] Why is an OrderedDict not sliceable?
>
> On Sun, Jan 24, 2016 at 07:47:47PM +, Albert-Jan Roskam wrote:
>
>>> You appear to be confusing ordered and sorted.
>>
>> You are correct. Is there a difference in the way those terms are
>> used colloquially vs. in the field of Computer Science (Note: English
>> is not my mother tongue)?
>
> In ordinary English, "ordered" and "sorted" often are used to mean the
> same thing. People do often use sorted and ordered as interchangeable,
> but the definitions are slightly different:
>
>
>
> ordered \ordered\ adj.
> 1. having or evincing a systematic arrangement; especially,
> having elements succeeding in order according to rule; as,
> an ordered sequence; an ordered pair. Opposite of
> disordered or unordered. [Narrower terms:
> abecedarian, alphabetical; {consecutive, sequent,
> sequential, serial, successive ]
> [WordNet 1.5 +PJC]
>
> 2. arranged in order.
>
> Sort \Sort\, v. t. [imp. & p. p. Sorted; p. pr. & vb. n.
> Sorting.]
> 1. To separate, and place in distinct classes or divisions,
> as things having different qualities; as, to sort cloths
> according to their colors; to sort wool or thread
> according to its fineness.
> [1913 Webster]
>
>
> The way I would put it is that "sorted" means the items are ordered
> according to some specific rule or property of the items themselves,
> e.g. to sort your clothes by colour. "Ordered" is more general: it just
> means to have some order, which may be according to a rule or property,
> or it may be in whatever sequence the items happen to have.
>
> Books on a shelf have some order, the order that they appear when you
> read them from left to right, regardless of whether they are sorted by
> author, title, height, colour or at random. Books jumbled up in a bag
> have no order.
>
> Ordinary dicts are like books in a bag. You reach in and grab whatever
> book happens to come to hand first. OrderedDicts are like books on a
> shelf: you can systematically touch each book in order starting from the
> left, and new books are always added to the right.
Thank you! That distinction is indeed quite subtle. With "ordered" I tend to
think of "ordinal measurement level" or something like that. E.g., sort a list
of heights, calculate the median, ntiles etc. But your description makes it a
whole lot clearer. Sometimes analogies work better!
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Change datatype for specific columns in an 2D array & computing the mean
Thank you SO MUCH Oscar and others. This is exactly what i wanted to get. I think i can take it form here. I spent hours looking at different ways to figure it out and i came close. I tried numpy.genfromtxt, numpy.loadtext, json, etc. I am at the moment learning how to open various data files with different format such as csv, pdf, html, etc. and then convert them to arrays or list. Thanks again for your patience and help EK ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How do I test file operations (Such as opening, reading, writing, etc.)?
Hello all, [much snipped] boB>> >> I don't want to mess with what will become the program's *real* boB>> >> classifiers.txt (And other needed text files to come, that will boB>> >> likewise be editable.), so how do I simulate these various needed file boB>> >> operations in a way that tests the actual program code, but without boB>> >> touching the actual data files? Danny> As Alan says, you can also parameterize in a different way: by the Danny> directory location where files are being read. Then you can use a Danny> temporary directory for your unit tests, and prepare the testing Danny> environment that way. If you take this approach, the tempfile module Danny> can help with this. Danny> Danny> https://docs.python.org/3.5/library/tempfile.html Danny> https://docs.python.org/3.5/library/tempfile.html#tempfile.TemporaryDirectory Danny> Alan>> > Danny has shown you one way using a mocked filesystem. Alan>> > But for your case can't you just specify a file location Alan>> > as an environment variable or argv? That way you get the Alan>> > advantage of using real files, which can be an important Alan>> > factor in timing issues, especially if you plan on having Alan>> > any concurrency going on. And it's simple to do... Matt>I would be tempted to generate a 'test data.CSV" file, and run the Matt>tests on that. It means that as you write the code, and find some Matt>edge cases, you can alter your code and add the edge cases to the Matt>test data. That way, the test data acts to cover the space of Matt>various oddities in your work. I'll add one option to the mix, and summarize the other options I saw listed earlier. Option A (tempfile): Create a directory and copy your pristine tree into the directory and make the base directory for the important data files configurable. Also known as parameterization. Option B (starting with Danny's sample code) Create the objects to emulate whatever filesystem behaviour you need. Option C (use pyfakefs): Use pyfakefs, which acts like a filesystem for testing purposes. https://pypi.python.org/pypi/pyfakefs https://github.com/jmcgeheeiv/pyfakefs Option D (use StringIO): If you are less concerned about filesystem interactions and really just want an individual thingy that that behaves like a file, but can be constructed in memory, use StringIO (or cStringIO). Good luck! -Martin -- Martin A. Brown http://linux-ip.net/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How do I test file operations (Such as opening, reading, writing, etc.)?
On Wed, Jan 27, 2016 at 11:24 PM, Danny Yoo wrote:
> You can make the file input/output interface a parameter of your editor.
>
> ###
> class Editor(object):
> def __init__(self, filesystem):
> self.filesystem = filesystem
> ...
>
>
> Since it's an explicit parameter, we can pass in either something that
> does it "for real" by using the built-in input output functions, or we
> can "fake it", by providing something that's convenient for unit
> tests.
>
>
> What do we need out of an input/output interface? Well, maybe a few
> basic operations. Let's say that we need to be able to do two things:
>
>
> 1. Open files, which returns a "filelike" object. If it can't
> find the file, let's have it raise an IOError.
>
> 2. Create new files, which returns a "filelike" object.
>
> This is admittedly bare-bones, but let's demonstrate what this might
> look like. First, let's see what a real implementation might look
> like:
>
>
> class RealFilesystem(object):
> def __init__(self):
> pass
>
> def open(self, filename):
> return open(filename, 'r')
>
> def create(self, filename):
> return open(filename, 'w')
>
>
> where we're just delegating the methods here to use the built-in
> open() function from Python's standard library.
>
> If we need to construct an editor that works with the real file
> system, that's not too bad:
>
> editor = Editor(filesystem=RealFilesystem())
I was already planning on designing a class to handle my program's
file I/O. I will probably need to add an append method, too. Thanks
for giving my a sound starting point!
> Now what about a test-friendly version of this? This actually isn't
> bad either; we can make judicious use of the StringIO class, which
> represents in-memory streams:
>
> ###
> from StringIO import StringIO
>
> class FakeFilesystem(object):
> """Simulate a very simple filesystem."""
> def __init__(self):
> self.filecontents = {}
>
> def _open_as_stringio(self, filename):
> filelike = StringIO(self.filecontents[filename])
> real_close = filelike.close
> def wrapped_close():
> self.filecontents[filename] = filelike.getvalue()
> real_close()
> filelike.close = wrapped_close
> return filelike
>
> def open(self, filename):
> if filename in self.filecontents:
> return self._open_as_stringio(filename)
> else:
> raise IOError, "Not found"
>
> def create(self, filename):
> self.filecontents[filename] = None
> return self._open_as_stringio(filename)
>
>
> (I'm using Python 2.7; if you're on Python 3, substitute the initial
> import statement with "from io import StringIO").
I was just scanning the docs on io. A note relevant to IOError:
"Changed in version 3.3: Operations that used to raise IOError now
raise OSError, since IOError is now an alias of OSError."
> This is a class that will look approximately like a filesystem,
> because we can "create" and "open" files, and it'll remember. All of
> this is in-memory, taking advantage of the StringIO library. The
> "tricky" part about this is that we need to watch when files close
> down, because then we have to record what the file looked like, so
> that next time we open the file, we can recall it.
>
>
> Let's see how this works:
>
>
fs = FakeFilesystem()
fs.open('hello')
> Traceback (most recent call last):
> File "", line 1, in
> File "fake_filesystem.py", line 21, in open
> raise IOError, "Not found"
> IOError: Not found
h = fs.create('hello')
h.write('hello world')
h.close()
h2 = fs.open('hello')
h2.read()
> 'hello world'
h2.close()
>
I will need to read the io docs in detail, but I am wondering if the
"with open ..." context manager is still usable to handle simulated
file closing using this technique?
> So for our own unit tests, now we should be able to say something like this:
>
> ##
> def test_foobar(self):
> fs = FakeFileSystem()
> fs.filecontents['classifiers.txt'] = """
> something here to test what happens when classifiers exists.
> """
> e = Editor(filesystem=fs)
> # ... fill me in!
> ##
You have given me a substantial hunk of meat to chew on, Danny! Thank
you very much for your lucid explanation and examples!! You have
given me a very solid starting point if I choose this route. I may
very well need to experiment with all of the approaches mentioned in
this thread. Much to learn!
--
boB
___
Re: [Tutor] How do I test file operations (Such as opening, reading, writing, etc.)?
On Thu, Jan 28, 2016 at 2:44 AM, Alan Gauld wrote: > Danny has shown you one way using a mocked filesystem. > But for your case can't you just specify a file location > as an environment variable or argv? That way you get the > advantage of using real files, which can be an important > factor in timing issues, especially if you plan on having > any concurrency going on. And it's simple to do... This type of approach was actually what first popped into my head. It is partially why I set up my project structure as grammar/grammar and grammar/test, where my actual program code would be under grammar. I thought this way I could have an identically structured data/ folder under both grammar/ and test/. But it was not coming to me how to set up class Editor(), so that it would seamlessly access the *correct* filesystem, depending on whether I was running program code or test code. But amongst all the things Danny clarified, he really helped me see how to do this in the context of writing classes. But in choosing what approach to use, I had not considered the possible importance of using real files in some instances, which you allude to. Thanks! boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How do I test file operations (Such as opening, reading, writing, etc.)?
On Thu, Jan 28, 2016 at 4:14 PM, Alan Gauld wrote: > On 28/01/16 20:03, Danny Yoo wrote: >> (Aside: this is somewhat why I think the topic of inheritance and >> inheritance >> hierarchies are entirely the wrong things to focus on when we're >> teaching OOP. > > Absolutely. > I always try to focus on the objects passing, and responding to, *messages* > as the key feature. Inheritance is a convenience, often abused to do code > reuse. The thing to focus on is polymorphism which just happens to be > implemented by inheritance heirarchies in most languages (although > not in python!) I'll ask you the same question that I asked Danny: Do you have a favorite text which teaches OOP the way you feel it should be taught? And if possible, Python-based? boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How do I test file operations (Such as opening, reading, writing, etc.)?
On Thu, Jan 28, 2016 at 5:09 PM, Martin A. Brown wrote: > I'll add one option to the mix, and summarize the other options I saw listed > earlier. > > Option A (tempfile): > > Create a directory and copy your pristine tree into the directory > and make the base directory for the important data files configurable. > Also known as parameterization. > > Option B (starting with Danny's sample code) > > Create the objects to emulate whatever filesystem behaviour you need. > > Option C (use pyfakefs): > > Use pyfakefs, which acts like a filesystem for testing purposes. > https://pypi.python.org/pypi/pyfakefs > https://github.com/jmcgeheeiv/pyfakefs > > Option D (use StringIO): > > If you are less concerned about filesystem interactions and really > just want an individual thingy that that behaves like a file, but > can be constructed in memory, use StringIO (or cStringIO). Isn't option D what Danny was using to make option B? Or are you saying keep things even simpler? boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How do I test file operations (Such as opening, reading, writing, etc.)?
Hello there, >> I'll add one option to the mix, and summarize the other options I saw listed >> earlier. >> >> Option A (tempfile): >> >> Create a directory and copy your pristine tree into the directory >> and make the base directory for the important data files configurable. >> Also known as parameterization. >> >> Option B (starting with Danny's sample code) >> >> Create the objects to emulate whatever filesystem behaviour you need. >> >> Option C (use pyfakefs): >> >> Use pyfakefs, which acts like a filesystem for testing purposes. >> https://pypi.python.org/pypi/pyfakefs >> https://github.com/jmcgeheeiv/pyfakefs >> >> Option D (use StringIO): >> >> If you are less concerned about filesystem interactions and really >> just want an individual thingy that that behaves like a file, but >> can be constructed in memory, use StringIO (or cStringIO). > >Isn't option D what Danny was using to make option B? Or are you >saying keep things even simpler? Oh dear--yes. Apologies, Danny and boB. To the doghouse with me. -Martin -- Martin A. Brown http://linux-ip.net/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] How do I test file operations (Such as opening, reading, writing, etc.)?
On Thu, Jan 28, 2016 at 2:03 PM, Danny Yoo wrote: > Just to emphasize what I think is an essential point: the basic > approach we're doing is here parameterization: to take something that > used to be hardcoded, and turn it into a parameter that allows us to > substitute with something else. Thank you for the correct term for the idea I have been gradually trying to understand better and implement. Work has been slow the past couple of weeks, so I have been trying to rework the last large project I wrote within the past year to make it capable of evaluating a broader range of treatment plans. Even though I wrote this less than a year ago, I am now seeing so many ways I can improve the readability, compactness and efficiency with what I have learned since. Even though this was a strictly procedural program, I have found that many of my functions can be rewritten to handle more than what I originally intended. This parameterization you speak of has allowed me to eliminate several similar functions by generalizing certain things that behave similarly. And I am sure that I am missing other opportunities for doing this! > ...When we program, we find > that domain of values expanded to a richer set, and not just to > inactive values like strings or dictionaries or images, but now we can > pass entire collections of behavior as a parameter. That's one of the > lessons of OOP: values are not just inert data: they can define > dynamic behavior. I am only now beginning to speculate on these new possibilities that this paradigm may enable. How *mere* bits can be assembled into ever more complex, but coherent structures that can do so much continues to astound me. Old hat for you experts, but exciting new ground for me! > (Aside: this is somewhat why I think the topic of inheritance and > inheritance hierarchies are entirely the wrong things to focus on when > we're teaching OOP. Those topics are often used as a shortcut > mechanism to do code sharing, and although that's convenient, my > opinion is that it misses the forest for the trees. What I think > OOP's heart is beating is in the ability to parameterize behavior.) In response to your aside, do you have a favorite text that teaches OOP the way you feel it should be taught? And is there a Python-based version? -- boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
[Tutor] [ANN] Gajja 0.1 (was: How do I test file operations (Such as opening, reading, writing, etc.)?)
Ben Finney writes: > I have today published a different approach, which I designed for one > code base ad is to date its only user. I'm looking for more feedback. > > https://pypi.python.org/pypi/gajja/> I forgot to mention the appropriate channels for feedback: Please contact me at if you have feedback on this, or report an issue at the project's homepage https://notabug.org/bignose/python-gajja>. You can also discuss this on the thread I've opened at the main Python forum https://mail.python.org/mailman/listinfo/python-list>. -- \ “That's all very good in practice, but how does it work in | `\ *theory*?” —anonymous | _o__) | Ben Finney ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
