[issue2011] compiler.parse("1; ") adds unexpected extra Discard(Const(None)) to parse tree

Guido van Rossum added the comment: What on earth is this about? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2011> __ ___ Python-bugs-list mailing list Unsubs

[issue846388] Check for signals during regular expression matches

Guido van Rossum added the comment: Backported to 2.5.2 as r60576. (The other deltas are not backported.) Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/is

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

Guido van Rossum added the comment: > > I have one minor nit on the current rational.py code: all internal > > accesses to the numerator and denominator should use self._numerator > > and self._denominator -- going through the properties makes it *much* > > slower. Remem

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

Guido van Rossum added the comment: Jeffrey: Yay for measurements! I was going to say that __add__ is inefficient because it makes so many function calls, but it turns out that, as you say, the cost of constructing a new Rational instance drowns everything else. On my 2.8GHz iMac, Rational(2,3

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

Guido van Rossum added the comment: > I'm not sure I like the idea of names Rational and Fraction; the two > classes numbers.Rational and rational.Rational are quite different beasts, > and using two almost-synonyms for their names seems like a bad idea. > Is there some more

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

Guido van Rossum added the comment: > Fair enough. Should it be fractions.Fraction or fraction.Fraction? I think "from fractions import Fraction" is linguistically more correct -- the concept is always mentioned in plural, but a fractional number is of course singular. We also

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

Guido van Rossum added the comment: Go for it! __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue2016] Crash when modifying the **kwargs passed to a function.

