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
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Then what did you mean by "just to make it possible to write code
that runs under both" ?
___
Python tracker <[EMAIL PROTECTED]>
<http://
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
But that's all part of the "make it easy to port" strategy.
I stick to my claim that trying to write code that runs unchanged in 3.0
is a non-goal of Python 2.6, and I do not want to suggest that this is a
good
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Well what would you suggest we do?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1717>
___
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
OK, remove it in 3.0.1, provided that's released this year.
Performance fixes are always fair game for bugfix releases.
Please don't "fix" the what's new document (or undo the fix).
I do hope cmp() was
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
nosy: -gvanrossum
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1717>
___
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Eh? It's just a doc bug now.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4185>
___
Guido van Rossum added the comment:
This was discussed recently on python-dev (or was it python-ideas). The
world is not ready for this. Please refer to the archive for motivation.
--
resolution: -> rejected
status: open -> closed
___
Guido van Rossum added the comment:
Retro, you are blowing this way out of proportion. Style guidelines are
not absolute rules that must be followed at all cost, and there are
always exceptions. You need to have a lot of experience before you can
claim with certainty that a certain piece of
Guido van Rossum added the comment:
Don't open a new issue to point out that you just opened a new issue.
About removing getopt.error: if it's in 3.0, it needs to stay or be
properly deprecated. 3.1 has to be backwards compatible with 3.0 for sure.
--
nosy: +gvanrossum
Guido van Rossum added the comment:
[-gvanrossum]
___
Python tracker
<http://bugs.python.org/issue1040026>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue1040026>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
I've been on vacation and unable to follow this, and won't have time to
catch up now. Note that I have no vested interest in Google's module
except knowing it has many happy users (I have never used it myself --
but Collin Winter has and h
Guido van Rossum added the comment:
After reading all that I still think we should fix this now, and fix
pickle so that it can read (and write?) 2.x pickles. This is much less
visible than cmp() still being present in 3.0, and we've already decided
to kill that in 3.0.1, so we can kill in
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue3826>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue4842>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
I don't think this has much to do with try/except. That it works in 2.6
but not in 3.0 isn't a big deal; the semantics of variables used in
except clauses has changed dramatically.
It has to do with deletion of a variable that's held in a cel
Changes by Guido van Rossum :
--
assignee: gvanrossum ->
versions: +Python 3.1 -Python 3.0
___
Python tracker
<http://bugs.python.org/issue2897>
___
___
Py
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue2897>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
I'm not going to get to this.
--
assignee: gvanrossum ->
___
Python tracker
<http://bugs.python.org/issue2226>
___
_
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue2226>
___
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Not it.
--
assignee: gvanrossum ->
___
Python tracker
<http://bugs.python.org/issue2772>
___
___
Python-bugs-list mai
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue2772>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
assignee: gvanrossum ->
___
Python tracker
<http://bugs.python.org/issue1708>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue1708>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
assignee: gvanrossum ->
___
Python tracker
<http://bugs.python.org/issue2073>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Guido van Rossum :
--
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue2073>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum :
--
assignee: gvanrossum ->
___
Python tracker
<http://bugs.python.org/issue1772833>
___
___
Python-bugs-list mailing list
Un
Changes by Guido van Rossum :
--
assignee: gvanrossum ->
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue614557>
___
___
Python-bugs-lis
Changes by Guido van Rossum :
--
assignee: gvanrossum ->
nosy: -gvanrossum
___
Python tracker
<http://bugs.python.org/issue1911>
___
___
Python-bugs-list mai
1601 - 1700 of 5533 matches
Mail list logo
