Guido van Rossum added the comment:
> FWIW, should PyUnicode_Check, PyTuple_Check etc. also change to
> PyUnicode_CHECK, PyTuple_CHECK etc because they are macros?
While this would technically be the right thing to do, those macros
have had a long and productive life before 2.6 so I'
Guido van Rossum added the comment:
Committed revision 59574.
I added a simple C API as well, PySignal_SetWakeupFd(fd).
Thanks all!
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Guido van Rossum:
--
assignee: -> gvanrossum
keywords: +patch
nosy: +gvanrossum
priority: -> normal
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum added the comment:
Sigh. I'll try to make time to review & apply this.
--
assignee: -> gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Guido van Rossum added the comment:
Martin, can you have a look at this?
Cartman, can you produce a unittest for the correct behavior that only
uses ASCII input (using \u instead of just typing Turkish characters)?
--
assignee: -> loewis
nosy: +loe
Guido van Rossum added the comment:
Hm. The test2.py file, when I download it, contains the two bytes
"\xc4\xb1" in the first unicode() call, and "\xc4\xb0" in the second
one. This is *always* supposed to produce a UnicodeDecodeError, since
it would use the default encoding
Guido van Rossum added the comment:
> Replacing Turkish characters with hex versions in test2.py still results
> in UnicodeDecodeError and works with python 2.4.
I'm hoping Martin can confirm this, but I suspect that this is due to
a tightening of the rules for converting from 8-bit
Guido van Rossum added the comment:
Committed revision 59576.
I found some time.
Happy pybotting!
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum added the comment:
I disagree that this would be harmless; this was excluded intentionally.
A (bound) method contains an instance which definitely represents state
and calling the method can easily mutate that state.
This is different from classes (which could contain state
Guido van Rossum added the comment:
I can't reproduce this.
How did you install Python?
Python 2.5.2a0 (release25-maint, Nov 27 2007, 14:00:00)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "lice
Guido van Rossum added the comment:
> print u"\u0069".upper()
>
> should give \u0130 (LATIN CAPITAL LETTER I WITH DOT ABOVE)
>
> print u"\u0049".lower()
>
> should give \u0131 (LATIN SMALL LETTER DOTLESS I)
>
> These transformations work fine with p
Guido van Rossum added the comment:
Then I suggest you talk to the Ubuntu developers or whoever packaged
Python 2.5.1 for it.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Guido van Rossum added the comment:
> I tried downloading the latest rev of urlparse.py (59480) and it flunked
> its own unit test, "urlparse.test()" Two test cases fail.
That's not the official test -- that code should probably be deleted.
The real test is in Lib/
Guido van Rossum added the comment:
> But it should be affected by locale, thats the point of locale.setlocale
> call. This is how libc's wc functions behave.
No, the locale should only affect 8-bit string operations, never
unicode operations.
__
Trac
Guido van Rossum added the comment:
> Ok then what is the suggested way to get back the Turkish way of doing
> upper/lower on i & I ?
That's a question for Martin von Loewis. I suppose you could use 8-bit
strings exclusively. Or you could use .translate() wit
Guido van Rossum added the comment:
Martin, I'm asking you because according to svn blame I copied this from
the int/long integration branch last January.
I looked at the code of _PyLong_FitsInLong(), and I don't understand why
it wants an exact integer. The code
Guido van Rossum added the comment:
I'll take this off line.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1515>
__
___
Python-bugs-list mailing list
U
Guido van Rossum added the comment:
Well, if they do that, they apparently break inspect.py. Should they
be doing that? Why are they doing that? Can you contact the Ubuntu
folks about this?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Guido van Rossum added the comment:
Tickle the interest of one of the many folks with commit privileges.
Since 2.6 isn't going to be released for months there's no great hurry,
but waiting until the last minute would be a mistake.
__
Tracker <[EM
Guido van Rossum added the comment:
If there aren't too many differences between the 2.6 and 3.0 version of
decimal.py and your patch, do 2.6 first, then the next time we merge
stuff into 3.0 from the trunk it'll be forward-ported automatically.
Though you'd have to start
Guido van Rossum added the comment:
> Funnily,
>
> print "".encode("iso-8859-9").decode("iso-8859-9").upper()
>
> works, but
>
> print "".encode("iso-8859-9").upper().decode("iso-8859-9")
>
> not.
Guido van Rossum added the comment:
Maybe the original author (Barry Warsaw) can review this?
--
assignee: -> barry
nosy: +barry, gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Guido van Rossum added the comment:
Two easy ways to get the functionality using 8-bit strings, assuming
you've already set your locale properly:
(1) If your data is already an 8-bit string (i.e. isinstance(data,
str)), simply use data.upper() or data.lower()
(2) If your data is Unicode
Guido van Rossum added the comment:
This can't be fixed directly -- the pthreads mutex is not an
interruptable system call.
However there's a simple (though expensive) work-around: use a very long
timeout. The timeout version of waiting for a lock is a busy-wait with a
short sleep
Guido van Rossum added the comment:
I think you misunderstand raw_input(). It just returns
sys.stdin.readline().rstrip("\n"). I don't think it's worth fixing.
The 'q' processing works fine as long as you didn't type \r first. :-)
--
nosy: +gvanros
Guido van Rossum added the comment:
I believe its original intent was to only ignore variables starting with
PYTHON, but I'm not 100% sure. Ignoring PATH seems counterintuitive.
I'm not sure about THREADDEBUG -- I'm thinking that variable should be
renamed PYTHONTHREADDEBUG?
BT
Guido van Rossum added the comment:
I agree with Tesiph, more useful behavior would be to raise an error
immediately because the argument is not a directory. If you wanted to
remove the think linked to, you could use rmtree("foo/.",
ignore_errors=True).
--
nosy: +
Guido van Rossum added the comment:
Fixed in 2.6.
Committed revision 59582.
3.0 will follow at the next merge.
--
keywords: +patch
nosy: +gvanrossum
resolution: -> accepted
status: open -> closed
versions: +Python 2.6 -Python 3.0
__
Tracker &
Guido van Rossum added the comment:
Very odd. Can you experiment with input() and sys.stdin.readline() to
see what exactly gets returned? It seems that somehow the CRLF -> LF
translation isn't working, and that should be fixed somewhere else,
not in license().
I imagine you could just
Guido van Rossum added the comment:
Thanks for the patch. I think it should raise IOError, not ValueError,
and it should use the onerror() handling used for all other errors.
Also, can you include an update for the docs in the Doc tree?
__
Tracker <[EM
Guido van Rossum added the comment:
> >>> len(x)
Please print repr(x). That should be safe even if it contains control
characters.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Guido van Rossum added the comment:
> >>> import sys
> >>> x = input()
> Hi:
> >>> repr(x)
> "'Hi:'"
> >>> x = sys.stdin.readline()
> Hi:
> >>> repr(x)
> "'Hi:\\n'"
Hm, that works a
Guido van Rossum added the comment:
Ah d'oh!
The 3.0 code was wrong. I've fixed it now in SVN by going back to input()
Committed revision 59583.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Guido van Rossum added the comment:
I think we can fix this as follows: whenever it calls os.mkdir() and an
error is returned, check if that is EISDIR or EEXISTS, and if so, check
that indeed it now exists as a directory, and then ignore the error.
Moreover, I'd like to do this for the ult
Guido van Rossum added the comment:
Can you rephrase this as svn diff output?
Also, mkdir() is a confusing name for the helper -- I'd call it
forgiving_mkdir() or something like that.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Changes by Guido van Rossum:
--
assignee: -> gvanrossum
nosy: +gvanrossum
priority: -> normal
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1679>
__
Changes by Guido van Rossum:
--
assignee: -> gvanrossum
nosy: +gvanrossum
priority: -> normal
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1682>
__
Guido van Rossum added the comment:
On the one hand, if you want to format a float like that, you should use
"%.0f". On the other hand, this should either consistently fail or
succeed, not depending on how large the float is.
I think in 2.6 we can't change this, but in 3.0, I p
Guido van Rossum added the comment:
Committed revision 59636.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum added the comment:
Committed revision 59646.
--
nosy: +gvanrossum
resolution: -> accepted
status: open -> closed
type: -> behavior
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from Guido van Rossum:
Should I apply this? There are more places that reference __cmp__ in
the library. OTOH there are some folks who would like to see __cmp__
make a come-back as a shorthand for defining 6 comparison operators, for
totally-ordered types. (I'm still wa
Guido van Rossum added the comment:
Go ahead then!
--
assignee: -> tiran
nosy: +gvanrossum
resolution: -> accepted
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum added the comment:
This should be fixed. Maarten, can you create a patch that works for
you? (Since few of us have access to the platform where it breaks.)
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Guido van Rossum added the comment:
Maarten, can you build Python 2.6 from svn? (See
http://www.python.org/dev/faq/#subversion-svn for help.)
It looks like this has been fixed there, per r53434. Perhaps the same
changes can be backported.
__
Tracker <[EM
Changes by Guido van Rossum:
--
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1718>
__
___
Python
Guido van Rossum added the comment:
I don't see a bug here. It is as Amaury explains.
--
nosy: +gvanrossum
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Guido van Rossum added the comment:
Looks like a doc change that Georg could easily apply.
--
assignee: nnorwitz -> georg.brandl
nosy: +georg.brandl, gvanrossum
priority: -> low
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum added the comment:
I see this too. Maybe Fredrik understands?
--
assignee: -> effbot
nosy: +effbot, gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Guido van Rossum added the comment:
Good catch!
Committed revision 59659.
I wonder how many other places have the same problem...
--
nosy: +gvanrossum
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://
Changes by Guido van Rossum:
--
assignee: -> vsajip
nosy: +vsajip
priority: -> low
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1709>
__
__
Guido van Rossum added the comment:
Actually, only the f.close() call should be conditionalized.
Does this patch fix the issue for you?
--
assignee: -> gvanrossum
nosy: +gvanrossum
priority: -> normal
Added file: http://bugs.python.org/file9040/distutil
Guido van Rossum added the comment:
site.py is already fixed in svn; it actually did cause problems, see
issue #1667.
I fixed pydoc.py.
Committed revision 59660.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Guido van Rossum added the comment:
I'm not a big distutils expert myself, I can't quite interpret your
feedback. In dry-run mode, it shouldn't try to copy the script, correct?
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
&l
Guido van Rossum added the comment:
How about 2.6?
--
assignee: -> loewis
nosy: +gvanrossum, loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Guido van Rossum added the comment:
So that's correct behavior right? (I looked at the code for copy_file()
in cmd.py and it passes the dry_run parameter to the file utility
function that does the actual copying.
__
Tracker <[EMAIL PROTECTED
Changes by Guido van Rossum:
--
assignee: -> georg.brandl
nosy: +georg.brandl
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1722>
__
___
Python-bu
Guido van Rossum added the comment:
Committed revision 59668. (2.5 branch)
Committed revision 59669. (2.6 trunk)
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum added the comment:
So what's the correct fix? Skip the whole block if size==0?
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Guido van Rossum added the comment:
I'll look at this when I have time. If you find someone else interested
in reviewing, please give them the patch!
--
assignee: -> gvanrossum
keywords: +patch
nosy: +gvanrossum
priority: -> low
__
Trac
Guido van Rossum added the comment:
Yup. Same if the exception comes in a file. I'll try to free up some
cycles to look into this. Thanks for the report!
--
assignee: -> gvanrossum
nosy: +gvanrossum
__
Tracker <[EMAIL PROTEC
Guido van Rossum added the comment:
Could you please add a unit test for this? Then I can check it in.
I'm thinking this could safely be fixed in 2.5.2.
--
assignee: -> gvanrossum
nosy: +gvanrossum
resolution: -> accepted
__
Tracker <[E
Changes by Guido van Rossum:
--
resolution: -> wont fix
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1205>
__
___
Python
Changes by Guido van Rossum:
--
nosy: -gagenellina
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1723>
__
New submission from Guido van Rossum:
Since 1e-1000 == 0.0 (on an IEEE-754 platform anyway), I would expect
-1e-1000 to be -0.0. But it does not appear that way:
>>> 1e-1000
0.0
>>> -0.0
-0.0
>>> -1e-1000
0.0
However (correctly):
>>> (-1.0) * 1e-1000
-0.
Guido van Rossum added the comment:
BTW this was on x86 Linux. On x86 OSX (10.4, Tiger) it works correctly:
>>> -1e-1000
-0.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Guido van Rossum added the comment:
One nit: you added a blank line to the end of test_math.py.
This will cause the checkin to fail. :-)
One bigger issue: the sign() function doesn't seem to work properly for
nans. E.g. on Linux I get:
>>> inf = 1e1000
>>> nan =
Guido van Rossum added the comment:
Can you produce a version of the patch that applies cleanly to 2.6? Then
we can apply it there first and merge into 3.0 later.
But I wonder. It seems this changes every single call to
PyImport_ImportModule() in the core to _PyImport_ImportModuleNoLock
Guido van Rossum added the comment:
I'm just following the last post's suggestion "Should we close this then?"
My message (somebody "should" submit a patch) was sarcastic --- it was
in reference to the comment that Python "should" be more practical.
Sinc
Guido van Rossum added the comment:
I think I understand what's going on. The trail leads from the last "if
(tty) {" block in builtin_input() to PyOS_Readline() which in turn ends
up calling PyOS_StdioReadline() (because that's the most likely
initialization of PyOS_Rea
Guido van Rossum added the comment:
> > One nit: you added a blank line to the end of test_math.py.
> > This will cause the checkin to fail. :-)
>
> *grr* stupid white space check hook
No, you edited a line that didn't need editing. :-)
> > One bigger issue: the si
Guido van Rossum added the comment:
I see. I think there's still something uncomfortable with this function
though -- it looks in sys.modules, but if it doesn't find it there, it
invokes the full-blown import machinery, which calls the (possibly
overridden) __import__ builtin, whi
Guido van Rossum added the comment:
Cool.
I suspect Unix will also require a customized version to be used in case
GNU readline isn't present.
And I wouldn't be surprised if GNU readline itself doesn't handle UTF-8
properly either!
__
Tracker &l
Guido van Rossum added the comment:
Committed revision 59674. (2.5.2 branch)
Committed revision 59675. (2.6 trunk)
--
resolution: -> fixed
status: open -> closed
versions: +Python 2.6, Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://
Changes by Guido van Rossum:
--
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1729>
__
___
Python
Guido van Rossum added the comment:
> Why not implement copysign? It's a standard, familiar function with well-
> documented meaning all over the web, and it can easily be used to create
> whatever sign test is necessary, letting the user decide what results
> (s)he wants for
Guido van Rossum added the comment:
> Guido van Rossum wrote:
> > Good idea. Since you seem to like providing patches, can you create
> > one for math.copysign()?
>
> Don't forget it's copysign() on Unix but _copysign() on Windows.
>
> #if defined(MS_WINDOW
Guido van Rossum added the comment:
Can't repro either.
I strongly suspect that this is because somehow linecache finds a
different version of the module on sys.path.
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Guido van Rossum added the comment:
Can you trace this a bit further? Can you suggest a specific
modification that would fix this issue?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Guido van Rossum added the comment:
I suspect the assert is an overflow check. But since asserts are
compiled into no-ops unless we're using debug mode, I don't see the
point of using an assert. Just to close the issue I'll replace it with
a proper overflow check.
Guido van Rossum added the comment:
Before I make a fool out of myself, what do folks think of this patch?
Added file: http://bugs.python.org/file9052/tkinter.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Guido van Rossum added the comment:
OK, just check it in then, but do add docs!
On Jan 3, 2008 2:03 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
>
> Christian Heimes added the comment:
>
> Guido van Rossum wrote:
> > Well, the Python API in the math module should a
Guido van Rossum added the comment:
Do you happen to be on Ubuntu?
Maybe this is the same as issue #1665 ?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1728>
__
__
Guido van Rossum added the comment:
This has been fixed in 2.6, see revision 57216.
We won't be fixing this in 2.4, although a vendor might consider this.
Should we be fixing this in 2.5?
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED
Guido van Rossum added the comment:
Committed revision 59685. (2.5.2 branch)
Committed revision 59686. (2.6 trunk)
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum added the comment:
Ping? I was hoping for a patch?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1243>
__
___
Python-bugs-list mailing list
Guido van Rossum added the comment:
No, backporting that to 2.5 isn't an option; it introduces a new feature
and breaks binary backwards compatibility by removing the
PyImport_ImportModuleEx entry point from the executable (turning it into
a macro).
--
assignee: gvanrossum ->
Guido van Rossum added the comment:
Let's close this unless there's a response from one of the original
stakeholders within a week (i.e. by Jan 11 2008).
--
keywords: +patch -64bit
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Guido van Rossum added the comment:
OK, accepted for 2.5 and 2.6.
Can someone with a stake and submit access (e.g. lemburg) check it in?
--
assignee: -> lemburg
resolution: -> accepted
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Guido van Rossum:
--
resolution: -> duplicate
status: open -> closed
superseder: -> re.match.func_code.co_filename returns "re.py"
__
Tracker <[EMAIL PROTECTED]>
<http
Guido van Rossum added the comment:
I just don't see this happening. Possibly it's out of date. Lots of
things have changed in the pickle world since 2002.
--
resolution: -> wont fix
status: open -> closed
Tracker <[EMAI
Guido van Rossum added the comment:
Hm, perhaps I misinterpreted the discussion. If no patch is necessary,
please close as won't fix or invalid.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Guido van Rossum added the comment:
Looks okay, but needs docs.
--
nosy: +gvanrossum
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1089358>
_
___
Guido van Rossum added the comment:
Then let's leave well enough alone. I believe Greg Ward doesn't usually
respond to queries about optparse, but I'm assigning it to him anyway in
case his interest is piqued. But for now, let's close this.
--
assignee: -
Guido van Rossum added the comment:
Mind if I assign this to Facundo? Facundo, if you wish to pass this on,
just unassign it.
--
assignee: effbot -> facundobatista
nosy: +gvanrossum
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org
Guido van Rossum added the comment:
I'm sorry, but can you rephrase that in the form of a patch? I can't
quite figure out what you're trying to say, except that it sounds like
it's scratching an itch of yours.
--
nosy: +gvanrossum
__
Guido van Rossum added the comment:
looks good.
--
assignee: gvanrossum -> jyasskin
resolution: -> accepted
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum added the comment:
Committed revision 59725.
Thanks for the fix, Mark! This issue is a great example of how our
development process works well.
I propose not to backport this to 2.5.2, it's a rather minor issue and
who knows what user code might depend on the existing
Guido van Rossum added the comment:
PS. I reformatted some long lines in the patch. In general, I like to
keep all lines < 80 chars, in both C and Python code.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Guido van Rossum added the comment:
I think it's fine to accept this (once the remaining issues are
resolved) -- it's a remarkably small patch.
Regarding TCGETA, perhaps the issue is that it isn't defined unless
is included? While Python doesn't USE it, it exports it
fr
Guido van Rossum added the comment:
Committed revision 59726.
This is in the trunk (2.6). Do you need this backported to 2.5.2 as well?
--
keywords: +patch
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
1201 - 1300 of 5533 matches
Mail list logo