Guido van Rossum added the comment: I have a proposed minimal fix, but I wonder if this would break existing code (apart from the exploit given here). Martin? (I think the discussion between Alexander and Amaury can be ignored for the purpose of reviewing the fix; only the exploit matters

[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

Guido van Rossum added the comment: > Okay, Nick; you've got me convinced. For some reason I wasn't really > thinking of these methods as alternative constructors---in this light, > your arguments about doing the same as __new__, and about established > patterns, make perf

[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

Guido van Rossum added the comment: Yay! And my benchmark went from 70 usec to 15 usec. Not bad! PS. Never use relative speedup numbers based on profiled code -- the profiler skews things tremendously. Not saying you did, just stating the obvious. :) __ Tracker

[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

Guido van Rossum added the comment: PS. I can shave off nearly 4 usec of the constructor like this: -self = super(Fraction, cls).__new__(cls) +if cls is Fraction: +self = object.__new__(cls) +else: +self = super().__new__(cls) This would seem to

[issue960406] unblock signals in threads

Guido van Rossum added the comment: restore nosy list -- nosy: -sandylovesedward Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue960406> ___ Pyth

[issue1600] str.format() produces different output on different platforms (Py30a2)

Guido van Rossum added the comment: I would like Python to follow the C99 rule here. It is practical and Python has a long tradition of following C where it makes sense. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

Guido van Rossum added the comment: A C reimplementation of gcd probably makes little sense -- for large numbers it is dominated by the cost of the arithmetic, and that will remain the same. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

Guido van Rossum added the comment: I think this is definitely premature optimization. :-) In any case, before going any further, you should design a benchmark and defend it. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue2163] test_socket is flakey

New submission from Guido van Rossum: I find that test_socket fails regularly (but not always) when run via "regrtest.py -uall". The message is always "socket is not connected" but it's unclear from which test it comes -- all I know is that it comes from tearDown() on

[issue1040026] os.times() is bogus

Guido van Rossum added the comment: Well, 8./5 equals 100/60. Go figure. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1040026> _ ___ Python-bugs-

[issue1040026] os.times() is bogus

Guido van Rossum added the comment: test_times.py produces the correct value on Linux for me, but I see the same bogus value as Malte on OSX. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/iss

[issue2186] map and filter shouldn't support None as first argument (in Py3k only)

New submission from Guido van Rossum: There are other ways of getting the same effects now (list() or zip() for map(None, ...)). -- keywords: easy messages: 62967 nosy: gvanrossum severity: normal status: open title: map and filter shouldn't support None as first argument (in Py3k

[issue2186] map and filter shouldn't support None as first argument (in Py3k only)

Changes by Guido van Rossum: -- components: +Interpreter Core type: -> behavior __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2186> __ ___ Python-bu

[issue2187] map and filter objects shouldn't call themselves itertools.imap and itertools.ifilter objects

New submission from Guido van Rossum: Probably ifilter and imap should go (moving the code over to bltinmodule.c). -- components: Interpreter Core keywords: easy messages: 62968 nosy: gvanrossum severity: normal status: open title: map and filter objects shouldn't call thems

[issue2186] map and filter shouldn't support None as first argument (in Py3k only)

Guido van Rossum added the comment: Let me assign this to Raymond for the answering of the question about ifilterfalse. -- assignee: -> rhettinger nosy: +rhettinger __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.o

[issue2163] test_socket is flakey

Guido van Rossum added the comment: It seems to work now for me too. I'll keep an eye out though. -- resolution: -> works for me status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.

[issue2187] map and filter objects shouldn't call themselves itertools.imap and itertools.ifilter objects

Changes by Guido van Rossum: -- assignee: -> rhettinger nosy: +rhettinger __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2187> __ ___ Python-bugs-li

[issue1394] simple patch, improving unreachable bytecode removing

Guido van Rossum added the comment: On Mon, Feb 25, 2008 at 1:32 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > Unit tests are just for bugfixes. I presume you meant "are *not* just for bugfixes". __ Tracker <[EMAIL PROTECTED]>

[issue2186] map and filter shouldn't support None as first argument (in Py3k only)

Guido van Rossum added the comment: > What do you guys think about just making the predicate argument optional? > >filter([-2,0,2]) --> -2, 2 >filter(pred, iterable) > > One arg is the first case and two args is the second case. -1. Apart from range() this is

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

Guido van Rossum added the comment: The py3k feature was intentional. I'm not sure who did the backport (could've been me, long ago). I think the backport should be replaced with a warning that is only issued when -3 is given. __ Tracker <[EM

[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

Guido van Rossum added the comment: > I noticed that my patch uses Py_TYPE(self)->tp_hash, whereas normal > processing of slot_tp_hash() uses lookup_method(self,"__hash__",hash_str). > > I am almost sure that both expressions return the same value. > Is this cor

[issue1733184] slice type is unhashable

Guido van Rossum added the comment: Alexander nailed my motivation. Have the proponents for this change really thought through that making slices hashable means that henceforth this code will work? d = {} d[:] = [1, 2, 3] # surprise here print d # prints {slice(None, None

[issue2186] map and filter shouldn't support None as first argument (in Py3k only)

Guido van Rossum <[EMAIL PROTECTED]> added the comment: It would break the symmetry with map(). __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2186> __ __

[issue1619060] bisect on presorted list

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Sorry, I will claim ignorance on this one. I don't recall the last time I've used a bisection, but it was probably around the time bisect.py was first added to the standard library. I do recall using heap sort as a way to c

[issue2292] Missing *-unpacking generalizations

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Didn't you say it does sets too? Does this work? a = [1, 2, 3] {1, *a, 0, 4} # {0, 1, 2, 3, 4} How about dicts? kwds = {'z': 0, 'w': 12} {'x': 1, 'y': 2, **kwds} # {'x': 1, &

[issue2292] Missing *-unpacking generalizations

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Looking at the flatten() example I'm curious -- how come the output of >>> flatten(L) is displayed as a list rather than as ? Also, do I understand correctly that yield *(1, 2, 3) is equivalent to yield 1 yield

[issue2292] Missing *-unpacking generalizations

Changes by Guido van Rossum <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9674/unnamed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2292> __

[issue2292] Missing *-unpacking generalizations

Changes by Guido van Rossum <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9675/unnamed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2292> __

[issue1689] Backport PEP 3141 to 2.6

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Why can't this be closed? -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> <http://bugs.

[issue2305] Update What's new in 2.6

New submission from Guido van Rossum <[EMAIL PROTECTED]>: Somebody will have to write the "What's new in 2.6" document. I'm doing 3.0 but I'm not doing 2.6 as well. -- assignee: georg.brandl components: Documentation messages: 63591 nosy: georg.brandl, gva

[issue2306] Update What's new in 3.0

New submission from Guido van Rossum <[EMAIL PROTECTED]>: I will be working on this. -- assignee: gvanrossum components: Documentation messages: 63592 nosy: gvanrossum priority: high severity: normal status: open title: Update What's

[issue2307] Decide what to do with bytes/str when transferring pickles between 2.6 and 3.0

New submission from Guido van Rossum <[EMAIL PROTECTED]>: A pickled str instance written by 2.6 currently unpickles under 3.0 as a bytes instance. That would be correct if the intended use is binary data, but it's wrong if the intended use is text. My hunch is that there's more p

[issue2308] Make structseq more like collections.namedtuple

New submission from Guido van Rossum <[EMAIL PROTECTED]>: The built-in type structseq (used by e.g. os.stat() for the stat structure and by the time module for a time tuple) resembles the new namedtuple type added to the collections module in 2.6. It would be nice if these had at least a

[issue2309] Add xturtle to the standard library?

New submission from Guido van Rossum <[EMAIL PROTECTED]>: Georg Lingl has offered his xturtle for the standard library. Barring showstopping problems with dependencies or code qualitiy I think this is a good thing to add to 3.0 as a replacement for turtle, and to add to 2.6 while keepi

[issue2309] Add xturtle to the standard library?

Guido van Rossum <[EMAIL PROTECTED]> added the comment: See http://mail.python.org/pipermail/python-dev/2008-March/077621.html __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2310] Reorganize the 3.0 Misc/NEWS file

New submission from Guido van Rossum <[EMAIL PROTECTED]>: The 3.0 Misc/NEWS file is a mess. It is vastly incomplete because it usually gets skipped during merges rather than resolving the conflicts. -- assignee: georg.brandl components: Documentation messages: 63597 nosy: georg.

[issue2311] Update the ACKS file

New submission from Guido van Rossum <[EMAIL PROTECTED]>: We should keep the ACKS files up to date. Have all the GHOP contributors been added? -- assignee: georg.brandl components: Documentation messages: 63598 nosy: georg.brandl, gvanrossum priority: normal severity: normal

[issue2312] Update PEP 3135 (super())

New submission from Guido van Rossum <[EMAIL PROTECTED]>: The super() PEP currently is completely wrong w.r.t. reality. The implementation is solid and won't change. The PEP just needs to be rewritten to match reality. -- assignee: georg.brandl components: Documentati

[issue1513695] new turtle module

Guido van Rossum <[EMAIL PROTECTED]> added the comment: (This is no longer the latest version. Gregor, mind uploading a newer one?) -- nosy: +gvanrossum _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.o

[issue2314] Test issue

Guido van Rossum <[EMAIL PROTECTED]> added the comment: So what did the email you sent look like? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2314> __ __

[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Any progress? -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1950> __ _

[issue2314] Test issue

Guido van Rossum <[EMAIL PROTECTED]> added the comment: So what's the syntax for setting multiple attributes via an email subject? [assignee=+twouters,priority=low]? __ Tracker <[EMAIL PROTECTED]> <http://bugs.

[issue2314] Test issue

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Picky! -- assignee: gvanrossum -> nnorwitz nosy: +twouters priority: immediate -> low __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2314] Test issue

Guido van Rossum <[EMAIL PROTECTED]> added the comment: [assignee=guido] Does it also work in the body of the message? __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2314] Test issue

Guido van Rossum <[EMAIL PROTECTED]> added the comment: No. -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2314> __ ___

[issue868845] Need unit tests for <...> reprs

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I'd rather not label this as easy yet, since there's a decision to be made. I would welcome a doc patch though! Tracker <[EMAIL PROTECTED]> <http://bu

[issue2282] TextIOWrapper.seekable() always returns False

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Confirmed. Ping, since you're looking at io.py anyway, can you fix this too? -- assignee: -> ping nosy: +ping priority: -> high __ Tracker <[EMAIL PROTECTED]> <http:/

[issue2305] Update What's new in 2.6

Changes by Guido van Rossum <[EMAIL PROTECTED]>: -- assignee: georg.brandl -> akuchling __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2305> __ ___

[issue1202] zlib.crc32() and adler32() return value

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Sure. (Though sending pickles to 3.0 would still cause problems. Consumers of pickled checksums would do wise to *always* take the CRC mod 2**32 before doing comparisons.) __ Tracker <[EMAIL

[issue2324] Document that 2.6 pickles of strings turn into pickles of unicode in 3.0

Guido van Rossum <[EMAIL PROTECTED]> added the comment: The issue is different; there is already a bug open for this (bug 2307). -- nosy: +gvanrossum resolution: -> invalid status: open -> closed superseder: -> Decide what to do with bytes/str when transferring pickl

[issue2307] Decide what to do with bytes/str when transferring pickles between 2.6 and 3.0

Guido van Rossum <[EMAIL PROTECTED]> added the comment: We have a proposed solution for 2.x -> 3.x. In 3.x, an (8-bit) str instance received from 2.x will be decoded into a (Unicode) str instance. The encoding defaults to ASCII; you can specify a different encoding and also an error

[issue2330] Update PEP 3000 with new release schedule

New submission from Guido van Rossum <[EMAIL PROTECTED]>: Barry, can you update the PEP with a discussion of the schedule, so we can refer to it? -- assignee: barry components: Documentation messages: 63686 nosy: barry, gvanrossum priority: urgent severity: normal status: open

[issue2310] Reorganize the 3.0 Misc/NEWS file

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Correct. Martin & I just discussed this. We'll empty the current 3.0 NEWS file and start adding stuff consistently from 3.0a3, but skipping stuff merged from 3.0. For the big changes since 2.x, people will have to refer t

[issue2368] Fixer needed to change __builtin__ -> builtins

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Brett meant to add 'builtins' as an alias for __builtin__. I don't think we should do that. However we should have a fixer for this. Assigning to Collin and changing the subject to match. -- assignee: gvanr

[issue2307] Decide what to do with bytes/str when transferring pickles between 2.6 and 3.0

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Checked in as r61467. When pickling a bytes instance in a protocol < 3, it is pickled as a user-defined type (essentially faking a __reduce__ operation) which can be read back correctly in 3.0 but probably n

[issue2339] Backport intern() -> sys.intern()

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I see no great advantage in having it backported, though I also don't see no great harm. Since we still use interning as an internal speed-up, I believe in exposing the API, past discussions notwithstanding. -- prior

[issue2374] Use of builtin file should give Py3k warning

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I'll review this. My hunch is that we don't need this -- 2to3 takes care of this so there is no reason to tell people to change their code by hand. (You may notice a pattern -- things that 2to3 can fix easily generally

[issue2374] Use of builtin file should give Py3k warning

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Let's not do this. This approach is not sufficiently backwards compatible; it will break any code that uses isinstance(x, file). Even though that's not forward compatible with 3.0, it works in 2.5 and before, so it should

[issue2321] return more memory from unicode objects to system

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Looks good, Neal. Are you hesitant to check this in? I ran a little test showing that indeed it gives much more memory back to the system. -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTE

[issue2371] Patch for catching exceptions that do not inherit from BaseException

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I'll review this once I address issue2291. -- assignee: -> gvanrossum nosy: +gvanrossum priority: -> normal __ Tracker <[EMAIL PROTECTED]> <http:/

[issue2291] Raise a Py3K warning for catching non-BaseException exceptions

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I finally figured this out. The try/except statement is a complete red herring; the problem is in the raise statement. The behavior is the same in 2.4, 2.5 and 2.6, even though Exception is a classic class in 2.4 and a new-style cl

[issue1711] socket functions that should return unsigned int return signed int

Guido van Rossum <[EMAIL PROTECTED]> added the comment: This is likely fixed; setting the status to pending and priority to low. I believe this will eventually close it. -- priority: normal -> low status: open -> pending __ Tracker <[

[issue2371] Patch for catching exceptions that do not inherit from BaseException

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Thanks! Applied as r61475. -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2291] Raise a Py3K warning for catching non-BaseException exceptions

Guido van Rossum <[EMAIL PROTECTED]> added the comment: "except object:" will continue to be a no-op, if only for compatibility. With -3 it will issue a warning (I just checked this in, from issue2371). With -3 -Werror it will be an error. We still need patches to issue

[issue2292] Missing *-unpacking generalizations

Guido van Rossum <[EMAIL PROTECTED]> added the comment: This is fun, but needs more work (see python-3000 thread). I'm setting the priority to low, since I won't hold up a release to get this in (if there's even a rough consensus). -- assignee: gvanrossum -> tw

[issue2226] Small _abcoll Bugs / Oddities

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I'm setting this to critical to ensure that I will at least have a thorough look at this before the release. I'm not sure whether I will decide to address it or leave it alone. -- priori

[issue2371] Patch for catching exceptions that do not inherit from BaseException

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Alex, can you please open a separate bug for that? The cross-posting of comments is unhelpful, and the issue was not introduced by this patch. __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2371] Patch for catching exceptions that do not inherit from BaseException

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I've checked a temporary work-around for that issue and another one in r61478. This now has some false negatives; that's better than false positives IMO. __ Tracker <[EMAI

[issue2303] isinstance is 4x as slow as in 2.5 because the common case raises

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I'll set this to critical to ensure that I look at it at least once before we release. I'm not sure however that we can do much about it -- nor that it matters much in practice. Perhaps we could speed up certain common is

[issue2291] Raise a Py3K warning for catching non-BaseException exceptions

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Thanks! -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2379] Raise a Py3K warning for __getitem__ or __getslice__ on exception instances

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I'll review this soon. -- assignee: -> gvanrossum nosy: +gvanrossum priority: -> release blocker __ Tracker <[EMAIL PROTECTED]> <http:/

[issue2341] Raise a Py3K warning when raise non-BaseException exceptions

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I'll review this soon. -- assignee: -> gvanrossum nosy: +gvanrossum priority: critical -> release blocker __ Tracker <[EMAIL PROTECTED]> <http:/

[issue2341] Raise a Py3K warning when raise non-BaseException exceptions

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Checked in as r61486. I tweaked your change slightly to compare the output of PyErr_Warn() with -1. The "minor" patch is incorrect IMO; the code where the comment was originally is indeed normalizing the exception in a spe

[issue2380] Raise a Py3K warning for catching nested tuples with non-BaseException exceptions

Changes by Guido van Rossum <[EMAIL PROTECTED]>: -- keywords: +26backport, easy priority: -> low __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2380> __ _

[issue2379] Raise a Py3K warning for __getitem__ or __getslice__ on exception instances

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Cleaned up and committed as r61489. Thanks!! -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue1911] webbrowser.open firefox 3 issues

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Sorry, I have lots of other things to do before I get to this. It's too late for 2.5.2; 2.5.3 won't be out until September or October 2008. Please ping before then. -- components: +Library (Lib) -Extension Module

[issue1179] [CVE-2007-4965] Integer overflow in imageop module

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Sorry this missed the 2.5.2 release. I'll try to look again before 2.5.3 is imminent. -- components: +Extension Modules -Library (Lib) __ Tracker <[EMAIL PROTECTED]> <ht

[issue1775] filehandle.write() does not return None (Python 3.0a2)

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Georg, can you whip up a bit of documentation for this? (Of course you may find that the docs for io.py are lacking more than just this nit...) -- assignee: gvanrossum -> georg.brandl components: +Documentation -Lib

[issue1762972] 'exec' does not accept what 'open' returns

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Christian, I still see __file__ point to a .pyc file: guido-macbookpro:~/p3 guido$ ./python.exe Python 3.0a3+ (py3k:61464M, Mar 17 2008, 16:36:53) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "cop

[issue1337696] Elemental Security contribution - pgen2 package

Guido van Rossum <[EMAIL PROTECTED]> added the comment: This has now been included in the sandbox code for 2to3 and is slated for inclusion in the Python trunk (and the py3k branch). Closing this patch. -- resolution: -> accepted status: open -> closed title: Elemen

[issue667770] import C API mess

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Brett, perhaps you can consider this with your integration of import-rewritten-in-Python? I think it's fine to leave this alone for 2.6. -- assignee: gvanrossum -> brett.cannon components: +Interpreter C

[issue1616] compiler warnings

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Let's make this a catch-all bug to remind us to ensure the build is warning-free on as many platforms as possible. -- priority: low -> critical title: compiler warnings (gcc 2.96) -> compiler warnings versions: +P

[issue1717] Get rid of more refercenes to __cmp__

Guido van Rossum <[EMAIL PROTECTED]> added the comment: __cmp__ is not coming back. -- priority: low -> normal __ Tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue2390] Merge 2.6 ACKS with 3.0 ACKS

New submission from Guido van Rossum <[EMAIL PROTECTED]>: Due to blocked merges etc. I expect that some names appearing in the 2.6 ACKS file aren't in the 3.0 ACKS file. And possible the other way around where backports are involved. I like this file to be as inclusive as possible (

[issue1518] Fast globals/builtins access (patch)

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Making sure I look at this at least once carefully before releasing. -- assignee: -> gvanrossum priority: -> critical __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2303] isinstance is 4x as slow as in 2.5 because the common case raises

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Perhaps, though I'm not sure if that doesn't slow things down further due to the complicated protocol for calling it. Also, there's a recursion check in the built-in implementation. _

