Add unit test for #103; also make CHANGES blurb and HowToUse notes a little clearerpyparsing_2.4.2a1pyparsing_2.4.1.1

3 files changed, 32 insertions, 2 deletions

diff --git a/CHANGES b/CHANGES
index db5bd87..235aecc 100644
--- a/CHANGES
+++ b/CHANGES
@@ -11,12 +11,14 @@ for people to give it a try before I can call it ready to go.
 The `expr[...]` notation was pushed out to be synonymous with
 `OneOrMore(expr)`, but this is really counter to most Python
 notations (and even other internal pyparsing notations as well).
+It should have been defined to be equivalent to ZeroOrMore(expr).
 
 It also seems that I introduced a problem by enabling some noisy
 diagnostics, and added a very subtle ParserElement-as-
 unintentional-iterator bug, so 2.4.1 really needs to be unreleased.
 So sorry, everyone!
 
+
 (Updated)
 - A new shorthand notation has been added for repetition
   expressions: expr[min, max], with '...' valid as a min
diff --git a/docs/HowToUsePyparsing.rst b/docs/HowToUsePyparsing.rst
index 3e9e1f8..7d4c061 100644
--- a/docs/HowToUsePyparsing.rst
+++ b/docs/HowToUsePyparsing.rst
@@ -148,9 +148,9 @@ Usage notes
   - ``expr[... ,n]`` is equivalent to ``expr*(0, n)``
     (read as "0 to n instances of expr")
 
-  - ``expr[...]`` is equivalent to ``ZeroOrMore(expr)``
+  - ``expr[...]`` and ``expr[0, ...]`` are equivalent to ``ZeroOrMore(expr)``
 
-  - ``expr[0, ...]`` is equivalent to ``ZeroOrMore(expr)``
+  - ``expr[1, ...]`` is equivalent to ``OneOrMore(expr)``
 
   Note that ``expr[..., n]`` does not raise an exception if
   more than n exprs exist in the input stream; that is,
diff --git a/unitTests.py b/unitTests.py
index 725622d..90e3344 100644
--- a/unitTests.py
+++ b/unitTests.py
@@ -4670,6 +4670,34 @@ class EnableDebugOnNamedExpressionsTest(ParseTestCase):
                           "using enable_debug_on_named_expressions")
 
 
+class UndesirableButCommonPracticesTest(ParseTestCase):
+    def runTest(self):
+        import pyparsing as pp
+        ppc = pp.pyparsing_common
+
+        # While these are valid constructs, and they are not encouraged
+        # there is apparently a lot of code out there using these
+        # coding styles.
+        #
+        # Even though they are not encouraged, we shouldn't break them.
+
+        # Create an And using a list of expressions instead of using '+' operator
+        expr = pp.And([pp.Word('abc'), pp.Word('123')])
+        expr.runTests("""
+            aaa 333
+            b 1
+            ababab 32123
+        """)
+
+        # Passing a single expression to a ParseExpression, when it really wants a sequence
+        expr = pp.Or(pp.Or(ppc.integer))
+        expr.runTests("""
+            123
+            456
+            abc
+        """)
+
+
 class MiscellaneousParserTests(ParseTestCase):
     def runTest(self):