Re: Can't get sqlite3.Row working: keyword lookup doesn't work
lgabiot wrote:
> using Python 2.7.6
>
> I try to access a sqlite database using keyword lookup instead of
> position (much more easy to maintain code), but it always fail, with the
> error:
> Index must be int or string
>
> I have created the database, populated it, and here is the code that
> tries to retrieve the information:
>
> with sqlite3.connect(mydbPath) as db: # open the database
> db.row_factory = sqlite3.Row
> cursor = db.cursor()
> cursor.execute("SELECT * FROM files")
>
> for row in cursor.fetchall():
> print(row.keys())
> print(row["filename"])
>
>
> result is:
>
> ['filename', 'filepath', 'filetag', 'PROJECT', 'SCENE', 'TAKE', 'TAPE',
[...]
> 'is_cantar', 'is_sound_devices', 'exist']
>
> error => Index must be int or string
Please remember to cut and past the traceback next time.
> What is wrong?
My crystal ball says that you have a
from __future__ import unicode_literals
statement at the beginning of the module. If I'm right try
row[b"filename"]
--
https://mail.python.org/mailman/listinfo/python-list
Re: Python declarative
On Sunday, January 26, 2014 10:53:32 AM UTC+5:30, Chris Angelico wrote: > On Sun, Jan 26, 2014 at 3:47 PM, Rustom Mody wrote: > > On Sunday, January 26, 2014 9:36:15 AM UTC+5:30, Chris Angelico wrote: > >> Code isn't something to be afraid of. It's just text files like any > >> other. After all, Python code is a config file for /usr/bin/python, so > >> if you want to change what Python does, just edit its config file! > > Windows stores configuration in the registry -- by fiat > > Linux (posix) stores configuration in /etc + ~/.files -- by convention > > Which do you think is preferable? > Not exclusively, in either case. Many many things are config files of > various sorts. The terms of the GPL specifically state that a GPL'd > language does not enforce that code written in it is GPL'd, because > it's just (to the GPL code) data files. Ok so you are being careful and hedging your bets!! [And Ive no idea what the gpl has to do with this] If you see the 'Principle of Least Power here: http://www.w3.org/DesignIssues/Principles.html there is a spectrum of power from narrow data format to universal data format to Turing complete programming language. And a strong case is made for minimizing the 'power' in any application. By decreeing things about the registry, windows solves many problems that create unnecessary headaches for developers, packagers, uses with the laissez-faire approach of 'put whatever you like in /etc.' This follows from the principle: "Anything goes" applied to /etc means messes go in. Its harder to push messes into a dictat-ed registry Steven's link http://www.codinghorror.com/blog/2008/05/xml-the-angle-bracket-tax.html linked to http://nothing-more.blogspot.in/2004/10/where-xml-goes-astray.html explains what the real problem is: Xml, originally a document format, is nowadays used as a data-format. This conduces to humongous messing, first for the xml-library writers, and thence to the users of those libraries because library messes inevitably leak past abstraction barriers to cause user-programmer headaches. tl;dr Frank's principle: "Express little as possible in " is correct. "And therefore XML is the solution" is bad logic [Unless == "java" !] -- https://mail.python.org/mailman/listinfo/python-list
Re: Python declarative
"Rustom Mody" wrote in message news:3683cd10-592b-4a3d-ba77-b963a1aa2...@googlegroups.com... > > Xml, originally a document format, is nowadays used as a data-format. > This conduces to humongous messing, first for the xml-library writers, and > thence to the users of those libraries because library messes inevitably > leak past abstraction barriers to cause user-programmer headaches. > > tl;dr > Frank's principle: "Express little as possible in " > is correct. > "And therefore XML is the solution" > is bad logic > [Unless == "java" !] If that is the case, what is 'good logic'? JSON or YAML? It does not make much difference which format I use. However, I will say that I found it a useful discipline to create an xml schema to describe my form definition, for two reasons. Firstly, I was hand-crafting my form definitions initially, and as I added features it became unwieldy. Forcing myself to create the schema highlighted a lot of anomalies and I ended up with a much cleaner structure as a result. Secondly, it has picked up a lot of errors in the resulting documents which would otherwise have generated hard-to-find runtime exceptions. Frank -- https://mail.python.org/mailman/listinfo/python-list
Python with 3d cartoon
Is it possible to write cartoon with 3D images using python? If yes , please locate me some resources. thank -- https://mail.python.org/mailman/listinfo/python-list
Re: Python with 3d cartoon
On 26/01/2014 10:46, ngangsia akumbo wrote: Is it possible to write cartoon with 3D images using python? If yes , please locate me some resources. thank What have you done to locate resources for yourself? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Python with 3d cartoon
On Sunday, January 26, 2014 11:55:34 AM UTC+1, Mark Lawrence wrote: > On 26/01/2014 10:46, ngangsia akumbo wrote: > > > > What have you done to locate resources for yourself? I have searched but not found something very clear. That is why i asked. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python declarative
On Sun, 26 Jan 2014 15:06:15 +1100, Chris Angelico wrote: > Code isn't something to be afraid of. Not according to the Laundry series by Charles Stross. The protagonist of the series was "recruited" to the Laundry after the computer program he was working on almost summoned Nyarlathotep the Crawling Chaos Elder God to Wolverhampton. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python declarative
On Sun, 26 Jan 2014 08:03:18 +0200, Frank Millman wrote: > I do not expect anyone to read or edit the XML - it is just a storage > format. I am sure it could be done in JSON or YAML as well. But that's not what you originally said. You stated: "here is how I would write your simple 'About' box" and compared your XML to actual code written by Chris. As I said in my previous post, if the XML is intended as a purely internal document, written by and read by your application, it's not so bad. (But then XML is intended for document *exchange*, i.e. from one application to another. If your XML is just used *internally*, with no interchange needed, why not use a more efficient internal format? XML's strength is that it is a well-known standard that allows application A to interchange documents with application B. But it's weaknesses include, it is neither efficient like a custom-designed binary format, not human-editable. It seems to me that if I were in your position, I would have the GUI designer generate source code in some language directly, rather than XML. Ah, wait! An idea strikes... if your GUI designer generates XML, you could then have a plug-in system to convert the XML to source code in whatever languages the plug-in supports. So that's a possible good use for XML as an intermediate language. > One objective is to make it easy for non-programmers to modify forms and > create new ones. I showed a screenshot earlier that illustrated a > 'button' definition. The idea of drag-and-drop GUI designers is hardly new. I was using one back in 1986 or '88, Apple's Hypercard. Now that was a user-friendly programming language/environment/toolkit. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Python with 3d cartoon
On 2014-01-26 02:46, ngangsia akumbo wrote: > Is it possible to write cartoon with 3D images using python? > > If yes , please locate me some resources. thank Check out Blender which can be scripted using Python. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Can't get sqlite3.Row working: keyword lookup doesn't work
Le 26/01/14 09:05, Peter Otten a écrit : Please remember to cut and past the traceback next time. What is wrong? My crystal ball says that you have a from __future__ import unicode_literals statement at the beginning of the module. If I'm right try row[b"filename"] Thanks a lot for your answer! your crystal ball was completely right, indeed I use the __future__ import, and the b'' fixed everything. Three days I was trying to get this... -- https://mail.python.org/mailman/listinfo/python-list
Re: Python declarative
On Sunday, January 26, 2014 2:42:57 PM UTC+5:30, Frank Millman wrote: > "Rustom Mody" wrote: > > Xml, originally a document format, is nowadays used as a data-format. > > This conduces to humongous messing, first for the xml-library writers, and > > thence to the users of those libraries because library messes inevitably > > leak past abstraction barriers to cause user-programmer headaches. > > tl;dr > > Frank's principle: "Express little as possible in " > > is correct. > > "And therefore XML is the solution" > > is bad logic > > [Unless == "java" !] > If that is the case, what is 'good logic'? JSON or YAML? > It does not make much difference which format I use. However, I will say > that I found it a useful discipline to create an xml schema to describe my > form definition, for two reasons. > Firstly, I was hand-crafting my form definitions initially, and as I added > features it became unwieldy. Forcing myself to create the schema highlighted > a lot of anomalies and I ended up with a much cleaner structure as a result. > Secondly, it has picked up a lot of errors in the resulting documents which > would otherwise have generated hard-to-find runtime exceptions. There are json/yaml 'schema'* validators if you want eg https://github.com/alecthomas/voluptuous http://rx.codesimply.com/ * if you want to call them that! -- https://mail.python.org/mailman/listinfo/python-list
SiafOO?
Today I stumbled upon www.siafoo.net when looking for tutorials on reStructured Text today. It looks like it could be good place to hang out to pick up programming skills (I am not in the positions help others, yet), is it? /Martin -- https://mail.python.org/mailman/listinfo/python-list
re Questions
Im pretty new to Python and understand most of the basics of Python re but am
stumped by a unexpected matching dynamics.
If I want to set up a match replicating the '\w' pattern I would assume that
would be done with '[A-z0-9_]'. However, when I run the following:
re.findall('[A-z0-9_]','^;z %C\@0~_') it matches ['^', 'z', 'C', '\\', '0',
'_']. I would expect the match to be ['z', 'C', '0', '_'].
Why does this happen?
Thanks in advance
Blake
--
https://mail.python.org/mailman/listinfo/python-list
Re: SiafOO?
On 26/01/2014 16:35, Martin Schöön wrote: Today I stumbled upon www.siafoo.net when looking for tutorials on reStructured Text today. It looks like it could be good place to hang out to pick up programming skills (I am not in the positions help others, yet), is it? /Martin "Have an unfortunate situation where you need to fit as much as you can in one expression?". "You've just saved a line of code and a variable name (for the function)." Not my cup of tea, but thank you anyway, YMMV. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: re Questions
On Sun, Jan 26, 2014 at 9:59 AM, Blake Adams wrote:
> Im pretty new to Python and understand most of the basics of Python re but am
> stumped by a unexpected matching dynamics.
>
> If I want to set up a match replicating the '\w' pattern I would assume that
> would be done with '[A-z0-9_]'. However, when I run the following:
>
> re.findall('[A-z0-9_]','^;z %C\@0~_') it matches ['^', 'z', 'C', '\\', '0',
> '_']. I would expect the match to be ['z', 'C', '0', '_'].
>
> Why does this happen?
Because the characters \ ] ^ and _ are between Z and a in the ASCII
character set.
You need to do this:
re.findall('[A-Za-z0-9_]','^;z %C\@0~_')
--
https://mail.python.org/mailman/listinfo/python-list
Re: re Questions
On Mon, Jan 27, 2014 at 3:59 AM, Blake Adams wrote:
> If I want to set up a match replicating the '\w' pattern I would assume that
> would be done with '[A-z0-9_]'. However, when I run the following:
>
> re.findall('[A-z0-9_]','^;z %C\@0~_') it matches ['^', 'z', 'C', '\\', '0',
> '_']. I would expect the match to be ['z', 'C', '0', '_'].
>
> Why does this happen?
Because \w is not the same as [A-z0-9_]. Quoting from the docs:
"""
\w For Unicode (str) patterns:Matches Unicode word characters; this
includes most characters that can be part of a word in any language,
as well as numbers and the underscore. If the ASCII flag is used, only
[a-zA-Z0-9_] is matched (but the flag affects the entire regular
expression, so in such cases using an explicit [a-zA-Z0-9_] may be a
better choice).For 8-bit (bytes) patterns:Matches characters
considered alphanumeric in the ASCII character set; this is equivalent
to [a-zA-Z0-9_].
"""
If you're working with a byte string, then you're close, but A-z is
quite different from A-Za-z. The set [A-z] is equivalent to
[ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz] (that's
a literal backslash in there, btw), so it'll also catch several
non-alphabetic characters. With a Unicode string, it's quite
distinctly different. Either way, \w means "word characters", though,
so just go ahead and use it whenever you want word characters :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: re Questions
In article , Chris Angelico wrote: > The set [A-z] is equivalent to > [ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz] I'm inclined to suggest the regex compiler should issue a warning for this. I've never seen a character range other than A-Z, a-z, or 0-9. Well, I suppose A-F or a-f if you're trying to match hex digits (and some variations on that for octal). But, I can't imagine any example where somebody wrote A-z and it wasn't an error. -- https://mail.python.org/mailman/listinfo/python-list
Re: re Questions
On Sunday, January 26, 2014 12:06:59 PM UTC-5, larry@gmail.com wrote:
> On Sun, Jan 26, 2014 at 9:59 AM, Blake Adams wrote:
>
> > Im pretty new to Python and understand most of the basics of Python re but
> > am stumped by a unexpected matching dynamics.
>
> >
>
> > If I want to set up a match replicating the '\w' pattern I would assume
> > that would be done with '[A-z0-9_]'. However, when I run the following:
>
> >
>
> > re.findall('[A-z0-9_]','^;z %C\@0~_') it matches ['^', 'z', 'C', '\\', '0',
> > '_']. I would expect the match to be ['z', 'C', '0', '_'].
>
> >
>
> > Why does this happen?
>
>
>
> Because the characters \ ] ^ and _ are between Z and a in the ASCII
>
> character set.
>
>
>
> You need to do this:
>
>
>
> re.findall('[A-Za-z0-9_]','^;z %C\@0~_')
Got it that makes sense. Thanks for the quick reply Larry
--
https://mail.python.org/mailman/listinfo/python-list
Re: re Questions
On Sunday, January 26, 2014 12:08:01 PM UTC-5, Chris Angelico wrote:
> On Mon, Jan 27, 2014 at 3:59 AM, Blake Adams wrote:
>
> > If I want to set up a match replicating the '\w' pattern I would assume
> > that would be done with '[A-z0-9_]'. However, when I run the following:
>
> >
>
> > re.findall('[A-z0-9_]','^;z %C\@0~_') it matches ['^', 'z', 'C', '\\', '0',
> > '_']. I would expect the match to be ['z', 'C', '0', '_'].
>
> >
>
> > Why does this happen?
>
>
>
> Because \w is not the same as [A-z0-9_]. Quoting from the docs:
>
>
>
> """
>
> \w For Unicode (str) patterns:Matches Unicode word characters; this
>
> includes most characters that can be part of a word in any language,
>
> as well as numbers and the underscore. If the ASCII flag is used, only
>
> [a-zA-Z0-9_] is matched (but the flag affects the entire regular
>
> expression, so in such cases using an explicit [a-zA-Z0-9_] may be a
>
> better choice).For 8-bit (bytes) patterns:Matches characters
>
> considered alphanumeric in the ASCII character set; this is equivalent
>
> to [a-zA-Z0-9_].
>
> """
>
>
>
> If you're working with a byte string, then you're close, but A-z is
>
> quite different from A-Za-z. The set [A-z] is equivalent to
>
> [ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz] (that's
>
> a literal backslash in there, btw), so it'll also catch several
>
> non-alphabetic characters. With a Unicode string, it's quite
>
> distinctly different. Either way, \w means "word characters", though,
>
> so just go ahead and use it whenever you want word characters :)
>
>
>
> ChrisA
Thanks Chris
--
https://mail.python.org/mailman/listinfo/python-list
Re: re Questions
On Mon, Jan 27, 2014 at 4:15 AM, Roy Smith wrote: > In article , > Chris Angelico wrote: > >> The set [A-z] is equivalent to >> [ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz] > > I'm inclined to suggest the regex compiler should issue a warning for > this. > > I've never seen a character range other than A-Z, a-z, or 0-9. Well, I > suppose A-F or a-f if you're trying to match hex digits (and some > variations on that for octal). But, I can't imagine any example where > somebody wrote A-z and it wasn't an error. I've used a variety of character ranges, certainly more than the 4-5 you listed, but I agree that A-z is extremely likely to be an error. However, I've sometimes used a regex (bytes mode) to find, say, all the ASCII printable characters - [ -~] - and I wouldn't want that precluded. It's a bit tricky trying to figure out which are likely to be errors and which are not, so I'd be inclined to keep things as they are. No warnings. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: re Questions
On 26/01/2014 17:15, Blake Adams wrote:
On Sunday, January 26, 2014 12:08:01 PM UTC-5, Chris Angelico wrote:
On Mon, Jan 27, 2014 at 3:59 AM, Blake Adams wrote:
If I want to set up a match replicating the '\w' pattern I would assume that
would be done with '[A-z0-9_]'. However, when I run the following:
re.findall('[A-z0-9_]','^;z %C\@0~_') it matches ['^', 'z', 'C', '\\', '0',
'_']. I would expect the match to be ['z', 'C', '0', '_'].
Why does this happen?
Because \w is not the same as [A-z0-9_]. Quoting from the docs:
"""
\w For Unicode (str) patterns:Matches Unicode word characters; this
includes most characters that can be part of a word in any language,
as well as numbers and the underscore. If the ASCII flag is used, only
[a-zA-Z0-9_] is matched (but the flag affects the entire regular
expression, so in such cases using an explicit [a-zA-Z0-9_] may be a
better choice).For 8-bit (bytes) patterns:Matches characters
considered alphanumeric in the ASCII character set; this is equivalent
to [a-zA-Z0-9_].
"""
If you're working with a byte string, then you're close, but A-z is
quite different from A-Za-z. The set [A-z] is equivalent to
[ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz] (that's
a literal backslash in there, btw), so it'll also catch several
non-alphabetic characters. With a Unicode string, it's quite
distinctly different. Either way, \w means "word characters", though,
so just go ahead and use it whenever you want word characters :)
ChrisA
Thanks Chris
I'm pleased to see that your question has been answered.
Now would you please read and action this
https://wiki.python.org/moin/GoogleGroupsPython to prevent us seeing the
double line spacing above, thanks.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
Re: re Questions
On 26/01/2014 17:25, Chris Angelico wrote: On Mon, Jan 27, 2014 at 4:15 AM, Roy Smith wrote: In article , Chris Angelico wrote: The set [A-z] is equivalent to [ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz] I'm inclined to suggest the regex compiler should issue a warning for this. I've never seen a character range other than A-Z, a-z, or 0-9. Well, I suppose A-F or a-f if you're trying to match hex digits (and some variations on that for octal). But, I can't imagine any example where somebody wrote A-z and it wasn't an error. I've used a variety of character ranges, certainly more than the 4-5 you listed, but I agree that A-z is extremely likely to be an error. However, I've sometimes used a regex (bytes mode) to find, say, all the ASCII printable characters - [ -~] - and I wouldn't want that precluded. It's a bit tricky trying to figure out which are likely to be errors and which are not, so I'd be inclined to keep things as they are. No warnings. ChrisA I suggest a single warning is always given "Regular expressions can be fickle. Have you considered using string methods?". My apologies to regex fans if they're currently choking over their tea, coffee, cocoa, beer, scotch, saki, ouzo or whatever :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Lists inside dictionary and how to look for particular value
z={ 'PC2': ['02:02:02:02:02:02', '192.168.0.2', '200'],
'PC3': ['03:03:03:03:03:03', '192.168.0.3', '200'],
'PC1': ['01:01:01:01:01:01', '192.168.0.1', '200'] }
My solution:
z=raw_input("Enter Host, Mac, ip and time")
t=z.split()
t[0]=z[1:]
for key in dic:
if t[2] in dic[key]:
del dic[t[0]]
else:
dic[t[0]] = t[1:]
What I really want to achieve is:
How to search for a particular value inside list. First, I want the user to
input hostname and ip. e.g. PC1 and 192.168.0.1, then need to find out if
192.168.0.1 has already been assigned to some host in dictionary. In this case
I would need to skip for search inside list of user input host.
Forexample, if user inputs PC1 and 192.168.0.1 i would like to skip searching
in above PC1's values. So it should detect matching only with different hosts
and skip its own name.
If i input PC4 and 192.168.0.1 then it should detect conflict with PC1. So PC4
would be deleted(As soon as user inputs new host it is saved in above database
then if conflict with others deleted)
--
https://mail.python.org/mailman/listinfo/python-list
Re: re Questions
On 2014-01-26 12:15, Roy Smith wrote:
> > The set [A-z] is equivalent to
> > [ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz]
>
> I'm inclined to suggest the regex compiler should issue a warning
> for this.
>
> I've never seen a character range other than A-Z, a-z, or 0-9.
> Well, I suppose A-F or a-f if you're trying to match hex digits
> (and some variations on that for octal). But, I can't imagine any
> example where somebody wrote A-z and it wasn't an error.
I'd not object to warnings on that one literal "A-z" set, but I've
done some work with VINs¹ where the allowable character-set is A-Z and
digits, minus letters that can be hard to distinguish visually
(I/O/Q), so I've used ^[A-HJ-NPR-Z0-9]{17}$ as a first-pass filter
for VINs that were entered (often scanned, but occasionally
hand-keyed). In some environments, I've been able to intercept I/O/Q
and remap them accordingly to 1/0/0 to do the disambiguation for the
user. So I'd not want to see other character-classes touched, as
they can be perfectly legit.
-tkc
¹ http://en.wikipedia.org/wiki/Vehicle_Identification_Number
--
https://mail.python.org/mailman/listinfo/python-list
Re: Lists inside dictionary and how to look for particular value
mick verdu wrote:
> z={ 'PC2': ['02:02:02:02:02:02', '192.168.0.2', '200'],
> 'PC3': ['03:03:03:03:03:03', '192.168.0.3', '200'],
> 'PC1': ['01:01:01:01:01:01', '192.168.0.1', '200'] }
>
> My solution:
>
> z=raw_input("Enter Host, Mac, ip and time")
> t=z.split()
> t[0]=z[1:]
> for key in dic:
> if t[2] in dic[key]:
> del dic[t[0]]
> else:
> dic[t[0]] = t[1:]
>
>
> What I really want to achieve is:
>
>
> How to search for a particular value inside list. First, I want the user
> to input hostname and ip. e.g. PC1 and 192.168.0.1, then need to find out
> if 192.168.0.1 has already been assigned to some host in dictionary. In
> this case I would need to skip for search inside list of user input host.
>
> Forexample, if user inputs PC1 and 192.168.0.1 i would like to skip
> searching in above PC1's values. So it should detect matching only with
> different hosts and skip its own name.
>
> If i input PC4 and 192.168.0.1 then it should detect conflict with PC1. So
> PC4 would be deleted(As soon as user inputs new host it is saved in above
> database then if conflict with others deleted)
You are making the problem unnecessarily complex. For the example scenario
start with a dict that maps host to ip:
host2ip = {
"PC1": "192.168.0.1",
"PC2": "192.168.0.2",
"PC3": "192.168.0.3",
}
host, ip = raw_input("Enter host and ip: ").split()
if host not in host2ip:
print "adding", host
host2ip[host] = ip
else:
old_ip = host2ip[host]
if old_ip == ip:
print "no changes necessary"
else:
print "updating ip for", host, "from", old_ip, "to", ip
host2ip[host] = ip
Then proceed and come up with an unambiguous description of what to do with
mac and time in plain english, and add or modify data structures as
necessary.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Lists inside dictionary and how to look for particular value
On 2014-01-26 10:47, mick verdu wrote:
> z={ 'PC2': ['02:02:02:02:02:02', '192.168.0.2', '200'],
> 'PC3': ['03:03:03:03:03:03', '192.168.0.3', '200'],
> 'PC1': ['01:01:01:01:01:01', '192.168.0.1', '200'] }
>
> My solution:
>
> z=raw_input("Enter Host, Mac, ip and time")
> t=z.split()
> t[0]=z[1:]
^
First, I don't think that this is doing what you want it to. I
suspect you want something like
data = {}
while True:
z = raw_input("Enter Host, Mac, IP and Time")
try:
host, mac, ip, time = z.split()
except ValueError:
print("Could not parse. Quitting")
break
existing = get_existing(data, mac, ip)
if existing:
print("%s/%s already exists as %s" % (
mac, ip, existing)
else:
data[host] = [mac, ip, time]
> How to search for a particular value inside list. First, I want the
> user to input hostname and ip. e.g. PC1 and 192.168.0.1, then need
> to find out if 192.168.0.1 has already been assigned to some host
> in dictionary. In this case I would need to skip for search inside
> list of user input host.
You have two main choices, depending on the size of the data and how
frequently you're running the queries:
1) you can search through the entire dataset every time for any sort
of match. If the list is reasonably small or you're not throwing
thousands of queries-per-second at it, this is insignificant and can
be pretty straight-forward:
def get_existing(data, mac, ip):
for hostname, (m, i, _) in data.items():
if mac == m or ip = i:
return hostname
return None
2) You can maintain separate data structures for the
reverse-mapping. This has a much faster lookup time at the cost of
more space and maintaining the reverse mappings. The whole thing
might look more like
ip_to_hostname = {}
mac_to_hostname = {}
data = {}
while True:
z = raw_input("Enter Host, MAC, IP and Time")
try:
host, mac, ip, time = z.split()[:4]
except ValueError:
print("Could not parse. Quitting")
break
if mac in mac_to_hostname:
print("MAC already exists as %s" % mac_to_hostname[mac])
elif ip in ip_to_hostname:
print("IP already exists as %s" % ip_to_hostname[ip])
# elif host in data:
# mac2, ip2, _ = data[host]
# if (mac, ip) != (mac2, ip2):
# print("Hostname already entered (%s/%s)" % (mac2, ip2))
else:
data[host] = [mac, ip, time]
ip_to_hostname[ip] = host
mac_to_hostname[mac] = host
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Lists inside dictionary and how to look for particular value
@Peter Otten: I have lists for keys. What I want is if host already exists it would overwrite otherwise add to database. And if host doesn't exist it will first add this host to database and then compare its IP with IPs of rest of hosts. If ip matches with any of the other hosts, it will delete the host that it just added now.I know it doesn't make sense but I need to do it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Lists inside dictionary and how to look for particular value
I have programming course and trying to learn things. This is of no human use. I am just following exercises. Just have to do steps as asked. -- https://mail.python.org/mailman/listinfo/python-list
Re: Lists inside dictionary and how to look for particular value
On Sun, 26 Jan 2014 10:47:11 -0800, mick verdu wrote:
> z={ 'PC2': ['02:02:02:02:02:02', '192.168.0.2', '200'],
> 'PC3': ['03:03:03:03:03:03', '192.168.0.3', '200'], 'PC1':
> ['01:01:01:01:01:01', '192.168.0.1', '200'] }
>
> My solution:
>
> z=raw_input("Enter Host, Mac, ip and time")
> t=z.split()
> t[0]=z[1:]
> for key in dic:
> if t[2] in dic[key]:
> del dic[t[0]]
> else:
> dic[t[0]] = t[1:]
>
>
> What I really want to achieve is:
>
>
> How to search for a particular value inside list. First, I want the user
> to input hostname and ip. e.g. PC1 and 192.168.0.1, then need to find
> out if 192.168.0.1 has already been assigned to some host in dictionary.
> In this case I would need to skip for search inside list of user input
> host.
>
> Forexample, if user inputs PC1 and 192.168.0.1 i would like to skip
> searching in above PC1's values. So it should detect matching only with
> different hosts and skip its own name.
>
> If i input PC4 and 192.168.0.1 then it should detect conflict with PC1.
> So PC4 would be deleted(As soon as user inputs new host it is saved in
> above database then if conflict with others deleted)
Can we step back a few stages.
What are you writing this software for? The network management at the
level you're trying to observe happens for the most part automatically at
the ip stack / network hardware level.
Do you think this database of which ip maps to which MAC is actually
going to have some human use? If so, what?
Or is this some sort of homework exercise as part of a programming course?
--
Denis McMahon, denismfmcma...@gmail.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: Lists inside dictionary and how to look for particular value
On 26/01/2014 20:28, mick verdu wrote: I have programming course and trying to learn things. This is of no human use. I am just following exercises. Just have to do steps as asked. A slightly OT observation... Mick, consider using more meaningful names than t,z etc. You know what they stand for now and you will remember them whilst you work on this task. But if you revisit the code in a few weeks, months etc. you'll have a hard job remembering what they stood for. -- https://mail.python.org/mailman/listinfo/python-list
Unwanted Spaces and Iterative Loop
I have been working on a python script that separates mailing addresses into
different components.
Here is my code:
inFile = "directory"
outFile = "directory"
inHandler = open(inFile, 'r')
outHandler = open(outFile, 'w')
outHandler.write("FarmID\tAddress\tStreetNum\tStreetName\tSufType\tDir\tCity\tProvince\tPostalCode")
for line in inHandler:
str = line.replace("FarmID\tAddress", " ")
outHandler.write(str[0:-1])
str = str.replace(" ","\t", 1)
str = str.replace(" Rd,","\tRd\t\t")
str = str.replace(" Rd","\tRd\t")
str = str.replace("Ave,","\tAve\t\t")
str = str.replace("Ave ","\tAve\t\t")
str = str.replace("St ","\tSt\t\t")
str = str.replace("St,","\tSt\t\t")
str = str.replace("Dr,","\tDr\t\t")
str = str.replace("Lane,","\tLane\t\t")
str = str.replace("Pky,","\tPky\t\t")
str = str.replace(" Sq,","\tSq\t\t")
str = str.replace(" Pl,","\tPl\t\t")
str = str.replace("\tE,","E\t")
str = str.replace("\tN,","N\t")
str = str.replace("\tS,","S\t")
str = str.replace("\tW,","W\t")
str = str.replace(",","\t")
str = str.replace(" ON","ON\t")
outHandler.write(str)
inHandler.close()
The text file that this manipulates has 91 addresses, so I'll just paste 5 of
them in here to get the idea:
FarmID Address
1 1067 Niagara Stone Rd, Niagara-On-The-Lake, ON L0S 1J0
2 4260 Mountainview Rd, Lincoln, ON L0R 1B2
3 25 Hunter Rd, Grimsby, ON L3M 4A3
4 1091 Hutchinson Rd, Haldimand, ON N0A 1K0
My issue is that in the output file, there is a space before each city and each
postal code that I do not want there.
Furthermore, the FarmID is being added on to the end of the postal code under
the original address column for each address. This also is not supposed to be
happening, and I am having trouble designing an iterative loop to
remove/prevent that from happening.
Any help is greatly appreciated!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unwanted Spaces and Iterative Loop
On 26/01/2014 21:46, matt.s.maro...@gmail.com wrote:
I have been working on a python script that separates mailing addresses into
different components.
Here is my code:
inFile = "directory"
outFile = "directory"
inHandler = open(inFile, 'r')
outHandler = open(outFile, 'w')
outHandler.write("FarmID\tAddress\tStreetNum\tStreetName\tSufType\tDir\tCity\tProvince\tPostalCode")
for line in inHandler:
str = line.replace("FarmID\tAddress", " ")
outHandler.write(str[0:-1])
str = str.replace(" ","\t", 1)
str = str.replace(" Rd,","\tRd\t\t")
str = str.replace(" Rd","\tRd\t")
str = str.replace("Ave,","\tAve\t\t")
str = str.replace("Ave ","\tAve\t\t")
str = str.replace("St ","\tSt\t\t")
str = str.replace("St,","\tSt\t\t")
str = str.replace("Dr,","\tDr\t\t")
str = str.replace("Lane,","\tLane\t\t")
str = str.replace("Pky,","\tPky\t\t")
str = str.replace(" Sq,","\tSq\t\t")
str = str.replace(" Pl,","\tPl\t\t")
str = str.replace("\tE,","E\t")
str = str.replace("\tN,","N\t")
str = str.replace("\tS,","S\t")
str = str.replace("\tW,","W\t")
str = str.replace(",","\t")
str = str.replace(" ON","ON\t")
outHandler.write(str)
inHandler.close()
The text file that this manipulates has 91 addresses, so I'll just paste 5 of
them in here to get the idea:
FarmID Address
1 1067 Niagara Stone Rd, Niagara-On-The-Lake, ON L0S 1J0
2 4260 Mountainview Rd, Lincoln, ON L0R 1B2
3 25 Hunter Rd, Grimsby, ON L3M 4A3
4 1091 Hutchinson Rd, Haldimand, ON N0A 1K0
My issue is that in the output file, there is a space before each city and each
postal code that I do not want there.
Furthermore, the FarmID is being added on to the end of the postal code under
the original address column for each address. This also is not supposed to be
happening, and I am having trouble designing an iterative loop to
remove/prevent that from happening.
Any help is greatly appreciated!
Make your life easier by using the csv module to read and write your
data, the write using the excel-tab dialect, see
http://docs.python.org/3/library/csv.html#module-csv
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
Help: python 3.3.3 (AMD64) scripts fail as non-admin user on Windows Server 2012 R2
I've installed python for all users with full permissions to all users (see picture). Python runs for all users. However, scripts only work when I run as Administrator. Running a script always results in an "ImportError: cannot import name" error. Here, for example, is the output of "pip -h" run as an unprivileged user: pip : Traceback (most recent call last): At line:1 char:1 + pip -h 2>&1 | Out-File -FilePath pip.txt + ~~~ + CategoryInfo : NotSpecified: (Traceback (most recent call last)::String) [], RemoteException + FullyQualifiedErrorId : NativeCommandError File "C:\Open\Python33\lib\runpy.py", line 160, in _run_module_as_main "__main__", fname, loader, pkg_name) File "C:\Open\Python33\lib\runpy.py", line 73, in _run_code exec(code, run_globals) File "C:\Open\Python33\Scripts\pip.exe\__main__.py", line 5, in ImportError: cannot import name main I get regular output when I run "pip -h" as Administrator: Usage: pip [options] Commands: install Install packages. uninstall Uninstall packages. freeze Output installed packages in requirements format. listList installed packages. showShow information about installed packages. search Search PyPI for packages. wheel Build wheels from your requirements. zip DEPRECATED. Zip individual packages. unzip DEPRECATED. Unzip individual packages. bundle DEPRECATED. Create pybundles. helpShow help for commands. General Options: -h, --help Show help. -v, --verbose Give more output. Option is additive, and can be used up to 3 times. -V, --version Show version and exit. -q, --quiet Give less output. --log-filePath to a verbose non-appending log, that only logs failures. This log is active by default at C:\Users\Safe Administrator\pip\pip.log. --log Path to a verbose appending log. This log is inactive by default. --proxy Specify a proxy in the form [user:passwd@]proxy.server:port. --timeout Set the socket timeout (default 15 seconds). --exists-action Default action when a path already exists: (s)witch, (i)gnore, (w)ipe, (b)ackup. --certPath to alternate CA bundle. I can't figure out the issue: please help! <>-- https://mail.python.org/mailman/listinfo/python-list
Re: Lists inside dictionary and how to look for particular value
mick verdu wrote: What I want is if host already exists it would overwrite otherwise add to database. And if host doesn't exist it will first add this host to database and then compare its IP with IPs of rest of hosts. If ip matches with any of the other hosts, it will delete the host that it just added now. It sounds like you should be maintaining two dictionaries: hostname --> IP (+ other host-related data) IP --> hostname Given a (newhost, newip) pair, first look for newip in the IP --> hostname dictionary. If it's there and the old hostname equals newhost, you're finished. If it's there with a different hostname, first delete that entry from IP --> hostname, and also delete the old hostname from hostname --> IP. Now add tne new entry to both dictionaries. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Unwanted Spaces and Iterative Loop
On 2014-01-26 21:46, matt.s.maro...@gmail.com wrote:
I have been working on a python script that separates mailing addresses into
different components.
Here is my code:
inFile = "directory"
outFile = "directory"
inHandler = open(inFile, 'r')
outHandler = open(outFile, 'w')
Shouldn't you be writing a '\n' at the end of the line?
outHandler.write("FarmID\tAddress\tStreetNum\tStreetName\tSufType\tDir\tCity\tProvince\tPostalCode")
for line in inHandler:
This is being done on every single line of the file:
str = line.replace("FarmID\tAddress", " ")
outHandler.write(str[0:-1])
str = str.replace(" ","\t", 1)
str = str.replace(" Rd,","\tRd\t\t")
str = str.replace(" Rd","\tRd\t")
str = str.replace("Ave,","\tAve\t\t")
str = str.replace("Ave ","\tAve\t\t")
str = str.replace("St ","\tSt\t\t")
str = str.replace("St,","\tSt\t\t")
str = str.replace("Dr,","\tDr\t\t")
str = str.replace("Lane,","\tLane\t\t")
str = str.replace("Pky,","\tPky\t\t")
str = str.replace(" Sq,","\tSq\t\t")
str = str.replace(" Pl,","\tPl\t\t")
str = str.replace("\tE,","E\t")
str = str.replace("\tN,","N\t")
str = str.replace("\tS,","S\t")
str = str.replace("\tW,","W\t")
str = str.replace(",","\t")
str = str.replace(" ON","ON\t")
outHandler.write(str)
inHandler.close()
The text file that this manipulates has 91 addresses, so I'll just paste 5 of
them in here to get the idea:
FarmID Address
1 1067 Niagara Stone Rd, Niagara-On-The-Lake, ON L0S 1J0
2 4260 Mountainview Rd, Lincoln, ON L0R 1B2
3 25 Hunter Rd, Grimsby, ON L3M 4A3
4 1091 Hutchinson Rd, Haldimand, ON N0A 1K0
My issue is that in the output file, there is a space before each city and each
postal code that I do not want there.
You could try splitting on '\t', stripping the leading and trailing
whitespace on each part, and then joining them together again with
'\t'. (Make sure that you also write the '\n' at the end of line.)
Furthermore, the FarmID is being added on to the end of the postal code under
the original address column for each address. This also is not supposed to be
happening, and I am having trouble designing an iterative loop to
remove/prevent that from happening.
Any help is greatly appreciated!
As Mark said, you could also use the CSV module.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Unwanted Spaces and Iterative Loop
>
>
> outHandler.write("FarmID\tAddress\tStreetNum\tStreetName\tSufType\tDir\tCity\tProvince\tPostalCode")
>
> ...
> FarmID Address
> 1 1067 Niagara Stone Rd, Niagara-On-The-Lake, ON L0S 1J0
> 2 4260 Mountainview Rd, Lincoln, ON L0R 1B2
> 3 25 Hunter Rd, Grimsby, ON L3M 4A3
> 4 1091 Hutchinson Rd, Haldimand, ON N0A 1K0
>
>
You are wanting to produce tab-separated output, with an "Address" field
plus the Address split into fields for Street Number, Street Name, Suffix
Type, Direction?
The four lines you have pasted are examples of your input? If yes,
"Direction" is a single letter?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Help: python 3.3.3 (AMD64) scripts fail as non-admin user on Windows Server 2012 R2
On Sun, 26 Jan 2014 17:30:21 -0500, Luis Marsano wrote: > I've installed python for all users with full permissions to all users > (see picture). > Python runs for all users. > However, scripts only work when I run as Administrator. Running a script > always results in an "ImportError: cannot import name" error. Here, for > example, is the output of "pip -h" run as an unprivileged user: This does not appear to be a Python problem. This appears to be a generic Windows permissions problem. My guess is that you've made sure that the Python .exe is executable by all users, but the standard library files are only readable by the Administrator user. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Lists inside dictionary and how to look for particular value
ThanK you. It solved my problem. Can someone tell me how can i print particular value inside list of key. I know how to print J['PC2'][1] means will print IP. but I want the user to input some element and I will print element just before that element. e.g. if user inputs 192.168.0.2, program will print 02:02:02:02:02:02. If user inputs 192.168.0.1 I will print 01:01:01:01:01:01. -- https://mail.python.org/mailman/listinfo/python-list
Re: Unwanted Spaces and Iterative Loop
On Sunday, 26 January 2014 18:44:16 UTC-5, Jason Friedman wrote:
> outHandler.write("FarmID\tAddress\tStreetNum\tStreetName\tSufType\tDir\tCity\tProvince\tPostalCode")
>
>
>
> ...
>
> FarmID Address
>
> 1 1067 Niagara Stone Rd, Niagara-On-The-Lake, ON L0S 1J0
>
> 2 4260 Mountainview Rd, Lincoln, ON L0R 1B2
>
> 3 25 Hunter Rd, Grimsby, ON L3M 4A3
>
> 4 1091 Hutchinson Rd, Haldimand, ON N0A 1K0
>
>
> You are wanting to produce tab-separated output, with an "Address" field
> plus the Address split into fields for Street Number, Street Name, Suffix
> Type, Direction?
>
>
>
> The four lines you have pasted are examples of your input? If yes,
> "Direction" is a single letter?
Yes to your first question. Yes, the four lines I have pasted are examples of
input. Direction is a single letter (there are some records that are `King St.
E,`). I have solved the problem with the spaces, but still cannot figure out
the iterative loop to get rid of the farm ID in the address column that isn`t
split.
--
https://mail.python.org/mailman/listinfo/python-list
Highlighting program variables instead of keywords?
My son sent me a link to an essay about highlighting program data instead of keywords: https://medium.com/p/3a6db2743a1e/ I think this might have value, especially if to could bounce back and forth between both schemes. Is anyone aware of tools like this for Python? Bonus points for pointers to an Emacs implementation. Thanks, Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Unwanted Spaces and Iterative Loop
On Sun, 26 Jan 2014 13:46:21 -0800, matt.s.marotta wrote:
> I have been working on a python script that separates mailing addresses
> into different components.
>
> Here is my code:
>
> inFile = "directory"
> outFile = "directory"
> inHandler = open(inFile, 'r')
> outHandler = open(outFile, 'w')
Are you *really* opening the same file for reading and writing at the
same time?
Even if your operating system allows that, surely it's not a good idea.
You might get away with it for small files, but at some point you're
going to run into weird, hard-to-diagnose bugs.
> outHandler.write("FarmID\tAddress\tStreetNum\tStreetName\tSufType\tDir
\tCity\tProvince\tPostalCode")
This looks like a CSV file using tabs as the separator. You really ought
to use the csv module.
http://docs.python.org/3/library/csv.html
http://docs.python.org/2/library/csv.html
http://pymotw.com/2/csv/
> for line in inHandler:
> str = line.replace("FarmID\tAddress", " ")
> outHandler.write(str[0:-1])
> str = str.replace(" ","\t", 1)
> str = str.replace(" Rd,","\tRd\t\t")
> str = str.replace(" Rd","\tRd\t")
> str = str.replace("Ave,","\tAve\t\t")
> str = str.replace("Ave","\tAve\t\t")
> str = str.replace("St ","\tSt\t\t")
> str = str.replace("St,","\tSt\t\t")
> str = str.replace("Dr,","\tDr\t\t")
[snip additional string manipulations]
> str = str.replace(",","\t")
> str = str.replace(" ON","ON\t")
> outHandler.write(str)
Aiy aiy aiy, what a mess! I get a headache just trying to understand it!
The first question that comes to mind is that you appear to be writing
each input line *twice*, first after a very minimal set of string
manipulations (you convert the literal string "FarmID\tAddress" to a
space, then write the whole line out), the second time after a whole mess
of string replacements. Why?
If the sample data you show below is accurate, I *think* what you are
trying to do is simply suppress the header line. The first line in the
input file is:
FarmID Address
and rather than write that you want to write a space. I don't know why
you want the output file to begin with a space, but this would be better:
for line in inHandler:
line = line.strip() # Remove any leading and trailing whitespace,
# including the trailing newline. Later, we'll add a newline
# back in.
if line == "FarmID\tAddress":
outHandler.write(" ") # Write a mysterious space.
continue # And skip to the next line.
# Now process the non-header lines.
Now, as far as the non-header lines, you do a whole lot of complex string
manipulations, replacing chunks of text with or without tabs or commas to
the same text with or without tabs but in a different order. The logic of
these manipulations completely escape me: what are you actually trying to
do here?
I *strongly* suggest that you don't try to implement your program logic
in the form of string manipulations. According to your sample data, your
data looks like this:
1 1067 Niagara Stone Rd, Niagara-On-The-Lake, ON L0S 1J0
i.e.
farmId TAB address COMMA district COMMA postcode
It is much better to pull the line apart into named components,
manipulate the components directly, then put it back together in the
order you want. This makes the code more understandable, and easier to
change if you ever need to change things.
for line in inHandler:
line = line.strip()
if line == "FarmID\tAddress":
outHandler.write(" ") # Write a mysterious space.
continue
# Now process the non-header lines.
farmid, address = line.split("\t")
farmid = farmid.strip()
address, district, postcode = address.split(",")
address = address.strip()
district = district.strip()
postcode = postcode.strip()
# Now process the fields however you like.
parts_of_address = address.split(" ")
street_number = parts_of_address[0] # first part
street_type = parts_of_address[-1] # last part
street_name = parts_of_address[1:-1] # everything else
street_name = " ".join(street_name)
and so on for the post code. Then, at the very end, assemble the parts
you want to write out, join them with tabs, and write:
fields = [farmid, street_number, street_name, street_type, ... ]
outHandler.write("\t".join(fields))
outHandler.write("\n")
Or use the csv module to do the actual writing. It will handle escaping
anything that needs escaping, newlines, tabs, etc.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Re: Highlighting program variables instead of keywords?
On 1/26/2014 7:31 PM, Skip Montanaro wrote: My son sent me a link to an essay about highlighting program data instead of keywords: https://medium.com/p/3a6db2743a1e/ What it is doing is color coding user-supplied identifiers, with different color for each one. I found that confusing to read. The only use I can see for this is to track the usage of a particular name, but that would be better done by just highlighting one name at a time. I think this might have value, especially if to could bounce back and forth between both schemes. Is anyone aware of tools like this for Python? Bonus points for pointers to an Emacs implementation. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Highlighting program variables instead of keywords?
On Mon, Jan 27, 2014 at 11:46 AM, Terry Reedy wrote: > The only use I can see for this is to track the usage of a particular name, > but that would be better done by just highlighting one name at a time. In SciTE, I can put the cursor on a word and hit Ctrl-F3 to find other instances of that word. If that's not enough, following it up with Ctrl-Home, F3 will find the first instance of it, and if the program follows the Define-Before-Use principle, that'll be the definition. That's usually enough. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Highlighting program variables instead of keywords?
On Mon, Jan 27, 2014 at 11:51 AM, Chris Angelico wrote: > On Mon, Jan 27, 2014 at 11:46 AM, Terry Reedy wrote: >> The only use I can see for this is to track the usage of a particular name, >> but that would be better done by just highlighting one name at a time. > > In SciTE, I can put the cursor on a word and hit Ctrl-F3 to find other > instances of that word. If that's not enough, following it up with > Ctrl-Home, F3 will find the first instance of it, and if the program > follows the Define-Before-Use principle, that'll be the definition. > That's usually enough. > > ChrisA That said, though, I grew up without syntax highlighting of any sort, and didn't think it particularly important; but now that I have editors with all those sorts of features, I do find them handy. So it's possible that a system like this would be of value if once the programmer gets used to it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Unwanted Spaces and Iterative Loop
On Sunday, 26 January 2014 19:40:26 UTC-5, Steven D'Aprano wrote:
> On Sun, 26 Jan 2014 13:46:21 -0800, matt.s.marotta wrote:
>
>
>
> > I have been working on a python script that separates mailing addresses
>
> > into different components.
>
> >
>
> > Here is my code:
>
> >
>
> > inFile = "directory"
>
> > outFile = "directory"
>
> > inHandler = open(inFile, 'r')
>
> > outHandler = open(outFile, 'w')
>
>
>
> Are you *really* opening the same file for reading and writing at the
>
> same time?
>
>
>
> Even if your operating system allows that, surely it's not a good idea.
>
> You might get away with it for small files, but at some point you're
>
> going to run into weird, hard-to-diagnose bugs.
>
>
>
>
>
> > outHandler.write("FarmID\tAddress\tStreetNum\tStreetName\tSufType\tDir
>
> \tCity\tProvince\tPostalCode")
>
>
>
> This looks like a CSV file using tabs as the separator. You really ought
>
> to use the csv module.
>
>
>
> http://docs.python.org/3/library/csv.html
>
> http://docs.python.org/2/library/csv.html
>
>
>
> http://pymotw.com/2/csv/
>
>
>
>
>
> > for line in inHandler:
>
> > str = line.replace("FarmID\tAddress", " ")
>
> > outHandler.write(str[0:-1])
>
> > str = str.replace(" ","\t", 1)
>
> > str = str.replace(" Rd,","\tRd\t\t")
>
> > str = str.replace(" Rd","\tRd\t")
>
> > str = str.replace("Ave,","\tAve\t\t")
>
> > str = str.replace("Ave","\tAve\t\t")
>
> > str = str.replace("St ","\tSt\t\t")
>
> > str = str.replace("St,","\tSt\t\t")
>
> > str = str.replace("Dr,","\tDr\t\t")
>
> [snip additional string manipulations]
>
> > str = str.replace(",","\t")
>
> > str = str.replace(" ON","ON\t")
>
> > outHandler.write(str)
>
>
>
>
>
> Aiy aiy aiy, what a mess! I get a headache just trying to understand it!
>
>
>
> The first question that comes to mind is that you appear to be writing
>
> each input line *twice*, first after a very minimal set of string
>
> manipulations (you convert the literal string "FarmID\tAddress" to a
>
> space, then write the whole line out), the second time after a whole mess
>
> of string replacements. Why?
>
>
>
> If the sample data you show below is accurate, I *think* what you are
>
> trying to do is simply suppress the header line. The first line in the
>
> input file is:
>
>
>
> FarmIDAddress
>
>
>
> and rather than write that you want to write a space. I don't know why
>
> you want the output file to begin with a space, but this would be better:
>
>
>
> for line in inHandler:
>
> line = line.strip() # Remove any leading and trailing whitespace,
>
> # including the trailing newline. Later, we'll add a newline
>
> # back in.
>
> if line == "FarmID\tAddress":
>
> outHandler.write(" ") # Write a mysterious space.
>
> continue # And skip to the next line.
>
> # Now process the non-header lines.
>
>
>
>
>
> Now, as far as the non-header lines, you do a whole lot of complex string
>
> manipulations, replacing chunks of text with or without tabs or commas to
>
> the same text with or without tabs but in a different order. The logic of
>
> these manipulations completely escape me: what are you actually trying to
>
> do here?
>
>
>
> I *strongly* suggest that you don't try to implement your program logic
>
> in the form of string manipulations. According to your sample data, your
>
> data looks like this:
>
>
>
> 1 1067 Niagara Stone Rd, Niagara-On-The-Lake, ON L0S 1J0
>
>
>
> i.e.
>
>
>
> farmId TAB address COMMA district COMMA postcode
>
>
>
> It is much better to pull the line apart into named components,
>
> manipulate the components directly, then put it back together in the
>
> order you want. This makes the code more understandable, and easier to
>
> change if you ever need to change things.
>
>
>
> for line in inHandler:
>
> line = line.strip()
>
> if line == "FarmID\tAddress":
>
> outHandler.write(" ") # Write a mysterious space.
>
> continue
>
> # Now process the non-header lines.
>
> farmid, address = line.split("\t")
>
> farmid = farmid.strip()
>
> address, district, postcode = address.split(",")
>
> address = address.strip()
>
> district = district.strip()
>
> postcode = postcode.strip()
>
> # Now process the fields however you like.
>
> parts_of_address = address.split(" ")
>
> street_number = parts_of_address[0] # first part
>
> street_type = parts_of_address[-1] # last part
>
> street_name = parts_of_address[1:-1] # everything else
>
> street_name = " ".join(street_name)
>
>
>
> and so on for the post code. Then, at the very end, assemble the parts
>
> you want to write out, join them with tabs, and write:
>
>
>
> fields = [farmid, street_number, street_name, street_type, ... ]
>
> outHandler
Re: Highlighting program variables instead of keywords?
On Sun, 26 Jan 2014 18:31:49 -0600, Skip Montanaro wrote: > My son sent me a link to an essay about highlighting program data > instead of keywords: > > https://medium.com/p/3a6db2743a1e/ > > I think this might have value, especially if to could bounce back and > forth between both schemes. Hmmm, I'm not convinced, but then I wasn't convinced by syntax highlighting either until I had used it for a while. (I still think it's a nice-to-have rather than a must-have.) Seems to me that beyond a dozen or so variables, the colours won't be distinctive enough to get much benefit. Especially if similar names get similar colours, e.g. the name "handle_process" and the typo "handle_prosess" will be barely distinguishable. In a well-designed program, most variables will appear in a fairly limited number of places, possibly in only a single function or method, so in even a fairly small project you might have a few dozen distinct variables, each of which might appear only three or five times. > Is anyone aware of tools like this for > Python? Bonus points for pointers to an Emacs implementation. Sorry, can't help you. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Highlighting program variables instead of keywords?
On Mon, Jan 27, 2014 at 12:29 PM, Steven D'Aprano wrote: > Hmmm, I'm not convinced, but then I wasn't convinced by syntax > highlighting either until I had used it for a while. (I still think it's > a nice-to-have rather than a must-have.) It's definitely just a nice-to-have. I've built miniature text editors into various programs (including two MUD clients, for the purpose of editing files on the server), and haven't bothered with the level of sophistication required for smart-indent, much less syntax highlighting. (I'll occasionally put in an auto-indent - hit enter and it indents to the same level as the previous line - but not even always that, and definitely not "hey, that line has more ( than ) so I'll indent an extra level", which is a *hugely* helpful feature when I'm doing main coding (it catches errors, as well as saving time on indentation), but one I can do without if it means I can knock together an editor in a tenth the time.) > Seems to me that beyond a dozen or so variables, the colours won't be > distinctive enough to get much benefit. Especially if similar names get > similar colours, e.g. the name "handle_process" and the typo > "handle_prosess" will be barely distinguishable. In a well-designed > program, most variables will appear in a fairly limited number of places, > possibly in only a single function or method, so in even a fairly small > project you might have a few dozen distinct variables, each of which > might appear only three or five times. Hmm. Would similar names get similar colours? I would guess that a naive approach would just go sequentially through the file, but if it's smart enough to recognize similarity, it'd be nice if it could then be smart enough to make them contrast. The more similar the words, the less similar the colours, and vice versa. Or at very least, sort all the words alphabetically, and then distribute them in some binary flip-flop method that will tend to put the ones with the same start further apart. (That would catch typos anywhere other than the beginning of the name.) Oh. Yes, they will get similar colours. Just re-read the page: """ Variable names with similar prefixes will be assigned similar colors. We collect all the custom names and order them alphabetically, then distributing them evenly along a spectrum. This way we make sure we use as distinct colors as possible. """ IMO this is a flawed design decision. The purpose of the color is to add information, not to replicate what's already there. (And it's using the simplistic method I described, of simply sorting alphabetically to determine similarity. There are other ways of distinguishing, but they're a lot more complicated.) If it's smart enough to recognize the difference between local and global names, that would be useful. Might not be so useful in JS, but definitely in Python. It would take a bit of smartness, but most editors these days have to be able to fully parse the language anyway. Hmm. Actually, this might be a plausible idea just on its own: never mind about distinguishing specific names, just create a highlight class for each of "local name" (including function parameters), "global name, read-only", and "global name, assigned to in this function", and possibly non-local (read-only and assigned) as well. If you suddenly see that the name 'len' has changed from being "global name, read-only" to "local name", you'll know instantly that you just shadowed a built-in (probably unintentionally and in a way likely to cause bugs). Do any editors currently offer this? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Highlighting program variables instead of keywords?
> What it is doing is color coding user-supplied identifiers, with different > color for each one. I found that confusing to read. I think it would take some time to get used to, and I don't think it would be the only way I'd like to view my program. I think an interactive pylint (or pyflakes or frosty) type capability would be useful, highlighting a subset of the messages it produces, like variables which were assigned but never used, or using undefined variables. It might be best supported by actually running the checker in the background, then using its messages to direct where to highlight suspect bits of code. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Unwanted Spaces and Iterative Loop
On Mon, Jan 27, 2014 at 12:15 PM, wrote: > I`m not reading and writing to the same file, I just changed the actual paths > to directory. For next time, say "directory1" and "directory2" to preserve the fact that they're different. Though if they're file names, I'd use "file1" and "file2" - calling them "directory" implies that they are, well, directories :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Unwanted Spaces and Iterative Loop
On Sunday, 26 January 2014 20:56:01 UTC-5, Chris Angelico wrote: > On Mon, Jan 27, 2014 at 12:15 PM, wrote: > > > I`m not reading and writing to the same file, I just changed the actual > > paths to directory. > > > > For next time, say "directory1" and "directory2" to preserve the fact > > that they're different. Though if they're file names, I'd use "file1" > > and "file2" - calling them "directory" implies that they are, well, > > directories :) > > > > ChrisA Thanks, but any chance you could help me out with my question of removing the FarmID from the postal code? -- https://mail.python.org/mailman/listinfo/python-list
Re: Unwanted Spaces and Iterative Loop
>
> I`m not reading and writing to the same file, I just changed the actual
> paths to directory.
>
> This is for a school assignment, and we haven`t been taught any of the
> stuff you`re talking about. Although I appreciate your help, everything
> needs to stay as is and I just need to create the loop to get rid of the
> farmID from the end of the postal codes.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
If you are allowed to use if/then this seems to work:
inFile = "data"
outFile = "processed"
inHandler = open(inFile, 'r')
outHandler = open(outFile, 'w')
for line in inHandler:
if line.startswith("FarmID"):
outHandler.write("FarmID\tAddress\tStreetNum\tStreetName\tSufType\tDir\tCity\tProvince\tPostalCode\n")
else:
line = line.replace(" ","\t", 1)
line = line.replace(" Rd,","\tRd\t\t")
line = line.replace(" Rd","\tRd\t")
line = line.replace("Ave,","\tAve\t\t")
line = line.replace("Ave ","\tAve\t\t")
line = line.replace("St ","\tSt\t\t")
line = line.replace("St,","\tSt\t\t")
line = line.replace("Dr,","\tDr\t\t")
line = line.replace("Lane,","\tLane\t\t")
line = line.replace("Pky,","\tPky\t\t")
line = line.replace(" Sq,","\tSq\t\t")
line = line.replace(" Pl,","\tPl\t\t")
line = line.replace("\tE,","E\t")
line = line.replace("\tN,","N\t")
line = line.replace("\tS,","S\t")
line = line.replace("\tW,","W\t")
line = line.replace(",","\t")
line = line.replace(" ON","ON\t")
outHandler.write(line)
inHandler.close()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Highlighting program variables instead of keywords?
Steven D'Aprano writes: > Hmmm, I'm not convinced, but then I wasn't convinced by syntax > highlighting either until I had used it for a while. (I still think > it's a nice-to-have rather than a must-have.) I wouldn't rate syntax highlighting a must-have. But I do think it's significantly more difficult to work with an editor that doesn't highlight the syntax of the code. > Seems to me that beyond a dozen or so variables, the colours won't be > distinctive enough to get much benefit. A more severe problem with the suggestion is that human cognition is only capable of attending to a limited number of differences at once, and so this kind of attention-drawing is a limited resource. Drawing attention to some aspects is at the expense of reduced attention to other aspects. The significant benefit of syntax highlighting is that it reduces the difficulty to read the text and see what will be obvious to the compiler: the structure of each statement and block. So spending the limited resource of differential attention to colours is valuable to help with this difficult aspect of reading code. So I strongly disagree with the statement “But as it stands, we highlight the obvious (like the word function) and leave most of the content in black.” Once you have attention on it, the word “function” is obvious. But the whole motivation of highlighting syntax using different colours is to get that differential attention in the first place. The difference between tokens *isn't* so obvious when glancing at the code without those colours. That said, the motivation in highlighting different names differently is a good one, too. I would like to have the benefit described in the article: having different names easily distinguished in the code. But I don't think that should come at the expense of significantly reducing the ease of quickly distinguishing the syntactical structure. -- \ “We must find our way to a time when faith, without evidence, | `\disgraces anyone who would claim it.” —Sam Harris, _The End of | _o__) Faith_, 2004 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Highlighting program variables instead of keywords?
In article , Chris Angelico wrote: > That said, though, I grew up without syntax highlighting of any sort, > and didn't think it particularly important; but now that I have > editors with all those sorts of features, I do find them handy. Same here, except I'd replace "find them handy" with "totally addicted to". -- https://mail.python.org/mailman/listinfo/python-list
Re: Unwanted Spaces and Iterative Loop
On Sunday, 26 January 2014 21:00:35 UTC-5, Jason Friedman wrote:
> I`m not reading and writing to the same file, I just changed the actual paths
> to directory.
>
>
>
> This is for a school assignment, and we haven`t been taught any of the stuff
> you`re talking about. Although I appreciate your help, everything needs to
> stay as is and I just need to create the loop to get rid of the farmID from
> the end of the postal codes.
>
>
> --
>
> https://mail.python.org/mailman/listinfo/python-list
>
>
>
> If you are allowed to use if/then this seems to work:
>
>
>
> inFile = "data"
>
> outFile = "processed"
> inHandler = open(inFile, 'r')
> outHandler = open(outFile, 'w')
>
> for line in inHandler:
> if line.startswith("FarmID"):
>
> outHandler.write("FarmID\tAddress\tStreetNum\tStreetName\tSufType\tDir\tCity\tProvince\tPostalCode\n")
>
> else:
> line = line.replace(" ","\t", 1)
> line = line.replace(" Rd,","\tRd\t\t")
>
> line = line.replace(" Rd","\tRd\t")
> line = line.replace("Ave,","\tAve\t\t")
> line = line.replace("Ave ","\tAve\t\t")
>
> line = line.replace("St ","\tSt\t\t")
> line = line.replace("St,","\tSt\t\t")
> line = line.replace("Dr,","\tDr\t\t")
>
> line = line.replace("Lane,","\tLane\t\t")
> line = line.replace("Pky,","\tPky\t\t")
>
> line = line.replace(" Sq,","\tSq\t\t")
> line = line.replace(" Pl,","\tPl\t\t")
>
>
>
> line = line.replace("\tE,","E\t")
> line = line.replace("\tN,","N\t")
> line = line.replace("\tS,","S\t")
>
> line = line.replace("\tW,","W\t")
> line = line.replace(",","\t")
> line = line.replace(" ON","ON\t")
>
>
>
> outHandler.write(line)
> inHandler.close()
Unfortunately this did not work - the columns get messed up and there is no
column for the full address.
--
https://mail.python.org/mailman/listinfo/python-list
buggy python interpretter or am I missing something here?
I'm writing a linux daemon in python 2.x to process batches of GPS/GIS
data and I'm running into something that seems to break the expected
program flow in a REALLY BAD WAY.
Consider the attached template script and execute it with the -h option.
It is falling through to the except: clause even though try to manually
exit with sys.exit(0). However, if I insert a "raise" into the except
clause then the sys.exit(0) executes properly.
See the attached code and output from when I run it.
Not interested in work-arounds. I want to understand why it doesn't work
as expected.
Thanks!
TCdaemon.py
#! /usr/bin/python
import sys
#
--
defaultparams={ \
"basedir": "/process", \
"inpipe": "/tmp/TCdaemonIN", \
"maxjobs":8, \
"outpipe": "/tmp/TCdaemonOUT", \
"ZZZ": 0
}
#
--
def parse_args(a,d):
l=len(a)
idx=1
try:
while (idxhttps://mail.python.org/mailman/listinfo/python-list
Remove unwanted characters from column
School assignment is to create a tab separated output with the original given
addresses in one column and then the addresses split into other columns (ex,
columns for city, postal code, street suffix).
Here is my code:
inHandler = open(inFile, 'r')
outHandler = open(outFile, 'w')
outHandler.write("FarmID\tAddress\tStreetNum\tStreetName\tSufType\tDir\tCity\tProvince\tPostalCode")
for line in inHandler:
str = line.replace("FarmID\tAddress", " ")
outHandler.write(str[0:-1])
str = str.replace(" ","\t", 1)
str = str.replace(" Rd, ","\tRd\t\t")
str = str.replace("Rd ","\tRd\t\t")
str = str.replace("Ave, ","\tAve\t\t")
str = str.replace("Ave ","\tAve\t\t")
str = str.replace("St ","\tSt\t\t")
str = str.replace("St, ","\tSt\t\t")
str = str.replace("Dr, ","\tDr\t\t")
str = str.replace("Lane, ","\tLane\t\t")
str = str.replace("Pky, ","\tPky\t\t")
str = str.replace(" Sq, ","\tSq\t\t")
str = str.replace(" Pl, ","\tPl\t\t")
str = str.replace("\tE, ","E\t")
str = str.replace("\tN, ","N\t")
str = str.replace("\tS, ","S\t")
str = str.replace("\tW, ","W\t")
str = str.replace(",\t","\t\t")
str = str.replace(", ON ","\tON\t")
outHandler.write(str)
inHandler.close()
outHandler.close()
Here is some sample addresses, there are over 100:
FarmID Address
1 1067 Niagara Stone Rd, Niagara-On-The-Lake, ON L0S 1J0
2 4260 Mountainview Rd, Lincoln, ON L0R 1B2
3 25 Hunter Rd, Grimsby, ON L3M 4A3
4 1091 Hutchinson Rd, Haldimand, ON N0A 1K0
5 5172 Green Lane Rd, Lincoln, ON L0R 1B3
6 500 Glenridge Ave, St. Catharines, ON L2S 3A1
7 471 Foss Rd, Pelham, ON L0S 1C0
8 758 Niagara Stone Rd, Niagara-On-The-Lake, ON L0S 1J0
9 3836 Main St, Lincoln, ON L0R 1S0
I have everything worked out, except that the final output places the farmID at
the end of postal code as seen in the example below (notice the brackets
showing where the farmID is placed):
FarmID Address StreetNum StreetName SufType Dir City
ProvincePostalCode
1 1067 Niagara Stone Rd, Niagara-On-The-Lake, ON L0S 1J0(1) 1067
Niagara Stone Rd Niagara-On-The-Lake ON L0S 1J0
Any ideas on how to fix this? Keep in mind as well that the farmID will have 2
characters at a certain point.
--
https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On 01/26/2014 07:42 PM, me wrote:
I'm writing a linux daemon in python 2.x to process batches of GPS/GIS
data and I'm running into something that seems to break the expected
program flow in a REALLY BAD WAY.
Consider the attached template script and execute it with the -h option.
It is falling through to the except: clause even though try to manually
exit with sys.exit(0). However, if I insert a "raise" into the except
clause then the sys.exit(0) executes properly.
See the attached code and output from when I run it.
Not interested in work-arounds. I want to understand why it doesn't work
as expected.
Thanks!
TCdaemon.py
#! /usr/bin/python
import sys
#
--
defaultparams={ \
"basedir": "/process", \
"inpipe": "/tmp/TCdaemonIN", \
"maxjobs":8, \
"outpipe": "/tmp/TCdaemonOUT", \
"ZZZ": 0
}
#
--
def parse_args(a,d):
l=len(a)
idx=1
try:
while (idx
Never *ever* have a bare except like that. If it gets invoked, you have
no idea why. A simple typo like ixd instead of idx or a(idx) instead
of a[idx] would raise an exception but give you no idea why.
Do
try:
...
except Exception,e:
print e
at the absolute minimum.
(Python 3 syntax would differ slightly, but the advice is the same.)
Perhaps printing a traceback along with the exception would help. Add
traceback.print_exc()
Gary Herron
#
--
#
--
#
--
if (__name__=="__main__"):
print defaultparams
parse_args(sys.argv,defaultparams)
print defaultparams
output.txt ---
[@blackbox new]$ ./TCdaemon.py -h
{'ZZZ': 0, 'basedir': '/process', 'outpipe': '/tmp/TCdaemonOUT',
'maxjobs': 8, 'inpipe': '/tmp/TCdaemonIN'}
help goes here
./TCdaemon.py: error in command line - ['-h']
[@blackbox new]$ echo $?
1
[@blackbox new]$
[@blackbox new]$
[@blackbox new]$ # editing to add "raise" at line 40
[@blackbox new]$
[@blackbox new]$
[@blackbox new]$
[@blackbox new]$ ./TCdaemon.py -h
{'ZZZ': 0, 'basedir': '/process', 'outpipe': '/tmp/TCdaemonOUT',
'maxjobs': 8, 'inpipe': '/tmp/TCdaemonIN'}
help goes here
[@blackbox new]$ echo $?
0
[@blackbox new]$
--
https://mail.python.org/mailman/listinfo/python-list
Re:Remove unwanted characters from column
matt.s.maro...@gmail.com Wrote in message:
> School assignment is to create a tab separated output with the original given
> addresses in one column and then the addresses split into other columns (ex,
> columns for city, postal code, street suffix).
>
> Here is my code:
>
> inHandler = open(inFile, 'r')
> outHandler = open(outFile, 'w')
> outHandler.write("FarmID\tAddress\tStreetNum\tStreetName\tSufType\tDir\tCity\tProvince\tPostalCode")
> for line in inHandler:
> str = line.replace("FarmID\tAddress", " ")
> outHandler.write(str[0:-1])
>
> str = str.replace(" ","\t", 1)
> str = str.replace(" Rd, ","\tRd\t\t")
> str = str.replace("Rd ","\tRd\t\t")
> str = str.replace("Ave, ","\tAve\t\t")
> str = str.replace("Ave ","\tAve\t\t")
> str = str.replace("St ","\tSt\t\t")
> str = str.replace("St, ","\tSt\t\t")
> str = str.replace("Dr, ","\tDr\t\t")
> str = str.replace("Lane, ","\tLane\t\t")
> str = str.replace("Pky, ","\tPky\t\t")
> str = str.replace(" Sq, ","\tSq\t\t")
> str = str.replace(" Pl, ","\tPl\t\t")
>
> str = str.replace("\tE, ","E\t")
> str = str.replace("\tN, ","N\t")
> str = str.replace("\tS, ","S\t")
> str = str.replace("\tW, ","W\t")
> str = str.replace(",\t","\t\t")
> str = str.replace(", ON ","\tON\t")
>
> outHandler.write(str)
>
> inHandler.close()
> outHandler.close()
>
>
> Here is some sample addresses, there are over 100:
>
> FarmIDAddress
> 1 1067 Niagara Stone Rd, Niagara-On-The-Lake, ON L0S 1J0
> 2 4260 Mountainview Rd, Lincoln, ON L0R 1B2
> 3 25 Hunter Rd, Grimsby, ON L3M 4A3
> 4 1091 Hutchinson Rd, Haldimand, ON N0A 1K0
> 5 5172 Green Lane Rd, Lincoln, ON L0R 1B3
> 6 500 Glenridge Ave, St. Catharines, ON L2S 3A1
> 7 471 Foss Rd, Pelham, ON L0S 1C0
> 8 758 Niagara Stone Rd, Niagara-On-The-Lake, ON L0S 1J0
> 9 3836 Main St, Lincoln, ON L0R 1S0
>
>
>
> I have everything worked out, except that the final output places the farmID
> at the end of postal code as seen in the example below (notice the brackets
> showing where the farmID is placed):
>
> FarmIDAddress StreetNum StreetName SufType Dir City
> ProvincePostalCode
> 1 1067 Niagara Stone Rd, Niagara-On-The-Lake, ON L0S 1J0(1) 1067
> Niagara Stone Rd Niagara-On-The-Lake ON L0S 1J0
>
> Any ideas on how to fix this? Keep in mind as well that the farmID will have
> 2 characters at a certain point.
>
Your specific concern is triggered by having two writes in the loop.
Get rid of the first and you're marginally closer.
But really, you've got much bigger troubles. All those
unrestricted replace calls are not at all robust. But maybe
you'll get away with it for a school assignment if the test data
is very limited.
Better would be to treat it like a parsing problem, figuring what
delimiter rule applies to each field, and building a list Then
use str.join to build the line for the outHandler.
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
Re:buggy python interpretter or am I missing something here?
me Wrote in message: > I'm writing a linux daemon in python 2.x to process batches of GPS/GIS > data and I'm running into something that seems to break the expected > program flow in a REALLY BAD WAY. > > Consider the attached template script and execute it with the -h option. > It is falling through to the except: clause even though try to manually > exit with sys.exit(0). However, if I insert a "raise" into the except > clause then the sys.exit(0) executes properly. > > See the attached code and output from when I run it. > > Not interested in work-arounds. I want to understand why it doesn't work > as expected. > sys.exit() raises an exception, and you're deliberately eating that exception. > > -- > > def parse_args(a,d): > l=len(a) > idx=1 > try: > while (idx if (a[idx]=="-#"): > idx=idx+1 > d["maxjobs"]=int(a[idx]) > elif (a[idx]=="-d"): > idx=idx+1 > d["basedir"]=a[idx] > elif (a[idx]=="-h"): > print "help goes here" > sys.exit(0) > elif (a[idx]=="-i"): > idx=idx+1 > d["inpipe"]=a[idx] > elif (a[idx]=="-o"): > idx=idx+1 > d["outpipe"]=a[idx] > idx=idx+1 > except: Bare except is almost never a good idea. It's going to intercept the exit exception, plus control C, syntax errors and others. Which you'd have known if you printed the exception code. If you're going to catch an exception, be specific. Otherwise expect the unexpected. There is a hierarchy of exception classes, so you could catch a fairly generic class. But you do need to distinguish. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re:buggy python interpretter or am I missing something here?
On Mon, 27 Jan 2014 00:36:20 -0500, Dave Angel wrote: > sys.exit() raises an exception, and you're deliberately eating > that exception. > I can buy that sys.exit (may) be throwing an exception...My point of contention isn't that I may be throwing one, but why would a subsequent "raise" in the except: clause cause the point of program execution to jump back up to the sys.exit(0) and then function correctly. This seems to be a violation of the programming semantics of python as I understand them...coming from an old fart c++ programmer where bare catch() is totally acceptable and common form. > > Bare except is almost never a good idea. It's going to intercept > the exit exception, plus control C, syntax errors and others. > Which you'd have known if you printed the exception code. > > > If you're going to catch an exception, be specific. Otherwise > expect the unexpected. > > > There is a hierarchy of exception classes, so you could catch a > fairly generic class. But you do need to distinguish. I'll take your point of "almost a never good idea" under consideration and agree that if I was writing something for production use I'd be more comprehensive, but I really don't care what exceptions are raised at this point ... until I've tested with bunches of input data and see that it does break and under what circumstances. But...it still doesn't explain why/how a raise in the except: clause can recover the point of program execution back to the sys.exit(0) that threw the exception. Are you saying that the programming semantics of try/except are different in python than they are in c++? My expectation being that when an exception occurs program control jumps to the except: and then continues below without ever going back to the code that threw the exception in the first place...because that's exactly what it appears to be doing? Are except: clauses in python more synonymous with the old BASIC "GOSUB" or "ON ERROR GOSUB" statement rather than following the c++ semantics? kind regards -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Sun, 26 Jan 2014 21:04:57 -0800, Gary Herron wrote: > > Never *ever* have a bare except like that. If it gets invoked, you have > no idea why. A simple typo like ixd instead of idx or a(idx) instead > of a[idx] would raise an exception but give you no idea why. > > Do >try: >... >except Exception,e: >print e > at the absolute minimum. > (Python 3 syntax would differ slightly, but the advice is the same.) > > Perhaps printing a traceback along with the exception would help. Add > traceback.print_exc() So here's the clencher without debating the merits bare except: since a bare catch(...) is totally acceptable in the c++ world. When I have except: by itself the program fails...but simply adding the "except Exception,e: " causes the program to work correctly. To me that signifies an undefined behavior of the python specification, or at least bad behavior of the python interpreter I'm using. If you can syntactically use a bare except: without generating an invalid syntax error then it should have a well defined and predictable outcome. If in fact the "except Exception, e:" is what's required then a bare except shouldn't be considered valid syntax at all, right? kind regards -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On 1/27/2014 12:04 AM, Gary Herron wrote: Do try: ... except Exception,e: print e at the absolute minimum. (Python 3 syntax would differ slightly, but the advice is the same.) The 'python 3' syntax except Exception as e: works in 2.7 and perhaps 2.6. So use it unless you need compatibility with even earlier versions. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.4.0b3
On behalf of the Python development team, I'm quite pleased to announce the third beta release of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a "pathlib" module providing object-oriented filesystem paths * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new "statistics" module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new "tracemalloc" module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O Python 3.4 is now in "feature freeze", meaning that no new features will be added. The final release is projected for mid-March 2014. To download Python 3.4.0b3 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0b3 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) -- https://mail.python.org/mailman/listinfo/python-list
Re: Highlighting program variables instead of keywords?
On 1/26/2014 8:29 PM, Steven D'Aprano wrote: On Sun, 26 Jan 2014 18:31:49 -0600, Skip Montanaro wrote: My son sent me a link to an essay about highlighting program data instead of keywords: https://medium.com/p/3a6db2743a1e/ I think this might have value, especially if to could bounce back and forth between both schemes. Hmmm, I'm not convinced, but then I wasn't convinced by syntax highlighting either until I had used it for a while. (I still think it's a nice-to-have rather than a must-have.) When my fingers get a bit fumbly, I find it more useful. When I do not hit ' or " solidly, or type a mismatch 'something", having the string literal color continue is a handy clue. So is 'it' not getting the keyword color that if would. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Highlighting program variables instead of keywords?
On 1/26/2014 8:46 PM, Skip Montanaro wrote: I think an interactive pylint (or pyflakes or frosty) type capability would be useful, highlighting a subset of the messages it produces, like variables which were assigned but never used, or using undefined variables. It might be best supported by actually running the checker in the background, then using its messages to direct where to highlight suspect bits of code. One of my long-term goals for Idle is an extension that would run user-installed code analyzers over the contents of an edit window, with the output sent to an OutputWindow. Using the contents of the latter to mark things in the editor window is an interesting idea. That is already done for SyntaxErrors and traceback file:line references. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Mon, 27 Jan 2014 01:21:41 -0500, Terry Reedy wrote: > On 1/27/2014 12:04 AM, Gary Herron wrote: > >> Do >>try: >>... >>except Exception,e: >>print e >> at the absolute minimum. >> (Python 3 syntax would differ slightly, but the advice is the same.) > > The 'python 3' syntax >except Exception as e: > works in 2.7 and perhaps 2.6. So use it unless you need compatibility > with even earlier versions. My point of contention isn't so much about what specific syntax I should be using as much as it is about being allowed to use a syntax that gives erroneous results without triggering a syntax violation. If the bare except: clause is syntactically legal then it should yield deterministic results based on a well defined language specification, right? It's looking very much like "except:" is undefined behaviour. kind regards -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Mon, Jan 27, 2014 at 12:02 AM, me wrote: > On Mon, 27 Jan 2014 00:36:20 -0500, Dave Angel wrote: > >> sys.exit() raises an exception, and you're deliberately eating >> that exception. >> > > I can buy that sys.exit (may) be throwing an exception...My point of > contention isn't that I may be throwing one, but why would a subsequent > "raise" in the except: clause cause the point of program execution to > jump back up to the sys.exit(0) and then function correctly. You've missed the point here. sys.exit() *does* raise an exception: SystemExit, a subclass of BaseException. In fact, you can implement sys.exit in pure Python like so: def exit(status): raise SystemExit(status) Your bare 'except:' catches that SystemExit along with any other possible exception; the bare 'raise' in the except clause just re-raises the same SystemExit, which then does what you meant for it to do in the first place. Exception classes form a hierarchy, with BaseException being the base (obviously :)), "except:" is really just shorthand for "except BaseException:", and is very rarely a good idea. Deriving from BaseException are SystemExit, KeyboardInterrupt, and Exception. SystemExit is the exception raised by sys.exit(), which if left unhandled, the interpreter takes as a sign to shut down gracefully. KeyboardInterrupt is raised by Ctrl+C, or (more accurately, if I'm not mistaken) by sending SIGINT to the process. Exception is the base class for all other exceptions, such as TypeError, ValueError, OSError, etc., and is what you actually want to catch if you really don't care what exception is raised but want to handle it (though in most cases, you either should care, or should at least report what the exception was, preferably with a traceback...which is easiest to do by not trying to catch the exception at all). I would suggest skimming through the Python tutorial and/or language reference if you haven't before, there's a lot of good information in there that will make your life with Python much easier. And, please take this positively, but from your posted code it's fairly apparent that Python is not your native tongue :). For instance, you don't need the backslashes in your defaultparams assignment; the parser knows it needs to keep looking on subsequent lines when it hasn't found the closing '}' yet. Also, you can iterate over a (sys.argv) in a for loop, replacing 'l', 'idx', and the while loop; something like for arg in a: if arg == '-h': print help # help being defined elsewhere... elif arg == '-hh': # no really, print help print 'help' And the big one, argument parsing is a solved problem in Python. Check out the argparse module in the standard library (or if you're using an older version of Python, try either optparse or getopt. It's really a thrice-solved problem ;)). I hope I've been of some help, -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
In any case, thanks for the answers guys. I'm satisfied that the except: syntax yields undefined behavior, and in my mind it shouldn't be syntactically allowed then. Updating to Exception,e or Exception as e fixes the problem. -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Mon, Jan 27, 2014 at 12:46 AM, me wrote: > > In any case, thanks for the answers guys. I'm satisfied that the except: > syntax yields undefined behavior, and in my mind it shouldn't be > syntactically allowed then. It's not undefined, though; it is explicitly defined. See my other message, and here are a couple other places to skim through: http://docs.python.org/2/tutorial/errors.html and http://docs.python.org/2/library/exceptions.html -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On 01/26/2014 10:17 PM, me wrote: On Sun, 26 Jan 2014 21:04:57 -0800, Gary Herron wrote: Never *ever* have a bare except like that. If it gets invoked, you have no idea why. A simple typo like ixd instead of idx or a(idx) instead of a[idx] would raise an exception but give you no idea why. Do try: ... except Exception,e: print e at the absolute minimum. (Python 3 syntax would differ slightly, but the advice is the same.) Perhaps printing a traceback along with the exception would help. Add traceback.print_exc() So here's the clencher without debating the merits bare except: since a bare catch(...) is totally acceptable in the c++ world. When I have except: by itself the program fails...but simply adding the "except Exception,e: " causes the program to work correctly. Doubtful. We've been doing this kind of stuff for decades without hitting your supposed bug. Much more likely is that you've misinterpreted the results. Ii don't know how, but I'm quite confident that you have. Your contention that the raise goes back to the sys.exit() is certainly a mis-interpretation also. The re-raise of the original exception is now an uncaught exception, and the interpreter's response to an uncaught exception is to kill the program. Nearly the same result as the sys.exit(), but via a different pathway. To me that signifies an undefined behavior of the python specification, or at least bad behavior of the python interpreter I'm using. If you can syntactically use a bare except: without generating an invalid syntax error then it should have a well defined and predictable outcome. It is well defined. Slow down a bit, rerun your two tests, show is the code *and* the results, and we'll get to the bottom of this. If in fact the "except Exception, e:" is what's required then a bare except shouldn't be considered valid syntax at all, right? Bare excepts are perfectly legal valid syntax and have their uses, however it's just extremely dangerous programming to allow a simple typo (or any of an infinite number of possible errors) in your try section to masquerade as a "error in command line" (to quote your print at that point).Python's dynamic typing makes bare except extremely dangerous. In Python, unlike C, any number of typos can be syntactically correct, but meaningless, exception-raising actions at run time. Things like misspelling a variable/function name, substituting a comma for a decimal point, indexing something that is not indexable, applying a function to the wrong parameters or wrong number of parameters, ... All these are *not* syntax errors (as they would be in C), but will cause a run-time exception -- and you'd never know why with that bare except blindly catching them all and claiming "command line error". Gary Herron kind regards -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On 01/26/2014 10:46 PM, me wrote: In any case, thanks for the answers guys. I'm satisfied that the except: syntax yields undefined behavior, and in my mind it shouldn't be syntactically allowed then. Updating to Exception,e or Exception as e fixes the problem. That's an irksome habit you have there, this jumping to (incorrect) conclusions so quickly. We'd like to get to the bottom of this. (And correct your mis-interpretations while we're at it :-)But we need to see your test *and* the results. Gary Herron -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Mon, 27 Jan 2014 00:47:13 -0600, Zachary Ware wrote: > You've missed the point here. sys.exit() *does* raise an exception: > SystemExit, a subclass of BaseException. In fact, you can implement > sys.exit in pure Python like so: > > def exit(status): > raise SystemExit(status) > > Your bare 'except:' catches that SystemExit along with any other > possible exception; the bare 'raise' in the except clause just re-raises > the same SystemExit, which then does what you meant for it to do in the > first place. Well that does change things a bit and makes perfect sense now. Thx! > And, please take this positively, but from your posted code it's fairly > apparent that Python is not your native tongue :). Correct. The barbarians invaded my homeland and forced me to speak their wicked incantations. I'm a c/c++ guy through and through with a sprinkling of the ancient tongues like algol, LSI-11 and Z80 assembler, fortran-4, etc. My python stuff is all rapid application development for personal projects. If I need to do anything serious I take the time to do it in C+ +. > For instance, you > don't need the backslashes in your defaultparams assignment; the parser > knows it needs to keep looking on subsequent lines when it hasn't found > the closing '}' yet. It's the intendation specific requirements that throw me. I haven't seen such a hork since RPG. ;^) > Also, you can iterate over a (sys.argv) in a for > loop, replacing 'l', 'idx', and the while loop; something like > > for arg in a: > if arg == '-h': > print help # help being defined elsewhere... > elif arg == '-hh': > # no really, print help print 'help' Understood, except that some parameters take multiple elements...thus why I manually reference the indexes. > And the big one, argument parsing is a solved problem in Python. Check > out the argparse module in the standard library (or if you're using an > older version of Python, try either optparse or getopt. It's really a > thrice-solved problem ;)). Yup. Every language and platform has multiple arg parsing libraries. Didn't feel like taking the time to research any since most of my python ramblings are usually pyQT4 bindings to QT4 gui and postgresql apps. > > I hope I've been of some help, Pointing out that sys.exit() raises a low level exception was the point I was missing. Thx! -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Sun, 26 Jan 2014 23:03:51 -0800, Gary Herron wrote: found the part I was missing based on another response. Didn't realize that sys.exit() triggered an instance of "BaseException" and that explains the weird behavior. thx! -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On 01/26/2014 10:42 PM, me wrote: My point of contention isn't so much about what specific syntax I should be using as much as it is about being allowed to use a syntax that gives erroneous results without triggering a syntax violation. If the bare except: clause is syntactically legal then it should yield deterministic results based on a well defined language specification, right? It's looking very much like "except:" is undefined behaviour. There is nothing undefined about it. `except:` catches everything. Occasionally there is a good reason to do it that way, but under typical circumstances you tell 'except' which exceptions you are prepared to deal with. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Sun, 26 Jan 2014 23:12:18 -0800, Gary Herron wrote: > On 01/26/2014 10:46 PM, me wrote: >> In any case, thanks for the answers guys. I'm satisfied that the >> except: >> syntax yields undefined behavior, and in my mind it shouldn't be >> syntactically allowed then. >> >> Updating to Exception,e or Exception as e fixes the problem. >> >> > That's an irksome habit you have there, this jumping to (incorrect) > conclusions so quickly. We'd like to get to the bottom of this. (And > correct your mis-interpretations while we're at it :-)But we need to > see your test *and* the results. > > Gary Herron Problem solved. I understand what was happening now with the "raise" following the bare except: Since this code is for a personal research project I'm not as concerned about code quality as I would be if I was getting paid to write production code...and if it was production code I'd only prototype a proof-of-concept in python and then rewrite in c++. The project is to take advantage of all 16 CPU cores to process A LOT of GPS data for a 3d map-making and visualization project. Now my bottleneck may end up being the python global lock when doing concurrent processing...but we'll see. -- https://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.3.4 release candidate 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm reasonably happy to announce the Python 3.3.4 release candidate 1. Python 3.3.4 includes several security fixes and over 120 bug fixes compared to the Python 3.3.3 release. This release fully supports OS X 10.9 Mavericks. In particular, this release fixes an issue that could cause previous versions of Python to crash when typing in interactive mode on OS X 10.9. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in the 3.3 series, see http://docs.python.org/3.3/whatsnew/3.3.html and for the detailed changelog of 3.3.4, see http://docs.python.org/3.3/whatsnew/changelog.html To download Python 3.3.4 rc1 visit: http://www.python.org/download/releases/3.3.4/ This is a preview release, please report any bugs to http://bugs.python.org/ The final version is scheduled to be released in two weeks' time, on or about the 10th of February. Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlLmDI4ACgkQN9GcIYhpnLAr6wCePRbHF80k5goV4RUDBA5FfkwF rLUAnRg0RpL/b6apv+Dt2/sgnUd3hTPA =Z4Ss -END PGP SIGNATURE- -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On 01/26/2014 10:46 PM, me wrote: [...] I'm satisfied that the except: syntax yields undefined behavior, and in my mind it shouldn't be syntactically allowed then. Two points: 1) Python is not C++ 2) You asked for help; you received it. Coming back with an attitude of "Python must be broken, I'll work around it" is going to quickly lose you the support of those willing to help again. -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Sun, 26 Jan 2014 23:17:29 -0800, Ethan Furman wrote: > On 01/26/2014 10:46 PM, me wrote: >> >> [...] I'm satisfied that the except: syntax yields undefined behavior, >> and in my mind it shouldn't be >> syntactically allowed then. > > Two points: > >1) Python is not C++ > >2) You asked for help; you received it. Coming back > with an attitude of "Python must be broken, I'll work around it" > is going to quickly lose you the support of those willing to help > again. Whatever...lighten up dude! -- https://mail.python.org/mailman/listinfo/python-list
