On 4/4/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
Oh, goodie, a segmentation fault. Let's see if I can reproduce it ;PAnd so I could. test_banana.CananaTestCase.testCrashNegativeLong crashes, because it calls PyString_AsStringAndSize() with an int-ptr as second argument (an a
On 4/4/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Thomas Wouters wrote:> And so I could. test_banana.CananaTestCase.testCrashNegativeLong> crashes, because it calls PyString_AsStringAndSize() with an int-ptr as> second argument (an adjacent ptr variable becomes gar
entTree as ElementTree
and of course combined with explicit-relative imports:from .custometree or xml.etree or elementtree import cElementTree or ElementTree as ETor is that all going too far? :)-- Thomas Wouters <
[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into y
d, but it's probably easier to make the IMPORT_NAME (and possibly IMPORT_FROM) opcodes take more names from the stack, and do it all in the C code for the opcodes. And __import__ could be changed to accept a sequence of modules (it takes keyword arguments now, anyway. ;)
-- Thomas Wouters <[E
the latter problems are fixable, but the former should be fixed by passing the argument to ValueError through repr(), I think. It's also been suggested (by the reporter, and I agree) that the actual base should be in the errormessage too. Is there some reason not to do this that I've over
oredumpsize and check to see what it crashes on?
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
It's wasn't added in 2.5 or 2.4, though, so it's not particularly new and I can't guarantee that it's not used in any third party code. But, then again, anyone using it isn't free of leaks. Should removing or renaming it be done in
2.5 or in Py3K?Triple-negative'
:-)
Not with -uall, yes. Without -uall it ran fine (by chance, I admit.) I
didn't feel like running the rather lengthy -uall test on my box right
before bedtime; I won't be skipping that again anytime soon ;)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy m
laced that with "finding the generator-cleanup crash Tim encountered" :-) I don't know if I'll get to it this weekend, though, so if anyone else wants to hunt for it, don't let me stop you.
-- Thomas Wouters <[EMAIL PROTEC
't the case. It should do it that way, I believe, but it's not the cause of this crash.)
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Py
On 4/15/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
(I first thought the problem was caused by gen_dealloc doing 'Py_DECREF(gen->gen_frame)' instead of 'frame = gen->gen_frame; gen->gen_frame = NULL; Py_DECREF(frame)', but that isn't the case. It should
d newish tcl/tk. At least in kernel/libc land, various thread related things changed of late. I don't have access to other machines with tcl/tk right now, but I wonder if anyone can reproduce this in different situations.
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature vi
On 4/16/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
test_threading_local is not entirely consistent, but it looks a lot more reliable on my box than on Neal's automated mails:test_threading_localbeginning 11 repetitions12345678901
...
test_threading_local leaked [34, 34, 34,
e it will break in the future, I suggest it gets fixed. It *looks* like renaming the _MultibyteStreamWriter attribute is the easiest solution, but I don't know which API has precedence. (One of the two was added fairly recently, at least, since it didn't break in the p3yk branch until I m
good thing. :)
Should this be fixed, or is it an esoteric enough case that I shouldn't bother?-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
e can step in and fix it. (It looks like SF auto-assigned it to Martin already, hmm.)
http://sourceforge.net/tracker/index.php?func=detail&aid=1475162&group_id=5470&atid=105470
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to h
st program:#include #include <
tk.h>int main(void) {Tcl_Interp *trp;unsetenv("DISPLAY");trp = Tcl_CreateInterp();printf("%d\n", Tk_Init(trp));printf("%d\n", Tk_Init(trp));
return 0;}Yes, this C snippet locks up on my systems, just as the python
in test_mmap.) But other than that, anyone object to committing this to the trunk (not sandbox)? The tests *are* run by default, but only with very small limits (so they'll use less memory than most of the tests), to make sure the tests do function.
-- Thomas Wouters <[EMAIL PROTECTED]>
be last-minuted into beta1 too.) That should fix both Google's problems and that of everyone having existing non-package subdirs :-) Then, if it really matters, we can change the import in
2.6.Note that absolute import (which will be turned on for all in 2.6)
2.7, see the PEP. -- Thomas Wouters &
if if-else is your decision, if-else is what we'll do. And so it is, I believe, with this case.
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing li
On 4/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 4/26/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:>>> On 4/26/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > OK, forget it. I'll face the pitchforks.>>> Maybe this'll help:>>
On 4/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
Alrighty then. The list has about 12 hours to convince me (and you) that it's a bad idea to generate that warning. I'll be asleep by the time the trunk un-freezes, and I have a string of early meetings tomorrow. I'll get t
end. You can't be serious. One package just to install a __init__.py file?Sure. Have you counted the number of 'empty' packages in Debian lately? Besides, Guido's original proposal is not a fix for your problem, either; he only proposes to change
oo/__init__.py for your namespace to work, it just makes foo/bar/__init__.py and foo/zbr/__init__.py optional.
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-De
pful hint from an old-timer who remembers as far back as Modules/Setup would be welcome. :)
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev
and I believe that's Guido's desire, too. Otherwise, he would've asked me to make the warning a FutureWarning, instead. (Which could of course still happen.)
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .
I have the impression Talin wants to implement it himself, but even if he doesn't, I'm sure I'll have a free week somewhere in the next year and a half in which I can implement it :) It's not that hard a problem, it just requires a lot of reading of the AST and function-call code (i
fferent values for time.time() even if they run on the same computerand at the same time.As long as the value returned by time.time
() is still 'seconds', and everything in the time and datetime modules properly considers the same epoch, I would say it's a bug (for third-party m
f.failUnlessEqual(pythonapi.PyInt_FromLong
(42), 42)(Untested, since I can't reproduce, but I think I have it right.)-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Pyth
On 5/9/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
Thomas Wouters wrote:> On 5/8/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:>>> test_ctypes>> test test_ctypes failed -- Traceback (most recent call last):
>> File "/home/neal/python/trunk/Lib/ctype
; as an attribute, and it really ought to be a Py_ssize_t struct member (instead of the long it is now.)
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Py
means people get their hands on a beta -- good testing material -- that much sooner.
An acceptable (to me) alternative would be to skip alpha3. The biggest change is Martin's rewrite of various os.* methods, which IMHO isn't really that big a deal (it's not *supposed* to change too many s
the alphas even less important. Wetting the appetites and soliciting feedback on the major features is what they're for, in my eyes.
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
you move into the beta stage all you
do is fix bugs.Note that the problem isn't 'post-alpha', it's 'post-beta' -- new features (especially minor or long-agreed-upon) are fine up until beta1 ;)-- Thomas Wouters <
[EMAIL PROTECTED]>Hi! I'm a .signature
a particular value is a platform-dependant accident anyway (people seem to be ignoring 64-bit hardware all the time... I know Tim does :)
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
test added ;) but I'm also wondering if zlib shouldn't be fixed. Now, I'm AMD64-centric, so my suggested fix would be to change the PyInt_FromLong() call to PyLong_FromUnsignedLong(), making zlib always return positive numbers -- it might break some code on 32-bit platforms, but that c
ing and an int, i think01:00 oh well, i guess sean and richard know what they changed...Does 'a tuple containing two Nones, a string and an int' ring a bell to anyone? :)
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature fil
which can cause crashes for the simplest of reasons ;-)
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
On 5/29/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
On May 28, 2006, at 4:31 AM, Thomas Wouters wrote:>> I'm seeing a dubious failure of test_gzip and test_tarfile on my> AMD64 machine. It's triggered by the recent struct changes, but I'd> say it's probably ca
efore this change, you didn't have to check whether the value is negative before the struct.unpack/pack dance, regardless of which format character you used. This misfeature is used (and many would consider it convenient, even Pythonic, for struct to DWIM), breaking it suddenly is bad.
-- Thoma
would be untrue then.)
On the other hand, if a separate type was used for PyInts (Py_pyint_t or whatever, defaulting to long, except on LLP64 systems), EWT's request for a 64-bit integer represented by C 'long long's would be a simple configure switch.
-- Thomas Wouters <[EMAI
warning to tell people to fix their code 'or else'. The prevalence of the warnings (outside of the stdlib) should give us a clue whether to make it an exception in
2.6 or wait for 2.7/3.0.Perhaps more people could chime in? Am I being too anal about backward compatibility here?-- Thomas W
odes. It doesn't have to be more liberal than 2.4 (and preferably shouldn't, as that could break backward compatibility of some code -- much less common, though.)Making a list of which formatcodes accept what values (for what valuetypes) for
2.4 is easy enough (and should be added to
is minor case is just overkill. (The C compile-time warning would be useful in other cases, too... hmm, perhaps we can do some post-processing of .o files, looking for deprecated symbols left undefined...)
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .
On 5/29/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
Thomas Wouters wrote:> I know which 'it' I meant: the same 'it' as struct already accepts in> Python 2.4 and before. Yes, it's inconsistent between formatcodes and> valuetypes -- fixing that the whole poi
this is way out of scope for 2.5. Guido said it is okto change this to 64-bit ints in 2.6, but I expect some embeddedsystem developers will start screaming when they hear that: 64-bitarithmetic is expensive on a 32-bit machine.
Well, those systems shouldn't have a 64-bit Py_ssize_t anyway,
3yk branch and forget about
2.x; gives people all the more reason to switch, two years from now.-- Thomas Wouters <
[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing
you can very easily emulate the unittest API with py.test ;-)Since there's time for
2.6, I'd encourage everyone to look at py.test, maybe we can just merge it with unittest ;P-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file
On 6/4/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
"Thomas Wouters" <[EMAIL PROTECTED]> writes:> On 6/4/06, Michael Hudson <[EMAIL PROTECTED]> wrote:> [ For non-checkins readers: Martin Blais checked in un-unittestification
> of test_struct, which spawned que
On 6/4/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
On 6/4/06, Michael Hudson <
[EMAIL PROTECTED]> wrote:I don't want to pull the 'do you know who I am?' routine, and I know
you're addressing python-dev rather than just me, but I'm currentlysitting in the s
lse does, though.) It may be a good idea to check for more such cornercases while we're at it (but I couldn't find any in the fast-locals bit.)-- Thomas Wouters <
[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
__
t, not if I use the same compile options for 2.5 as for 2.4... ;-)-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev@python.org
http:
how a 10-20% speedup of your testcase in 2.5 compared to 2.4. 3.3 showed a 10% slowdown or so.Test-more'ly y'rs,-- Thomas Wouters <[EMAIL PROTECTED]
>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
__
nsive tests, though (I'd have to make sure the machine is unloaded for a much longer period of time, and I don't have the time :)
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
__
ll it "slow"; just let it be documented as 'might not always work and might be inefficient', so there's room to make it the perfect and preferred way to get a MAC address without having to rename it. (Not that I think that's a reliable prospect, but hey ;)
-- Thomas Wouter
ot; for more information.>>> quit()Traceback (most recent call last):
File "", line 1, in ?TypeError: 'str' object is not callable>>> centurion:~/python/python/trunk > ./pythonPython 2.5a2 (trunk:46753, Jun 8 2006, 17:46:46)
[GCC 4.1.2
them. I can draw huge ASCII diagrams explaining the fundamental difference between CVS/SVN, BitKeeper/Arch/Darcs/Bazaar-NG/Mercurial and Monotone (yes, that's three groups), and I have powerpoint(!) sheets I used to give a presentation about how and why BitKeeper works at work. It's probably a
On 6/13/06, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
On Mon, Jun 12, 2006 at 11:31:14PM +0200, Thomas Wouters wrote:> First of all, changing SCM means changing how everyone works. Distributed branches is not the only requirement. Oh, I know, no worries about that.
There are also:-
python-3000 only.)
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
0, tp_name = 0x53d15a "EncodingMap", tp_basicsize = 80,
[...]Did someone forget a PyType_Ready() call when EncodingMap was added? (And what other types are missing PyType_Ready() calls? :)-- Thomas Wouters <[EMAIL PROTECTED]
>Hi! I'm a .signature virus! copy me i
;for real' in a directory that won't generate checkins to python-checkins ;)
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev@pyth
etail (and furthermore, the actual limit is just guessed.) It's not like a real solution is impossible, it's just very complex. Much like, say,
restricted execution :-)-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! cop
or what not) will actively be inhibiting the acceptance of
the new names ;)
This is all much less the case with stdlib modules, I guess, and I see no
real objection to making those conform to PEP 8.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into yo
tines in fileobject.c take
pretty good care not to read too much, and I choose to see that as
explicitly designed that way.)
Absent-ly y'rs,
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .sign
e, but I don't think
those people deserve to get the full force of Tim's optimizations either.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mai
f.' (e.g. @foo): loses readability, wins too little
- '?' and other non-alphanumerical characters in identifiers: like sigils
- strict private/public accessing: 'fake' protection; use closures instead
etc. No need to come up with them all, I'm sure all the prize ideas will
: 13.10
>loop_class: 17.11
The main difference isn't the lookup of 'self', it's the attribute retrieval
of 'x' from 'self'.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help
On Sun, Jan 08, 2006 at 08:09:22AM -0800, Ralf W. Grosse-Kunstleve wrote:
> --- Thomas Wouters <[EMAIL PROTECTED]> wrote:
> > The main difference isn't the lookup of 'self', it's the attribute retrieval
> > of 'x' from 'self'.
>
On Sun, Jan 08, 2006 at 01:35:16PM +0100, "Martin v. Löwis" wrote:
> Thomas Wouters wrote:
> > Yet if it isn't recorded, people will keep bringing it up. How about a
> > 'rejected ideas' PEP for ideas that are right out no matter how people
> > argue?
On Sun, Jan 08, 2006 at 06:31:35PM +0100, "Martin v. Löwis" wrote:
> Thomas Wouters wrote:
> > My point isn't that it isn't archived somewhere (mailinglists, wiki, FAQ,
> > the minds of many, many people, not just Python developers) but that it
> >
not sure what's wrong about the
editorialization, but perhaps I'm just too insensitive towards functional
programming disciples. And I'm usually quite in tune with sensitive minds.
But we can discuss that off-list ;)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .sig
e discussion), upgrading the Python parser
beyond a simple LL(1), and maybe implicit ()'s for functioncalls, if I feel
inspired. The exact wording, and additional rejects, can be discussed at
length by those interested.
--
Thomas Wouters <[E
d response to most of these harebrained tricks, but it
does put a lie to the 'uncrashable python' idea :)
Not-for-or-against-including-ctypes-anyway'ly y'rs,
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me
and cPickle (and
pickle, too!), when feeding invalid input. Those modules are more in the
awkward-foot-angle terrain for me, though.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
__
d the issue (there was no actual need to subclass, there), and I have
no idea whether that specific issue was solved or not, but I'm trying to
find it again :)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me sprea
On Wed, Jan 11, 2006 at 02:54:40PM +0100, Thomas Wouters wrote:
> The pickle vulnerability came up last year, when someone on #python was
> subclassing a builtin type (string or dict, I think the latter) that was
> using a magical invocation of (IIRC) __new__ on unpickle. The subclassed
. String
representations of integers -- and indeed, numbers in general, as the Python
tutorial explains in Appendix B -- have a base. Adding such a method to
integers (and, I presume, longs) would beg the question why floats, Decimals
and complex numbers don't have them.
In-favour-of-%2b-ly y&#
e rms and his
laywers wanted, but that itself doesn't make the license GPL-compatible. It
apparently allows derived works from being GPL-compatible, though. 2.0 and
2.1 derive from 1.6, but 2.0.1 and 2.1.1 derive from 1.6.1.
I'm sure it makes sense to someone.
Go-figure'ly y'rs,
espite the
specialcasing of numbers,) I don't mind either. I do mind names like
'to_base' or 'as_str' or 'shouldbestr' or other names that make me turn on
autocompletion in my editor.
> Alternatively, a name like "to_base" that clarifies the intent and is l
On Fri, Jan 20, 2006 at 06:56:23AM +1000, Nick Coghlan wrote:
> I'm not aware of anyone that would miss octal literals,
Except anyone who uses os.chmod. I would be mighty sad if we removed octal
and hexadecimal literals for 'cleanliness' reasons alone.
--
Thomas Wouters <[
g
TestCase in this way, while convenient, isn't important enough to warrant
this (IMHO).
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-
x myself.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
'll do some googling and browsing other
tty/pty-using code to see if there's anything we're not doing we should be
doing, but it looks like a platform bug that we can't fix... Not without
re-implementing os.isatty anyway ;P
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'
u an account to the machine the buildbot
> runs on.
I think I've seen enough confusing situations for a while... I'm sure the
bug is the same on Solaris 10 ;P
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me sp
support for ducktyping than showcase subclassing ;)
But perhaps I've missed that single, all-convincing argument that it has use
subclassing... In that case, could it be added to the PEP? :)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signat
rg/pipermail/python-dev/2006-January/059938.html
was never responded to. And licenses are fluid, it may be a piece of cake to
get one of those 'tools' un-GPL'ed, even if they are.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy m
On Thu, Jan 26, 2006 at 09:26:27AM +, Michael Hoffman wrote:
> [Thomas Wouters]
> > [Subclassing string] is my only problem with the PEP. It's all very nice
> > that subclassing from string makes it easier not to break things, but
> > subclassing implies a certain re
. Most
posixmodule functions, by the looks of it, as well as a few in _tkinter and
socket. And that's just a quick grep for PyArg_Parse* with '"et' as an
argument. Perhaps if __open__ was generalized into __equivalent_string__...
but we've been there already. ;)
--
Thomas Wouters
On Wed, Jan 25, 2006 at 01:59:18AM +0100, Thomas Wouters wrote:
> [ iffy isatty behaviour on Solaris ]
Considering that:
- the approach for opening pty's, while not the only one, is the preferred
way of doing it on Solaris,
- the actual pty's seem to be completely functional,
On Thu, Jan 26, 2006 at 09:41:53PM -0500, Tim Peters wrote:
> [Thomas Wouters]
> > ...
> > I'd need developer access back to check it in, though.
> AFAICT, twouters has developer access to the Python project --
> although maybe someone else re-enabled that w/o mentio
eal download URL for ZODB
> .
>
> Overall I'm not sure that's an improvement, but it was the best I
> could come up with 2 years ago when ZODB stopped using SF for
> downloads.
What if the package wasn't named README, but rather
'www.python.org' with a relea
pects,
like iteration, and those are argued on both sides of the subclassing camp.
The question is whether they should be actual subclasses of the Python
string type. As for what platforms do, if we want to stick to the platform
handling of paths, we change nothing. That's apparently not what
was clear that the resulting binary (of non-GPL-compatible source
and a GPL library) was a GPL violation, but the source itself was not.
Not that they can't change their minds, of course. But I wouldn't go and ask
them if they changed their minds yet; it might make them ;P
--
Thomas
agree,) and it doesn't look like doing so, by initializing
the variables, wouldn't be too big a performance hit.
I also noticed test_logging is spuriously failing, and not just on my
machine (according to buildbot logs.) Is anyone (Vinay?) looking at that
yet?
--
Thomas Wouters <[EMAIL
On Tue, Jan 31, 2006 at 06:04:45PM +0100, "Martin v. Löwis" wrote:
> Thomas Wouters wrote:
> > I also noticed test_logging is spuriously failing, and not just on my
> > machine (according to buildbot logs.) Is anyone (Vinay?) looking at that
> > yet?
> I looked a
On Tue, Jan 31, 2006 at 09:04:39PM +0100, "Martin v. Löwis" wrote:
> Thomas Wouters wrote:
> > All in all, it seems like a timing issue -- the timing is different because
> > the previous test already imported some modules. The test_logging test uses
> > threads, *u
ak, and the switch is directly followed by a set of the nchannels
output parameter. The only way through the switch is through the set of
ssize. I understand the compiler doesn't "see" it this way, but who knows
for how long :)
I guess we ignore this until we're closer to
the 'no warnings' policy or
the flags to gcc, or add a 'known spurious warnings' checking thing to the
buildbot.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
__
On Wed, Feb 01, 2006 at 11:29:16AM -0500, Tim Peters wrote:
> [Thomas Wouters]
> > Well, I said 4.0.3, and that was wrong. It's actually a pre-release of 4.0.3
> > (in Debian's 'unstable' distribution.) However, 4.0.2 (the actual release)
> > behaves th
t;
> and then add:
>
> assert(e >= 0);
>
> after the call.
Done, although it was nowhere near obvious to me that -1 would be a sane
sentinel value ;) Not that I don't believe you, but it took some actual
reading of _PyLong_AsScaledDouble to confirm it.
Reading-
301 - 400 of 417 matches
Mail list logo
