Martin v. Löwis 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
Martin v. Löwis 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) and
> PyUnicode_DecodeF
Martin v. Löwis 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 -
Martin v. Löwis 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 memo
Martin v. Löwis 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 is
0x, i.
Martin v. Löwis 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 state to make
Martin v. Löwis added the comment:
Am 13.09.2010 10:00, schrieb Kristján Valur Jónsson:
>
> Kristján Valur Jónsson added the comment:
>
> I've changed the function as you suggest, although there are in fact no
> failure detection semantics defined for PyThread_create_key
Martin v. Löwis 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 mann
Martin v. Löwis 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 t
Martin v. Löwis 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 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 no
Martin v. Löwis 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 val
Martin v. Löwis 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
<http://bugs.python.org/issue9
Martin v. Löwis 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 comment; I
Martin v. Löwis 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 syst
Martin v. Löwis 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: every ti
Martin v. Löwis added the comment:
Am 16.09.10 14:06, schrieb Armin Ronacher:
>
> Armin Ronacher added the comment:
>
>> Hmm. So under what conditions should it continue, and under what
>> conditions should it raise an exception (when errno is EINTR)?
>
> EINTR in
Martin v. Löwis 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
Martin v. Löwis 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 :
--
resolution: -> invalid
___
Python tracker
<http://bugs.python.org/issue9900>
___
___
Python-bugs-list mailing list
Unsubscri
Martin v. Löwis 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 cl
Martin v. Löwis 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: flush,
Martin v. Löwis 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 with
Martin v. Löwis 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 is gained by
Martin v. Löwis added the comment:
Looks fine to me.
--
___
Python tracker
<http://bugs.python.org/issue678250>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Martin v. Löwis :
--
Removed message: http://bugs.python.org/msg117109
___
Python tracker
<http://bugs.python.org/issue678250>
___
___
Python-bug
Changes by Martin v. Löwis :
--
Removed message: http://bugs.python.org/msg117108
___
Python tracker
<http://bugs.python.org/issue678250>
___
___
Python-bug
Changes by Martin v. Löwis :
--
Removed message: http://bugs.python.org/msg117107
___
Python tracker
<http://bugs.python.org/issue678250>
___
___
Python-bug
Changes by Martin v. Löwis :
--
Removed message: http://bugs.python.org/msg117106
___
Python tracker
<http://bugs.python.org/issue678250>
___
___
Python-bug
Changes by Martin v. Löwis :
--
Removed message: http://bugs.python.org/msg117110
___
Python tracker
<http://bugs.python.org/issue678250>
___
___
Python-bug
Martin v. Löwis 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
<h
New submission from Martin v. Löwis :
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 defined (which it
Martin v. Löwis 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
<http://bugs.python.org/issue9
Martin v. Löwis 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 they are defined by the
Martin v. Löwis added the comment:
-1 for the patch. I still maintain that it is better to follow the current SDK.
--
___
Python tracker
<http://bugs.python.org/issue9
Martin v. Löwis 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 TestSuite
Martin v. Löwis 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 Windo
Martin v. Löwis 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, &a
Martin v. Löwis 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
Martin v. Löwis added the comment:
Closing, as suggested by neologix
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Martin v. Löwis :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9952>
___
___
Python-bugs-
Martin v. Löwis 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 for command line access are
Changes by Martin v. Löwis :
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9954>
___
___
Python-bugs-
Changes by Martin v. Löwis :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue9980>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis 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 added the comment:
Yes, the new text is fine.
--
___
Python tracker
<http://bugs.python.org/issue9983>
___
___
Python-bugs-list mailing list
Unsub
Martin v. Löwis 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 favorite would be to a
Martin v. Löwis 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
<http://bugs.python.o
Martin v. Löwis 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.
So please do
Changes by Martin v. Löwis :
--
title: requested log file -> Installer doesn't install on Windows Server 2008
DataCenter R2
___
Python tracker
<http://bugs.python.org
Martin v. Löwis added the comment:
Attach some file
--
keywords: +patch
Added file: http://bugs.python.org/file19097/README.diff
___
Python tracker
<http://bugs.python.org/issue2
Martin v. Löwis added the comment:
Éric: which patch: file18807, or http://codereview.appspot.com/2340041/?
--
___
Python tracker
<http://bugs.python.org/issue9
Martin v. Löwis 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
<http://bugs.python.org/is
Martin v. Löwis 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 :
--
versions: -Python 2.6
___
Python tracker
<http://bugs.python.org/issue6792>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis 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 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 a discussi
Martin v. Löwis 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 is
Martin v. Löwis 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 the
Martin v. Löwis 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 in a text
Martin v. Löwis 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 justif
Martin v. Löwis added the comment:
Am 09.10.2010 14:07, schrieb Antoine Pitrou:
>
> Antoine Pitrou 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
Martin v. Löwis 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 that
there is an except
Martin v. Löwis 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 fe
Martin v. Löwis added the comment:
Am 10.10.2010 17:51, schrieb STINNER Victor:
>
> STINNER Victor added the comment:
>
>> We run into problems because we have two inconsistent encodings,
>> ...
>
> What? No. We have problems because we don't use the same en
Martin v. Löwis 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. Then this ques
Martin v. Löwis 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 varia
Martin v. Löwis added the comment:
> You mean that we should use the following encoding for the command line
> arguments, environment variables and all filenames/paths:
> - Mac OS X: utf-8
> - Windows: unicode for command line/env, mbcs to decode filenames
No: unicode for fi
Martin v. Löwis added the comment:
> If you remove both, Python will get very poor grades for OS
> interoperability on platforms that often deal with multiple
> different encodings for file names.
Why that? It will work very well in such a setting, much better
than,
Martin v. Löwis added the comment:
Notice that the error shows further up in the output, at the point where the
test was actually run:
gcc: ${LDFLAGS}: No such file or directory
--
___
Python tracker
<http://bugs.python.org/issue9
Martin v. Löwis added the comment:
> There is one reason for not wanting to assume that the encoding is
> always UTF-8: the user might access the system from a non-UTF8
> terminal (such as when logging in with an SSH session from a system
> not using UTF-8, or using an altern
Martin v. Löwis added the comment:
> Being pedantic about forcing some encoding onto things that don't
> have an encoding won't really work out in practice. Dealing with
> file names, OS environments, pipes and sockets is dirty work, so
> I think we should go with the 80
Martin v. Löwis added the comment:
> You can't possibly expect a user to switch to using UTF-8 for
> all his/her applications just because Python needs this to
> properly decode file names.
If the user hasn't switched to UTF-8, why would Python need that
to properl
Martin v. Löwis added the comment:
I don't understand. If the code is already Python 3 code, why are you running
2to3 on it?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
I still don't understand. If it's 2.x code, why do you want to say that it is
3.x code?
If you don't want to run a specific fixer, you can exclude it from the list of
fixers.
--
___
Python
Martin v. Löwis added the comment:
Maybe we need to tackle this from a different angle: can you please specify the
feature you are asking for exactly, with any syntax, API, or command line
changes that you consider necessary?
Omitting redundant parentheses for print is a separate issue (feel
Martin v. Löwis added the comment:
The patch is incorrect. Even though this may let get these characters
"through", the other end will have no clue that \x is meant as an escape.
Please face the ugly truth: XML (and hence XML-RPC) just does not support these
characters, see http://
Martin v. Löwis added the comment:
> How about this phrasing: “Make 2to3 fixers not touch code in a block
> starting with ’if sys.version >= '3'’“ (and hexversion, version_info,
> you get the idea)?
I don't think this can work. You may have to write code like
Martin v. Löwis added the comment:
>> I don't think this can work. You may have to write code like
>>
>> if sys.version_info >= (3,):
>> try:
>> some_code()
>> except Exception, e:
>> pass
>>
>> (i.e. not use the "
Martin v. Löwis added the comment:
What operating system are you using? What compiler?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
Ok, unless you are using the very same compiler that Python was compiled with,
this will indeed crash. Closing this as "won't fix", then - use
PyRun_SimpleString instead.
--
resolution: -> wont fix
stat
Martin v. Löwis added the comment:
No, CDATA is not an appropriate mechanism to encapsulate bytes in XML. The data
in the CDATA section must still match the Char production, and it must still
follow the encoding.
--
___
Python tracker
<h
Martin v. Löwis added the comment:
It's probably more Python's implementation that Андрей is interested in,
however, I agree that this is off-topic for this bug tracker, and that
comp.lang.python might be a better place. You can also answer these questions
by studying the Python s
Martin v. Löwis added the comment:
Éric, I think the patch needs some rework. First, it is incorrect/incomplete:
please see the Char definition for a complete list of characters that must be
excluded. This then raises a Unicode vs. bytes issue, where invalid Unicode
characters must be
New submission from Martin v. Löwis :
Reportedly, platform.uname gives UnicodeError for non-ASCII computer names on
Windows, see http://www.pasteall.org/16215
I think it is incorrect that _node uses socket.gethostname on Windows. uname()
should return the local hostname (i.e. the one that the
Martin v. Löwis added the comment:
The failure of platform.uname is an independent bug. IMO, it shouldn't use
socket.gethostname on Windows, but instead look at the COMPUTERNAME environment
variable or call the GetComputerName API function. This is more close to what
uname() does on
Martin v. Löwis added the comment:
One solution would be to duplicate the UTF-8 decoder for OSX, incorporating
surrogate escape. This should be much shorter than the full UTF-8 codec, and
perhaps at least utf8_code_length could be shared
Martin v. Löwis added the comment:
We shouldn't need to reopen the file in the first place. If we already have a
file handle, we can rewind it. Then the encoding of the file name becomes
irrelevant.
I keep forgetting: what was the plan for deprecating the FILE* functions in the
p
Martin v. Löwis added the comment:
Vlastil, what makes you think that issue2636-20101009.zip is a 64-bit version?
I can only find 32-bit DLLs in it.
--
___
Python tracker
<http://bugs.python.org/issue2
Martin v. Löwis added the comment:
> There are two issues here:
There are two issues, but not here :-)
> 1. socket.gethostname() shouldn't raise an error on Windows, but
>return the Unicode host name
This is issue 9377, please keep that out of this issue.
> Could som
Martin v. Löwis added the comment:
As a further note: I think socket.gethostname() is a special case, since this
is just about a local setting (i.e. not related to DNS). We should then assume
that it is encoded in the locale encoding (in particular, that it is encoded in
mbcs on Windows
Martin v. Löwis added the comment:
> More evidence that the NetBIOS name is used:
>
> http://msdn.microsoft.com/en-us/library/aa368009(VS.85).aspx
> http://msdn.microsoft.com/en-us/library/ms724295(v=VS.85).aspx
>
> One problem with this approach is that changes to the NetB
Martin v. Löwis added the comment:
Please note that the error is not in the third decimal position, but only in
the 16th (i.e. the difference between the intended value and the actual value
is smaller than 0.0001).
--
nosy: +loewis
Martin v. Löwis added the comment:
> From my understanding of the documentation, the expected behavior
> is for xmlrpclib to raise an xmlrpclib.Fault [...]
What specific wording in the documentation makes you thinks so?
If anything, I'd expect a ResponseError (which appears u
Martin v. Löwis added the comment:
Not necessarily a separate report. Would you be interested in writing a patch
that clears that all up (for 2.7 and/or 3.2)?
--
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
Interesting. I'd like to propose than that this is resolved as "won't fix",
i.e. embedding Python into Delphi is declared as just not supported (or using
floating-point operations in such an environm
Martin v. Löwis added the comment:
Am 15.10.2010 20:03, schrieb David Watson:
>
> David Watson added the comment:
>
>> As a further note: I think socket.gethostname() is a special case, since
>> this is just about a local setting (i.e. not related to DNS).
>
Martin v. Löwis added the comment:
> The issue Raymond raised is the potential impossibility of making the
> change /after/ we settle on a stable ABI. The question is whether the
> ABI will be enforced starting from 3.2, or from a later date.
I'd like to repeat that it will not
Martin v. Löwis added the comment:
Assuming the patch doesn't cause warnings on the compilers that we use, it
looks fine to me.
--
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
> Can't we just do it now, and be done with it regardless of the stable ABI?
Sure. Somebody needs to implement it (and consider what consequences
this has on third-party modules - I'm uncertain).
--
_
601 - 700 of 4778 matches
Mail list logo
