Martin v. Löwis added the comment:
It would be ok if a test is only run on a system with IEEE floats, and
skipped elsewhere. For all practical purposes, Python assumes that all
systems have IEEE float.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1383>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1385>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
That's not a bug in Python, but in your script. You should not pass such
a string to createComment.
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Martin v. Löwis added the comment:
It's not a bug in the DOM implementation, as createCommment does not
specify an exception in this case. It may be a bug in the W3 DOM
specification; please report that to the W3 consortium.
It's not a bug in toxml, which should always serialize the D
Martin v. Löwis added the comment:
I'm not willing to change minidom unless there is precedence of how to
deal with this case. So can you find DOM implementations in other
languages that meet the DOM spec an still reject your code?
__
Tracker <[EMAIL P
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1394>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
Would anybody want to provide a patch, then?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1390>
__
___
Python-bugs-list
Martin v. Löwis added the comment:
It may the intention that these functions may raise exceptions in other
cases as well - but can you also support that possibility from the text
of the DOM spec itself?
Adding an exception there may break existing applications, which already
have except clauses
Martin v. Löwis added the comment:
The standard procedure for an incompatible change would be to add such a
parameter to 2.6, and then change the default behavior in 2.7 (or rather
3.1). Of course, people will not notice the change in 2.6, and then be
surprised as much about the default change
Changes by Martin v. Löwis:
--
severity: urgent -> normal
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1411>
__
___
Python-bugs-list mailing li
Martin v. Löwis added the comment:
As now should be clear, there really is no bug here.
Notice that you can also write
1 .__str__()
--
nosy: +loewis
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://
Martin v. Löwis added the comment:
See
http://www.python.org/doc/2.5/ref/whitespace.html
which says that you can put spaces between arbitrary tokens, and
http://www.python.org/doc/2.5/ref/attribute-references.html
which says that all of primary, ".", and identifier are separate to
Martin v. Löwis added the comment:
Ok, I'm rejecting it now based on the YAGNI argument Guido brought up,
and based on my own concerns.
--
resolution: -> rejected
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Martin v. Löwis added the comment:
Ok. Closing it as third-party.
--
resolution: -> invalid
status: open -> closed
versions: +3rd party -Python 2.5
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Martin v. Löwis added the comment:
Thanks for the report. This is now fixed in r58940.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
I think this patch is wrong. Python source code is inherently text, so
generate_tokens should decode the input, rather than operating on bytes.
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Martin v. Löwis added the comment:
Thanks for the patch. Committed as r58941.
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
This error message is not produced by the Python MSI file, but by
Windows installer itself. It computes the set of files that we are about
to install, which includes the Microsoft C Runtime DLL. I guess that
this file is also in use by Explorer.
It is safe to
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1431>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
As Guido says: this is by design. The Unicode type doesn't really
support storage of surrogates; so don't use it for that.
--
nosy: +loewis
resolution: -> wont fix
status: open -> closed
__
Tracker &
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1442>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
I'm rejecting this patch, for several reasons:
- it addresses too many issues in a single patch. Separate bug reports
need to be submitted for independent issues.
- for each issue, it fails to explain what the problem is. For example,
"some lib
Martin v. Löwis added the comment:
tiran is correct. distutils should work without having to invoke a VS
build environment. Relying on that environment would have worked way
back to VC6 and earlier, but it would reduce the ease of use of distutils.
Rejecting the patch.
--
nosy: +loewis
Martin v. Löwis added the comment:
I'm opposed to this patch. Any change to the MSI build process should
only be made when/after the default compiler for Python is changed. That
needs to be discussed on python-dev first, and I hope that the new build
infrastructure will *not* use the PCb
Martin v. Löwis added the comment:
One issue that also needs discussion is the structure of the build
directory. It could temporarily be PCbuild9, but in the long run, it
should replace PCbuild. Apart from that, the issue is whether there
should be a flat structure as it is currently in PCbuild
Martin v. Löwis added the comment:
In all versions of make, "make CFLAGS=..." should work fine (although
that's not an environment variable).
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://b
Martin v. Löwis added the comment:
> Any "standard" way to add custom compilation flags?.
See the README. Set OPT to influence the optimization flags;
set EXTRA_CFLAGS otherwise.
__
Tracker <[EMAIL PROTECTED]>
<http://bug
Martin v. Löwis added the comment:
There is always the debate whether distutils might be repackaged and
backported to older Python releases, therefore people hesitate to remove
support for older versions.
As for finding it in the registry: are you sure it has no registry
settings anymore? I
Martin v. Löwis added the comment:
As another note: you shouldn't remove support code for Itanium. Even
though no Itanium binaries will be produced at the releases, I see no
reason to rip the code out - people with Itanium machines should still
be able to build Python, with some e
Martin v. Löwis added the comment:
Ok. Running vsvars is fine, then.
The change to get_build_architecture is broken in another way: as it
parses the architecture out of sys.version, you still get Intel, not x86
(unless you also change PC/pyconfig.h - which may break code that relies
on the
Changes by Martin v. Löwis:
--
resolution: -> accepted
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1455>
__
___
Python-bugs-list mailing list
Uns
Martin v. Löwis added the comment:
The reason this is not part of the Windows installer is twofold:
a) nobody ever thought of making it so, ever since the htmlhelp was
added, and
b) no code was contributed to add such a procedure to the Windows installer.
Contributions are welcome, although I
Martin v. Löwis added the comment:
kevinwatters: don't bother fixing msi.py. I'll update it whenever I make
a release; there is little point in updating it in-between.
--
assignee: -> loewis
nosy: +loewis
__
Tracker <[EMAIL P
Martin v. Löwis added the comment:
Did you test the change for VS 2003? In my MSMDir
(C:\Programme\Gemeinsame Dateien\Merge Modules), I only have the
following files
GDIPlus.msm
msmask32_X86.msm
msmask32_X86_ENU.msm
VB_Control_mschart_RTL_X86_---.msm
VB_Control_mschart_RTL_X86_ENU.msm
Martin v. Löwis added the comment:
Closing because of lack of activity.
--
resolution: -> works for me
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
Thanks for pointing that out. The MSI build needs to be taught to pick
them up. If I seemingly don't find the time, feel free to contribute a
patch.
--
assignee: -> loewis
nosy: +loewis
__
Tracker <[EMAI
Martin v. Löwis added the comment:
Thanks for the patch. It looked good, so I committed it as r59066. Let's
see whether the buildbot picks it up correctly.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Martin v. Löwis added the comment:
So what's the definition of struct winsize on these systems?
Also, why do you think this is a bug in Python? AFAICT, the specific
ioctl call does not occur in Python, but in your own code.
--
nosy: +loewis
resolution: -> invalid
stat
Martin v. Löwis added the comment:
Please don't use the FileSystemEncoding on Windows for sys.path items.
Instead, it should use the wide API to perform all system calls. Py3k
shouldn't ever use the file system encoding for anything on Windows.
__
Track
Martin v. Löwis added the comment:
It seems that this patch has broken a lot of buildbots, e.g.
http://www.python.org/dev/buildbot/all/x86%20gentoo%20trunk/builds/2625/step-test/0
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.p
Martin v. Löwis added the comment:
See also Tools/buildbot/buildmsi.bat. With cygwin installed, building
the documentation is as simple as
bash.exe -c 'cd Doc;make PYTHON=python2.5 update htmlhelp'
"%ProgramFiles%\HTML Help Workshop\hhc.exe" Doc\build\htmlhelp\pydoc.
New submission from Martin v. Löwis:
I believe it is safe to drop all the _EXPORTS macros (MMAP_EXPORTS,
WINSOUND_EXPORRTS etc) from all projects; atleast I cannot see any
reason for having them. Some are clearly bogus, e.g. unicodedata and
test_capi both define MMAP_EXPORTS, _socket defines
Martin v. Löwis added the comment:
See the MSDN for details. IIUC:
- _WIN32 is defined by the compiler, always, unless the platform is
WIN16 (which is no longer supported). It is even defined on Win64 (where
the compiler also defines _WIN64). So there should be no need to defined
it explicitly
Martin v. Löwis added the comment:
It's tedious to require users to invoke such a shell, and it would
produce an endless flood of support requests if we made that a
requirement. So requiring to build in such a shell is absolutely
unacceptable.
__
Tracker &l
Changes by Martin v. Löwis:
--
assignee: -> tiran
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1476>
__
___
Python-bugs-list mailing list
Uns
Martin v. Löwis added the comment:
Why do you think this is a bug? 08 really is a syntax error, and 010
really means 8.
--
nosy: +loewis
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
Can you provide a setup.py that allows to reproduce this error?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1285>
__
___
New submission from Martin v. Löwis:
Can you propose a specific wording?
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1494>
__
___
Martin v. Löwis added the comment:
Thanks. I committed something like that as 59176.
Notice that the precise semantics of all operations is specified in the
DOM itself,
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html
which says
Adds the node newChild to the end of the list
Martin v. Löwis added the comment:
I verified the installer; this problem is now fixed.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
Can you please be specific what compilers and systems you are talking
about? I doubt your statements hold for *all* native UNIX compilers. In
particular, .s files should be compiled with as, not cc, on the UNIX
systems I'm familiar with, but that won'
Martin v. Löwis added the comment:
I disagree. h2py is much too unreliable, and should be phased out over time.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Martin v. Löwis added the comment:
I don't mind adding the libs, although I think inclusion of the libs
should be reconsidered, anyway. Why do we ship all of them, when you
only ever need pythonxy.lib?
If you are creating separate directories, please don't indicate the
"64-bit&q
Martin v. Löwis added the comment:
It's not so clear that this is a bug. If you install both versions
simultaneously, they might stomp on each other's registry settings, at
least for the extensions. So this is rather a feature request.
Notice that the behaviour is not new to Vista.
Martin v. Löwis added the comment:
Yes, a number of items were not moved, as SF failed to provide them on
export.
--
nosy: +loewis
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/iss
Martin v. Löwis added the comment:
Thanks for the patch. Committed as r59295.
Because of the version change, the patch cannot be applied to 2.5.x
--
resolution: -> accepted
status: open -> closed
_
Tracker <[EMAIL PROTECTE
Martin v. Löwis added the comment:
I still don't get the point of including sys/termio.h. Python does *not*
use the TCGETA macro itself *at all*. Python applications may, but they
can't use the included sys/termio.h, since they are written in Python,
not in C. To put the question the
Martin v. Löwis added the comment:
jos, can you please provide a real name in "Your Details" of this
tracker? We cannot accept anonymous/pseudonymous patches.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.pyth
Martin v. Löwis added the comment:
Committed chflags.diff as r59317.
--
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Martin v. Löwis added the comment:
What problem(s) does this solve?
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1554>
__
___
Pyth
Martin v. Löwis added the comment:
And what problem is solved by the removal of ARGSUSED?
For the functions whose signatures you changed, can you please add
documentation and test changes as well (where necessary)?
Please don't remove the arguments PyObject* on METHO_NOARGS functions;
th
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1560>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
I tried running vcredist from within the python MSI. That aborts with
error message that it can't run another installer while one is already
running.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Martin v. Löwis added the comment:
I would like to ask the submitter to review the code himself for
suitability in 2.6. The underlying API has been extended a lot, so it's
unlikely that this patch is still the best choice.
--
nosy: +loewis
__
Tr
Martin v. Löwis added the comment:
I think you are right - that's a bug. As a consequence, overflowed would
be cleared less often than it is now, which in turn may cause a fatal
abort in case it fails to recover from a stack overflow (i.e. if it
consumes another 50 stack frames, inste
Martin v. Löwis added the comment:
locale.strxfrm needs to be removed in Python 3, probably along with the
entire locale module. We can't support it anymore.
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Changes by Martin v. Löwis:
--
nosy: loewis
severity: normal
status: open
title: Test
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1619>
__
___
Pyth
Changes by Martin v. Löwis:
--
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1619>
__
___
Python
Martin v. Löwis added the comment:
It operates on char*, not Unicode strings.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1618>
__
___
Python-bugs-list
Martin v. Löwis added the comment:
Using ansi is out of scope of this issue, and should not be mixed with
it. -ansi is about disabling certain GCC extensions. This report is
about C code in Python which has undefined behavior.
I think there is disagreement on whether Python should stop relying
Martin v. Löwis added the comment:
I agree with Amaury. This all works exactly as it should work, and will
not change.
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Martin v. Löwis added the comment:
I assume that applies to Py_Refcnt and Py_Type as well?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1629>
__
___
Pyth
Martin v. Löwis added the comment:
Can you please be more specific? What code exactly are you executing,
and what is the exact error message that you get?
In the entire Python source code, the error message "Execfile unable to
take arguments beyond 255!" is never produced. Very
Martin v. Löwis added the comment:
I think it should be backported.
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1638>
__
___
Pyth
Martin v. Löwis added the comment:
While you can't modify the MIB, I'm sure it would be possible to change
the generator code that compiles the MIB into Python source code, to
work around the restrictions in the byte code.
__
Tracker <[EMAIL PROT
Martin v. Löwis added the comment:
I think it's bad to mix separate issues in a single report, as it makes
it difficult to track which of them had been resolved.
As for the paths - I am not surprised it is broken now, as pydoc hasn't
been updated ever since the documentation had bee
Martin v. Löwis added the comment:
Closing as requested.
--
resolution: -> out of date
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
I've fixed PEP 3123 to update the spelling.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1629>
__
___
Python-bugs-
Martin v. Löwis added the comment:
Why the compatibility?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1629>
__
___
Python-bugs-list mailing list
Unsubs
Martin v. Löwis added the comment:
FWIW, should PyUnicode_Check, PyTuple_Check etc. also change to
PyUnicode_CHECK, PyTuple_CHECK etc because they are macros?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Martin v. Löwis added the comment:
I think too many issues get mixed in this report. I would like to ignore
all but one issue, but I don't understand what the one issue is that
this report should deal with.
cartman, when you compare Python 2.4 and 2.5, could it be that the 2.4
Pytho
Martin v. Löwis added the comment:
> print "".encode("iso-8859-9").upper().decode("iso-8859-9")
> does not
Please get your types right. "" is a byte string (in Python 2.x).
encode: unicode -> string
decode: string -> unicode
That you
Martin v. Löwis added the comment:
As of r59585, _PyLong_FitsInLong() is no longer.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Martin v. Löwis:
--
status: pending -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1673>
__
___
Python-bugs-list mailing li
Martin v. Löwis added the comment:
I would expect that this is a Tk bug, primarily, not a Python bug. If
somebody could reproduce it with Tk alone, it would be good to report it
at http://sourceforge.net/tracker/?group_id=12997
--
nosy: +loewis
Martin v. Löwis added the comment:
Can you give some reference to demonstrate that this is the usual behavior?
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Martin v. Löwis added the comment:
Would you like to work on a patch?
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1688>
__
___
Pyth
Martin v. Löwis added the comment:
What do you mean by "Crash"?
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1690>
__
___
Py
Martin v. Löwis added the comment:
Fixed.
--
nosy: +loewis
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
It's definitely not good to define it unconditionally in PC/pyconfig.h,
as that would affect any extensions compiled for Python.
I'm -0 on defining it conditionally for the compilation of Python
itself. I dislike having to constrain Python to Windows
Martin v. Löwis added the comment:
"The macros don't restrain us to Win2k but they prevent us from using
APIs which are not compatible with Windows 2000." --- That's what I
meant by "constrain"/restrain: we can't use API that was added in XP
directly. For funct
Martin v. Löwis added the comment:
I opted for conditionalizing it to OpenBSD; it was wrong on Linux,
anyway, as _BSD_SOURCE has a different meaning there.
Fixed in r59610 and r59611.
--
resolution: -> fixed
status: open -> closed
__
Tracker &
Martin v. Löwis added the comment:
Notice that file *was* open up to Python 2.4; this was changed with
#1479181 - so "open" is newer than file, in a sense. Assigning to Neal,
who committed the original change.
--
assignee: -> nnorwitz
nosy: +loe
Martin v. Löwis added the comment:
Please report this issue to http://sourceforge.net/projects/pypi
This tracker is for Python itself only.
--
nosy: +loewis
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTE
Martin v. Löwis added the comment:
This issue is closed, and didn't really deal with VS 2005 at all, so we
should avoid tracking any further changes in it.
I personally don't care about the PCbuild8 folder at all. It can be
removed, updated, replaced with that script - whatever people
Martin v. Löwis added the comment:
I think this is a duplicate of #1301 (reopen if you think it's not),
where I think Facundo makes an excellent point.
--
resolution: -> duplicate
status: open -> closed
superseder: -> Bad assertion
Martin v. Löwis added the comment:
Certainly. This macro definitely *is* an lvalue.
--
resolution: -> invalid
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis added the comment:
If possible, I would like to see the C library phased out of Python on
Windows, for file I/O. In this case, it would mean that ReadConsoleW is
used directly for character input. Notice that _cgetws does not take a
file handle as a parameter, but implicitly uses
Martin v. Löwis added the comment:
Can you please run
msiexec /i /l*v python.log
then compress python.log, and attach it to the report? Thanks.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
501 - 600 of 2255 matches
Mail list logo