nstant-folding, and the lack of it, does seem to come
up in users' requests. Whether they *need* constant-folding or not, it
seems that some people have come to expect it. E.g. see this recent
thread on python-list:
http://code.activestate.com/lists/python-list/596506/
class C(object):
def spam():
pass
result = spam()
spam = staticmethod(spam)
Making staticmethod callable would, in my opinion, be the obvious way to
do it.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyt
get similar results regardless of the size of L.
Size of L key/cmp
== =
6 9.4
600 13.9
6 7.0
600 6.7
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
but
time()'s granularity is 1/60th of a second; on Unix,
clock() has 1/100th of a second granularity and time()
is much more precise.
Should timeit be changed, or the docs, or have I missed something?
--
Steven
___
Python-Dev mailing
Tim Delaney wrote:
You'd end up using more horizontal space, but we all seem to have
widescreen monitors these days.
Not even close to "we all".
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
% nearly always requires a list().
YMMV.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Greg Ewing wrote:
Steven D'Aprano wrote:
The main one that comes to my mind is that other than looping, any
time I want to process dict.items() etc I often need to call list()
first.
I don't think that's such a bad thing. It makes it clear that
you're performing a more
Lennart Regebro wrote:
On Tue, Mar 22, 2011 at 22:12, Steven D'Aprano wrote:
The main one that comes to my mind is that other than looping, any time I
want to process dict.items() etc I often need to call list() first.
"Process" no. If you want it to be a list, yes. This is b
On Mon, Feb 21, 2011 at 1:52 PM, Nick Coghlan wrote:
> As the subject line asks, is there anything preventing the following
> PEPs from being marked Final?
>
> SA 389 argparse - New Command Line Parsing Module Bethard
Sorry for taking forever to get back to this. So I looked over
super().method() # or at the end of the overloaded method?
What arguments should be passed? What do you do with the result?
If you can think of a way for Python to automagically tell when to call
super(), what arguments to pass to it, and what to do with the result,
your crysta
I'd rather work around bugs in
third-party classes than try to deal with Python actively subverting the
code I read and write by mysteriously calling superclass methods where
there is no call to a superclass method.
--
Steven
___
Pytho
d.
At the very least, I think you need to explicitly define what you mean
by "100% branch coverage". Possibly this will assist in the disagreement
between you and Antoine re "100% versus "comprehensive" coverage.
--
Steven
_
Michael Foord wrote:
On 15/04/2011 02:23, Steven D'Aprano wrote:
[...]
If we treat django's failure to use super as a bug, you want the
Python language to work-around that bug so that:
What you say (that this particular circumstance could be treated as a
bug in django) is tru
y go to the python-ideas
mailing list for any extended discussion.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
e the side-effect that non-reflexivity will propagate
to containers)
(3) allow types to register that they are non-reflexive, allowing
containers to skip the identity shortcut when necessary.
(but it is not clear to me that the extra complexity will be worth
heck bit patterns. I think it is painful and ironic that a
development system aimed at non-programmers released by a company
notorious for "dumbing down" interfaces over 20 years ago had better and
simpler support for NANs than we have now.
--
Steven
___
False. There's
no need for a NAB comparison flag.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
s they shouldn't rely on it. Identity tests are an implementation
detail. But in any case, reflexivity is *not* a guarantee of Python.
With rich comparisons, you can define __eq__ to do anything you like.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Mark Shannon wrote:
Steven D'Aprano wrote:
Mark Shannon wrote:
Related to the discussion on "Not a Number" can I point out a few
things that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than
types and values so may
does do
a lot of numeric work, and does come across NANs, and still doesn't like
them one bit.)
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
be
considered broken.
Then Python is broken by design, because by design *all* rich comparison
methods can do anything.
On 27/04/2011 15:53, Guido van Rossum wrote:
Maybe we should just call off the odd NaN comparison behavior?
Right on, Guido. (A pity that a lot of people d
ers), and so long as NANs continue to be "badly behaved" in this
sense, then I could live with that. It's really just formalizing the
status quo as deliberate policy rather than an accident:
nan == nan will still return False
[nan] == [nan] will still return True.
Purists on both
Steven D'Aprano wrote:
I know thousands of words have been spilled on this, including many by
myself, but I really believe this discussion is mostly bike-shedding.
Hmmm... on reflection, I think I may have been a bit unfair. In
particular, I don't mean any slight on any of the
rent *documented* behaviour that list equality is based on object
equality, the actual behaviour is surprising, but I don't think there is
anything wrong with the idea of containers assuming that their elements
are reflexive.
--
Steven
_
to fix. If containers
wish to define container equality as taking identity into account, good
for the container. Document it and move on, but please don't touch floats.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
ogrammers using
Hypercard. There's no sign that Apple were wrong to expose NANs and INFs
to users, no flood of Hypercard users confused by NAN inequality.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
Robert Kern wrote:
On 4/28/11 8:44 PM, Steven D'Aprano wrote:
Greg Ewing wrote:
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
The real question should be, why does Python treat all NANs as
signalling NANs
instead of quiet NANs? I
Ben Finney wrote:
Steven D'Aprano writes:
Robert Kern wrote:
On 4/28/11 8:44 PM, Steven D'Aprano wrote:
The real question should be, why does Python treat all NANs as
signalling NANs instead of quiet NANs? I don't believe this helps
anyone.
Actually, Python treats all NaN
x
print local x (1)
If we implemented this change, there would be no more questions about
UnboundLocalError, but instead there would be lots of questions like
"why is it that globals revert to their old value after I change them in
a function?".
--
Steven
__
but what value does it have?
Just thinking about debugging the mess that this could make gives me a
headache.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
entially a
semantic change that will break any code that distinguishes between
(global) NameError and (local) UnboundLocalError. But personally, I
don't know why it was thought necessary to distinguish between them in
the first place.
--
Steven
___
ocument as "potentially" helpful
when a number of people have said that it *actually* did help them.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
value of typecode"
After ~12 years of doing this, it comes naturally. I appreciate that
this may come across as weird though :)
Whereas I read it as 'has the value' (or just 'is' ;=).
Am I the only one who reads == as "equals"?
--
Steven
ttributes, we should qualify the word: data attribute vs method
attribute.
(I'm not suggesting that we should routinely refer to "method attribute"
rather than simply method, but only when we wish to emphasize that
methods are a kind of attribute and not a completely diffe
ta are not" for the sake of it. Leave the
functions-as-data case for a footnote.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ng used in third-party code. It may
even *encourage* it, by making the extra functionality more explicit.
However, is there any reason why test.support itself shouldn't be
renamed test._support, or possibly _test.support, so that the *entire*
suite is marked as a priv
On 5/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> >> One comment I have, I don't know if it's relevant - it perhaps
> >> depends on whether the "Global Module Index" is auto-generated or
> >> not. This is the page I visit the most out of all the Python
> >> documentation,
On 5/23/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Also, try
>
> http://pydoc.gbrandl.de:3000/os.path.exists
Beautiful!
STeVe
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
_
On 6/4/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> The threading module contains buggy code:
>
> class Thread(_Verbose):
> ...
> def start(self):
> assert self.__initialized, "Thread.__init__() not called"
> assert not self.__started, "thread already started"
> ...
On 6/9/07, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> I believe that this should be changed, so that Python first looks for
> the attribute in the instance's dict and only then through the dict's
> mro.
[snip]
> What do you think?
Are you suggesting that the following code should print "43" instead o
> On 6/10/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 6/9/07, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> > > I believe that this should be changed, so that Python first looks for
> > > the attribute in the instance's dict and only then through the
On 7/8/07, Kevin Jacobs <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote:
> Also vaguely apropos:
>
> def ilen(seq):
> 'Return the length of the hopefully finite sequence'
> n = 0
> for x in seq:
> n += 1
> return n
Also known as::
sum(1 for _ in iterable)
That's always been simple
On 7/10/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Please help!
>
> I've made a meta patch that makes debugging the bugs a lot easier. It
> replaces assert_(foo == bar) and failUnless(foo == bar) with
> failUnlessEqual(foo, bar). failUnlessEqual shows the value of
On 9/20/07, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
> On Thursday 30 August 2007 16:28, Alexander Neundorf wrote:
> ...
> > The cmake files for building python are now in a cvs repository:
> > http://www.cmake.org/cgi-bin/viewcvs.cgi/Utilities/CMakeBuildForPython/?roo
> >t=ParaView3
Thanks f
On 9/29/07, Michael Foord <[EMAIL PROTECTED]> wrote:
> Terry Reedy wrote:
> > There are two normal ways for internal Python text to have \r\n:
> > 1. Read from a file with \r\r\n. Then \r\r\n is correct output (on the
> > same platform).
> > 2. Intentially put there by a programmer. If s/he also
On 9/29/07, Michael Foord <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > On 9/29/07, Michael Foord <[EMAIL PROTECTED]> wrote:
> >
> >> Terry Reedy wrote:
> >>
> >>> There are two normal ways for internal Python text to have \r\
On 10/31/07, Fred Drake <[EMAIL PROTECTED]> wrote:
> If I had to choose built-in names, though, I'd prefer "property",
> "propset", "propdel". Another possibility that seems reasonable
> (perhaps a bit better) would be:
>
>class Thing(object):
>
>@property
>def attribute(self):
On Nov 10, 2007 11:31 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Unless I get negative feedback really soon I plan to submit this later
> today. I've tweaked the patch slightly to be smarter about replacing
> the setter and the deleter together if they are the same object.
Definitely +1 on
On Nov 14, 2007 1:18 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Nov 14, 2007 10:30 AM, Isaac Morland <[EMAIL PROTECTED]> wrote:
> > So I wrote a Signature class. Instances of the class represent all the
> > information present between the parentheses of a procedure definition.
> > Properties
On Nov 21, 2007 4:33 PM, Michael Foord <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I'm asking a Py3k question on python-dev because I'd like to have
> > opinions from people who haven't thought about Py3k much yet. Consider
> > the following example:
> >
> > class C:
> > def fo
On Nov 28, 2007 2:23 PM, <[EMAIL PROTECTED]> wrote:
> Sorry if this is a dumb question, but are there actually good reasons to
> remove "types"?
> IMHO the types module helps keeping code readable.
> For example
> "if type(obj) == FloatType"
> is just more readable than
> "if type(obj) == type(1.
On Nov 28, 2007 10:11 PM, Ron Adam <[EMAIL PROTECTED]> wrote:
> Keeping __root__ relatively short has the benefit of being able to easily
> use "__root__.name" in the case where "name" was/is used in the local
> scope. I don't see any reason to make it harder. There might even be a
> use case for
On Nov 30, 2007 4:40 PM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 30, 2007 at 03:05:18PM -0800, Guido van Rossum wrote:
> > On Nov 30, 2007 2:17 PM, Nicko van Someren <[EMAIL PROTECTED]> wrote:
> > > +1 for __universal__
> >
> > It's almost as if nobody has seen my proposal to leave
On Jan 6, 2008 8:33 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> * PJE: Does pkg_resource have an easy way to overwrite a package in a
> name space package? E.g. an user wants to overwrite Python's
> databases.sqlite with a newer version of sqlite. Can he simply do it by
> inserting a package
On Jan 6, 2008 11:34 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > Do we really want to encourage this? Wouldn't that just introduce
> > more pyxml-like nightmares? I've been bitten way too many times by
> > pyxml overwritin
On Jan 6, 2008 1:07 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:03 PM 1/6/2008 -0700, Steven Bethard wrote:
> >Maybe the situation is different here, but having someone installing a
> >different version of sqlite behind my back makes me nervous.
>
> Er, some
On Jan 22, 2008 5:40 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Daniel Stutzbach]
> > There are many places in the C implementation where a slot
> > returns an int rather than a PyObject. There other replies
> > in this thread seem to support altering the signature of the
> > slot to retu
On Jan 25, 2008 9:13 AM, Jameson Chema Quinn <[EMAIL PROTECTED]> wrote:
> I'm writing a source code editor that translates identifiers and keywords
> on-screen into a different natural language. This tool will do no
> transformations except at the reversible word level. There is one simple,
> avoid
On Tue, Mar 4, 2008 at 5:10 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> Christian Heimes wrote:
> > Bob Kline wrote:
> >> Any possibility of revisiting this question (upgrading to a more recent
> >> compiler for Windows builds of Python)?
> >
> > The latest alphas of Python 2.6 and 3.0 are b
On Wed, Mar 19, 2008 at 5:51 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> This flag is exposed to python code as sys.flags.py3k_warning
>
> So the hack added to some of the test code that I saw go by on
> python-checkins isn't needed :)
Excellent. I asked around at the sprints and everyone tho
Right now, test_py3kwarn only runs if the test suite is run using the
-3 command line flag to Python. So for most regrtest runs (e.g. the
buildbots) this test will never be run.
It would be nice to be able to turn the flag on from Python (e.g.
within test_py3kwarn). Is that possible? Here's what
On Sat, Mar 22, 2008 at 2:58 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > Right now, test_py3kwarn only runs if the test suite is run using the
> > -3 command line flag to Python. So for most regrtest runs (e.g. the
> > b
On Sun, Mar 23, 2008 at 3:02 PM, "Martin v. Löwis" wrote:
[talking about running the buildbots using the -3 flag to issue Py3K warnings]
> Yes. I don't think it should be turned on regularly in the tests until
> they regularly are quiet under -3.
So the plan is to silence all Py3K warnings in th
On Tue, Apr 1, 2008 at 12:42 AM, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> The Windows buildbots are still failing because some tests keep files
> opened. This causes subsequent tests which use the same file to fail.
>
> Here is a recent run which had a failure early on:
>
> http://www.python.
On Tue, Apr 1, 2008 at 10:20 AM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
> 2008/4/1, Tim Golden <[EMAIL PROTECTED]>:
> > If this is the thing to do, presumably test_support should
> > grow a "remove_file" which does something of this sort?
>
> +1 (I was thinking exactly that).
+1 here too.
On Thu, Apr 3, 2008 at 3:09 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> "Tim Golden" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> | [re tests which fail because something's holding a file
> | open with SHARE_DELETE]
>
> There are a couple of things one can do in a director
On Wed, Apr 9, 2008 at 4:48 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 09/04/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > It would be, if .eggs were a packaging format, rather than a binary
> > distribution/runtime format.
> >
> > Remember "eggs are to Python as jars are to Java" -
hink that four items is rather short and would prefer the
dots to come in around six or eight items. That's not entirely an
aesthetic preference, I also have a reason for thinking that it might
actually make a difference, but to avoid turning this discussion into
bike-shedding I'l
On Sun, Apr 20, 2008 at 4:15 PM, Tarek Ziadé <[EMAIL PROTECTED]> wrote:
> I have submitted a patch for review here: http://bugs.python.org/issue2663
>
> glob-style patterns or a callable (for complex cases) can be provided
> to filter out files or directories.
I'm not a big fan of the sequence-o
On Tue, Apr 22, 2008 at 1:56 AM, Tarek Ziadé <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 2:25 AM, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On Sun, Apr 20, 2008 at 4:15 PM, Tarek Ziadé <[EMAIL PROTECTED]> wrote:
> > > I have submit
ery* easily miss the fact that TITLEPATTERN is a
callable while glancing over the code (and be very confused if I later
saw it being called or passed as a callback)", most people would
dismiss the concern and tell me it was my problem. It certainly isn't a
ad out even longer, here's one example where I would use one:
def parrot(args, transformation=None):
if transformation is None: # Use an identity function.
transformation = lambda x: x
for arg in args:
do_something_with(transformation(arg))
Does anybody have any c
on't want them to have access to is solved by the
technical solution of file permissions and ACLs.
I have no opinion on this specific problem, but it is equally fallacious
to say that social problems_never_ have technical solutions as it is to
say that they _al
eter for enumerate().
Why would it be nice? What would you use it for?
The only thing I can think of is printing lines with line numbers, and
starting those line numbers at one instead of zero. If that's the only
use-case, should it require
nting
seq[i-1] = foo(item)
I never need to think about whether it is zero-based, one-based, or some
other N-based counting, because it is always zero-based.
-0 on any change to enumerate.
--
Steven D'Aprano
___
Python-Dev mailing list
Python-De
ith strings. But that's a discussion for
another day.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
+ 1*3
Which one should the compiler prohibit?
I strongly suggest that you look at the Zen of Python:
>>> import this
The Zen of Python, by Tim Peters
...
There should be one-- and preferably only one --obvious way to do it.
There should be ONE OBVIOUS way to do it,
omise it using standard
techniques e.g. shadow the atomic() function with your own version,
sub-class the types you wish to treat differently, make __atomic__ a
computed property instead of a simple attribute, etc.
Re-writing the above to match Python 3 is left as an exercise.
--
Steven
ll evil
Perhaps not the root of *all* evil but it is certainly the root of much
evil, and the treatment of delegation-based classes like UserString as
second-class objects is a good example of why isinstance checking
should be avoided as much as possible.
--
Steven
_
X" % s
"X {0!r} X".format(s)
"X " + repr(s) + " X"
I for one am excited to see advanced string formatting via .format(),
but would be very disappointed if future Python versions removed the
simplicity of %.
--
Steven
__
eep %-formatting for?
Yes, I don't particularly see the advantage of writing:
"spam %s spam" % (value,)
over
"spam %s spam" % value
Why require the first version?
--
Steven
___
Python-Dev mailing list
Python-Dev@python.
On Thu, 5 Jun 2008 08:50:32 pm Paul Moore wrote:
> On 05/06/2008, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> > Yes, I don't particularly see the advantage of writing:
> >
> > "spam %s spam" % (value,)
> >
> > over
> >
> > &q
On my computer, dict(a=spam,
b=eggs) is two times slower than {'a':spam, 'b':eggs} and nearly three
times slower than (spam, eggs). I don't imagine building a dict will
ever be faster than building a tuple. Given that format() is already
significantly slower than %, w
u want, that perhaps the test suite needs a tad better organisation.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
y splitting
the tests into sub-directories. You can still get all the false
positives you want by writing
grep -r -I parrot *
instead of
grep -I parrot *
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
really have to name your
attribute None, and are prepared to live with the consequences, then go
ahead.
In a similar fashion:
>>> class Parrot(object):
... pass
...
>>> p = Parrot()
>>> p.1 = 'spam'
File &q
a.y attribute!
return y # always returns 1
Perhaps you want this behaviour, but I don't think it is either obvious
or desirable.
Pascal doesn't have this problem because you always explicitly define
your local variables.
--
Steven
___
So I wouldn't discount your suggestion.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
t;> od.items()
[(1, 'norwegian red'), (2, 'parrot')]
This is close to the behaviour of regular dicts, and to do differently
would be very surprising to me. Again, anyone who wants the alternative
behaviour can get it easily, with a pop and a set.
+1 for an ordered di
ncept in jeopardy, then I vote -1 on the index-based API. This
applies also to slicing.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Sun, 15 Jun 2008 07:39:05 pm Armin Ronacher wrote:
> Steven D'Aprano pearwood.info> writes:
> > Conceptually, I would expect the following behaviour:
> > >>> od = odict()
> > >>> od[1] = 'spam' # insert a new key
> > >>&
g decimal
exponents with binary mantissas upsets me too, but somehow it's less
upsetting.)
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ride the wrong value. So as Python exists now, no, it's not
terribly useful. But it's not inherently a stupid idea.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
as "fail if"
or "fail unless", and I resent having to turn the condition around into
a "assert if not" test just to satisfy others who are never going to
read my code. I wish people would go find another bike shed to
interfere with.
--
Steven
_
eader,
you have no way of telling what my intent is.
When I write tests, my intent is often to specify the conditions that
constitute a failure. I don't want to negate it to specify a success
just to satisfy you.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
he likes it, that's his prerogative. But let's not
pretend that this particular bike shed colour has any objectively
rational reason, or that the change won't force some people to have to
change the way they think about tests.
--
Steven
___
han no decision, and
> I suspect most if us can agree that it's better if everyone thinks
> about tests the same way.
There's a term for what happens when everybody in a community or group
thinks about a subject the same way.
http://en.wikipedia.org/wiki/Groupthink
--
Steven
_
rt the nature of the tests:
assert_not_spam()
assert_ham()
assert_parrot()
assert_not_spanish_inquisition()
just for the sake of consistency (and that would be a good thing
*why*?), but only at the cost of inverting the code inside the test,
which may or may not be a simple thing to do.
--
Steven
_
ork with positive assertions, the method names themselves are doubly
> negative. assert* methods are so much more straightforward to
> comprehend.
Maybe for you. That's not a human universal. Please don't assume that
your favourite bike-shed colour mus
ther than
making another spurious claim of objective superiority.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
1401 - 1500 of 1900 matches
Mail list logo
