From willspearman at gmail.com Tue Sep 5 10:21:39 2017 From: willspearman at gmail.com (Will Spearman) Date: Tue, 05 Sep 2017 14:21:39 +0000 Subject: [TriPython] ScienceLogic Careers Message-ID: Fellow Pythonistas, My company, ScienceLogic, is hiring for several python software development positions, a devops position, and a UI developer. ScienceLogic's product is an enterprise monitoring platform for datacenters, businesses, and service providers that provides reporting, alerting, automation, and integration with other products. We are based in Reston VA, but have a growing office here in RTP. You can see the job descriptions here: https://www.sciencelogic.com/company/careers. Business has been booming, and we are in need of several new people for some growing areas of engineering. We recently completed a project to monitor all the equipment on the International Space Station: https://www.sciencelogic.com/blog/space-station-it-monitoring. Check us out on Glassdoor: https://www.glassdoor.com/Overview/Working-at-ScienceLogic-EI_IE342863.11,23.htm . I am a python developer and have been with ScienceLogic for about 2 years now. If you think any of those positions would be a good fit for you, please let me know directly. I look forward to working with you. -------------- next part -------------- Fellow Pythonistas, My company, ScienceLogic, is hiring for several python software development positions, a devops position, and a UI developer. ScienceLogic's product is an enterprise monitoring platform for datacenters, businesses, and service providers that provides reporting, alerting, automation, and integration with other products. We are based in Reston VA, but have a growing office here in RTP. You can see the job descriptions here:**[1]https://www.sciencelogic.com/company/careers. Business has been booming, and we are in need of several new people for some growing areas of engineering. We recently completed a project to monitor all the equipment on the International Space Station:**[2]https://www.sciencelogic.com/blog/space-station-it-monitoring. Check us out on Glassdoor:**[3]https://www.glassdoor.com/Overview/Working-at-ScienceLogic-EI_IE342863.11,23.htm. I am a python developer and have been with ScienceLogic for about 2 years now. If you think any of those positions would be a good fit for you, please let me know directly. I look forward to working with you. References Visible links 1. https://www.sciencelogic.com/company/careers 2. https://www.sciencelogic.com/blog/space-station-it-monitoring 3. https://www.glassdoor.com/Overview/Working-at-ScienceLogic-EI_IE342863.11,23.htm From cbc at unc.edu Tue Sep 5 10:22:38 2017 From: cbc at unc.edu (Calloway, Chris) Date: Tue, 5 Sep 2017 14:22:38 +0000 Subject: [TriPython] Reminder: Raleigh Project Night Tonight Message-ID: <7C3D9576-0AE6-4B23-B6F5-8B3599C87074@unc.edu> Another great first Tuesday project night tonight at WebAssign. Plenty of free parking in the deck behind the WebAssign. There will be pizza: http://tripython.org/Members/sgambino/sept-17-rpn When: Tuesday, September 5, 6-9pm Where: WebAssign NCSU Centennial Campus 1791 Varsity Drive, Suite 200 Raleigh What: Raleigh Project Night meets on first Tuesdays. Have a project you want to show off, share, seek help with, or just get some work done surrounded by like-minded Python lovers? Join us for our monthly project night and do just that! Don't have something to work on? Just need some help with Python? Show up and enjoy the energy, sprint on an open source project, find something interesting to contribute to or be inspired by! The setting is informal and there is no schedule, so don't worry if you show up past the start time. Whether you are a Python newbie needing help or have an open source project you want to share, come hang out and hack. Plenty of free after hours parking is available in the upper level of the deck behind WebAssign (turn through the median just before the intersection of Varsity and Main Campus Drives). If the door is locked, call the number posted on the door. Bring your laptop. -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 -------------- next part -------------- Another great first Tuesday project night tonight at WebAssign. Plenty of free parking in the deck behind the WebAssign. There will be pizza: [1]http://tripython.org/Members/sgambino/sept-17-rpn When: Tuesday, September 5, 6-9pm Where: WebAssign NCSU Centennial Campus 1791 Varsity Drive, Suite 200 Raleigh What: Raleigh Project Night meets on first Tuesdays. Have a project you want to show off, share, seek help with, or just get some work done surrounded by like-minded Python lovers? Join us for our monthly project night and do just that! Don't have something to work on? Just need some help with Python? Show up and enjoy the energy, sprint on an open source project, find something interesting to contribute to or be inspired by! The setting is informal and there is no schedule, so don't worry if you show up past the start time. Whether you are a Python newbie needing help or have an open source project you want to share, come hang out and hack. Plenty of free after hours parking is available in the upper level of the deck behind WebAssign (turn through the median just before the intersection of Varsity and Main Campus Drives). If the door is locked, call the number posted on the door. Bring your laptop. -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 References Visible links 1. http://tripython.org/Members/sgambino/sept-17-rpn From cbc at unc.edu Fri Sep 8 11:50:11 2017 From: cbc at unc.edu (Calloway, Chris) Date: Fri, 8 Sep 2017 15:50:11 +0000 Subject: [TriPython] Upcoming Chapel Hill Project Night Message-ID: <4CB36D32-5F5B-4CB0-BA6F-66C44632F3E1@unc.edu> I?m keeping a watch on whether it would be advisable to have Chapel Hill Project night next Wednesday. I assume it will be fine. But I?ll send out a meeting reminder or cancellation either way on Tuesday. -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 -------------- next part -------------- I'm keeping a watch on whether it would be advisable to have Chapel Hill Project night next Wednesday. I assume it will be fine. But I'll send out a meeting reminder or cancellation either way on Tuesday. -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 From cbc at unc.edu Tue Sep 12 13:48:04 2017 From: cbc at unc.edu (Calloway, Chris) Date: Tue, 12 Sep 2017 17:48:04 +0000 Subject: [TriPython] Reminder: Chapel Hill Project Night (is a go for tomorrow) Message-ID: <112B880A-761C-4FF5-B72D-8F2B3629559F@unc.edu> Sunshine tomorrow, so project night is a go. Pizza will be provided. http://tripython.org/Members/cbc/sept-17-chpn When: Wed Sept 13, 6-9pm Where: Renaissance Computing Institute (RENCI) Biltmore Conference Room 5th Floor, Europa Center 100 Europa Drive, Suite 590 Chapel Hill What: Chapel Hill Project Night meets on second Wednesdays. Have a project you want to show off, share, seek help with, or just get some work done surrounded by like-minded Python lovers? Join us for our monthly project night and do just that! Don't have something to work on? Just need some help with Python? Show up and enjoy the energy, sprint on an open source project, find something interesting to contribute to or be inspired by! The setting is informal and there is no schedule, so don't worry if you show up past the start time. Whether you are a Python newbie needing help or have an open source project you want to share, come hang out and hack. We will be joined again this month by the Triangle Deep Learning Study Group. Plenty of free after hours parking is available in the RENCI parking deck. Bring your laptop. -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 -------------- next part -------------- Sunshine tomorrow, so project night is a go. Pizza will be provided. [1]http://tripython.org/Members/cbc/sept-17-chpn When: Wed Sept 13, 6-9pm Where: Renaissance Computing Institute (RENCI) Biltmore Conference Room 5th Floor, Europa Center 100 Europa Drive, Suite 590 Chapel Hill What: Chapel Hill Project Night meets on second Wednesdays. Have a project you want to show off, share, seek help with, or just get some work done surrounded by like-minded Python lovers? Join us for our monthly project night and do just that! Don't have something to work on? Just need some help with Python? Show up and enjoy the energy, sprint on an open source project, find something interesting to contribute to or be inspired by! The setting is informal and there is no schedule, so don't worry if you show up past the start time. Whether you are a Python newbie needing help or have an open source project you want to share, come hang out and hack. We will be joined again this month by the Triangle Deep Learning Study Group. Plenty of free after hours parking is available in the RENCI parking deck. Bring your laptop. -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 References Visible links 1. http://tripython.org/Members/cbc/sept-17-chpn From ken at mack-z.com Thu Sep 14 09:32:42 2017 From: ken at mack-z.com (Ken MacKenzie) Date: Thu, 14 Sep 2017 09:32:42 -0400 Subject: [TriPython] A question of recursion and nested parsing Message-ID: So I have a bit of code I have created that works to solve the problem, however as an academic exercise, I realized I could not reason of a way to solve it without recursion. The situation, I have a file with many possible delimiters and those delimiters have levels so to speak so as I am kind of parsing a tree, and in this case a tree that is lists of lists of lists of x n... Excuse the lack of real commenting in this sample. But curious what other ways I could solve it, or if there are ways I could perhaps make it perform faster. It performs fast enough but I realize the file could get quite long. ======= parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", "\x05", "\x06", "\x07"] parse_2 = [chr(255), chr(254), chr(253), chr(252)] all_parsers = parse_1 + parse_2 def recursive_parse(in_var, parse_char): if isinstance(in_var, list): return [recursive_parse(x, parse_char) for x in in_var] elif isinstance(in_var, str): return in_var.split(parse_char) def nested_parse(str_in): big_list = [] temp = [] parse_list = all_parsers max_lvl = len(parse_list) - 1 for lvl, psr_c in enumerate(parse_list): # print("temp:", temp[0][:20]) if lvl == 0: temp.append(str_in.split(psr_c)) else: pre_lvl = lvl - 1 new_lvl = recursive_parse(temp[pre_lvl], psr_c) temp.append(new_lvl) big_list = temp[max_lvl] return big_list -------------- next part -------------- So I have a bit of code I have created that works to solve the problem, however as an academic exercise, I realized I could not reason of a way to solve it without recursion. The situation, I have a file with many possible delimiters and those delimiters have levels so to speak so as I am kind of parsing a tree, and in this case a tree that is lists of lists of lists of x n... Excuse the lack of real commenting in this sample.** But curious what other ways I could solve it, or if there are ways I could perhaps make it perform faster.** It performs fast enough but I realize the file could get quite long. ======= parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", "\x05", "\x06", "\x07"] parse_2 = [chr(255), chr(254), chr(253), chr(252)] all_parsers = parse_1 + parse_2 def recursive_parse(in_var, parse_char): ** ** if isinstance(in_var, list): ** ** ** ** return [recursive_parse(x, parse_char) for x in in_var] ** ** elif isinstance(in_var, str): ** ** ** ** return in_var.split(parse_char) def nested_parse(str_in): ** ** big_list = [] ** ** temp = [] ** ** parse_list = all_parsers ** ** max_lvl = len(parse_list) - 1 ** ** for lvl, psr_c in enumerate(parse_list): ** ** ** ** # print("temp:", temp[0][:20]) ** ** ** ** if lvl == 0: ** ** ** ** ** ** temp.append(str_in.split(psr_c)) ** ** ** ** else: ** ** ** ** ** ** pre_lvl = lvl - 1 ** ** ** ** ** ** new_lvl = recursive_parse(temp[pre_lvl], psr_c) ** ** ** ** ** ** temp.append(new_lvl) ** ** big_list = temp[max_lvl] ** ** return big_list From bgailer at gmail.com Fri Sep 15 08:47:58 2017 From: bgailer at gmail.com (Bob Gailer) Date: Fri, 15 Sep 2017 08:47:58 -0400 Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: References: Message-ID: On Sep 14, 2017 9:33 AM, "Ken MacKenzie" wrote: > > So I have a bit of code I have created that works to solve the problem, > however as an academic exercise, I realized I could not reason of a way to > solve it without recursion. My understanding of computer science says that recursion is never necessary. There is always a way to solve the problem without recursion. > The situation, I have a file with many possible delimiters and those > delimiters have levels so to speak so as I am kind of parsing a tree, and > in this case a tree that is lists of lists of lists of x n... > Excuse the lack of real commenting in this sample.** But curious what > other ways I could solve it, or if there are ways I could perhaps make it > perform faster.** It performs fast enough but I realize the file could get > quite long. It would be very helpful if you would give us a sample input and the corresponding output. Your description above does not help. Also your code has lots of** in it that I presume are either spaces or tabs. I would appreciate it if you would post the code that is actually executable. My guess is that there's a much simpler way to do this. > ======= > parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", "\x05", "\x06", > "\x07"] > parse_2 = [chr(255), chr(254), chr(253), chr(252)] > all_parsers = parse_1 + parse_2 > def recursive_parse(in_var, parse_char): > ** ** if isinstance(in_var, list): > ** ** ** ** return [recursive_parse(x, parse_char) for x in in_var] > ** ** elif isinstance(in_var, str): > ** ** ** ** return in_var.split(parse_char) > def nested_parse(str_in): > ** ** big_list = [] > ** ** temp = [] > ** ** parse_list = all_parsers > ** ** max_lvl = len(parse_list) - 1 > ** ** for lvl, psr_c in enumerate(parse_list): > ** ** ** ** # print("temp:", temp[0][:20]) > ** ** ** ** if lvl == 0: > ** ** ** ** ** ** temp.append(str_in.split(psr_c)) > ** ** ** ** else: > ** ** ** ** ** ** pre_lvl = lvl - 1 > ** ** ** ** ** ** new_lvl = recursive_parse(temp[pre_lvl], psr_c) > ** ** ** ** ** ** temp.append(new_lvl) > ** ** big_list = temp[max_lvl] > ** ** return big_list > > _______________________________________________ > TriZPUG mailing list > TriZPUG at python.org > https://mail.python.org/mailman/listinfo/trizpug > http://tripython.org is the Triangle Python Users Group > -------------- next part -------------- On Sep 14, 2017 9:33 AM, "Ken MacKenzie" <[1]ken at mack-z.com> wrote: > > ** **So I have a bit of code I have created that works to solve the problem, > ** **however as an academic exercise, I realized I could not reason of a way to > ** **solve it without recursion. My understanding of computer science says that recursion is never necessary. There is always a way to solve the problem without recursion. > ** **The situation, I have a file with many possible delimiters and those > ** **delimiters have levels so to speak so as I am kind of parsing a tree, and > ** **in this case a tree that is lists of lists of lists of x n... > ** **Excuse the lack of real commenting in this sample.** But curious what > ** **other ways I could solve it, or if there are ways I could perhaps make it > ** **perform faster.** It performs fast enough but I realize the file could get > ** **quite long. It would be very helpful if you would give us a sample input and the corresponding output. Your description above does not help. Also your code has lots of** in it that I presume are either spaces or tabs. I would appreciate it if you would post the code that is actually executable. My guess is that there's a much simpler way to do this. > ** **======= > ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", "\x05", "\x06", > ** **"\x07"] > ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] > ** **all_parsers = parse_1 + parse_2 > ** **def recursive_parse(in_var, parse_char): > ** **** ** if isinstance(in_var, list): > ** **** ** ** ** return [recursive_parse(x, parse_char) for x in in_var] > ** **** ** elif isinstance(in_var, str): > ** **** ** ** ** return in_var.split(parse_char) > ** **def nested_parse(str_in): > ** **** ** big_list = [] > ** **** ** temp = [] > ** **** ** parse_list = all_parsers > ** **** ** max_lvl = len(parse_list) - 1 > ** **** ** for lvl, psr_c in enumerate(parse_list): > ** **** ** ** ** # print("temp:", temp[0][:20]) > ** **** ** ** ** if lvl == 0: > ** **** ** ** ** ** ** temp.append(str_in.split(psr_c)) > ** **** ** ** ** else: > ** **** ** ** ** ** ** pre_lvl = lvl - 1 > ** **** ** ** ** ** ** new_lvl = recursive_parse(temp[pre_lvl], psr_c) > ** **** ** ** ** ** ** temp.append(new_lvl) > ** **** ** big_list = temp[max_lvl] > ** **** ** return big_list > > _______________________________________________ > TriZPUG mailing list > [2]TriZPUG at python.org > [3]https://mail.python.org/mailman/listinfo/trizpug > [4]http://tripython.org is the Triangle Python Users Group > References Visible links 1. mailto:ken at mack-z.com 2. mailto:TriZPUG at python.org 3. https://mail.python.org/mailman/listinfo/trizpug 4. http://tripython.org/ From willspearman at gmail.com Fri Sep 15 08:56:42 2017 From: willspearman at gmail.com (Will Spearman) Date: Fri, 15 Sep 2017 12:56:42 +0000 Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: References: Message-ID: Sharing it as a github gist is helpful. Try this: https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 On Fri, Sep 15, 2017 at 8:48 AM Bob Gailer wrote: > On Sep 14, 2017 9:33 AM, "Ken MacKenzie" <[1]ken at mack-z.com> wrote: > > > > ** **So I have a bit of code I have created that works to solve the > problem, > > ** **however as an academic exercise, I realized I could not reason > of a > way to > > ** **solve it without recursion. > > My understanding of computer science says that recursion is never > necessary. There is always a way to solve the problem without recursion. > > ** **The situation, I have a file with many possible delimiters and > those > > ** **delimiters have levels so to speak so as I am kind of parsing a > tree, and > > ** **in this case a tree that is lists of lists of lists of x n... > > ** **Excuse the lack of real commenting in this sample.** But curious > what > > ** **other ways I could solve it, or if there are ways I could perhaps > make it > > ** **perform faster.** It performs fast enough but I realize the file > could get > > ** **quite long. > It would be very helpful if you would give us a sample input and the > corresponding output. Your description above does not help. > Also your code has lots of** in it that I presume are either spaces or > tabs. > I would appreciate it if you would post the code that is actually > executable. > My guess is that there's a much simpler way to do this. > > ** **======= > > ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", "\x05", > "\x06", > > ** **"\x07"] > > ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] > > ** **all_parsers = parse_1 + parse_2 > > ** **def recursive_parse(in_var, parse_char): > > ** **** ** if isinstance(in_var, list): > > ** **** ** ** ** return [recursive_parse(x, parse_char) for x in > in_var] > > ** **** ** elif isinstance(in_var, str): > > ** **** ** ** ** return in_var.split(parse_char) > > ** **def nested_parse(str_in): > > ** **** ** big_list = [] > > ** **** ** temp = [] > > ** **** ** parse_list = all_parsers > > ** **** ** max_lvl = len(parse_list) - 1 > > ** **** ** for lvl, psr_c in enumerate(parse_list): > > ** **** ** ** ** # print("temp:", temp[0][:20]) > > ** **** ** ** ** if lvl == 0: > > ** **** ** ** ** ** ** temp.append(str_in.split(psr_c)) > > ** **** ** ** ** else: > > ** **** ** ** ** ** ** pre_lvl = lvl - 1 > > ** **** ** ** ** ** ** new_lvl = recursive_parse(temp[pre_lvl], psr_c) > > ** **** ** ** ** ** ** temp.append(new_lvl) > > ** **** ** big_list = temp[max_lvl] > > ** **** ** return big_list > > > > _______________________________________________ > > TriZPUG mailing list > > [2]TriZPUG at python.org > > [3]https://mail.python.org/mailman/listinfo/trizpug > > [4]http://tripython.org is the Triangle Python Users Group > > > > References > > Visible links > 1. mailto:ken at mack-z.com > 2. mailto:TriZPUG at python.org > 3. https://mail.python.org/mailman/listinfo/trizpug > 4. http://tripython.org/ > _______________________________________________ > TriZPUG mailing list > TriZPUG at python.org > https://mail.python.org/mailman/listinfo/trizpug > http://tripython.org is the Triangle Python Users Group > -------------- next part -------------- Sharing it as a github gist is helpful. Try this: [1]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 On Fri, Sep 15, 2017 at 8:48 AM Bob Gailer <[2]bgailer at gmail.com> wrote: ** **On Sep 14, 2017 9:33 AM, "Ken MacKenzie" <[1][3]ken at mack-z.com> wrote: ** **> ** **> ** **So I have a bit of code I have created that works to solve the ** **problem, ** **> ** **however as an academic exercise, I realized I could not reason of a ** **way to ** **> ** **solve it without recursion. ** **My understanding of computer science says that recursion is never ** **necessary. There is always a way to solve the problem without recursion. ** **> ** **The situation, I have a file with many possible delimiters and ** **those ** **> ** **delimiters have levels so to speak so as I am kind of parsing a ** **tree, and ** **> ** **in this case a tree that is lists of lists of lists of x n... ** **> ** **Excuse the lack of real commenting in this sample.** But curious ** **what ** **> ** **other ways I could solve it, or if there are ways I could perhaps ** **make it ** **> ** **perform faster.** It performs fast enough but I realize the file ** **could get ** **> ** **quite long. ** **It would be very helpful if you would give us a sample input and the ** **corresponding output. Your description above does not help. ** **Also your code has lots of** in it that I presume are either spaces or ** **tabs. ** **I would appreciate it if you would post the code that is actually ** **executable. ** **My guess is that there's a much simpler way to do this. ** **> ** **======= ** **> ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", "\x05", ** **"\x06", ** **> ** **"\x07"] ** **> ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] ** **> ** **all_parsers = parse_1 + parse_2 ** **> ** **def recursive_parse(in_var, parse_char): ** **> ** **** ** if isinstance(in_var, list): ** **> ** **** ** ** ** return [recursive_parse(x, parse_char) for x in in_var] ** **> ** **** ** elif isinstance(in_var, str): ** **> ** **** ** ** ** return in_var.split(parse_char) ** **> ** **def nested_parse(str_in): ** **> ** **** ** big_list = [] ** **> ** **** ** temp = [] ** **> ** **** ** parse_list = all_parsers ** **> ** **** ** max_lvl = len(parse_list) - 1 ** **> ** **** ** for lvl, psr_c in enumerate(parse_list): ** **> ** **** ** ** ** # print("temp:", temp[0][:20]) ** **> ** **** ** ** ** if lvl == 0: ** **> ** **** ** ** ** ** ** temp.append(str_in.split(psr_c)) ** **> ** **** ** ** ** else: ** **> ** **** ** ** ** ** ** pre_lvl = lvl - 1 ** **> ** **** ** ** ** ** ** new_lvl = recursive_parse(temp[pre_lvl], psr_c) ** **> ** **** ** ** ** ** ** temp.append(new_lvl) ** **> ** **** ** big_list = temp[max_lvl] ** **> ** **** ** return big_list ** **> ** **> _______________________________________________ ** **> TriZPUG mailing list ** **> [2][4]TriZPUG at python.org ** **> [3][5]https://mail.python.org/mailman/listinfo/trizpug ** **> [4][6]http://tripython.org is the Triangle Python Users Group ** **> References ** **Visible links ** **1. mailto:[7]ken at mack-z.com ** **2. mailto:[8]TriZPUG at python.org ** **3. [9]https://mail.python.org/mailman/listinfo/trizpug ** **4. [10]http://tripython.org/ _______________________________________________ TriZPUG mailing list [11]TriZPUG at python.org [12]https://mail.python.org/mailman/listinfo/trizpug [13]http://tripython.org is the Triangle Python Users Group References Visible links 1. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 2. mailto:bgailer at gmail.com 3. mailto:ken at mack-z.com 4. mailto:TriZPUG at python.org 5. https://mail.python.org/mailman/listinfo/trizpug 6. http://tripython.org/ 7. mailto:ken at mack-z.com 8. mailto:TriZPUG at python.org 9. https://mail.python.org/mailman/listinfo/trizpug 10. http://tripython.org/ 11. mailto:TriZPUG at python.org 12. https://mail.python.org/mailman/listinfo/trizpug 13. http://tripython.org/ From chris at archimedeanco.com Fri Sep 15 08:57:46 2017 From: chris at archimedeanco.com (Chris Rossi) Date: Fri, 15 Sep 2017 08:57:46 -0400 Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: References: Message-ID: http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html On Fri, Sep 15, 2017 at 8:56 AM, Will Spearman wrote: > Sharing it as a github gist is helpful. Try this: > [1]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2 > f8 > On Fri, Sep 15, 2017 at 8:48 AM Bob Gailer <[2]bgailer at gmail.com> > wrote: > > ** **On Sep 14, 2017 9:33 AM, "Ken MacKenzie" <[1][3]ken at mack-z.com> > wrote: > ** **> > ** **> ** **So I have a bit of code I have created that works to solve > the > ** **problem, > ** **> ** **however as an academic exercise, I realized I could not > reason of a > ** **way to > ** **> ** **solve it without recursion. > > ** **My understanding of computer science says that recursion is never > ** **necessary. There is always a way to solve the problem without > recursion. > ** **> ** **The situation, I have a file with many possible delimiters > and > ** **those > ** **> ** **delimiters have levels so to speak so as I am kind of > parsing a > ** **tree, and > ** **> ** **in this case a tree that is lists of lists of lists of x > n... > ** **> ** **Excuse the lack of real commenting in this sample.** But > curious > ** **what > ** **> ** **other ways I could solve it, or if there are ways I could > perhaps > ** **make it > ** **> ** **perform faster.** It performs fast enough but I realize > the > file > ** **could get > ** **> ** **quite long. > ** **It would be very helpful if you would give us a sample input and > the > ** **corresponding output. Your description above does not help. > ** **Also your code has lots of** in it that I presume are either > spaces > or > ** **tabs. > ** **I would appreciate it if you would post the code that is actually > ** **executable. > ** **My guess is that there's a much simpler way to do this. > ** **> ** **======= > ** **> ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", > "\x05", > ** **"\x06", > ** **> ** **"\x07"] > ** **> ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] > ** **> ** **all_parsers = parse_1 + parse_2 > ** **> ** **def recursive_parse(in_var, parse_char): > ** **> ** **** ** if isinstance(in_var, list): > ** **> ** **** ** ** ** return [recursive_parse(x, parse_char) for x > in > in_var] > ** **> ** **** ** elif isinstance(in_var, str): > ** **> ** **** ** ** ** return in_var.split(parse_char) > ** **> ** **def nested_parse(str_in): > ** **> ** **** ** big_list = [] > ** **> ** **** ** temp = [] > ** **> ** **** ** parse_list = all_parsers > ** **> ** **** ** max_lvl = len(parse_list) - 1 > ** **> ** **** ** for lvl, psr_c in enumerate(parse_list): > ** **> ** **** ** ** ** # print("temp:", temp[0][:20]) > ** **> ** **** ** ** ** if lvl == 0: > ** **> ** **** ** ** ** ** ** temp.append(str_in.split(psr_c)) > ** **> ** **** ** ** ** else: > ** **> ** **** ** ** ** ** ** pre_lvl = lvl - 1 > ** **> ** **** ** ** ** ** ** new_lvl = recursive_parse(temp[pre_lvl], > psr_c) > ** **> ** **** ** ** ** ** ** temp.append(new_lvl) > ** **> ** **** ** big_list = temp[max_lvl] > ** **> ** **** ** return big_list > ** **> > ** **> _______________________________________________ > ** **> TriZPUG mailing list > ** **> [2][4]TriZPUG at python.org > ** **> [3][5]https://mail.python.org/mailman/listinfo/trizpug > ** **> [4][6]http://tripython.org is the Triangle Python Users Group > ** **> > > References > > ** **Visible links > ** **1. mailto:[7]ken at mack-z.com > ** **2. mailto:[8]TriZPUG at python.org > ** **3. [9]https://mail.python.org/mailman/listinfo/trizpug > ** **4. [10]http://tripython.org/ > _______________________________________________ > TriZPUG mailing list > [11]TriZPUG at python.org > [12]https://mail.python.org/mailman/listinfo/trizpug > [13]http://tripython.org is the Triangle Python Users Group > > References > > Visible links > 1. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2 > f8 > 2. mailto:bgailer at gmail.com > 3. mailto:ken at mack-z.com > 4. mailto:TriZPUG at python.org > 5. https://mail.python.org/mailman/listinfo/trizpug > 6. http://tripython.org/ > 7. mailto:ken at mack-z.com > 8. mailto:TriZPUG at python.org > 9. https://mail.python.org/mailman/listinfo/trizpug > 10. http://tripython.org/ > 11. mailto:TriZPUG at python.org > 12. https://mail.python.org/mailman/listinfo/trizpug > 13. http://tripython.org/ > > _______________________________________________ > TriZPUG mailing list > TriZPUG at python.org > https://mail.python.org/mailman/listinfo/trizpug > http://tripython.org is the Triangle Python Users Group > > -------------- next part -------------- [1]http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html On Fri, Sep 15, 2017 at 8:56 AM, Will Spearman <[2]willspearman at gmail.com> wrote: ** **Sharing it as a github gist is helpful. Try this: ** **[1][3]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 ** **On Fri, Sep 15, 2017 at 8:48 AM Bob Gailer <[2][4]bgailer at gmail.com> wrote: ** ** **** **On Sep 14, 2017 9:33 AM, "Ken MacKenzie" <[1][3][5]ken at mack-z.com> ** ** **wrote: ** ** **** **> ** ** **** **> ** **So I have a bit of code I have created that works to solve ** ** **the ** ** **** **problem, ** ** **** **> ** **however as an academic exercise, I realized I could not ** ** **reason of a ** ** **** **way to ** ** **** **> ** **solve it without recursion. ** ** **** **My understanding of computer science says that recursion is never ** ** **** **necessary. There is always a way to solve the problem without ** ** **recursion. ** ** **** **> ** **The situation, I have a file with many possible delimiters ** ** **and ** ** **** **those ** ** **** **> ** **delimiters have levels so to speak so as I am kind of ** ** **parsing a ** ** **** **tree, and ** ** **** **> ** **in this case a tree that is lists of lists of lists of x ** ** **n... ** ** **** **> ** **Excuse the lack of real commenting in this sample.** But ** ** **curious ** ** **** **what ** ** **** **> ** **other ways I could solve it, or if there are ways I could ** ** **perhaps ** ** **** **make it ** ** **** **> ** **perform faster.** It performs fast enough but I realize the ** ** **file ** ** **** **could get ** ** **** **> ** **quite long. ** ** **** **It would be very helpful if you would give us a sample input and ** ** **the ** ** **** **corresponding output. Your description above does not help. ** ** **** **Also your code has lots of** in it that I presume are either spaces ** ** **or ** ** **** **tabs. ** ** **** **I would appreciate it if you would post the code that is actually ** ** **** **executable. ** ** **** **My guess is that there's a much simpler way to do this. ** ** **** **> ** **======= ** ** **** **> ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", ** ** **"\x05", ** ** **** **"\x06", ** ** **** **> ** **"\x07"] ** ** **** **> ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] ** ** **** **> ** **all_parsers = parse_1 + parse_2 ** ** **** **> ** **def recursive_parse(in_var, parse_char): ** ** **** **> ** **** ** if isinstance(in_var, list): ** ** **** **> ** **** ** ** ** return [recursive_parse(x, parse_char) for x in ** ** **in_var] ** ** **** **> ** **** ** elif isinstance(in_var, str): ** ** **** **> ** **** ** ** ** return in_var.split(parse_char) ** ** **** **> ** **def nested_parse(str_in): ** ** **** **> ** **** ** big_list = [] ** ** **** **> ** **** ** temp = [] ** ** **** **> ** **** ** parse_list = all_parsers ** ** **** **> ** **** ** max_lvl = len(parse_list) - 1 ** ** **** **> ** **** ** for lvl, psr_c in enumerate(parse_list): ** ** **** **> ** **** ** ** ** # print("temp:", temp[0][:20]) ** ** **** **> ** **** ** ** ** if lvl == 0: ** ** **** **> ** **** ** ** ** ** ** temp.append(str_in.split(psr_c)) ** ** **** **> ** **** ** ** ** else: ** ** **** **> ** **** ** ** ** ** ** pre_lvl = lvl - 1 ** ** **** **> ** **** ** ** ** ** ** new_lvl = recursive_parse(temp[pre_lvl], ** ** **psr_c) ** ** **** **> ** **** ** ** ** ** ** temp.append(new_lvl) ** ** **** **> ** **** ** big_list = temp[max_lvl] ** ** **** **> ** **** ** return big_list ** ** **** **> ** ** **** **> _______________________________________________ ** ** **** **> TriZPUG mailing list ** ** **** **> [2][4][6]TriZPUG at python.org ** ** **** **> [3][5][7]https://mail.python.org/mailman/listinfo/trizpug ** ** **** **> [4][6][8]http://tripython.org is the Triangle Python Users Group ** ** **** **> ** ** **References ** ** **** **Visible links ** ** **** **1. mailto:[7][9]ken at mack-z.com ** ** **** **2. mailto:[8][10]TriZPUG at python.org ** ** **** **3. [9][11]https://mail.python.org/mailman/listinfo/trizpug ** ** **** **4. [10][12]http://tripython.org/ ** ** **_______________________________________________ ** ** **TriZPUG mailing list ** ** **[11][13]TriZPUG at python.org ** ** **[12][14]https://mail.python.org/mailman/listinfo/trizpug ** ** **[13][15]http://tripython.org is the Triangle Python Users Group References ** **Visible links ** **1. [16]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 ** **2. mailto:[17]bgailer at gmail.com ** **3. mailto:[18]ken at mack-z.com ** **4. mailto:[19]TriZPUG at python.org ** **5. [20]https://mail.python.org/mailman/listinfo/trizpug ** **6. [21]http://tripython.org/ ** **7. mailto:[22]ken at mack-z.com ** **8. mailto:[23]TriZPUG at python.org ** **9. [24]https://mail.python.org/mailman/listinfo/trizpug ** 10. [25]http://tripython.org/ ** 11. mailto:[26]TriZPUG at python.org ** 12. [27]https://mail.python.org/mailman/listinfo/trizpug ** 13. [28]http://tripython.org/ _______________________________________________ TriZPUG mailing list [29]TriZPUG at python.org [30]https://mail.python.org/mailman/listinfo/trizpug [31]http://tripython.org is the Triangle Python Users Group References Visible links 1. http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html 2. mailto:willspearman at gmail.com 3. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 4. mailto:bgailer at gmail.com 5. mailto:ken at mack-z.com 6. mailto:TriZPUG at python.org 7. https://mail.python.org/mailman/listinfo/trizpug 8. http://tripython.org/ 9. mailto:ken at mack-z.com 10. mailto:TriZPUG at python.org 11. https://mail.python.org/mailman/listinfo/trizpug 12. http://tripython.org/ 13. mailto:TriZPUG at python.org 14. https://mail.python.org/mailman/listinfo/trizpug 15. http://tripython.org/ 16. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 17. mailto:bgailer at gmail.com 18. mailto:ken at mack-z.com 19. mailto:TriZPUG at python.org 20. https://mail.python.org/mailman/listinfo/trizpug 21. http://tripython.org/ 22. mailto:ken at mack-z.com 23. mailto:TriZPUG at python.org 24. https://mail.python.org/mailman/listinfo/trizpug 25. http://tripython.org/ 26. mailto:TriZPUG at python.org 27. https://mail.python.org/mailman/listinfo/trizpug 28. http://tripython.org/ 29. mailto:TriZPUG at python.org 30. https://mail.python.org/mailman/listinfo/trizpug 31. http://tripython.org/ From david at handysoftware.com Fri Sep 15 09:01:41 2017 From: david at handysoftware.com (David Handy) Date: Fri, 15 Sep 2017 09:01:41 -0400 (EDT) Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: References: Message-ID: <1505480501.405724223@apps.rackspace.com> Hi Ken - Since no one else is answering, I guess I'll speak up. You asked some general questions, so I'll give some general answers. Yes, it is always possible to solve a recursive problem without actually doing recursive function calls. But it usually requires building some kind of stack, and in your main loop, pushing and popping things off of that stack. A Python list works great as a stack because pushing (appending) to the end and popping off of the end of a Python list are efficient operations. Recursive function calls sometimes is the right approach for clear and performant code, but one exception to that is if the nesting can get very deep. The sys.getrecursionlimit() will tell you how many levels deep you can call functions. Generally the limit is 1000. If your parser runs fast enough, I don't know that I'd spend my time or yours trying to speed it up. But if the file could get up to gigabytes in size, then you have a memory problem. Reading the whole file into a string like you did can be fast for small files, but for bigger files you can run out of memory, especially since your code will essentially make several copies of the same data (one string containing the entire file, a list containing the entire file split on the first delimiter, etc.) To get around that, you'd have to read the file a chunk at a time, then process each chunk using a [ finite state machine ]( https://en.wikipedia.org/wiki/Finite-state_machine#Finite_state_machines_and_compilers ) to break it down into tokens, using your series of delimiters. This would require a complete reorganization of your code. If your file size will not be more than a few megabytes it probably isn't worth it unless you wish to do it as a learning exercise. The other half of the parsing problem is the eventual data structure you want to build, which you did not describe at all. I have additional feedback on your variable names, but won't give it unless you ask. :) I hope this is helpful - David H On Thursday, September 14, 2017 9:32am, "Ken MacKenzie" said: > _______________________________________________ > TriZPUG mailing list > TriZPUG at python.org > https://mail.python.org/mailman/listinfo/trizpug > http://tripython.org is the Triangle Python Users Group > So I have a bit of code I have created that works to solve the problem, > however as an academic exercise, I realized I could not reason of a way to > solve it without recursion. > > The situation, I have a file with many possible delimiters and those > delimiters have levels so to speak so as I am kind of parsing a tree, and > in this case a tree that is lists of lists of lists of x n... > > Excuse the lack of real commenting in this sample. But curious what other > ways I could solve it, or if there are ways I could perhaps make it perform > faster. It performs fast enough but I realize the file could get quite > long. > > ======= > parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", "\x05", "\x06", > "\x07"] > parse_2 = [chr(255), chr(254), chr(253), chr(252)] > all_parsers = parse_1 + parse_2 > > > def recursive_parse(in_var, parse_char): > if isinstance(in_var, list): > return [recursive_parse(x, parse_char) for x in in_var] > elif isinstance(in_var, str): > return in_var.split(parse_char) > > > def nested_parse(str_in): > big_list = [] > temp = [] > parse_list = all_parsers > max_lvl = len(parse_list) - 1 > for lvl, psr_c in enumerate(parse_list): > # print("temp:", temp[0][:20]) > if lvl == 0: > temp.append(str_in.split(psr_c)) > else: > pre_lvl = lvl - 1 > new_lvl = recursive_parse(temp[pre_lvl], psr_c) > temp.append(new_lvl) > > big_list = temp[max_lvl] > return big_list > So I have a bit of code I have created that works to solve the problem, > however as an academic exercise, I realized I could not reason of a way to > solve it without recursion. > The situation, I have a file with many possible delimiters and those > delimiters have levels so to speak so as I am kind of parsing a tree, and > in this case a tree that is lists of lists of lists of x n... > Excuse the lack of real commenting in this sample.** But curious what > other ways I could solve it, or if there are ways I could perhaps make it > perform faster.** It performs fast enough but I realize the file could get > quite long. > ======= > parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", "\x05", "\x06", > "\x07"] > parse_2 = [chr(255), chr(254), chr(253), chr(252)] > all_parsers = parse_1 + parse_2 > def recursive_parse(in_var, parse_char): > ** ** if isinstance(in_var, list): > ** ** ** ** return [recursive_parse(x, parse_char) for x in in_var] > ** ** elif isinstance(in_var, str): > ** ** ** ** return in_var.split(parse_char) > def nested_parse(str_in): > ** ** big_list = [] > ** ** temp = [] > ** ** parse_list = all_parsers > ** ** max_lvl = len(parse_list) - 1 > ** ** for lvl, psr_c in enumerate(parse_list): > ** ** ** ** # print("temp:", temp[0][:20]) > ** ** ** ** if lvl == 0: > ** ** ** ** ** ** temp.append(str_in.split(psr_c)) > ** ** ** ** else: > ** ** ** ** ** ** pre_lvl = lvl - 1 > ** ** ** ** ** ** new_lvl = recursive_parse(temp[pre_lvl], psr_c) > ** ** ** ** ** ** temp.append(new_lvl) > ** ** big_list = temp[max_lvl] > ** ** return big_list > -------------- next part -------------- Hi Ken - Since no one else is answering, I guess I'll speak up. You asked some general questions, so I'll give some general answers. Yes, it is always possible to solve a recursive problem without actually doing recursive function calls. But it usually requires building some kind of stack, and in your main loop, pushing and popping things off of that stack. A Python list works great as a stack because pushing (appending) to the end and popping off of the end of a Python list are efficient operations. Recursive function calls sometimes is the right approach for clear and performant code, but one exception to that is if the nesting can get very deep. The sys.getrecursionlimit() will tell you how many levels deep you can call functions. Generally the limit is 1000. If your parser runs fast enough, I don't know that I'd spend my time or yours trying to speed it up. But if the file could get up to gigabytes in size, then you have a memory problem. Reading the whole file into a string like you did can be fast for small files, but for bigger files you can run out of memory, especially since your code will essentially make several copies of the same data (one string containing the entire file, a list containing the entire file split on the first delimiter, etc.) To get around that, you'd have to read the file a chunk at a time, then process each chunk using a [1]finite state machine to break it down into tokens, using your series of delimiters. This would require a complete reorganization of your code. If your file size will not be more than a few megabytes it probably isn't worth it unless you wish to do it as a learning exercise. The other half of the parsing problem is the eventual data structure you want to build, which you did not describe at all. I have additional feedback on your variable names, but won't give it unless you ask. :) I hope this is helpful - David H On Thursday, September 14, 2017 9:32am, "Ken MacKenzie" said: > _______________________________________________ > TriZPUG mailing list > TriZPUG at python.org > https://mail.python.org/mailman/listinfo/trizpug > http://tripython.org is the Triangle Python Users Group > So I have a bit of code I have created that works to solve the problem, > however as an academic exercise, I realized I could not reason of a way to > solve it without recursion. > > The situation, I have a file with many possible delimiters and those > delimiters have levels so to speak so as I am kind of parsing a tree, and > in this case a tree that is lists of lists of lists of x n... > > Excuse the lack of real commenting in this sample. But curious what other > ways I could solve it, or if there are ways I could perhaps make it perform > faster. It performs fast enough but I realize the file could get quite > long. > > ======= > parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", "\x05", "\x06", > "\x07"] > parse_2 = [chr(255), chr(254), chr(253), chr(252)] > all_parsers = parse_1 + parse_2 > > > def recursive_parse(in_var, parse_char): > if isinstance(in_var, list): > return [recursive_parse(x, parse_char) for x in in_var] > elif isinstance(in_var, str): > return in_var.split(parse_char) > > > def nested_parse(str_in): > big_list = [] > temp = [] > parse_list = all_parsers > max_lvl = len(parse_list) - 1 > for lvl, psr_c in enumerate(parse_list): > # print("temp:", temp[0][:20]) > if lvl == 0: > temp.append(str_in.split(psr_c)) > else: > pre_lvl = lvl - 1 > new_lvl = recursive_parse(temp[pre_lvl], psr_c) > temp.append(new_lvl) > > big_list = temp[max_lvl] > return big_list > So I have a bit of code I have created that works to solve the problem, > however as an academic exercise, I realized I could not reason of a way to > solve it without recursion. > The situation, I have a file with many possible delimiters and those > delimiters have levels so to speak so as I am kind of parsing a tree, and > in this case a tree that is lists of lists of lists of x n... > Excuse the lack of real commenting in this sample.** But curious what > other ways I could solve it, or if there are ways I could perhaps make it > perform faster.** It performs fast enough but I realize the file could get > quite long. > ======= > parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", "\x05", "\x06", > "\x07"] > parse_2 = [chr(255), chr(254), chr(253), chr(252)] > all_parsers = parse_1 + parse_2 > def recursive_parse(in_var, parse_char): > ** ** if isinstance(in_var, list): > ** ** ** ** return [recursive_parse(x, parse_char) for x in in_var] > ** ** elif isinstance(in_var, str): > ** ** ** ** return in_var.split(parse_char) > def nested_parse(str_in): > ** ** big_list = [] > ** ** temp = [] > ** ** parse_list = all_parsers > ** ** max_lvl = len(parse_list) - 1 > ** ** for lvl, psr_c in enumerate(parse_list): > ** ** ** ** # print("temp:", temp[0][:20]) > ** ** ** ** if lvl == 0: > ** ** ** ** ** ** temp.append(str_in.split(psr_c)) > ** ** ** ** else: > ** ** ** ** ** ** pre_lvl = lvl - 1 > ** ** ** ** ** ** new_lvl = recursive_parse(temp[pre_lvl], psr_c) > ** ** ** ** ** ** temp.append(new_lvl) > ** ** big_list = temp[max_lvl] > ** ** return big_list > References Visible links 1. https://en.wikipedia.org/wiki/Finite-state_machine#Finite_state_machines_and_compilers From david at handysoftware.com Fri Sep 15 09:17:57 2017 From: david at handysoftware.com (David Handy) Date: Fri, 15 Sep 2017 09:17:57 -0400 (EDT) Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: References: Message-ID: <1505481477.451223558@apps.rackspace.com> This is hilarious. While I was typing and editing my response beginning with "Since no one else is answering ...", three other people sent replies! I like the link Chris Rossi sent about how to turn a recursive algorithm into an iterative one. My advice I gave using a Python list as a stack is an example of the "accumulator" that the linked article talks about, for the case where a more simple accumulator such as an integer isn't enough information. An example would be if you are writing code to parse an XML document, the accumulator/stack could be the list of nested tags you have encountered so far during processing. David H On Friday, September 15, 2017 8:57am, "Chris Rossi" said: > _______________________________________________ > TriZPUG mailing list > TriZPUG at python.org > https://mail.python.org/mailman/listinfo/trizpug > http://tripython.org is the Triangle Python Users Group > http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html > > On Fri, Sep 15, 2017 at 8:56 AM, Will Spearman > wrote: > > > Sharing it as a github gist is helpful. Try this: > > [1]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2 > > f8 > > On Fri, Sep 15, 2017 at 8:48 AM Bob Gailer <[2]bgailer at gmail.com> > > wrote: > > > > ** **On Sep 14, 2017 9:33 AM, "Ken MacKenzie" > <[1][3]ken at mack-z.com> > > wrote: > > ** **> > > ** **> ** **So I have a bit of code I have created that works to > solve > > the > > ** **problem, > > ** **> ** **however as an academic exercise, I realized I could not > > reason of a > > ** **way to > > ** **> ** **solve it without recursion. > > > > ** **My understanding of computer science says that recursion is never > > ** **necessary. There is always a way to solve the problem without > > recursion. > > ** **> ** **The situation, I have a file with many possible > delimiters > > and > > ** **those > > ** **> ** **delimiters have levels so to speak so as I am kind of > > parsing a > > ** **tree, and > > ** **> ** **in this case a tree that is lists of lists of lists of x > > n... > > ** **> ** **Excuse the lack of real commenting in this sample.** But > > curious > > ** **what > > ** **> ** **other ways I could solve it, or if there are ways I > could > > perhaps > > ** **make it > > ** **> ** **perform faster.** It performs fast enough but I realize > > the > > file > > ** **could get > > ** **> ** **quite long. > > ** **It would be very helpful if you would give us a sample input and > > the > > ** **corresponding output. Your description above does not help. > > ** **Also your code has lots of** in it that I presume are either > > spaces > > or > > ** **tabs. > > ** **I would appreciate it if you would post the code that is actually > > ** **executable. > > ** **My guess is that there's a much simpler way to do this. > > ** **> ** **======= > > ** **> ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", > > "\x05", > > ** **"\x06", > > ** **> ** **"\x07"] > > ** **> ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] > > ** **> ** **all_parsers = parse_1 + parse_2 > > ** **> ** **def recursive_parse(in_var, parse_char): > > ** **> ** **** ** if isinstance(in_var, list): > > ** **> ** **** ** ** ** return [recursive_parse(x, parse_char) for x > > in > > in_var] > > ** **> ** **** ** elif isinstance(in_var, str): > > ** **> ** **** ** ** ** return in_var.split(parse_char) > > ** **> ** **def nested_parse(str_in): > > ** **> ** **** ** big_list = [] > > ** **> ** **** ** temp = [] > > ** **> ** **** ** parse_list = all_parsers > > ** **> ** **** ** max_lvl = len(parse_list) - 1 > > ** **> ** **** ** for lvl, psr_c in enumerate(parse_list): > > ** **> ** **** ** ** ** # print("temp:", temp[0][:20]) > > ** **> ** **** ** ** ** if lvl == 0: > > ** **> ** **** ** ** ** ** ** temp.append(str_in.split(psr_c)) > > ** **> ** **** ** ** ** else: > > ** **> ** **** ** ** ** ** ** pre_lvl = lvl - 1 > > ** **> ** **** ** ** ** ** ** new_lvl = > recursive_parse(temp[pre_lvl], > > psr_c) > > ** **> ** **** ** ** ** ** ** temp.append(new_lvl) > > ** **> ** **** ** big_list = temp[max_lvl] > > ** **> ** **** ** return big_list > > ** **> > > ** **> _______________________________________________ > > ** **> TriZPUG mailing list > > ** **> [2][4]TriZPUG at python.org > > ** **> [3][5]https://mail.python.org/mailman/listinfo/trizpug > > ** **> [4][6]http://tripython.org is the Triangle Python Users Group > > ** **> > > > > References > > > > ** **Visible links > > ** **1. mailto:[7]ken at mack-z.com > > ** **2. mailto:[8]TriZPUG at python.org > > ** **3. [9]https://mail.python.org/mailman/listinfo/trizpug > > ** **4. [10]http://tripython.org/ > > _______________________________________________ > > TriZPUG mailing list > > [11]TriZPUG at python.org > > [12]https://mail.python.org/mailman/listinfo/trizpug > > [13]http://tripython.org is the Triangle Python Users Group > > > > References > > > > Visible links > > 1. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2 > > f8 > > 2. mailto:bgailer at gmail.com > > 3. mailto:ken at mack-z.com > > 4. mailto:TriZPUG at python.org > > 5. https://mail.python.org/mailman/listinfo/trizpug > > 6. http://tripython.org/ > > 7. mailto:ken at mack-z.com > > 8. mailto:TriZPUG at python.org > > 9. https://mail.python.org/mailman/listinfo/trizpug > > 10. http://tripython.org/ > > 11. mailto:TriZPUG at python.org > > 12. https://mail.python.org/mailman/listinfo/trizpug > > 13. http://tripython.org/ > > > > _______________________________________________ > > TriZPUG mailing list > > TriZPUG at python.org > > https://mail.python.org/mailman/listinfo/trizpug > > http://tripython.org is the Triangle Python Users Group > > > > > [1]http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html > On Fri, Sep 15, 2017 at 8:56 AM, Will Spearman > <[2]willspearman at gmail.com> > wrote: > > ** **Sharing it as a github gist is helpful. Try this: > ** > **[1][3]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 > ** **On Fri, Sep 15, 2017 at 8:48 AM Bob Gailer > <[2][4]bgailer at gmail.com> wrote: > > ** ** **** **On Sep 14, 2017 9:33 AM, "Ken MacKenzie" > <[1][3][5]ken at mack-z.com> > ** ** **wrote: > ** ** **** **> > ** ** **** **> ** **So I have a bit of code I have created that works to > solve > ** ** **the > ** ** **** **problem, > ** ** **** **> ** **however as an academic exercise, I realized I could > not > ** ** **reason of a > ** ** **** **way to > ** ** **** **> ** **solve it without recursion. > > ** ** **** **My understanding of computer science says that recursion is > never > ** ** **** **necessary. There is always a way to solve the problem > without > ** ** **recursion. > ** ** **** **> ** **The situation, I have a file with many possible > delimiters > ** ** **and > ** ** **** **those > ** ** **** **> ** **delimiters have levels so to speak so as I am kind > of > ** ** **parsing a > ** ** **** **tree, and > ** ** **** **> ** **in this case a tree that is lists of lists of lists > of x > ** ** **n... > ** ** **** **> ** **Excuse the lack of real commenting in this sample.** > But > ** ** **curious > ** ** **** **what > ** ** **** **> ** **other ways I could solve it, or if there are ways I > could > ** ** **perhaps > ** ** **** **make it > ** ** **** **> ** **perform faster.** It performs fast enough but I > realize the > ** ** **file > ** ** **** **could get > ** ** **** **> ** **quite long. > ** ** **** **It would be very helpful if you would give us a sample > input and > ** ** **the > ** ** **** **corresponding output. Your description above does not help. > ** ** **** **Also your code has lots of** in it that I presume are > either spaces > ** ** **or > ** ** **** **tabs. > ** ** **** **I would appreciate it if you would post the code that is > actually > ** ** **** **executable. > ** ** **** **My guess is that there's a much simpler way to do this. > ** ** **** **> ** **======= > ** ** **** **> ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", > "\x04", > ** ** **"\x05", > ** ** **** **"\x06", > ** ** **** **> ** **"\x07"] > ** ** **** **> ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] > ** ** **** **> ** **all_parsers = parse_1 + parse_2 > ** ** **** **> ** **def recursive_parse(in_var, parse_char): > ** ** **** **> ** **** ** if isinstance(in_var, list): > ** ** **** **> ** **** ** ** ** return [recursive_parse(x, parse_char) > for x in > ** ** **in_var] > ** ** **** **> ** **** ** elif isinstance(in_var, str): > ** ** **** **> ** **** ** ** ** return in_var.split(parse_char) > ** ** **** **> ** **def nested_parse(str_in): > ** ** **** **> ** **** ** big_list = [] > ** ** **** **> ** **** ** temp = [] > ** ** **** **> ** **** ** parse_list = all_parsers > ** ** **** **> ** **** ** max_lvl = len(parse_list) - 1 > ** ** **** **> ** **** ** for lvl, psr_c in enumerate(parse_list): > ** ** **** **> ** **** ** ** ** # print("temp:", temp[0][:20]) > ** ** **** **> ** **** ** ** ** if lvl == 0: > ** ** **** **> ** **** ** ** ** ** ** temp.append(str_in.split(psr_c)) > ** ** **** **> ** **** ** ** ** else: > ** ** **** **> ** **** ** ** ** ** ** pre_lvl = lvl - 1 > ** ** **** **> ** **** ** ** ** ** ** new_lvl = > recursive_parse(temp[pre_lvl], > ** ** **psr_c) > ** ** **** **> ** **** ** ** ** ** ** temp.append(new_lvl) > ** ** **** **> ** **** ** big_list = temp[max_lvl] > ** ** **** **> ** **** ** return big_list > ** ** **** **> > ** ** **** **> _______________________________________________ > ** ** **** **> TriZPUG mailing list > ** ** **** **> [2][4][6]TriZPUG at python.org > ** ** **** **> [3][5][7]https://mail.python.org/mailman/listinfo/trizpug > ** ** **** **> [4][6][8]http://tripython.org is the Triangle Python > Users Group > ** ** **** **> > > ** ** **References > > ** ** **** **Visible links > ** ** **** **1. mailto:[7][9]ken at mack-z.com > ** ** **** **2. mailto:[8][10]TriZPUG at python.org > ** ** **** **3. [9][11]https://mail.python.org/mailman/listinfo/trizpug > ** ** **** **4. [10][12]http://tripython.org/ > ** ** **_______________________________________________ > ** ** **TriZPUG mailing list > ** ** **[11][13]TriZPUG at python.org > ** ** **[12][14]https://mail.python.org/mailman/listinfo/trizpug > ** ** **[13][15]http://tripython.org is the Triangle Python Users Group > > References > > ** **Visible links > ** **1. > [16]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 > ** **2. mailto:[17]bgailer at gmail.com > ** **3. mailto:[18]ken at mack-z.com > ** **4. mailto:[19]TriZPUG at python.org > ** **5. [20]https://mail.python.org/mailman/listinfo/trizpug > ** **6. [21]http://tripython.org/ > ** **7. mailto:[22]ken at mack-z.com > ** **8. mailto:[23]TriZPUG at python.org > ** **9. [24]https://mail.python.org/mailman/listinfo/trizpug > ** 10. [25]http://tripython.org/ > ** 11. mailto:[26]TriZPUG at python.org > ** 12. [27]https://mail.python.org/mailman/listinfo/trizpug > ** 13. [28]http://tripython.org/ > > _______________________________________________ > TriZPUG mailing list > [29]TriZPUG at python.org > [30]https://mail.python.org/mailman/listinfo/trizpug > [31]http://tripython.org is the Triangle Python Users Group > > References > > Visible links > 1. http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html > 2. mailto:willspearman at gmail.com > 3. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 > 4. mailto:bgailer at gmail.com > 5. mailto:ken at mack-z.com > 6. mailto:TriZPUG at python.org > 7. https://mail.python.org/mailman/listinfo/trizpug > 8. http://tripython.org/ > 9. mailto:ken at mack-z.com > 10. mailto:TriZPUG at python.org > 11. https://mail.python.org/mailman/listinfo/trizpug > 12. http://tripython.org/ > 13. mailto:TriZPUG at python.org > 14. https://mail.python.org/mailman/listinfo/trizpug > 15. http://tripython.org/ > 16. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 > 17. mailto:bgailer at gmail.com > 18. mailto:ken at mack-z.com > 19. mailto:TriZPUG at python.org > 20. https://mail.python.org/mailman/listinfo/trizpug > 21. http://tripython.org/ > 22. mailto:ken at mack-z.com > 23. mailto:TriZPUG at python.org > 24. https://mail.python.org/mailman/listinfo/trizpug > 25. http://tripython.org/ > 26. mailto:TriZPUG at python.org > 27. https://mail.python.org/mailman/listinfo/trizpug > 28. http://tripython.org/ > 29. mailto:TriZPUG at python.org > 30. https://mail.python.org/mailman/listinfo/trizpug > 31. http://tripython.org/ > -------------- next part -------------- This is hilarious. While I was typing and editing my response beginning with "Since no one else is answering ...", three other people sent replies! I like the link Chris Rossi sent about how to turn a recursive algorithm into an iterative one. My advice I gave using a Python list as a stack is an example of the "accumulator" that the linked article talks about, for the case where a more simple accumulator such as an integer isn't enough information. An example would be if you are writing code to parse an XML document, the accumulator/stack could be the list of nested tags you have encountered so far during processing. David H On Friday, September 15, 2017 8:57am, "Chris Rossi" said: > _______________________________________________ > TriZPUG mailing list > TriZPUG at python.org > https://mail.python.org/mailman/listinfo/trizpug > http://tripython.org is the Triangle Python Users Group > http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html > > On Fri, Sep 15, 2017 at 8:56 AM, Will Spearman > wrote: > > > Sharing it as a github gist is helpful. Try this: > > [1]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2 > > f8 > > On Fri, Sep 15, 2017 at 8:48 AM Bob Gailer <[2]bgailer at gmail.com> > > wrote: > > > > ** **On Sep 14, 2017 9:33 AM, "Ken MacKenzie" > <[1][3]ken at mack-z.com> > > wrote: > > ** **> > > ** **> ** **So I have a bit of code I have created that works to > solve > > the > > ** **problem, > > ** **> ** **however as an academic exercise, I realized I could not > > reason of a > > ** **way to > > ** **> ** **solve it without recursion. > > > > ** **My understanding of computer science says that recursion is never > > ** **necessary. There is always a way to solve the problem without > > recursion. > > ** **> ** **The situation, I have a file with many possible > delimiters > > and > > ** **those > > ** **> ** **delimiters have levels so to speak so as I am kind of > > parsing a > > ** **tree, and > > ** **> ** **in this case a tree that is lists of lists of lists of x > > n... > > ** **> ** **Excuse the lack of real commenting in this sample.** But > > curious > > ** **what > > ** **> ** **other ways I could solve it, or if there are ways I > could > > perhaps > > ** **make it > > ** **> ** **perform faster.** It performs fast enough but I realize > > the > > file > > ** **could get > > ** **> ** **quite long. > > ** **It would be very helpful if you would give us a sample input and > > the > > ** **corresponding output. Your description above does not help. > > ** **Also your code has lots of** in it that I presume are either > > spaces > > or > > ** **tabs. > > ** **I would appreciate it if you would post the code that is actually > > ** **executable. > > ** **My guess is that there's a much simpler way to do this. > > ** **> ** **======= > > ** **> ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", > > "\x05", > > ** **"\x06", > > ** **> ** **"\x07"] > > ** **> ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] > > ** **> ** **all_parsers = parse_1 + parse_2 > > ** **> ** **def recursive_parse(in_var, parse_char): > > ** **> ** **** ** if isinstance(in_var, list): > > ** **> ** **** ** ** ** return [recursive_parse(x, parse_char) for x > > in > > in_var] > > ** **> ** **** ** elif isinstance(in_var, str): > > ** **> ** **** ** ** ** return in_var.split(parse_char) > > ** **> ** **def nested_parse(str_in): > > ** **> ** **** ** big_list = [] > > ** **> ** **** ** temp = [] > > ** **> ** **** ** parse_list = all_parsers > > ** **> ** **** ** max_lvl = len(parse_list) - 1 > > ** **> ** **** ** for lvl, psr_c in enumerate(parse_list): > > ** **> ** **** ** ** ** # print("temp:", temp[0][:20]) > > ** **> ** **** ** ** ** if lvl == 0: > > ** **> ** **** ** ** ** ** ** temp.append(str_in.split(psr_c)) > > ** **> ** **** ** ** ** else: > > ** **> ** **** ** ** ** ** ** pre_lvl = lvl - 1 > > ** **> ** **** ** ** ** ** ** new_lvl = > recursive_parse(temp[pre_lvl], > > psr_c) > > ** **> ** **** ** ** ** ** ** temp.append(new_lvl) > > ** **> ** **** ** big_list = temp[max_lvl] > > ** **> ** **** ** return big_list > > ** **> > > ** **> _______________________________________________ > > ** **> TriZPUG mailing list > > ** **> [2][4]TriZPUG at python.org > > ** **> [3][5]https://mail.python.org/mailman/listinfo/trizpug > > ** **> [4][6]http://tripython.org is the Triangle Python Users Group > > ** **> > > > > References > > > > ** **Visible links > > ** **1. mailto:[7]ken at mack-z.com > > ** **2. mailto:[8]TriZPUG at python.org > > ** **3. [9]https://mail.python.org/mailman/listinfo/trizpug > > ** **4. [10]http://tripython.org/ > > _______________________________________________ > > TriZPUG mailing list > > [11]TriZPUG at python.org > > [12]https://mail.python.org/mailman/listinfo/trizpug > > [13]http://tripython.org is the Triangle Python Users Group > > > > References > > > > Visible links > > 1. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2 > > f8 > > 2. mailto:bgailer at gmail.com > > 3. mailto:ken at mack-z.com > > 4. mailto:TriZPUG at python.org > > 5. https://mail.python.org/mailman/listinfo/trizpug > > 6. http://tripython.org/ > > 7. mailto:ken at mack-z.com > > 8. mailto:TriZPUG at python.org > > 9. https://mail.python.org/mailman/listinfo/trizpug > > 10. http://tripython.org/ > > 11. mailto:TriZPUG at python.org > > 12. https://mail.python.org/mailman/listinfo/trizpug > > 13. http://tripython.org/ > > > > _______________________________________________ > > TriZPUG mailing list > > TriZPUG at python.org > > https://mail.python.org/mailman/listinfo/trizpug > > http://tripython.org is the Triangle Python Users Group > > > > > [1]http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html > On Fri, Sep 15, 2017 at 8:56 AM, Will Spearman > <[2]willspearman at gmail.com> > wrote: > > ** **Sharing it as a github gist is helpful. Try this: > ** > **[1][3]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 > ** **On Fri, Sep 15, 2017 at 8:48 AM Bob Gailer > <[2][4]bgailer at gmail.com> wrote: > > ** ** **** **On Sep 14, 2017 9:33 AM, "Ken MacKenzie" > <[1][3][5]ken at mack-z.com> > ** ** **wrote: > ** ** **** **> > ** ** **** **> ** **So I have a bit of code I have created that works to > solve > ** ** **the > ** ** **** **problem, > ** ** **** **> ** **however as an academic exercise, I realized I could > not > ** ** **reason of a > ** ** **** **way to > ** ** **** **> ** **solve it without recursion. > > ** ** **** **My understanding of computer science says that recursion is > never > ** ** **** **necessary. There is always a way to solve the problem > without > ** ** **recursion. > ** ** **** **> ** **The situation, I have a file with many possible > delimiters > ** ** **and > ** ** **** **those > ** ** **** **> ** **delimiters have levels so to speak so as I am kind > of > ** ** **parsing a > ** ** **** **tree, and > ** ** **** **> ** **in this case a tree that is lists of lists of lists > of x > ** ** **n... > ** ** **** **> ** **Excuse the lack of real commenting in this sample.** > But > ** ** **curious > ** ** **** **what > ** ** **** **> ** **other ways I could solve it, or if there are ways I > could > ** ** **perhaps > ** ** **** **make it > ** ** **** **> ** **perform faster.** It performs fast enough but I > realize the > ** ** **file > ** ** **** **could get > ** ** **** **> ** **quite long. > ** ** **** **It would be very helpful if you would give us a sample > input and > ** ** **the > ** ** **** **corresponding output. Your description above does not help. > ** ** **** **Also your code has lots of** in it that I presume are > either spaces > ** ** **or > ** ** **** **tabs. > ** ** **** **I would appreciate it if you would post the code that is > actually > ** ** **** **executable. > ** ** **** **My guess is that there's a much simpler way to do this. > ** ** **** **> ** **======= > ** ** **** **> ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", > "\x04", > ** ** **"\x05", > ** ** **** **"\x06", > ** ** **** **> ** **"\x07"] > ** ** **** **> ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] > ** ** **** **> ** **all_parsers = parse_1 + parse_2 > ** ** **** **> ** **def recursive_parse(in_var, parse_char): > ** ** **** **> ** **** ** if isinstance(in_var, list): > ** ** **** **> ** **** ** ** ** return [recursive_parse(x, parse_char) > for x in > ** ** **in_var] > ** ** **** **> ** **** ** elif isinstance(in_var, str): > ** ** **** **> ** **** ** ** ** return in_var.split(parse_char) > ** ** **** **> ** **def nested_parse(str_in): > ** ** **** **> ** **** ** big_list = [] > ** ** **** **> ** **** ** temp = [] > ** ** **** **> ** **** ** parse_list = all_parsers > ** ** **** **> ** **** ** max_lvl = len(parse_list) - 1 > ** ** **** **> ** **** ** for lvl, psr_c in enumerate(parse_list): > ** ** **** **> ** **** ** ** ** # print("temp:", temp[0][:20]) > ** ** **** **> ** **** ** ** ** if lvl == 0: > ** ** **** **> ** **** ** ** ** ** ** temp.append(str_in.split(psr_c)) > ** ** **** **> ** **** ** ** ** else: > ** ** **** **> ** **** ** ** ** ** ** pre_lvl = lvl - 1 > ** ** **** **> ** **** ** ** ** ** ** new_lvl = > recursive_parse(temp[pre_lvl], > ** ** **psr_c) > ** ** **** **> ** **** ** ** ** ** ** temp.append(new_lvl) > ** ** **** **> ** **** ** big_list = temp[max_lvl] > ** ** **** **> ** **** ** return big_list > ** ** **** **> > ** ** **** **> _______________________________________________ > ** ** **** **> TriZPUG mailing list > ** ** **** **> [2][4][6]TriZPUG at python.org > ** ** **** **> [3][5][7]https://mail.python.org/mailman/listinfo/trizpug > ** ** **** **> [4][6][8]http://tripython.org is the Triangle Python > Users Group > ** ** **** **> > > ** ** **References > > ** ** **** **Visible links > ** ** **** **1. mailto:[7][9]ken at mack-z.com > ** ** **** **2. mailto:[8][10]TriZPUG at python.org > ** ** **** **3. [9][11]https://mail.python.org/mailman/listinfo/trizpug > ** ** **** **4. [10][12]http://tripython.org/ > ** ** **_______________________________________________ > ** ** **TriZPUG mailing list > ** ** **[11][13]TriZPUG at python.org > ** ** **[12][14]https://mail.python.org/mailman/listinfo/trizpug > ** ** **[13][15]http://tripython.org is the Triangle Python Users Group > > References > > ** **Visible links > ** **1. > [16]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 > ** **2. mailto:[17]bgailer at gmail.com > ** **3. mailto:[18]ken at mack-z.com > ** **4. mailto:[19]TriZPUG at python.org > ** **5. [20]https://mail.python.org/mailman/listinfo/trizpug > ** **6. [21]http://tripython.org/ > ** **7. mailto:[22]ken at mack-z.com > ** **8. mailto:[23]TriZPUG at python.org > ** **9. [24]https://mail.python.org/mailman/listinfo/trizpug > ** 10. [25]http://tripython.org/ > ** 11. mailto:[26]TriZPUG at python.org > ** 12. [27]https://mail.python.org/mailman/listinfo/trizpug > ** 13. [28]http://tripython.org/ > > _______________________________________________ > TriZPUG mailing list > [29]TriZPUG at python.org > [30]https://mail.python.org/mailman/listinfo/trizpug > [31]http://tripython.org is the Triangle Python Users Group > > References > > Visible links > 1. http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html > 2. mailto:willspearman at gmail.com > 3. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 > 4. mailto:bgailer at gmail.com > 5. mailto:ken at mack-z.com > 6. mailto:TriZPUG at python.org > 7. https://mail.python.org/mailman/listinfo/trizpug > 8. http://tripython.org/ > 9. mailto:ken at mack-z.com > 10. mailto:TriZPUG at python.org > 11. https://mail.python.org/mailman/listinfo/trizpug > 12. http://tripython.org/ > 13. mailto:TriZPUG at python.org > 14. https://mail.python.org/mailman/listinfo/trizpug > 15. http://tripython.org/ > 16. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 > 17. mailto:bgailer at gmail.com > 18. mailto:ken at mack-z.com > 19. mailto:TriZPUG at python.org > 20. https://mail.python.org/mailman/listinfo/trizpug > 21. http://tripython.org/ > 22. mailto:ken at mack-z.com > 23. mailto:TriZPUG at python.org > 24. https://mail.python.org/mailman/listinfo/trizpug > 25. http://tripython.org/ > 26. mailto:TriZPUG at python.org > 27. https://mail.python.org/mailman/listinfo/trizpug > 28. http://tripython.org/ > 29. mailto:TriZPUG at python.org > 30. https://mail.python.org/mailman/listinfo/trizpug > 31. http://tripython.org/ > From chris at archimedeanco.com Fri Sep 15 09:38:20 2017 From: chris at archimedeanco.com (Chris Rossi) Date: Fri, 15 Sep 2017 09:38:20 -0400 Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: <1505481477.451223558@apps.rackspace.com> References: <1505481477.451223558@apps.rackspace.com> Message-ID: For grins I just did the first exercise on that link I sent, and it was kind of fun. Actually doing the exercise helps significantly with understanding why it works. You'll probably need to at least work up to Part 3, though, because you're going to need data structures for the parsing you're trying to do. As an aside, I tend to leave things recursive unless circumstances force my hand. Premature optimization is the root of all evil, machine time is cheaper than programmer time, and all of that jazz. But it is a good mental exercise. Chris On Fri, Sep 15, 2017 at 9:17 AM, David Handy wrote: > This is hilarious. While I was typing and editing my response beginning > with "Since no one else is answering ...", three other people sent > replies! > > > > I like the link Chris Rossi sent about how to turn a recursive algorithm > into an iterative one. My advice I gave using a Python list as a stack > is > an example of the "accumulator" that the linked article talks about, for > the case where a more simple accumulator such as an integer isn't enough > information. An example would be if you are writing code to parse an XML > document, the accumulator/stack could be the list of nested tags you > have > encountered so far during processing. > > > > David H > > > > > > On Friday, September 15, 2017 8:57am, "Chris Rossi" > said: > > > _______________________________________________ > > TriZPUG mailing list > > TriZPUG at python.org > > https://mail.python.org/mailman/listinfo/trizpug > > http://tripython.org is the Triangle Python Users Group > > http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html > > > > On Fri, Sep 15, 2017 at 8:56 AM, Will Spearman < > willspearman at gmail.com> > > wrote: > > > > > Sharing it as a github gist is helpful. Try this: > > > [1]https://gist.github.com/willspearman/ > 97d9ee58b9391b0cdcd09d601017a2 > > > f8 > > > On Fri, Sep 15, 2017 at 8:48 AM Bob Gailer <[2]bgailer at gmail.com> > > > wrote: > > > > > > ** **On Sep 14, 2017 9:33 AM, "Ken MacKenzie" > > <[1][3]ken at mack-z.com> > > > wrote: > > > ** **> > > > ** **> ** **So I have a bit of code I have created that works to > > solve > > > the > > > ** **problem, > > > ** **> ** **however as an academic exercise, I realized I could not > > > reason of a > > > ** **way to > > > ** **> ** **solve it without recursion. > > > > > > ** **My understanding of computer science says that recursion is > never > > > ** **necessary. There is always a way to solve the problem without > > > recursion. > > > ** **> ** **The situation, I have a file with many possible > > delimiters > > > and > > > ** **those > > > ** **> ** **delimiters have levels so to speak so as I am kind of > > > parsing a > > > ** **tree, and > > > ** **> ** **in this case a tree that is lists of lists of lists of x > > > n... > > > ** **> ** **Excuse the lack of real commenting in this sample.** But > > > curious > > > ** **what > > > ** **> ** **other ways I could solve it, or if there are ways I > > could > > > perhaps > > > ** **make it > > > ** **> ** **perform faster.** It performs fast enough but I realize > > > the > > > file > > > ** **could get > > > ** **> ** **quite long. > > > ** **It would be very helpful if you would give us a sample input > and > > > the > > > ** **corresponding output. Your description above does not help. > > > ** **Also your code has lots of** in it that I presume are either > > > spaces > > > or > > > ** **tabs. > > > ** **I would appreciate it if you would post the code that is > actually > > > ** **executable. > > > ** **My guess is that there's a much simpler way to do this. > > > ** **> ** **======= > > > ** **> ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", > > > "\x05", > > > ** **"\x06", > > > ** **> ** **"\x07"] > > > ** **> ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] > > > ** **> ** **all_parsers = parse_1 + parse_2 > > > ** **> ** **def recursive_parse(in_var, parse_char): > > > ** **> ** **** ** if isinstance(in_var, list): > > > ** **> ** **** ** ** ** return [recursive_parse(x, parse_char) for x > > > in > > > in_var] > > > ** **> ** **** ** elif isinstance(in_var, str): > > > ** **> ** **** ** ** ** return in_var.split(parse_char) > > > ** **> ** **def nested_parse(str_in): > > > ** **> ** **** ** big_list = [] > > > ** **> ** **** ** temp = [] > > > ** **> ** **** ** parse_list = all_parsers > > > ** **> ** **** ** max_lvl = len(parse_list) - 1 > > > ** **> ** **** ** for lvl, psr_c in enumerate(parse_list): > > > ** **> ** **** ** ** ** # print("temp:", temp[0][:20]) > > > ** **> ** **** ** ** ** if lvl == 0: > > > ** **> ** **** ** ** ** ** ** temp.append(str_in.split(psr_c)) > > > ** **> ** **** ** ** ** else: > > > ** **> ** **** ** ** ** ** ** pre_lvl = lvl - 1 > > > ** **> ** **** ** ** ** ** ** new_lvl = > > recursive_parse(temp[pre_lvl], > > > psr_c) > > > ** **> ** **** ** ** ** ** ** temp.append(new_lvl) > > > ** **> ** **** ** big_list = temp[max_lvl] > > > ** **> ** **** ** return big_list > > > ** **> > > > ** **> _______________________________________________ > > > ** **> TriZPUG mailing list > > > ** **> [2][4]TriZPUG at python.org > > > ** **> [3][5]https://mail.python.org/mailman/listinfo/trizpug > > > ** **> [4][6]http://tripython.org is the Triangle Python Users > Group > > > ** **> > > > > > > References > > > > > > ** **Visible links > > > ** **1. mailto:[7]ken at mack-z.com > > > ** **2. mailto:[8]TriZPUG at python.org > > > ** **3. [9]https://mail.python.org/mailman/listinfo/trizpug > > > ** **4. [10]http://tripython.org/ > > > _______________________________________________ > > > TriZPUG mailing list > > > [11]TriZPUG at python.org > > > [12]https://mail.python.org/mailman/listinfo/trizpug > > > [13]http://tripython.org is the Triangle Python Users Group > > > > > > References > > > > > > Visible links > > > 1. https://gist.github.com/willspearman/ > 97d9ee58b9391b0cdcd09d601017a2 > > > f8 > > > 2. mailto:bgailer at gmail.com > > > 3. mailto:ken at mack-z.com > > > 4. mailto:TriZPUG at python.org > > > 5. https://mail.python.org/mailman/listinfo/trizpug > > > 6. http://tripython.org/ > > > 7. mailto:ken at mack-z.com > > > 8. mailto:TriZPUG at python.org > > > 9. https://mail.python.org/mailman/listinfo/trizpug > > > 10. http://tripython.org/ > > > 11. mailto:TriZPUG at python.org > > > 12. https://mail.python.org/mailman/listinfo/trizpug > > > 13. http://tripython.org/ > > > > > > _______________________________________________ > > > TriZPUG mailing list > > > TriZPUG at python.org > > > https://mail.python.org/mailman/listinfo/trizpug > > > http://tripython.org is the Triangle Python Users Group > > > > > > > > [1]http://blog.moertel.com/posts/2013-05-11-recursive-to- > iterative.html > > On Fri, Sep 15, 2017 at 8:56 AM, Will Spearman > > <[2]willspearman at gmail.com> > > wrote: > > > > ** **Sharing it as a github gist is helpful. Try this: > > ** > > > **[1][3]https://gist.github.com/willspearman/ > 97d9ee58b9391b0cdcd09d601017a2f8 > > ** **On Fri, Sep 15, 2017 at 8:48 AM Bob Gailer > > <[2][4]bgailer at gmail.com> wrote: > > > > ** ** **** **On Sep 14, 2017 9:33 AM, "Ken MacKenzie" > > <[1][3][5]ken at mack-z.com> > > ** ** **wrote: > > ** ** **** **> > > ** ** **** **> ** **So I have a bit of code I have created that works > to > > solve > > ** ** **the > > ** ** **** **problem, > > ** ** **** **> ** **however as an academic exercise, I realized I > could > > not > > ** ** **reason of a > > ** ** **** **way to > > ** ** **** **> ** **solve it without recursion. > > > > ** ** **** **My understanding of computer science says that recursion > is > > never > > ** ** **** **necessary. There is always a way to solve the problem > > without > > ** ** **recursion. > > ** ** **** **> ** **The situation, I have a file with many possible > > delimiters > > ** ** **and > > ** ** **** **those > > ** ** **** **> ** **delimiters have levels so to speak so as I am kind > > of > > ** ** **parsing a > > ** ** **** **tree, and > > ** ** **** **> ** **in this case a tree that is lists of lists of > lists > > of x > > ** ** **n... > > ** ** **** **> ** **Excuse the lack of real commenting in this > sample.** > > But > > ** ** **curious > > ** ** **** **what > > ** ** **** **> ** **other ways I could solve it, or if there are ways > I > > could > > ** ** **perhaps > > ** ** **** **make it > > ** ** **** **> ** **perform faster.** It performs fast enough but I > > realize the > > ** ** **file > > ** ** **** **could get > > ** ** **** **> ** **quite long. > > ** ** **** **It would be very helpful if you would give us a sample > > input and > > ** ** **the > > ** ** **** **corresponding output. Your description above does not > help. > > ** ** **** **Also your code has lots of** in it that I presume are > > either spaces > > ** ** **or > > ** ** **** **tabs. > > ** ** **** **I would appreciate it if you would post the code that is > > actually > > ** ** **** **executable. > > ** ** **** **My guess is that there's a much simpler way to do this. > > ** ** **** **> ** **======= > > ** ** **** **> ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", > > "\x04", > > ** ** **"\x05", > > ** ** **** **"\x06", > > ** ** **** **> ** **"\x07"] > > ** ** **** **> ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] > > ** ** **** **> ** **all_parsers = parse_1 + parse_2 > > ** ** **** **> ** **def recursive_parse(in_var, parse_char): > > ** ** **** **> ** **** ** if isinstance(in_var, list): > > ** ** **** **> ** **** ** ** ** return [recursive_parse(x, parse_char) > > for x in > > ** ** **in_var] > > ** ** **** **> ** **** ** elif isinstance(in_var, str): > > ** ** **** **> ** **** ** ** ** return in_var.split(parse_char) > > ** ** **** **> ** **def nested_parse(str_in): > > ** ** **** **> ** **** ** big_list = [] > > ** ** **** **> ** **** ** temp = [] > > ** ** **** **> ** **** ** parse_list = all_parsers > > ** ** **** **> ** **** ** max_lvl = len(parse_list) - 1 > > ** ** **** **> ** **** ** for lvl, psr_c in enumerate(parse_list): > > ** ** **** **> ** **** ** ** ** # print("temp:", temp[0][:20]) > > ** ** **** **> ** **** ** ** ** if lvl == 0: > > ** ** **** **> ** **** ** ** ** ** ** temp.append(str_in.split(psr_ > c)) > > ** ** **** **> ** **** ** ** ** else: > > ** ** **** **> ** **** ** ** ** ** ** pre_lvl = lvl - 1 > > ** ** **** **> ** **** ** ** ** ** ** new_lvl = > > recursive_parse(temp[pre_lvl], > > ** ** **psr_c) > > ** ** **** **> ** **** ** ** ** ** ** temp.append(new_lvl) > > ** ** **** **> ** **** ** big_list = temp[max_lvl] > > ** ** **** **> ** **** ** return big_list > > ** ** **** **> > > ** ** **** **> _______________________________________________ > > ** ** **** **> TriZPUG mailing list > > ** ** **** **> [2][4][6]TriZPUG at python.org > > ** ** **** **> [3][5][7]https://mail.python. > org/mailman/listinfo/trizpug > > ** ** **** **> [4][6][8]http://tripython.org is the Triangle Python > > Users Group > > ** ** **** **> > > > > ** ** **References > > > > ** ** **** **Visible links > > ** ** **** **1. mailto:[7][9]ken at mack-z.com > > ** ** **** **2. mailto:[8][10]TriZPUG at python.org > > ** ** **** **3. [9][11]https://mail.python. > org/mailman/listinfo/trizpug > > ** ** **** **4. [10][12]http://tripython.org/ > > ** ** **_______________________________________________ > > ** ** **TriZPUG mailing list > > ** ** **[11][13]TriZPUG at python.org > > ** ** **[12][14]https://mail.python.org/mailman/listinfo/trizpug > > ** ** **[13][15]http://tripython.org is the Triangle Python Users > Group > > > > References > > > > ** **Visible links > > ** **1. > > > [16]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2 > f8 > > ** **2. mailto:[17]bgailer at gmail.com > > ** **3. mailto:[18]ken at mack-z.com > > ** **4. mailto:[19]TriZPUG at python.org > > ** **5. [20]https://mail.python.org/mailman/listinfo/trizpug > > ** **6. [21]http://tripython.org/ > > ** **7. mailto:[22]ken at mack-z.com > > ** **8. mailto:[23]TriZPUG at python.org > > ** **9. [24]https://mail.python.org/mailman/listinfo/trizpug > > ** 10. [25]http://tripython.org/ > > ** 11. mailto:[26]TriZPUG at python.org > > ** 12. [27]https://mail.python.org/mailman/listinfo/trizpug > > ** 13. [28]http://tripython.org/ > > > > _______________________________________________ > > TriZPUG mailing list > > [29]TriZPUG at python.org > > [30]https://mail.python.org/mailman/listinfo/trizpug > > [31]http://tripython.org is the Triangle Python Users Group > > > > References > > > > Visible links > > 1. http://blog.moertel.com/posts/2013-05-11-recursive-to- > iterative.html > > 2. mailto:willspearman at gmail.com > > 3. https://gist.github.com/willspearman/ > 97d9ee58b9391b0cdcd09d601017a2f8 > > 4. mailto:bgailer at gmail.com > > 5. mailto:ken at mack-z.com > > 6. mailto:TriZPUG at python.org > > 7. https://mail.python.org/mailman/listinfo/trizpug > > 8. http://tripython.org/ > > 9. mailto:ken at mack-z.com > > 10. mailto:TriZPUG at python.org > > 11. https://mail.python.org/mailman/listinfo/trizpug > > 12. http://tripython.org/ > > 13. mailto:TriZPUG at python.org > > 14. https://mail.python.org/mailman/listinfo/trizpug > > 15. http://tripython.org/ > > 16. > https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 > > 17. mailto:bgailer at gmail.com > > 18. mailto:ken at mack-z.com > > 19. mailto:TriZPUG at python.org > > 20. https://mail.python.org/mailman/listinfo/trizpug > > 21. http://tripython.org/ > > 22. mailto:ken at mack-z.com > > 23. mailto:TriZPUG at python.org > > 24. https://mail.python.org/mailman/listinfo/trizpug > > 25. http://tripython.org/ > > 26. mailto:TriZPUG at python.org > > 27. https://mail.python.org/mailman/listinfo/trizpug > > 28. http://tripython.org/ > > 29. mailto:TriZPUG at python.org > > 30. https://mail.python.org/mailman/listinfo/trizpug > > 31. http://tripython.org/ > > > > _______________________________________________ > TriZPUG mailing list > TriZPUG at python.org > https://mail.python.org/mailman/listinfo/trizpug > http://tripython.org is the Triangle Python Users Group > > -------------- next part -------------- For grins I just did the first exercise on that link I sent, and it was kind of fun.** Actually doing the exercise helps significantly with understanding why it works.** You'll probably need to at least work up to Part 3, though, because you're going to need data structures for the parsing you're trying to do. As an aside, I tend to leave things recursive unless circumstances force my hand.** Premature optimization is the root of all evil, machine time is cheaper than programmer time, and all of that jazz.** But it is a good mental exercise. ** Chris On Fri, Sep 15, 2017 at 9:17 AM, David Handy <[1]david at handysoftware.com> wrote: ** **This is hilarious. While I was typing and editing my response beginning ** **with "Since no one else is answering ...", three other people sent ** **replies! ** **I like the link Chris Rossi sent about how to turn a recursive algorithm ** **into an iterative one. My advice I gave using a Python list as a stack is ** **an example of the "accumulator" that the linked article talks about, for ** **the case where a more simple accumulator such as an integer isn't enough ** **information. An example would be if you are writing code to parse an XML ** **document, the accumulator/stack could be the list of nested tags you have ** **encountered so far during processing. ** **David H ** **On Friday, September 15, 2017 8:57am, "Chris Rossi" ** **<[2]chris at archimedeanco.com> said: ** **> _______________________________________________ ** **> TriZPUG mailing list ** **> [3]TriZPUG at python.org ** **> [4]https://mail.python.org/mailman/listinfo/trizpug ** **> [5]http://tripython.org is the Triangle Python Users Group ** **> [6]http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html ** **> ** **> On Fri, Sep 15, 2017 at 8:56 AM, Will Spearman <[7]willspearman at gmail.com> ** **> wrote: ** **> ** **> > Sharing it as a github gist is helpful. Try this: ** **> > [1][8]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2 ** **> > f8 ** **> > On Fri, Sep 15, 2017 at 8:48 AM Bob Gailer <[2][9]bgailer at gmail.com> ** **> > wrote: ** **> > ** **> > ** **On Sep 14, 2017 9:33 AM, "Ken MacKenzie" ** **> <[1][3][10]ken at mack-z.com> ** **> > wrote: ** **> > ** **> ** **> > ** **> ** **So I have a bit of code I have created that works to ** **> solve ** **> > the ** **> > ** **problem, ** **> > ** **> ** **however as an academic exercise, I realized I could not ** **> > reason of a ** **> > ** **way to ** **> > ** **> ** **solve it without recursion. ** **> > ** **> > ** **My understanding of computer science says that recursion is never ** **> > ** **necessary. There is always a way to solve the problem without ** **> > recursion. ** **> > ** **> ** **The situation, I have a file with many possible ** **> delimiters ** **> > and ** **> > ** **those ** **> > ** **> ** **delimiters have levels so to speak so as I am kind of ** **> > parsing a ** **> > ** **tree, and ** **> > ** **> ** **in this case a tree that is lists of lists of lists of x ** **> > n... ** **> > ** **> ** **Excuse the lack of real commenting in this sample.** But ** **> > curious ** **> > ** **what ** **> > ** **> ** **other ways I could solve it, or if there are ways I ** **> could ** **> > perhaps ** **> > ** **make it ** **> > ** **> ** **perform faster.** It performs fast enough but I realize ** **> > the ** **> > file ** **> > ** **could get ** **> > ** **> ** **quite long. ** **> > ** **It would be very helpful if you would give us a sample input and ** **> > the ** **> > ** **corresponding output. Your description above does not help. ** **> > ** **Also your code has lots of** in it that I presume are either ** **> > spaces ** **> > or ** **> > ** **tabs. ** **> > ** **I would appreciate it if you would post the code that is actually ** **> > ** **executable. ** **> > ** **My guess is that there's a much simpler way to do this. ** **> > ** **> ** **======= ** **> > ** **> ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", ** **> > "\x05", ** **> > ** **"\x06", ** **> > ** **> ** **"\x07"] ** **> > ** **> ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] ** **> > ** **> ** **all_parsers = parse_1 + parse_2 ** **> > ** **> ** **def recursive_parse(in_var, parse_char): ** **> > ** **> ** **** ** if isinstance(in_var, list): ** **> > ** **> ** **** ** ** ** return [recursive_parse(x, parse_char) for x ** **> > in ** **> > in_var] ** **> > ** **> ** **** ** elif isinstance(in_var, str): ** **> > ** **> ** **** ** ** ** return in_var.split(parse_char) ** **> > ** **> ** **def nested_parse(str_in): ** **> > ** **> ** **** ** big_list = [] ** **> > ** **> ** **** ** temp = [] ** **> > ** **> ** **** ** parse_list = all_parsers ** **> > ** **> ** **** ** max_lvl = len(parse_list) - 1 ** **> > ** **> ** **** ** for lvl, psr_c in enumerate(parse_list): ** **> > ** **> ** **** ** ** ** # print("temp:", temp[0][:20]) ** **> > ** **> ** **** ** ** ** if lvl == 0: ** **> > ** **> ** **** ** ** ** ** ** temp.append(str_in.split(psr_c)) ** **> > ** **> ** **** ** ** ** else: ** **> > ** **> ** **** ** ** ** ** ** pre_lvl = lvl - 1 ** **> > ** **> ** **** ** ** ** ** ** new_lvl = ** **> recursive_parse(temp[pre_lvl], ** **> > psr_c) ** **> > ** **> ** **** ** ** ** ** ** temp.append(new_lvl) ** **> > ** **> ** **** ** big_list = temp[max_lvl] ** **> > ** **> ** **** ** return big_list ** **> > ** **> ** **> > ** **> _______________________________________________ ** **> > ** **> TriZPUG mailing list ** **> > ** **> [2][4][11]TriZPUG at python.org ** **> > ** **> [3][5][12]https://mail.python.org/mailman/listinfo/trizpug ** **> > ** **> [4][6][13]http://tripython.org is the Triangle Python Users Group ** **> > ** **> ** **> > ** **> > References ** **> > ** **> > ** **Visible links ** **> > ** **1. mailto:[7][14]ken at mack-z.com ** **> > ** **2. mailto:[8][15]TriZPUG at python.org ** **> > ** **3. [9][16]https://mail.python.org/mailman/listinfo/trizpug ** **> > ** **4. [10][17]http://tripython.org/ ** **> > _______________________________________________ ** **> > TriZPUG mailing list ** **> > [11][18]TriZPUG at python.org ** **> > [12][19]https://mail.python.org/mailman/listinfo/trizpug ** **> > [13][20]http://tripython.org is the Triangle Python Users Group ** **> > ** **> > References ** **> > ** **> > Visible links ** **> > 1. [21]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2 ** **> > f8 ** **> > 2. mailto:[22]bgailer at gmail.com ** **> > 3. mailto:[23]ken at mack-z.com ** **> > 4. mailto:[24]TriZPUG at python.org ** **> > 5. [25]https://mail.python.org/mailman/listinfo/trizpug ** **> > 6. [26]http://tripython.org/ ** **> > 7. mailto:[27]ken at mack-z.com ** **> > 8. mailto:[28]TriZPUG at python.org ** **> > 9. [29]https://mail.python.org/mailman/listinfo/trizpug ** **> > 10. [30]http://tripython.org/ ** **> > 11. mailto:[31]TriZPUG at python.org ** **> > 12. [32]https://mail.python.org/mailman/listinfo/trizpug ** **> > 13. [33]http://tripython.org/ ** **> > ** **> > _______________________________________________ ** **> > TriZPUG mailing list ** **> > [34]TriZPUG at python.org ** **> > [35]https://mail.python.org/mailman/listinfo/trizpug ** **> > [36]http://tripython.org is the Triangle Python Users Group ** **> > ** **> > ** **> [1][37]http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html ** **> On Fri, Sep 15, 2017 at 8:56 AM, Will Spearman ** **> <[2][38]willspearman at gmail.com> ** **> wrote: ** **> ** **> ** **Sharing it as a github gist is helpful. Try this: ** **> ** ** **> ** ****[1][3][39]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 ** **> ** **On Fri, Sep 15, 2017 at 8:48 AM Bob Gailer ** **> <[2][4][40]bgailer at gmail.com> wrote: ** **> ** **> ** ** **** **On Sep 14, 2017 9:33 AM, "Ken MacKenzie" ** **> <[1][3][5][41]ken at mack-z.com> ** **> ** ** **wrote: ** **> ** ** **** **> ** **> ** ** **** **> ** **So I have a bit of code I have created that works to ** **> solve ** **> ** ** **the ** **> ** ** **** **problem, ** **> ** ** **** **> ** **however as an academic exercise, I realized I could ** **> not ** **> ** ** **reason of a ** **> ** ** **** **way to ** **> ** ** **** **> ** **solve it without recursion. ** **> ** **> ** ** **** **My understanding of computer science says that recursion is ** **> never ** **> ** ** **** **necessary. There is always a way to solve the problem ** **> without ** **> ** ** **recursion. ** **> ** ** **** **> ** **The situation, I have a file with many possible ** **> delimiters ** **> ** ** **and ** **> ** ** **** **those ** **> ** ** **** **> ** **delimiters have levels so to speak so as I am kind ** **> of ** **> ** ** **parsing a ** **> ** ** **** **tree, and ** **> ** ** **** **> ** **in this case a tree that is lists of lists of lists ** **> of x ** **> ** ** **n... ** **> ** ** **** **> ** **Excuse the lack of real commenting in this sample.** ** **> But ** **> ** ** **curious ** **> ** ** **** **what ** **> ** ** **** **> ** **other ways I could solve it, or if there are ways I ** **> could ** **> ** ** **perhaps ** **> ** ** **** **make it ** **> ** ** **** **> ** **perform faster.** It performs fast enough but I ** **> realize the ** **> ** ** **file ** **> ** ** **** **could get ** **> ** ** **** **> ** **quite long. ** **> ** ** **** **It would be very helpful if you would give us a sample ** **> input and ** **> ** ** **the ** **> ** ** **** **corresponding output. Your description above does not help. ** **> ** ** **** **Also your code has lots of** in it that I presume are ** **> either spaces ** **> ** ** **or ** **> ** ** **** **tabs. ** **> ** ** **** **I would appreciate it if you would post the code that is ** **> actually ** **> ** ** **** **executable. ** **> ** ** **** **My guess is that there's a much simpler way to do this. ** **> ** ** **** **> ** **======= ** **> ** ** **** **> ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", ** **> "\x04", ** **> ** ** **"\x05", ** **> ** ** **** **"\x06", ** **> ** ** **** **> ** **"\x07"] ** **> ** ** **** **> ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] ** **> ** ** **** **> ** **all_parsers = parse_1 + parse_2 ** **> ** ** **** **> ** **def recursive_parse(in_var, parse_char): ** **> ** ** **** **> ** **** ** if isinstance(in_var, list): ** **> ** ** **** **> ** **** ** ** ** return [recursive_parse(x, parse_char) ** **> for x in ** **> ** ** **in_var] ** **> ** ** **** **> ** **** ** elif isinstance(in_var, str): ** **> ** ** **** **> ** **** ** ** ** return in_var.split(parse_char) ** **> ** ** **** **> ** **def nested_parse(str_in): ** **> ** ** **** **> ** **** ** big_list = [] ** **> ** ** **** **> ** **** ** temp = [] ** **> ** ** **** **> ** **** ** parse_list = all_parsers ** **> ** ** **** **> ** **** ** max_lvl = len(parse_list) - 1 ** **> ** ** **** **> ** **** ** for lvl, psr_c in enumerate(parse_list): ** **> ** ** **** **> ** **** ** ** ** # print("temp:", temp[0][:20]) ** **> ** ** **** **> ** **** ** ** ** if lvl == 0: ** **> ** ** **** **> ** **** ** ** ** ** ** temp.append(str_in.split(psr_c)) ** **> ** ** **** **> ** **** ** ** ** else: ** **> ** ** **** **> ** **** ** ** ** ** ** pre_lvl = lvl - 1 ** **> ** ** **** **> ** **** ** ** ** ** ** new_lvl = ** **> recursive_parse(temp[pre_lvl], ** **> ** ** **psr_c) ** **> ** ** **** **> ** **** ** ** ** ** ** temp.append(new_lvl) ** **> ** ** **** **> ** **** ** big_list = temp[max_lvl] ** **> ** ** **** **> ** **** ** return big_list ** **> ** ** **** **> ** **> ** ** **** **> _______________________________________________ ** **> ** ** **** **> TriZPUG mailing list ** **> ** ** **** **> [2][4][6][42]TriZPUG at python.org ** **> ** ** **** **> [3][5][7][43]https://mail.python.org/mailman/listinfo/trizpug ** **> ** ** **** **> [4][6][8][44]http://tripython.org is the Triangle Python ** **> Users Group ** **> ** ** **** **> ** **> ** **> ** ** **References ** **> ** **> ** ** **** **Visible links ** **> ** ** **** **1. mailto:[7][9][45]ken at mack-z.com ** **> ** ** **** **2. mailto:[8][10][46]TriZPUG at python.org ** **> ** ** **** **3. [9][11][47]https://mail.python.org/mailman/listinfo/trizpug ** **> ** ** **** **4. [10][12][48]http://tripython.org/ ** **> ** ** **_______________________________________________ ** **> ** ** **TriZPUG mailing list ** **> ** ** **[11][13][49]TriZPUG at python.org ** **> ** ** **[12][14][50]https://mail.python.org/mailman/listinfo/trizpug ** **> ** ** **[13][15][51]http://tripython.org is the Triangle Python Users Group ** **> ** **> References ** **> ** **> ** **Visible links ** **> ** **1. ** **> ** **[16][52]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 ** **> ** **2. mailto:[17][53]bgailer at gmail.com ** **> ** **3. mailto:[18][54]ken at mack-z.com ** **> ** **4. mailto:[19][55]TriZPUG at python.org ** **> ** **5. [20][56]https://mail.python.org/mailman/listinfo/trizpug ** **> ** **6. [21][57]http://tripython.org/ ** **> ** **7. mailto:[22][58]ken at mack-z.com ** **> ** **8. mailto:[23][59]TriZPUG at python.org ** **> ** **9. [24][60]https://mail.python.org/mailman/listinfo/trizpug ** **> ** 10. [25][61]http://tripython.org/ ** **> ** 11. mailto:[26][62]TriZPUG at python.org ** **> ** 12. [27][63]https://mail.python.org/mailman/listinfo/trizpug ** **> ** 13. [28][64]http://tripython.org/ ** **> ** **> _______________________________________________ ** **> TriZPUG mailing list ** **> [29][65]TriZPUG at python.org ** **> [30][66]https://mail.python.org/mailman/listinfo/trizpug ** **> [31][67]http://tripython.org is the Triangle Python Users Group ** **> ** **> References ** **> ** **> Visible links ** **> 1. [68]http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html ** **> 2. mailto:[69]willspearman at gmail.com ** **> 3. [70]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 ** **> 4. mailto:[71]bgailer at gmail.com ** **> 5. mailto:[72]ken at mack-z.com ** **> 6. mailto:[73]TriZPUG at python.org ** **> 7. [74]https://mail.python.org/mailman/listinfo/trizpug ** **> 8. [75]http://tripython.org/ ** **> 9. mailto:[76]ken at mack-z.com ** **> 10. mailto:[77]TriZPUG at python.org ** **> 11. [78]https://mail.python.org/mailman/listinfo/trizpug ** **> 12. [79]http://tripython.org/ ** **> 13. mailto:[80]TriZPUG at python.org ** **> 14. [81]https://mail.python.org/mailman/listinfo/trizpug ** **> 15. [82]http://tripython.org/ ** **> 16. ** **[83]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 ** **> 17. mailto:[84]bgailer at gmail.com ** **> 18. mailto:[85]ken at mack-z.com ** **> 19. mailto:[86]TriZPUG at python.org ** **> 20. [87]https://mail.python.org/mailman/listinfo/trizpug ** **> 21. [88]http://tripython.org/ ** **> 22. mailto:[89]ken at mack-z.com ** **> 23. mailto:[90]TriZPUG at python.org ** **> 24. [91]https://mail.python.org/mailman/listinfo/trizpug ** **> 25. [92]http://tripython.org/ ** **> 26. mailto:[93]TriZPUG at python.org ** **> 27. [94]https://mail.python.org/mailman/listinfo/trizpug ** **> 28. [95]http://tripython.org/ ** **> 29. mailto:[96]TriZPUG at python.org ** **> 30. [97]https://mail.python.org/mailman/listinfo/trizpug ** **> 31. [98]http://tripython.org/ ** **> _______________________________________________ TriZPUG mailing list [99]TriZPUG at python.org [100]https://mail.python.org/mailman/listinfo/trizpug [101]http://tripython.org is the Triangle Python Users Group References Visible links 1. mailto:david at handysoftware.com 2. mailto:chris at archimedeanco.com 3. mailto:TriZPUG at python.org 4. https://mail.python.org/mailman/listinfo/trizpug 5. http://tripython.org/ 6. http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html 7. mailto:willspearman at gmail.com 8. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2 9. mailto:bgailer at gmail.com 10. mailto:ken at mack-z.com 11. mailto:TriZPUG at python.org 12. https://mail.python.org/mailman/listinfo/trizpug 13. http://tripython.org/ 14. mailto:ken at mack-z.com 15. mailto:TriZPUG at python.org 16. https://mail.python.org/mailman/listinfo/trizpug 17. http://tripython.org/ 18. mailto:TriZPUG at python.org 19. https://mail.python.org/mailman/listinfo/trizpug 20. http://tripython.org/ 21. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2 22. mailto:bgailer at gmail.com 23. mailto:ken at mack-z.com 24. mailto:TriZPUG at python.org 25. https://mail.python.org/mailman/listinfo/trizpug 26. http://tripython.org/ 27. mailto:ken at mack-z.com 28. mailto:TriZPUG at python.org 29. https://mail.python.org/mailman/listinfo/trizpug 30. http://tripython.org/ 31. mailto:TriZPUG at python.org 32. https://mail.python.org/mailman/listinfo/trizpug 33. http://tripython.org/ 34. mailto:TriZPUG at python.org 35. https://mail.python.org/mailman/listinfo/trizpug 36. http://tripython.org/ 37. http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html 38. mailto:willspearman at gmail.com 39. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 40. mailto:bgailer at gmail.com 41. mailto:ken at mack-z.com 42. mailto:TriZPUG at python.org 43. https://mail.python.org/mailman/listinfo/trizpug 44. http://tripython.org/ 45. mailto:ken at mack-z.com 46. mailto:TriZPUG at python.org 47. https://mail.python.org/mailman/listinfo/trizpug 48. http://tripython.org/ 49. mailto:TriZPUG at python.org 50. https://mail.python.org/mailman/listinfo/trizpug 51. http://tripython.org/ 52. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 53. mailto:bgailer at gmail.com 54. mailto:ken at mack-z.com 55. mailto:TriZPUG at python.org 56. https://mail.python.org/mailman/listinfo/trizpug 57. http://tripython.org/ 58. mailto:ken at mack-z.com 59. mailto:TriZPUG at python.org 60. https://mail.python.org/mailman/listinfo/trizpug 61. http://tripython.org/ 62. mailto:TriZPUG at python.org 63. https://mail.python.org/mailman/listinfo/trizpug 64. http://tripython.org/ 65. mailto:TriZPUG at python.org 66. https://mail.python.org/mailman/listinfo/trizpug 67. http://tripython.org/ 68. http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html 69. mailto:willspearman at gmail.com 70. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 71. mailto:bgailer at gmail.com 72. mailto:ken at mack-z.com 73. mailto:TriZPUG at python.org 74. https://mail.python.org/mailman/listinfo/trizpug 75. http://tripython.org/ 76. mailto:ken at mack-z.com 77. mailto:TriZPUG at python.org 78. https://mail.python.org/mailman/listinfo/trizpug 79. http://tripython.org/ 80. mailto:TriZPUG at python.org 81. https://mail.python.org/mailman/listinfo/trizpug 82. http://tripython.org/ 83. https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 84. mailto:bgailer at gmail.com 85. mailto:ken at mack-z.com 86. mailto:TriZPUG at python.org 87. https://mail.python.org/mailman/listinfo/trizpug 88. http://tripython.org/ 89. mailto:ken at mack-z.com 90. mailto:TriZPUG at python.org 91. https://mail.python.org/mailman/listinfo/trizpug 92. http://tripython.org/ 93. mailto:TriZPUG at python.org 94. https://mail.python.org/mailman/listinfo/trizpug 95. http://tripython.org/ 96. mailto:TriZPUG at python.org 97. https://mail.python.org/mailman/listinfo/trizpug 98. http://tripython.org/ 99. mailto:TriZPUG at python.org 100. https://mail.python.org/mailman/listinfo/trizpug 101. http://tripython.org/ From cbc at unc.edu Fri Sep 15 10:07:44 2017 From: cbc at unc.edu (Calloway, Chris) Date: Fri, 15 Sep 2017 14:07:44 +0000 Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: References: <1505481477.451223558@apps.rackspace.com> Message-ID: <8DC86A17-B576-43D4-872A-867D01DCD446@unc.edu> In this case, machine memory might be the problem, in which case David?s suggestion is more optimal than recursion, as it allows for data streaming. Think SAX parser vs DOM parser. They both have their use cases. Very much appreciating seeing an actual Python discussion on this list. ( -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 On 9/15/17, 9:38 AM, "TriZPUG on behalf of Chris Rossi" wrote: For grins I just did the first exercise on that link I sent, and it was kind of fun. Actually doing the exercise helps significantly with understanding why it works. You'll probably need to at least work up to Part 3, though, because you're going to need data structures for the parsing you're trying to do. As an aside, I tend to leave things recursive unless circumstances force my hand. Premature optimization is the root of all evil, machine time is cheaper than programmer time, and all of that jazz. But it is a good mental exercise. Chris On Fri, Sep 15, 2017 at 9:17 AM, David Handy wrote: > This is hilarious. While I was typing and editing my response beginning > with "Since no one else is answering ...", three other people sent > replies! > > > > I like the link Chris Rossi sent about how to turn a recursive algorithm > into an iterative one. My advice I gave using a Python list as a stack > is > an example of the "accumulator" that the linked article talks about, for > the case where a more simple accumulator such as an integer isn't enough > information. An example would be if you are writing code to parse an XML > document, the accumulator/stack could be the list of nested tags you > have > encountered so far during processing. > > > > David H > > > > > > On Friday, September 15, 2017 8:57am, "Chris Rossi" > said: > > > _______________________________________________ > > TriZPUG mailing list > > TriZPUG at python.org > > https://mail.python.org/mailman/listinfo/trizpug > > http://tripython.org is the Triangle Python Users Group > > http://blog.moertel.com/posts/2013-05-11-recursive-to-iterative.html > > > > On Fri, Sep 15, 2017 at 8:56 AM, Will Spearman < > willspearman at gmail.com> > > wrote: > > > > > Sharing it as a github gist is helpful. Try this: > > > [1]https://gist.github.com/willspearman/ > 97d9ee58b9391b0cdcd09d601017a2 > > > f8 > > > On Fri, Sep 15, 2017 at 8:48 AM Bob Gailer <[2]bgailer at gmail.com> > > > wrote: > > > > > > ** **On Sep 14, 2017 9:33 AM, "Ken MacKenzie" > > <[1][3]ken at mack-z.com> > > > wrote: > > > ** **> > > > ** **> ** **So I have a bit of code I have created that works to > > solve > > > the > > > ** **problem, > > > ** **> ** **however as an academic exercise, I realized I could not > > > reason of a > > > ** **way to > > > ** **> ** **solve it without recursion. > > > > > > ** **My understanding of computer science says that recursion is > never > > > ** **necessary. There is always a way to solve the problem without > > > recursion. > > > ** **> ** **The situation, I have a file with many possible > > delimiters > > > and > > > ** **those > > > ** **> ** **delimiters have levels so to speak so as I am kind of > > > parsing a > > > ** **tree, and > > > ** **> ** **in this case a tree that is lists of lists of lists of x > > > n... > > > ** **> ** **Excuse the lack of real commenting in this sample.** But > > > curious > > > ** **what > > > ** **> ** **other ways I could solve it, or if there are ways I > > could > > > perhaps > > > ** **make it > > > ** **> ** **perform faster.** It performs fast enough but I realize > > > the > > > file > > > ** **could get > > > ** **> ** **quite long. > > > ** **It would be very helpful if you would give us a sample input > and > > > the > > > ** **corresponding output. Your description above does not help. > > > ** **Also your code has lots of** in it that I presume are either > > > spaces > > > or > > > ** **tabs. > > > ** **I would appreciate it if you would post the code that is > actually > > > ** **executable. > > > ** **My guess is that there's a much simpler way to do this. > > > ** **> ** **======= > > > ** **> ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", "\x04", > > > "\x05", > > > ** **"\x06", > > > ** **> ** **"\x07"] > > > ** **> ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] > > > ** **> ** **all_parsers = parse_1 + parse_2 > > > ** **> ** **def recursive_parse(in_var, parse_char): > > > ** **> ** **** ** if isinstance(in_var, list): > > > ** **> ** **** ** ** ** return [recursive_parse(x, parse_char) for x > > > in > > > in_var] > > > ** **> ** **** ** elif isinstance(in_var, str): > > > ** **> ** **** ** ** ** return in_var.split(parse_char) > > > ** **> ** **def nested_parse(str_in): > > > ** **> ** **** ** big_list = [] > > > ** **> ** **** ** temp = [] > > > ** **> ** **** ** parse_list = all_parsers > > > ** **> ** **** ** max_lvl = len(parse_list) - 1 > > > ** **> ** **** ** for lvl, psr_c in enumerate(parse_list): > > > ** **> ** **** ** ** ** # print("temp:", temp[0][:20]) > > > ** **> ** **** ** ** ** if lvl == 0: > > > ** **> ** **** ** ** ** ** ** temp.append(str_in.split(psr_c)) > > > ** **> ** **** ** ** ** else: > > > ** **> ** **** ** ** ** ** ** pre_lvl = lvl - 1 > > > ** **> ** **** ** ** ** ** ** new_lvl = > > recursive_parse(temp[pre_lvl], > > > psr_c) > > > ** **> ** **** ** ** ** ** ** temp.append(new_lvl) > > > ** **> ** **** ** big_list = temp[max_lvl] > > > ** **> ** **** ** return big_list > > > ** **> > > > ** **> _______________________________________________ > > > ** **> TriZPUG mailing list > > > ** **> [2][4]TriZPUG at python.org > > > ** **> [3][5]https://mail.python.org/mailman/listinfo/trizpug > > > ** **> [4][6]http://tripython.org is the Triangle Python Users > Group > > > ** **> > > > > > > References > > > > > > ** **Visible links > > > ** **1. mailto:[7]ken at mack-z.com > > > ** **2. mailto:[8]TriZPUG at python.org > > > ** **3. [9]https://mail.python.org/mailman/listinfo/trizpug > > > ** **4. [10]http://tripython.org/ > > > _______________________________________________ > > > TriZPUG mailing list > > > [11]TriZPUG at python.org > > > [12]https://mail.python.org/mailman/listinfo/trizpug > > > [13]http://tripython.org is the Triangle Python Users Group > > > > > > References > > > > > > Visible links > > > 1. https://gist.github.com/willspearman/ > 97d9ee58b9391b0cdcd09d601017a2 > > > f8 > > > 2. mailto:bgailer at gmail.com > > > 3. mailto:ken at mack-z.com > > > 4. mailto:TriZPUG at python.org > > > 5. https://mail.python.org/mailman/listinfo/trizpug > > > 6. http://tripython.org/ > > > 7. mailto:ken at mack-z.com > > > 8. mailto:TriZPUG at python.org > > > 9. https://mail.python.org/mailman/listinfo/trizpug > > > 10. http://tripython.org/ > > > 11. mailto:TriZPUG at python.org > > > 12. https://mail.python.org/mailman/listinfo/trizpug > > > 13. http://tripython.org/ > > > > > > _______________________________________________ > > > TriZPUG mailing list > > > TriZPUG at python.org > > > https://mail.python.org/mailman/listinfo/trizpug > > > http://tripython.org is the Triangle Python Users Group > > > > > > > > [1]http://blog.moertel.com/posts/2013-05-11-recursive-to- > iterative.html > > On Fri, Sep 15, 2017 at 8:56 AM, Will Spearman > > <[2]willspearman at gmail.com> > > wrote: > > > > ** **Sharing it as a github gist is helpful. Try this: > > ** > > > **[1][3]https://gist.github.com/willspearman/ > 97d9ee58b9391b0cdcd09d601017a2f8 > > ** **On Fri, Sep 15, 2017 at 8:48 AM Bob Gailer > > <[2][4]bgailer at gmail.com> wrote: > > > > ** ** **** **On Sep 14, 2017 9:33 AM, "Ken MacKenzie" > > <[1][3][5]ken at mack-z.com> > > ** ** **wrote: > > ** ** **** **> > > ** ** **** **> ** **So I have a bit of code I have created that works > to > > solve > > ** ** **the > > ** ** **** **problem, > > ** ** **** **> ** **however as an academic exercise, I realized I > could > > not > > ** ** **reason of a > > ** ** **** **way to > > ** ** **** **> ** **solve it without recursion. > > > > ** ** **** **My understanding of computer science says that recursion > is > > never > > ** ** **** **necessary. There is always a way to solve the problem > > without > > ** ** **recursion. > > ** ** **** **> ** **The situation, I have a file with many possible > > delimiters > > ** ** **and > > ** ** **** **those > > ** ** **** **> ** **delimiters have levels so to speak so as I am kind > > of > > ** ** **parsing a > > ** ** **** **tree, and > > ** ** **** **> ** **in this case a tree that is lists of lists of > lists > > of x > > ** ** **n... > > ** ** **** **> ** **Excuse the lack of real commenting in this > sample.** > > But > > ** ** **curious > > ** ** **** **what > > ** ** **** **> ** **other ways I could solve it, or if there are ways > I > > could > > ** ** **perhaps > > ** ** **** **make it > > ** ** **** **> ** **perform faster.** It performs fast enough but I > > realize the > > ** ** **file > > ** ** **** **could get > > ** ** **** **> ** **quite long. > > ** ** **** **It would be very helpful if you would give us a sample > > input and > > ** ** **the > > ** ** **** **corresponding output. Your description above does not > help. > > ** ** **** **Also your code has lots of** in it that I presume are > > either spaces > > ** ** **or > > ** ** **** **tabs. > > ** ** **** **I would appreciate it if you would post the code that is > > actually > > ** ** **** **executable. > > ** ** **** **My guess is that there's a much simpler way to do this. > > ** ** **** **> ** **======= > > ** ** **** **> ** **parse_1 = ["\n", "\x00", "\x01", "\x02", "\x03", > > "\x04", > > ** ** **"\x05", > > ** ** **** **"\x06", > > ** ** **** **> ** **"\x07"] > > ** ** **** **> ** **parse_2 = [chr(255), chr(254), chr(253), chr(252)] > > ** ** **** **> ** **all_parsers = parse_1 + parse_2 > > ** ** **** **> ** **def recursive_parse(in_var, parse_char): > > ** ** **** **> ** **** ** if isinstance(in_var, list): > > ** ** **** **> ** **** ** ** ** return [recursive_parse(x, parse_char) > > for x in > > ** ** **in_var] > > ** ** **** **> ** **** ** elif isinstance(in_var, str): > > ** ** **** **> ** **** ** ** ** return in_var.split(parse_char) > > ** ** **** **> ** **def nested_parse(str_in): > > ** ** **** **> ** **** ** big_list = [] > > ** ** **** **> ** **** ** temp = [] > > ** ** **** **> ** **** ** parse_list = all_parsers > > ** ** **** **> ** **** ** max_lvl = len(parse_list) - 1 > > ** ** **** **> ** **** ** for lvl, psr_c in enumerate(parse_list): > > ** ** **** **> ** **** ** ** ** # print("temp:", temp[0][:20]) > > ** ** **** **> ** **** ** ** ** if lvl == 0: > > ** ** **** **> ** **** ** ** ** ** ** temp.append(str_in.split(psr_ > c)) > > ** ** **** **> ** **** ** ** ** else: > > ** ** **** **> ** **** ** ** ** ** ** pre_lvl = lvl - 1 > > ** ** **** **> ** **** ** ** ** ** ** new_lvl = > > recursive_parse(temp[pre_lvl], > > ** ** **psr_c) > > ** ** **** **> ** **** ** ** ** ** ** temp.append(new_lvl) > > ** ** **** **> ** **** ** big_list = temp[max_lvl] > > ** ** **** **> ** **** ** return big_list > > ** ** **** **> > > ** ** **** **> _______________________________________________ > > ** ** **** **> TriZPUG mailing list > > ** ** **** **> [2][4][6]TriZPUG at python.org > > ** ** **** **> [3][5][7]https://mail.python. > org/mailman/listinfo/trizpug > > ** ** **** **> [4][6][8]http://tripython.org is the Triangle Python > > Users Group > > ** ** **** **> > > > > ** ** **References > > > > ** ** **** **Visible links > > ** ** **** **1. mailto:[7][9]ken at mack-z.com > > ** ** **** **2. mailto:[8][10]TriZPUG at python.org > > ** ** **** **3. [9][11]https://mail.python. > org/mailman/listinfo/trizpug > > ** ** **** **4. [10][12]http://tripython.org/ > > ** ** **_______________________________________________ > > ** ** **TriZPUG mailing list > > ** ** **[11][13]TriZPUG at python.org > > ** ** **[12][14]https://mail.python.org/mailman/listinfo/trizpug > > ** ** **[13][15]http://tripython.org is the Triangle Python Users > Group > > > > References > > > > ** **Visible links > > ** **1. > > > [16]https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2 > f8 > > ** **2. mailto:[17]bgailer at gmail.com > > ** **3. mailto:[18]ken at mack-z.com > > ** **4. mailto:[19]TriZPUG at python.org > > ** **5. [20]https://mail.python.org/mailman/listinfo/trizpug > > ** **6. [21]http://tripython.org/ > > ** **7. mailto:[22]ken at mack-z.com > > ** **8. mailto:[23]TriZPUG at python.org > > ** **9. [24]https://mail.python.org/mailman/listinfo/trizpug > > ** 10. [25]http://tripython.org/ > > ** 11. mailto:[26]TriZPUG at python.org > > ** 12. [27]https://mail.python.org/mailman/listinfo/trizpug > > ** 13. [28]http://tripython.org/ > > > > _______________________________________________ > > TriZPUG mailing list > > [29]TriZPUG at python.org > > [30]https://mail.python.org/mailman/listinfo/trizpug > > [31]http://tripython.org is the Triangle Python Users Group > > > > References > > > > Visible links > > 1. http://blog.moertel.com/posts/2013-05-11-recursive-to- > iterative.html > > 2. mailto:willspearman at gmail.com > > 3. https://gist.github.com/willspearman/ > 97d9ee58b9391b0cdcd09d601017a2f8 > > 4. mailto:bgailer at gmail.com > > 5. mailto:ken at mack-z.com > > 6. mailto:TriZPUG at python.org > > 7. https://mail.python.org/mailman/listinfo/trizpug > > 8. http://tripython.org/ > > 9. mailto:ken at mack-z.com > > 10. mailto:TriZPUG at python.org > > 11. https://mail.python.org/mailman/listinfo/trizpug > > 12. http://tripython.org/ > > 13. mailto:TriZPUG at python.org > > 14. https://mail.python.org/mailman/listinfo/trizpug > > 15. http://tripython.org/ > > 16. > https://gist.github.com/willspearman/97d9ee58b9391b0cdcd09d601017a2f8 > > 17. mailto:bgailer at gmail.com > > 18. mailto:ken at mack-z.com > > 19. mailto:TriZPUG at python.org > > 20. https://mail.python.org/mailman/listinfo/trizpug > > 21. http://tripython.org/ > > 22. mailto:ken at mack-z.com > > 23. mailto:TriZPUG at python.org > > 24. https://mail.python.org/mailman/listinfo/trizpug > > 25. http://tripython.org/ > > 26. mailto:TriZPUG at python.org > > 27. https://mail.python.org/mailman/listinfo/trizpug > > 28. http://tripython.org/ > > 29. mailto:TriZPUG at python.org > > 30. https://mail.python.org/mailman/listinfo/trizpug > > 31. http://tripython.org/ > > > > _______________________________________________ > TriZPUG mailing list > TriZPUG at python.org > https://mail.python.org/mailman/listinfo/trizpug > http://tripython.org is the Triangle Python Users Group > > From ncdave4life at gmail.com Fri Sep 15 12:00:10 2017 From: ncdave4life at gmail.com (David Burton) Date: Fri, 15 Sep 2017 12:00:10 -0400 Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: <8DC86A17-B576-43D4-872A-867D01DCD446@unc.edu> References: <1505481477.451223558@apps.rackspace.com> <8DC86A17-B576-43D4-872A-867D01DCD446@unc.edu> Message-ID: Parsing problems are *always* best solved by first creating a formal syntax specification. There are no non-trivial exceptions to that rule. You should not write any code until you have done that. If you haven't done a formal syntax spec then you do not yet fully understand the problem you're working on, and you should not be writing code. *Sometimes it helps to know what you're doing.* - Quotations from Prof. Kwan(sp?) My preference is for Pascal-esque syntax diagrams (a/k/a "railroad diagrams"), like these: http://primepuzzle.com/tp2/syntax-diagrams.html https://www.google.com/search?q=%22syntax+diagram%22 You could also use BNF , but I do not recommend it. The problem with BNF is that it cannot express loops, so you end up using recursion when a loop would be simpler and clearer. The mains advantage of BNF are that (1) it's just ASCII, so you can easily paste it into comments in your code, etc., and (2) there are parser generator tools to automatically generate a parser from the BNF. But that's a very tiny payoff for the heavy cost of obfuscating your parser with artificial, unnecessary recursion, to avoid looping. Once you have your syntax spec'd, you can use it as a "flow chart" (remember those, anyone?) for your code. Unless the syntax is really horrible, writing the code then becomes trivial. If you managed to spec your syntax without using recursion then you won't need recursion in your code. But if it was necessary to use recursion in your syntax diagrams then the "right (cleanest, most natural, easiest to understand) way to write your parser will use recursion. If you're stuck working in a primitive language which doesn't support recursion, then if your syntax diagrams use recursion, in your parser you'll need to simulate recursion with an explicit stack. Otherwise, use recursion when it is the natural way to express the syntax, and don't use it otherwise. Dave -------------- next part -------------- Parsing problems are always**best solved by first creating a formal syntax specification. There are no non-trivial exceptions to that rule. You should not write any code until you have done that. If you haven't done a formal syntax spec then you do not yet fully understand the problem you're working on, and you should not be writing code. Sometimes it helps to know what you're doing. - Quotations from Prof. Kwan(sp?) My preference is for Pascal-esque syntax diagrams (a/k/a "railroad diagrams"), like these: [1]http://primepuzzle.com/tp2/syntax-diagrams.html [2]https://www.google.com/search?q=%22syntax+diagram%22 You could also use [3]BNF, but I do not recommend it. The problem with BNF is that it cannot express loops, so you end up using recursion when a loop would be simpler and clearer. The mains advantage of BNF are that (1) it's just ASCII, so you can easily paste it into comments in your code, etc., and (2) there are parser generator tools to automatically generate a parser from the BNF. But that's a very tiny payoff for the heavy cost of obfuscating your parser with artificial, unnecessary recursion, to avoid looping. Once you have your syntax spec'd, you can use it as a "flow chart" (remember those, anyone?) for your code. Unless the syntax is really horrible, writing the code then becomes trivial. If you managed to spec your syntax without using recursion then you won't need recursion in your code. But if it was necessary to use recursion in your syntax diagrams then the "right (cleanest, most natural, easiest to understand) way to write your parser will use recursion. If you're stuck working in a primitive language which doesn't support recursion, then if your syntax diagrams use recursion, in your parser you'll need to simulate recursion with an explicit stack. Otherwise, use recursion when it is the natural way to express the syntax, and don't use it otherwise. Dave References Visible links 1. http://primepuzzle.com/tp2/syntax-diagrams.html 2. https://www.google.com/search?q=%22syntax+diagram%22 3. https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form From ken at mack-z.com Fri Sep 15 12:32:17 2017 From: ken at mack-z.com (Ken MacKenzie) Date: Fri, 15 Sep 2017 12:32:17 -0400 Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: <8DC86A17-B576-43D4-872A-867D01DCD446@unc.edu> References: <1505481477.451223558@apps.rackspace.com> <8DC86A17-B576-43D4-872A-867D01DCD446@unc.edu> Message-ID: OK I have gone through all the responses, let me try to address what I can 1. I pasted from emacs into gmail, sorry it formatted poorly. I will get the code out into a repo later today to make it easier to grab. 2. A note about the code, right now it is a simple module that I am testing in ipython. So the bigger picture. We have a u2 DB on Solaris here. U2 is an atrocious select performer so to serve so RESTful API's (using falcon) to support PowerBI reporting I wrote a "Data Bridge" program that using fabric issues commands against the DB to build XML extracts that I can pull into SQL Server (or another RDBMS using SQL Alchemy) to serve the reporting API's. However the export process for the U2 side can take an hour for a file with say about 1 million records. That seemed slow to me, plus no way to try to get it to go faster as that was maxing out a single core on the m10 in question and it is a single threaded app. This becomes a conundrum as the timing of the extract needs to be after backups but before business starts. So I got to figuring I wonder if I could just pull the raw data files and parse them. I mean the data I need is plain text in there, I can bring them down with fabric/scp and then work with them manually. So that is how we are here. 3. What I know about the data. There is a list of many possible delimiters but there is a core few I truly care about. I am no taking the range of possible delimiters and cleaning them out. By the time we get to the recursive function there are 5 levels of delimiters it could go through in recursion however each level could have a very large branch count but the branches get handled serially so that should be ok. 4. I did change the code, well added another entry point, to deal with parsing the file line by line as opposed to a readlines(). No immediate change in performance which I expect but when I get to testing say that 1 million record file it will become relevant. I hope this helps a bit as to there where why and it is not exactly premature optimization but an attempt to try to proof if this different method can compete or exceed the existing tested performance. Ken -------------- next part -------------- OK I have gone through all the responses, let me try to address what I can 1.** I pasted from emacs into gmail, sorry it formatted poorly.** I will get the code out into a repo later today to make it easier to grab. 2.** A note about the code, right now it is a simple module that I am testing in ipython.** So the bigger picture.** We have a u2 DB on Solaris here.** U2 is an atrocious select performer so to serve so RESTful API's (using falcon) to support PowerBI reporting I wrote a "Data Bridge" program that using fabric issues commands against the DB to build XML extracts that I can pull into SQL Server (or another RDBMS using SQL Alchemy) to serve the reporting API's.** However the export process for the U2 side can take an hour for a file with say about 1 million records.** That seemed slow to me, plus no way to try to get it to go faster as that was maxing out a single core on the m10 in question and it is a single threaded app.** This becomes a conundrum as the timing of the extract needs to be after backups but before business starts. So I got to figuring I wonder if I could just pull the raw data files and parse them.** I mean the data I need is plain text in there, I can bring them down with fabric/scp and then work with them manually.** So that is how we are here. 3.** What I know about the data.** There is a list of many possible delimiters but there is a core few I truly care about.** I am no taking the range of possible delimiters and cleaning them out.** By the time we get to the recursive function there are 5 levels of delimiters it could go through in recursion however each level could have a very large branch count but the branches get handled serially so that should be ok. 4.** I did change the code, well added another entry point, to deal with parsing the file line by line as opposed to a readlines().** No immediate change in performance which I expect but when I get to testing say that 1 million record file it will become relevant. I hope this helps a bit as to there where why and it is not exactly premature optimization but an attempt to try to proof if this different method can compete or exceed the existing tested performance. Ken From ken at mack-z.com Fri Sep 15 14:35:11 2017 From: ken at mack-z.com (Ken MacKenzie) Date: Fri, 15 Sep 2017 14:35:11 -0400 Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: References: <1505481477.451223558@apps.rackspace.com> <8DC86A17-B576-43D4-872A-867D01DCD446@unc.edu> Message-ID: Side note response I missed: 5. I am fine with commentary on my variable name, or any part of the code. I feel that if one is not ready for criticism of their code then they should not put it out publicly. I mean that is the point of open source anyway. So let the code have it if you see something. A small caveat, the code was made to be a quick R&D throwaway not production code. I am sure that will curse it into production at some point by saying it. Anyway I would never leave the code as is. I mean there isn't a docstring to be seen and the only comments in the actual code are previous code attempts I replaced. I do know that I have a history of being lazy with variable naming though. Ken On Fri, Sep 15, 2017 at 12:32 PM, Ken MacKenzie wrote: > OK I have gone through all the responses, let me try to address what I can > > 1. I pasted from emacs into gmail, sorry it formatted poorly. I will get > the code out into a repo later today to make it easier to grab. > > 2. A note about the code, right now it is a simple module that I am > testing in ipython. So the bigger picture. We have a u2 DB on Solaris > here. U2 is an atrocious select performer so to serve so RESTful API's > (using falcon) to support PowerBI reporting I wrote a "Data Bridge" program > that using fabric issues commands against the DB to build XML extracts that > I can pull into SQL Server (or another RDBMS using SQL Alchemy) to serve > the reporting API's. However the export process for the U2 side can take > an hour for a file with say about 1 million records. That seemed slow to > me, plus no way to try to get it to go faster as that was maxing out a > single core on the m10 in question and it is a single threaded app. This > becomes a conundrum as the timing of the extract needs to be after backups > but before business starts. > > So I got to figuring I wonder if I could just pull the raw data files and > parse them. I mean the data I need is plain text in there, I can bring > them down with fabric/scp and then work with them manually. So that is how > we are here. > > 3. What I know about the data. There is a list of many possible > delimiters but there is a core few I truly care about. I am no taking the > range of possible delimiters and cleaning them out. By the time we get to > the recursive function there are 5 levels of delimiters it could go through > in recursion however each level could have a very large branch count but > the branches get handled serially so that should be ok. > > 4. I did change the code, well added another entry point, to deal with > parsing the file line by line as opposed to a readlines(). No immediate > change in performance which I expect but when I get to testing say that 1 > million record file it will become relevant. > > I hope this helps a bit as to there where why and it is not exactly > premature optimization but an attempt to try to proof if this different > method can compete or exceed the existing tested performance. > > Ken > -------------- next part -------------- Side note response I missed: 5.** I am fine with commentary on my variable name, or any part of the code.** I feel that if one is not ready for criticism of their code then they should not put it out publicly.** I mean that is the point of open source anyway.** So let the code have it if you see something.** A small caveat, the code was made to be a quick R&D throwaway not production code.** I am sure that will curse it into production at some point by saying it.** Anyway I would never leave the code as is.** I mean there isn't a docstring to be seen and the only comments in the actual code are previous code attempts I replaced.** I do know that I have a history of being lazy with variable naming though. Ken On Fri, Sep 15, 2017 at 12:32 PM, Ken MacKenzie <[1]ken at mack-z.com> wrote: OK I have gone through all the responses, let me try to address what I can 1.** I pasted from emacs into gmail, sorry it formatted poorly.** I will get the code out into a repo later today to make it easier to grab. 2.** A note about the code, right now it is a simple module that I am testing in ipython.** So the bigger picture.** We have a u2 DB on Solaris here.** U2 is an atrocious select performer so to serve so RESTful API's (using falcon) to support PowerBI reporting I wrote a "Data Bridge" program that using fabric issues commands against the DB to build XML extracts that I can pull into SQL Server (or another RDBMS using SQL Alchemy) to serve the reporting API's.** However the export process for the U2 side can take an hour for a file with say about 1 million records.** That seemed slow to me, plus no way to try to get it to go faster as that was maxing out a single core on the m10 in question and it is a single threaded app.** This becomes a conundrum as the timing of the extract needs to be after backups but before business starts. So I got to figuring I wonder if I could just pull the raw data files and parse them.** I mean the data I need is plain text in there, I can bring them down with fabric/scp and then work with them manually.** So that is how we are here. 3.** What I know about the data.** There is a list of many possible delimiters but there is a core few I truly care about.** I am no taking the range of possible delimiters and cleaning them out.** By the time we get to the recursive function there are 5 levels of delimiters it could go through in recursion however each level could have a very large branch count but the branches get handled serially so that should be ok. 4.** I did change the code, well added another entry point, to deal with parsing the file line by line as opposed to a readlines().** No immediate change in performance which I expect but when I get to testing say that 1 million record file it will become relevant. I hope this helps a bit as to there where why and it is not exactly premature optimization but an attempt to try to proof if this different method can compete or exceed the existing tested performance. Ken References Visible links 1. mailto:ken at mack-z.com From ken at mack-z.com Fri Sep 15 14:56:02 2017 From: ken at mack-z.com (Ken MacKenzie) Date: Fri, 15 Sep 2017 14:56:02 -0400 Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: References: <1505481477.451223558@apps.rackspace.com> <8DC86A17-B576-43D4-872A-867D01DCD446@unc.edu> Message-ID: One more update. As part of extended research I have figured out the juice is not worth the squeeze on this method. Reliability concerns inside the overall data structures. That being said as a point of academic discussion on the nested parse engine in recursive vs iterative mode I consider the conversation worthwhile. But the code will probably end there for now. On Fri, Sep 15, 2017 at 2:35 PM, Ken MacKenzie wrote: > Side note response I missed: > > 5. I am fine with commentary on my variable name, or any part of the > code. I feel that if one is not ready for criticism of their code then > they should not put it out publicly. I mean that is the point of open > source anyway. So let the code have it if you see something. A small > caveat, the code was made to be a quick R&D throwaway not production code. > I am sure that will curse it into production at some point by saying it. > Anyway I would never leave the code as is. I mean there isn't a docstring > to be seen and the only comments in the actual code are previous code > attempts I replaced. I do know that I have a history of being lazy with > variable naming though. > > Ken > > On Fri, Sep 15, 2017 at 12:32 PM, Ken MacKenzie wrote: > >> OK I have gone through all the responses, let me try to address what I can >> >> 1. I pasted from emacs into gmail, sorry it formatted poorly. I will >> get the code out into a repo later today to make it easier to grab. >> >> 2. A note about the code, right now it is a simple module that I am >> testing in ipython. So the bigger picture. We have a u2 DB on Solaris >> here. U2 is an atrocious select performer so to serve so RESTful API's >> (using falcon) to support PowerBI reporting I wrote a "Data Bridge" program >> that using fabric issues commands against the DB to build XML extracts that >> I can pull into SQL Server (or another RDBMS using SQL Alchemy) to serve >> the reporting API's. However the export process for the U2 side can take >> an hour for a file with say about 1 million records. That seemed slow to >> me, plus no way to try to get it to go faster as that was maxing out a >> single core on the m10 in question and it is a single threaded app. This >> becomes a conundrum as the timing of the extract needs to be after backups >> but before business starts. >> >> So I got to figuring I wonder if I could just pull the raw data files and >> parse them. I mean the data I need is plain text in there, I can bring >> them down with fabric/scp and then work with them manually. So that is how >> we are here. >> >> 3. What I know about the data. There is a list of many possible >> delimiters but there is a core few I truly care about. I am no taking the >> range of possible delimiters and cleaning them out. By the time we get to >> the recursive function there are 5 levels of delimiters it could go through >> in recursion however each level could have a very large branch count but >> the branches get handled serially so that should be ok. >> >> 4. I did change the code, well added another entry point, to deal with >> parsing the file line by line as opposed to a readlines(). No immediate >> change in performance which I expect but when I get to testing say that 1 >> million record file it will become relevant. >> >> I hope this helps a bit as to there where why and it is not exactly >> premature optimization but an attempt to try to proof if this different >> method can compete or exceed the existing tested performance. >> >> Ken >> > > -------------- next part -------------- One more update.** As part of extended research I have figured out the juice is not worth the squeeze on this method.** Reliability concerns inside the overall data structures.** That being said as a point of academic discussion on the nested parse engine in recursive vs iterative mode I consider the conversation worthwhile.** But the code will probably end there for now. On Fri, Sep 15, 2017 at 2:35 PM, Ken MacKenzie <[1]ken at mack-z.com> wrote: Side note response I missed: 5.** I am fine with commentary on my variable name, or any part of the code.** I feel that if one is not ready for criticism of their code then they should not put it out publicly.** I mean that is the point of open source anyway.** So let the code have it if you see something.** A small caveat, the code was made to be a quick R&D throwaway not production code.** I am sure that will curse it into production at some point by saying it.** Anyway I would never leave the code as is.** I mean there isn't a docstring to be seen and the only comments in the actual code are previous code attempts I replaced.** I do know that I have a history of being lazy with variable naming though. Ken On Fri, Sep 15, 2017 at 12:32 PM, Ken MacKenzie <[2]ken at mack-z.com> wrote: OK I have gone through all the responses, let me try to address what I can 1.** I pasted from emacs into gmail, sorry it formatted poorly.** I will get the code out into a repo later today to make it easier to grab. 2.** A note about the code, right now it is a simple module that I am testing in ipython.** So the bigger picture.** We have a u2 DB on Solaris here.** U2 is an atrocious select performer so to serve so RESTful API's (using falcon) to support PowerBI reporting I wrote a "Data Bridge" program that using fabric issues commands against the DB to build XML extracts that I can pull into SQL Server (or another RDBMS using SQL Alchemy) to serve the reporting API's.** However the export process for the U2 side can take an hour for a file with say about 1 million records.** That seemed slow to me, plus no way to try to get it to go faster as that was maxing out a single core on the m10 in question and it is a single threaded app.** This becomes a conundrum as the timing of the extract needs to be after backups but before business starts. So I got to figuring I wonder if I could just pull the raw data files and parse them.** I mean the data I need is plain text in there, I can bring them down with fabric/scp and then work with them manually.** So that is how we are here. 3.** What I know about the data.** There is a list of many possible delimiters but there is a core few I truly care about.** I am no taking the range of possible delimiters and cleaning them out.** By the time we get to the recursive function there are 5 levels of delimiters it could go through in recursion however each level could have a very large branch count but the branches get handled serially so that should be ok. 4.** I did change the code, well added another entry point, to deal with parsing the file line by line as opposed to a readlines().** No immediate change in performance which I expect but when I get to testing say that 1 million record file it will become relevant. I hope this helps a bit as to there where why and it is not exactly premature optimization but an attempt to try to proof if this different method can compete or exceed the existing tested performance. Ken References Visible links 1. mailto:ken at mack-z.com 2. mailto:ken at mack-z.com From cbc at unc.edu Fri Sep 15 15:04:16 2017 From: cbc at unc.edu (Calloway, Chris) Date: Fri, 15 Sep 2017 19:04:16 +0000 Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: References: <1505481477.451223558@apps.rackspace.com> <8DC86A17-B576-43D4-872A-867D01DCD446@unc.edu> Message-ID: On 9/15/17, 2:35 PM, "TriZPUG on behalf of Ken MacKenzie" wrote: > I feel that if one is not ready for criticism of their code then > they should not put it out publicly. I mean that is the point of open > source anyway. Very much in the spirit of Stacy?s featured talk last month: Slides: https://geekgirlbeta.wordpress.com/2017/08/14/code-reviews-using-art-critique-principles-the-slides/ Video: https://www.youtube.com/watch?v=xpqwuaCW6os The flipside is that we should be cognizant of the fact that human beings are receiving the criticisms we make and so offer them in a way that is not personal. David Handy is a shining example of such good behavior. These two sides are reflective of a very old programming maxim: ?Be liberal in what you accept, and conservative in what you offer.? -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 From aikimark at aol.com Fri Sep 15 15:57:22 2017 From: aikimark at aol.com (Mark Hutchinson) Date: Fri, 15 Sep 2017 15:57:22 -0400 Subject: [TriPython] A question of recursion and nested parsing Message-ID: <15e871df9c3-c09-3f1bb@webjasstg-vab52.srv.aolmail.net> Ken Regarding your recursion and nested parsing problem, I'd first say to follow David's advice and make the specification your first step. Kudos to David for an excellent reply. I think I would classify your problem as DSL, Domain Specific Language. As such, here are some potentially useful links to DSL topics: https://en.wikipedia.org/wiki/Domain-specific_language https://ep2015.europython.eu/conference/talks/the-unabridged-guide-to-domain-specific-languages-in-python https://www.slideshare.net/Siddhi/creating-domain-specific-languages-in-python * also attend Brian's PyParsing presentation at the end of September * Alternatives to PyParsing are PLY, PyDSLtool, Textx, lark, and Coco (generator) http://blog.erezsh.com/how-to-write-a-dsl-in-python-with-lark/ Perhaps you might need to roll-your-own DSL. Here is a tutorial if you take that path. https://mathema.tician.de/tutorial-dsl-codegen/ ========================== Some personal thoughts and experiences. * Sometimes cleaning the text may simplify your parsing efforts. It looks like your question includes text cleaning. I think it best to separate the cleaning and parsing code. * When files get large, you might need to perform buffered I/O. While line-by-line I/O is a form of buffering, it doesn't always lend itself to good performance for multi-line parsing. * If performance is still a bottleneck, you might need to break up the work into multiple executables and join them with pipes. Mark Hutchinson -------------- next part -------------- Ken Regarding your recursion and nested parsing problem, I'd first say to follow David's advice and make the specification your first step. Kudos to David for an excellent reply. I think I would classify your problem as DSL, Domain Specific Language. As such, here are some potentially useful links to DSL topics: https://en.wikipedia.org/wiki/Domain-specific_language https://ep2015.europython.eu/conference/talks/the-unabridged-guide-to-domain-specific-languages-in-python https://www.slideshare.net/Siddhi/creating-domain-specific-languages-in-python * also attend Brian's PyParsing presentation at the end of September * Alternatives to PyParsing are PLY, PyDSLtool, Textx, lark, and Coco (generator) http://blog.erezsh.com/how-to-write-a-dsl-in-python-with-lark/ Perhaps you might need to roll-your-own DSL. Here is a tutorial if you take that path. https://mathema.tician.de/tutorial-dsl-codegen/ ========================== Some personal thoughts and experiences. * Sometimes cleaning the text may simplify your parsing efforts. It looks like your question includes text cleaning. I think it best to separate the cleaning and parsing code. * When files get large, you might need to perform buffered I/O. While line-by-line I/O is a form of buffering, it doesn't always lend itself to good performance for multi-line parsing. * If performance is still a bottleneck, you might need to break up the work into multiple executables and join them with pipes. Mark Hutchinson From ken at mack-z.com Fri Sep 15 16:45:28 2017 From: ken at mack-z.com (Ken MacKenzie) Date: Fri, 15 Sep 2017 16:45:28 -0400 Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: <15e871df9c3-c09-3f1bb@webjasstg-vab52.srv.aolmail.net> References: <15e871df9c3-c09-3f1bb@webjasstg-vab52.srv.aolmail.net> Message-ID: Because now this is an academic exercise I am going to start playing with this in another problem domain I like to work with, NLP. I will take a look at that. I think recursion is an acceptable solution in this case however because of python not being a functional language and lacking TCO it would typically be a model I avoid in python code. I shall try to attend that. Last I looked TriPUG meetings were out towards Durham and Chapel Hill which as a Joco resident makes it tough to head that way after work. I was so happy TriLUG moved back to Raleigh meetings recently. I need to make an effort to attend because frankly I am thinking about entering the job market because I am getting the feeling I just no longer belong at my current employer and want to go somewhere I can dive deeper into python and other modern languages. So better to put myself out there with a real face and name to the local community. Ken On Fri, Sep 15, 2017 at 3:57 PM, Mark Hutchinson via TriZPUG < trizpug at python.org> wrote: > Ken > Regarding your recursion and nested parsing problem, I'd first say to > follow David's advice and make the specification your first step. Kudos > to David for an excellent reply. > I think I would classify your problem as DSL, Domain Specific Language. > As such, here are some potentially useful links to DSL topics: > https://en.wikipedia.org/wiki/Domain-specific_language > https://ep2015.europython.eu/conference/talks/the- > unabridged-guide-to-domain-specific-languages-in-python > https://www.slideshare.net/Siddhi/creating-domain- > specific-languages-in-python > > * also attend Brian's PyParsing presentation at the end of September > * Alternatives to PyParsing are PLY, PyDSLtool, Textx, lark, and Coco > (generator) > > http://blog.erezsh.com/how-to-write-a-dsl-in-python-with-lark/ > Perhaps you might need to roll-your-own DSL. Here is a tutorial if you > take that path. > https://mathema.tician.de/tutorial-dsl-codegen/ > ========================== > Some personal thoughts and experiences. > * Sometimes cleaning the text may simplify your parsing efforts. It > looks > like your question includes text cleaning. I think it best to separate > the cleaning and parsing code. > * When files get large, you might need to perform buffered I/O. While > line-by-line I/O is a form of buffering, it doesn't always lend itself > to > good performance for multi-line parsing. > * If performance is still a bottleneck, you might need to break up the > work into multiple executables and join them with pipes. > Mark Hutchinson > > > -------------- next part -------------- Because now this is an academic exercise I am going to start playing with this in another problem domain I like to work with, NLP.** I will take a look at that.** I think recursion is an acceptable solution in this case however because of python not being a functional language and lacking TCO it would typically be a model I avoid in python code. I shall try to attend that.** Last I looked TriPUG meetings were out towards Durham and Chapel Hill which as a Joco resident makes it tough to head that way after work.** I was so happy TriLUG moved back to Raleigh meetings recently.** I need to make an effort to attend because frankly I am thinking about entering the job market because I am getting the feeling I just no longer belong at my current employer and want to go somewhere I can dive deeper into python and other modern languages.** So better to put myself out there with a real face and name to the local community. Ken On Fri, Sep 15, 2017 at 3:57 PM, Mark Hutchinson via TriZPUG <[1]trizpug at python.org> wrote: ** **Ken ** **Regarding your recursion and nested parsing problem, I'd first say to ** **follow David's advice and make the specification your first step.** Kudos ** **to David for an excellent reply. ** **I think I would classify your problem as DSL, Domain Specific Language. ** ** As such, here are some potentially useful links to DSL topics: ** **[2]https://en.wikipedia.org/wiki/Domain-specific_language ** **[3]https://ep2015.europython.eu/conference/talks/the-unabridged-guide-to-domain-specific-languages-in-python ** **[4]https://www.slideshare.net/Siddhi/creating-domain-specific-languages-in-python ** ** *** also attend Brian's PyParsing presentation at the end of September ** ** *** Alternatives to PyParsing are PLY, PyDSLtool, Textx, lark, and Coco ** ** **(generator) ** **[5]http://blog.erezsh.com/how-to-write-a-dsl-in-python-with-lark/ ** **Perhaps you might need to roll-your-own DSL.** Here is a tutorial if you ** **take that path. ** **[6]https://mathema.tician.de/tutorial-dsl-codegen/ ** **========================== ** **Some personal thoughts and experiences. ** *** Sometimes cleaning the text may simplify your parsing efforts.** It looks ** **like your question includes text cleaning.** I think it best to separate ** **the cleaning and parsing code. ** *** When files get large, you might need to perform buffered I/O.** While ** **line-by-line I/O is a form of buffering, it doesn't always lend itself to ** **good performance for multi-line parsing. ** *** If performance is still a bottleneck, you might need to break up the ** **work into multiple executables and join them with pipes. ** **Mark Hutchinson References Visible links 1. mailto:trizpug at python.org 2. https://en.wikipedia.org/wiki/Domain-specific_language 3. https://ep2015.europython.eu/conference/talks/the-unabridged-guide-to-domain-specific-languages-in-python 4. https://www.slideshare.net/Siddhi/creating-domain-specific-languages-in-python 5. http://blog.erezsh.com/how-to-write-a-dsl-in-python-with-lark/ 6. https://mathema.tician.de/tutorial-dsl-codegen/ From ken at mack-z.com Fri Sep 15 16:40:24 2017 From: ken at mack-z.com (Ken MacKenzie) Date: Fri, 15 Sep 2017 16:40:24 -0400 Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: References: <1505481477.451223558@apps.rackspace.com> <8DC86A17-B576-43D4-872A-867D01DCD446@unc.edu> Message-ID: I need to sit down and watch that. Probably need to make some of my coworkers do the same. I try to be very liberal with criticism but I also like to see proof that the criticism holds weight and of course the criticism is better with an alternative solution. However I am a person that believes the best code comes from 10 versions that preceded it that proved to be the wrong way. The reason is a scientists, failure IS a result and it is an important result, if not the most important result. Nothing scares me more than when my code compiles/runs without obvious issue the first time. That is usually a sure sign that something really bad has happened. It is kind of like what I say about the game of chess... You learn more when you lose than when you win. On Fri, Sep 15, 2017 at 3:04 PM, Calloway, Chris wrote: > On 9/15/17, 2:35 PM, "TriZPUG on behalf of Ken MacKenzie" > > wrote: > > I feel that if one is not ready for criticism of their code then > > they should not put it out publicly. I mean that is the point of open > > source anyway. > > Very much in the spirit of Stacy?s featured talk last month: > > Slides: https://geekgirlbeta.wordpress.com/2017/08/14/code- > reviews-using-art-critique-principles-the-slides/ > Video: https://www.youtube.com/watch?v=xpqwuaCW6os > > The flipside is that we should be cognizant of the fact that human beings > are receiving the criticisms we make and so offer them in a way that is not > personal. David Handy is a shining example of such good behavior. > > These two sides are reflective of a very old programming maxim: ?Be > liberal in what you accept, and conservative in what you offer.? > > -- > Sincerely, > > Chris Calloway > Applications Analyst > University of North Carolina > Renaissance Computing Institute > (919) 599-3530 > > -------------- next part -------------- I need to sit down and watch that.** Probably need to make some of my coworkers do the same.** I try to be very liberal with criticism but I also like to see proof that the criticism holds weight and of course the criticism is better with an alternative solution.** However I am a person that believes the best code comes from 10 versions that preceded it that proved to be the wrong way.** The reason is a scientists, failure IS a result and it is an important result, if not the most important result.** Nothing scares me more than when my code compiles/runs without obvious issue the first time.** That is usually a sure sign that something really bad has happened. It is kind of like what I say about the game of chess...** You learn more when you lose than when you win. On Fri, Sep 15, 2017 at 3:04 PM, Calloway, Chris <[1]cbc at unc.edu> wrote: On 9/15/17, 2:35 PM, "TriZPUG on behalf of Ken MacKenzie" wrote: > I feel that if one is not ready for criticism of their code then > they should not put it out publicly.** I mean that is the point of open > source anyway. Very much in the spirit of Stacy***s featured talk last month: Slides: [4]https://geekgirlbeta.wordpress.com/2017/08/14/code-reviews-using-art-critique-principles-the-slides/ Video: [5]https://www.youtube.com/watch?v=xpqwuaCW6os The flipside is that we should be cognizant of the fact that human beings are receiving the criticisms we make and so offer them in a way that is not personal. David Handy is a shining example of such good behavior. These two sides are reflective of a very old programming maxim: ***Be liberal in what you accept, and conservative in what you offer.*** -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute [6](919) 599-3530 References Visible links 1. mailto:cbc at unc.edu 2. mailto:unc.edu at python.org 3. mailto:ken at mack-z.com 4. https://geekgirlbeta.wordpress.com/2017/08/14/code-reviews-using-art-critique-principles-the-slides/ 5. https://www.youtube.com/watch?v=xpqwuaCW6os 6. file:///tmp/tel:%28919%29%20599-3530 From scott at hallcomm-inc.com Fri Sep 15 17:52:05 2017 From: scott at hallcomm-inc.com (Scott G. Hall) Date: Fri, 15 Sep 2017 17:52:05 -0400 Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: References: <1505481477.451223558@apps.rackspace.com> <8DC86A17-B576-43D4-872A-867D01DCD446@unc.edu> Message-ID: <2169d032-925a-29a3-66ed-8f3ee705de70@hallcomm-inc.com> When I learned language parsing (early 1980's) and worked as a research grunt on the C Standards Committee (for Howard at Computer Innovations and the C86-Plus compiler...), we used a tree model to represent syntax: Drawing Tree Diagrams: Problems and Suggestions (http://www.academypublication.com/issues/past/jltr/vol01/06/29.pdf) also used for YACC syntax (Yet Another Compiler Compiler -- a parsing generator) which is in-turn based on Linguistics parsing trees: Syntax - Drawing tree diagrams of ambiguous sentences generated by a CFG (https://linguistics.stackexchange.com/questions/9706/drawing-tree-diagrams-of-ambiguous-sentences-generated-by-a-cfg) Then there's always the /Backus-Naur Form/ (Backus Normal Form) that was used in the late 1980's and early 1990's by /Dr. Dobb's Journal/ and the /C/C++ User's Journal/: Notations for context-free grammers: BNF, Syntax Diagrams, EBNF (http://www.cs.man.ac.uk/~pjj/bnf/bnf.html ) The /railroad/ syntax diagrams seem intriguing though.? - sgh On 09/15/2017 12:00 PM, David Burton wrote: > Parsing problems are always**best solved by first creating a formal syntax > specification. There are no non-trivial exceptions to that rule. You > should not write any code until you have done that. > If you haven't done a formal syntax spec then you do not yet fully > understand the problem you're working on, and you should not be writing > code. > > Sometimes it helps to know what you're doing. > - Quotations from Prof. Kwan(sp?) > > My preference is for Pascal-esque syntax diagrams (a/k/a "railroad > diagrams"), like these: > [1]http://primepuzzle.com/tp2/syntax-diagrams.html > [2]https://www.google.com/search?q=%22syntax+diagram%22 -- Scott G. Hall Raleigh, NC, USA ph. 919-624-5973 Scott at HallComm-Inc.Com -------------- next part -------------- When I learned language parsing (early 1980's) and worked as a research grunt on the C Standards Committee (for Howard at Computer Innovations and the C86-Plus compiler...), we used a tree model to represent syntax: [1]Drawing Tree Diagrams: Problems and Suggestions ([2]http://www.academypublication.com/issues/past/jltr/vol01/06/29.pdf) also used for YACC syntax (Yet Another Compiler Compiler -- a parsing generator) which is in-turn based on Linguistics parsing trees: [3]Syntax - Drawing tree diagrams of ambiguous sentences generated by a CFG ([4]https://linguistics.stackexchange.com/questions/9706/drawing-tree-diagrams-of-ambiguous-sentences-generated-by-a-cfg) Then there's always the Backus-Naur Form (Backus Normal Form) that was used in the late 1980's and early 1990's by Dr. Dobb's Journal and the C/C++ User's Journal: [5]Notations for context-free grammers: BNF, Syntax Diagrams, EBNF ([6]http://www.cs.man.ac.uk/~pjj/bnf/bnf.html) The railroad syntax diagrams seem intriguing though. - sgh On 09/15/2017 12:00 PM, David Burton wrote: Parsing problems are always**best solved by first creating a formal syntax specification. There are no non-trivial exceptions to that rule. You should not write any code until you have done that. If you haven't done a formal syntax spec then you do not yet fully understand the problem you're working on, and you should not be writing code. Sometimes it helps to know what you're doing. - Quotations from Prof. Kwan(sp?) My preference is for Pascal-esque syntax diagrams (a/k/a "railroad diagrams"), like these: [1][7]http://primepuzzle.com/tp2/syntax-diagrams.html [2][8]https://www.google.com/search?q=%22syntax+diagram%22 -- Scott G. Hall Raleigh, NC, USA ph. 919-624-5973 [9]Scott at HallComm-Inc.Com References Visible links 1. http://www.academypublication.com/issues/past/jltr/vol01/06/29.pdf 2. http://www.academypublication.com/issues/past/jltr/vol01/06/29.pdf 3. https://linguistics.stackexchange.com/questions/9706/drawing-tree-diagrams-of-ambiguous-sentences-generated-by-a-cfg 4. https://linguistics.stackexchange.com/questions/9706/drawing-tree-diagrams-of-ambiguous-sentences-generated-by-a-cfg 5. http://www.cs.man.ac.uk/%7Epjj/bnf/bnf.html 6. http://www.cs.man.ac.uk/%7Epjj/bnf/bnf.html 7. http://primepuzzle.com/tp2/syntax-diagrams.html 8. https://www.google.com/search?q=%22syntax+diagram%22 9. mailto:Scott at hallcomm-inc.com From cbc at unc.edu Fri Sep 15 15:07:47 2017 From: cbc at unc.edu (Calloway, Chris) Date: Fri, 15 Sep 2017 19:07:47 +0000 Subject: [TriPython] A question of recursion and nested parsing In-Reply-To: References: <1505481477.451223558@apps.rackspace.com> <8DC86A17-B576-43D4-872A-867D01DCD446@unc.edu> Message-ID: <360A51AC-4413-43DF-AC14-0C29CB55F994@unc.edu> On 9/15/17, 3:04 PM, "TriZPUG on behalf of Calloway, Chris" wrote: ? These two sides are reflective of a very old programming maxim: ?Be liberal in what you accept, and conservative in what you offer.? https://en.wikipedia.org/wiki/Robustness_principle Why am I not surprised this came from Jon Postel? -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 From cbc at unc.edu Mon Sep 18 13:24:09 2017 From: cbc at unc.edu (Calloway, Chris) Date: Mon, 18 Sep 2017 17:24:09 +0000 Subject: [TriPython] Reminder: Durham Project Night Message-ID: There?s another great project night tonight at the ever gracious Caktus in Durham. http://tripython.org/Members/markdlavin/sept-17-dpn When: Monday, September 18, 6-9pm Where: Caktus Group Tech Space 108 Morris St Durham What: Have a project you want to show off, share, seek help with, or just get some work done surrounded by like-minded Python lovers? Join us for our monthly project night and do just that! Don't have something to work on? Just need some help with Python? Show up and enjoy the energy, sprint on an open source project, find something interesting to contribute to or be inspired! The setting is informal and there is no schedule, so don't worry if you show up past the start time. Whether you are a Python newbie needing help or have an open source project you want to share, come hang out and hack. Park in the municipal deck on the other side of the Arts Council across W. Morgan St. The entrance to the Caktus Tech Space is on Morris St. Bring your laptop. -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 -------------- next part -------------- There's another great project night tonight at the ever gracious Caktus in Durham. [1]http://tripython.org/Members/markdlavin/sept-17-dpn When: Monday, September 18, 6-9pm Where: Caktus Group Tech Space 108 Morris St Durham What: Have a project you want to show off, share, seek help with, or just get some work done surrounded by like-minded Python lovers? Join us for our monthly project night and do just that! Don't have something to work on? Just need some help with Python? Show up and enjoy the energy, sprint on an open source project, find something interesting to contribute to or be inspired! The setting is informal and there is no schedule, so don't worry if you show up past the start time. Whether you are a Python newbie needing help or have an open source project you want to share, come hang out and hack. Park in the municipal deck on the other side of the Arts Council across W. Morgan St. The entrance to the Caktus Tech Space is on Morris St. Bring your laptop. -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 References Visible links 1. http://tripython.org/Members/markdlavin/sept-17-dpn From cbc at unc.edu Wed Sep 27 09:50:00 2017 From: cbc at unc.edu (Calloway, Chris) Date: Wed, 27 Sep 2017 13:50:00 +0000 Subject: [TriPython] Reminder: TriPython September 2017 Meeting: PyParsing: How To Process Text If You Hate Regular Expressions Message-ID: <86C4BFE0-B430-4188-9E52-DE493229312B@unc.edu> We have a big meeting with many people signed up for tomorrow at Caktus to hear Brian Fannin. I hope to see you there. http://tripython.org/Members/cbc/sept-17-mtg/ When: Thursday, September 28, 7pm Where: Caktus Group 108 Morris St. Durham What: Brian Fannin will speak and describes his talk as, "Like any person of sound mind, I hate using regular expressions. While writing an expression parser, I discovered the PyParsing library and was immediately in love. I'll walk through some examples of how you can use PyParsing to tame your text data. You may never use regex again!" Brian is the founder and captain of PirateGrunt LLC, a predictive modeling, training and software consultancy with a focus on the insurance industry. He has been an actuary for over twenty years and has worked in a number of roles all over the world. He loves data, data visualization, data architecture, data munging, data modeling, data analysis, data and also data. Extemporaneous "lightning talks" of 5-10 minute duration are also welcome and don't need to be pre-announced. Park in the municipal deck on the other side of the Arts Council across W. Morgan St. The meeting will be followed by our usual after-meeting at a nearby tavern for food and beverage. Come join us for a fun and informative evening. -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 -------------- next part -------------- We have a big meeting with many people signed up for tomorrow at Caktus to hear Brian Fannin. I hope to see you there. http://tripython.org/Members/cbc/sept-17-mtg/ When: Thursday, September 28, 7pm Where: Caktus Group 108 Morris St. Durham What: Brian Fannin will speak and describes his talk as, "Like any person of sound mind, I hate using regular expressions. While writing an expression parser, I discovered the PyParsing library and was immediately in love. I'll walk through some examples of how you can use PyParsing to tame your text data. You may never use regex again!" Brian is the founder and captain of PirateGrunt LLC, a predictive modeling, training and software consultancy with a focus on the insurance industry. He has been an actuary for over twenty years and has worked in a number of roles all over the world. He loves data, data visualization, data architecture, data munging, data modeling, data analysis, data and also data. Extemporaneous "lightning talks" of 5-10 minute duration are also welcome and don't need to be pre-announced. Park in the municipal deck on the other side of the Arts Council across W. Morgan St. The meeting will be followed by our usual after-meeting at a nearby tavern for food and beverage. Come join us for a fun and informative evening. -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 From cbc at unc.edu Wed Sep 27 09:46:04 2017 From: cbc at unc.edu (Calloway, Chris) Date: Wed, 27 Sep 2017 13:46:04 +0000 Subject: [TriPython] October Raleigh Project Night Cancellation and Request Message-ID: <5B564CE5-7F58-4472-BC1D-F8ED3C825AD1@unc.edu> TriPythonistas, I regret to inform you that due to circumstances beyond our control, the location at which we normally hold Raleigh Project Night will not be available in October. Therefore, October Raleigh Project Night has been pre-emptively cancelled. I am given to presume Raleigh Project Night will resume at WebAssign in November. However, if you have a venue under your control you?d like to volunteer for October Raleigh Project Night on Tuesday, October 3 from 6pm to 9pm, especially a venue close to NCSU or downtown, I?d be all ears. We simply need a place with seating at tables, power outlets, and accessible wifi. A laptop projector connection is preferred to be available just in case but not required for a project night. -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 -------------- next part -------------- TriPythonistas, I regret to inform you that due to circumstances beyond our control, the location at which we normally hold Raleigh Project Night will not be available in October. Therefore, October Raleigh Project Night has been pre-emptively cancelled. I am given to presume Raleigh Project Night will resume at WebAssign in November. However, if you have a venue under your control you'd like to volunteer for October Raleigh Project Night on Tuesday, October 3 from 6pm to 9pm, especially a venue close to NCSU or downtown, I'd be all ears. We simply need a place with seating at tables, power outlets, and accessible wifi. A laptop projector connection is preferred to be available just in case but not required for a project night. -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 From willbeeler.marketing at gmail.com Wed Sep 27 13:24:29 2017 From: willbeeler.marketing at gmail.com (William Beeler) Date: Wed, 27 Sep 2017 13:24:29 -0400 Subject: [TriPython] Reminder: TriPython September 2017 Meeting: PyParsing: How To Process Text If You Hate Regular Expressions In-Reply-To: <86C4BFE0-B430-4188-9E52-DE493229312B@unc.edu> References: <86C4BFE0-B430-4188-9E52-DE493229312B@unc.edu> Message-ID: <4EA2ECAE-51B5-437C-B9AC-83D665911078@gmail.com> Hi Chris, I?ve really appreciated getting these emails. Thank you for sending them. Unfortunately, I?m trying to consolidate my email at this email address, and it appears that I?m going in an entirely different direction with things in my life. Python doesn?t seem to be in my future. Could I kindly be taken off the the list? By the way, how are things going? How are things at RENCI? Thanks! Regards, Will Beeler > On Sep 27, 2017, at 9:50 AM, Calloway, Chris wrote: > > We have a big meeting with many people signed up for tomorrow at Caktus to > hear Brian Fannin. I hope to see you there. > > > > http://tripython.org/Members/cbc/sept-17-mtg/ > > > > When: Thursday, September 28, 7pm > > Where: Caktus Group > > 108 Morris St. > > Durham > > What: Brian Fannin will speak and describes his talk as, "Like any person > of sound mind, I hate using regular expressions. While writing an > expression parser, I discovered the PyParsing library and was immediately > in love. I'll walk through some examples of how you can use PyParsing to > tame your text data. You may never use regex again!" Brian is the founder > and captain of PirateGrunt LLC, a predictive modeling, training and > software consultancy with a focus on the insurance industry. He has been > an actuary for over twenty years and has worked in a number of roles all > over the world. He loves data, data visualization, data architecture, data > munging, data modeling, data analysis, data and also data. Extemporaneous > "lightning talks" of 5-10 minute duration are also welcome and don't need > to be pre-announced. Park in the municipal deck on the other side of the > Arts Council across W. Morgan St. The meeting will be followed by our > usual after-meeting at a nearby tavern for food and beverage. Come join us > for a fun and informative evening. > > > > -- > > Sincerely, > > > > Chris Calloway > > Applications Analyst > > University of North Carolina > > Renaissance Computing Institute > > (919) 599-3530 > > > _______________________________________________ > TriZPUG mailing list > TriZPUG at python.org > https://mail.python.org/mailman/listinfo/trizpug > http://tripython.org is the Triangle Python Users Group From cbc at unc.edu Wed Sep 27 16:15:42 2017 From: cbc at unc.edu (Calloway, Chris) Date: Wed, 27 Sep 2017 20:15:42 +0000 Subject: [TriPython] Anaconda and Microsoft Partner to Deliver Python-Powered Machine Learning Message-ID: <90DBD956-F496-46B6-B6D7-5AE680ADE655@unc.edu> https://www.datanami.com/this-just-in/anaconda-microsoft-partner-deliver-python-powered-machine-learning/ -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 -------------- next part -------------- https://www.datanami.com/this-just-in/anaconda-microsoft-partner-deliver-python-powered-machine-learning/ -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 From captain at pirategrunt.com Thu Sep 28 22:08:45 2017 From: captain at pirategrunt.com (Brian Fannin) Date: Thu, 28 Sep 2017 22:08:45 -0400 Subject: [TriPython] PyParsing Message-ID: <46f33086-67f2-ff38-c9ee-ede4a73be5c3@pirategrunt.com> Thanks so much to all who came out to hear my talk about PyParsing tonight. Here's the link to the GitHub repo with the Jupyter notebook: https://github.com/PirateGrunt/pyparsing. Happy to hear any thoughts or suggestions. -Brian From jefferson.r.heard at gmail.com Fri Sep 29 08:09:08 2017 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Fri, 29 Sep 2017 08:09:08 -0400 Subject: [TriPython] PyParsing In-Reply-To: References: <46f33086-67f2-ff38-c9ee-ede4a73be5c3@pirategrunt.com> Message-ID: Here's the documentation on plotting I mentioned: https://seaborn.pydata.org/tutorial/distributions.html Seaborn is still matplotlib, but it's a higher level, well styled wrapper on top of matplotlib. On Sep 28, 2017 22:12, "Brian Fannin" wrote: Thanks so much to all who came out to hear my talk about PyParsing tonight. Here's the link to the GitHub repo with the Jupyter notebook: https://github.com/PirateGrunt/pyparsing. Happy to hear any thoughts or suggestions. -Brian _______________________________________________ TriZPUG mailing list TriZPUG at python.org https://mail.python.org/mailman/listinfo/trizpug http://tripython.org is the Triangle Python Users Group -------------- next part -------------- Here's the documentation on plotting I mentioned:**[1]https://seaborn.pydata.org/tutorial/distributions.html Seaborn is still matplotlib, but it's a higher level, well styled wrapper on top of matplotlib. On Sep 28, 2017 22:12, "Brian Fannin" <[2]captain at pirategrunt.com> wrote: Thanks so much to all who came out to hear my talk about PyParsing tonight. Here's the link to the GitHub repo with the Jupyter notebook: [3]https://github.com/PirateGrunt/pyparsing. Happy to hear any thoughts or suggestions. -Brian _______________________________________________ TriZPUG mailing list [4]TriZPUG at python.org [5]https://mail.python.org/mailman/listinfo/trizpug [6]http://tripython.org is the Triangle Python Users Group References Visible links 1. https://seaborn.pydata.org/tutorial/distributions.html 2. mailto:captain at pirategrunt.com 3. https://github.com/PirateGrunt/pyparsing 4. mailto:TriZPUG at python.org 5. https://mail.python.org/mailman/listinfo/trizpug 6. http://tripython.org/ From trawick at gmail.com Fri Sep 29 09:41:50 2017 From: trawick at gmail.com (Jeff Trawick) Date: Fri, 29 Sep 2017 09:41:50 -0400 Subject: [TriPython] PyParsing In-Reply-To: <46f33086-67f2-ff38-c9ee-ede4a73be5c3@pirategrunt.com> References: <46f33086-67f2-ff38-c9ee-ede4a73be5c3@pirategrunt.com> Message-ID: On Thu, Sep 28, 2017 at 10:08 PM, Brian Fannin wrote: > Thanks so much to all who came out to hear my talk about PyParsing > tonight. Here's the link to the GitHub repo with the Jupyter notebook: > https://github.com/PirateGrunt/pyparsing. Happy to hear any thoughts or > suggestions. > Thanks for sharing! I wanted to go, but "life". (Generally, thanks speakers and Chris and other helpers for getting presentations posted.) > > -Brian > _______________________________________________ > TriZPUG mailing list > TriZPUG at python.org > https://mail.python.org/mailman/listinfo/trizpug > http://tripython.org is the Triangle Python Users Group > -- Born in Roswell... married an alien... http://emptyhammock.com/ -------------- next part -------------- On Thu, Sep 28, 2017 at 10:08 PM, Brian Fannin <[1]captain at pirategrunt.com> wrote: Thanks so much to all who came out to hear my talk about PyParsing tonight. Here's the link to the GitHub repo with the Jupyter notebook: [2]https://github.com/PirateGrunt/pyparsing. Happy to hear any thoughts or suggestions. Thanks for sharing!** I wanted to go, but "life".** (Generally, thanks speakers and Chris and other helpers for getting presentations posted.) ** -Brian _______________________________________________ TriZPUG mailing list [3]TriZPUG at python.org [4]https://mail.python.org/mailman/listinfo/trizpug [5]http://tripython.org is the Triangle Python Users Group -- Born in Roswell... married an alien... [6]http://emptyhammock.com/ References Visible links 1. mailto:captain at pirategrunt.com 2. https://github.com/PirateGrunt/pyparsing 3. mailto:TriZPUG at python.org 4. https://mail.python.org/mailman/listinfo/trizpug 5. http://tripython.org/ 6. http://emptyhammock.com/ From betsy at python.org Thu Sep 28 18:58:41 2017 From: betsy at python.org (Betsy Waliszewski) Date: Thu, 28 Sep 2017 15:58:41 -0700 Subject: [TriPython] PyCon 2018 CFP is Open! Message-ID: Hi, Woohoo! The PyCon 2018 CFP is open! Here is a link to all the information: https://us.pycon.org/2018/speaking/ - Tutorial proposals ? deadline is 24 November 2017 AoE. - Talk, Poster, and Education Summit proposals ? deadline is 3 January 2018 AoE. If you know of a company who might be interested in sponsoring, feel free to share our prospectus: https://us.pycon.org/2018/sponsors/prospectus/. Or an email intro to me would be wonderful, too. Cheers, Betsy -------------- next part -------------- Hi, Woohoo! The**PyCon 2018 CFP is open! Here is a link to all the information:**[1]https://us.pycon.org/2018/speaking/ * Tutorial proposals *** deadline is 24 November 2017 AoE. * Talk, Poster, and Education Summit proposals *** deadline is 3 January 2018 AoE. If you know of a company who might be interested in sponsoring, feel free to share our prospectus:**[2]https://us.pycon.org/2018/sponsors/prospectus/. Or an email intro to me would be wonderful, too. Cheers, Betsy References Visible links 1. https://us.pycon.org/2018/speaking/ 2. https://us.pycon.org/2018/sponsors/prospectus/ From cbc at unc.edu Fri Sep 29 11:22:41 2017 From: cbc at unc.edu (Calloway, Chris) Date: Fri, 29 Sep 2017 15:22:41 +0000 Subject: [TriPython] PyParsing In-Reply-To: <46f33086-67f2-ff38-c9ee-ede4a73be5c3@pirategrunt.com> References: <46f33086-67f2-ff38-c9ee-ede4a73be5c3@pirategrunt.com> Message-ID: <507F20A2-027E-4E46-993E-3E02557200D8@unc.edu> Brian, thank you so much for a great talk and food for thought. There were many compliment on your presentation at the after-meeting. Your notebook repo has been linked on the TriPython meetings page: http://tripython.org/meetings/ Also, thanks for Caktus for the great space and snacks. Thanks for Eric Leary for the video wrangling. And thanks to our lightning talkers. As mentioned at the meeting, the October featured speaker meeting will have to be moved from the usual fourth Thursday just for October only. I?ll send announcements when we know more. Also, remember that there is no Raleigh Project Night for October unless we get a temporary venue. The next project night will be Chapel Hill Project Night on October 11. Raleigh Project Night is expected to resume in November at WebAssign. -- Sincerely, Chris Calloway Applications Analyst University of North Carolina Renaissance Computing Institute (919) 599-3530 On 9/28/17, 10:08 PM, "TriZPUG on behalf of Brian Fannin" wrote: Thanks so much to all who came out to hear my talk about PyParsing tonight. Here's the link to the GitHub repo with the Jupyter notebook: https://github.com/PirateGrunt/pyparsing. Happy to hear any thoughts or suggestions. -Brian _______________________________________________ TriZPUG mailing list TriZPUG at python.org https://mail.python.org/mailman/listinfo/trizpug http://tripython.org is the Triangle Python Users Group From jeremy at fastmail.com Fri Sep 29 21:14:12 2017 From: jeremy at fastmail.com (Jeremy Freeman) Date: Fri, 29 Sep 2017 21:14:12 -0400 Subject: [TriPython] PyParsing In-Reply-To: <507F20A2-027E-4E46-993E-3E02557200D8@unc.edu> References: <46f33086-67f2-ff38-c9ee-ede4a73be5c3@pirategrunt.com> <507F20A2-027E-4E46-993E-3E02557200D8@unc.edu> Message-ID: <0FCBD2F4-2E94-42F1-B81B-5D366169DA78@fastmail.com> Chris/Brian, Sorry to miss the talk. I was a CityCamp. Can you post a link to the video to the list when it is up? -- Jeremy > On Sep 29, 2017, at 11:22 AM, Calloway, Chris wrote: > > Brian, thank you so much for a great talk and food for thought. There were many compliment on your presentation at the after-meeting. Your notebook repo has been linked on the TriPython meetings page: http://tripython.org/meetings/ > > Also, thanks for Caktus for the great space and snacks. Thanks for Eric Leary for the video wrangling. And thanks to our lightning talkers. > > As mentioned at the meeting, the October featured speaker meeting will have to be moved from the usual fourth Thursday just for October only. I?ll send announcements when we know more. > > Also, remember that there is no Raleigh Project Night for October unless we get a temporary venue. The next project night will be Chapel Hill Project Night on October 11. Raleigh Project Night is expected to resume in November at WebAssign. > > -- > Sincerely, > > Chris Calloway > Applications Analyst > University of North Carolina > Renaissance Computing Institute > (919) 599-3530 > > > On 9/28/17, 10:08 PM, "TriZPUG on behalf of Brian Fannin" wrote: > > Thanks so much to all who came out to hear my talk about PyParsing > tonight. Here's the link to the GitHub repo with the Jupyter notebook: > https://github.com/PirateGrunt/pyparsing. Happy to hear any thoughts or > suggestions. > > -Brian > _______________________________________________ > TriZPUG mailing list > TriZPUG at python.org > https://mail.python.org/mailman/listinfo/trizpug > http://tripython.org is the Triangle Python Users Group > > > _______________________________________________ > TriZPUG mailing list > TriZPUG at python.org > https://mail.python.org/mailman/listinfo/trizpug > http://tripython.org is the Triangle Python Users Group