Changes by Martin v. Löwis:
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1029>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mai
Martin v. Löwis added the comment:
URL test (http://www.python.org/sf/1668596)
--
nosy: +loewis
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
New submission from Martin v. Löwis:
This contains a word egastono that is unlikely to occur elsewhere
--
messages: 55039
nosy: loewis
severity: normal
status: open
title: Test
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Martin v. Löwis added the comment:
It had indeed the status Fixed/Open on SF. It was marked as Fixed and
Closed by rhettinger, then reopened by rhettinger in response to my
comment in msg53513.
It does not refer to _bsddb.c, but bsddbmodule.c. Are you saying that
bsddbmodule.c supports __iter__
Changes by Martin v. Löwis:
--
priority: immediate -> normal
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1542308>
_
___
Python-bugs-li
Martin v. Löwis added the comment:
It should not be possible to trigger Py_FatalError through pure Python
code. I still haven't tried reproducing the problem, but if it is
reproducable, it's a bug.
Tracker <[EMAIL PROTECTED]>
<htt
Martin v. Löwis added the comment:
Yes, nobody seems to be interested in fixing it.
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue877124>
___
Python-bugs-
New submission from Martin v. Löwis:
In r57374, the ParseTuple string for datetime_strptime was changed from
ss:datetime to uu:datetime, without adjusting the output arguments. It's
not clear to me what the rationale of this change was; it is incorrect
as u outputs Py_UNICODE, not
Changes by Martin v. Löwis:
--
nosy: +gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1055>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
nosy: -gvanrossum
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1055>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
I think it is neither possible nor "good" to produce a uniform result.
Python traditionally exposes APIs "as-is", providing the system actually
has an API with the same name. It never tries to hide differing system
behaviors in the Python
Changes by Martin v. Löwis:
--
priority: -> normal
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1055>
__
___
Python-bugs-list mailing list
Uns
Changes by Martin v. Löwis:
--
assignee: -> loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1040>
__
___
Python-bugs-list mailing list
Uns
Martin v. Löwis added the comment:
This is now fixed in r57720.
Using wide APIs would be possible through GetTimeZoneInformation,
however, then TZ won't be supported anymore (unless the CRT code to
parse TZ is duplicated).
--
nosy: +loewis
resolution: -> fixed
status: open -
Martin v. Löwis added the comment:
I now see the problem. What you want to do cannot possibly work.
You are trying to create a string object that is larger than 2GB; this
is not possible on a 32-bit system (which I assume you are using). No
matter how you modify the read() function, it would
Changes by Martin v. Löwis:
--
resolution: -> accepted
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1039>
__
___
Python-bugs-list mailing list
Uns
Changes by Martin v. Löwis:
--
versions: +Python 3.0 -Python 2.6
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1675334>
_
___
Python-bugs-list
Changes by Martin v. Löwis:
--
versions: +Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1001>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
versions: +Python 3.0
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1463370>
_
___
Python-bugs-list mailing list
Martin v. Löwis added the comment:
The patch looks fine to me, please apply.
--
assignee: loewis -> georg.brandl
resolution: -> accepted
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Martin v. Löwis added the comment:
I have now fixed it in 57750, 57751, 57754. I leave the bug open until I
can actually test it.
--
resolution: -> fixed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Martin v. Löwis added the comment:
Given that the underlying platform has no support for that, it will be
difficult to implement correctly across all systems.
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Martin v. Löwis added the comment:
I agree with cartman: Python behaves as designed in all cases discussed
here. Closing this report as invalid.
--
nosy: +loewis
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Martin v. Löwis added the comment:
Thanks for the patch. Committed as r57759 and r57760. I added it to the
trunk as well, as it might be possible that the test is run on FAT even
if the operating system is Windows XP.
--
nosy: +loewis
resolution: -> accepted
status: open ->
Martin v. Löwis added the comment:
The fatal error is raised if the stack overflows in the process of
handling RuntimeError. In certain cases, the C algorithms won't bail out
if a RuntimeError is raised, and just catch it. If that then causes
another stack overflow, Python gives up. One
New submission from Martin v. Löwis:
Let's see who gets this
--
assignee: georg.brandl
messages: 55508
nosy: georg.brandl, loewis
severity: normal
status: open
title: Test issue
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Changes by Martin v. Löwis:
--
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1064>
__
___
Python
Martin v. Löwis added the comment:
I think it's incorrect: asynchat operates on bytes, not strings, as it
directly interfaces with the socket, and no encoding is specified for
the protocol.
So, IMO, callers should be expected to pass bytes only, as terminator
and as data.
--
Martin v. Löwis added the comment:
This is now fixed in r57838.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
This is now fixed in r57837
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
While I agree with the principle (use wide APIs where possible), I'd
like to point out that they don't work on Windows 95 (at least some
don't; if you link with MSLU, you get some more to work); that was the
major reason not to use them in the p
Martin v. Löwis added the comment:
I don't see the problem. When open() reports that the file does not
exist, the most likely reason is that it really does not exist. Perhaps
it has not been created, yet, and you need to wait until it has been
created before you can open it?
--
Martin v. Löwis added the comment:
I'm closing this as "works for me" now. It cannot possibly be a bug in
Python, since the error was created by the operating system; Python does
not make it up randomly. I also doubt that the operating system will
arbitrarily report that a file is
Martin v. Löwis added the comment:
I have now changed the string to "Python Software Foundation" in r57859,
r57860, and r57861.
--
resolution: -> fixed
status: open -> closed
versions: +Python 2.6, Python 3.0
_
Tracker <[EMAI
Martin v. Löwis added the comment:
It definitely sounds like a compiler bug. Unless you can provide further
details to the specific error in the C code of Python, it's likely that
we can do little about it.
If you want to analyze this further, here is a number of things you can try:
- co
Martin v. Löwis added the comment:
This is a duplicate of #1078.
--
nosy: +loewis
resolution: -> duplicate
status: open -> closed
superseder: -> cachersrc.py using tuple unpacking args
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis added the comment:
If you are curious, we could now try to find out what precisely goes
wrong. The procedure would be this
* after each step, check whether the problem still occurs
a) resolve the includes manually, then strip everything that isn't
needed. This could start
Martin v. Löwis added the comment:
Mark Hammond has now confirmed it worked for 3.0a1, so closing it.
--
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Martin v. Löwis added the comment:
I don't understand the problem. What Solaris version are you using?
Why do you want to remove _XOPEN_SOURCE? Solaris considers this as a
request for XPG 4.2 only _XOPEN_SOURCE_EXTENDED is defined, which it
shouldn't be on
Martin v. Löwis added the comment:
A 2.5 patch would not be accepted; there won't be any new features
for 2.5 , and new port would be a new feature.
Procedurally, are you willing to support a QNX port for the coming years
(say, 5 years)? Otherwise, there is little point in accepting s
Martin v. Löwis added the comment:
Closing because of lack of feedback. (it may be that I got feedback in
private mail off-tracker; I don't remember).
--
resolution: -> works for me
status: open -> closed
_
Tracker <[EMAIL PRO
Changes by Martin v. Löwis:
--
severity: normal -> minor
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1654408>
_
___
Python-bugs-li
Martin v. Löwis added the comment:
The source of make_type is in Parser/asdl_c.py.
--
nosy: +loewis
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1087>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1006>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1007>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1012>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1015>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1016>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1017>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1023>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1029>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1030>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1000>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1002>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1004>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1005>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1019>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1022>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1026>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1027>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1032>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1034>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1043>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1047>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1061>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1071>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1075>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1076>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
I don't think recoding the message is the right thing to do. Instead,
the email package should be fixed to not treat the bytes before the
first part of a multipart message as text, or else assume that it is
Latin-1 encoded (it's certainly not *meant*
Martin v. Löwis added the comment:
Thanks for the report. This is now fixed.
--
nosy: +loewis
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
-1. I doubt this is needed often enough to justify a builtin function.
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Martin v. Löwis added the comment:
I could not quite reproduce this on the German version (the error text
reads " Das System kann die angegebene Datei nicht finden" on XP),
however, the patch looks good and it fixes the same problem for the
registry functions (where I get "
Martin v. Löwis added the comment:
Thanks for the patch. Committed as r57928
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Martin v. Löwis:
Yes.
--
nosy: +loewis
resolution: -> wont fix
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1094>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
There definitely won't be any new features in 2.5.x. However, I think
Bill said he might make this available separately.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.or
Martin v. Löwis added the comment:
I'm not sure like the naming of the format. "mixed-endian" could mean
anything. I doubt IEEE specifies this as a possible byte representation
(but then, I'm uncertain whether IEEE specifies big-endian and
little-endian, either).
One option
Martin v. Löwis added the comment:
Thanks for the report. This is now fixed in r57947
--
nosy: +loewis
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
Thanks for the report. This is now fixed in r57957 (although I tested it
only on Unix).
--
nosy: +loewis
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
The first issue (non-ASCII characters won't work in interactive mode)
was reported as issue 1100 also, and is now fixed in r57957.
As for the other issues, I'm not quite sure what to make out of them - I
see a different behavior:
py> "Äpfe
Martin v. Löwis added the comment:
I have three problems with the current form of the patch:
a) in the documentation, it should state that __dict__ is an attribute,
not a method.
b) why are you moving the subclassed-from-builtin types into the except
block? It is there to reject things that
Martin v. Löwis added the comment:
Ok, I added a comment in r57958
--
resolution: -> fixed
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Martin v. Löwis added the comment:
I'm closing this as out-of-date, now that the documentation format is
not based on TeX anymore. If you would like to port this to Sphinx, feel
free to reopen it (or submit any such feature as a new patch).
--
nosy: +loewis
resolution: -> out
Martin v. Löwis added the comment:
Thanks for the patch. Committed as r57960.
--
nosy: +loewis
versions: +Python 2.6 -Python 2.4
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Changes by Martin v. Löwis:
--
resolution: -> accepted
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1388440>
_
__
Martin v. Löwis added the comment:
Thanks for the patch. It wouldn't work as-is, because it broke PGEN. I
fixed that, and committed the change as r57961 and r57962.
--
resolution: -> accepted
status: open -> closed
versions: +Python 2.5,
Martin v. Löwis added the comment:
What's wrong with
py> for x in 1,2,3:print(x,end=" ")
...
1 2 3
Closing as invalid.
--
nosy: +loewis
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<
Martin v. Löwis added the comment:
Why do you think so? The documentation is correct as it stands;
dummy_threading should be used when thread is not present, not when
threading is not present (as threading will always be present, it just
won't import when thread is not present).
--
Changes by Martin v. Löwis:
--
assignee: -> loewis
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1102>
__
___
Python-bugs-li
Martin v. Löwis added the comment:
Thanks for the patch. Committed as r57984 and r57985.
--
nosy: +loewis
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
Thanks for the patch. Committed as r57990 and r57991.
--
resolution: -> accepted
status: open -> closed
versions: +Python 2.5, Python 2.6 -Python 2.3
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.
Martin v. Löwis added the comment:
The patch looks fine to me (with the addition of checking for sunos5
instead). A few things to consider:
- you could check the system at import time, rather than call time, of
_get_soname()
- notice that the file is located in /usr/ccs/bin, which may not be
Martin v. Löwis added the comment:
There are really two issues here; it is usually better to report them
separately, so they can be analyzed, fixed, and closed separately:
a) the compileall script apparently fails (not surprisingly so, I never
tested it for 3.0), and
b) Python does not work on
Martin v. Löwis added the comment:
For 2.5, it reverts to the state of 2.4. You'll have to find a
work-around on your own.
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Martin v. Löwis added the comment:
Can you please elaborate? What does that have to do with Python?
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1112>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
A plain "print" only results in output of "" in
interactive mode, as interactive mode will not only perform the action,
but also display the result. In a Python script, a plain "print" will
have no effect.
Guido, can you take a lo
Martin v. Löwis added the comment:
Greg, can you take a look? If not, please unassign.
--
assignee: -> gregory.p.smith
nosy: +gregory.p.smith, loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1115>
__
___
Python-bugs-list mailing list
Unsubs
1 - 100 of 4778 matches
Mail list logo