On Fri, Apr 3, 2009 at 11:27, Antoine Pitrou wrote:
> Thomas Wouters python.org> writes:
> >
> >
> > Pystone is pretty much a useless benchmark. If it measures anything, it's
> the
> speed of the bytecode dispatcher (and it doesn't measure it particularly
;
> "...string iteration isn't about treating strings as sequences of strings,
> it's about treating strings as sequences of characters. The fact that
> characters are also strings is the reason we have problems, but characters
> are strings for other good reasons." -
ith fork(). I don't think
we should wait with fixing the big issue (making threads and fork() being
unnecessarily flakey) until we have a good fix for the small issue (a tiny
bit of a memory leak after a fork() -- in the child process only.)
Especially since the good fix for the small issue mig
On Mon, Jul 20, 2009 at 11:26, Mike Klaas wrote:
>
>
> On Thu, Jul 16, 2009 at 1:08 PM, Thomas Wouters wrote:
>
>>
>> Picking up a rather old discussion... We encountered this bug at Google
>> and I'm now "incentivized" to fix it.
>>
>> F
ead one) and the way
we blindly type-pun a pthread_t to a long, that I'm not sure I want to try
and build something correct and reliable on top of it.
--
Thomas Wouters
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
Index: Python/import.c
=
s
> are available again. That will probably not occur until Monday, maybe
> Tuesday.
I'm still waiting on a replacement controller, so it wasn't to be today.
Hopefully tomorrow, if the hardware supplier has one in stock. Still no
news on whether we have any chance at all o
On Mon, Aug 10, 2009 at 21:12, Thomas Wouters wrote:
>
>
> On Sat, Aug 8, 2009 at 22:22, A.M. Kuchling wrote:
>
>> The following sites are up again on a new machine, but cannot be
>> updated through SVN hooks or whatever mechanism:
>>
>> www.python.org
ldn't affect anyone.)
On Tue, Aug 11, 2009 at 07:26, Thomas Wouters wrote:
>
>
> On Mon, Aug 10, 2009 at 21:12, Thomas Wouters wrote:
>
>>
>>
>> On Sat, Aug 8, 2009 at 22:22, A.M. Kuchling wrote:
>>
>>> The following sites are up again on a new
On Sat, Jul 25, 2009 at 19:25, Gregory P. Smith wrote:
> On Thu, Jul 23, 2009 at 4:28 PM, Thomas Wouters wrote:
> >
> > So attached (and at http://codereview.appspot.com/96125/show ) is a
> > preliminary fix, correcting the problem with os.fork(), os.forkpty() and
> &g
On Wed, Sep 9, 2009 at 20:19, Gregory P. Smith wrote:
> On Wed, Sep 9, 2009 at 9:07 AM, Thomas Wouters wrote:
> >
> >
> > On Sat, Jul 25, 2009 at 19:25, Gregory P. Smith wrote:
> >>
> >> On Thu, Jul 23, 2009 at 4:28 PM, Thomas Wouters
> wro
On Fri, Sep 11, 2009 at 08:06, Cameron Simpson wrote:
> On 25Jul2009 10:25, Gregory P. Smith wrote:
> | On Thu, Jul 23, 2009 at 4:28 PM, Thomas Wouters
> wrote:
> | > So attached (and at http://codereview.appspot.com/96125/show ) is a
> | > preliminary fix, correcting the
On Wed, Sep 9, 2009 at 23:56, Nick Coghlan wrote:
> Thomas Wouters wrote:
> > Your idea of making this an API called a 'fork lock' or something
> > sounds good (though I think it needs a better name. PyBeforeFork &
> > PyAfterFork?). The subpr
On Wed, Jan 13, 2010 at 19:51, Guido van Rossum wrote:
> Please mail me topics you'd like to hear me talk about in my keynote
> at PyCon this year.
I'd like to hear you lay to rest that nonsense about you retiring :>
--
Thomas Wouters
Hi! I'm a .signature
> 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/thomas%40python.org
>
--
Thomas Wouters
Hi! I'm a .signature virus! copy me into your .
he locals, and the 'f'
function still looks it up in globals, but now *they are the same dict*.
Using the same dict for locals and globals is how modules work, as well.
The main confusion here is the fact that 'exec' doesn't generate closures.
(Nobody was ever conf
pose of it. The complaints seem to have died down now (though
possibly because of the 'no arch' topic :)
--
Thomas Wouters
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
Python-Dev mailing list
Python-De
ently, there is quite a number of Arch users, and they do make
> bug reports. Good :-)
>
I don't know that they do. I just know that people came to #python and
complained, which is unfortunately something completely different. (We did
ask every single one to take it up with the right forum,
On Fri, Nov 5, 2010 at 01:43, Stephen J. Turnbull wrote:
> Thomas Wouters writes:
>
> > To clarify (but I dont speak for the rest of #python, just myself), I
> think
> > the move was premature, but I don't use Arch and I don't know what
> typical
> >
On Fri, Nov 5, 2010 at 17:09, Stephen J. Turnbull wrote:
> Thomas Wouters writes:
>
> > > This is unrealistic. It would seriously annoy Arch's intended
> > > audience. (Eg, recently I've become a lot more favorable to using
> > > Word instead o
s and spaces (usually not even consciously, but just because their editor isn't playing along.) There probably should be an option to turn the warning off again (although I won't fight for it ;) -- but I don't know what that option should be.
-- Thomas Wouters <[EMAIL PROTECTED]>
hem?
The question is: where to store them? In a pre-allocated list, or in agrowing list?Or you can expose Py_INCREF to Python code. I'm thinking about that for big-mem tests anyway ;-)
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy
and tuples.) So, while
sys.maxint doesn't change, and any container with sane amounts of elements will almost certainly work (one would hope that's tested enough by now), real-world code that actually uses, say, more than 100Gb worth of memory in a single container may still break. Unle
ntil last year. We didn't call them sprints and they obviously weren't as freeform as the Python sprints, but the concept was the same (as well as the atmosphere.) We stopped having them because the number of concurrent projects was consistently larger than the number of programmers, whic
4, but it's still a bug. file_readinto should be using PyInt_FromSsize_t() instead. (There is the SAFE_DOWNCAST macro for cases where we know the *value* of the (s)size_t will always fit in a long, on any supported system, but that isn't the case here.)
-- Thomas Wouters <[EMAIL PROTECT
ions like this? Maybethere is a win64 compiler that would generate a warning.
I doubt it. Explicit casts are meant to silence warnings (among other things.) Warning for all casts is bound to generate quite a lot of warnings.-- Thomas Wouters <
[EMAIL PROTECTED]>Hi! I'm a .signature
ouldn't generate a warning; it's a valid (implicit) downcast that might lose bits. I believe there's a Windows compiler that goes warn for such cases, but if so, I'm sure it generates a whole lot of spurious ones at the moment.
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I&
Since Alex isn't on python-dev, forwarding this for his convenience (he said he wanted to reply.) Tim also replied to his checkin, but I didn't forward that message.-- Forwarded message ------
From: Thomas Wouters <[EMAIL PROTECTED]>Date: Aug 24, 2006 12:16 AMSubj
on implementation is great to experiment.Why, other than performance? It's a lot simpler and much easier to get right in Python, which is quite good for maintenance, too.
-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me sprea
On 8/26/06, David Hopwood <[EMAIL PROTECTED]> wrote:
CPython should be fixed anyway. The correct fix is"if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)".Why not just "... && x == LONG_MIN"?
-- Thomas Wouters <[EMAIL PROTECTED]&
x27;t think I've ever heard of that idea. I don't know what 'import
redirection' is either. But maybe it was one of those things that were still
supposed to go into PEP 328.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me i
. (Only for header files that should really be
internal, of course, not ones that are oft-used outside the core.)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
Py
On 1/3/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Thomas Wouters schrieb:
> (Only for header
> files that should really be internal, of course, not ones that are
> oft-used outside the core.)
Which are these?
Mostly structmember.h and structseq.h, les
before 2.6, and the migration step is not as
large as many fear it to be. Having Python 2.6 optionally warn for
3.0-compatibility is a lot easier for the average developer than having a
separate tool or a separately compiled Python.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .sign
On 1/10/07, Steve Holden <[EMAIL PROTECTED]> wrote:
Collin Winter wrote:
> On 1/10/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>> On 1/10/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>> It is my strong preference that we not go down this path.
&g
On 1/10/07, Steve Holden <[EMAIL PROTECTED]> wrote:
Thomas Wouters wrote:
>
>
> On 1/10/07, *Steve Holden* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Collin Winter wrote:
> > On 1/10/07, Thomas Wouters <[EMAIL PROTE
g/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/thomas%40python.org
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
P
of confusion. No one is suggesting
Python 3.0be anything less for the sake of backward compatibility.
Instead, it has
been suggested Python 2.6 (and possibly 2.7) be something *more* in order to
provide for an easier upgrade path. No compromises in Python 3.0.
--
Thomas Wouters <[EMAIL PROTECTED]>
hon 2.6, in order to make it a list-like type
that whines when it is being operated on in ways the 3.0 type won't allow.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
to inefficient or complicated code.
Python 3.0 is there to break backward compatibility, and do it cleanly. Any
work done to ease the upgrade path should be done in 2.x (and separate
tools), not 3.0. 3.0 is not a transitional release.
--
Thomas Wouters &
k that, in this
case, it is the right thing to do. Well, the least-wrong thing to do. If
only C had more visibility control, sigh ;-P
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file
been implemented yet, it's rather pointless to talk about how to
handle them in 2.6.
Is there a chance that this special case could be handled by an import
hook in py 2.6?
I expect you don't mean an actual import hook, but just a future import?
Then sure, there is a chance. We'
7;import *' or a bare 'exec' in your function can change the order of
DECREFs.
--
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
ample of a classmethod in C.)
As a final note: Python's source itself is a good source of answers and
examples. Almost all of the features of the Python API are used in a builtin
type or stdlib module, and for C source, Python's source is remarkably
readable ;-)
--
Thomas Wouters <[EMAIL
___
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/thomas%40python.org
--
Thomas Wouters <[EMAIL PROTECTED]
n 2/14/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Thomas Wouters schrieb:
>
> The same way += et al. are in-place: it would ask 'x' to modify itself,
> if it can. If not, no harm done. (It would be called as 'x = ipow(x, n,
> 10)' of course, j
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/thomas%40python.org
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signa
ecause it had to
be, to do what it is supposed to do) and it will not require any less of a
brain-warp to understand (because that's just what event-driven programming
takes.)
If I wasn't short on free time (spending most of it on Py3k and, soon,
py3k-forward-compatibility) I would do all
eactors aliased to it, and
no one would have to change a single line of code.
--
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
ht
all that from the 'main' mainloop. Or you can design all mainloops as
coroutines and have them call each other. (I haven't looked at Phillip's
approach at all, but something tells me coroutines are involved :-)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .
t's called
closure in many places already, and 'unused' in others).
I would also apply this part of the change, and both to
the trunk and Python 2.5. Objections?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
we're going to keep the
performance impact minimal or how we're going to handle dict views and what
not. I mean doubts about this procedure of having transitional releases
between 2.5 and 3.0, and the *community* impact of 2.6+ and 3.0 this way.
One thing in particular I wonder about is th
e the
biggest piece of unfinished Py3k work.
Neil
___
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/thomas%40python.org
--
Thomas Wouters &
...
FWIW, you can remove 'might' from that sentence: I've seen more than a few
people use that kind of code (and I share your concerns.)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
/git/whatever version of the repository wouldn't be
too much effort, and might make things easier for external people
developing patches. Thomas Wouters apparently has private scripts
that perform the conversion. What needs to be done to move ahead with
this idea?
I need to get time, or pe
's (not just
distributed ones), that doesn't mean it's a no-brainer to set them up
'officially', and maintain them :) There's a lot more work in there, so be
prepared to spend some time to get it to work right and reliable for
everyone.
--
Thomas Wouters <[EMAIL
ly attributed; it was me, not Martin. (But thanks for
agreeing :)
--
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:/
is the wrong thing to
do, simply because it sets (yet another) precedent. If providing an
alternate API with clearer semantics is too 'heavy-weight' a solution and
warning is for some reason unacceptable (I don't see why; all the arguments
against warning there go for *any* warning
On 3/14/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Thomas Wouters schrieb:
> However, changing documented, tested behaviour without warning gives
> Python an even worse name. I agree with PJE that the change is the wrong
> thing to do, simply because it sets (y
lass' is it in the right place in the inheritance
tree, etc) can pretty easily be done in a metaclass, possibly with the help
of some decorators. I've been meaning to write such a metaclass, but haven't
had the time. Likewise, I've been meaning to write all this down in an
article.
not, or at least not consciously. I think the point is that 'type'
and its subclasses are special enough that this warrants a separate 'X' that
inherits from 'type' rather than 'object'. Reduced reusability, but how
badly does this affect you in the real w
orth polluting the module namespace with more
confusing __*__ names? It seems more sensible to me to simply make pickle
refuse to operate on classes and functions defined in __main__. It wouldn't
even be the least understandable restriction in pickle. The
'__source_name__' attribute would read
r, which actually has its upsides as well
(no need for Rietveld to 'poll' changes, an explicit 'ok, updated according
to feedback' report, no irrelevant intermediate changes to get confused at.)
There's one thing Rietveld always has a bit of trouble representing, that
being merge
his the same way. The fact
that it got there by analyzing subsequent patches is really immaterial --
except in so far as it marks the intended changes more clearly.
--
Thomas Wouters
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
ge was introduced and whether it
was intentional) it's really helpful if the checkin message explains the
intent without having to visit the bugtracker for each one.
--
Thomas Wouters
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
he dummy merge to prevent
> inadvertent reversion in 2.7.
>
Just to be clear on this, so people don't think this is more complicated
than it needs to be: you can still *develop* a patch based on 2.5, even
commit it to your local repository, and then only push it to 2.6 or 2.7 and
later.
by it. Changing
staticmethod to be directly callable may still be a good idea, but changing
what its descr_get does is not. Making CFunctions turn into bound methods is
something that seems of little value, but could be considered at a later
point (after the warning has had time to flush out most of the pro
A warning when CPython
encounters the case that will change behaviour in the next CPython release
and in other implementations is almost as good as changing the behaviour.
--
Thomas Wouters
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
if there are still cases where staticmethods should be callable; it
seems to me it would have no real benefit, and it would lure people into a
false sense of security when mistakenly using staticmethod as the wrapper
(which is, after all, a lot more vi
and personal information over the
internet; you can't always tell the result is bad, and it can be very
painful finding out.
Jaywalking-and-unprotected-sex-metaphors-available-on-demand'ly y'rs,
--
Thomas Wouters
Hi! I'm a .signature virus! copy me into your .signature file to h
On Sun, Mar 20, 2011 at 17:59, Georg Brandl wrote:
> On 20.03.2011 16:50, Thomas Wouters wrote:
> >
> >
> > On Sun, Mar 20, 2011 at 17:39, Georg Brandl > <mailto:g.bra...@gmx.net>> wrote:
> >
> > The reason why rebasing is not universally appli
from the Twisted crew and others.
>
It ended up that Jim Fulton is actually writing the PEP (with input from
Twisted people and others.)
--
Thomas Wouters
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
n-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/thomas%40python.org
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
__
en
files", 24)
I'm not complaining about the whitespace-normalization issues, but rather
the open files issue ;-P It sounds like a buglet somewhere, although it may
be in libsvn.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file
On 7/11/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
I just got this traceback trying to do a rather large checkin:
Transmitting fil
On 7/11/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
libsvn._core.SubversionException: ("Can't open file
'/data/repos/projects/db/transactions/56255- 1.txn/props': Too many open
files", 24)
Fixed. The problem was that checkwhitespace.py wasn't closing t
elieve you will find more uses for it than you expect (although I do
believe you yourself don't have a need for it. I just don't think you're a
typical Python programmer in this case :)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your
asically, which means it includes renames, directory mutation,
changelogs, change-dependency information (which 'revision' it is based on,
in effect) and whatever else the DCVS needs or wants. You can toss those
around just like you can toss around diffs.
--
Thomas Wouters <[EMAIL
of-me'ly y'rs,
[*] Bazaar was chosen for a number of unimportant reasons that are entirely
moot at this point. It doesn't reflect my personal preference or constitute
any form of official endorsement :-)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! co
t Subversion 1.5 or 2.0 will get actual
branch tracking and full-history merging. If done properly (it's not done
yet, so it's hard to say) it would reduce the advantage of the DVCS
solutions by about half ;-P
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .s
ers are less clear, more chaotic, without
the numbering. Any chance we can get something like it back? :)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
Python-Dev mai
an I add it to the
> regression-test harness?
It basically calls Tools/scripts/reindent.py with --dry-run (although I
notice the version we call from SVN is more forgiving towards tokenizer
errors. I'm not sure we need that here.) Incorporating it in the normal test
suit would be goo
stored in pyconfig.h as is usual for configure. You
can't override them with C compiler flags, but you can edit pyconfig.h if
you can't change the configure flags. Keep in mind that you change both of
those (you probably want to just diff the two pyconfig.h's to see what else
is differ
omes py3k and 2.x development is done on a
branch (in which case I imagine we'd merge between those two in some way :-)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
P
t it's worth, when I last looked at this (a year or so ago), only a
few fringe browsers on mobile phones had issues with accepting our wildcard
certificate, and some of those only because they didn't trust the root
authority.
--
Thomas Wouters <[EMAIL PROTECTED]>
to check something into the trunk that re-eally must
not be merged into py3k, but you're afraid it's not going to be obvious to
the merger, please record the change as 'merged' using "svnmerge merge -M
-r". Please take care when picking the revision ;) You can also
On 9/19/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
>
> 2007/9/18, Thomas Wouters <[EMAIL PROTECTED]>:
>
> > Unfortunately, that's not how it works :-) If you check something into
> the
> > trunk, it will be merged into Py3k sooner or later. I may ask th
On 9/27/07, Eric Smith <[EMAIL PROTECTED]> wrote:
>
> Thomas Wouters wrote:
>
> > Unfortunately, that's not how it works :-) If you check something into
> > the trunk, it will be merged into Py3k sooner or later. I may ask the
> > original submitter for assist
On 9/28/07, Thomas Heller <[EMAIL PROTECTED]> wrote:
>
> Thomas Wouters schrieb:
> >> > If you re-eally need to check something into the trunk that re-eally
> >> > must not be merged into py3k, but you're afraid it's not going to be
> >> >
if it's worth it, as the
timing has to be pretty exact for that to happen, and you wouldn't want to
introduce a bug there; could be years before someone figures it out :P
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file t
e cyclic-gc system. I don't see that
this method is. If cyclic-gc is unavailable, should this function be
unavailable too?
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
t see any issue
preventing that, right now.
(I was actually working on backporting the new super() (incorrectly
described in PEP 3135) which builds on top of PEP 3115; I can backport
without PEP 3115 but it would be a waste if we then backported 3115 after
all.)
--
Thomas Wouters <[EMAIL PROT
Perhaps there is another solution. Have dir() exclude objects
> which are modules. For example, dir(logging) would exclude
> sys, os, types, time, string, cStringIO, and traceback.
Don't forget that that would mean dir(os) would no longer show 'path'.
--
Thomas Wouters <
.__getstate
> A.__setstate (1, 2)
> q=
> r= Traceback (most recent call last):
> File "foo.py", line 44, in
> print 'r=', r
> File "foo.py", line 37, in __repr__
> return '' % (self.a, self.b)
> AttributeError: '
it in
> refactor.get_all_fix_names.
>
> So, any better suggestions?
>
I would fix the from-future fixer to not remove futures that are specific to
3.0, and let the fixers specific to those features remove them.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm
a few years longer than that it be
cluttered with backward compatibility crap, and even rather than that widely
used code be riddled with such. But it's up to Guido in the end.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file
quires
no such knowledge. Or, alternatively, a preprocessor step involving 3to2,
which I think will result in better code. Unfortunately I don't have time to
work on either anytime soon.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signa
Twisted implementations of
various protocols are really quite, quite good -- in many cases quite a lot
better than the stdlib ones. But including those takes yet more time.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me
On Mon, Mar 24, 2008 at 10:21 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 24, 2008 at 3:04 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, Feb 15, 2008 at 9:11 PM, Josiah Carlson <
> [EMAIL PROTECTED]>
> > wrote:
> > >
3.0 is the version that will
support function annotations. Python 2.6 will almost certainly not, and 2.5
will most assuredly not -- features don't get added after the major version
has been released, we only fix bugs.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus!
ecent call last):
> File "", line 1, in
> File "/home/gps/python/trunk/Lib/encodings/__init__.py", line 100, in
> search_function
> level=0)
> TypeError: SetupPathsAndImport() got an unexpected keyword argument
> 'level'
>
Your Google sitec
101 - 200 of 417 matches
Mail list logo
