Martin v. Löwis mar...@v.loewis.de added the comment:
See the subversion history. It was added in r14344, which supposedly originated
from Thomas Heller, so he should know.
Thomas, what's the reason for suppressing PDB files?
--
nosy: +loewis, theller
Martin v. Löwis mar...@v.loewis.de added the comment:
http://svn.python.org/projects/external/openssl-1.0.0a/asm64/
Please follow the instructions in PCbuild/readme.txt carefully. Thanks.
--
resolution: - invalid
status: open - closed
___
Python
Martin v. Löwis mar...@v.loewis.de added the comment:
IIUC, you are proposing to fix Python 2.6 only. Please understand that this
branch is closed for bug fixes (unless they are security issues, which this
issue is not).
As for 2.7: please try explaining again what specific issue the patch
Martin v. Löwis mar...@v.loewis.de added the comment:
As mentioned above I cannot provide more information because I am
unable to find the root of the issue. All I know is that if the
atexit handler is executed after the module globals were set to None
it fails to shutdown properly.
Ok
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: - works for me
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9775
Martin v. Löwis mar...@v.loewis.de added the comment:
I guess this test should simply removed.
(not sure which test you are referring to: the test case, or the
test for too long path names:) I think both tests need to stay.
Instead, I think that testMaxPathLen is incorrect: it doesn't
take
Martin v. Löwis mar...@v.loewis.de added the comment:
I don't see the issue at all; the attached script runs just fine.
--
Added file: http://bugs.python.org/file18754/t.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9775
Martin v. Löwis mar...@v.loewis.de added the comment:
This would also impact the ABI, I suppose.
Correct. So it either needs to happen before 3.2, or wait until 4.0,
or the introduction of wide hashes needs to be done in a compatible
manner, likely requiring two parallel hashing
Martin v. Löwis mar...@v.loewis.de added the comment:
Am 05.09.2010 13:12, schrieb Antoine Pitrou:
Antoine Pitrou pit...@free.fr added the comment:
Correct. So it either needs to happen before 3.2, or wait until 4.0,
Shouldn't there be a provision for ABI versioning?
There is certainly
Martin v. Löwis mar...@v.loewis.de added the comment:
baikie, coming back to your original message: what precisely makes you believe
that sun_path does not need to be null-terminated on Linux?
--
___
Python tracker rep...@bugs.python.org
http
Martin v. Löwis mar...@v.loewis.de added the comment:
Having patches in the tracker is fine to me. Even if the patch is closed, it's
still available.
Of course, there are many ways to publish code on the net: you could post the
patch to Rietveld, to the Python wiki, or publish an entire clone
Martin v. Löwis mar...@v.loewis.de added the comment:
I agree with msg115992. People do use make to build extension modules, with
hard-coded file names in the make targets.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Martin v. Löwis mar...@v.loewis.de added the comment:
It seems that multiprocessing is fairly conservative wrt. 64-bit support. For
example, conn_send_string has a string limit of 0x7fff. Therefore, several
of the warnings are harmless; the respective lengths fit into int just fine.
I
Martin v. Löwis mar...@v.loewis.de added the comment:
Instead of
PyLong_FromLong((Py_uintptr_t) self);
use
PyLong_FromVoidPtr(self);
For the others, I suggest making length and allocated Py_ssize_t; this is
likely a pervasive change. Of course, very few people will currently run
Martin v. Löwis mar...@v.loewis.de added the comment:
I see. Looking at net/unix/af_unix.c:unix_mkname of Linux 2.6, there is a
comment that says
Check unix socket name: [...]
- if started by not zero, should be NULL terminated (FS object)
However, the code then just does
Martin v. Löwis mar...@v.loewis.de added the comment:
The ifdef should go; pthreads always support TLS (since XPG5, 1997).
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9786
Martin v. Löwis mar...@v.loewis.de added the comment:
What is appMalloc, and what does it have to do with some Python lock?
You seem to suggest that some malloc implementations make use of Python
interpreter internals. I would call that a bug in the malloc implementation (it
violates standard
New submission from Martin v. Löwis mar...@v.loewis.de:
Will this have two patch keywords?
--
files: rss.xml.diff
keywords: patch
messages: 116189
nosy: loewis
priority: normal
severity: normal
status: open
title: Test issue
Added file: http://bugs.python.org/file18859/rss.xml.diff
Martin v. Löwis mar...@v.loewis.de added the comment:
No.
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9839
Martin v. Löwis mar...@v.loewis.de added the comment:
It's probably best to rewrite these functions in the way the SDK Example
section works (i.e. CreateFile/ReadFile) instead of _open/_read (*). As Amaury
says, the warnings are harmless: the file numbers will always be in range, as
_open
Martin v. Löwis mar...@v.loewis.de added the comment:
It should not hang anymore, since r84172/r84198. The issue was a GIL-based
deadlock: the GIL was acquired and then not released in a callback function, so
the next callback caused a deadlock.
The actual cause was a non-ASCII character
Martin v. Löwis mar...@v.loewis.de added the comment:
Dag: thanks again for the patch. You did everything correctly; Eric's remarks
were just in case you plan to submit contributions in an ongoing manner.
Raymond: that it makes users go through the hoops of getting a tracker account,
doing
Martin v. Löwis mar...@v.loewis.de added the comment:
+1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9042
___
___
Python-bugs-list mailing
Martin v. Löwis mar...@v.loewis.de added the comment:
I know this is closed, but traditionally, we have put stuff like this into
README (not sure whether Sébastien read the README :-). So if anybody feel like
adding some text, go ahead.
In return, feel also free to take out some text
Martin v. Löwis mar...@v.loewis.de added the comment:
If the feature to be provided is multiple Python installations with the same
prefix, then I suggest to generalize this beyond the debug build. One approach
would be:
1. add a --bin-suffix configure option (Debian: set this to _d when
Martin v. Löwis mar...@v.loewis.de added the comment:
As Brian explains: if you want the Wow6432 entries, install the 32-bit Python -
which will install just fine on your 64-bit system, and is, in many cases, the
better choice.
--
nosy: +loewis
status: open - closed
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: - accepted
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9817
___
___
Python-bugs
Martin v. Löwis mar...@v.loewis.de added the comment:
What do you gain with this patch? (i.e. what is its advantage?)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9820
Martin v. Löwis mar...@v.loewis.de added the comment:
I did not realize the build instructions recommended using the
buildbot tool. It is clearly past time I got around to doing windows
build myself.
I'd rather prefer a different setup, also: it would
be better if the batch files to get
Martin v. Löwis mar...@v.loewis.de added the comment:
About Windows: supports_unicode_filenames is False if
sys.getwindowsversion().platform 2: win32s (0) or Windows 9x/ME
(1). I don't know win32s, but I know that Windows 9x/ME is not more
supported.
Win32s is long gone
Martin v. Löwis mar...@v.loewis.de added the comment:
I think that supports_unicode_filenames is still useful to check if
the filesystem API uses bytes (Linux, FreeBSD, Solaris, ...) or
characters (Mac OS X, Windows). Mac OS X is a special case because
the C API uses char* (byte string
Martin v. Löwis mar...@v.loewis.de added the comment:
Use PCbuild/bdist_wininst.vcproj.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9818
Martin v. Löwis mar...@v.loewis.de added the comment:
You know directly that os.listdir(bytes) is unable to encode the
filename, instead of manipulate an invalid filename (b'?') and get
the error later (when you use the filename: open, copy, delete, ...
the file).
Ok. Then I'm -1
Martin v. Löwis mar...@v.loewis.de added the comment:
About Windows, os.listdir(str) never fails, but my question is about
os.listdir(bytes). Should os.listdir(bytes) returns invalid filenames
(encoded
with mbcs+replace, filenames not usable to open, rename or delete the file)
or
just
Martin v. Löwis mar...@v.loewis.de added the comment:
If we choose to keep this behaviour, I will have to revert my commit on mbcs
codec to be consistent with os.listdir(). Or at least patch
PyUnicode_EncodeFSDefault and os.fsencode() (use replace error handler
Martin v. Löwis mar...@v.loewis.de added the comment:
The examples in Stevens/Rago's Advanced Programming in the Unix
Environment also pass address lengths to bind(), etc. that do
not include the null.
I didn't (mean to) suggest that the null must be included in the
length - only
Martin v. Löwis mar...@v.loewis.de added the comment:
You may find this hard to believe, but we do in fact embed python
into other applications.
This is actually very easy to believe.
appMalloc, is in this case, the canonical memory allocator in
UnrealEngine. But it could be any other
Martin v. Löwis mar...@v.loewis.de added the comment:
It seems we need to clarify the return value of PyThread_create_key. The patch
returns 0 in case of failure, which is clearly wrong as 0 is also a valid key.
I think it's safe to return -1: TlsAlloc returns TLS_OUT_OF_INDEXES, which
Martin v. Löwis mar...@v.loewis.de added the comment:
Note that we are not making any new requirements on python here.
But you are. So far, there was no guarantee whatsoever about the state
of Python when malloc is called. You are now introducing a requirement
that Python must be in a certain
Martin v. Löwis mar...@v.loewis.de added the comment:
Am 13.09.2010 10:00, schrieb Kristján Valur Jónsson:
Kristján Valur Jónsson krist...@ccpgames.com added the comment:
I've changed the function as you suggest, although there are in fact no
failure detection semantics defined
Martin v. Löwis mar...@v.loewis.de added the comment:
Perhaps we can simply call Py_FatalError() instead? There's not much we
can do when such a failure occurs anyway.
Sounds fine as well. Python's own usage definitely shouldn't fail. If
extension modules use this in an aggressive manner
Martin v. Löwis mar...@v.loewis.de added the comment:
My (I think fairly straightforward) idea is to just compile the
useful values in Makefile and config.h into _sysconfig.c and arrange
for sysconfig to import that and check it first (fallback to parsing
mf and conf.h).
You seem to suggest
Martin v. Löwis mar...@v.loewis.de added the comment:
Another solution would be not to make clean, but del *.obj.
However, I would prefer if we stopped using makefile.msc altogether,
and explicitly included the source files of bzip2 into bz2.vcproj, similar to
the way _bsddb is built (in 2.7
Martin v. Löwis mar...@v.loewis.de added the comment:
@Martin: yep, I know we still need to install pyconfig.h and
Makefile, but we shouldn't need to parse them to get programmatic
access to the data they contain.
Hmm. What do you gain by not parsing them
Martin v. Löwis mar...@v.loewis.de added the comment:
As a point of information, on my gentoo linux system without
largefile support in the kernel, any value 4294967295 or above
results in getrlimit reporting -1. Any smaller value is set and
reported as itself. (If a sufficiently large
Martin v. Löwis mar...@v.loewis.de added the comment:
I fail to see why this is a bug. If the system call is interrupted, why should
Python not report that?
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9867
Martin v. Löwis mar...@v.loewis.de added the comment:
I can't test the patch right now, but it looks good to me.
Please check it into py3k to see how the buildbots do. If it seems to work
correctly (both for x86 and AMD64), feel free to backport it to 2.7 and 3.1.
As for vs9to8: I can't
Martin v. Löwis mar...@v.loewis.de added the comment:
One could argue of course that every user of Python should handle
EINTR, but that's something I think should be solved in the IO
library because very few people know that one is supposed to restart
syscalls on EINTR on POSIX systems
Martin v. Löwis mar...@v.loewis.de added the comment:
Not having some complicate and brittle code to parse Makefiles would
certainly be a win, IMO.
Not sure how the patch would look like, but I would expect that any
patch to build a module to include Makefile settings makes it *less*
robust
Martin v. Löwis mar...@v.loewis.de added the comment:
Am 16.09.10 14:06, schrieb Armin Ronacher:
Armin Ronacherarmin.ronac...@active-4.com added the comment:
Hmm. So under what conditions should it continue, and under what
conditions should it raise an exception (when errno is EINTR
Martin v. Löwis mar...@v.loewis.de added the comment:
Unless base64 is an OpenSSL trademark, this is FUD.
The license clearly states: All advertising materials mentioning
features or use of this software. Do you somehow disagree that
base64 is a feature of the OpenSSL library?
What
Martin v. Löwis mar...@v.loewis.de added the comment:
Please include a message when closing an issue to indicate why it's closed.
AFAICT, this is indeed incorrect usage of the API: you should have used
PyEval_SaveThread instead of PyEval_ReleaseLock.
--
nosy: +loewis
resolution
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: - invalid
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9900
___
___
Python-bugs
Martin v. Löwis mar...@v.loewis.de added the comment:
I never claimed that the clause triggered for all software in
existence. We are talking about OpenSSL being bundled with Python
where Python is very much aware of OpenSSL. Provided the following 3
circumstances are met, the advertisement
Martin v. Löwis mar...@v.loewis.de added the comment:
Should flush be modified to do nothing in this case or should the unit test
be updated?
Tim is suggesting that flush should indeed become a noop. Since nobody
else speaking in favor of it being an error, I guess this is the way to
go
Martin v. Löwis mar...@v.loewis.de added the comment:
Interestingly, the matter was discussed on another issue, #2643. I
also agree that ideally flush() should become a no-op (only in 3.2,
since it would break compatibility). But then we should also expose a
separate sync() method
Martin v. Löwis mar...@v.loewis.de added the comment:
I think Antoine misinterpreted my message. I do think that flush should
continue to msync, except in cases where there really is no underlying file to
sync to. It may (or may not) be unfortunate that the method is called flush,
but nothing
Martin v. Löwis mar...@v.loewis.de added the comment:
Looks fine to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue678250
___
___
Python
Changes by Martin v. Löwis mar...@v.loewis.de:
--
Removed message: http://bugs.python.org/msg117109
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue678250
Changes by Martin v. Löwis mar...@v.loewis.de:
--
Removed message: http://bugs.python.org/msg117108
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue678250
Changes by Martin v. Löwis mar...@v.loewis.de:
--
Removed message: http://bugs.python.org/msg117107
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue678250
Changes by Martin v. Löwis mar...@v.loewis.de:
--
Removed message: http://bugs.python.org/msg117106
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue678250
Changes by Martin v. Löwis mar...@v.loewis.de:
--
Removed message: http://bugs.python.org/msg117110
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue678250
Martin v. Löwis mar...@v.loewis.de added the comment:
Please submit this as a new bug issue, preferably with precise instructions on
how to reproduce it. Can you provide some clue how the file became hidden in
the first place?
--
___
Python tracker
New submission from Martin v. Löwis mar...@v.loewis.de:
In Python 3.2, when inheriting from TestSuite, it is no longer possible to
override __call__ (e.g. to introduce a TestSuite setUp and tearDown).
The __call__ method will not be called anymore.
Instead, if the object has a _wrapped_run
Martin v. Löwis mar...@v.loewis.de added the comment:
Is that problem reproducible?
I.e. what did you do, in what order, and: when you do it again, will the
problem occur again?
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http
Martin v. Löwis mar...@v.loewis.de added the comment:
I fail to see the issue. The documentation clearly says, above the block of all
the EX_* constants:
Note
Some of these may not be available on all Unix platforms, since there is some
variation. These constants are defined where
Martin v. Löwis mar...@v.loewis.de added the comment:
-1 for the patch. I still maintain that it is better to follow the current SDK.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9784
Martin v. Löwis mar...@v.loewis.de added the comment:
Perhaps slightly ironically (for this particular bug report) is that
the change was introduced to support class and module level setUp and
tearDown (similar to the use-case it now blocks).
FWIW, this issue arrived from pygresql, see
Martin v. Löwis mar...@v.loewis.de added the comment:
issue9783.diff provides a patch that will compile clean on 32 and 64
bit Windows systems. I tried to avoid explicit casts where I could,
but it was not always possible. I have ported a lot of my company's
code to 64 bit (all Windows
Martin v. Löwis mar...@v.loewis.de added the comment:
See, for example, the link you gave in msg115750. It has this sample code in it
(listed in the Examples section):
FNFCIREAD(fnFileRead)
{
DWORD dwBytesRead = 0;
UNREFERENCED_PARAMETER(pv);
if( ReadFile((HANDLE)hf, memory, cb
Martin v. Löwis mar...@v.loewis.de added the comment:
Martin Lowis do you mean API when you type SDK?
When I said SDK examples, then I really meant examples as published
in the SDK, not examples as published in the API (and the SDK
documentation, in turn, is published on msdn).
But yes
Martin v. Löwis mar...@v.loewis.de added the comment:
Closing, as suggested by neologix
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8831
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9952
Martin v. Löwis mar...@v.loewis.de added the comment:
-1. On Linux, and many other systems based on or using free software, the
sqlite command line tool is readily available, and including it would conflict
with the one provided by the system vendor.
For Windows, pre-built binaries
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9954
Changes by Martin v. Löwis mar...@v.loewis.de:
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9980
___
___
Python-bugs-list
Martin v. Löwis mar...@v.loewis.de added the comment:
Please don't say that urllib does not perform any ssl validation. It
certainly *does* perform ssl validation, namely it validates whether the
payload received over ssl matches the certificate received from the server.
What it does not do
Martin v. Löwis mar...@v.loewis.de added the comment:
Yes, the new text is fine.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9983
Martin v. Löwis mar...@v.loewis.de added the comment:
-1 on this patch; I think any change must get consensus on python-dev first,
and there is no point in resolving this in the bug tracker. If no agreement can
be found (which is actually likely), a PEP needs to be written.
My personal
Martin v. Löwis mar...@v.loewis.de added the comment:
Please run msiexec /i python-2.7.msi /l*v python.log, and compress and attach
the resulting log file.
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10002
Martin v. Löwis mar...@v.loewis.de added the comment:
In this specific run, the critical error was this:
MSI (s) (38:74) [00:36:38:068]: Assembly Error:Der angeforderte Vorgang war
nicht erfolgreich. Es ist ein Systemneustart erforderlich, um die
durchgeführten Änderungen rückgängig zu machen
Changes by Martin v. Löwis mar...@v.loewis.de:
--
title: requested log file - Installer doesn't install on Windows Server 2008
DataCenter R2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10002
Martin v. Löwis mar...@v.loewis.de added the comment:
Attach some file
--
keywords: +patch
Added file: http://bugs.python.org/file19097/README.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2771
Martin v. Löwis mar...@v.loewis.de added the comment:
Éric: which patch: file18807, or http://codereview.appspot.com/2340041/?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9807
Martin v. Löwis mar...@v.loewis.de added the comment:
2.6 is closed for bug fixes, so this cannot be applied anymore.
Notice that py3k has this fixed in r84068; I'll backport the fix to 2.7.
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
Martin v. Löwis mar...@v.loewis.de added the comment:
AFAICT, they are compatible, so +1.
The typical proposition of an incompatible change either proposes to use const
char* as the return type, or has multi-level pointers that are proposed to be
constified
Changes by Martin v. Löwis mar...@v.loewis.de:
--
versions: -Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6792
___
___
Python-bugs
Martin v. Löwis mar...@v.loewis.de added the comment:
The advice is still necessary, AFAIK. The issue is Windows, in particular
producing function pointers across DLL boundaries. In Python core, this is not
an issue, since the references will all be inside pythonXY.dll
Martin v. Löwis mar...@v.loewis.de added the comment:
I'd rather not reopen this issue. It was too far-ranging, and has failed to get
a specific solution. Please stop posting to this closed issue; if you want to
contribute, please open a new one.
I think the inclusion of the module should see
Martin v. Löwis mar...@v.loewis.de added the comment:
Did this fix actually make the 2.7 release?
Are you sure you posted to the right issue? I fail to see the
relationship between your message and the original report.
If you found a bug in Python 2.7, please report it as a
separate issue
Martin v. Löwis mar...@v.loewis.de added the comment:
Antoine: Python cannot possibly know whether a command line argument is meant
as a file name or as some other text, and what encoding the receiving
application will apply to it (if any).
I agree it's best to have all IO encodings being
Martin v. Löwis mar...@v.loewis.de added the comment:
The most likely values to be non-ASCII are, therefore, file paths. So it
would make sense to also use the filesystem encoding for environment
variables (so as to satisfy the common case).
-1. Environment variables are typically set
Martin v. Löwis mar...@v.loewis.de added the comment:
If the mere existence of the fsname encoding leads to that much
confusion, I think I also support its removal.
Well, the fsname encoding has a hardwired value under OS X (regardless
of the locale), which kind of justifies its existence
Martin v. Löwis mar...@v.loewis.de added the comment:
Am 09.10.2010 14:07, schrieb Antoine Pitrou:
Antoine Pitrou pit...@free.fr added the comment:
For the command line, it would mean that we
introduced a new encoding: command line encoding, which will be utf-8 on
OSX.
Or more
Martin v. Löwis mar...@v.loewis.de added the comment:
I find it quite clear. failure not only means that no item was found, but
also that the operation failed, i.e. raised an exception. In general, a NULL
pointer returned from a function that returns PyObject* *always* means
Martin v. Löwis mar...@v.loewis.de added the comment:
kiorky: see my msg55157. Python behaves correctly as it stands - raising the
exception is fully intentional. It's not a bug that it gets raised; dates
before 1900 are just not supported. Adding support for them is a new feature
Martin v. Löwis mar...@v.loewis.de added the comment:
Am 10.10.2010 17:51, schrieb STINNER Victor:
STINNER Victor victor.stin...@haypocalc.com added the comment:
We run into problems because we have two inconsistent encodings,
...
What? No. We have problems because we don't use
Martin v. Löwis mar...@v.loewis.de added the comment:
For the command line arguments and environment variables, we don't have a lot
of choices: locale or filesystem encodings. So Antoine and Martin: which
encoding do you prefer?
I still propose to drop the fsname encoding
Martin v. Löwis mar...@v.loewis.de added the comment:
I don't know what you mean by dropping, since OS X by construction needs
a filesystem encoding (utf-8) different from the locale encoding;
See above. I propose to stop using the locale encoding for command line
arguments and environment
901 - 1000 of 4659 matches
Mail list logo
