On 2020-02-27, Stefan Ram wrote:
> One can count overlapping occurences as follows.
>
>|>>> print(len(findall('(?=aa)','cb')))
>|3
>
> Every web page says that lookahead assertions do
> not consume nor move the "current positio
Stefan Ram wrote:
One can count overlapping occurences as follows.
|>>> print(len(findall('(?=aa)','cb')))
|3
Every web page says that lookahead assertions do
not consume nor move the "current position".
But what mental model can I make o
On Thursday, September 21, 2017 at 9:29:19 AM UTC-7, Tobiah wrote:
> Are these completely equivalent?
>
> def foo(thing):
>
> assert(thing > 0), "Thing must be greater than zero"
>
>
> def foo(thing):
>
> if not (thing > 0): raise AssertionError("Thing must be greater than
> z
Op 2017-09-22, Thomas Jollans schreef :
> Just to make the implication explicit:
>
from math import nan
nan is nan
> True
nan == nan
> False
nan != nan
> True
To add to the fun:
>>> nan is nan
True
Stephan
--
https://mail.python.org/mailman/listinfo/python-list
On 2017-09-22 14:43, Steve D'Aprano wrote:
> In the case of floating point NANs, they are unordered with respect to all
> numbers. So for any number x, we always have:
>
> NAN == x
> NAN < x
> NAN > x
> NAN <= x
> NAN >= x
>
> all return False, and
>
> NAN != x
>
> return True.
Just to make t
On Fri, 22 Sep 2017 10:03 pm, alister wrote:
> On Fri, 22 Sep 2017 21:15:54 +1000, Steve D'Aprano wrote:
>
>> On Fri, 22 Sep 2017 08:50 pm, alister wrote:
>>
The bottom line is, if I saw
if not (thing > 0): raise AssertionError(...)
in a code review, I'd probably insis
On 2017-09-22 14:03, alister via Python-list wrote:
> On Fri, 22 Sep 2017 21:15:54 +1000, Steve D'Aprano wrote:
>> On Fri, 22 Sep 2017 08:50 pm, alister wrote:
>>> [snip]
>>>
>>> In a code review I would want the condition changed to be less noisy/
>>> confusing to the reader.
>>>
>>> if thing <=0:
On Fri, 22 Sep 2017 21:15:54 +1000, Steve D'Aprano wrote:
> On Fri, 22 Sep 2017 08:50 pm, alister wrote:
>
>>> The bottom line is, if I saw
>>>
>>> if not (thing > 0): raise AssertionError(...)
>>>
>>> in a code review, I'd probably insist that either it be changed to use
>>> `assert`,
>>> or t
On Fri, 22 Sep 2017 08:50 pm, alister wrote:
>> The bottom line is, if I saw
>>
>> if not (thing > 0): raise AssertionError(...)
>>
>> in a code review, I'd probably insist that either it be changed to use
>> `assert`,
>> or the exception be changed to ValueError, whichever better expresses
>> t
e an assertion, because it
> uses the assert keyword!
>
> The second is testing a condition, and if need be, raising an exception.
> Which looks like an inappropriate exception. Why AssertionError? It
> looks like it ought to be a ValueError.
>
> Assertions aren'
On Fri, Sep 22, 2017 at 3:49 AM, Steve D'Aprano
wrote:
> On Fri, 22 Sep 2017 03:31 am, Chris Angelico wrote:
>
>> Impressive. That means that, in 2.7, it's actually equivalent to:
>>
> def test3():
>> ... if not foo: raise AssertionError, "bar baz"
>
> That's nothing. In 1.5 (yes, *one* po
On Fri, 22 Sep 2017 03:31 am, Chris Angelico wrote:
> On Fri, Sep 22, 2017 at 3:23 AM, Steve D'Aprano
> wrote:
>> That is definitely version-dependent, because I've just tried it and got
>> different byte-code in Python 2.7.
>>
>> py> import dis
>> py> def test1():
>> ... assert foo, "bar baz
ers, then I think we should say that the two above are very
different.
The first is an actual assertion. It has to be an assertion, because it uses the
assert keyword!
The second is testing a condition, and if need be, raising an exception. Which
looks like an inappropriate exception. Why Asser
On Fri, Sep 22, 2017 at 3:23 AM, Steve D'Aprano
wrote:
> That is definitely version-dependent, because I've just tried it and got
> different byte-code in Python 2.7.
>
> py> import dis
> py> def test1():
> ... assert foo, "bar baz"
> ...
> py> def test2():
> ... if not foo: raise Assertio
On Fri, 22 Sep 2017 02:59 am, Ned Batchelder wrote:
> On 9/21/17 12:29 PM, Tobiah wrote:
>> Are these completely equivalent?
[... assert, versus test and raise AssertionError ...]
> Let's see:
[...]
> Yes, they are completely equivalent, compiling to precisely the same
> bytecode.
That is defin
On 9/21/17 12:29 PM, Tobiah wrote:
Are these completely equivalent?
def foo(thing):
assert(thing > 0), "Thing must be greater than zero"
def foo(thing):
if not (thing > 0): raise AssertionError("Thing must be greater than
zero")
Other than the fact that the assertion can
Are these completely equivalent?
def foo(thing):
assert(thing > 0), "Thing must be greater than zero"
def foo(thing):
if not (thing > 0): raise AssertionError("Thing must be greater than
zero")
Other than the fact that the assertion can be turned off
with -O?
Thanks,
Tob
On Fri, 07 Mar 2014 16:15:36 -0800, Dan Stromberg wrote:
> On Fri, Mar 7, 2014 at 3:11 AM, Steven D'Aprano
> wrote:
>
>
>> Assertions are not bad! They're just misunderstood and abused.
>
>> You should read this guy's blog post on when to use asser
On 8-3-2014 1:15, Dan Stromberg wrote:
> On Fri, Mar 7, 2014 at 3:11 AM, Steven D'Aprano
> wrote:
>
>>
>> Assertions are not bad! They're just misunderstood and abused.
>
>> You should read this guy's blog post on when to use assert:
>>
>
Dan Stromberg writes:
> BTW, what about:
>
> if value >= 3:
>raise AssertionError('value must be >= 3')
That would be very confusing, since it would only appear when the value
is >= 3. Were you making some other point?
--
\“If this is your first visit to the USSR, you are welcome
On Fri, Mar 7, 2014 at 3:11 AM, Steven D'Aprano
wrote:
>
> Assertions are not bad! They're just misunderstood and abused.
> You should read this guy's blog post on when to use assert:
>
> http://import-that.dreamwidth.org/676.html
Nice article.
BTW, what a
On Fri, Mar 7, 2014 at 10:11 PM, Steven D'Aprano
wrote:
>> http://xkcd.com/1339/
>>
>> Abusing assert for arg checking violates XKCD 1339. Write
>> standards-compliant code!
>
> Assertions are not bad! They're just misunderstood and abused.
>
&g
Write
> standards-compliant code!
Assertions are not bad! They're just misunderstood and abused.
(By the way, assertions are not the same as assumptions. Asserts can be
used to check that assumptions are correct, or to check the internal
logic of your reasoning. Whereas assumptions ar
They produce the wrong exception type, they disappear when you least
expect them, and now we have another reason not to use assert.
http://xkcd.com/1339/
Abusing assert for arg checking violates XKCD 1339. Write
standards-compliant code!
ChrisA
--
https://mail.python.org/mailman/listinfo/python
> Put simply, it doesn't occur often enough to be worth it. The cost
> outweighs the potential benefit.
I don't buy it. You could backtrack instead of failing for \b+ and
\b*, and it would be almost as fast as this optimization.
-- Devin
On Tue, Jan 3, 2012 at 1:57 PM, MRAB wrote:
> On 03/01/20
On 03/01/2012 09:45, Devin Jeanpierre wrote:
\\b\\b and \\b{2} aren't equivalent ?
This sounds suspiciously like a bug!
Why the wording is "should never" ? Repeating a zero-width assertion is not
forbidden, for instance :
import re
re.compile("\\b\\b\w+\\b\\b")
<_sre.SRE_Pattern obje
46 AM, candide wrote:
> The regular expression HOWTO
> (http://docs.python.org/howto/regex.html#more-metacharacters) explains the
> following
>
> # --
> zero-width assertions should never be repeated, because if they match once
> at a given
The regular expression HOWTO
(http://docs.python.org/howto/regex.html#more-metacharacters) explains
the following
# --
zero-width assertions should never be repeated, because if they match
once at a given location, they can obviously be matched an infinite
number
Terry Reedy writes:
> The temptation to write unfactored duplicate code like this is a
> negative of unittest.
I don't see that it's especially attributable to the ‘unittest’ module.
It's a common problem to be solved, and solutions are available.
> The question is whether get_filenames gets th
nerstr)
self.assertEquals(3,len(matching_names))
A side point unrelated to the question: your code will be easier to read
if you follow PEP 8, specifically its recommendations regarding spaces
around syntax (like ‘=’ and ‘,’).
when I run the unittest, if the test fails at the firs
Ben Finney writes:
> Yes, that's by design. Each function in a TestCase subclass is a test
> case […]
Poorly described. Try this instead: Each test case in a TestCase
subclass must be a separate function, whose name starts with ‘test’.
Or you could see what the documentation says; it may descri
mes(self.dirname,innerstr)
> self.assertEquals(3,len(matching_names))
A side point unrelated to the question: your code will be easier to read
if you follow PEP 8, specifically its recommendations regarding spaces
around syntax (like ‘=’ and ‘,’).
> when I run the unittest, if the tes
thanks Peter
that was good advice
jim
On Oct 16, 1:44 pm, Peter Otten <__pete...@web.de> wrote:
> Keep it simple ;)
--
http://mail.python.org/mailman/listinfo/python-list
a'
> when I run the unittest, if the test fails at the first assertion,the
> other assertions are not executed at all..How do I organize the test
> so that all assertions can run?
Keep it simple ;)
def test_get_filenames_single_match(self):
> innerstr='tom&#
'jerry'
matching_names=get_filenames(self.dirname,innerstr)
self.assertEquals(3,len(matching_names))
when I run the unittest, if the test fails at the first assertion,the
other assertions are not executed at all..How do I organize the test
so that all assertions can run?
thank
ote:
I've started on ch 3 of my beginner's intro to programming, now delving
into the details of the Python language.
It's just a few pages yet, file [03 asd.pdf] (no real title yet!) at
http://tinyurl.com/programmingbookP3> which is at Google Docs.
The first topic is about asserti
l.com/programmingbookP3> which is at Google Docs.
>
> The first topic is about assertions and exceptions. I wonder whether this text
> is easy or difficult to understand for a beginner. Or any improvements that
> could be made.
>
> Cheers,
>
> - Alf
The only iss
is at Google Docs.
>
> The first topic is about assertions and exceptions. I wonder whether
> this text is easy or difficult to understand for a beginner. Or any
> improvements that could be made.
>
I don't think it's helpful in Python to refer to "... variables, which
On 2-2-2010 21:54, Alf P. Steinbach wrote:
I've started on ch 3 of my beginner's intro to programming, now delving
into the details of the Python language.
Alf,
I think it's a good read so far. I just don't like the smilies that
occur in the text. It's a book (or article) that I'm reading, no
On Feb 2, 12:54 pm, "Alf P. Steinbach" wrote:
> The first topic is about assertions and exceptions. I wonder whether this text
> is easy or difficult to understand for a beginner. Or any improvements that
> could be made.
To my eyes it reads nicely. You may want to try it out
I've started on ch 3 of my beginner's intro to programming, now delving into the
details of the Python language.
It's just a few pages yet, file [03 asd.pdf] (no real title yet!) at http://tinyurl.com/programmingbookP3> which is at Google Docs.
The first topic is ab
alex23 wrote:
> r0g wrote:
>> Well I think sometimes, for the sake of expediency and overall
>> pleasantness, it's better to let the smaller things go: and if you just
>> can't let them go then at least try and issue corrections in a friendly
>> manner rather than a cold or pious one.
>
> The iro
r0g wrote:
> Well I think sometimes, for the sake of expediency and overall
> pleasantness, it's better to let the smaller things go: and if you just
> can't let them go then at least try and issue corrections in a friendly
> manner rather than a cold or pious one.
The irony, it is too rich...
--
Ben Finney wrote:
> r0g writes:
>
>> Ben Finney wrote:
>>> People sometimes get upset — on an immediate, irrational level —
>>> when their assertions are challenged. There's no denying that
>>> emotions entangle our discourse, and our interpretati
r0g writes:
> Ben Finney wrote:
> > People sometimes get upset — on an immediate, irrational level —
> > when their assertions are challenged. There's no denying that
> > emotions entangle our discourse, and our interpretation of the
> > discourse of others.
&
why the assertion was not true).
>
That's a fair point I had never really considered. I'd wouldn't have
been nearly as upset if you'd started your sentence with AssertionError :)
> People sometimes get upset — on an immediate, irrational level — when
> their ass
t question, but
to an assertion.
Every assertion expressed, though, implies the question “is this
assertion true?”. It was that question that was answered “No” (followed
by an explanation of why the assertion was not true).
People sometimes get upset — on an immediate, irrational level — when
thei
On 11/22/09 16:05, Helmut Jarausch wrote:
On 11/22/09 14:58, Jelle Smet wrote:
Hi List,
I'm trying to match lines in python using the re module.
The end goal is to have a regex which enables me to skip lines which
have ok and warning in it.
But for some reason I can't get negative lookaheads wo
Tim Chase wrote:
import re
line='2009-11-22 12:15:441 lmqkjsfmlqshvquhsudfhqf qlsfh
qsduidfhqlsiufh qlsiuf qldsfhqlsifhqlius dfh warning qlsfj lqshf
lqsuhf lqksjfhqisudfh qiusdfhq iusfh'
re.match('.*(?!warning)',line)
<_sre.SRE_Match object at 0xb75b1598>
I would expect that this would NOT
On 11/22/09 14:58, Jelle Smet wrote:
Hi List,
I'm trying to match lines in python using the re module.
The end goal is to have a regex which enables me to skip lines which have ok
and warning in it.
But for some reason I can't get negative lookaheads working, the way it's explained in
"http://
import re
line='2009-11-22 12:15:441 lmqkjsfmlqshvquhsudfhqf qlsfh qsduidfhqlsiufh
qlsiuf qldsfhqlsifhqlius dfh warning qlsfj lqshf lqsuhf lqksjfhqisudfh qiusdfhq
iusfh'
re.match('.*(?!warning)',line)
<_sre.SRE_Match object at 0xb75b1598>
I would expect that this would NOT match as it's a neg
Hi List,
I'm trying to match lines in python using the re module.
The end goal is to have a regex which enables me to skip lines which have ok
and warning in it.
But for some reason I can't get negative lookaheads working, the way it's
explained in "http://docs.python.org/library/re.html";.
Con
> >> debugging.
>>
>> > If it helps go ahead an use them. The world won't end if you use an
>> > assertion in a less than ideal situation. And, after all, if someone
>> > doesn't like it they can shut them off.
>>
>> Is there any way
them. The world won't end if you use an
> > assertion in a less than ideal situation. And, after all, if someone
> > doesn't like it they can shut them off.
>
> Is there any way to have finer control of assertions than just passing -O
> to the Python interpreter? Suppose I w
And, after all, if someone
> doesn't like it they can shut them off.
Is there any way to have finer control of assertions than just passing -O
to the Python interpreter? Suppose I want to switch them off for certain
modules but not others, am I out of luck?
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
; parameters.
>
> I'm curious how this does or doesn't fit into python's duck-typing
> philosophy.
The duck-typing thing fits into a wider philosophy of being liberal in
what you accept. As you're constraining what a function accepts, it
definitely goes against the
ecent call last):
> File "", line 1, in ?
> ValueError: x must be equal to three but is 1 instead
These are are verbose to the point of silliness, and usually not worth
the effort since assertions are only supposed to check for ostensibly
impossible conditions. Thus it shoul
Matthew Woodcraft <[EMAIL PROTECTED]> wrote:
> I have a question for you. Consider this function:
>
> def f(n):
> """Return the largest natural power of 2 which does not exceed n."""
> if n < 1:
> raise ValueError
> i = 1
> while i <= n:
> j = i
> i
On Fri, 26 Jan 2007 18:28:32 +, Matthew Woodcraft wrote:
> I have a question for you. Consider this function:
>
> def f(n):
> """Return the largest natural power of 2 which does not exceed n."""
> if n < 1:
> raise ValueError
> i = 1
> while i <= n:
> j = i
>
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> The less your function does, the more constrained it is, the less
> testing you have to do -- but the less useful it is, and the more work
> you put onto the users of your function. Instead of saying something
> like
> a = MyNumericClass(1)
> b = MyNum
On Thu, 25 Jan 2007 16:54:05 +, Matthew Wilson wrote:
> Lately, I've been writing functions like this:
>
> def f(a, b):
>
> assert a in [1, 2, 3]
> assert b in [4, 5, 6]
>
> The point is that I'm checking the type and the values of the
> parameters.
If somebody passes in a == MyNum
service, etc.) or is it to
be called only by you in a very controlled fashion ?
In the first case, passing an invalid input is a *user error*, not a
*programming error*. Assertions should be used for programming errors
only to assert invariants, statements which should be correct no matter
what
Lately, I've been writing functions like this:
def f(a, b):
assert a in [1, 2, 3]
assert b in [4, 5, 6]
The point is that I'm checking the type and the values of the
parameters.
I'm curious how this does or doesn't fit into python's duck-typing
philosophy.
I find that when I detect inv
63 matches
Mail list logo
