On Thu, 5 Jun 2008 10:43:20 pm Nick Coghlan wrote:
> I'm really starting to wonder if supporting positional arguments to
> str.format() *at all* is a mistake. Maybe we should ditch support for
> positional arguments and just accept a single dictionary as the sole
> parameter to format().
>
> For d
On Sat, 7 Jun 2008 07:32:40 am Martin v. Löwis wrote:
> Flat is better than nested,
> and adding hierarchy will make it *more* difficult to find anything
> (except perhaps for the one person who did the rearrangement).
Do you have a filing cabinet with everything filed under "F" for File?
*wink*
On Sat, 7 Jun 2008 08:58:06 am Eric Smith wrote:
> > Really? Given the choice between core_language (divided into syntax
> > and builtins) and stdlib you wouldn't know where to look?
>
> Really. I wouldn't bother thinking about it. I'd just grep.
Since you'll do the same thing regardless of whet
On Mon, 9 Jun 2008 12:24:55 pm Curt Hagenlocher wrote:
> So, it's okay to setattr the attribute name "None" but not okay to
> set it directly?
I suspect this is off-topic for python-dev, and would be better on
comp.lang.python or similar, but for what it's worth, I consider having
an attribu
On Sat, 14 Jun 2008 04:19:30 pm Cesare Di Mauro wrote:
> A "with" statement (such as Pascal's one) can be implemented adding a
> new scope resolution on top of LEGB. So, taking the FAQ's example,
> and using a new keyword (because with is already assigned to a
> different kind of work):
>
> def fo
On Sun, 15 Jun 2008 02:59:51 pm David Wolever wrote:
> And, as far as questions about the definition of an ordered
> dictionary, is there any good reason not to simply treat the dict as
> a list? Something like (with the obvious bits left out):
Yes.
(1) If you implement the ordered dict as a l
On Sun, 15 Jun 2008 05:12:38 pm Raymond Hettinger wrote:
> With an odict that preserves insertion order, you're talking about
> *deleting* the old entry and *appending* the new one, complete with
> both the new key and new value.
I certainly don't consider updating an ordered dictionary entry as
On Sun, 15 Jun 2008 06:42:32 pm laurent wrote:
> An other way to think of such a structure would be as a list, for
> which each item would also have an associated key.
> I think someone mentioned the link with a list during this thread,
> but here I am not referring to implementation, but the feat
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
> > >>&
On Fri, 27 Jun 2008 07:30:43 am Raymond Hettinger wrote:
> The format is already close to the C99 notation
> but replaces the 'p' with '* 2.0 **' which I find to
> be both readable and self-explanatory.
Since we're talking about what's "readable and self-explanatory", I find
that jarring, unexpec
On Sat, 28 Jun 2008 11:17:10 am Greg Ewing wrote:
> tomer filiba wrote:
> > >>> def f(**kwargs):
> >
> > ... print kwargs
> > ...
> >
> > >>> f(a=5,b=7,a=8)
> >
> > {'a': 8, 'b': 7}
>
> I can't think of any reason why one would need to be
> able to write such code, or even want to.
It would
On Mon, 14 Jul 2008 12:45:58 am Michael Foord wrote:
> I tend to think of testing as action followed by assertion -
> I do this and this should have happened. Your tests usually define
> 'expected behaviour' rather than defining how your code won't fail...
Who is the "your" that you are speaking
On Mon, 14 Jul 2008 12:39:48 am Antoine Pitrou wrote:
> Let's split hairs a little...
>
> Steve Holden holdenweb.com> writes:
> > "Fail" isn't a negative. As Guido said, it's a description of the
> > test behavior under particular circumstances.
>
> In most circumstances, "fail" is a negative word
On Mon, 14 Jul 2008 04:19:57 am Mark Hammond wrote:
> try to stick to the issue at hand
I'm sorry, did I reply to the wrong message? I thought this was part of
a thread titled "unittest's redundant assertions: asserts vs.
failIf/Unlesses". What *is* the issue at hand if not the question of
p
On Mon, 14 Jul 2008 09:54:16 am Steve Holden wrote:
> > Python may be Guido's language, and if he wants to use his
> > dictatorial powers to say that tests must be written as positive
> > assertions because that's the way he likes it, that's his
> > prerogative. But let's not pretend that this part
On Mon, 14 Jul 2008 04:27:40 pm Stephen J. Turnbull wrote:
> FWIW, I meant 10 != not not 10.
>>> 10 != not not 10
File "", line 1
10 != not not 10
^
SyntaxError: invalid syntax
With respect, I think that the fact that you made an analogy with Python
code that you hadn't tested
On Tue, 15 Jul 2008 04:55:59 pm Thomas Lotze wrote:
> I'm surprised nobody (that I've noticed) has brought up the point yet
> that test code is a lot easier to read if it makes positive
> assertions.
Please don't claim that your subjective opinion is an objective fact.
> When reading failure c
On Tue, 15 Jul 2008 08:54:25 pm Jeroen Ruigrok van der Werven wrote:
> Some greps on random Python projects give me a 4-10:1 ratio for
> assert* versus fail*.
Without knowing what those "random" projects are, or what the grep was,
it's impossible to interpret that statistic. For example, is it b
On Tue, 15 Jul 2008 06:32:53 pm Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
> > On Mon, 14 Jul 2008 04:27:40 pm Stephen J. Turnbull wrote:
> > > FWIW, I meant 10 != not not 10.
> > >
> > >>> 10 != not not 10
>
On Wed, 16 Jul 2008 08:13:22 am Guido van Rossum wrote:
> > Tests in the standard distribution which use the deprecated
> > style will need to be converted. Steven d'Aprano claims this is
> > nontrivial (and thus error- prone) in some cases. I haven't seen
> &g
On Tue, 15 Jul 2008 09:26:45 am Raymond Hettinger wrote:
> From: "Ben Finney" <[EMAIL PROTECTED]>
>
> > Right, so I'm putting up a separate PEP just for the renaming.
> > Should be arriving on this list soon.
>
> I would like to work with you or someone else who is interested
> on an alternative PE
On Sun, 27 Jul 2008 02:23:11 am [EMAIL PROTECTED] wrote:
> How about just making a matrix multiply function that can take many
> arguments? I think this is pretty readable:
>
> mmul(a, b, c, d)
>
> Additionally, mmul could then optimize the order of the
> multiplications (e.g., depending the dime
On Thu, 31 Jul 2008 03:01:42 pm Sumant Gupta wrote:
> Hi
>
> I have a problem reading very large text file.
> When I call the len function to get the total lines in python file.i
> get memory error . I am reading the list of files in a loop ,2 files
> are read properly but when the third file is re
On Mon, 25 Aug 2008 05:04:16 am Antoine Pitrou wrote:
> > > CompareFloatsIntegers: 274ms 274ms 0.30us
> > > 0.630ms
> >
> > Much slower, but probably due to switch from int -> long. There
> > could be potential for optimizing this case.
>
> Well honestly you don't often compare
On Thu, 28 Aug 2008 08:39:01 am Georg Brandl wrote:
> Fredrik Lundh schrieb:
> > (using 3.0a4)
> >
> > >>> exec(open("file.py"))
> >
> > Traceback (most recent call last):
> >File "", line 1, in
> > TypeError: exec() arg 1 must be a string, file, or code object, not
> > TextIOWrapper
> >
> >
On Thu, 28 Aug 2008 01:38:14 pm Guido van Rossum wrote:
> On Wed, Aug 27, 2008 at 6:21 PM, Steven D'Aprano <[EMAIL PROTECTED]>
wrote:
...
> > I don't think M.__file__ should lie and say it was loaded from a
> > file that it wasn't loaded from. It's usef
On Mon, 1 Sep 2008 11:24:02 pm Nick Coghlan wrote:
> I've been taking a close look at the API for multiprocessing and
> threading, and have discovered a somewhat strange pattern that occurs
> multiple times in both interfaces: factory functions with names that
> start with a capital letter so they
On Tue, 16 Sep 2008 10:50:45 am Greg Ewing wrote:
> Steven D'Aprano wrote:
> > I was confused about the role of commas, and totally gobsmacked
> > when I discovered that commas make tuples everywhere except when
> > following an except statement.
>
> Um... you'
On Tue, 30 Sep 2008 11:50:10 pm Guido van Rossum wrote:
> > To avoid silent skipping, is it possible to drop 'unreadable'
> > names, issue a warning (instead of exception), and continue to
> > completion? "Warning: unreadable filename skipped; see
> > PyWiki/UnreadableFilenames"
>
> That would be
On Wed, 1 Oct 2008 07:40:01 am Martin v. Löwis wrote:
> >> On Windows, we might reject bytes filenames for all file
> >> operations: open(), unlink(), os.path.join(), etc. (raise a
> >> TypeError or UnicodeError)
> >
> > Since I've seen no objections to this yet: please no. If we offer a
> > "lower
On Wed, 1 Oct 2008 09:21:37 am you wrote:
> On Tue, Sep 30, 2008 at 4:08 PM, Steven D'Aprano <[EMAIL PROTECTED]>
wrote:
> > On Wed, 1 Oct 2008 07:40:01 am Martin v. Löwis wrote:
> >> >> On Windows, we might reject bytes filenames for all file
> >> &
On Thu, 2 Oct 2008 01:46:45 pm Barry Warsaw wrote:
> On behalf of the Python development team and the Python community, I
> am happy to announce the release of Python 2.6 final. This is the
> production-ready version of the latest in the Python 2 series.
I'd like to thank you all very much for yo
On Sat, 4 Oct 2008 12:26:30 pm Nick Coghlan wrote:
> (Tangent: the above two try/except examples are perfectly legal Py3k
> code. Do we really need the "pass" statement anymore?)
I can't imagine why you would think we don't need the pass statement. I
often use it:
* For subclassing exceptions:
On Thu, 9 Oct 2008 06:27:06 am Kristján Valur Jónsson wrote:
> Hello there.
> I've just noticed what I consider a performance problem:
> Using new style classes to provide attribute-like access using
> __getattr__ is considerably slower than old style classes: Observe:
>
> s = """
> class dude:
>
On Sat, 15 Nov 2008 01:27:54 am Daniel Furrer wrote:
[snip]
> We're looking for:
> - Hints as to which python compiler would be best to work on. (The
> official Python compiler package seems very nice to work with
> actually...) - If there are any requests in the area of optimization
> that we coul
On Fri, 28 Nov 2008 11:59:39 pm Mart Somermaa wrote:
> Nick Coghlan wrote:
> > As Hrvoje has pointed out, 'sys' is part of the internal
> > interpreter machinery - it's there as soon as the interpreter
> > starts. The import call for it just grabs it out of the module
> > cache and creates a refere
On Sat, 29 Nov 2008 03:30:49 am Christian Heimes wrote:
...
> May I point you to the two leading underscores? The name '__import__'
> clearly suggests that the function is part of Python's internals. By
> definition all attributes of the form __*__ are not meant to be used
> directly.
What about
On Sat, 29 Nov 2008 05:20:01 am Alex Martelli wrote:
> On Fri, Nov 28, 2008 at 9:47 AM, Steven D'Aprano <[EMAIL PROTECTED]>
wrote:
> > On Sat, 29 Nov 2008 03:30:49 am Christian Heimes wrote:
> > ...
> >
> >> May I point you to the two leading unders
On Sat, 29 Nov 2008 01:56:00 pm Nick Coghlan wrote:
> Steven D'Aprano wrote:
> > Should this be reported as a documentation bug? Given the new
> > import hooks, would it be fair to say that the main reason for
> > __import__ is to use it to import a module whose name is
On Sat, 6 Dec 2008 09:18:47 am Nick Coghlan wrote:
> Toshio Kuratomi wrote:
> > Guido van Rossum wrote:
> >> Glob was just an example. Many use cases for directory traversal
> >> couldn't care less if they see *all* files.
> >
> > Okay. Makes it harder to prove correct or not if I don't know what
On Sat, 6 Dec 2008 12:47:45 pm Guido van Rossum wrote:
> But I disagree that "most of the cool possibilities they have heard
> about" are necessarily third party libraries. Python's standard
> library has lots of stuff to offer.
+1 on that. I've been using Python for a decade now, and the first th
On Sat, 6 Dec 2008 11:48:27 am Nick Coghlan wrote:
> Toshio Kuratomi wrote:
> > Nick Coghlan wrote:
...
> >> Why? Most programs won't be able to do anything with it. And if
> >> the program *can* do something with it... that's what the bytes
> >> version of the APIs are for.
> >
> > Nonsense. A pr
On Tue, 9 Dec 2008 08:55:21 am Filip Gruszczyński wrote:
> There is a large discussion on python-list about Guido's article
> about new self syntax, therefore I would like to use that to raise
> similar question: self in the body. Some time ago I was coding in
> Magik language
> (http://en.wikipedi
On Fri, 12 Dec 2008 06:33:28 pm Toshio Kuratomi wrote:
> Also interesting, if you point your browser at:
> http://toshio.fedorapeople.org/u/
>
> You should see two other test files. They're both
> (one-half)(enyei).html but one's encoded in utf-8 and the other in
> latin-1.
For what it's worth
nce (which is hideous without it)--I have
> no reason to think there are any loops.
>
> Currently I am working around this by doing an os._exit(), which is
> immediate, but this seems like a bit of hack. Is this something that
> needs fixing, or that has already been f
choose other mechanisms for speeding up the
> exit process in various (less clean) ways, if they have a need for
> this.
>
> BTW: Rather than using a huge in-memory dict, I'd suggest to either
> use an on-disk dictionary such as the ones found in mxBeeBase or
> a database.
The
On Sun, 21 Dec 2008 06:45:11 am Antoine Pitrou wrote:
> Steven D'Aprano pearwood.info> writes:
> > In November 2007, a similar problem was reported on the
> > comp.lang.python newsgroup. 370MB was large enough to demonstrate
> > the problem. I don't know if a
should be two different
functions rather than one function with a switch. I think
os.path.commonprefix should only operate on path components, and if
character-by-character prefix matching on general strings is useful,
then it should be a string method.
--
Steven D'Aprano
_
gladly give up that
correspondence (which I don't find that great) in order to simplify
exiting a generator expression early.
So I like the proposed change. I find it elegant and very Pythonic. +1
for me.
--
Steven D'Aprano
___
Pyth
On Wed, 21 Jan 2009 03:10:24 pm Terry Reedy wrote:
> Steven D'Aprano wrote:
...
> > In a generator expression, we have:
> >
> > yielded-expr for-clause if-clause
> >
> > while the corresponding nested statements are:
> >
> > for-clause if
ot that difficult to create a generator to yield all
the combinations:
(comb for k in ks for comb in itertools.combinations(seq, k))
I'm with Nick that this would make a good example for the documentation.
I don't object to combinations growing the extra functionality, but if
it does, peo
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be no
need for the pprint module. In any case, it seems that the pprint module
actually calls repr() on objects other than dicts, tuples an
Eric Smith wrote:
Terry Reedy wrote:
Ron Adam wrote:
Steven D'Aprano wrote:
Michael Foord wrote:
Don't we have a pretty-print API - and isn't it spelled __str__ ?
Not really. If it were as simple as calling str(obj), there would be
no need for the pprint module.
I agr
Raymond Hettinger wrote:
The arguments for and against the patch could be brought against
partial()
itself, so I don't understand the -1's at all.
Quite so, but that doesn't justify adding more capabilities to partial().
I concur with Collin. Lever arguments are a road to bloat.
One pers
Antoine Pitrou wrote:
Hello,
When reviewing the PEP 3151 implementation (*), Ezio commented that
"FileSystemError" looks a bit strange and that "FilesystemError" would
be a better spelling. What is your opinion?
It's a file system (two words), not filesystem (not in any dictionary or
spell ch
Ben Finney wrote:
"M.-A. Lemburg" writes:
No, you tell them: "If you want Unicode 6 semantics, use regex, if
you're fine with Unicode 2.0/3.0 semantics, use re".
What do we say, then, to those who are unaware of the different
semantics between those versions of Unicode, and want regular exp
Ben Finney wrote:
Steven D'Aprano writes:
Ben Finney wrote:
"M.-A. Lemburg" writes:
No, you tell them: "If you want Unicode 6 semantics, use regex, if
you're fine with Unicode 2.0/3.0 semantics, use re".
What do we say, then, to those who are unaware of t
Antoine Pitrou wrote:
On Fri, 26 Aug 2011 17:25:56 -0700
Dan Stromberg wrote:
[...]
If you add regex as "import regex", and the new regex module doesn't work
out, regex might be harder to get rid of. from __future__ import is an
established way of trying something for a while to see if it's g
Terry Reedy wrote:
On 8/26/2011 8:23 PM, Antoine Pitrou wrote:
I would only agree as long as it wasn't too much worse
than O(1). O(log n) might be all right, but O(n) would be
unacceptable, I think.
It also depends a lot on *actual* measured performance
Amen. Some regard O(n*n) sorts to be,
Dan Stromberg wrote:
On Sat, Aug 27, 2011 at 9:53 AM, Brian Curtin wrote:
On Sat, Aug 27, 2011 at 11:48, Dan Stromberg wrote:
No, this was not the intent of __future__. The intent is that a
feature is desirable but also backwards incompatible (e.g. introduces
a new keyword) so that for 1 (so
Antoine Pitrou wrote:
Le jeudi 01 septembre 2011 à 08:45 -0700, Guido van Rossum a écrit :
This is definitely thought of as a separate
mark added to the e; ë is not a new letter. I have a feeling it's the
same way for the French and Germans, but I really don't know.
(Antoine? Georg?)
Indeed, t
Terry Reedy wrote:
On 9/6/2011 12:58 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/06/2011 12:59 PM, Stephen J. Turnbull wrote:
Joao S. O. Bueno writes:
Removing it would mean explicitly "batteries removal".
That's what we usually do with a dead battery, no?
Raymond Hettinger wrote:
On Sep 6, 2011, at 1:36 PM, Martin v. Löwis wrote:
I think this is what people underestimate. I can't name
applications either - but that doesn't mean they don't exist.
Google code search is pretty good indicator that this method
has near zero uptake. If it dies, I
Ethan Furman wrote:
A question came up on StackOverflow about range objects and floating
point numbers. I thought about writing an frange that did for floats
what range does for ints,
For what it's worth, here's mine:
http://code.activestate.com/recipes/577068-floating-point-range/
--
S
Guido van Rossum wrote:
On Fri, Sep 23, 2011 at 6:36 PM, Steven D'Aprano wrote:
Ethan Furman wrote:
A question came up on StackOverflow about range objects and floating point
numbers. I thought about writing an frange that did for floats what range
does for ints,
For what it&#x
Guido van Rossum wrote:
On Fri, Sep 23, 2011 at 7:13 PM, Steven D'Aprano wrote:
http://code.activestate.com/recipes/577068-floating-point-range/
I notice that your examples carefully skirt around the rounding issues.
I also carefully *didn't* claim that it made rounding issues
Fernando Perez wrote:
On Sat, 24 Sep 2011 08:13:11 -0700, Guido van Rossum wrote:
I expect that to implement a version worthy of the stdlib math module,
i.e. that computes values that are correct within 0.5ULP under all
circumstances (e.g. lots of steps, or an end point close to the end of
the
Alexander Belopolsky wrote:
On Tue, Sep 27, 2011 at 2:23 AM, Greg Ewing wrote:
..
And I don't like "linspace" either. Something more self
explanatory such as "subdivide" or "interpolate" might
be better.
"Grid" would be nice and short, but may suggest 2-dimentional result.
Whatever word we c
Alexander Belopolsky wrote:
In addition to Steven's criticisms of numpy.linspace(), I would like a
new function to work with types other than float. It certainly makes
sense to have range-like functionality for fractions and decimal
floats, but also I often find a need to generate a list of equ
Ethan Furman wrote:
What about the idea of this signature?
frange([start], stop, step=None, count=None)
Then when count is desired, it can be specified, and when step is
sufficient, no change is necessary.
A default of start=0 makes sense for integer range, because the most
common use for
Oleg Broytman wrote:
On Tue, Sep 27, 2011 at 07:46:52PM +0100, Wilfred Hughes wrote:
+def assertNotRaises(self, excClass, callableObj=None, *args, **kwargs):
+"""Fail if an exception of class excClass is thrown by
+callableObj when invoked with arguments args and keyword
+
Victor Stinner wrote:
Hum, copy-paste failure, I wrote numbers in the wrong order, it's:
(test: Python 3.2 => Python 3.3)
"A".join(["Bob"]*100)): 0.92 => 2.11
("C"+"AB"*300).rfind("CA"): 0.57 => 1.03
("A" + ("Z"*128*1024)).replace("A", "BB", 1): 0.25 => 0.50
I improved str.replace(): it's now 5
Cameron Simpson wrote:
On 06Oct2011 04:26, Glyph wrote:
| On Oct 5, 2011, at 10:46 PM, Cameron Simpson wrote:
| > Surely VERY FEW tests need to be run as root, and they need careful
| > consideration. The whole thing (build, full test suite) should
| > not run as root.
|
| This is news to me -
Antoine Pitrou wrote:
In CPython, looking for reference cycles is a parasitic task that
interferes with what you are trying to measure. It is not critical in
any way, and you can schedule it much less often if it takes too much
CPU, without any really adverse consequences. timeit takes the safe w
Xavier Morel wrote:
Not being too eager to kill APIs is good, but giving rise to this kind of
living-dead APIs is no better in my opinion, even more so since Python has
lost one of the few tools it had to manage them (as DeprecationWarning was
silenced by default). Both choices are harmful to us
Guido van Rossum wrote:
Point of order (repeated), please move this thread to python-ideas.
Isn't that cruel to the people reading python-ideas?
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
Terry Reedy wrote:
On 12/9/2011 5:17 AM, Nick Coghlan wrote:
As Chris pointed out though, the real problem with the "repeatedly run
2to3" workflow is that it can make interpreting tracebacks from the
field *really* hard.
This just gave me the idea of tagging tracebacks with the Python version
Greg Ewing wrote:
Matt Joiner wrote:
ಠ_ಠ
What's up with these ?_? messages?
I think that, depending on the typeface you view it with, it is supposed to be
some sort of smiley: two big wide open square eyes with tightly pursed lips.
Presumably it is supposed to be a look of shock and surpr
Steven D'Aprano wrote:
Greg Ewing wrote:
Matt Joiner wrote:
ಠ_ಠ
What's up with these ?_? messages?
I think that, depending on the typeface you view it with, it is supposed
to be some sort of smiley: two big wide open square eyes with tightly
pursed lips. Presumably it is supp
Jim Jewett wrote:
My personal opinion is that accepting *and parsing* enough data for
this to be a problem
is enough of an edge case that I don't want normal dicts slowed down
at all for this; I would
therefore prefer that the change be restricted to such a compile-time
switch, with current beha
Christian Heimes wrote:
[...]
I propose an addition to the current Python C API:
int PyOS_URandom(char *buf, Py_ssize_t len)
Read "len" chars from the OS's RNG into the pre-allocated buffer "buf".
The RNG should be suitable for cryptography.
Since some platforms may not have /dev/urandom, we
David Malcolm wrote:
When backporting the fix to ancient python versions, I'm inclined to
turn the change *off* by default, requiring the change to be enabled via
an environment variable: I want to avoid breaking existing code, even if
such code is technically relying on non-guaranteed behavior.
Benjamin Peterson wrote:
2012/1/5 Nick Coghlan :
On Fri, Jan 6, 2012 at 10:07 AM, Steven D'Aprano wrote:
Surely the way to verify the behaviour is to run this from the shell:
python -c print(hash("abcde"))
twice, and see that the calls return different values. (Or have I
mi
Benjamin Peterson wrote:
2012/1/5 Steven D'Aprano :
[...]
There's nothing obscure about directly testing the hash. That's about as far
from obscure as it is possible to get: you are directly testing the presence
of a feature by testing the feature.
It's obscure because h
Glenn Linderman wrote:
On 1/5/2012 5:52 PM, Steven D'Aprano wrote:
At some point, presuming that there is no speed penalty, the behaviour
will surely become not just enabled by default but mandatory. Python
has never promised that hashes must be predictable or consistent, so
apart
Victor Stinner wrote:
-if os.name in ('nt', 'os2'):
+if os.name in ('nt'):
This change is wrong: it should be os.name == 'nt'.
Or possibly os.name in ('nt', ) (note the comma).
--
Steven
___
Python-Dev mailing list
Python-Dev@pyth
On 14/01/12 12:58, Gregory P. Smith wrote:
I do like *randomly seeding the hash*. *+1*. This is easy. It can easily be
back ported to any Python version.
It is perfectly okay to break existing users who had anything depending on
ordering of internal hash tables. Their code was already broken.
Victor Stinner wrote:
- Marc Andre Lemburg proposes to fix the vulnerability directly in
dict (for any key type). The patch raises an exception if a lookup
causes more than 1000 collisions.
Am I missing something? How does this fix the vulnerability? It seems to me
that the only thing this d
Guido van Rossum wrote:
On Fri, Jan 13, 2012 at 5:58 PM, Gregory P. Smith wrote:
It is perfectly okay to break existing users who had anything depending on
ordering of internal hash tables. Their code was already broken. We
*will*provide a flag and/or environment variable that can be set to t
python wrote:
jbk
[snip 560+ lines of quoted text]
Please delete irrelevant text when replying to digests, and replace the
subject line with a meaningful subject.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
Antoine Pitrou wrote:
Le jeudi 19 janvier 2012 à 00:25 +0900, Stephen J. Turnbull a écrit :
> You claim people won't use stable releases because of not enough
> alphas? That sounds completely unrelated.
Surely testing is related to user perceptions of stability. More
testing helps reduce bu
Brett Cannon wrote:
And honestly, if we don't go with this I'm with Georg's comment in another
email of beginning to consider stripping the stdlib down to core libraries
to help stop with the bitrot (sorry, Paul). If we can't attract new
replacements for modules we can't ditch because of backwar
Victor Stinner wrote:
The last solution is very simple: count collision and raise an
exception if it hits a limit. ...
According to my basic tests, a limit of 35 collisions
requires a dictionary with more than 10,000,000 integer keys to raise
an error. I am not talking about the attack, but vali
Benjamin Peterson wrote:
2012/1/20 Terry Reedy :
Since 'raise' means 're-raise the current error', 'raise as OtherError'
means (clearly to me, anyway) 're-raise the current error as OtherError'.
That doesn't make any sense. You're changing the exception completely
not reraising it.
I expect
Guido van Rossum wrote:
On Fri, Jan 20, 2012 at 11:51 AM, Donald Stufft wrote:
On Friday, January 20, 2012 at 2:36 PM, Tres Seaver wrote:
On 01/20/2012 02:04 PM, Donald Stufft wrote:
Even if a MemoryException is raised I believe that is still a
fundamental change in the documented contract o
Terry Reedy wrote:
On 1/20/2012 11:17 AM, Victor Stinner wrote:
There is no perfect solutions, drawbacks of each solution should be
compared.
Amen.
One possible attack that has been described for a collision counting
dict depends on knowing precisely the trigger point. So let
MAXCOLLISIONS
Guido van Rossum wrote:
It should derive from BaseException.
RuntimeError meets that requirement, and it is an existing exception so there
are no issues with introducing a new built-in exception to a point release.
py> issubclass(RuntimeError, BaseException)
True
--
Steven
Ethan Furman wrote:
The question I have at the moment is: should `raise as` be an error if
no exception is currently being handled?
I think so.
"raise as Spam" essentially means "raise Spam with the context set to None".
That's actually only useful if the context otherwise wouldn't be None,
Paul McMillan wrote:
On Sat, Jan 21, 2012 at 4:19 PM, Jared Grubb wrote:
I agree; it sounds really odd to throw an exception since nothing is actually
wrong and there's nothing the caller would do about it to recover anyway.
Rather than throwing an exception, maybe you just reseed the random
Eli Bendersky wrote:
Hello,
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome.
I think you need to emphasize that modules in __preview__ are NOT expected to
have a forward-compatible, stable, API. This is a featu
1301 - 1400 of 1539 matches
Mail list logo
