probably weird or stupid newbie dictionary question

[hawkmoon269]

I've read in several places that a Python dictionary is analagous to
some other languages' hash table (Perl's, for instance).  But FMU a
dictionary's keys are *themselves* hashed so that a hash table exists
that maps hashed key values to keys in the dictionary.  ISTM, then,
that the analogy is at least somewhat faulty...except for the fact that
a dictionary's keys could themselves be hashed redundantly...i.e., the
values to be used as keys could be hashed, inserted into the dictionary
(and mapped to their values, of course), and they would then be hashed
(again) behind the scenes...IOW, ISTM that a dictionary is correctly
understood generally as a mapping (as documentation indicates) and
*could* be understood as a special case hash table itself...Is that
accurate?

h

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: probably weird or stupid newbie dictionary question

[hawkmoon269]

That makes sense.  Thanks. :-)

h

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: probably weird or stupid newbie dictionary question

[hawkmoon269]

Very.  Thanks much. :-)

h

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ftp

[hawkmoon269]

It turns out that the retrlines method strips of EOL CRLF and \n.  My
solution was to create a new method in ftplib that doesn't do this.
I'm assuming that there is a better OOP solution to this, e.g. some
kind of subclassing, but do not have the expertise as yet to implement
that.  At any rate, just thought I'd post in case others encountered
the same issue.  Incidentally, though, I'm wondering about the slightly
different transfer results.  Specifically, when I use DOS, the file
transfers like this --

string, string, string (hidden CRLF)
string, string, string (hidden CRLF)
...

but when I use Python in transfers like this --

string, string, string (hidden CRLF) string, string, string (hidden
CRLF).

If it's not obvious, the source file (sitting on a mainframe somewhere)
is in comma-delimited format.

As it is now, I've coded an Access application to automatically
"import" the file, clean it for my purposes, and "export" it's contents
appropriately etc.  But for whatever reason the import wizard inserts a
blank record for each CRLF.  When I use DOS and get the format
indicated above, this doesn't occur.  Any ideas as to how I could
resolve this?  It's not a big deal as I can just have Access refuse to
import blank lines.  However, the general procedure does take longer to
execute etc

hawk

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ftp

[hawkmoon269]

I just wanted to indicate that a carriage return is present but not
visible.

hawk

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ftp

[hawkmoon269]

That's a good idea.  Thanks! :-)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ftp

[hawkmoon269]

Just implemented the latter and works beautifully! ...even resolved my
other issue.  Thanks again. :-).

-- 
http://mail.python.org/mailman/listinfo/python-list

ftp

[hawkmoon269]

I would like to write a small ftp script that I could use in place of
DOS.  So far I have this --

from ftplib import FTP

server = 'xxx'
username = 'xxx'
password = 'xxx'
file = 'xxx'

ftp = FTP(server)
ftp.login(username, password)
ftp.retrlines('RETR ' + file, open('C:\My Documents\' + file,
'w').write

but this just writes the source files contents into a giant string in
the output file.  The source file is comma-delimited with a
fixed-length of 80 chars per line.  I need the same format for the
output file.  I've tried this --

ftp.retrlines('RETR ' + file, open('C:\My Documents\' + file,
'w').write('\n')

and that gives the correct output format...but it writes the output to
the IDE interpreter command line and not the file.  What am I doing
wrong?

hawk

-- 
http://mail.python.org/mailman/listinfo/python-list