Guido van Rossum <[EMAIL PROTECTED]> added the comment:
No time to review, but making a function return something useful instead
of None seems a good idea.
--
assignee: gvanrossum ->
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
assignee: -> loewis
nosy: +loewis
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue799428>
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On Fri, Mar 21, 2008 at 3:03 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>
> Okay. How about we use this like it is for 2.x, and split it ou
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Go.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1657>
__
___
Python-bugs-list mailing list
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> Well, okay. I still think we should expose these core interpreter types
> somehow, so people can identify types easily. I don't want to be forced
> to finding the type of sys._getframe to tell if I have a frame o
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
The USTimeZone example class hasn't been updated for the new US DST
rules that went into effect in 2007. For a description of the new
rules, see:
http://wwp.greenwichmeantime.com/daylight-saving-time/usa/d
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Hi Daniel,
Can you change it so that the start and end values are chosen
dynamically based on the year? I.e. if year < 2007 use the old values
otherwise use the new ones. A tzinfo object is supposed to (within
reason) handle h
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'd be okay with only covering 1987 and later. But it's probably good
to have a table-based solution anway, to make it easy to handle future
changes -- I'm sure 2007 is not the last
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
In 2.x, \u and \U are interpreted as Unicode escapes in
raw Unicode strings. That was a mistake, but we can't fix it (except
when using "from __future__ import unicode_literals"). In 3.0, \u or
\U in a r
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
title: \u and \U in raw strings have reverted -> \u and \U in raw strings have
regressed in 3.0a4
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
components: +Interpreter Core
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2557>
__
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
The docs still need to be updated! An entry in what's new in 3.0 should
also be added.
--
assignee: -> georg.brandl
components: +Documentation -Unicode
nosy: +georg.brandl, gvanrossum
status:
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Instead of "ignored" (which might be read ambiguously) how about "not
treated specially"?
You also still need to add some words to whatsnew.
__
Tracker <[EMAIL PROTECTED]>
&
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
What's dict unpacking? I hope it's not an implementation of this sad
idea posted recently:
{'a': x, 'b': y} = {'a': 42, 'b': 'hello'} # Same as x, y = 42, 'hello'
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I don't like that the patch changes the API of a function in
test_support() (in particular changing the return type; adding optional
arguments is not a problem). This could trip up 3rd party users of this
API. I recommend cre
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Thanks, that's much better (though I'm not the authority on all details
of this patch).
__
Tracker <[EMAIL PROTECTED]>
<http://
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I think we should either get this into the 3.0a5 release planned for May
7, or wait for 3.1. I'd prefer to see some kind of PEP discussion on
the python-3000 list, rather than just a BDFL approval in a tracker
issue. I think it
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Assigning anything not related to Py3k design to me is a mistake; I
don't have the bandwidth to handle this, sorry.
--
assignee: gvanrossum ->
__
Tracker <[EMAIL PROTECTED]>
<
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Please don't add to a closed issue that old. If you still have an issue
with this, please open a new issue. If you have a patch, kindly upload
it to the issue.
Tracker <[EMAIL PRO
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
To be honest, I don't know what the uses are for that codec.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Hm, can you use lowercase for the local variable names dststart and
dstend? Otherwise looks good.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
We went over this before. *I* consider the 2.x behavior a mistake, and
a decision was made to change in 3.0. It got much worse in 3.0 because
all literals are Unicode (except byte literals).
To add a unicode value to a raw string
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Barry, this sounds like a file you weren't aware of. Too late for
3.0a4, but perhaps you can add this to the roster of files to be looked
at for each release?
--
assignee: gvanrossum -> barr
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
In 3.0, r'\u1234' is a string of 6 characters (\, u, 1, 2, 3, 4). In
2.6, after "from __future__ import unicode_literals" it is a string of
one character (code point 0x1234). IMO the 3.0 behavior should be
i
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Thanks, looks good. Since this is assigned to Georg, can you check it
in, Georg?
Should this be backported to 2.5 docs as well?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> Do I understand correctly that non-starred arguments are packed into
> intermediate tuples/sets in the presence of starred arguments so that
> {a,b,*c,d,e} is equivalent to {*{a,b},*c,*{d,e}}? This should not be a
>
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I agree with Thomas. The order in which __hash__() is evaluated
shouldn't matter to your app; if __hash__() isn't a pure function (apart
from possible caching) you've got worse trouble.
_
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1736190>
_
___
Python-bugs-list mailing list
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I don't think this ought to be changed in exec(). It ought to be done
by opening the file using universal newlines.
--
resolution: -> rejected
status: open -> closed
__
Tracker
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
My plan:
- add deprecations to 3.1
- remove in 3.3
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I still think it shouldn't be tokenize's business to handle this. I'm
not quite sure how exec() manages to do this; I note that this gives a
syntax error:
exec('x = 1\rprint x\r')
___
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'm all for adding new APIs that provide new functionality (we have a
few at Google that we really should contribute).
I'm not for having several aliases for the same functionality; it maybe
the JUnit way but Python'
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Agreed that the various loader classes etc. are mostly a waste. The sad
thing is that everyone who is serious about unittests has to reinvent
the code that finds files ending in _test.py on the filesystem, or
something like that,
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I recommend that you only care about \n and consider everything else
unspecified.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> Steve Purcell <[EMAIL PROTECTED]> added the comment:
> Hey, I'm open to anything. If I started writing unittest from scratch
> knowing what I know now, I'd probably have kept the API a little
>
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Cool. Let's make this a SystemError (in both debug builds and non-debug
build). Greg, go ahead and fix it.
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> [*sigh* i wish we didn't use a signed size type all over the place]
What would you use for error returns then?
__
Tracker <[EMAIL PROTECTED]>
<http://bu
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Hi Amaury, thanks for your work on this. I applied your patch and looked
at the code but there seem to be some issues left still.
(1) I don't think you need to add a warning to classic classes that
define __eq__ without __hash
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Note: some more tests also fail:
test_descr, test_quopri, test_set
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Let's try to have this resolved before the next release.
Also let's try not to accidentally merge the 2.6 changes related to this
issue into 3.0. :-)
--
priority: high -> release blocker
___
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Greg, any reason why you kept the assert()? IMO having the ValueError
even in debug mode is better.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Please do get rid of the asserts.
Regarding signed sizes, it's a historic accident (copied from Unix
system calls which tended to use plain ints or longs in the olden days),
but it may not be impossible to fix -- we've fi
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
This looks indeed wrong. Unfortunately it also looks hard to fix in a
way that won't break unpickling arrays pickled by a previous Python
version. We won't be able to fix this in 2.5 (it'll be a new feature)
but we s
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I think this has potential, but it is too liberal. There are many more
characters that cannot be assumed printable, e.g. many of the Latin-1
characters in the range 0x80 through 0x9F. Isn't there some Unicode
data table that
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Do I need to look at this, or is the review going well without my
interference?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Once the review for this is completed I have no objection to it going in.
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1683368>
_
___
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
priority: -> critical
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2632>
__
___
Python-b
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Atsuo: I missed Michael Urman's comment. Can you copy it here, or
(better :-) write a patch that uses it?
Amaury: I think it would be okay to use backslashreplace as the default
error handler for sys.stderr. Probably not for
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Code review:
Objects/rangeobject.c:
line 259-260:
AFAIK register is completely useless in this day and age; drop it.
line 296 and further:
Please move the || and && operators to the end of the previous line.
line 313 etc:
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Close. Just a few nits:
line 298:
These two fit on one line. Possibly the whole thing fits. If it doesn't,
the '{' should be on a line by itself.
(Are you aware of PEP 7, C code guidelines? I realize it's incomp
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I don't think this is a good idea; I've explained why earlier on this issue.
__
Tracker <[EMAIL PROTECTED]>
<http://
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
keywords: +easy
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2650>
__
___
Python-bugs
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
versions: +Python 2.6, Python 3.0 -Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2650>
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 25, 2008 at 3:36 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
> Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
>
> Thanks for the help.
>
> Yes, after thinking for a while,
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 25, 2008 at 3:41 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> If it makes any difference, the attributes aren't even available through
> Python.
But they are deducible via the str() or repr(). A
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Looks good. Go ahead. Make sure to block the CL (and any follow-up CLs
that use this) from integration into 3.0.
--
assignee: -> benjamin.peterson
nosy: +gvanrossum
resolution: -&
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I think it's important to make this available in 2.6; it will let people
writing 3.0-oriented code in 2.6 (as several developers are planning to
do) do the right thing for this syntax.
__
Trac
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> I would think tp_iternext failing to set an exception should not be
> translated into stop iteration. Instead, builtin_next() should return
> NULL without an exception set and thus trigger a SystemError.
Wrong; the i
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
+1 on this. I have a few nits about the code:
Line 1083: "%.200s object is not an iterator", it->ob_type->tp_name);
Line is too long.
Line 1088: if (res == NULL) {
How about
if (res != NULL)
return res;
?
Li
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Feel free to submit a patch to fix the docs.
Changing the API is not an option -- it's been like this since the
tp_iternext slot was added, and it's been designed like this for a
reason: so that in the common case of iterat
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
This patch doesn't apply cleanly. :-(
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
See also comments published on the code review site:
http://codereview.appspot.com/602
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Show me which tests break and I'll decide.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2735>
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
We need to look at more details why those fail. Perhaps there's one
common place where this is used? Did you add __length_hint__ yet?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Fair enough. Let's keep __len__. Did you upload the patch to the codde
review site yet? Hopefully I have time to look at it tonight.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
This is a very long line. I am wondering how it will be wrapped. What
will happen to this exceedingly long line? Will it be wrapped? Will it?
Really? What will happen?
Here's an example:
def fact(n):
if n > 1:
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
nosy: -gvanrossum
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
FWIW, I've added Giampaolo's latest patch to Rietveld:
http://codereview.appspot.com/744
Review comments added there should automatically be CC'ed here.
_
Tracker <
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On Fri, Apr 18, 2008 at 1:46 AM, Marc-Andre Lemburg
<[EMAIL PROTECTED]> wrote:
> On 2008-04-18 05:35, atsuo ishimoto wrote:
> > atsuo ishimoto <[EMAIL PROTECTED]> added the comment:
> >
> > Is a
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
FWIW, I've uploaded diff3.txt to Rietveld:
http://codereview.appspot.com/767
Code review comments should be reflected here.
I had to skip the change to Modules/unicodename_db.h which were too
large for Rietvel
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
No need to change anything, the diff is just too big for the code
review tool (Rietveld), but since it consists only of numbers we don't
need to review it anyway. :)
__
Tracker <[EMAIL PRO
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On Tue, May 6, 2008 at 1:26 AM, Marc-Andre Lemburg wrote:
> So you've limited the codec design to just doing Unicode<->bytes
> conversions ?
Yes. This was quite a conscious decision that was not taken lightly,
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
imageop is deleted in 3.0. See PEP 3108. So it can't be a release
blocker. This also explains my general lack of interest in this module.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'd be happy to have a separate more relaxed API for stackable codecs,
however, the API should not be overloaded on the .encode() and .decode()
methods on str and bytes objects.
__
Tracker <[E
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
As the term "single-quoted string" is clearly ambiguous, I propose to
change the error message to just "string" (or perhaps "string literal",
but then you'd have to change the triple-quoted message
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Stop bothering us.
--
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
nosy: -gvanrossum
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Try adding re.LOCALE to the flags. I'm not sure why that is needed but
it seems to fix this issue.
I still think this is a legitimate bug though.
--
nosy: +gvanrossum
__
Tracker <[E
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
This is certainly out of scope for 3.0. Remember, for 3.0 we're trying
to get a release out of the door, not cram in new features, no matter
how small.
Beyond 3.0, I'm still rather reluctant -- I expect most users will
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
This doesn't sound like it will ever be reliable.
Kai Zhu, a better strategy would be for you to maintain your own
experimental port of Python 2.6+3.0 based upon these patches.
--
resolution: -> rejected
status:
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
No, re.sub()'s documentation
(http://docs.python.org/library/re.html#re.sub)
makes it clear that \ followed by n in the replacement string is
interpreted.
To insert \ followed by n you have to double the \ inside the raw strin
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Yes, I know. I'll spend some time on it this week.
BTW what's the hold-up with the rc2 release? Or did I just miss it?
___
Python tracker <[EMAIL PROTECTED]>
<http://
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I approve of the API change. It's 3.0, dammit!
--
nosy: +gvanrossum
resolution: -> accepted
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
resolution: -> out of date
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
OK, reopening. Can you post an example that fails today?
--
resolution: out of date ->
status: closed -> open
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
This will have to deferred to the final 3.0 release, I don't have time
today (dr's appt, internal release, blah, blah).
Sorry!
--
priority: release blocker -> deferred blocker
___
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I think the ability to read old files is essential. The ability to
write them is a mer nice-to-have.
On Fri, Nov 21, 2008 at 7:36 AM, <[EMAIL PROTECTED]> wrote:
>
>me> ... I thought Guido was of the opinion that t
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Reading old dumbdbm files is essential. Writing them is not.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
[fix title]
--
title: Re: r67310 - in python/branches/py3k: Lib/dbm/dumb.py
Lib/test/test_dbm_dumb.py Misc/NEWS -> Byte/string inconsistencies between
different dbm modules
___
Pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
You meant socket.py.
This is an extremely subtle area. I would be very wary of changing this
-- there is a use case where headers are read from the socket using
readline() but the rest of the data is read directly from the socke
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'm fine with disabling this feature in xmlrpclib.py, and possibly even
in httplib.py.
I'm *not* fine with "fixing" this behavior in socket.py -- the unittest
coverage is unfortunately small and we have had plen
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Working on it! Woo hoo!
Thanks Victor for the detailed feedback.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On Tue, Dec 2, 2008 at 12:07 PM, Barry A. Warsaw <[EMAIL PROTECTED]> wrote:
>
> Barry A. Warsaw <[EMAIL PROTECTED]> added the comment:
>
> Guido, ETA? I think this will be one of the last things before we
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I wouldn't go so far as claiming this is completed, but I think it's in
a good enough shape to release. I may continue to work on it some more,
but you can freeze the tree at any moment -- I won't add more XXX
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On Wed, Dec 3, 2008 at 1:36 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> Some small mistakes :
>
> * « an object always compares equal to it
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I think this is good enough for now.
Someone else can help add stuff I missed, but I don't think we need to
keep a bug open to remind us.
--
resolution: -> fixed
status:
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Bah. That means we'll have to start deprecating cmp() in 3.1, and won't
be able to remove it until 3.2 or 3.3. :-)
___
Python tracker <[EMAIL PROTECTED]>
<http://
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
It is true for 2.6 unless you use various from __future__ imports, which
I consider a form of contortion.
Even with 2.6 I don't see how you can specify a metaclass without doing
something weird like
foo = MyMetaclass('f
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
You're misrepresenting or misunderstanding the goal of 2.6. Its goal
isn't to make it easy to write code that runs under both. Its stated
goal is to make it easy to write code that can easily be *ported* to
3.0. That&#x
1601 - 1700 of 5563 matches
Mail list logo
