Martin v. Löwis added the comment:
Lars, any comment?
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel, loewis
___
Python tracker
<http://bugs.python.org/issu
Martin v. Löwis added the comment:
The approach looks fine to me. Would you like to work on a patch?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue12
Martin v. Löwis added the comment:
The patch looks fine to me.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue12904>
___
___
Python-bugs-list m
Martin v. Löwis added the comment:
I don't think it's necessary. People who want to get at the files can do an
administrative installation, and put the files anywhere they like.
Therefore, I won't work on this myself; somebody would have to contribute the
code. It will be dif
Martin v. Löwis added the comment:
> Martin, what do you mean "administrative installation"?
That's what you get when you do "msiexec /a .msi".
http://en.wikipedia.org/wiki/Windows_Installer#Administrative_installation
--
title: In MSI/EXE installer, all
Martin v. Löwis added the comment:
I'm -1 on this approach; I don't think yet another container type is the right
solution, given that we have already plenty of them.
If you want to avoid creating large lists, then the StringIO type should
already provide that. So I wonder
Martin v. Löwis added the comment:
> This predates both the inclusion of Decimal in Python (2.4) and
> nanosecond resolution in the utime API (2008). I could find no
> discussion of the change, so I don't know what other representations
> were considered. It's hard to
Martin v. Löwis added the comment:
This must be a duplicate report - this issue has been known for years, and
Kristjan and others (including myself) volunteered to work on it, and did
actually work on it.
I don't think it's necessary to have a bug report in the bug tracker for i
Martin v. Löwis added the comment:
What date would the final release then be made? It would be best if it could be
done before Aug 27. If necessary, I could also make a release on September 6
(but not any day before or after)
--
___
Python tracker
Martin v. Löwis added the comment:
The bug is not a regression since 2.6.5; AFAICT, it was in Python "forever". I
recommend to revert the checkin, and postpone fixing it to 2.7.1.
--
___
Python tracker
<http://bugs.python.
Changes by Martin v. Löwis :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue2944>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Martin v. Löwis :
--
versions: -Python 2.6
___
Python tracker
<http://bugs.python.org/issue9597>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
$ grep getpath PCbuild/*
PCbuild/pythoncore.vcproj:
RelativePath="..\PC\getpathp.c"
So it's fairly obvious that it is used, no?
--
___
Python tracker
<http
Martin v. Löwis added the comment:
No, the guards are probably redundant.
--
___
Python tracker
<http://bugs.python.org/issue9596>
___
___
Python-bugs-list mailin
Martin v. Löwis added the comment:
Notice that this is also a duplicate of #9144, which was fixed for 2.7, but
nobody bothered to move the fix to the other branches. This goes all back to
#7902, which has now introduced an incompatible change into 2.6 (otherwise,
changing multiprocessing
Martin v. Löwis added the comment:
Backporting this change to 2.6 has created an incompatibility in that branch,
see for example issue9600. Apparently, it will only break code that is
"conceptually wrong", but still "worked" on 2.6.
I'll suggest that this is a r
Changes by Martin v. Löwis :
--
priority: normal -> release blocker
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue7902>
___
___
Pyth
Martin v. Löwis added the comment:
Re msg113792: Nick, running the clean step before configure is not possible. It
requires a Makefile, which isn't there yet.
--
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
Considering the notice
---
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
Usually, copying Modules/Setup.dist to Modules/Setup will
Martin v. Löwis added the comment:
Using chunked writes is tricky. If the first write succeeds, and the second one
fails, how do you report the result?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue8
Martin v. Löwis added the comment:
For the length hint, it would be best to use PyLong_FromSize_t, as in
dictobject.c. It would be sad if __length_hint__ would return a much-too-small
value (or even a negative number).
For the search finger, dictobject has opted to make me_hash of type
Martin v. Löwis added the comment:
Using chunked writes is tricky. If the first write succeeds, and the second one
fails, how do you report the result?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue9
Changes by Martin v. Löwis :
--
Removed message: http://bugs.python.org/msg113981
___
Python tracker
<http://bugs.python.org/issue8650>
___
___
Python-bugs-list m
Martin v. Löwis added the comment:
> Most people use buffered I/O, and the buffered layer automatically retries.
I see. I think this is already slightly problematic: if you send an
interrupt, it won't oblige. IMO, any such loop ought to be
inter
Martin v. Löwis added the comment:
> Well, the loop stops when an error status is returned by the raw IO
> layer. At that point, the buffered IO layer re-raises the error after a
> bit of internal cleanup.
Assume the following case:
1. writing starts, and writes some data
2. Ctrl-C i
Martin v. Löwis added the comment:
Try setting HOST_PYTHON.
--
___
Python tracker
<http://bugs.python.org/issue9615>
___
___
Python-bugs-list mailing list
Unsub
Martin v. Löwis added the comment:
Why do you say "modifications to the deepcopied structure were
affecting the original"? Your code sample doesn't include any modifications to
the deepcopied structure.
Try modifying it, and watch the original remaining unchanged.
-
Martin v. Löwis added the comment:
Numbers are immutable, and hence don't need to be copied. In fact, it is
impossible to create two int object that both have the value 4, but are
different objects:
py> 2+2 is 3+1
True
--
___
Python
Martin v. Löwis added the comment:
It can't go into 2.x anymore.
--
versions: +Python 3.2 -Python 2.6, Python 2.7
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
Using www.google.com for IPv6 lookups is a bad idea: whether or not you get an
IPv6 address depends on whether your nameserver participates in "google over
ipv6". www.python.org would be a bet
Martin v. Löwis added the comment:
I'm not sure whether backporting it to 3.1 is a good idea. It's potentially an
ABI change (although a minor one, as the field offsets remain the same, only
the interpretation of the padding
Martin v. Löwis added the comment:
Why is PyLong_FromSocket_t defined in a header file in the first place? The
only caller is in socketmodule.c, and calling it elsewhere wouldn't work,
anyway, since it relies on SOCKET_T being defined.
So -1 on the
Martin v. Löwis added the comment:
> I agree, but it was already like that, and I didn't want to change it.
This goes back to issue 1378. Christian, do you recall why you needed to add
the helper macros to a header file? You said
# Added PyLong_FromSocket_t and PyLong_AsSoc
Martin v. Löwis added the comment:
You are misinterpreting what you are seeing. The message you get is not an
error message. It works all fine, and correctly. To build the sunaudiodev
module, you need Sun/Oracle Solaris, not Linux.
--
nosy: +loewis
resolution: -> invalid
sta
Martin v. Löwis added the comment:
What file system is this on?
--
___
Python tracker
<http://bugs.python.org/issue9631>
___
___
Python-bugs-list mailin
Martin v. Löwis added the comment:
Anybody *really* interested in this issue: somebody will need to write a PEP,
get it accepted, and provide an implementations. Open source is about
scratching your own itches: the ones affected by a problems are the ones which
are also expected to provide
Martin v. Löwis added the comment:
> mbcs functions don't use the wchar_t type.
That's not true. MultiByteToWideChar use LPWSTR, which is a typedef for
wchar_t*.
These functions assume that Py_UNICODE is the same type as WCHAR.
> We should just check that we are compiling un
Martin v. Löwis added the comment:
No, we should keep both. bdist_wininst provides which which bdist_msi cannot
provide.
--
status: pending -> open
___
Python tracker
<http://bugs.python.org/issue1
Martin v. Löwis added the comment:
For cross-3.0-0.7.diff, we would need a real name and a contributor agreement.
Of course, attribution is muddy here; this literally goes back to sraue's
patch, which in turn goes back to scott.tsai's patch.
I'm still uncertain what it is
Martin v. Löwis added the comment:
I don't think anything in distutils can solve whatever the problem is that
people perceive.
All I can say about the patch is that it apparently doesn't do any harm. I
expect that, if it is accepted, people continue complain that "i
Martin v. Löwis added the comment:
Thanks for the patch. Committed as r84261.
I'm not sure what the point is of supporting IDNA in getnameinfo, so I have
removed that from the patch. If you think it's needed, please elaborate.
--
Changes by Martin v. Löwis :
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue1027206>
___
___
Python-bugs-
Martin v. Löwis added the comment:
Is this patch in response to an actual problem, or a theoretical problem?
If "actual problem": what was the specific application, and what was the
specific host name?
If theoretical, I recommend to close it as "won't fix". I find it
Martin v. Löwis added the comment:
>> Is this patch in response to an actual problem, or a theoretical problem?
>> If "actual problem": what was the specific application, and what was the
>> specific host name?
>
> It's about environments, not applicatio
Martin v. Löwis added the comment:
> That would be an improvement. The idea of the patches I posted
> is to combine this with the existing surrogateescape mechanism,
> which handles situations like this perfectly well.
The surrogateescape mechanism is a very hackish approach, and
vio
New submission from Martin v. Löwis :
Copy of issue 1027206; support in the socket module was provided, but this
request remains:
Also other modules should support unicode hostnames.
(httplib already does) but urllib and urllib2 don't.
--
components: Library (Lib), Unicode
key
Martin v. Löwis added the comment:
I have now committed file 18615 as r84313: thanks for the patch.
I have split this issue into two: this one is only about the socket module, and
#9679 carries any remaining features (it would be good if we have only one bug
per bug report).
Since the
Martin v. Löwis added the comment:
>From msg60564: it's not clear to me what this request really means. It could
>mean that Python should support IRIs, but then, I'm not sure whether this
>support can be in urllib, or whether a separate libr
Martin v. Löwis added the comment:
Ok, I'm closing this as "won't fix". The OP doesn't have the issue anymore;
anybody else having some issue please report that separately (taking into
account that you are likely asked to provide a patch as well).
--
resolu
Martin v. Löwis added the comment:
> why is it a UnicodeError?
Because IDNA is an encoding, and codecs are supposed to raise UnicodeErrors.
The string you are trying to encode is not supported in the encoding in
question.
It would be possible to catch the UnicodeError, and re-raise it a
Martin v. Löwis added the comment:
> I don't see how a name resolution API returning non-ASCII bytes
> would indicate an error.
It's in violation of RFC 952 (slightly relaxed by RFC 1123).
> But to be more explicit, that's like saying "if it hurts, get
>
Martin v. Löwis added the comment:
> Ah, I wondered if it was something like that
> (encoding=>UnicodeError). It's not really a *unicode* error, it's a
> syntax error in the domain name construction (ie: it is invalid
> whether or not unicode is involved, it just isn&
Martin v. Löwis added the comment:
Which specific clause of the license do you consider violated?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue9
Martin v. Löwis added the comment:
Python 2.7 and Python 3.1 are supported for bug fixes.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue9
Martin v. Löwis added the comment:
>> Which specific clause of the license do you consider violated?
>
> * 3. All advertising materials mentioning features or use of this
> *software must display the following acknowledgment:
> *"This product includes so
Martin v. Löwis added the comment:
> I'd suggest to add a paragraph like this to the release pages:
-1, unless the PSF lawyer advises that such a paragraph is indeed
necessary. It may shy away users from using Python, which is clearly
und
Martin v. Löwis added the comment:
> I feel this breaks most people's expectations...
I think you are quite mistaken in this assumption. Sure, object references are
difficult to grasp at first, but they are a highly useful concept, and follow
very simple, systematic principles -
Martin v. Löwis added the comment:
> Since we are not following those old-style BSD license requirements
You state that is if it was a fact, which is it not. We, indeed, fully
comply with the license requirements.
> The python.org site is full of references to OpenSSL. Most
> promi
Martin v. Löwis added the comment:
david, please accept that regardless of whether this is a bug or not, people
dealing with bug reports will always determine that it is no bug, and close it.
*Please stop reopening this report*.
If you want to appeal to this decision, please post a message
Martin v. Löwis added the comment:
> It's not reasonable when addressed to a customer who might go
> elsewhere.
I remain -1 on this change, until such a customer actually shows
up at a Python developer.
--
title: socket, PEP 383: Mishandling of non-ASCII bytes in host/d
Martin v. Löwis added the comment:
It certainly builds fine on Linux; I also believe it builds fine on OSX. In
either case, it should use the system zlib; the included zlib will be used only
on Windows, and on systems that don't have a system zlib.
I certainly didn't include all
Martin v. Löwis added the comment:
Ok, I have now added these files in r84332.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Martin v. Löwis added the comment:
Unfortunately, Tix just won't build that easily. Patches are welcome.
It may be worthwhile to rely on build_tkinter.py exclusively (but that often
doesn't work, either).
--
___
Python trac
Martin v. Löwis added the comment:
This patch is incorrect. The naming of the directories as in msi.py is correct;
the naming in Tools/buildbot is slightly inappropriate.
Tix relies on the specific directory names referred-to by msi.py, hence I use a
different in my buildarea than Tools
Martin v. Löwis added the comment:
Thanks for the patch, committed as r84487. I'll try it out with the next 3.2
alpha release.
Leaving this open for possible backports.
--
___
Python tracker
<http://bugs.python.org/issu
Changes by Martin v. Löwis :
--
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/issue1303434>
___
___
Python-bugs-list mailing list
Un
Martin v. Löwis added the comment:
As this was never meant for inclusion in Python, and apparently confuses
people, I'm closing it - it couldn't go into 2.x, anyway.
--
resolution: -> out of date
status: open -> closed
___
Pytho
Martin v. Löwis 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
___
P
Martin v. Löwis 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 tracker
Martin v. Löwis 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 is meant
to resolve
Martin v. Löwis 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 - but
Changes by Martin v. Löwis :
--
resolution: -> works for me
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9775>
___
___
Pyth
Martin v. Löwis 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 into acc
Martin v. Löwis 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
<http://bugs.python.org/i
Martin v. Löwis 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 in
Martin v. Löwis added the comment:
Am 05.09.2010 13:12, schrieb Antoine Pitrou:
>
> Antoine Pitrou 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
Martin v. Löwis 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
<http://bugs.python.org/issue8
Martin v. Löwis 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 to bitb
Martin v. Löwis 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
<http://bugs.python.org/issue9
Martin v. Löwis 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 recommend that the
Martin v. Löwis 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 into
XML documents
Martin v. Löwis 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
/*
* This may look like an
Martin v. Löwis added the comment:
The ifdef should go; pthreads always support TLS (since XPG5, 1997).
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue9
Martin v. Löwis 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 layering
New submission from Martin v. Löwis :
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 added the comment:
No.
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue9839>
___
___
Pyth
Martin v. Löwis 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 created them tha
Martin v. Löwis 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 in the NIS database
Martin v. Löwis 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 a checkou
Martin v. Löwis added the comment:
+1
--
___
Python tracker
<http://bugs.python.org/issue9042>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis 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 that talks about very old
Martin v. Löwis 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 creating
Martin v. Löwis 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 -> clo
Changes by Martin v. Löwis :
--
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/issue9817>
___
___
Python-bugs-list mailing list
Unsubscri
Martin v. Löwis added the comment:
What do you gain with this patch? (i.e. what is its advantage?)
--
___
Python tracker
<http://bugs.python.org/issue9
Martin v. Löwis 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 the
Martin v. Löwis 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. It was a
Martin v. Löwis 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 stri
Martin v. Löwis added the comment:
Use PCbuild/bdist_wininst.vcproj.
--
___
Python tracker
<http://bugs.python.org/issue9818>
___
___
Python-bugs-list mailin
Martin v. Löwis 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
501 - 600 of 4778 matches
Mail list logo
