Nick Coghlan wrote:
>> One thing that actually can motivate that test_subprocess takes 20% of the
>> overall time is that this test is a good generic Python stress test - this
>> test might catch some other startup race condition, for example.
>
> test_decimal has a short version which tests basic
Raymond Hettinger wrote:
> > but refactoring the contains code to use find_internal sounds like a good
> > first step. any takers?
>
> I'm up for it.
excellent!
just fyi, unless my benchmark is mistaken, the Unicode implementation has
the same problem:
str in -> 25.8 µsec per loop
unico
Raymond Hettinger wrote:
> Based on some ideas from Skip, I had tried transforming the likes of "x
> in (1,2,3)" into "x in frozenset([1,2,3])". When applicable, it
> substantially simplified the generated code and converted the O(n)
> lookup into an O(1) step. There were substantial savings eve
Phillip J. Eby wrote:
>>Only contains expressions are translated:
>>
>> "if x in [1,2,3]"
>>
>>currently turns into:
>>
>> "if x in (1,2,3)"
>>
>>and I'm proposing that it go one step further:
>>
>> "if x in Seachset([1,2,3])"
>
> ISTM that whenever I use a constant in-list like that,
Phillip J. Eby wrote:
> Were these timings done with the code that turns (1,2,3) into a constant?
I used a stock 2.4 from python.org, which seems to do this (for tuples,
not for lists).
> Also, I presume that these timings still include extra LOAD_FAST operations
> that could be replaced
> wit
Phillip J. Eby wrote:
>>here's the disassembly:
>
> FYI, that's not a dissassembly of what timeit was actually timing; see
> 'template' in timeit.py.
> As a practical matter, the only difference would probably be the use of
> LOAD_FAST instead of
> LOAD_NAME, as
> timeit runs the code in a fun
Tim Peters wrote:
> [Fredrik Lundh]
>> wouldn't be the first time...
>
> How soon we forget .
oh, that was in the dark ages of Python 1.4. I've rebooted myself many times
since
then...
> Fredrik introduced a pile of optimizations special-casing the snot out
> o
Donovan Baarda wrote:
> Apparently lawyers have decided that you can't give code away. Intellectual
> charity is illegal :-)
what else would a lawyer say? do you really expect lawyers to admit that there
are ways to do things that don't involve lawyers?
Martin v. Löwis wrote:
>> I'd say that this explains why it would still make sense to let the code
>> generator change
>> "x in (a, b, c)" to "x == a or x == b or x == c", as long as a, b, and c are
>> all integers.
>
> How often does that happen in real code?
don't know, but it happens:
[EMAI
Raymond Hettinger wrote:
> I used those addresses and sent notes to everyone who hasn't made a
> recent checkin.
where recent obviously was defined as "after 2.4" for checkins, and "last week"
for tracker activities.
python-dev was a lot more fun in the old days.
__
Scott David Daniels wrote:
> What should marshal / unmarshal do with floating point NaNs (the case we
> are worrying about is Infinity) ? The current behavior is not perfect.
>
> Michael Spencer chased down a supposed "Idle" problem to (on Win2k):
> marshal.dumps(1e1) == 'f\x061.#INF'
>
<[EMAIL PROTECTED]> wrote:
> (ie. the re library only returns the ~last~ match for named groups - not
> a list of ~all~ the matches for the named groups. And the hierarchy of
those named groups is non-existant in the flat dictionary of matches
> that results. )
are you 100% sure that this can b
Tim Peters wrote:
> All Python behavior in the presence of a NaN, infinity, or signed zero
> is a platform-dependent accident. This is because C89 has no such
> concepts, and Python is written to the C89 standard. It's not easy to
> fix across all platforms (because there is no portable way to d
Skip Montanaro wrote:
> Are float("inf") and float("nan") supported everywhere?
nope.
>>> float("inf")
Traceback (most recent call last):
File "", line 1, in ?
ValueError: invalid literal for float(): inf
>>> float("nan")
Traceback (most recent call last):
File "", line 1, in ?
ValueError: i
> pickle doesn't have the INF=>1.0 bug:
>
import pickle
pickle.loads(pickle.dumps(1e1))
> ...
> ValueError: invalid literal for float(): 1.#INF
>
import cPickle
cPickle.loads(cPickle.dumps(1e1))
> ...
> ValueError: could not convert string to float
>
import marshal
Ka-Ping wrote:
> counter = Counter()
> readonly_facet = facet(counter, ['value'])
>
> If i've done this correctly, it should be impossible to alter the
> contents of the list or the counter, given only the immutable_facet
> or the readonly_facet, after restrict() has been called.
I'm prob
Scott David Daniels wrote:
> From yesterday's sprint
sprint? I was beginning to wonder why nobody cared about this;
guess I missed the announcement ;-)
> At the least a change like this will catch the unpacking:
> in marshal.c (around line 500) in function r_object:
> PyFPE_START_PROTECT("ato
Tim Peters wrote:
> marshal shouldn't be representing doubles as decimal strings to begin
> with. All code for (de)serialing C doubles should go thru
> _PyFloat_Pack8() and _PyFloat_Unpack8(). cPickle (proto >= 1) and
> struct (std mode) already do; marshal is the oddball.
is changing the marsh
Tim Peters wrote:
> [Fredrik Lundh]
>> is changing the marshal format really the right thing to do at this
>> point?
>
> I don't see anything special about "this point" -- it's just sometime
> between 2.4.1 and 2.5a0. What do you have in mind?
I was
Bob Ippolito wrote:
> It might be worth mentioning that if/when subversion is used to replace CVS,
> unified diffs are
> going to be the obvious way to do it, because I don't think that subversion
> supports context diffs
> without using an external diff command.
subversion? you meant bazaar
Brian Sabbey wrote:
In short, if doFoo is defined like:
def doFoo(func1, func2):
pass
You would be able to call it like:
doFoo(**):
def func1(a, b):
return a + b
def func2(c, d):
return c + d
That is, a suite can be used to define keyword arguments.
umm. isn't that just an
Brian Sabbey wrote:
If suites were commonly used as above to define properties, event handlers
and other callbacks, then I think most people would be able to comprehend
what the first example above is doing much more quickly than the second.
wonderful logic, there. good luck with your future adv
Guido van Rossum wrote:
This reflects a style pattern that I've come to appreciate more
recently:
what took you so long? ;-)
Why do people care about cluttering namespaces so much? I thought
thats' what namespaces were for -- to put stuff you want to remember
for a bit. A function's local namespace
Josiah Carlson wrote:
See the previous two discussions on thunks here on python-dev, and
notice how the only problem that seem bettered via blocks/thunks /in
Python/ are those which are of the form...
#setup
try:
block
finally:
#finalization
... and depending on the syntax, properties. I o
Shane Hathaway wrote:
Brian's suggestion makes the code read more like an outline. In Brian's
example, the high-level intent stands out from the details
that assumes that when you call a library function, the high-level intent of
*your* code is obvious from the function name in the library, and to
File "C:\Code\python\lib\test\test_csv.py", line 58, in _test_default_attrs
self.assertRaises(TypeError, delattr, obj.dialect, 'quoting')
File "C:\Code\python\lib\unittest.py", line 320, in failUnlessRaises
callableObj(*args, **kwargs)
AttributeError: attribute 'quoting' of '_csv.Dialect' o
Glyph Lefkowitz wrote:
> Despite being guilty of propagating this style for years myself, I have to
> disagree. Consider the
> following network-conversation using Twisted style (which, I might add, would
> be generalizable to
> other Twisted-like systems if they existed ;-)):
>
> def strawma
Josiah Carlson wrote:
> > for my purposes, I've found that the #1 callback killer in contemporary
> > Python
> > is for-in:s support for the iterator protocol:
> ...
> > and get shorter code that runs faster. (see cElementTree's iterparse for
> > an excellent example. for typical use cases, it'
Bob Ippolito wrote:
>>> def strawman(self):
>>> def sayGoodbye(mingleResult):
>>> def goAway(goodbyeResult):
>>> self.loseConnection()
>>> self.send("goodbye").addCallback(goAway)
>>> def mingle(helloResult):
>>> self.send("nice weather we're having").ad
Michael Chermside wrote:
There is one exception... matching strings. There we have a powerful
means of specifying patterns (regular expressions), and a multi-way
branch based on the content of a string is a common situation. A new
way to write this:
s = get_some_string_value()
if s == '':
Facundo Batista wrote:
Is there a document that details which objects are cached in memory
(to not create the same object multiple times, for performance)?
why do you think you need to know?
If not, could please somebody point me out where this is implemented
for strings?
Objects/stringobject.c (wh
Guido van Rossum wrote:
> At the same time, having to use it as follows:
>
> for f in with_file(filename):
< for line in f:
> print process(line)
>
> is really ugly, so we need new syntax, which also helps with keeping
> 'for' semantically backwards compatible. So let's use
Guido van Rossum wrote:
> I've written a PEP about this topic. It's PEP 340: Anonymous Block
> Statements (http://python.org/peps/pep-0340.html).
>
> Some highlights:
>
> - temporarily sidestepping the syntax by proposing 'block' instead of 'with'
> - __next__() argument simplified to StopIteratio
Phillip J. Eby wrote:
This interest is unrelated to anonymous blocks in any case; it's about
being able to simulate lightweight pseudo-threads ala Stackless, for use
with Twisted. I can do this now of course, but "yield expressions" as
described in PEP 340 would eliminate the need for the awkwa
Guido van Rossum wrote:
> Fredrik, what does your intuition tell you?
having been busy with other stuff for nearly a week, and seeing that the PEP is
now at
version 1.22, my intuition tells me that it's time to read the PEP again before
I have any
opinion on anything ;-)
_
Gustavo J. A. M. Carneiro wrote:
> I have not read every email about this subject, so sorry if this has
> already been mentioned.
>
> In PEP 340 I read:
>
> block EXPR1 as VAR1:
> BLOCK1
>
> I think it would be much clearer this (plus you save one keyword):
>
> bl
Thomas Heller wrote:
> AFAIK, you can configure Python to use 16-bits or 32-bits Unicode chars,
> independend from the size of wchar_t. The HAVE_USABLE_WCHAR_T macro
> can be used by extension writers to determine if Py_UNICODE is the same as
> wchar_t.
note that "usable" is more than just "same
Gustavo J. A. M. Carneiro wrote:
> In that case,
>
> block VAR1 in EXPR1:
> BLOCK1
>
> And now I see how using 'for' statements (perhaps slightly changed)
> turned up in the discussion.
you're moving through this discussion exactly backwards; the current
proposal stems from the
François Pinard wrote:
> It happens once in a while that I want to comment out the except clauses
> of a try statement, when I want the traceback of the inner raising, for
> debugging purposes. Syntax forces me to also comment the `try:' line,
> and indent out the lines following the `try:' line.
François Pinard wrote:
> > > f = None
> > > try:
> > > f = action1(...)
> > > ...
> > > finally:
> > > if f is not None:
> > > action2(f)
> > f = action1()
> > try:
> > ...
> > finally:
> > action2(f)
> > I can't see how this would ever do some
Guido van Rossum wrote:
> > (to save typing, you can use an empty string or even
> > put quotes around the exception name, but that may
> > make it harder to spot the change)
>
> Yeah, but that will stop working in Python 3.0.
well, I tend to remove my debugging hacks once I've fixed
the bug. I
Michael Hudson wrote:
> Looking at my above code, no (even though I think I've rendered the
> point moot...). Compare and contrast:
>
> @template
> def redirected_stdout(out):
> save_stdout = sys.stdout
> sys.stdout = out
>
> yield None
>
> sys.stdout = save_stdout
>
> class redir
Guido van Rossum wrote:
> PEP 340 redux
> =
>
> Syntax:
> do EXPR [as VAR]:
> BLOCK
>
> Translation:
> abc = EXPR
> [VAR =] abc.__enter__()
> try:
> BLOCK
> finally:
> abc.__exit__(*"sys.exc_info()") # Not exactly
>
> Pros:
> - can use a decorated generator as EXPR
> - sepa
Guido van Rossum wrote:
> I've written up the specs for my "PEP 340 redux" proposal as a
> separate PEP, PEP 343.
>
> http://python.org/peps/pep-0343.html
>
> Those who have been following the thread "Merging PEP 310 and PEP
> 340-redux?" will recognize my proposal in that thread, which received
>
Nick Coghlan wrote:
> I think the key benefit relates to the fact that correctly written resource
> management code currently has to be split it into two pieces - the first piece
> before the try block (e.g. 'lock.acquire()', 'f = open()'), and the latter in
> the finally clause (e.g. 'lock.releas
e
>> ElementTree is an unlikely addition to the standard library.
>
> Rewritten:
>
> If Fredrik Lundh were supportive of the idea, I think the Standard
> Library would benefit greatly from incorporating ElementTree.
shipping stable versions of ElementTree/cElementTree (or PIL,
> moving the main trunk and main development over to the Python CVS is
> another thing, entirely.
(as I've said many times before, both the user community and the developer
community would benefit if the core standard library were made smaller, and
more externally maintained packages were included
Gustavo Niemeyer wrote:
> > > moving the main trunk and main development over to the Python CVS is
> > > another thing, entirely.
> >
> > (as I've said many times before, both the user community and the developer
> > community would benefit if the core standard library were made smaller, and
> > m
Guido van Rossum wrote:
> (Now that I work for Google I realize more than ever before the
> importance of keeping URLs stable; PageRank(tm) numbers don't get
> transferred as quickly as contents. I have this worry too in the
> context of the python.org redesign; 301 permanent redirect is *not*
> g
Fred L. Drake, Jr. wrote:
> docs.python.org was created specifically to make searching the most recent
> "stable" version of the docs easier (using Google's site: modifier, no less).
> I don't know what the link count statistics say (other than what you
> mention), and don't know which gets hit mo
Georg Brandl wrote:
> If something like Fredrik's new doc system is adopted, it would be extremely
> convenient to refer someone to just
>
> docs.python.org/os.path.join
>
> without looking up how the page is actually named.
you could of course reserve a toplevel directory for that purpose; e.g.
Martin v. Löwis wrote:
> > - is (c)ElementTree still planned for inclusion ?
>
> It is included already.
in the xml.etree package, in case someone's looking for it in the
usual place.
that is,
import xml.etree.ElementTree as ET
import xml.etree.cElementTree as ET
will work in any 2.5
Georg Brandl wrote:
> If something like Fredrik's new doc system is adopted
don't hold your breath, by the way. it's clear that the current PSF-sponsored
site overhaul won't lead to anything remotely close to a best-of-breed python-
powered site, and I'm beginning to think that I should spend my
Guido van Rossum wrote:
> - it's probably too big to attempt to rush this into 2.5
After reading some of the discussion, and seen some of the arguments,
I'm beginning to feel that we need working code to get this right.
It would be nice if we could get a bytes() type into the first alpha, so
the
Thomas Wouters wrote:
> > After reading some of the discussion, and seen some of the arguments,
> > I'm beginning to feel that we need working code to get this right.
> >
> > It would be nice if we could get a bytes() type into the first alpha, so
> > the design can get some real-world exposure in
Tim Parkin wrote:
> As for cutting edge, it's using twisted, restructured text, nevow, clean
> urls, xhtml, semantic markup, css2, interfaces, adaption, eggs, the path
> module, moinmoin, yaml (to avoid xml),
that's not cutting edge, that's buzzword bingo.
> something I don't think I would be qu
Guido wrote:
> I'm actually assuming to put this off until 2.6 anyway.
makes sense.
(but will there be a 2.6? isn't it time to start hacking on 3.0?)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
(my mails to python-dev are bouncing; guess that's what you get when
you question the PSF's ability to build web sites... trying again.)
Neal Norwitz wrote:
> > (is the xmlplus/xmlcore issue still an issue, btw?)
>
> What issue are you talking about?
the changes described here
http://mail.
Talin wrote:
> So the general notion is similar to the various proposals on the Wiki -
> an inline keyword which serves the function of lambda. I chose the
> keyword "given" because it reminds me of math textbooks, e.g. "given x,
> solve for y". And I like the idea of syntactical structures that m
Paul Moore wrote:
> > I think most about everything has already been said wrt lambda already,
> > but I guess we could have a little war on spelling issues ;-)
>
> Agreed, but credit to Talin for actually implementing his suggestion.
> And it's nice to see that the AST makes this sort of experimen
> > (is the xmlplus/xmlcore issue still an issue, btw?)
>
> What issue are you talking about?
the changes described here
http://mail.python.org/pipermail/python-dev/2005-December/058710.html
"I'd like to propose that a new package be created in the standard library:
xmlcore."
which
Paul Moore wrote:
> > > I definately don't want to start a flame war, although I suspect I already
> > > have :/
> >
> > I think most about everything has already been said wrt lambda already,
> > but I guess we could have a little war on spelling issues ;-)
>
> Agreed, but credit to Talin for act
Barry Warsaw wrote:
> We know at least there will never be a 2.10, so I think we still have
> time.
because there's no way to count to 10 if you only have one digit?
we used to think that back when the gas price was just below 10 SEK/L,
but they found a way...
__
Adam Olsen wrote:
> While we're at it, any chance of renaming str/unicode to text in 3.0?
> It's a MUCH better name, as evidenced by the opentext/openbytes names.
> str is just some odd C-ism.
>
> Obviously it's a form of gratuitous breakage, but I think the long
> term benefits are enough that w
Aahz wrote:
> In all fairness to Tim (and despite the fact that emotionally I agree
> with you), the fact is that there had been essentially no forward motion
> on www.python.org redesign until he went to work. Even if we end up
> chucking out all his work in favor of something else, I'll conside
Guido van Rossum wrote:
> A bunch of Googlers were discussing the best way of doing the
> following (a common idiom when maintaining a dict of lists of values
> relating to a key, sometimes called a multimap):
>
> if key not in d: d[key] = []
> d[key].append(value)
/.../
> Feedback?
+1. ch
Michael Hudson wrote:
> > OTOH, even if we didn't rename str/unicode to text, opentext would
> > still be a good name for the function that opens a text file.
>
> Hnnrgh, not really. You're not opening a 'text', nor are you
> constructing something that might reasonably be called an 'opentext'.
Martin v. Löwis wrote:
> Also, I think has_key/in should return True if there is a default.
and keys should return all possible key values!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
Georg Brandl wrote:
> as Jim Jewett noted, multifile is supplanted by email as much as mimify etc.
> but it is not marked as deprecated. Should it be deprecated in 2.5?
-0.5 (gratuitous breakage).
I think the current "see also/supersedes" link is good enough.
__
Raymond Hettinger wrote:
> I would like to add something like this to the collections module, but a PEP
> is
> probably needed to deal with issues like:
frankly, now that Guido is working 50% on Python, do we really have to use
the full PEP process also for simple things like this?
I'd say we l
Nick Coghlan wrote:
> Using Guido's original example:
>
> d.get(key, [], True).append(value)
hmm. are you sure you didn't just reinvent setdefault ?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
Bengt Richter wrote:
> >> because there's no way to count to 10 if you only have one digit?
> >>
> >> we used to think that back when the gas price was just below 10 SEK/L,
> >> but they found a way...
> >>
> >IIRC Guido is on record as saying "There will be no Python 2.10 because
> >I hate the am
Terry Reedy wrote:
> > I'd say we let the BDFL roam free.
>
> PEPs are useful for question-answering purposes even after approval. The
> design phase can be cut short by simply posting the approved design doc.
not for trivialities. it'll take Guido more time to write a PEP than to
implement the
Georg Brandl wrote:
> I've just checked in some enhancements to the fileinput module.
>
> * fileno() to check the current file descriptor
> * mode argument to allow opening in universal newline mode
> * openhook argument to allow transparent opening of compressed
> or encoded files.
>
> Please f
Bob Ippolito wrote:
> Doesn't this discussion belong on c.l.p / python-list?
yes, please.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyth
Raymond Hettinger wrote:
> Like "autodict" could mean anything.
fwiw, the first google hit for "autodict" appears to be part of someone's
link farm
At this website we have assistance with autodict. In addition to
information for autodict we also have the best web sites concerning
dic
Raymond Hettinger wrote:
> Aside: Why on_missing() is an oddball among dict methods. When
> teaching dicts to beginner, all the methods are easily explainable ex-
> cept this one. You don't call this method directly, you only use it
> when subclassing, you have to override it to do anything use
Just van Rossum wrote:
> > If bytes support the buffer interface, we get another interesting
> > issue -- regular expressions over bytes. Brr.
>
> We already have that:
>
> >>> import re, array
> >>> re.search('\2', array.array('B', [1, 2, 3, 4])).group()
> array('B', [2])
> >>>
>
> Not su
M.-A. Lemburg wrote:
> Microsoft has recently released their express version of the Visual C++.
> Given that this version is free for everyone, wouldn't it make sense
> to ship Python 2.5 compiled with this version ?!
>
> http://msdn.microsoft.com/vstudio/express/default.aspx
>
> I suppose thi
> if I could chose, I'd use the same compiler for at least one more release...
to clarify, the guideline should be "does the new compiler version add some-
thing important ?", rather than just "is there a new version ?"
___
Python-Dev mailing list
P
Facundo Batista wrote:
> After a small talk with Raymond, yesterday in the breakfast, I
> proposed in PyAr the idea of start to translate the Library Reference.
>
> You'll agree with me that this is a BIG effort. But not only big, it's
> dynamic!
>
> So, we decided that we need a system that prov
(manually cross-posting from comp.lang.python)
Ben Cartwright wrote:
> Your evidence points to some unoptimized code in the underlying C
> implementation of Python. As such, this should probably go to the
> python-dev list (http://mail.python.org/mailman/listinfo/python-dev).
> This tactic typi
[EMAIL PROTECTED] wrote:
> > it's about time that someone sat down and merged the string and unicode
> > implementations into a single "stringlib" code base (see the SRE sources for
> > an efficient way to do this in plain C). [1]
> [...]
> > 1) anyone want me to start working on this ?
>
> This w
Greg Ewing wrote:
> Fredrik Lundh wrote:
>
> > moving to (basic) C++ might also be a good idea (in 3.0, perhaps). is any-
> > one still stuck with pure C89 these days ?
>
> Some of us actually *prefer* working with plain C
> when we have a choice, and don't cons
Guido van Rossum wrote:
> > Fredrik Lundh wrote:
> >
> > > > My personal goal in life right now is to stay as
> > > > far away from C++ as I can get.
> > >
> > > so what C compiler are you using ?
> >
> > Gcc, mostly. I don't
Thomas Wouters wrote:
> I added webstats for all subsites of python.org:
>
> http://www.python.org/webstats/
what's that "Java/1.4.2_03" user agent doing? (it's responsible for
10% of all hits in january/february, and 20% of the hits today...)
___
Tim Peters wrote:
> For simpler fun, run this silly little program, and look at memory
> consumption at the prompts:
>
> """
> x = []
> for i in xrange(100):
>x.append([])
> raw_input("full ")
> del x[:]
> raw_input("empty ")
> """
>
> For example, in a release build on WinXP, VM size is a
[EMAIL PROTECTED] wrote:
> I'm not saying Python 3 should be written in C++, I'm only saying
> that doing so would have not just disadvantages.
someone also pointed out in private mail (I think; it doesn't seem to
have made it to this list) that CPython's extensive use of "inheritance
by aggregat
[EMAIL PROTECTED] wrote:
> The docstring shows how to use it. Yet another Andrew Kuchling gem
> as I recall (or maybe an effbot gem).
amk, most likely.
and in 92.65% of all cases, switching from "regex" to "re" involves adding
\ in front of (, | and ) if they don't already have them, and removi
Guido van Rossum wrote:
> I don't see how adding featuers that nobody uses helps.
the amount of odd staticmethod uses you see on comp.lang.python
these days is staggering.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
Raymond Hettinger wrote:
> When teaching your classes, do you sense an aversion to using double
> underscore methods in regular code? I sense an implied message that
> these methods are not intended to be called directly (i.e. the discomfort
> of typing x.__setitem__(k,v) serves as a cue to write
Raymond Hettinger wrote:
> This conversation is getting goofy.
indeed.
let's pray that nobody that is considering picking up Python sees this
thread.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
Guido van Rossum wrote:
> > I don't think a change like this should go into a 2.4.x release. It
> > stands a very very high chance of breaking someone's code. I _could_
> > be convinced about a warning being emitted about it, though I'm not
> > going to have the time to figure out the new compiler
see subject and http://python.org/sf/1368955
comments ?
(note sure how my previous attempt to post this ended up on
comp.lang.python instead, but I'll blame it on gmane... ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Alex Martelli wrote:
> On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote:
> ...
> > I think that adding parentheses would help, by at least signalling
> > that the logic is longer than just the next (single) expression.
> >
> > level = (0 if "absolute_import" in self.futures else -1)
>
> +1 (ju
"fermigier" <[EMAIL PROTECTED]> wrote:
> "Perl had a defect density of only 0.186. In comparison Python had a
> defect density of 0.372 and PHP was actually above both the baseline and
> LAMP averages at 0.474."
>
> This is of course a PR stunt. But I'm wondering if the actual "bugs"
> list was tr
"fermigier" wrote:
> But I'm wondering if the actual "bugs" list was transmitted to Python
> developers,
> and verified / acted upon.
and in case it wasn't clear from my previous post, the answer to
your specific question is "yes" ;-)
___
Python-D
Neal Norwitz wrote:
> Their reports were high quality and accurate.
absolutely (which is why I'm surprised that someone's using the un-
reviewed numbers are a quality measure; guess I have to go back
and read the article to see who that was...)
> Of the false positives, it was difficult for the
Greg Ewing wrote:
> Fredrik Lundh wrote:
>
> > return=NULL; output=junk => out of memory
> > return=junk; output=-1 => cannot do this
> > return=pointer; output=value => did this, returned value bytes
>
> > I agree that the design is a bit que
Martin v. Löwis wrote:
> > On the other hand, the exploit could be crafted based on reading the SVN
> > check-ins ...
>
> Sure. However, at that point, the bug is fixed (atleast in SVN);
> crackers need to act comparatively fast then to exploit it. OTOH, if
> only the report was available, the pro
201 - 300 of 732 matches
Mail list logo
