[Tutor] Tutor Digest, Vol 81, Issue 48

marupalli charan marupalli.charan at gmail.com
Fri Nov 12 10:08:41 CET 2010


Re:please, send me programms as a file ( like "word.py" ) for easy
understanding of the programmes.

On 11/12/10, tutor-request at python.org <tutor-request at python.org> wrote:
> Send Tutor mailing list submissions to
> 	tutor at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mail.python.org/mailman/listinfo/tutor
> or, via email, send a message with subject or body 'help' to
> 	tutor-request at python.org
>
> You can reach the person managing the list at
> 	tutor-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tutor digest..."
>
>
> Today's Topics:
>
>    1. Re: A deeper explanation of ability to modify list elements
>       in-place (Steven D'Aprano)
>    2. Re: Creating one file out of all the files in a directory
>       (Kushal Kumaran)
>    3. Re: A deeper explanation of ability to modify list elements
>       in-place (Serdar Tumgoren)
>    4. What is a "state variable"? (Richard D. Moores)
>    5. Re: What is a "state variable"? (Emile van Sebille)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 12 Nov 2010 04:41:34 +1100
> From: Steven D'Aprano <steve at pearwood.info>
> To: Python Tutor <Tutor at python.org>
> Subject: Re: [Tutor] A deeper explanation of ability to modify list
> 	elements in-place
> Message-ID: <4CDC2ACE.6030801 at pearwood.info>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Serdar Tumgoren wrote:
>
>> But I think I see your point. The list object behaves the same as the
>> objects stored inside the list.
>
> Er, surely not... the list object is a list, the objects inside the list
> are ints. They do not behave the same.
>
>
>  > In other words, the list object is a
>> reference to an ordered sequence of object references, and you're
>> operating
>> on those (referenced) objects rather than copies of the objects when you
>> iterate over the list. Is that correct? If so, no doubt there's a simpler
>> way to say all that?
>
> "A list is an ordered sequence of objects. When you iterate over the
> list, you see the contents of the list, not copies. Python never copies
> objects unless you explicitly tell it to."
>
>
>
> --
> Steven
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 11 Nov 2010 18:37:13 +0530
> From: Kushal Kumaran <kushal.kumaran at gmail.com>
> To: "Josep M. Fontana" <josep.m.fontana at gmail.com>, tutor at python.org
> Subject: Re: [Tutor] Creating one file out of all the files in a
> 	directory
> Message-ID: <1289480833.13521.5.camel at Nokia-N900>
> Content-Type: text/plain; charset="utf-8"
>
>
> ----- Original message -----
>> Hi,
>>
>> I'm trying to create a script to do the following. I have a directory
>> containing hundreds of text files. I need to create a single file with
>> the contents of all the files in the directory. Within that file,
>> though, I need to create marks that indicate the division between the
>> contents of each file that has wound up in that single file.
>>
>
> Your current code adds the marker line to the original files.  Is that
> intended?
>
> You can open the output file for writing by passing 'w' as the second
> argument to open.  You would do this before your directory-walking loop.
> Then when you read the contents of any file, just write to your output file
> as well, along with your marker line.
>
>> I got this far but I'm stumped to continue:
>>
>> ----------------- code--------
>> import os
>> path = '/Volumes/DATA/MyPath'
>> os.chdir(path)
>> file_names = glob.glob('*.txt')
>
> output_stream = open('outputfilename', 'w')
>
>> for subdir, dirs, files in os.walk(path):
>>? ? ? ?  for file in files:
>>? ? ? ? ? ? ? ?  f = open(file, 'r')
>>? ? ? ? ? ? ? ?  text = f.readlines()
>
> output_stream.writelines(text)
> output_stream.write('______\n')
>
>>? ? ? ? ? ? ? ?  f.close()
>>? ? ? ? ? ? ? ?  f = open(file, 'a')
>>? ? ? ? ? ? ? ?  f.write('\n\n' + '________________________________' +
>> '\n')
>>? ? ? ? ? ? ? ?  f.close()
>>
>
> output_stream.close()
>
>> ------------
>>
>> What's missing here is obvious. This iterates over all the files and
>> creates the mark for the division at the end of each file. There is
>> nothing, however, to pipe the output of this loop into a new file.
>> I've checked the different manuals I own plus some more on the
>> internet but I can't figure out how to do what's left.
>>
>> I could get by with a little help from my Tutor friends.
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://mail.python.org/pipermail/tutor/attachments/20101111/bdb2f06a/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 11 Nov 2010 14:21:22 -0500
> From: Serdar Tumgoren <tumgorenz at washpost.com>
> To: "Steven D'Aprano" <steve at pearwood.info>
> Cc: Python Tutor <Tutor at python.org>
> Subject: Re: [Tutor] A deeper explanation of ability to modify list
> 	elements	in-place
> Message-ID:
> 	<AANLkTikupHQzcu-mgy1h7ozPSFSuxRa59gNc27yvq2Ap at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> First off, thanks for the detailed response! I had a few follow-up questions
> below, if you're willing to indulge. Feel free to direct me to RTM some
> books on C and the python source code, of course :)
>
>
>> Why? Because the designer of Python, Guido van Rossum, wanted it to be
>> possible, and he designed the language so that it would be.
>>
>> Do you perhaps mean *how* is it possible?
>>
> Yes indeed, I suppose that is really what I was asking.
>
>
>>
>> The use of pointers is an implementation detail for efficiency, and it
>> refers to how Python's object model is implemented in C.
>>
>> It is important not to lose sight of the distinction between the semantics
>> of Python objects themselves, and the way that those objects are
>> implemented
>> in lower-level languages such as C.
>>
>> In Python, if you have x[0] = Dummy(), the list object x stores the Dummy
>> instance itself.
>
>
> I think the above example gets to the source of my confusion. Clearly the
> instance remains accessible via x[0], but I somehow never thought of a
> specific list index as an obvious "symbol" for -- or reference to -- an
> instance. I suspect that my confusion stems from the day-to-day routine of
> instantiating an object and assigning it to a variable at the same time,
> often inside a loop, and then performing additional processing on this
> instance *before* storing it in a list or some other container.
>
> Above, it seems that you're *still* performing simultaneous instantiation
> and assignment (from a code perspective), but the "symbol" that you're
> assigning to is the list index itself.
>
> And that seems to explain why the Dummy instance remains accessible and is
> not garbage-collected. Is that a correct understanding?
>
>
>> That's what the code *means* -- create an instance of the Dummy class and
>> store it in the list x. But of course for efficiency reasons, and ease of
>> programming, the most obvious implementation will be to place the instance
>> in the heap somewhere, and keep a pointer to it in the list. How else
>> could
>> you do it? You could store the entire object in the list, but that would
>> be
>> terribly inefficient.
>
>
>
> But it could be done -- you could, with difficulty, implement Python in a
>> language like Fortran 77 (which has no dynamic memory allocation, and
>> therefore no pointers), or in Haskell, which is purely functional. Or you
>> could come up with a (slow, inefficient) implementation which moved around
>> large instance objects instead of small pointers.
>
>
> There is no way to get access to the underlying pointers from pure Python
>> code. From pure Python, pointers don't exist -- Python gives you no way to
>> create or access pointers from Python code. All you have access to is
>> objects.
>
>
> So is a reference simply a Python-level symbol (ie some collections of
> characters accessible from Python code) that corresponds to a pointer, which
> in turn points to the location in memory where the object is stored?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://mail.python.org/pipermail/tutor/attachments/20101111/c82423e5/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 11 Nov 2010 12:11:34 -0800
> From: "Richard D. Moores" <rdmoores at gmail.com>
> To: tutor at python.org
> Subject: [Tutor] What is a "state variable"?
> Message-ID:
> 	<AANLkTikXjiusj5pnKEqyYWW_pLj5iMs_UgjTNXG=LfE- at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> The term comes up in the 2nd section of
> <http://personalpages.tds.net/~kent37/stories/00014.html>
>
> <http://en.wikipedia.org/wiki/State_%28computer_science%29> didn't help.
>
> k = 23
>
> Is k then a state variable in that its state is 23? What sorts of
> variables are, and are not, state variables?
>
> The concept of a state variable seems central to Kent's article. If
> only I knew exactly what it was.
>
> Thanks,
>
> Dick Moores
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 11 Nov 2010 13:22:25 -0800
> From: Emile van Sebille <emile at fenx.com>
> To: tutor at python.org
> Subject: Re: [Tutor] What is a "state variable"?
> Message-ID: <ibhmqi$t3r$2 at dough.gmane.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 11/11/2010 12:11 PM Richard D. Moores said...
>> The term comes up in the 2nd section of
>> <http://personalpages.tds.net/~kent37/stories/00014.html>
>>
>> <http://en.wikipedia.org/wiki/State_%28computer_science%29>  didn't help.
>>
>> k = 23
>>
>> Is k then a state variable in that its state is 23? What sorts of
>> variables are, and are not, state variables?
>>
>> The concept of a state variable seems central to Kent's article. If
>> only I knew exactly what it was.
>
>
>  From the article,
>
> "A class is a container for shared state, combined with functions
> (methods) that operate on that state. By putting state variables into
> member fields, they are accessible to all the methods of the class
> without having to be passed as parameters."
>
> So, by his own definition state variables are parameters.
>
> Emile
>
>
>
> ------------------------------
>
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
>
>
> End of Tutor Digest, Vol 81, Issue 48
> *************************************
>


More information about the Tutor mailing list