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
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
nosy: +gvanrossum
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3555>
___
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I worry that many things were not recoded in Misc/NEWS at all,
especially in the early days of 3.0 development (e.g. in the p3yk branch
:-).
I'm not sure if it's possible to fix this retroactively, however. As
long as we
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
nosy: +gvanrossum
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3572>
___
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Looking into this now. Will make sure it's included in beta3.
--
assignee: -> gvanrossum
priority: -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http:/
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Checked in patch 10 with minor style changes as r65838.
Thanks Matt for persevering! Thanks everyone else for contributing;
this has been quite educational.
--
resolution: -> accepted
status: open
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Reviewers: GvR,
Message:
Looks good. Go ahead and submit, assuming you've run full tests.
Description:
http://bugs.python.org/issue3560
Please review this at http://codereview.appspot.com/3003
Affected files:
Include/mem
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
PS. The PEP probably needs an update. And the docs.
http://codereview.appspot.com/3003
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
On 2008/08/19 17:18:45, GvR wrote:
> PS. The PEP probably needs an update. And the docs.
And Misc/NEWS
http://codereview.appspot.com/3003
___
Python tracker <[EMAIL PROTECTED]>
<http
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I like Armin's latest proposal: have Py_TPFLAGS_DEFAULT include
Py_TPFLAGS_HAVE_VERSION_TAG when compiling the core only. ISTR there's
a way to do this, but I can't find it right now.
_
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Please review the patch here: http://codereview.appspot.com/3005
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Submitted as r65874.
I will block this for 3.0; 3.0 extensions that want to mess with tp_dict
must explicitly disable this flag.
--
resolution: -> fixed
status: open -> closed
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Looking into this now.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1179>
___
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Latest patches applied to 2.5 branch: r65878.
And to 2.6 trunk: r65880.
--
resolution: -> accepted
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<h
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Sure, go right ahead.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1878>
___
__
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Did someone fix xmlrpc.client:1168 yet?
IMO it's okay to add encodebytes(), but let's leave encodestring()
around with a deprecation warning, since it's so late in the release cycle.
---
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Duly accepted. (Though if someone has a quick fix I'd be open to it. :-)
--
assignee: -> gvanrossum
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I think it's fine as it is. Incrementing the stack level more frequently
is a good thing since there used to be paths that didn't increment it at
all and hence could cause segfaults. The default is conservative since
inc
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
This will definitely not be in 2.6.
--
keywords: -26backport
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
The proper work-around is for the app to pass bytes into os.listdir();
then it will return bytes. It would be nice if open() etc. accepted
bytes (as well as strings of course), at least on Unix, but not
absolutely necessary -- t
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
So shutil should be fixed to pass a bytes value to os.listdir(). But
then os.remove() should be fixed to accept bytes as well. This is the
crux I believe: on Unix at least, syscall wrappers should accept bytes
for filenames. An
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
>> I do not accept an os.listdir() that raises an error because one
>> filename cannot be decoded. It sounds like using errors='replace' is
>> also wrong -- so the only solution is for os.listdir() to skip
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I'm not interested in the InvalidFilename class; it's an API
complification that might seem right for your situation but will hinder
most other people. However I *am* interested in a patch that makes
os.unlink() (a
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
See http://codereview.appspot.com/3055 for a code review of Victor's
latest patches.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Looks okay, although my taste would be to let the calls to
source_as_string() be slightly more verbose and include the "string,
bytes" part. While that has a little more redundancy, it is easier to
read, and possibly ea
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
I wonder if we shouldn't hold off on this. It's a substantial amount of
new code. I'd be fine with it going into 3.0.1 since it's pure
optimization (IIUC!). But right now we want
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
To be honest, I don't see any harm in adding this now, especially since
rc1 hasn't been released yet.
--
nosy: +gvanrossum
___
Python tracker <[EMAIL PROTECTED]>
&
Changes by Guido van Rossum <[EMAIL PROTECTED]>:
--
priority: -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3780>
___
_
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Yes, please move this to 3.0.1 / 2.6.1. The hard part appears to be
making sure that it compiles *and* is correct on all conceivable
platforms...
___
Python tracker <[EMAIL PROTECTE
Guido van Rossum <[EMAIL PROTECTED]> added the comment:
Making this into a release blocker just so someone will look at it.
Needs to be decided & fixed by rc2 at the very latest.
--
nosy: +gvanrossum
priority: high -> release blocker
_
901 - 1000 of 5533 matches
Mail list logo
