ually.
I agree that this is a concrete example that the PEP could address.
I myself don't know enough about decimal/cdecimal or the Python C API
to know why cdecimal can't duck type here, but it certainly sounds
like a good example to use to clarify the requirements being advocated
by the PEP
ng implementation-pain-wise and
lets-make-this-work-wise with the other implementations. The end result
will be better test coverage and clearer APIs in the stdlib.
--
R. David Murray http://www.bitdance.com
___
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, 17 Apr 2011 19:17:11 +0200, Stefan Krah wrote:
> R. David Murray wrote:
> [snip a lot]
>
> Thank you, this cleared up many things.
Heh. Keep in mind that this is my viewpoint. I *think* Brett agrees
with me. I'm sure he'll speak up if he doesn't.
> Th
(or even perhaps CPython developers) may want to
contribute Python-only versions and/or tests for things that would have
been affected by the PEP. I don't have time to do it right now,
but if I can pry any time loose I'll have it near the top of my list.
--
R. David Murray
y or any platform without
an accelerator (that is, anything *using* the python code) would be
expected to pass it.
I would hope that such tests would be vanishingly rare (that is,
that all needed tests can be expressed as black box tests).
--
R. David Murray http:/
on which to register the defect.
>
> What kind of object is *obj*?
Whatever object is being used to represent the data being parsed when
the defect is found. Right now that's always a Message, but that won't
continue to be true. The rest of
I'm not
> sure we want that at this point.
Personally, I consider myself an stdlib maintainer: I only occasionally
dabble in C code when fixing bugs that annoy me for some reason.
I suppose that's why I'm one of the people backing this PEP. I think
there are other CPython
27;s always the practicality beats purity argument:
if the PEP turns out to really get in the way of something everyone wants,
then we can agree to an exception.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-De
also enlightening to look at the output of hg churn. The number
of active CPython developers over the past year is not huge, and very
few of them have spoken up in this thread.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailin
; what "public" vs "private" is for) should not be tightly coupled to the
> > decision about whether to bother to explain what an API does?
>
> With what criteria would you propose to replace it with?
I believe Jean-Paul was suggesting that just because an interface is
language design principle (as I understand it) is that
mutable object do not return themselves upon mutation, while
immutable objects do return the new object.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python
27;t remember what
it was, though.
--
R. David Murray http://www.bitdance.com
___
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
pull
in .hg/last-message.txt, and just type 'Merge' in front of my previous
first line. I don't add the merge-from number, because I figure if you
know which branch you are looking at you know which branch the merge
came from, given that there is a strict progression.
--
R. David Mu
ou are applying a single changeset to multiple branches,
as we often do in our workflow, then I think duplicating the commit
message is (1) easy to do and (2) very helpful when looking at
hg log output.
--
R. David Murray http://www.bitdance.com
__
sary.
>
> > I thought the whole point of merging was that you brought a changeset
> > from one branch to another. This why I just write "merge" because
> > otherwise you're technically duplicating information that is pulled
> > onto the branch by merging.
&g
On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson
wrote:
> 2011/5/9 R. David Murray :
> > On Mon, 09 May 2011 09:08:53 -0500, Benjamin Peterson g> wrote:
> >> I thought the whole point of merging was that you brought a changeset
> >> from one branch to another
On Tue, 10 May 2011 11:51:19 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
> > On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson
> wrote:
>
> > > *cough* http://mercurial.selenic.com/wiki/GraphlogExtension
> >
> > I'
ut is better because it
indicates the causation more clearly. (I don't think it is necessary to
capture the subtlety of conditional assignment in the error message.)
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Pyth
x occasional
failures when when the randomly generated temporary path happened to
match the regex.
You will note the *active* verbs "fixed", "improve", and "change"
figure in there prominently :)
(Eh. And proofreading this email I see I made a grammar er
On Tue, 10 May 2011 17:45:44 +0400, Oleg Broytman wrote:
> On Tue, May 10, 2011 at 09:33:13AM -0400, R. David Murray wrote:
> > commit:
> > 11999: sync based on comparing mtimes, not mtime to system clock
> > NEWS:
> > Issue 11999: fixed sporadic sync failure
On Wed, 11 May 2011 00:59:08 +1000, Nick Coghlan wrote:
> On Tue, May 10, 2011 at 11:11 PM, R. David Murray w=
> rote:
> > How about:
> >
> > "reference to variable 'y' precedes an assignment that makes it a local
> > variable"
>
> For
On Tue, 10 May 2011 13:56:58 -0400, Terry Reedy wrote:
> On 5/10/2011 10:59 AM, Nick Coghlan wrote:
> > On Tue, May 10, 2011 at 11:11 PM, R. David Murray
> > wrote:
> >> How about:
> >>
> >> "reference to variable 'y' precedes an as
On Thu, 19 May 2011 01:16:44 +0900, "Stephen J. Turnbull"
wrote:
> Robert Collins writes:
>
> > Its probably too late to change, but please don't try to argue that
> > its correct: the continued confusion of folk running into this is
> > evidence that confusion *is happening*. Treat that as e
een once the
> bots update? If so, I'm impressed, and "thank you!" to all involved.
> Apple and MacPorts have long since washed their hands of that release.
You will note that Tiger is *not* in the stable set :)
--
R. David Murray http://www.bitdance.com
if anything
ought to be tweaked.
--
R. David Murray http://www.bitdance.com
___
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/arc
to look at Python/ceval.c.
--
R. David Murray http://www.bitdance.com
___
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/arc
_function_name(
var_one, var_two, var_three):
print x
vs
for x in long_function_name(
var_one, var_two, var_three):
print x
That's a case where I'd be likely to use even more than two indentation
levels. Usually, though, I try to refactor the statement
mentally ignore the "== typecode" part and see
> the switch structure more clearly.
I don't do much C coding, so I don't have the right to an opinion on
that (FWIW, I find constant-first jarring). But I'd hate to see the
above in python code. The fact that you li
t;> 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"?
No :)
Especially considering that Python actually has an 'is' operator.
I haven't read through your post, but if you don't know about it I
suspect that you will be interested in the following:
http://code.activestate.com/pypm/pysandbox/
I'm pretty sure Victor will be happy to have someone else interested in
this topic.
--
R. David Murray
On Sun, 19 Jun 2011 15:40:01 -0400, Jim Jewett wrote:
> Does this really need to be a bare except?
No, but that's a separate bug report, which you are welcome to
file. The issue I closed was about moving the existing code.
--
R. David Murray http://www.bitd
t is to
run just a selected set of fixers (so that you could use it to generate
python3 code), but it seems to me that renaming modules is something
that 3to2 (and 2to3, of course) should be good at.
--
R. David Murray http://www.bitdance.com
___
to following the existing coding
conventions of stdlib modules...
(I initially called it InvalidMultipartCTEDefect, but all of the other
names were spelled out, so)
--
R. David Murray http://www.bitdance.com
___
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
quest issues (ie: bugs) in
the tracker are tagged 2.7. I expect to see that percentage continue
to decrease over time.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
roposed code would allow me, when writing a generator in
my code, do something that would allow me to yield up all the
values from an arbitrary generator I'm calling, over which I have
no control (ie: I can't modify its code)?
--
R. David Murray http://www.bitdance.com
is that I am more comfortable calling them
all attributes than calling them all members. The term 'members'
isn't used anywhere in the language itself, as far as I can recall,
whereas getattr and setattr are evidence that the language considers
them all attributes. I think we do the
On Mon, 27 Jun 2011 15:27:12 +0100, Michael Foord
wrote:
> On 27/06/2011 15:08, R. David Murray wrote:
> > 'data attributes' can so easily become something else in Python...it
> > seems to me that the only real difference between 'data attributes' and
> &
type type). I don't think anyone would argue with you
about that in general. (In specific there might in fact be some
places in the docs where such a change would improve clarity!)
So, the correct generic term for something that can be accessed
via attribute notation is attribute. T
On Mon, 27 Jun 2011 20:30:12 +0100, Michael Foord
wrote:
> On 27/06/2011 20:22, R. David Murray wrote:
> > [snip...]
> > So, the correct generic term for something that can be accessed
> > via attribute notation is attribute. The more specific term for an
> > at
esn't cover "class attributes that aren't
> descriptors").
Also, instances can have methods as instance attributes.
Trying to use 'instance attributes' for non-method attributes is a bad
idea, I think.
Given that there is no one thing that covers al
cified, someone suggested that the overall sleep time could also be
> truncated to a minimum of zero, i.e. treating negative values as zero.
Please file a bug report at bugs.python.org.
--
R. David Murray http://www.bitdance.com
___
Pytho
we're not too
likely to know how to work with it on Windows if you don't install it
from the MSI.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
roject kicks off, but I wanted to release/post now
so that there might be a chance of some review happening while I still
have time to respond quickly to the feedback.
--
R. David Murray http://www.bitdance.com
[*] I believe that if you try to use an email6 Message object with the 3.2
things as flat as practical. Namespace
packages clearly have utility, but please let's not descend into
java-esq package hierarchies.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://
> Or perhaps worms dig their way carefully around known bugs?
Hexlify, wormaround...our Barry is just full of interesting words :)
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
-like system, I need to know the path to said script.
We're trying to make python as easy to use on Windows as it is on Unix.
If find-script-on-path is considered a worthwhile feature, then as Mark
said it should be added to base Python (on all platforms), not special-cased
in the Windows laun
u did in what I wrote, though.
--
R. David Murray http://www.bitdance.com
___
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
documentation for test.support to
the devguide, and then vet the test suite so that unlink and friends
are always called as 'support.unlink', etc.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@py
On Wed, 27 Jul 2011 16:58:53 +0300, Eli Bendersky wrote:
> R. David Murray wrote:
> > But they aren't redundant, since the test.support versions ignore
> > errors.
>
> As I mentioned elsewhere, it's not good practice to have two functions with
> the same name
On Fri, 29 Jul 2011 15:28:44 +0200, =?UTF-8?B?w4lyaWMgQXJhdWpv?=
wrote:
> Le 29/07/2011 14:50, Antoine Pitrou a écrit :
> >> changeset: 71562:bdad5bc9a2ed
> >> user:Ãric Araujo
> >> summary:
> >> Stop ignoring Mercurial merge conflits files
On Fri, 29 Jul 2011 15:38:31 +0200, Antoine Pitrou wrote:
> On Fri, 29 Jul 2011 15:28:44 +0200 > Ãric Araujo wrote:
> > make clean removes generated files, but *.rej and *.orig are backups,
> > which you may want to save or re-apply.
>
> What use are these backups really? We are using a (D)VCS,
care to in
the same way. That would doubtless help our users, but more care than
just marking functions as unstable would be required, I think.
Personally, I always thought the devguide should be part of Docs anyway.
It isn't because people didn't want it versioned along si
#x27;hg status' tells me all the files
that have appeared in my tree that I'm either not currently tracking or
explicitly ignoring (because the project's automated tools will deal
with them). Nothing in there about limiting it to files I *might*
w
wouldn't be any more of a problem than the regular python docs if
the devguide were in the normal doc tree. Just saying :)
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
On Fri, 29 Jul 2011 23:36:03 +0200, Antoine Pitrou wrote:
> On Fri, 29 Jul 2011 12:19:45 -0400
> "R. David Murray" wrote:
> >
> > > Besides, "hg status" is meant to show untracked files which could
> > > *potentially* be tracked. It's not
worked like
> this (we have many private APIs without an underscore).
I'm not sure it makes merging more difficult. I haven't had any
problems with email test merges even though I moved (i.e. renamed)
the test directory.
--
R. David Murray http://www.bitdance.com
n project.
My understanding (I could well be wrong) is that one reason is that we
prefer that the tests be installed. That is also the reason that a number
of tests that use large data files fetch them from the network (if and
only if the relevant resource is enabled).
--
R. David Murray
ndicate that something about the fix is not right.
So, I'm not sure this skip is even valid. I'm not sure we've finished
diagnosing the bug.
If there are any helpful tests I can run on Gentoo, please let me know.
--
R. David Murray http://www.bitdance.com
__
stalled.
I get null as the final output of that regardless of whether I use
'tr_TR' or 'tr_TR.utf8'.
This is with glibc-2.13-r2 (the r2 is Gentoo's mod number).
I'll attach this to the bug report, too, perhaps the discussion should
move there.
--
R. David Murray
On Tue, 02 Aug 2011 18:48:11 +0100, Chris Withers
wrote:
> On 19/07/2011 22:21, R. David Murray wrote:
> > The basic additional API is that a 'source' attribute contains the
> > text the generator read from the input source, and a 'value' attribute
>
them. Everything else is just details. And yes,
that distinction is much more important than the distinction between
minor version numbers. That's the whole point of python3, after all.
--
R. David Murray http://www.bitdance.com
___
P
luding that you are -1 on
the PEP :).
--
R. David Murray http://www.bitdance.com
___
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
nstall, so be it.
True, but I think that is orthogonal to the purposes of the PEP, which
is about supporting writing of system independent scripts that are *not*
provided by the distribution (or installed via packaging). And PEP 397
aims to extend that to
Two patches have been committed to 3.3 that I am very uncomfortable with.
See issue 13637 and issue 13641, respectively.
It seems to me that part of the point of the byte/string split (and the
lack of automatic coercion) is to make the programmer be explicit about
converting between unicode and by
On Mon, 27 Feb 2012 11:21:16 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
wrote:
> I find this rationale a bit sad: it's not that there is any (IMO) good
> technical reason for the feature - only that people "hate" the many
> available alternatives for some reason.
>
> But then, practicalit
On Mon, 27 Feb 2012 09:05:54 -0800, Ethan Furman wrote:
> Martin v. Löwis wrote:
> > Am 26.02.2012 07:06, schrieb Nick Coghlan:
> >> On Sun, Feb 26, 2012 at 1:13 PM, Guido van Rossum wrote:
> >>> A small quibble: I'd like to see a benchmark of a 'u' function
> >>> implemented in C.
> >> Even if
On Mon, 27 Feb 2012 10:17:57 -0800, Guido van Rossum wrote:
> On Mon, Feb 27, 2012 at 10:01 AM, Chris McDonough wrote:
> > The best argument is that there already exists tons and tons of Python 2
> > code that already does:
> >
> > Â u'that'
>
> +1
>
> > Needing to change it to:
> >
> > Â u('th
On Mon, 27 Feb 2012 14:50:21 -0500, Chris McDonough wrote:
> Currently we handle 3.2 compatibility in packages that "straddle" via
> six-like functions. We can continue doing this as necessary. If the
It seems to me that this undermines your argument in favor of u''.
Why can't you just continue
On Mon, 27 Feb 2012 16:16:39 -0500, Chris McDonough wrote:
> On Mon, 2012-02-27 at 21:03 +, Vinay Sajip wrote:
> > Yes, but making a backward step like reintroducing u'' just to make things a
> > tiny little bit sucky doesn't seem to me to be worth it, because then >=
> > 3.3 is
> > different
On Mon, 27 Feb 2012 16:10:25 -0500, Chris McDonough wrote:
> On Mon, 2012-02-27 at 21:07 +, Paul Moore wrote:
> > On 27 February 2012 20:39, Chris McDonough wrote:
> > > Note that u'' literals are sort of the tip of the iceberg here;
> > > supporting them will obviously not make development u
On Mon, 27 Feb 2012 22:11:36 +, Armin Ronacher
wrote:
> On 2/27/12 9:58 PM, R. David Murray wrote:
> > But the PEP doesn't address the unicode_literals plus str() approach.
> > That is, the rationale currently makes a false claim.
> Which would be exactly what tha
On Tue, 28 Feb 2012 22:21:11 +1000, Nick Coghlan wrote:
> On Tue, Feb 28, 2012 at 10:10 PM, Vinay Sajip wrote:
> > If the 2.x code depends on having u'xxx' literals, then 3.2 testing will
> > potentially involve running a fixer on all files in the project every time a
> > change is made, writing
On Wed, 29 Feb 2012 17:06:21 -0500, Calvin Spealman
wrote:
> On Feb 28, 2012 7:14 PM, wrote:
> >>
> >> Why is readding u'' a feature and not a bug?
> >
> >
> > There is a really simple litmus test for whether something is a bug:
> > does it deviate from the specification?
> >
> > In this case, t
On Thu, 01 Mar 2012 10:13:01 +1100, Chris Angelico wrote:
> On Thu, Mar 1, 2012 at 8:08 AM, Paul Moore wrote:
> > It would (apparently) help Victor to fix issues in his pysandbox
> > project. I don't know if a secure Python sandbox is an important
> > enough concept to warrant core changes to mak
On Thu, 01 Mar 2012 17:24:31 +0100, Antoine Pitrou wrote:
> On Thu, 1 Mar 2012 11:24:19 -0500
> Barry Warsaw wrote:
> >
> > I really do think that to the extent that you can do that kind of thing, you
> > may end up with essentially Python 3 support without even realizing it. :)
>
> That's unli
On Thu, 01 Mar 2012 21:12:48 +, Armin Ronacher
wrote:
> Hi,
>
> On 2/29/12 12:30 PM, Yury Selivanov wrote:
> > I see you've (or somebody) changed:
> Yes, I reworded that.
>
> > Could you just remove the statement completely?
> I will let Nick handle the PEP wording.
>
> > I don't think tha
On Thu, 01 Mar 2012 16:50:06 -0800, Guido van Rossum wrote:
> On Thu, Mar 1, 2012 at 4:39 PM, Victor Stinner
> wrote:
> > frozendict could be used to implement "read-only" types: it is not possible
> > to add or remove an attribute or set an attribute value, but attribute value
> > can be a muta
On Sat, 03 Mar 2012 03:06:33 +0400, "Alex A. Naanou"
wrote:
> Hi everyone,
>
> Just stumbled on a fun little thing:
>
> We create a simple structure...
>
> l = ([],)
>
>
> Now modify the list, and...
>
> l[0] += [1]
>
>
> ...we fail:
> ## Traceback (most recent call last):
> ## File
I don't like any of the suggested wordings. I have no problem with
us recommending other modules, but most of the Python libraries are
perfectly functional (not "leaky" or some other pejorative), they just
aren't as capable as the wiz-bang new stuff that's available on PyPI.
--David
_
On Wed, 14 Mar 2012 06:03:10 +0200, Eli Bendersky wrote:
> > Rather than indicating apathy on the party of third party developers, this
> > might be a sign that core Python is unapproachable or not worth the effort.
> >
> > For instance I have several one line patches languishing, I can't imagine
On Wed, 14 Mar 2012 10:05:11 -, Mark Shannon wrote:
> But how do you find issues?
>
> I want to do some reviews, but I don't want to wade through issues on
> components I know little or nothing about in order to find the ones I
> can review.
>
> There does not seem to be a way to filter sea
On Fri, 16 Mar 2012 09:38:49 +0200, Eli Bendersky wrote:
> 1. The behavior of append, insert and extend should be similar in this respect
> 2. AssertionError is not the customary error in such case - TypeError
> is much more suitable
> 3. The C implementation of ElementTree actually raises TypeErr
On Fri, 16 Mar 2012 15:49:33 -0400, Terry Reedy wrote:
> On 3/16/2012 11:33 AM, R. David Murray wrote:
> > On Fri, 16 Mar 2012 09:38:49 +0200, Eli Bendersky wrote:
> >> 1. The behavior of append, insert and extend should be similar in this
> >> respect
> &
On Tue, 20 Mar 2012 04:43:44 -0400, Glyph wrote:
>
> On Mar 20, 2012, at 3:33 AM, Matt Joiner wrote:
>
> > I believe we should make a monotonic_time method that assures monotonicity
> > and be done with it. Forward steadiness can not be guaranteed. No
> > parameters.
> >
>
> I think this dis
On Wed, 21 Mar 2012 09:09:38 +1100, Mark Hammond
wrote:
> On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
> > I asked a question about this on IRC, to which the response was that
> > there were two main reasons to install python in c:\pythonxy:
> >
> > 1 - issues due to spaces ('Program Files') or
On Tue, 20 Mar 2012 23:38:53 +0100, Georg Brandl wrote:
> Hi all,
>
> recently I've grown a bit tired of seeing our default Sphinx theme,
> especially as so many other projects use it. I decided to play around
> with something "clean" this time, and this is the result:
>
> http://www.python.o
On Wed, 21 Mar 2012 06:58:21 +0100, Georg Brandl wrote:
> On 21.03.2012 00:17, R. David Murray wrote:
> > On Tue, 20 Mar 2012 23:38:53 +0100, Georg Brandl wrote:
> >> Hi all,
> >>
> >> recently I've grown a bit tired of seeing our default Sphinx theme,
On Wed, 21 Mar 2012 12:39:18 -0700, Guido van Rossum wrote:
> On Wed, Mar 21, 2012 at 12:12 PM, Ned Batchelder
> wrote:
> > Personally, I think two Python projects that have focused on docs and done a
> > good job of it are Django and readthedocs.org. Â Perhaps we could follow
> > their lead?
>
On Fri, 23 Mar 2012 07:57:18 +1100, Chris Angelico wrote:
> On Fri, Mar 23, 2012 at 6:50 AM, Glenn Linderman
> wrote:
> > 3. Make the sidebar separately scrollable, so that it stays visible when
> > scrolling down in the text. This would make it much easier to jump from
> > section to section,
On Mon, 26 Mar 2012 08:44:40 -0400, Scott Dial
wrote:
> Why even bother formatting the page?
The web started out as *content markup*. Functional declarations, not
style declarations. I wish it had stayed that way, but it was inevitable
that it would not.
> The authorship and editorship have a
On Mon, 26 Mar 2012 12:55:42 -0400, PJ Eby wrote:
> On Sat, Mar 24, 2012 at 8:41 PM, Ben Finney wrote:
> > So, again, why make your browser window *for reading text* that large?
>
> Because I have one browser window, and it's maximized. And I can do this,
> because most websites are designed in
On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Aprano wrote:
> +1 on Nick's suggestion of try_monotonic. It is clear and obvious and doesn't
> mislead.
How about "monotonicest".
(No, this is not really a serious suggestion.)
However, time.steadiest might actually work.
--David
_
On Wed, 28 Mar 2012 20:56:30 -, "Jason R. Coombs" wrote:
> Will the release notes include something about this change, since it will
> likely have broad backward incompatibility for all existing virtualenvs? I
> wouldn't expect someone in operations to read the virtualenv news to find
> out wh
Since Martin hasn't sent a note about this here I will:
I noticed that text search wasn't working right on the bug tracker, and Martin
has taken it offline again to re-index.
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
On Thu, 29 Mar 2012 11:41:46 -, "Jason R. Coombs" wrote:
> Does the issue only exist for Python 2.6 and 2.7?
It might exist for 3.1 and 3.2 as well.
> I'm not familiar with the release process. What's the next step?
I would suggest opening an issue on the tracker and marking it as a
release
On Thu, 29 Mar 2012 18:21:34 +0200, Ross Lagerwall
wrote:
> On 03/29/2012 05:07 AM, "Martin v. Löwis" wrote:
> >>> I noticed that text search wasn't working right on the bug tracker, and
> >>> Martin
> >>> has taken it offline again to re-index.
> >>
> >> which will, unfortunately, take a few m
Some of us have expressed uneasiness about the consequences of dict
raising an error on lookup if the dict has been modified, the fix Victor
made to solve one of the crashers.
I don't know if I speak for the others, but (assuming that I understand
the change correctly) my concern is that there is
On Thu, 29 Mar 2012 21:14:32 +0200, =?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=
wrote:
> Am 29.03.2012 18:21, schrieb Ross Lagerwall:
> > On 03/29/2012 05:07 AM, "Martin v. Löwis" wrote:
> I noticed that text search wasn't working right on the bug tracker, and
> Martin
> has take
On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum wrote:
> On Thu, Mar 29, 2012 at 12:58 PM, R. David Murray
> wrote:
> > Some of us have expressed uneasiness about the consequences of dict
> > raising an error on lookup if the dict has been modified, the fix Victor
> &
On Thu, 29 Mar 2012 16:31:03 -0400, "R. David Murray"
wrote:
> On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum wrote:
> > My original assessment was that this only affects dicts whose keys
> > have a user-implemented __hash__ or __eq__ implementation, and that
&g
801 - 900 of 1043 matches
Mail list logo
