pyparsing: problem matching one of the words (CaselessLiteral) of a given list
I am writing a parser with pyparsing for a particular file structure. It's mainly a list of element definitions with the syntax: ElementName: ElementType, ParameterList. The ParameterList is optional and has the structure of a pp.delimitedList. An example excerpt of this file follows:
"L_000333": DRIF,L=0.0607
BPM15FL2EXTR: MONI
Q8FL2EXTR: QUAD, &
L=0.3286,K1=-0.7494081,&
DY="vert_offset_1"
"L_000334": DRIF,L=0.359694
D8FL2EXTR: CSRCSBEN,L=0.2200112619037261, &
ANGLE=-0.015708,E1=-0.007854, E2=-0.007854, &
SG_HALFWIDTH = 1, DY = "vert_offset_1", &
N_KICKS = "num_CSR_kicks", BINS = "bin_num", &
ISR = "with_ISR", CSR = "with_CSR", &
OUTPUT_INTERVAL = "output_interval", &
INTEGRATION_ORDER = "order_integration"
"L_000335": DRIF,L=0.134994
V9FL2EXTR: VKICK,L=0.1
...
To match the ElementType I want to use a list of given options, because there's a particular type called LINE, which does not match the same structure definition as the ones given in the example just above this lines. For instance, the type LINE follows the syntax:
FL2EXTR: LINE=(STARTFLEXTR,L_000297,FSHUTTER, ... etc... )
and it can be found in between of the elements given above. But by now, I'll forget about how to parse this particular type of element, because the problems come before :-/.
To achieve the proper parsing of a given list of elements, I defined the following building blocks:
import pyparsing as pp
# allowed delimiters:
lte_delim_0 = pp.Literal(',')
lte_delim_1 = pp.Literal('&')
lte_delim_2 = pp.Literal(',') + lte_delim_1
lte_delim = pp.Or([lte_delim_0, lte_delim_1, lte_delim_2])
# ElementName:
elementName = pp.Or([pp.Word(pp.alphanums + '_'), pp.dblQuotedString]) +
pp.Literal(':').suppress()
# ElementType:
elementType = pp.Or([pp.CaselessLiteral('DRIF'),
pp.CaselessLiteral('ALPH'),
pp.CaselessLiteral('BGGEXP'),
pp.CaselessLiteral('BMAPXY'),
pp.CaselessLiteral('BMXYZ'),
... looong list of possible ElementType ...
pp.CaselessLiteral('ZTRANSVERSE')])
# ParameterName and ParameterValue for the ParameterList:
parameterName = pp.Word(pp.alphanums + '_')
parameterValue = pp.Or([pp.Word(pp.alphanums + '_'),
pp.pyparsing_common.number,
pp.dblQuotedString])
# basic assignment definition:
assignmentExpr = pp.Group(parameterName('ParameterName') +
pp.Literal('=').suppress() +
parameterValue('ParameterValue'))
parameterList = pp.Dict(pp.delimitedList(assignmentExpr,
delim = lte_delim, combine = False))
# element definition
elementDefinition = pp.Group(elementName('ElementName') +
elementType('ElementType') +
pp.Optional(lte_delim.suppress() +
parameterList('ParameterList')))
Then I just create a parser for an element list as:
elementList = pp.OneOrMore(ElementDefinition)
However, when I parse the example list given above, the parser stops parsing when it encounters the element CSRCSBEN (even if it is defined in the elementType list of possible pp.CaselessLiterals!!!).
If instead of defining the elementType parser with the pp.Or([ ... list of pp.CaselessLiterals... ]) as I did above, I define the elementType simply as:
elementType = pp.Word(pp.alphanums + '_')
then I get all the element definitions in the list parsed right. But then, I cannot achieve the particular ElementType 'LINE' from being parsed differently...
Can anybody help me with that? Why is the parser stopping at the element CSRCSBEN even if it is given as a valid ElementType?
Thanks a lot in advance for your help!
Cheers,
Pau
python-3.x parsing pyparsing
add a comment |
I am writing a parser with pyparsing for a particular file structure. It's mainly a list of element definitions with the syntax: ElementName: ElementType, ParameterList. The ParameterList is optional and has the structure of a pp.delimitedList. An example excerpt of this file follows:
"L_000333": DRIF,L=0.0607
BPM15FL2EXTR: MONI
Q8FL2EXTR: QUAD, &
L=0.3286,K1=-0.7494081,&
DY="vert_offset_1"
"L_000334": DRIF,L=0.359694
D8FL2EXTR: CSRCSBEN,L=0.2200112619037261, &
ANGLE=-0.015708,E1=-0.007854, E2=-0.007854, &
SG_HALFWIDTH = 1, DY = "vert_offset_1", &
N_KICKS = "num_CSR_kicks", BINS = "bin_num", &
ISR = "with_ISR", CSR = "with_CSR", &
OUTPUT_INTERVAL = "output_interval", &
INTEGRATION_ORDER = "order_integration"
"L_000335": DRIF,L=0.134994
V9FL2EXTR: VKICK,L=0.1
...
To match the ElementType I want to use a list of given options, because there's a particular type called LINE, which does not match the same structure definition as the ones given in the example just above this lines. For instance, the type LINE follows the syntax:
FL2EXTR: LINE=(STARTFLEXTR,L_000297,FSHUTTER, ... etc... )
and it can be found in between of the elements given above. But by now, I'll forget about how to parse this particular type of element, because the problems come before :-/.
To achieve the proper parsing of a given list of elements, I defined the following building blocks:
import pyparsing as pp
# allowed delimiters:
lte_delim_0 = pp.Literal(',')
lte_delim_1 = pp.Literal('&')
lte_delim_2 = pp.Literal(',') + lte_delim_1
lte_delim = pp.Or([lte_delim_0, lte_delim_1, lte_delim_2])
# ElementName:
elementName = pp.Or([pp.Word(pp.alphanums + '_'), pp.dblQuotedString]) +
pp.Literal(':').suppress()
# ElementType:
elementType = pp.Or([pp.CaselessLiteral('DRIF'),
pp.CaselessLiteral('ALPH'),
pp.CaselessLiteral('BGGEXP'),
pp.CaselessLiteral('BMAPXY'),
pp.CaselessLiteral('BMXYZ'),
... looong list of possible ElementType ...
pp.CaselessLiteral('ZTRANSVERSE')])
# ParameterName and ParameterValue for the ParameterList:
parameterName = pp.Word(pp.alphanums + '_')
parameterValue = pp.Or([pp.Word(pp.alphanums + '_'),
pp.pyparsing_common.number,
pp.dblQuotedString])
# basic assignment definition:
assignmentExpr = pp.Group(parameterName('ParameterName') +
pp.Literal('=').suppress() +
parameterValue('ParameterValue'))
parameterList = pp.Dict(pp.delimitedList(assignmentExpr,
delim = lte_delim, combine = False))
# element definition
elementDefinition = pp.Group(elementName('ElementName') +
elementType('ElementType') +
pp.Optional(lte_delim.suppress() +
parameterList('ParameterList')))
Then I just create a parser for an element list as:
elementList = pp.OneOrMore(ElementDefinition)
However, when I parse the example list given above, the parser stops parsing when it encounters the element CSRCSBEN (even if it is defined in the elementType list of possible pp.CaselessLiterals!!!).
If instead of defining the elementType parser with the pp.Or([ ... list of pp.CaselessLiterals... ]) as I did above, I define the elementType simply as:
elementType = pp.Word(pp.alphanums + '_')
then I get all the element definitions in the list parsed right. But then, I cannot achieve the particular ElementType 'LINE' from being parsed differently...
Can anybody help me with that? Why is the parser stopping at the element CSRCSBEN even if it is given as a valid ElementType?
Thanks a lot in advance for your help!
Cheers,
Pau
python-3.x parsing pyparsing
The question could be posed differently: how can I match a list of elementDefinitions if and only if the parameterType of any of the elements is found in a given list of possible element types?
– Pau Gonzalez
Nov 22 '18 at 15:28
1
If I add your missing element types of MONI, QUAD, etc. and CSRCSBEN, I am able to parse your entire sample text. You might consider using a MatchFirst of CaselessKeywords instead of an Or of CaselessLiterals - this will make your later work with LIST easier.
– PaulMcG
Nov 22 '18 at 19:15
Hi @PaulMcG, thanks a lot for your super fast answer! Since you said that the code should work, I was trying "random" things with the sample text. I don't know why, when I deleted the CSRCSBEND keyword and typed it again, the parser started getting it right... Any idea which reason could hide behind that? Maybe some 't' or another "hidden" special character that could lead the parser to malfunction? I have no clue... In any case, after manually re-typing the sample text, the code works! Thanks for the tip with MatchFirst an CaselessKeyword (already implemented). Cheers, Pau
– Pau Gonzalez
Nov 22 '18 at 20:31
add a comment |
I am writing a parser with pyparsing for a particular file structure. It's mainly a list of element definitions with the syntax: ElementName: ElementType, ParameterList. The ParameterList is optional and has the structure of a pp.delimitedList. An example excerpt of this file follows:
"L_000333": DRIF,L=0.0607
BPM15FL2EXTR: MONI
Q8FL2EXTR: QUAD, &
L=0.3286,K1=-0.7494081,&
DY="vert_offset_1"
"L_000334": DRIF,L=0.359694
D8FL2EXTR: CSRCSBEN,L=0.2200112619037261, &
ANGLE=-0.015708,E1=-0.007854, E2=-0.007854, &
SG_HALFWIDTH = 1, DY = "vert_offset_1", &
N_KICKS = "num_CSR_kicks", BINS = "bin_num", &
ISR = "with_ISR", CSR = "with_CSR", &
OUTPUT_INTERVAL = "output_interval", &
INTEGRATION_ORDER = "order_integration"
"L_000335": DRIF,L=0.134994
V9FL2EXTR: VKICK,L=0.1
...
To match the ElementType I want to use a list of given options, because there's a particular type called LINE, which does not match the same structure definition as the ones given in the example just above this lines. For instance, the type LINE follows the syntax:
FL2EXTR: LINE=(STARTFLEXTR,L_000297,FSHUTTER, ... etc... )
and it can be found in between of the elements given above. But by now, I'll forget about how to parse this particular type of element, because the problems come before :-/.
To achieve the proper parsing of a given list of elements, I defined the following building blocks:
import pyparsing as pp
# allowed delimiters:
lte_delim_0 = pp.Literal(',')
lte_delim_1 = pp.Literal('&')
lte_delim_2 = pp.Literal(',') + lte_delim_1
lte_delim = pp.Or([lte_delim_0, lte_delim_1, lte_delim_2])
# ElementName:
elementName = pp.Or([pp.Word(pp.alphanums + '_'), pp.dblQuotedString]) +
pp.Literal(':').suppress()
# ElementType:
elementType = pp.Or([pp.CaselessLiteral('DRIF'),
pp.CaselessLiteral('ALPH'),
pp.CaselessLiteral('BGGEXP'),
pp.CaselessLiteral('BMAPXY'),
pp.CaselessLiteral('BMXYZ'),
... looong list of possible ElementType ...
pp.CaselessLiteral('ZTRANSVERSE')])
# ParameterName and ParameterValue for the ParameterList:
parameterName = pp.Word(pp.alphanums + '_')
parameterValue = pp.Or([pp.Word(pp.alphanums + '_'),
pp.pyparsing_common.number,
pp.dblQuotedString])
# basic assignment definition:
assignmentExpr = pp.Group(parameterName('ParameterName') +
pp.Literal('=').suppress() +
parameterValue('ParameterValue'))
parameterList = pp.Dict(pp.delimitedList(assignmentExpr,
delim = lte_delim, combine = False))
# element definition
elementDefinition = pp.Group(elementName('ElementName') +
elementType('ElementType') +
pp.Optional(lte_delim.suppress() +
parameterList('ParameterList')))
Then I just create a parser for an element list as:
elementList = pp.OneOrMore(ElementDefinition)
However, when I parse the example list given above, the parser stops parsing when it encounters the element CSRCSBEN (even if it is defined in the elementType list of possible pp.CaselessLiterals!!!).
If instead of defining the elementType parser with the pp.Or([ ... list of pp.CaselessLiterals... ]) as I did above, I define the elementType simply as:
elementType = pp.Word(pp.alphanums + '_')
then I get all the element definitions in the list parsed right. But then, I cannot achieve the particular ElementType 'LINE' from being parsed differently...
Can anybody help me with that? Why is the parser stopping at the element CSRCSBEN even if it is given as a valid ElementType?
Thanks a lot in advance for your help!
Cheers,
Pau
python-3.x parsing pyparsing
I am writing a parser with pyparsing for a particular file structure. It's mainly a list of element definitions with the syntax: ElementName: ElementType, ParameterList. The ParameterList is optional and has the structure of a pp.delimitedList. An example excerpt of this file follows:
"L_000333": DRIF,L=0.0607
BPM15FL2EXTR: MONI
Q8FL2EXTR: QUAD, &
L=0.3286,K1=-0.7494081,&
DY="vert_offset_1"
"L_000334": DRIF,L=0.359694
D8FL2EXTR: CSRCSBEN,L=0.2200112619037261, &
ANGLE=-0.015708,E1=-0.007854, E2=-0.007854, &
SG_HALFWIDTH = 1, DY = "vert_offset_1", &
N_KICKS = "num_CSR_kicks", BINS = "bin_num", &
ISR = "with_ISR", CSR = "with_CSR", &
OUTPUT_INTERVAL = "output_interval", &
INTEGRATION_ORDER = "order_integration"
"L_000335": DRIF,L=0.134994
V9FL2EXTR: VKICK,L=0.1
...
To match the ElementType I want to use a list of given options, because there's a particular type called LINE, which does not match the same structure definition as the ones given in the example just above this lines. For instance, the type LINE follows the syntax:
FL2EXTR: LINE=(STARTFLEXTR,L_000297,FSHUTTER, ... etc... )
and it can be found in between of the elements given above. But by now, I'll forget about how to parse this particular type of element, because the problems come before :-/.
To achieve the proper parsing of a given list of elements, I defined the following building blocks:
import pyparsing as pp
# allowed delimiters:
lte_delim_0 = pp.Literal(',')
lte_delim_1 = pp.Literal('&')
lte_delim_2 = pp.Literal(',') + lte_delim_1
lte_delim = pp.Or([lte_delim_0, lte_delim_1, lte_delim_2])
# ElementName:
elementName = pp.Or([pp.Word(pp.alphanums + '_'), pp.dblQuotedString]) +
pp.Literal(':').suppress()
# ElementType:
elementType = pp.Or([pp.CaselessLiteral('DRIF'),
pp.CaselessLiteral('ALPH'),
pp.CaselessLiteral('BGGEXP'),
pp.CaselessLiteral('BMAPXY'),
pp.CaselessLiteral('BMXYZ'),
... looong list of possible ElementType ...
pp.CaselessLiteral('ZTRANSVERSE')])
# ParameterName and ParameterValue for the ParameterList:
parameterName = pp.Word(pp.alphanums + '_')
parameterValue = pp.Or([pp.Word(pp.alphanums + '_'),
pp.pyparsing_common.number,
pp.dblQuotedString])
# basic assignment definition:
assignmentExpr = pp.Group(parameterName('ParameterName') +
pp.Literal('=').suppress() +
parameterValue('ParameterValue'))
parameterList = pp.Dict(pp.delimitedList(assignmentExpr,
delim = lte_delim, combine = False))
# element definition
elementDefinition = pp.Group(elementName('ElementName') +
elementType('ElementType') +
pp.Optional(lte_delim.suppress() +
parameterList('ParameterList')))
Then I just create a parser for an element list as:
elementList = pp.OneOrMore(ElementDefinition)
However, when I parse the example list given above, the parser stops parsing when it encounters the element CSRCSBEN (even if it is defined in the elementType list of possible pp.CaselessLiterals!!!).
If instead of defining the elementType parser with the pp.Or([ ... list of pp.CaselessLiterals... ]) as I did above, I define the elementType simply as:
elementType = pp.Word(pp.alphanums + '_')
then I get all the element definitions in the list parsed right. But then, I cannot achieve the particular ElementType 'LINE' from being parsed differently...
Can anybody help me with that? Why is the parser stopping at the element CSRCSBEN even if it is given as a valid ElementType?
Thanks a lot in advance for your help!
Cheers,
Pau
python-3.x parsing pyparsing
python-3.x parsing pyparsing
asked Nov 22 '18 at 14:55
Pau GonzalezPau Gonzalez
212
212
The question could be posed differently: how can I match a list of elementDefinitions if and only if the parameterType of any of the elements is found in a given list of possible element types?
– Pau Gonzalez
Nov 22 '18 at 15:28
1
If I add your missing element types of MONI, QUAD, etc. and CSRCSBEN, I am able to parse your entire sample text. You might consider using a MatchFirst of CaselessKeywords instead of an Or of CaselessLiterals - this will make your later work with LIST easier.
– PaulMcG
Nov 22 '18 at 19:15
Hi @PaulMcG, thanks a lot for your super fast answer! Since you said that the code should work, I was trying "random" things with the sample text. I don't know why, when I deleted the CSRCSBEND keyword and typed it again, the parser started getting it right... Any idea which reason could hide behind that? Maybe some 't' or another "hidden" special character that could lead the parser to malfunction? I have no clue... In any case, after manually re-typing the sample text, the code works! Thanks for the tip with MatchFirst an CaselessKeyword (already implemented). Cheers, Pau
– Pau Gonzalez
Nov 22 '18 at 20:31
add a comment |
The question could be posed differently: how can I match a list of elementDefinitions if and only if the parameterType of any of the elements is found in a given list of possible element types?
– Pau Gonzalez
Nov 22 '18 at 15:28
1
If I add your missing element types of MONI, QUAD, etc. and CSRCSBEN, I am able to parse your entire sample text. You might consider using a MatchFirst of CaselessKeywords instead of an Or of CaselessLiterals - this will make your later work with LIST easier.
– PaulMcG
Nov 22 '18 at 19:15
Hi @PaulMcG, thanks a lot for your super fast answer! Since you said that the code should work, I was trying "random" things with the sample text. I don't know why, when I deleted the CSRCSBEND keyword and typed it again, the parser started getting it right... Any idea which reason could hide behind that? Maybe some 't' or another "hidden" special character that could lead the parser to malfunction? I have no clue... In any case, after manually re-typing the sample text, the code works! Thanks for the tip with MatchFirst an CaselessKeyword (already implemented). Cheers, Pau
– Pau Gonzalez
Nov 22 '18 at 20:31
The question could be posed differently: how can I match a list of elementDefinitions if and only if the parameterType of any of the elements is found in a given list of possible element types?
– Pau Gonzalez
Nov 22 '18 at 15:28
The question could be posed differently: how can I match a list of elementDefinitions if and only if the parameterType of any of the elements is found in a given list of possible element types?
– Pau Gonzalez
Nov 22 '18 at 15:28
1
1
If I add your missing element types of MONI, QUAD, etc. and CSRCSBEN, I am able to parse your entire sample text. You might consider using a MatchFirst of CaselessKeywords instead of an Or of CaselessLiterals - this will make your later work with LIST easier.
– PaulMcG
Nov 22 '18 at 19:15
If I add your missing element types of MONI, QUAD, etc. and CSRCSBEN, I am able to parse your entire sample text. You might consider using a MatchFirst of CaselessKeywords instead of an Or of CaselessLiterals - this will make your later work with LIST easier.
– PaulMcG
Nov 22 '18 at 19:15
Hi @PaulMcG, thanks a lot for your super fast answer! Since you said that the code should work, I was trying "random" things with the sample text. I don't know why, when I deleted the CSRCSBEND keyword and typed it again, the parser started getting it right... Any idea which reason could hide behind that? Maybe some 't' or another "hidden" special character that could lead the parser to malfunction? I have no clue... In any case, after manually re-typing the sample text, the code works! Thanks for the tip with MatchFirst an CaselessKeyword (already implemented). Cheers, Pau
– Pau Gonzalez
Nov 22 '18 at 20:31
Hi @PaulMcG, thanks a lot for your super fast answer! Since you said that the code should work, I was trying "random" things with the sample text. I don't know why, when I deleted the CSRCSBEND keyword and typed it again, the parser started getting it right... Any idea which reason could hide behind that? Maybe some 't' or another "hidden" special character that could lead the parser to malfunction? I have no clue... In any case, after manually re-typing the sample text, the code works! Thanks for the tip with MatchFirst an CaselessKeyword (already implemented). Cheers, Pau
– Pau Gonzalez
Nov 22 '18 at 20:31
add a comment |
1 Answer
1
active
oldest
votes
Thanks for sharing an interesting problem. Sorry, I don't have a "good" solution for you. (Maybe if you spent a little time boiling it down to a simpler "repeat-by", a simpler grammar that exhibits the same effect?)
I will offer this suggestion. Consider pre-processing so that (A.) continuation lines with '&' become single long lines, and more importantly (B.) each line gets a type prefix, based on presence of a string like 'FL2EXTR' or 'CSRCSBEN'. Call them {TYPE1, TYPE2} or whatever is convenient, and prepend that token to the line.
Now you're faced with a pair of simpler problems, writing a pair of simpler grammars which have fewer details to cope with. The initial type token should make it easier to get just the 1st or 2nd grammar productions to trigger as appropriate.
Hi @J_H, sorry for my vary late answer... Since I already solved the problem after the comment of PaulMcG, I didn't try the approach you suggested. I guess pyparsing overcomes the problem of finding a token in a single line or in multiple lines, so the definition of appropriate delimiters in my script already did its job. But I like your approach of "pre-processing" token results. Actually I will have to deal with setParseAction quite a lot, because the next thing I have to implement in my script is a RPN (reverse polish notation) interpreter... Thanks a lot for your suggestion! :-)
– Pau Gonzalez
Nov 24 '18 at 19:02
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53433577%2fpyparsing-problem-matching-one-of-the-words-caselessliteral-of-a-given-list%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for sharing an interesting problem. Sorry, I don't have a "good" solution for you. (Maybe if you spent a little time boiling it down to a simpler "repeat-by", a simpler grammar that exhibits the same effect?)
I will offer this suggestion. Consider pre-processing so that (A.) continuation lines with '&' become single long lines, and more importantly (B.) each line gets a type prefix, based on presence of a string like 'FL2EXTR' or 'CSRCSBEN'. Call them {TYPE1, TYPE2} or whatever is convenient, and prepend that token to the line.
Now you're faced with a pair of simpler problems, writing a pair of simpler grammars which have fewer details to cope with. The initial type token should make it easier to get just the 1st or 2nd grammar productions to trigger as appropriate.
Hi @J_H, sorry for my vary late answer... Since I already solved the problem after the comment of PaulMcG, I didn't try the approach you suggested. I guess pyparsing overcomes the problem of finding a token in a single line or in multiple lines, so the definition of appropriate delimiters in my script already did its job. But I like your approach of "pre-processing" token results. Actually I will have to deal with setParseAction quite a lot, because the next thing I have to implement in my script is a RPN (reverse polish notation) interpreter... Thanks a lot for your suggestion! :-)
– Pau Gonzalez
Nov 24 '18 at 19:02
add a comment |
Thanks for sharing an interesting problem. Sorry, I don't have a "good" solution for you. (Maybe if you spent a little time boiling it down to a simpler "repeat-by", a simpler grammar that exhibits the same effect?)
I will offer this suggestion. Consider pre-processing so that (A.) continuation lines with '&' become single long lines, and more importantly (B.) each line gets a type prefix, based on presence of a string like 'FL2EXTR' or 'CSRCSBEN'. Call them {TYPE1, TYPE2} or whatever is convenient, and prepend that token to the line.
Now you're faced with a pair of simpler problems, writing a pair of simpler grammars which have fewer details to cope with. The initial type token should make it easier to get just the 1st or 2nd grammar productions to trigger as appropriate.
Hi @J_H, sorry for my vary late answer... Since I already solved the problem after the comment of PaulMcG, I didn't try the approach you suggested. I guess pyparsing overcomes the problem of finding a token in a single line or in multiple lines, so the definition of appropriate delimiters in my script already did its job. But I like your approach of "pre-processing" token results. Actually I will have to deal with setParseAction quite a lot, because the next thing I have to implement in my script is a RPN (reverse polish notation) interpreter... Thanks a lot for your suggestion! :-)
– Pau Gonzalez
Nov 24 '18 at 19:02
add a comment |
Thanks for sharing an interesting problem. Sorry, I don't have a "good" solution for you. (Maybe if you spent a little time boiling it down to a simpler "repeat-by", a simpler grammar that exhibits the same effect?)
I will offer this suggestion. Consider pre-processing so that (A.) continuation lines with '&' become single long lines, and more importantly (B.) each line gets a type prefix, based on presence of a string like 'FL2EXTR' or 'CSRCSBEN'. Call them {TYPE1, TYPE2} or whatever is convenient, and prepend that token to the line.
Now you're faced with a pair of simpler problems, writing a pair of simpler grammars which have fewer details to cope with. The initial type token should make it easier to get just the 1st or 2nd grammar productions to trigger as appropriate.
Thanks for sharing an interesting problem. Sorry, I don't have a "good" solution for you. (Maybe if you spent a little time boiling it down to a simpler "repeat-by", a simpler grammar that exhibits the same effect?)
I will offer this suggestion. Consider pre-processing so that (A.) continuation lines with '&' become single long lines, and more importantly (B.) each line gets a type prefix, based on presence of a string like 'FL2EXTR' or 'CSRCSBEN'. Call them {TYPE1, TYPE2} or whatever is convenient, and prepend that token to the line.
Now you're faced with a pair of simpler problems, writing a pair of simpler grammars which have fewer details to cope with. The initial type token should make it easier to get just the 1st or 2nd grammar productions to trigger as appropriate.
answered Nov 22 '18 at 19:23
J_HJ_H
3,3051617
3,3051617
Hi @J_H, sorry for my vary late answer... Since I already solved the problem after the comment of PaulMcG, I didn't try the approach you suggested. I guess pyparsing overcomes the problem of finding a token in a single line or in multiple lines, so the definition of appropriate delimiters in my script already did its job. But I like your approach of "pre-processing" token results. Actually I will have to deal with setParseAction quite a lot, because the next thing I have to implement in my script is a RPN (reverse polish notation) interpreter... Thanks a lot for your suggestion! :-)
– Pau Gonzalez
Nov 24 '18 at 19:02
add a comment |
Hi @J_H, sorry for my vary late answer... Since I already solved the problem after the comment of PaulMcG, I didn't try the approach you suggested. I guess pyparsing overcomes the problem of finding a token in a single line or in multiple lines, so the definition of appropriate delimiters in my script already did its job. But I like your approach of "pre-processing" token results. Actually I will have to deal with setParseAction quite a lot, because the next thing I have to implement in my script is a RPN (reverse polish notation) interpreter... Thanks a lot for your suggestion! :-)
– Pau Gonzalez
Nov 24 '18 at 19:02
Hi @J_H, sorry for my vary late answer... Since I already solved the problem after the comment of PaulMcG, I didn't try the approach you suggested. I guess pyparsing overcomes the problem of finding a token in a single line or in multiple lines, so the definition of appropriate delimiters in my script already did its job. But I like your approach of "pre-processing" token results. Actually I will have to deal with setParseAction quite a lot, because the next thing I have to implement in my script is a RPN (reverse polish notation) interpreter... Thanks a lot for your suggestion! :-)
– Pau Gonzalez
Nov 24 '18 at 19:02
Hi @J_H, sorry for my vary late answer... Since I already solved the problem after the comment of PaulMcG, I didn't try the approach you suggested. I guess pyparsing overcomes the problem of finding a token in a single line or in multiple lines, so the definition of appropriate delimiters in my script already did its job. But I like your approach of "pre-processing" token results. Actually I will have to deal with setParseAction quite a lot, because the next thing I have to implement in my script is a RPN (reverse polish notation) interpreter... Thanks a lot for your suggestion! :-)
– Pau Gonzalez
Nov 24 '18 at 19:02
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53433577%2fpyparsing-problem-matching-one-of-the-words-caselessliteral-of-a-given-list%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The question could be posed differently: how can I match a list of elementDefinitions if and only if the parameterType of any of the elements is found in a given list of possible element types?
– Pau Gonzalez
Nov 22 '18 at 15:28
1
If I add your missing element types of MONI, QUAD, etc. and CSRCSBEN, I am able to parse your entire sample text. You might consider using a MatchFirst of CaselessKeywords instead of an Or of CaselessLiterals - this will make your later work with LIST easier.
– PaulMcG
Nov 22 '18 at 19:15
Hi @PaulMcG, thanks a lot for your super fast answer! Since you said that the code should work, I was trying "random" things with the sample text. I don't know why, when I deleted the CSRCSBEND keyword and typed it again, the parser started getting it right... Any idea which reason could hide behind that? Maybe some 't' or another "hidden" special character that could lead the parser to malfunction? I have no clue... In any case, after manually re-typing the sample text, the code works! Thanks for the tip with MatchFirst an CaselessKeyword (already implemented). Cheers, Pau
– Pau Gonzalez
Nov 22 '18 at 20:31