Guido van Rossum added the comment:
IIRC:
The design started out this way because it predates new-style classes. When
this was put in one couldn't subclass extension types, and there were
plans/hopes to replace some of the lock types with platform-specific built-in
versions on
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Chester, this is your last warning. One more submission like this and
we will ban you from submitting new bug reports. You have to learn how
to use the bug tracker properly if you don't want to be ignored completely.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> Thanks. I think this part is the main reason I see a start argument to
> enumerate as potentially problematic:
>
> """all variants can easily be misread as starting at the nth item in the
> s
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Sure, fine.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2831>
__
___
Python-bugs-list mailin
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Please keep them. They correspond to the (?x) and (?s) syntax that is
supported inside the regex.
Perl compatibility is a feature, not a bug for the re module.
--
nosy: +gvanrossum
resolution: -> wont fix
status: open
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'm torn about the extra slot; I'd rather not add one, but I can't see
how to make this flexible enough without one.
It should definitely not be a built-in; the sys module is fine though
(e.g. sys.getrefco
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I see it differently. The rule is simply that if you use a bare * you
*must* follow it with at least one argument (that's not **k). This
makes sense since otherwise the * is redundant. Think about it; there
is nothing differ
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Since Pexpect is alive and well, doesn't it satisfy your needs? What's
the point of trying to push an alternative implementation that has
lingered for 7 years now?
--
n
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> Whether the C API stuff and .isprintable() should be backported to 2.6
> is something for Guido to decide.
No way -- while all of this makes sense in Py3k, where all strings are
Unicode, it would cause no end of problems in
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Looks like you accidentally removed 2-arg __pow__ from the Complex ABC.
This should stay of course.
Also, please add the binary operators back in a new ABC called Binary
deriving from In
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Excuse me? Have you actually been following the thread?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Looks good. I like keeping the *View classes around so someone can use
them still.
--
assignee: gvanrossum -> georg.brandl
___
Python tracker <[EMAIL PROTECTED]>
<http
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Not really, see the reply I sent to the checkin mail.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
The behavior observed is intentional. The docs should be updated.
--
nosy: +gvanrossum
resolution: -> rejected
status: open -> closed
___
Python tracker <[EMAIL PR
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I want to make this "bypass getattr" behavior mandatory for those
operations that currently use it, forcing the issue for other
implementations of Python. That's a doc change (but an important one!).
There are probab
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I say let's go with the cleanup. Extensions that want to be compiled
under 2.x and 3.0 will need lots of #ifdef code anyway.
--
nosy: +gvanrossum
___
Python tracker <[EMAIL PRO
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
If it's only failing during the second run of "make test", typically
there's some implicit dependency on something that is disturbed by
running a test that's later in the suite of tests. This could be eith
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I should add this was in the trunk (2.6).
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Submitted as r64281.
We still need a doc patch and changes to the exception printing (perhaps
also to traceback.py). Please open new issues for those.
--
resolution: -> fixed
status: open
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
N.B. Benjamin made a typo in the revision, it's r64284.
--
nosy: +gvanrossum
resolution: fixed ->
status: closed -> open
___
Python tracker <[EMAIL PROTECTED]>
<http:/
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Mostly, but I *really* want to see unittests for this.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
assignee: gvanrossum -> rhettinger
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Yeah, let's just reject this. There doesn't appear to be much demand.
--
resolution: -> rejected
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<h
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Methinks this one is also better rejected. Please reopen if you feel
strongly.
--
resolution: -> rejected
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<h
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Raymond, mind if we roll back your previous (incorrect) changes? They
really should not have been submitted in the first place.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Thanks for your contribution!
To get this commmitted, please draw the attention of someone else on
python-dev (or if you're an IRC person try #python-dev at freenote,
IIRC). I'd recommend moving the tests into the exis
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Rejecting. Too much risk as well, based on experience in the past with
supposedly harmless optimizations.
--
resolution: -> rejected
status: open -> closed
___
Python tracker <[
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
+1 on removing the trailing L from the repr.
+0 on trying to reduce the values to ints; that would be dead-end code
since in 3.0 it's a non-issue. And it doesn't solve the problem with repr.
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'm going to have to ask someone else to look at this code. I am too
busy with too many things to be able to take on a detailed code review.
--
assignee: gvanrossum ->
___
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Thanks for giving this some time. I think that backwards compatibility
should be a higher priority than being able to issue -3 warnings -- if
the warnings can't be generated, too bad, we'll just have to document
it. (I
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I think it's okay to accept Fraction('1.23', 1) -- if only because
rejecting it means changing the default for the 2nd arg to None and that
would slow it down again.
I agree that if the type of the 2nd arg isn'
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Don't do this for 2.5 please.
--
nosy: +gvanrossum
versions: +Python 3.0 -Python 2.5
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Sounds like re.UNICODE should be on by default when the pattern is a str
instance.
Also (per mailing list discussion) we should probably only allow
matching bytes when the pattern is bytes, and matching str when the
pattern
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
That's fine.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1682>
___
___
P
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Probably by design. There's probably even a unittest for this behavior.
--
nosy: +gvanrossum
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
There are tons of ways to violate Liskov in Python. Liskov is not always
the right rule.
NotImplemented is not appropriate -- it is only used as a magic return
value from binary functions.
--
resolution: -> rejected
sta
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'd like to reopen this. I'm still in favor of something like to this
algorithm:
def float_repr(x):
s = "%.16g" % x
if float(s) != x:
s = "%.17g" % x
s1 = s
if s1.startswith('-'):
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Raymond, Mark? Is a new patch with tests and docs forthcoming? Have
you decided on the API yet? I'm willing to approve this for beta 2,
which will be around July 15.
--
assignee: gvanrossum -&
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Here's a rough-and-tumble implementation of that idea, for Py3k.
Added file: http://bugs.python.org/file10808/float.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
That is truly maddening! :-(
I guess Noam's proposal to return str(x) if float(str(x)) == x makes
more sense then. I don't really care as much about 1.234567890123 vs.
1.234567890122 as I care about 1.2345 vs. 1.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
BTW couldn't you use the %a feature built into C99 to implement this?
(Both input and output?)
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On Fri, Jul 4, 2008 at 7:12 AM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
>
> Mark Dickinson <[EMAIL PROTECTED]> added the comment:
>
> Sure. What about non-C99 machines? I thought Python code was only
&g
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Here's a fixed patch, float2.diff. (The previous one tasted of an
earlier attempt.)
Added file: http://bugs.python.org/file10840/float2.diff
___
Python tracker <[EMAIL PRO
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
FWIW some comments by Amaury are here:
http://codereview.appspot.com/483
--
nosy: +gvanrossum
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Does anyone care about this still?
I added some comments on
http://codereview.appspot.com/504
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
IMO the generator expression is wrong in interpreting the StopIteration
as a break. It should fail just like the list comprehension fails.
--
nosy: +gvanrossum
___
Python tracker &
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Can we make sure this is fixed for beta 3? (Beta 2 would be great too,
but it's getting late.)
--
nosy: +gvanrossum
priority: -> deferred blocker
___
Python tracker <[EMAIL
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
If you two can agree that this code is good, I'm ok with the API.
I would emphasize in the docs and NEWS entry though that .hex() is an
*instance* method while .fromhex() is a *class* method.
___
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Does anybody still care about this?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
When a second 'make' fixes things, that usually means that there's a
dependency on another extension that is built later in the normal build
sequence. I vaguely we had this before and fixed it by reordering things.
Gr
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Here is the output of python -v during "import _multiprocessing". Maybe
this gives someone a clue?
>>> import _multiprocessing
dlopen("/Users/guido/p3/build/lib.macosx-10.3-i386-3.0/_multiprocessing.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
The order thing was a red herring. However, I understand what's going
on now. Somebody else can fix it hopefully.
So what's going on: In the Python instance that runs setup.py,
importing _multiprocessing fails. But
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I've checked in a fix (r65063) that simply clear sys.path_importer_cache
right before the attempted import of the freshly-built extension. This
seems to work.
--
assignee: jnoller -> gvanrossum
resolution: -> f
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I know this has been closed, but perhaps the fieldnames attribute could
be made into a property that reads the first line of the file if it
hasn't been read yet?
--
nosy: +gvanrossum
___
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
Give your lady only the very best, find out how here http://www.pinehelp.com/
--
messages: 70414
nosy: gvanrossum
severity: normal
status: open
title: Satisfy her lovemaking desire
___
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Ping? Anyone cares about this?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2542>
___
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On the issue of whether len(range()) should be allowed to be >
sys.maxsize, I think this should be allowed. I think in the future we
should change the __len__ protocol to allow unbounded lengths. Even
today, I think range(10**100
New submission from Guido van Rossum <[EMAIL PROTECTED]>:
Attached is a verifier for the binary code used by the _sre module (this
is often called bytecode, though to distinguish it from Python bytecode
I put it in quotes).
I wrote this for Google App Engine, and am making the patch ava
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> 3. Google considered this enough of a potential problem to pre-emptively
> fix it. Now that that problem has been publicly exposed, other careful
> users will expect it to be fixed and will find Python more attractive
>
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Submitted to 2.6 as r65544.
Will propagate to 3.0 as it gets merged -- should be a perfect merge.
Antoine: the re module has tons of unittests; showing that attempts to
break in are thwarted would be pretty boring. ;-)
--
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
How's this coming along?
--
versions: +Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Agreed, this has been broken for a long time, and few people have
noticed or complained. Let's wait.
--
assignee: gvanrossum ->
versions: +Python 2.7, Python 3.1 -Python 2
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
The two segfaults reported in msg64682 are still there in 2.6.
I'm elevating this to release blocker but don't have time to fix this
myself.
--
assignee: gvanrossum ->
priority: critical -> release blocker
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Can someone other than me test and apply this? It seems still relevant,
and __cmp__ is not coming back.
--
assignee: gvanrossum ->
___
Python tracker <[EMAIL PROTE
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Won't have time myself.
--
assignee: gvanrossum ->
priority: critical -> normal
___
Python tracker <[EMAIL PROTECTED]>
<http:/
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Let someone else review this.
--
assignee: gvanrossum ->
priority: critical -> normal
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
How's this going?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2235>
___
_
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I think it's better to leave this alone. Such a subtle change is likely
to trip over more people in worse ways than the alleged "bug".
--
resolution: -> rejected
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Without a patch this will not improve.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
2.6 should keep the original cPickle, warts and all, for backwards
compatibility. I'd be okay though with also having _pickle there --
just don't call in cPickle (and don't import it
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Nobody seems to care enough.
--
resolution: -> rejected
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Let's see if we can fix this by beta3.
--
assignee: gvanrossum ->
priority: -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http:/
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Ping? Patch?
--
nosy: +gvanrossum
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Is this still relevant?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1309567>
___
_
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Great! The same cannot be said of the 3.0 version, which is on my plate.
I wonder if you have an opinion on what to do with features that were
initially targeted for 3.0 and then backported to 2.6. Should these
appear in "wh
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Definitely don't bring buffer() back in 3.0! It needs to die.
If 2to3 can do this reasonably well, let's do that.
--
nosy: +gvanrossum
___
Python tracker <[EMAI
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Thanks for the feedback, I'll do that. I have 50% time instead of 20%,
though it doesn't feel that way lately. ;-)
___
Python tracker <[EMAIL PROTECTED]>
<http://
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Let's make sure the release manager is OK with this.
--
nosy: +barry
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Bill Janssen's "patch" breaks two unittests: test_email and
test_http_cookiejar. Details for test_email:
==
ERROR: test_rfc2231_bad_
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> Well, if it can't replace buffer() then the warning needs to change to
> just flat-out state that buffer() is gone and not suggest any
> replacement.
+1. buffer() stinks. memoryview() rules. They don't hva
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Dear GvR,
New code review comments by GvR have been published.
Please go to http://codereview.appspot.com/2827 to read them.
Message:
Hi Matt,
Here's a code review of your patch.
I'm leaning more and more towards want
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
IMO it would be better not to confuse matters my having os.fsync() call
fullfsync(); it's better to add a separate os.fullfsync() call on
platforms that support it. That way the application can choose. I
suppose Apple had a
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Does this occur in 2.6 or 2.5?
--
nosy: +gvanrossum
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
It's straightforward if you consider the implementation of the
requirement that %% renders a single percent sign: the second % is
parsed just like any other formatting code (i, d, f, etc.) and the stuff
between the firs
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Based on discussion in python-dev, I'm rejecting this patch.
Open a new one if you want to make F_FULLSYNC available.
--
resolution: -> rejected
status: open -> closed
_
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On Thu, Aug 7, 2008 at 8:03 AM, Matt Giuca <[EMAIL PROTECTED]> wrote:
>
> Matt Giuca <[EMAIL PROTECTED]> added the comment:
>
> I'm also attaching a "metapatch" - diff from patch 7 to patc
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'm sorry to have lead you this way, but since there is no fullfsync()
system call, IMO you should just make the F_FULLFSYNC constant
available. That should go into fcntlmodule.c.
--
nosy:
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Thanks, checked into the trunk as r65581.
--
resolution: -> accepted
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On Thu, Aug 7, 2008 at 2:17 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
>
> Bill Janssen <[EMAIL PROTECTED]> added the comment:
>
> My main fear with this patch is that "unquote" will become seen
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Good catch!
This looks pretty simple to fix; I think a type check is missing
(actually several, there are at least two implementations in io.py).
In fact, the 2.6 version of io.py already has the necessary checks.
(But merging
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On Thu, Aug 7, 2008 at 3:58 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Bill Janssen <[EMAIL PROTECTED]> added the comment:
>> Your original proposal was to make unquote() behave like
>> unquote_to_bytes(
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Good find Alexandre! Can you work up a patch? Would be even better if
it had a unittest.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Wouldn't that be lots and lots slower? I believe speed is one of the
reasons why the binary representation is currently dumped.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> Instead of sticking to network byte order, I propose to include byte
> order information in the pickle (for example as '<' or '>' like struct
> does), so that pickling/unpickling between the same-e
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> Matt Giuca <[EMAIL PROTECTED]> added the comment:
> By the way, what is the current status of this bug? Is anybody waiting
> on me to do anything? (Re: Patch 9)
I'll be reviewing it today or tomorrow. From loo
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On Wed, Aug 13, 2008 at 7:25 AM, Matt Giuca <[EMAIL PROTECTED]> wrote:
>> I have no strong opinion on the very remaining points you listed,
>> except that IMHO encode_rfc2231 with charset=None should not try to
>
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
>> Now that you've spent so much time with this patch, can't you think
>> of a faster way of doing this?
>
> Well firstly, you could replace Quoter (the class) with a "quoter"
> function
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
> Bill Janssen <[EMAIL PROTECTED]> added the comment:
>
> Erik van der Poel at Google has now chimed in with stats on current URL
> usage:
>
> ``...the bottom line is that escaped non-utf-8 is still quite prev
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11107/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11106/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
901 - 1000 of 5563 matches
Mail list logo
