Martin v. Löwis added the comment:
> So lacking a new patch, I think we should revert the existing change
> for now.
Oops, I missed that Alexander has proposed a patch.
--
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
> The logic suggested by Martin in msg120018 looks right to me, but the
> whole code seems to be unnecessarily complex. (And comb1==comb may
> need to be changed to comb1>=comb.) I don't understand why linear
> search through "skip
Martin v. Löwis added the comment:
> Passing Part3 tests and not crashing on crash.py is probably good
> enough for a commit, but I don't have a proof that length 20 skipped
> buffer is always enough.
I would agree with that. I still didn't have time to fully review the
pat
Martin v. Löwis added the comment:
> The C forms (NFC and NFKC) do canonical composition and U+FDFA is a
> compatibility composite. (BTW, makeunicodedata.py checks that maximum
> decomposed length of a character is < 19, but it would be better if it
> would compute and define a
Martin v. Löwis added the comment:
> I would like to see this reopened: we have a very large class of
> users that are not ready to entirely port to 64-bit and need this
> now.
And I remain -1 to such requests. You can appeal to that by writing a
PEP, or finding a committer who is w
Martin v. Löwis added the comment:
I fail to see the problem. The context is a plain void*, not (necessarily) a
function pointer, and getargs uses it with the same type it put in. Why do you
think PyCapsule_Destructor is of relevance
Martin v. Löwis added the comment:
This is tricky. It's clearly ill-formed XML, so I'm not sure that this needs to
be bug-compatible with Apple's implementation.
--
nosy: +loewis
___
Python tracker
<http://bugs.pyt
Martin v. Löwis added the comment:
I don't think this needs to block the beta release.
--
___
Python tracker
<http://bugs.python.org/issue10734>
___
___
Martin v. Löwis added the comment:
The problem is that the nested group doesn't share/propagate mutually exclusive
groups with its parent container. The attached patch fixes this.
--
keywords: +patch
Added file: http://bugs.python.org/file20114/argparse
Martin v. Löwis added the comment:
On Windows, using the bytes APIs for filenames is unreliable and fails for
characters that are not in the ANSI code page. So you should use
import os
for i in os.listdir(u'.'):
print os.path.isfile(i), '\t', i
instead.
Martin v. Löwis added the comment:
What's the use case for this function?
--
___
Python tracker
<http://bugs.python.org/issue10755>
___
___
Python-bugs-l
Martin v. Löwis added the comment:
This is not a bug. Your code that produces "very nasty filename" is the right
one - the file name is actually the one you asked for. The second code is also
behaving correctly: filename already *is* a bytestring, calling .encode for it
is m
Martin v. Löwis added the comment:
Oops, I take this back - I didn't notice you were using Python 3.1.
In any case, your first code is correct. What you get is the best you can ask
for.
That the second case fails is indeed a bug.
--
resolution: invalid ->
status: closed
Martin v. Löwis added the comment:
I don't think we can change this for the maintenance branches. The code behaves
according to the documentation:
access(path, mode) -> True if granted, False otherwise
"False otherwise" is really meant that way: otherwise. The spec
Martin v. Löwis added the comment:
IIUC, the issue is that people installing a 64-bit Python, and VS Express, and
then wonder why they can't build extension modules. I'm not so sure that there
is a bug in Python here - this setup is not supported (and that's really
Microsof
Martin v. Löwis added the comment:
Thorsten: my recommendation is to ignore this issue in your software. It's just
a warning.
--
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
> So, in reverse of issue 4871, it appears that in this case the API should
> reject bytes input with an appropriate error message.
-1. It is quite common to produce ill-formed zipfiles, and other
ziptools are interpreting them in violation of the
Martin v. Löwis added the comment:
Why do you think this is a bug in Python?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10776>
___
___
Pytho
Martin v. Löwis added the comment:
The documentation is incorrect; writexml does not support an encoding
parameter. Only Document nodes support the encoding parameter in writexml, and
it is intentional that its only effect is to fill out the XML declaration.
I don't understand the
Martin v. Löwis added the comment:
> The last sentence has nothing to do with the report, it was just a general
> remark that
> it would be nice if minidom could support unicode string directly.
minidom most certainly supports Unicode directly. All element names,
attribute names,
Martin v. Löwis added the comment:
> Looks good. Would there be a point in making any of the parameters optional?
No. The API should look exactly as it does on the system level. Anybody
calling these functions should know how call t
Martin v. Löwis added the comment:
> Just for the record, I was about to try to do this, when I realized that
> exposing prctl requires expecting a variable number of arguments with
> variable types.
> It turns out providing a Python wrapper for such a kind of C API is ju
Martin v. Löwis added the comment:
>> Seriously, it can wait 3.3.
>
> What exactly can wait until 3.3? The presented patch introduces no
> user visible changes. It is only a stepping stone to restoring some
> sanity in a way supplementary characters are treated by narrow
Martin v. Löwis added the comment:
> Are you serious? This sounds like a py4k idea. Can you give us a
> hint on what the new representation will be?
I'm thinking about an approach of a variable representation:
one, two, or four bytes, depending on the widest character that
app
Martin v. Löwis added the comment:
> Actually, it looks like PEP 3131 and the Language Reference [1] still
> disagree. The latter says:
>
> identifier ::= id_start id_continue*
>
> which should probably be
>
> identifier ::= xid_start xid_continue*
>
> i
New submission from Martin v. Löwis :
This is similar to #10348, but has a different scope; the attached patch
disables the ProcessPoolExecutor if the system has too few POSIX semaphores.
To keep support for the ThreadPoolExecutor, I had the test cases stop using
multiprocessing.Event in the
Martin v. Löwis added the comment:
The attached patch fixes it for me. No time to write tests right now.
--
keywords: +patch
Added file: http://bugs.python.org/file20205/zipfile.diff
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
I find the solution (running every test in a subprocess) a bit too drastic for
the problem. How about a modified approach: run regrtest with -S, and have it
create a subprocess for test_site only?
--
___
Python
Martin v. Löwis added the comment:
I think the policy is that it is ok to add more 3k warnings to 2.7; these are
not considered new features (or explicitly exempted, or some such).
--
___
Python tracker
<http://bugs.python.org/issue4
Martin v. Löwis added the comment:
> Isn't it kind of a CPython-specific detail, though?
If other implementations do provide proper keyword arguments,
I'd be skeptical that they all settled on the names that the
library documentation gives to the arguments.
--
title: Doc
Changes by Martin v. Löwis :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10802>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
Can you please run the script under strace, and report what system call is not
implemented? I.e. put
import subprocess
subprocess.Popen('ls')
into a file (foo.py), then run
strace -o trace.txt python foo.py
Please attach the output i
Martin v. Löwis added the comment:
If more people report this, there is still something Python could do:
- the configure test could verify that the running kernel actually implements
the system call, and undefine HAVE_PIPE2 if that's not the case. Of course this
would only help i
Martin v. Löwis added the comment:
The patch looks still fine. The only concern is that the test probably fails on
FAT, but I think that's acceptable.
--
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
Hmm. I wonder why the code doesn't use the st_mtime field. We should really
deprecate the stat module.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
I like the logic of Antoine's patch much better (basing this on whether the
listening socket had a timeout). I wonder whether it's correct though if there
is a defaulttimeout: shouldn't it then leave the timeout on the
Martin v. Löwis added the comment:
Is this really the time for restructuring tests? I think such activity should
wait until after the 3.2 release.
--
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
Thanks for the review, committed as r87665. Fixing flaky tests is fine, of
course.
--
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
Follow-up: I have disabled test_all_completed_some_already_completed in r87667,
as I couldn't figure out why it hangs.
--
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
Interesting. I wonder whether a reboot of the system would help (as it may have
old semaphores hanging around).
--
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
I wonder why reading from /dev/urandom has a loop in the first place, though -
isn't it guaranteed that you can read as many bytes as you want in one go? This
goes back to #934711, and apparently, even the original patch had the loop -
for reasons tha
Martin v. Löwis added the comment:
haypo: please avoid introducing explicit casts (such as the one in pyexpat.c).
Use SAFECASTs instead. If you are absolutely certain that a cast cannot
possibly truncate, add a comment explaining why that is. In the specific case,
I think it actually *is
Martin v. Löwis added the comment:
Closing it. It seems that people feel more safe when urandom loops until it has
enough data (see
http://stackoverflow.com/questions/4598507/dev-urandom-maximum-size/4598534#4598534).
I might still pursue this idea, but in a different issue
Martin v. Löwis added the comment:
I think this patch (nonblock2.patch) is wrong. If I have a non-blocking server
socket on *BSD, and do accept, with no default timeout: IIUC, under the patch,
I will get a blocking connection socket. However, according to the operating
system API, I&#
Martin v. Löwis added the comment:
> "It's a bug in random.c that doesn' t check for signal pending inside the
> read(2) code, so you have no chance to kill the process via signals until
> the read(2) syscall is finished, and it could take a lot of time before
> ret
Martin v. Löwis added the comment:
> MvL> If you are absolutely certain that a cast cannot possibly truncate,
> MvL> add a comment explaining why that is.
>
> Ah yes, sorry, I forgot to add a comment: done in r87746.
But the comment is actually wrong: It says
len <= buf
Martin v. Löwis added the comment:
> Well, either the defaulttimeout should have the priority over the parent
> socket's settings (your argument in msg125135), or it shouldn't. I'm
> fine with both, but I think any more complicated combination would end
> up puzzlin
Martin v. Löwis added the comment:
I don't think we should adding tests to 2.7, perhaps unless there are also
fixes for it. So targetting 3.3+ only seems reasonable.
--
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
> Oh. Not only is the comment is wrong, but the code is also wrong. It
> should return a negative value on error, whereas it returns the string
> length which is always positive (except on a unlikely Py_ssize_t => int
> overflow?).
Right
Martin v. Löwis added the comment:
> Ok, here is a patch which prefers the default timeout (if set) over fixing of
> inherited flags. Tested under Linux, Windows, OpenSolaris.
This patch looks fine to me. Please also update the accept documentation
to explain the situation (new socke
Martin v. Löwis added the comment:
Alternatively, val_int should have type sqlite3_int64, which is the return type
of sqlite3_value_int64.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue8
Martin v. Löwis added the comment:
> Martin, we would like to exclude Py_buffer from the stable ABI for
> Python 3.2, until we have a chance to thrash out the missing pieces
> of the documentation for 3.3. I *think* it is a documentation
> problem, but until we're certain, it seems safer to lea
Martin v. Löwis added the comment:
Removal of the buffer interface from the ABI has been committed as r87805,
r87806, r87805, r87808, and r87809.
--
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
I fail to see the bug. Garbage in, garbage out. AFAIU, returning
/usr/bin/python2.7 still might be the wrong answer.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
> You'll see that read returns less that 100M bytes when interrupted.
I see.
> while len(data) < expected:
> read(expected - len(data))
>
> So we're sure it won't break under some systems/conditions.
I think this is not
Martin v. Löwis added the comment:
Patch looks mostly good. Some comments:
- sethostname supports names with embedded null bytes, so
wrapper should not use strlen
- it's a bit asymmetric that gethostname is in the socket
module and supports Windows, and sethostname is in the POSIX
m
Martin v. Löwis added the comment:
I wonder whether there is a precedent of some system mapping SIGINT to
an exception. We could probably learn something from them.
> - should KeyboardInterrupt always exit with SIGINT, or only if it was
> actually raised by a signal handler?
IMO, if w
Martin v. Löwis added the comment:
> I agree that not guessing would be better.
Well, on Linux, readlink("/proc/self/exe") would be better than
guessing.
--
___
Python tracker
<http://bugs.pytho
Martin v. Löwis added the comment:
Closing this as "won't fix". Python is not going to reimplement depends.exe.
--
nosy: +loewis
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bu
Martin v. Löwis added the comment:
> According to the spec for gethostname(), the hostname that it returns
> is null-terminated so it won't support embedded NUL bytes. Should we
> still add it anyway?
Oops, I misread the spec. No, gethostname should then not be duplicated.
Putti
Martin v. Löwis added the comment:
> According to the spec, gethostid does not set errno - it now checks anyway.
Sorry, I misread that also. Leaving the check is fine; reverting it to
the previous code would be fine as well.
--
___
Python trac
Martin v. Löwis added the comment:
I'm with Raymond here (probably not surprisingly): -1 on backporting new
features into 2.7. This really is foremost about having policies and sticking
to them; special cases aren't special enough to break the rules.
Personally, I haven't
Martin v. Löwis added the comment:
You should use begin/end allow threads when the system call might block. To get
an indication, trace through the kernel code of some system; my guess is that
these are typically non-blocking (i.e. return immediately) - but I might be
wrong
Martin v. Löwis added the comment:
Unless you think the code is actually incorrect as it stands, it's certainly
worse to change it (in whatever respect) than to leave it.
--
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
Brian: "On native Windows, "Read & Execute" has no real affect on
applications". Why do you say that? The FILE_EXECUTE permission certainly has a
meaning on Windows, see
http://msdn.microsoft.com/en-us/library/gg258116(v=v
Martin v. Löwis added the comment:
> Thank you @loewis. However, I don't see where
> set_default_verify_path - is defined in the patch you have provided.
It's not defined in the patch, as it is already committed to Python.
--
title: some stdlib modules need to be u
Martin v. Löwis added the comment:
> I would focus on trying to provide a unique interface across all
> platforms. Being sendfile() not a standard POSIX I think we should
> not worry about providing a strict one-to-one interface.
We absolutely need to expose sendfile as-is. If w
Martin v. Löwis added the comment:
> I thought that patches weren't meant to include the regenerated files.
Correct. Not including them is perfectly fine.
--
___
Python tracker
<http://bugs.python.org
Changes by Martin v. Löwis :
--
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue7
Martin v. Löwis added the comment:
You need to install the MS CRT (msvcrt90.dll, along with its assembly manifests
and stuff) as well; it's not surprising that copying over an installation
doesn't work.
I'll also point out that this is not a bug: copying over an installation i
Martin v. Löwis added the comment:
I think this issue falls into a similar category as support for
case-insensitive but case-preserving file systems. Python uses regular file
system lookups, but then may need to verify whether it got the right one.
I'd like to request that PEP 31
Martin v. Löwis added the comment:
> There is also issue c) what if the filesystem encoding can only
> represent a compatibility character, say U+00B5, but not its NFKC
> equivalent, U+03BC?
That should be considered as similar to file systems that just cannot
represent certain char
Martin v. Löwis added the comment:
> Only Mac OS X and the HFS+ filesystem normalize filenames (to a variant
> of NFD). But such normalization is a good thing! I mean that I don't
> think that we have anything to do for that.
That may well be - I don't have a case whe
Martin v. Löwis added the comment:
As this clearly seems to be a Tk bug, I suggest to close this report as "won't
fix - 3rd party".
--
nosy: +loewis
___
Python tracker
<http://bugs.pyt
Martin v. Löwis added the comment:
Notice that a boilerplate module is already available: xxlimited.c.
--
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
> I see your point. The problem is that IDLE is somewhat included with
> Python (so in a sense it is not "3rd party"), and seems like a good
> tool for learning Python: my concern is similar to that in message
> 126276 <http://
Martin v. Löwis added the comment:
> Hmm. It seems better to me to accept this bug (and document it, and
> point out that it isn't Python's fault) than depriving 64-bit users
> of IDLE, or (even worse) of tkinter.
I disagree. There aren't really "64-bit users&qu
Martin v. Löwis added the comment:
Can you please be more specific? What do you mean by "text loaded from a UTF-8
text file"? How specifically did you load it?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.o
Martin v. Löwis added the comment:
> I would consider it to be regression and bugfix that is not inappropriate to
> repair at this point.
I'd also be in favor of fixing it. To reduce the risk of breaking
something, I'd only raise socketmodule to a more recent Windows API.
Of
Martin v. Löwis added the comment:
Why are you saying this isn't an issue in 2.6.5? It behaves exactly the same as
2.7.1.
In any case, this is not a bug. Pass encoding="utf-8-sig" to io.open to have
the signature stripped when the file is read.
--
resolution: -&
Martin v. Löwis added the comment:
Please run
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes
-I/usr/lsd/Linux/include -I. -IInclude -I./Include -I/usr/local/include
-I/usr/local/google/tools/python/release27-maint/Include
-I/usr/local/google/tools/python
Martin v. Löwis added the comment:
'D' denotes a door file. There are several of them in the system; the following
ones (from /var/run) match the time stamp:
Dr--r--r-- 1 daemon daemon 0 Mar 27 2010 kcfd_door
Dr--r--r-- 1 root root 0 Mar 27 2010 name_se
Martin v. Löwis added the comment:
> I am thinking about how to manage OS's with no support for doors.
> Instead of conditionally compile the new STAT, I would rather have
> the function always available, but returning FALSE when the OS
> doesn't support doors. But what
Martin v. Löwis added the comment:
Am 26.01.2011 14:14, schrieb Jesús Cea Avión:
>
> Jesús Cea Avión added the comment:
>
> Antoine, I am not talking about python, I am talking about the UNIX
> standarization process. In particular, how a new flag (for
> filesystems) in an
Martin v. Löwis added the comment:
>> Both cases indicate the users desire to change a specific locale
>> setting and thus - of course - all the changes which that implies!
>> So why should there be a difference?
>
> I don't think it's intenti
Martin v. Löwis added the comment:
What is /usr/lsd/Linux? This seems broken. Please take a look at
/usr/lsd/Linux/include/readline/history.h - it appears to be an empty file.
Make sure you have a working copy of the readline header files installed, and
make sure the build process picks them
Martin v. Löwis added the comment:
> I'm looking at the file right now. history.h is a link to readline.h
Ah, that's wrong. It must be a separate file, entirely different from
readline.h.
--
___
Python tracker
<http://bugs.pytho
Martin v. Löwis added the comment:
> I traced back to where that readline installation came from... It's
> the latest version from ftp.gnu.org + patches.
Did you mean to imply that you have now fixed your installation, or that
you consider
Martin v. Löwis added the comment:
> An clean alternative would be adding LC_* variable parsing code to
> Python to avoid the setlocale() call altogether.
That would be highly non-portable, and repeat the mistakes of
getdefaultlocale.
--
title: 3.x locale does not defaul
Martin v. Löwis added the comment:
> Kristján - will you submit a patch for review? (this issue seems like
> a release blocker to me - but I'll leave it to Georg to decide on
> setting its priority)
I wouldn't say it's a release blocker: I can build Python just fi
Martin v. Löwis added the comment:
See PEP 382: http://www.python.org/dev/peps/pep-0382/
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue11
Martin v. Löwis added the comment:
>> That would be highly non-portable, and repeat the mistakes of
>> getdefaultlocale.
>
> You say that often, but I don't really know why. It's certainly portable
> between various Unix platforms, perhaps not Windows, but then i
Martin v. Löwis added the comment:
More likely, it's my email reader. Sorry about that.
--
___
Python tracker
<http://bugs.python.org/issue6203>
___
___
Martin v. Löwis added the comment:
> Martin, could you shed some light on the state of that PEP?
It's implemented in a branch, and will likely be included in Python 3.3.
--
title: Implementing PEP 382 -> State of PEP 382 or How does distutils2 handle
Martin v. Löwis added the comment:
> Something has gone out of control here. Why do we need to check so many
> alternative locations?
What change do you propose?
--
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
> Martin, what if C posix module (or whoever) would export the symbolic
> constants, and update "stat.py" to use those symbolic constants?.
>
> Do you think that would be an improvement?.
Improvement compared to what? The status quo? Ce
Martin v. Löwis added the comment:
Am 31.01.2011 12:46, schrieb Jesús Cea Avión:
>
> Jesús Cea Avión added the comment:
>
> Martin, I guess "stat" deprecation could require a few years and it
> would be an extra incompatibility burden between 2.7 and 3.x.
>
>
Martin v. Löwis added the comment:
>> Apparently, contributor have the illusion that the values they put
>> into the file are somehow standardized, when they are actually not.
>
> Are there actual bugs with that or is it merely a theoretical concern?
Neither, nor (i.e.
Martin v. Löwis added the comment:
The fast subtype checks cannot be supported in the limited API, as the layout
of type objects is intentionally not exposed. It would be possible to expose a
getter for the type flags; the individual flag values *are* part of the ABI.
I propose the attached
Changes by Martin v. Löwis :
Removed file: http://bugs.python.org/file20644/unisub.diff
___
Python tracker
<http://bugs.python.org/issue11067>
___
___
Python-bugs-list m
1001 - 1100 of 4778 matches
Mail list logo
