Guido van Rossum added the comment:
Yup, thanks! Can you submit it and close this?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1692>
__
___
Python-bugs-list
Guido van Rossum added the comment:
I'll review this when I have time. Thanks! If you want speedier
response, please find someone else among the core developers; or perhaps
the bug day on Jan 19 will help.
--
assignee: -> gvanrossum
_
Guido van Rossum added the comment:
I'm okay with this feature, and the patch looks fine, except I don't
like the names used. It's not really about "read-only-ness" of
bytecode, it's about whether we write certain files. I'd suggest naming
the envvar
Guido van Rossum added the comment:
I checked in your change and made up a test.
Committed revision 59758.
Thanks!
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum added the comment:
"dont" is a pretty common contraction (see e.g. telnet.py).
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue602345>
_
Guido van Rossum added the comment:
Given how long this has been sitting without action, it's ludicrous to
keep it at "high" priority. I'm also taking it away from Jermy since
his interest must be minimal by now. And I'm removing 3.0 since it has
a completely different
Guido van Rossum added the comment:
Backport to 2.5.2:
Committed revision 59760.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1637>
__
___
Python-bugs-list
Guido van Rossum added the comment:
Sounds like a plan. Can you cook up a patch? Otherwise perhaps the Jan
19 bug day can look into this?
--
priority: -> low
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Guido van Rossum added the comment:
Something for the bug day on Jan 19.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1491>
__
___
Python-bugs-list
Guido van Rossum added the comment:
Something for the bug day on Jan 19?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1492>
__
___
Python-bugs-list
Guido van Rossum added the comment:
That solution (return NotImplemented instead of False) appears to work.
Committed revision 59761.
Thanks for bringing up this regression w.r.t. 2.5!
--
resolution: -> fixed
status: open -> closed
__
Tracker &
Guido van Rossum added the comment:
To resolve this, how about this patch (getenv.2.diff)?
- change getenv("PYTHONCASEOK") -> Py_GETENV() (inside #ifdef PYOS_OS2)
- rename THREADDEBUG -> PYTHONTHREADDEBUG and use Py_GETENV()
Added file: http://bugs.python.org/file90
Guido van Rossum added the comment:
Looks good, please commit!
(Christian: the problem with using PYC in the envar name is that it is
ambiguous about what happens to PYO files...)
--
resolution: -> accepted
Tracker <[EMAIL PROTECTED]&
Guido van Rossum added the comment:
PS the patch still has a problem:
Python/pythonrun.c:177: error: ‘Py_ReadOnlyBytecodeFlag’ undeclared
(first use in this function)
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/is
Guido van Rossum added the comment:
lgtm
--
resolution: -> accepted
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1747>
__
___
Python-bugs-li
Guido van Rossum added the comment:
I was about to check this in, when I noticed that the test runs for ~16
seconds on my state-of-the-arg hardware. I think that's too long.
Perhaps it should only be run when -ulargefile is enabled?
__
Tracker <[EMAIL P
Guido van Rossum added the comment:
Bug day candidate? 2.5.2 backport candidate.
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Guido van Rossum added the comment:
Thanks for tackling this!
What line in test_collections.py is calling a function with >255 args?
I'm a bit surprised since this has always been disallowed AFAICT.
I'd like to see everything related to keyword-only args included in one
patch.
Changes by Guido van Rossum:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1745>
__
___
Python-bugs-list mailing list
Unsubs
Guido van Rossum added the comment:
Alan and Eric, can I depend on you two to review each other's code and
let me know when you think the patch is ready to be submitted?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Guido van Rossum added the comment:
Sounds like a plan.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1526>
__
___
Python-bugs-list mailing list
Unsubs
Guido van Rossum added the comment:
Any chance of uploading a single patch that contains all these changes?
The profile tests often fail when io.py changes because they happen to
depend on "golden output" which includes line numbers of code in io.py
that happens to be traced during th
Guido van Rossum added the comment:
Crys, can you confirm this?
It would seem we'll need to fix this twice -- once for 2.x, once for 3.0.
--
nosy: +gvanrossum, tiran
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Guido van Rossum added the comment:
I recall being bitten by this too when first trying to use the logging
module.
I think the behavior is intentional, but I suppose it could be
documented better.
--
assignee: -> vsajip
nosy: +gvanrossum, vsajip
priority: -&g
Guido van Rossum added the comment:
3.0 will be a long way away for many users. Perhaps forcing English
isn't so bad, as Python's own error messages aren't translated anyway?
__
Tracker <[EMAIL PROTECTED]>
<http://b
New submission from Guido van Rossum:
As of today, the -m option doesn't appear to work any more in the trunk.
I get this error:
$ ./python -m string
Could not import runpy module
$
However it seems to be confused:
$ ./python -c 'import runpy'
$
IOW the module imports just
Guido van Rossum added the comment:
Bah. Environment error. Sorry!
--
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum added the comment:
Maybe just a doc update?
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1762972>
_
___
Python-bugs-list mailing list
Guido van Rossum added the comment:
Not yet, I ran out of time. Can you hold on for another week?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1657>
__
___
Pyth
Guido van Rossum added the comment:
There's something I misunderstand then. I thought 2.x also didn't
accept >255 args, but that test would seem to prove I'm wrong.
__
Tracker <[EMAIL PROTECTED]>
<http:
Guido van Rossum added the comment:
So if the input ends in '\n', '$' matches both before and after that
character, and two substitutions are made (even though multiline is not
set). Seems a bug to me.
--
nosy: +gvanrossum
__
Track
Guido van Rossum added the comment:
What change is responsible for the speedup? The cache check or removing
type(instance) from the set? Since type(instance) is usually the same
object as instance.__class__, the set will still have only one element
(in particular for Decimal this is the case
Guido van Rossum added the comment:
Then I'd say, this is the correct semantics, for better or for worse;
add an example to the docs, and a test to the test suite, and close this
as wont fix.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
New submission from Guido van Rossum:
We should either change the API so you can pass in a '<' comparator, or
get rid of it completely (since key=... takes care of all use cases I
can think of).
--
messages: 59575
nosy: gvanrossum
priority: normal
severity: normal
statu
Changes by Guido van Rossum:
--
components: +Interpreter Core
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1771>
__
___
Python-bugs-list mailing list
Guido van Rossum added the comment:
The intention was that the lowest-level (unbuffered) stream object can
write fewer bytes than given to it, as it is a direct interface to the
underlying system call, which has this property (especially when the
file is in non-blocking mode).
I think it's
Guido van Rossum added the comment:
Which is why I like to use \Z to match *only* the end of the string.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1761>
__
__
Guido van Rossum added the comment:
Raymond, do you *always* have to be such a grinch?
The mere existance of competing implementations proves that there's a
need. Hopefully having one in the stdlib will inspire others to
contribute improvements rather than starting from sc
Guido van Rossum added the comment:
Alexandre, which Python version did you compile with -Wstrict-overflow?
It would behoove us to check 2.5.2 thoroughly before it goes out the door.
I will contact Coverity to ask if they check for this kind of thing.
(They just upgraded us to "R
Guido van Rossum added the comment:
It would actually be better to use -fno-strict-overflow instead of
-fwrapv, if it exists (GCC 4.2 and later).
See also http://bugs.python.org/issue1621 which suggests there aren't
actually many places that need this; gcc -Wstrict-overflow should help
aud
Guido van Rossum added the comment:
Marc-Andre: what do you mean by breaking lots and lots of extensions?
Extensions also contain buffer overflow checks (at least I hope they do
:-) and those should also be guaranteed safe by using -fwrapv or
-fno-strict-overflow (GCC 4.2 and higher) until
Changes by Guido van Rossum:
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1731>
__
___
Python
Guido van Rossum added the comment:
The rejection of PEP 239 was years ago. PEP 3141 was accepted; it
includes adding a rational type to the stdlib, and Jeffrey is doing this
with my encouragement.
The motivation is to have at least one example of each type in our
modest numeric tower in the
Guido van Rossum added the comment:
Are you crazy? Adding new features to 2.5? No way!
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1381>
__
___
Python-bugs-
Guido van Rossum added the comment:
On Jan 9, 2008 4:29 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I think the history of rational modules is that simplistic
> implementations get built and then the writers find that exploding
> denominators limit their usefulness for anyt
New submission from Guido van Rossum:
I discovered that when converting a string to an int or float, the int
conversion allows whitespace after the sign, while the float conversion
doesn't. I think they should be consistent.
--
components: Interpreter Core
messages: 59641
Guido van Rossum added the comment:
I'd propose doing the same thing as int() and float(), which accept and
strip leading and trailing whitespace.
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Guido van Rossum added the comment:
Care to provide a patch?
Otherwise this may be a good bug day candidate. The next one's Jan 19.
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Guido van Rossum added the comment:
All in all, Decimal is the odd man out -- it may never become a full
member of the Real ABC. The built-in types complex, float and int (and
long in 2.x) all support mixed-mode arithmetic, and this is one of the
assumptions of the numeric tower -- and of course
Guido van Rossum added the comment:
> Would it be reasonable then to not have any of the numeric tower stuff
> put in the decimal module -- basically leave it alone (no __ceil__,
> etc)?
If that's the preference of the decimal developers, sure.
Guido van Rossum added the comment:
These are meant purely for the convenience of module initialization, and
there correct handling of reference counts in the light of failures is
of marginal importance. So while these may technically have leaks, you
shouldn't care.
--
Changes by Guido van Rossum:
--
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1784>
__
___
Python
Guido van Rossum added the comment:
Please submit a patch.
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1785>
__
___
Python-bugs-
New submission from Guido van Rossum:
When you type a command in pdb that happens to print something, the
output goes to sys.stdout, even if self.stdout references another file.
This makes it hard to debug code running inside a web server where
sys.stdout/stdout are connected to a socket (or a
Changes by Guido van Rossum:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1786>
__
___
Python-bugs-list mailing list
Unsubs
Guido van Rossum added the comment:
> Allowing leading and trailing whitespace causes failures in Cowlishaw's
> test suite. I guess Raymond's right: this bug report should be
> dismissed. It still bothers me a little that there isn't a strictly
> conforming imp
Guido van Rossum added the comment:
I'd say that accepting a trailing \n is a bug that should be fixed.
I think that ideally we'd be allowed to specify whitespace around the
value. I am always annoyed at programs that require me to type e.g. an
integer and don't let me put space
Guido van Rossum added the comment:
Moreover I think float is right and int is wrong.
Something to fix in 3.0, probably not in 2.6 (don't want to break too
much stuff that worked in 2.5).
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Guido van Rossum added the comment:
Sorry, there's just no way that this is going to be dealt with on the
Python core tracker. Who says it isn't memory corruption caused by some
Zope extension module...
--
nosy: +gvanrossum
resolution: -> rejected
status: o
Guido van Rossum added the comment:
So what's a hot key? Now I'm really confused. I don't recall anything
using scan codes in IDLE, at least not for the memory shortcuts etc.
__
Tracker <[EMAIL PROTECTED]>
<http://b
Guido van Rossum added the comment:
Not being familiar with localized keyboards, I don't understand your
question. Can you provide some screen dumps of what you see and explain
what you expected to see?
PS. What OS?
--
nosy: +gvanrossum
priority: -
Guido van Rossum added the comment:
> Do you want to be able to do Decimal("3 ") but not Decimal("3\n")?
I want either both or none, with a slight preference for both but only
if it can be done without breaking the spec.
The status quo is that "3 " is refused
Guido van Rossum added the comment:
IDLE is written using Tkinter, not native Windows UI programming APIs, I
don't know if the scan code is available in the keyboard events.
If you want something to happen on this, I suggest you try to create a
patch to IDLE yourself -- it's unlikel
Guido van Rossum added the comment:
I'll just withdraw it.
--
resolution: -> rejected
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Guido van Rossum added the comment:
With a newer compiler (GCC 4.0.1 on OSX 10.5.1) I still get some warnings:
/Users/guido/p25/Modules/_ctypes/libffi/src/x86/ffi_darwin.c:220:
warning: function declaration isn’t a prototype
/Users/guido/p25/Modules/readline.c: In function ‘flex_complete
Changes by Guido van Rossum:
--
status: pending -> open
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1616>
__
___
Python-bugs-list mailing list
Uns
Guido van Rossum added the comment:
Since this keeps coming up, I think it would make sense to turn this
into an optional extension module.
PS. The licensing concerns are another reason not to use this for the
core long (or int in Py3k) type.
--
keywords: +patch
nosy: +gvanrossum
Guido van Rossum added the comment:
I like the idea of exposing Python's command line flags, but I think
this API is a bit odd. I'd rather see it be a struct with members named
after the various arguments and values that are ints or bools -- or
simply a bunch of new flags directly
Guido van Rossum added the comment:
Well, what are you waiting for? Submit a patch!
--
keywords: +easy
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Guido van Rossum added the comment:
Can't you use a namedtuple? Then printing it would show the names of
the flags...
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Guido van Rossum added the comment:
I don't recall, but I suppose it had stopped working and nobody could be
found who wanted to maintain it. Possibly the Python-unfriendly license
was also a reason.
__
Tracker <[EMAIL PROTECTED]>
<http://b
Guido van Rossum added the comment:
> I'd rather see a better repr function for the
> sequence types.
Agreed. It's kind of unfortunate that we have two implementations for
the same concept, one in C and one in Python.
__
Tracker <[EMAI
Guido van Rossum added the comment:
Cool! Doesn't it feel good to rip out stuff? :-)
I do hope that you'll make sure all tests pass (-uall) before submitting
this.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Guido van Rossum added the comment:
Nice -- perhaps you can make it look like a function call,
posix.stat_result(st_mode=..., ...)? (Then someone else might finally
create a constructor with such a signature. :-)
__
Tracker <[EMAIL PROTECTED]>
Guido van Rossum added the comment:
To mark things for the bugday, set the 'easy' keyword.
However, this particular one is IMO too subtle for a bugday, witness the
discussion here. Perhaps a bugday could come up with an ultimate patch,
but I'd be hesitant to submit it without
Guido van Rossum added the comment:
I'm not sure what the point of that would be. Somebody might want to
send these asynchronously (using kill) which we might legitimately want
to catch. Also you don't know which other synchronous signals a
platform might define. I think at best a
Guido van Rossum added the comment:
How about a slight change to the proposed API, and make it a varargs
function? E.g.
operator.attrgetter('person', 'displayname')
This would avoid the need to parse the argument.
--
nosy: +gvanrossum
__
Guido van Rossum added the comment:
Fair enough. Fine with me then.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1826>
__
___
Python-bugs-list mailing list
Guido van Rossum added the comment:
> After more thought, I would like to make one more change and require the
> arguments to be keywords such as sort(key=str.lower) but not
> sort(str.lower).
Works for me. (To be honest I thought key was already required to be
Guido van Rossum added the comment:
> Since they are implementation details, they
> should have a "_" prepended to their names.
No, they are not, and they should not.
There are legitimate use cases for importing these directly. E.g. I
could be on a Windows box but have a desi
Guido van Rossum added the comment:
Here's an improved patch -- the recursive debugger invocation should
pass the I/O settings on.
--
assignee: -> gvanrossum
keywords: +easy
Added file: http://bugs.python.org/file9171/pdb.diff
__
Tracker
Guido van Rossum added the comment:
And guess what, in 3.0 __builtin__ is renamed to builtin.
--
resolution: -> rejected
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Changes by Guido van Rossum:
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1828>
__
___
Python-bugs-list mailing list
Uns
Changes by Guido van Rossum:
Removed file: http://bugs.python.org/file9172/unnamed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1828>
__
___
Python-bugs-list
Guido van Rossum added the comment:
Thanks!
Committed revision 59979.
--
nosy: +gvanrossum
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum added the comment:
I've added developer status to your username. Let me know if it doesn't
work.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Guido van Rossum added the comment:
The comment indicates it's not automatic that the version number follows
the Python release number.
Assigning to MAL who wants to coordinated this according to that same
comment.
--
assignee: -> lemburg
keywords: +easy
nosy: +gvanrossum,
Guido van Rossum added the comment:
Committed revision 59984 (2.6).
Decided not to backport this to 2.5.
--
resolution: -> fixed
status: open -> closed
versions: -Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum added the comment:
I've got a hunch that any crashes you cause with ctypes are your own
fault. :-)
--
nosy: +gvanrossum
priority: -> low
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyt
Changes by Guido van Rossum:
--
assignee: -> loewis
keywords: +patch
nosy: +loewis
priority: -> normal
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Guido van Rossum added the comment:
So can we definitely rule out that this could be caused by the recent
changes to threading.py (r57216)?
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Guido van Rossum added the comment:
Mark, it looks like the replace_whitespace flag shouldn't be used with
input containing newlines.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Guido van Rossum added the comment:
The original behavior is intentional. Please don't attempt to "fix" it.
--
nosy: +gvanrossum
resolution: -> rejected
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<ht
Guido van Rossum added the comment:
Use .splitlines() to break the input into lines, wrap each "line"
separately, and join again?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Guido van Rossum added the comment:
Raymond touched it last. :-) Perhaps r38041 is to blame?
--
assignee: -> rhettinger
nosy: +gvanrossum, rhettinger
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Guido van Rossum added the comment:
Good luck reaching him.
I'm pretty sure that the default behavior intentional *reflows* all
input text. Perhaps you can derive clues from reading the docs (which I
haven't)?
__
Tracker <[EMAIL PROT
Guido van Rossum added the comment:
Looking at that change more, the queue is now maintained as a heapq.
Perhaps the queue member is for internal use only?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Guido van Rossum added the comment:
Sure.
--
priority: -> low
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1861>
__
___
Python-bugs-list mailing li
Guido van Rossum added the comment:
It's a weakness, not a bug.
Just use a different variable name besides 'a'.
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://b
Guido van Rossum added the comment:
I think the -Wstrict-overflow option may not be enough for the audit we
need.
The overflow issue in expandtabs() still exists (in 2.5 as well as in
the trunk):
if (*p == '\n' || *p == '\r') {
i += j;
1301 - 1400 of 5533 matches
Mail list logo