[issue2073] asynchat push always sends 512 bytes (ignoring ac_out_buffer_size)

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I know nothing about asyncore. Does this problem still exist in the trunk (2.6)? __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2303] isinstance is 4x as slow as in 2.5 because the common case raises

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Yeah, but tp_ slots are expensive themselves (mostly in the amount of code that needs to be changed -- see typeobject.c). __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue1581] xmlrpclib.ServerProxy() doesn't use x509 data

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Let's tentatively say this needs to go into 2.6. Bill, if in the end you decide against it, just reject the patch. -- priority: -> critical versions: +Python 2.6 -Python 2.5 __ T

[issue2310] Reorganize the 3.0 Misc/NEWS file

Guido van Rossum <[EMAIL PROTECTED]> added the comment: > Do you mean "skipping stuff merged from 2.6" ? Yes :) __ Tracker <[EMAIL PROTECTED]> <http

[issue1605] Semi autogenerated _types module

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I'm still resounding -1 on this. Grouping types together because they happen to be implemented in C is a silly thing to do. Groupings should be based on usage, not on implementation style. I successfully argued against the i

[issue467384] provide a documented serialization func

Guido van Rossum <[EMAIL PROTECTED]> added the comment: There isn't anything actionable in this bug request. It makes much more sense to start a discussion about requirements etc. on python-ideas. -- resolution: -> out of date status:

[issue1657] [patch] epoll and kqueue wrappers for the select module

Guido van Rossum <[EMAIL PROTECTED]> added the comment: pyepoll for static names sounds fine (assuming you want some consistency). Given all the rave reviews, what are the chances that you'll be checking this in soon? __ Tracker <[EMAIL PRO

<    11   12   13   14   15   16   17   18   19   20   >