Martin v. Löwis added the comment:
> That's another possibility, in which case we would first remove the
> current accept4-calling code in order to fix the buildbot failure.
In Python, the lowest layer facing the operating system always directly
exposes the API as-is, without rei
Martin v. Löwis added the comment:
I think the reference to EasierPythonDebugging is outdated and should be
corrected. Dave Malcolm's work is already part of Python, and available with
every Python build.
--
nosy: +loewis
___
Python tracker
Martin v. Löwis added the comment:
> do we have official python docs on this that I should point to?
I only know of the doc string of libpython.py itself, in Tools/gdb
--
___
Python tracker
<http://bugs.python.org/iss
Martin v. Löwis added the comment:
This is now fixed in r85660. The field associated with a T_BOOL must be of type
char, so I changed the type of inTransaction.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
Martin v. Löwis added the comment:
> I'm the maintainer of a third-party library (gmpy) that would be
> impacted by this and I'm definitely in favor of this change.
Assume Python would make such a change, and users would build released
gmpy versions for such a Python release. W
Martin v. Löwis added the comment:
That appears to be a bug in the NFS server. When you creat("Gr\303\274-Gott"),
what actually comes out of getdents(3) is Gr\303\274-Gott. This only happens
with four bytes of non-ASCII - two UTF-8 bytes are correctly reported. We are
investig
Martin v. Löwis added the comment:
A few comments:
- in complex_hash, why did you drop the cast?
- in object.rst, add versionchanged. It should also explain that Py_hash_t is a
signed integer with the same width as size_t.
Otherwise, it looks fine
Martin v. Löwis added the comment:
> I would have thought that someone who intended a Unicode hostname
> to be looked up in its IDNA form would have encoded it using
> IDNA, rather than an 8-bit encoding - how many C programs would
> transcode the name that way, rather than just
Martin v. Löwis added the comment:
Am 18.10.2010 17:27, schrieb Antoine Pitrou:
>
> Antoine Pitrou added the comment:
>
>> AFAICT, a change from (Py_ssize_t)-1 to (size_t)-1 is less likely to
>> break code than a change from -1L to (Py_ssize_t)-1. (Assuming a
>>
Martin v. Löwis added the comment:
> Wouldn't it be cleaner if x was the same type as hash? Note that
> unsigned long is now wrong. What is needed is "unsigned integer type
> of the same size as Py_hash_t." If Py_hash_t has to stay signed, I
> think we should
Martin v. Löwis added the comment:
> My expectation is that Py_hash_t is the same as Py_ssize_t. The goal
> is to make hashes match the range of possible table sizes.
Please read the patch:
typedef Py_ssize_t Py_hash_t;
--
___
Python t
Martin v. Löwis added the comment:
Am 19.10.2010 06:58, schrieb Raymond Hettinger:
>
> Raymond Hettinger added the
> comment:
>
> Martin, any thoughts on adding a ZFS dependent feature? ISTM this
> Solaris feature hasn't taken hold elsewhere and it may be a mistake
Martin v. Löwis added the comment:
This is a system limitation. The underlying file system supports nanosecond
resolution for the file stamps, and stat(2) also supports reporting them.
However, utimes(2) only supports microsecond resolution when setting them.
Linux supports utimensat(2
Martin v. Löwis added the comment:
> Also, if GetComputerNameEx() only offers a choice of DNS names or
> NetBIOS names, and both are byte-oriented underneath (that was my
> reading of the "Computer Names" page), then presumably there
> shouldn't be a problem with ma
Martin v. Löwis added the comment:
> Sorry, I didn't mean how Windows constructs the result for the
> "A" interface - I was talking about Python code being able to map
> the result from the Unicode interface to the form used in the
> protocol (e.g. DNS). I believe
Martin v. Löwis added the comment:
It possible to script MSI, so that one could write a tool that manages all MSI
files that have the multi-version feature, and add and remove them to Python
installation in batches.
Alternatively, it would also be possible to integrate this into the Python
Martin v. Löwis added the comment:
Let me guess: It's GetFinalPathNameByHandle that is failing. Put some debug
output right after the call to verify.
Why is this critical? Not being able to stat VirtualBox folders doesn't sound
that critical to me.
--
nos
Martin v. Löwis added the comment:
These changes also look all reasonable to me.
--
___
Python tracker
<http://bugs.python.org/issue9778>
___
___
Python-bug
Martin v. Löwis added the comment:
I think something like this is worth adding. I'd like to see two changes
implemented:
- GetLastError should be checked for the "not implemented or some such" error
that you got, and the fallback only performed if its this error
- a comment
New submission from Martin v. Löwis :
_sre.c:match_start currently uses Py_BuildValue("i") to return the start index,
which itself is of type Py_ssize_t. This will get truncated on x64 Windows if
the start is > 2**31. PyInt_FromSsize_t should be used instead. Other usages of
New submission from Martin v. Löwis :
When extracting, the time stamps of directories are modified twice: once when
creating the directories, and then once in reverse order when done.
The first utimes call is redundant; it also causes issues with a buggy NFS
server, see
http://www.python.org
Martin v. Löwis added the comment:
I recommend to declare this issue closed, and keep it closed unless somebody
wants to propose to revert the change (widening the hash type) completely. Any
remaining issues that people want to attribute to this change (correctly or
incorrectly) should be
Martin v. Löwis added the comment:
This is not a bug, but intentional.
a is a Unicode string; it does not have an encoding internally (not GBK, not
UTF-8). Then, the string being exec'ed also becomes a Unicode string. exec'ing
Unicode strings is confusing; try to avoid this. The se
Martin v. Löwis added the comment:
Oops, I meant
a = "大"
--
___
Python tracker
<http://bugs.python.org/issue10187>
___
___
Python-bugs-list mailing
Martin v. Löwis added the comment:
> but why it is forced to encoded to utf-8,
> I think it should be encoded by the locale related encodings,not always utf-8,
> for example,in GBK locale,it should use GBK to encode the unicode
> object,right?
Wrong. Exec'ing Unicode
Martin v. Löwis added the comment:
> oh,you mentioned the PEP 263
> but I already set a header like this,you can see the attached test.py
> #coding=GBK
You have that in test.py, but not in the string you are giving to exec.
This is really a separate source code.
So you could hav
Martin v. Löwis added the comment:
I see. Here is an updated version that makes the touch operations optional.
--
assignee: ghaering -> lars.gustaebel
nosy: -ghaering
Added file: http://bugs.python.org/file19354/tarfile2.diff
___
Python trac
Martin v. Löwis added the comment:
As indicated in msg59954, it works fine on 3.x, so removing these versions.
--
versions: -Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue1542
Martin v. Löwis added the comment:
For 2.7, I don't think it's possible to really fix this. I see the following
options:
A. current status. Byte strings are compiled correctly, Unicode strings are not.
B. compile source as a Unicode string, as proposed in msg85886. Unicode st
Martin v. Löwis added the comment:
The patch lacks a documentation change. Otherwise, it looks fine.
--
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
> If you ascertain yourself that the test works under ZFS then I think it
> is enough. Of course, it would be better if a buildbot ran that test,
> but we can live without it (IMHO).
I agree. I trust that the patch is correct, and we really don'
Martin v. Löwis added the comment:
I don't quite understand the problem. How exactly do you manage to lose data?
The ftp server should send a 226 status code to indicate success over the
control connection, and presumably it will do so only after receiving the
proper TCP shutdown fro
Martin v. Löwis added the comment:
> All fixed now. :)
Does that refer to msg119743? Please provide this module
as a patch for branches/py3k, otherwise it's difficult to see
what exactly you are contributing.
Also, please provide Doc/library/
Martin v. Löwis added the comment:
> Proper behavior for ftplib when sending is to send all desired data,
> then call "sock.shutdown(socket.SHUT_RDWR)". This indicates that no
> more data will be sent, and blocks until the receiver has
> acknowledged all their data.
I t
Martin v. Löwis added the comment:
I'd like to see this patch reverted. I don't think it is useful.
1. encoding with NFD should not be necessary, as the system will do that,
anyway.
2. decoding with NFC is incompatible with previous Python releases, and I can't
see why NFC
Martin v. Löwis added the comment:
Why is the second parameter optional?
--
___
Python tracker
<http://bugs.python.org/issue9981>
___
___
Python-bugs-list mailin
Martin v. Löwis added the comment:
> Yes, but not exactly... Mac OS X NFD normalization is a little bit
> different than Python's normalization: see msg105669 and
> http://developer.apple.com/library/mac/#qa/qa2001/qa1173.html
I see. This is one more reason not to convert string
Martin v. Löwis added the comment:
Did you know break building the 3.x documentation with Python 2? If so, please
revert that change.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
This is a duplicate of http://bugs.python.org/issue10184
--
___
Python tracker
<http://bugs.python.org/issue10230>
___
___
Martin v. Löwis added the comment:
I just did an experiment on Windows 7. I used SetComputerNameEx to set the
NetBIOS name (4) to "e2718", and the DNS name (5) to "π3141"; then I rebooted.
This is on a system with windows-1252 as its ANSI code page (i.e.
u"π"==u
Martin v. Löwis added the comment:
r85934 now uses GetComputerNameExW on Windows.
--
___
Python tracker
<http://bugs.python.org/issue9377>
___
___
Python-bug
Martin v. Löwis added the comment:
The Solaris case then is already supported, with no change required: if Solaris
bans non-ASCII in the network configuration (or, rather, recommends to use
IDNA), then this will work fine with the current code.
The Josefsson AI_IDN flag is irrelevant to
Martin v. Löwis added the comment:
> The DNS name of the Windows machine is the combination of the DNS host
> name and the DNS domain that you setup on the machine. I think the
> misunderstanding is that you assume this combination will
> somehow appear as known DNS name of the mach
Martin v. Löwis added the comment:
> Wouldn't it be better to also attempt to decode the name using IDNA
> in case the name starts with the IDNA prefix ?
Perhaps better - but incompatible. I don't see a way to have the
resolver functions automatically decode IDNA, without pote
Martin v. Löwis added the comment:
> Python 2.6, for example, does ship a shared library.
That is not really the case. Python 2.6 ships in source form. It
builds with a libpython shared library only if you configure
with --enable-shared.
> In particular it is NOT acceptable for any ext
Martin v. Löwis added the comment:
Why do you say that the link is broken?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10244>
___
___
Pytho
Martin v. Löwis added the comment:
The link works fine for me right now, and the starship is alive and well.
--
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
The change from issue1054943 is indeed bogus. As written, the code will happily
run over starters, even though a blocked start means that subsequent characters
can't possibly be combinable. That way, the code manages to combine, in
'Li\u030dt-s\u
Martin v. Löwis added the comment:
make_buildinfo is always built and run as a 32-bit binary, so I think this part
of the change is fine (though unrelated to the objective of the change).
I think the patch is fine.
--
___
Python tracker
<h
Martin v. Löwis added the comment:
>> It's unfortunate that the patch had been backported to 2.6.6; we can't fix
>> it there anymore.
>
> Why not ? It looks a lot like a security fix.
Indeed, you could argue that. It's up to
Martin v. Löwis added the comment:
After starting to review the code, I'm becoming skeptical whether this is the
right approach. This does way to much action in C, and thus becomes complicated
but also limited.
An alternative approach would be to just expose lzma_code to Python, and
Martin v. Löwis added the comment:
> LZMAFile, LZMACompressor & LZMADecompressor are all inspired by and
> written to be as similar to bz2's for easier use & maintenance. I
> must admit that I haven't really put much thought into alternate ways
> to implement the
Martin v. Löwis added the comment:
> I guess I could rewrite it following these suggestions, but I probably won't
> be able to
> finish it in time for 3.2 beta.
The more I think about it, the more I feel like -1 about this code as
long as it uses stdio, and does buffering. W
Martin v. Löwis added the comment:
I think this approach (of file19364) is reasonable.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue775
Martin v. Löwis added the comment:
I find your approach fine; there isn't a need (IMO) to have the underlying
functions change.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
This is now committed as r86102. I opted to call the parameter set_attrs.
--
___
Python tracker
<http://bugs.python.org/issue10
Changes by Martin v. Löwis :
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10184>
___
___
Python-bugs-
Changes by Martin v. Löwis :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue10292>
___
___
Python-
Martin v. Löwis added the comment:
LGTM.
--
___
Python tracker
<http://bugs.python.org/issue10295>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Martin v. Löwis :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10243>
___
___
Python-bugs-
Martin v. Löwis added the comment:
I propose a different solution: On Windows, instead of calling write(), we call
WriteFile directly. We try to faithfully follow the CRT implementation as much
as possible, knowing that what we write to actually is a binary file (in
particular, the file
Martin v. Löwis added the comment:
> If I'm not mistaken, WriteFile takes the length as a DWORD, which is
> still 32 bits under Win64.
Oops, ignore me, then... I agree that clamping is fine, assuming the
buffering layer takes that i
Changes by Martin v. Löwis :
Removed file: http://bugs.python.org/file19498/unnamed
___
Python tracker
<http://bugs.python.org/issue10243>
___
___
Python-bugs-list mailin
Martin v. Löwis added the comment:
> On a second thought... is there another example where a *blocking* stream
> does not write all the data without raising an exception?
Why do you think this would be somehow an example for a blocking stream
that does not write all data without rais
Martin v. Löwis added the comment:
Am 04.11.2010 22:28, schrieb Amaury Forgeot d'Arc:
>
> Amaury Forgeot d'Arc added the comment:
>
>> Why do you think this would be somehow an example for a blocking stream
>> that does not write all data without raising an
Martin v. Löwis added the comment:
LGTM.
--
___
Python tracker
<http://bugs.python.org/issue10341>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
In this case, backporting is ok (but IMO not needed).
--
___
Python tracker
<http://bugs.python.org/issue10341>
___
___
Pytho
Martin v. Löwis added the comment:
As for back-porting: I'm not sure this is a bug in 2.7. It just doesn't support
Unicode filenames, but that's not (inherently) a bug. In 3.1, I can agree that
it's a bug - but we need to preserve the bytes support for compatibility.
F
Martin v. Löwis added the comment:
> Is this also applied to *all* ANSI Win32 API
> in other sources?
No. I think there are backwards compatibility concerns in some of the
APIs, so this must be discussed on python-dev.
--
___
Python tracker
Martin v. Löwis added the comment:
I'm able to, but I may not find time. Ask on python-dev; if you feel you need
to push this, offer to review issues in return.
--
___
Python tracker
<http://bugs.python.org/iss
Martin v. Löwis added the comment:
Out of curiosity: why are you building with --with-cxx_main?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
IIUC, Manfred's pythonInstallLog.zip is now from a successful installation, so
it is unfortunately of little help. We really would need a log of a failed
installation.
--
___
Python tracker
Changes by Martin v. Löwis :
--
versions: -Python 2.5, Python 2.6
___
Python tracker
<http://bugs.python.org/issue10363>
___
___
Python-bugs-list mailin
Martin v. Löwis added the comment:
It should certainly work around the problem you are reporting.
--
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
I wasn't really discussing (yet) whether this is a bug. I was just trying to
find out what specifically made you use this configure option. The need for it
should have gone away ten years ago or so.
--
___
P
Martin v. Löwis added the comment:
And I still don't understand the rationale for this request. Can you please
post an example Python module that has this markup you are asking for, so I can
show you how to achieve what you want without the m
Martin v. Löwis added the comment:
I don't understand the example, either. If I run 2to3 on it, I get, as the only
change
if sys.version_info[0] < 3: # Python 2
-from urllib import quote, unquote
-from urlparse import urlparse, urlunparse
-
Martin v. Löwis added the comment:
This goes back to issue400788 and
http://mail.python.org/pipermail/python-dev/2000-July/005897.html
http://mail.python.org/pipermail/python-dev/2000-August/008385.html
Skip changed it to do something meaningful (more than ten years ago), Mark
Hammond
Martin v. Löwis added the comment:
The database had been updated already in r85371. Backporting this change to
maintenance branches is not allowed by policy.
--
nosy: +loewis
resolution: -> fixed
status: open -> closed
___
Python tracker
Martin v. Löwis added the comment:
> For example, starting on line 152 we have,
> # Py3K
> #return unicode(self.compile())
> # Py2K
> return unicode(self.compile()).\
> encode('ascii', 'backslashreplace&
Martin v. Löwis added the comment:
> Consider here:
> http://www.sqlalchemy.org/trac/browser/lib/sqlalchemy/engine/base.py?rev=6884:b181f1e53603#L1329
> the py3k code uses the "raise ... from" syntax which isn't legal in Python 2.
In this case,
Martin v. Löwis added the comment:
Python has a policy of exposing low-level APIs as-is, i.e. the way the
operating system implements them. gethostbyname is an old BSD socket API
function that is limited to IPv4, and Python exposes it as such.
If you want another convenience function, I
Martin v. Löwis added the comment:
Can anybody reproduce this?
--
___
Python tracker
<http://bugs.python.org/issue11288>
___
___
Python-bugs-list mailin
Martin v. Löwis added the comment:
Matthew: please run "python -v", and attach any output it makes to this report.
--
___
Python tracker
<http://bugs.python.o
Martin v. Löwis added the comment:
Ok, closing this as "invalid" then - it's not a bug in the installer, but a
misconfiguration of the local system. Thanks to Bartosz for the analysis!
--
resolution: -> invalid
status: open -> closed
_
Martin v. Löwis added the comment:
Just for the record: at the moment, Python's source code isn't maintained in
Mercurial at all, but in subversion. Therefore, there are no official repos -
it's no surprise you didn't find any documentation what they were.
Martin v. Löwis added the comment:
Having the soname be libpython3 is the whole point of the library, it serves no
other reason.
It is intentional that there are file collisions with that file, and either the
local admin or the distributor must make an explicit choice which libpython3
Martin v. Löwis added the comment:
> The -hl -> -h part seems correct though.
Indeed.
--
___
Python tracker
<http://bugs.python.org/issue11347>
___
___
Martin v. Löwis added the comment:
> "Having the soname be libpython3 is the whole point of the library":
> I think that the point of this library is "libpython3.so" filename,
> not soname. Everything should still work if libpython3.so had no
> soname at all.
Martin v. Löwis added the comment:
Éric, what forward porting exactly needs to be done?
--
___
Python tracker
<http://bugs.python.org/issue9313>
___
___
Pytho
Martin v. Löwis added the comment:
-1. The description is factually correct - minidom *does* have a lower
footprint than other Python DOM implementations (such as 4DOM).
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue11
Martin v. Löwis added the comment:
> What about this phrasing then:
>
> """ MiniDOM has a smaller memory footprint than some of the other DOM
> compliant implementations for Python (such as 4DOM), but uses about
> 10x more memory than the faster and simpler x
Martin v. Löwis added the comment:
> It's the tree based API most python users are parsing XML with,
> though. So I do not agree that it's comparing apples and oranges, not
> at all. It's comparing tree based XML libraries, only one of which is
> worth being called
Martin v. Löwis added the comment:
These directories aren't missing - they are simply not included. Each such
inclusion should be preceded by an explicit request (preferably with some
rationale).
Including the demo directory is fine wi
Martin v. Löwis added the comment:
> Big dirs are really slow to read at once.
Do you a proof for that claim? How big, and how really slow?
> for i in os.listdir()
> use(i)
Also, how long does use(i) take, and what reduction (in percent)
can you gain from listdir iterating?
Changes by Martin v. Löwis :
Added file: http://bugs.python.org/file21018/a.diff
___
Python tracker
<http://bugs.python.org/issue2771>
___
___
Python-bugs-list mailin
Changes by Martin v. Löwis :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue2771>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Martin v. Löwis :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue2771>
___
___
Python-bugs-list mailing list
Unsubscri
Martin v. Löwis added the comment:
Exporting the SizeT functions on all systems is fine. It's not true that they
aren't declared: they are declared in modsupport.h if PY_SSIZE_T_CLEAN is
defined. Else they are not declared.
The patch looks fine to. I agree that mere cleanup sho
Martin v. Löwis added the comment:
-1. Changing the Mercurial tree will make it more difficult to maintain the
subversion tree, which will be the tree from which future 2.5 releases will be
made.
So if anything is done with this issue, please defer that after September 2011.
--
nosy
701 - 800 of 4778 matches
Mail list logo
