Changes by Martin v. Löwis :
Added file: http://bugs.python.org/file20645/unisub.diff
___
Python tracker
<http://bugs.python.org/issue11067>
___
___
Python-bugs-list m
Changes by Martin v. Löwis :
Removed file: http://bugs.python.org/file20645/unisub.diff
___
Python tracker
<http://bugs.python.org/issue11067>
___
___
Python-bugs-list m
Martin v. Löwis added the comment:
Reconsidering: it's better to use PyType_IsSubtype, as this matches better the
fast check.
--
Added file: http://bugs.python.org/file20646/unisub.diff
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
AFAICT, including sys/types.h by default in the test should be fine. It's a
standard header file (atleast for Posixish systems), so it should always be
present, and including it shouldn't cause harm even if it's not needed.
-
Martin v. Löwis added the comment:
Can you debug this, e.g. by inspecting the core file?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue11
Martin v. Löwis added the comment:
Supporting the ones in HTML 5 would be fine with me. Supporting those of
xml-entity-names would be inappropriate - it's not clear (to me, at least) that
all of them are really meant for use in HTML.
--
nosy: +l
Martin v. Löwis added the comment:
I can propose a specification of getsizeof: if you somehow manage to traverse
all objects (without considering an object twice), and sum up the getsizeof
results, you should end up with something close to, but smaller than the actual
memory consumption. How
New submission from Martin v. Löwis :
The None export of python3.dll is bogus; attached is a fix. This also
regenerates python3stub.def, which contained some exports that had already been
deleted from python3.def.
--
files: none.diff
keywords: patch
messages: 127917
nosy: georg.brandl
Martin v. Löwis added the comment:
Thanks for the quick review. Committed as r88333.
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
Here is the patch I'd like to add to 3.2: this adds PyType_GetFlags, so that
the fast checks remain available.
--
nosy: +georg.brandl
priority: normal -> release blocker
Added file: http://bugs.python.org/file20678/tp_fl
New submission from Martin v. Löwis :
When configuring r88333 with --enable-shared, the error message
./configure: line 4924: test: ==: unary operator expected
is produced. The attached patch fixes the problem.
--
files: pydebug.diff
keywords: patch
messages: 127931
nosy: loewis
Martin v. Löwis added the comment:
My claim is that Tkinter is thread-safe as it stands. A lot of thought has been
put into making Tkinter thread-safe, so if there is any claim to the contrary,
we would need more details: what exact Python version is being used, what exact
operating system
Martin v. Löwis added the comment:
Terry, if you are installing Python "for all users", but have the Open rebound
just for yourself, it is unreasonable to expect that the Python installation
procedure changes it. Per-user settings override machine settings; this is by
Micros
Martin v. Löwis added the comment:
> Is Tkinter's thread safety new?
It's supported on Unix since 1.5.1, and on Windows since 2.3.
--
___
Python tracker
<http://bugs.pytho
Martin v. Löwis added the comment:
Tk produces "bad screen distance" in Tk_GetScreenMM (convert string to screen
millimeters) and TkGetDoublePixels (convert string to number of pixels) when
strtod fails on the string being passed. It also produces the error in
SetPixelAny (convert
Martin v. Löwis added the comment:
Thanks for the review. Committed as r88350.
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
Thanks for the review. Committed as r88351.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
New submission from Martin v. Löwis :
Three slots in type objects are missing in PEP 384. This patch adds them to the
ABI.
--
files: typeslots.diff
keywords: patch
messages: 128075
nosy: georg.brandl, loewis
priority: release blocker
severity: normal
status: open
title: Add missing
New submission from Martin v. Löwis :
There are currently two ways to specify a type doc string in PyType_FromSpec;
either through the doc field (which is not actually processed), or through
Py_tp_doc (which works correctly).
The original concern for adding doc into the TypeSpec was that the
Martin v. Löwis added the comment:
> Given the recent multiple additions of "forgotten things" in the ABI,
> wouldn't it be better to mark the ABI experimental so that things can
> get ironed out in 3.2.1? (especially with user feedback after the
> release)
I don
Martin v. Löwis added the comment:
> No, the point of the proposal is to allow you to make further changes in
> response to user feedback. I assume you can't add things anymore once
> the ABI is declared "stable". Can you?
Adding things would be possible, althoug
Martin v. Löwis added the comment:
> My understanding is that Martin can add, but not subtract. Martin,
> is that correct?
Correct (see the elaboration I just sent).
> At this point, I'm not sure we know that the
> limited API is sufficient.
It's certainly not possib
Martin v. Löwis added the comment:
I'm not sure whether this is a bug, though. So I'd be skeptical that it should
be changed in 2.x, even if the cause was identified.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.o
Martin v. Löwis added the comment:
> I'd call this a bug, albeit a minor one. The documentation for 'int' says:
>
> "If the argument is outside the integer range a long object will be returned
> instead.&q
Martin v. Löwis added the comment:
Very smart!
--
___
Python tracker
<http://bugs.python.org/issue11144>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
Thansk for the review. Committed as r88400.
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
Thanks for the review. Committed as r88401.
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
Are you perhaps trying to run the installer from a network folder, or some
other location that needs your personal credentials for access?
Please run
msiexec /i python-2.7.1.msi /l*v python.log
and attach the resulting python.log to this report
Changes by Martin v. Löwis :
--
nosy: -loewis
___
Python tracker
<http://bugs.python.org/issue10181>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
It's the same as the current tp_doc parameter for static type objects, and
essentially like any other doc string in the C API. It's owned by the extension
module, which must make sure it lives at least as long as the t
Martin v. Löwis added the comment:
I see. This is an issue independent of the issue discussed here, though, please
open a new issue for that. I agree that either tp_dealloc should not release
the string, or should make a copy that it can release
New submission from Martin v. Löwis :
Currently, memory management for the Py_tp_doc slot in PyType_FromSpec is
ill-defined. The doc string being passed is stored in the type object as-is,
but later released with PyObject_Free. To make this consistent, PyType_FromSpec
should copy the string
Martin v. Löwis added the comment:
If this isn't added, people using the API might see crashes. If they then work
around crashes, they will see memory leaks in future releases.
--
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
> Well, isn't Py_tp_doc characteristically bound to a constant char *
That's exactly the problem: PyType_FromSpec puts in this string literal.
When the type is later released, PyObject_Free is called in
type_dealloc, wh
Martin v. Löwis added the comment:
> Sounds like a blocker to me. Martin, will you be able to provide a patch
> before final?
The attached patch works fine for me.
--
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
>>> Sounds like a blocker to me. Martin, will you be able to provide a patch
>>> before final?
>>
>> The attached patch works fine for me.
>
> Is there some documentation somewhere for all this?
Can you please be mor
Martin v. Löwis added the comment:
>> That tp_doc will be copied is currently undocumented. PyType_FromSpec
>> is documented in the PEP.
>
> I meant all of py_tp_doc, "limited api", "restricted api" show almost
> zero hits in the API docs. A
Martin v. Löwis added the comment:
Instead of using http over TCP and basic auth to upload stuff to PyPI, you can
also use SSH. In this case, no password is needed at all.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue9
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Rejecting as "invalid". If you somehow still think something should
change, please discuss that on the py3k list.
--
nosy: +chester, loewis
resolution: -> invalid
status: open -> closed
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I don't understand your question. What is "this site" that you are
referring to, and why do you think it uses a single sign-on system?
--
status: pending -> closed
__
T
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I don't see the problem at all. The -909 value is an implementation
artefact, and the submitter probably wouldn't have known it existed
without reading the source code. Perhaps we should change it to
something different ever
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Objection. I don't see the point of signing the binaries; signing the
MSI files should be enough.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The reason to close this report is that you are not reporting a bug in
Python. Instead, you report an issue with the bug tracker itself. This
tracker is solely, only, exclusively, for bugs you find in the
implementation of Python
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Opinion: After 2 years, I think the priority of this issue should be
> raised: help should 'just work' as installed, especially on Windows.
> Until is does, the instructions need to be improved so that normal user
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
assignee: loewis ->
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1489051>
_
___
Pyt
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
It's actually not possible, in general, to compute the memory
consumption of an object using basicsize and itemsize. An example is the
dictionary, where there is no way to find out how many slots are
currently allocated.
Even for
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Proposals like this have been rejected in the past. Memory consumption
> is an evasive concept. Lists over-allocate space
That issue is addressed in this patch.
> there are freelists,
but they allocate just an upper
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Lists will need a custom tp_footprint then, too.
True.
> BTW, is a new slot necessary, or
> can it just be a type method called __sizeof__?
It wouldn't be a type method, but a regular method on the specific type,
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> I'm torn about the extra slot; I'd rather not add one, but I can't see
> how to make this flexible enough without one.
I think adding a default __sizeof__ implementation into object
(__basicsize__ + len()*__i
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The problem is that any modern Windows does not just have a single home
directory for a user, but many of them. For example, there are the
HOMEDRIVE, HOMESHARE, and HOMEPATH variables, which may or may not be set.
In the light of th
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for the patch. Committed (with modifications) as r63498.
--
nosy: +loewis
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Python (the language) makes no guarantee itself on what the precise
semantics of floating-point operations is. This is documented in
http://docs.python.org/ref/types.html
"These represent machine-level double precision flo
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Why do you think this is a bug in Python?
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Is that a bug in setuptools? If so, don't report it here - setuptools is
a separate project, not part of the core Python (bdist_wininst is part
of distutils).
--
nosy: +loewis
__
Trac
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I'm rejecting this idea, for the reasons already given by others: the
same string might have different hash values, depending on which
encoding is chosen. Users will have to be explicit when hashing, just as
they need to be ex
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Would you like to work on a patch?
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I also think that there should be explicit set_errno/get_errno calls. If
you are interfacing to C, things should be as they are in C, i.e. you
have to explicitly set errno to zero if you want to read it afterwards
in a reliable
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
People might get confused that errno is modified "without reason".
I don't understand the need for the TLS, either - can't you just read
and write the "true" er
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Please take a look at the config.log, and locate the lines
In file included from
/usr/GNU/lib/gcc-lib/sparc-sun-solaris2.4/2.6.3/include/time.h:90,
from /usr/include/sys/time.h:418,
from /usr/inclu
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Can you please file a contributor agreement? This would be a
prerequisite for including the module.
Also, is there any progress on the open issues? I really would like to
see a single zip file that unpacks on top of the Pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Committed to 2.5 as r63561
--
status: pending -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Alan, it appears that the patch doesn't apply anymore, in r63553. Can
you please update it?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for the patch. Committed as r63562.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue175>
_
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> accepted
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for the patch. Committed as r63563.
Because of the new exception, I won't backport the change to 2.5.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMA
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
How can Python run arbitrary code between the return from a ctypes
method and the next Python instruction? None of the code should have any
effect on errno.
__
Tracker <[EMAIL PROTECTE
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I don't agree that PyUnicode_AsString is useless. There are many cases
where you don't need the length of the string, e.g. when relying on NULL
termination when passing stuff to some C library.
I suggest to close this repo
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
>> How can Python run arbitrary code between the return from a ctypes
>> method and the next Python instruction? None of the code should have any
>> effect on errno.
>
> By freeing objects because their refcou
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
[...]
>
> Using the native errno instead of a custom TLS value is bad because a
> lot of things can occur
So what's the semantics of set_errno then? Set the real errno? If so,
what if it gets changed between the call t
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> AFAIU, set_errno/get_errno should provide a ctypes-private copy of the real
> errno.
> The copy is copied into the 'real' errno just before ffi_call (in
> Modules/_ctypes/callproc.c),
> and the real er
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> invalid
status: open -> closed
versions: +3rd party -Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The behaviour is documented, e.g. in footnote 5.1 of
http://docs.python.org/ref/lists.html
It is fixed in Python 3.
--
nosy: +loewis
resolution: -> fixed
status: open -> closed
__
Tra
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This is now fixed in r63569
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2952>
__
___
Python-bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> My code sample did not intend to clear errno, it was intended to set errno
> to the last value that the ctypes-copy had before the call.
It's the same thing (to me): you change errno.
> To make my point clear (in c
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This patch has broken test_distutils, which now reports
test_distutils
test test_distutils produced unexpected output:
**
Using PyPI login from /home/martin/work/py2
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> This is because the code uses a print statement when opening the .pypirc
> file. This was already the case before this patch, but the code was not
> covered by tests. (see in previous revision)
>
> The test is not b
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The patch, in its current form, is incomplete. Can you please provide:
a) a VS 2008 project file, which builds both the curses module and the
pdcurses library, fetching the sources for that from ../../pdcurses (or
some such
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
This is now fixed in r63625 and r63626.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs
New submission from Martin v. Löwis <[EMAIL PROTECTED]>:
Test_imports takes a very long time to complete. I believe this is due
to the individual refactorings taking such a long time, even though they
apply to small pieces of code only.
--
messages: 67348
nosy: loewis
severity:
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
assignee: -> collinwinter
components: +2to3 (2.x to 3.0 conversion tool)
nosy: +collinwinter
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from Martin v. Löwis <[EMAIL PROTECTED]>:
Test_imports fails for selected cases, when run under Python 2.6.
E.g. from_import_usage fails for rewriting __builtin__ print, and also
for __builtin__ zip.
--
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversio
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for the report. This should now be fixed with r63643, r63644 and
r63645.
--
nosy: +loewis
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<h
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Closing the report as "invalid" then (and I strongly recommend to remove
gcc 2.6.3 right away. It obviously cannot be used to compile software on
your system).
--
resolution: -> invalid
sta
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I think the documentation is fine as it stands. The format is ASCII -
even though the payload might not be.
--
nosy: +loewis
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> How can a data format be printable ASCII and at the same time use
> non-ASCII characters ?
The "format" is the frame defining the structure. In the binary
formatter, it's a binary format. In the standard pickl
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Unfortunately, there's no way to fix this now, since the
> bug has been around since Python 1.6.
Actually, there is a way to fix that: pickle could start
emitting \u escapes for characters in the range 128..
Changes by Martin v. Löwis <[EMAIL PROTECTED]>:
--
resolution: -> invalid
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I think in Python 3, the whole wantobjects=False case should go. It was
a compatibility measure to support applications that didn't expect Tcl
objects; for Python 3, only a single case should be supported.
--
no
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I can't reproduce this. If I do
py> import tarfile
py> t=tarfile.open("pyOpenSSL-0.6.tar.gz","r:*")
py> t.extractall()
py>
it extracts just fine, and sets the s-bits. I've used the fil
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The patch looks fine to me, please apply. Don't forget to add a
Misc/NEWS entry.
--
assignee: gvanrossum -> schuppenies
resolution: -> accepted
___
Python tracker <[EMA
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
That os.listdir still uses bytes should be changed as well. Both file
names and command line arguments are strings, from the viewpoint of
Python. Nothing else is supported.
--
nosy: +
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I don't see any problem with that result? Why do you consider the result
incorrect, and what "correct" result would you have inspected instead?
Notice that int conversion of floats truncates them, by definition.
---
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
I see. There is no such thing as a "correct" conversion from real
numbers to integer numbers. Instead, there are various approaches,
called "truncating", "rounding", "flooring", and "ceili
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Whether or not that works in 3k depends on your console's encoding; your
program works just fine for me in Linux, with a UTF-8 console.
Python 2.5 was not using a "system page" (whatever that is); it was
sending the byt
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
The issue with unrepresentable file names hasn't been decided yet. One
option is to include the bytes object in that case, instead, noting that
this can only occur on selected platforms. Another option is indeed to
raise an ex
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for the patch. Committed as r63888
--
resolution: -> accepted
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Thanks for the patch, committed as r63929. Please move any further
discussion or other necessary changes into a new issue.
--
resolution: -> accepted
status: open -> closed
___
Py
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
Yes, please do provide an updated patch.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> So, since this patch allows python to be built 64-bit on a biarch
> system, and without it, the build doesn't work
This is simply not true. I can build Python 2.5 just fine for 64-bit
SPARC, using gcc, with
CC="gcc
Martin v. Löwis <[EMAIL PROTECTED]> added the comment:
> Your method is just flat wrong - equivalent to using a sledgehammer. The
> libraries fail to link not because gcc install is wrong but because the
> -m64 flag needs to be passed to the linker.
And indeed, the flag *is
1101 - 1200 of 4778 matches
Mail list logo
