Martin v. Löwis added the comment:
> maybe it'd be better to add support for libarchive
That wouldn't be better. We want the C dependency as small
and low-level as possible, so that the dependency is small
and the functionality flexible to implement stuff in Python
Martin v. Löwis added the comment:
> "posixcap" sounds ok to me.
Bike-sheddingly, it bothers me that these functions are actually
*not* defined by POSIX, but have been withdrawn before becoming
standard. So I'd rather call it linuxcap. Using _linuxcap, and
exposing them from
Martin v. Löwis added the comment:
In case it isn't clear from the discussion in issue8792: I'd be in favor of
supporting extensions as long as their usage is an opt-in feature. The current
nil support is already an opt-in feature. If alternative spellings of nil need
to be sup
Martin v. Löwis added the comment:
> An addition: It was reported in #10425 that None values are
> incorrectly serialized as , instead of just
> , or maybe <{namespace prefix for extensions defined by
> Apache}:nil/>.
This is not incorrect, but follows the specification of th
Martin v. Löwis added the comment:
db: there *is* no "sane system ca path", or Python would have done that long
ago. On Windows, it may be possible to drop OpenSSL, and use the system
certificate store. However, that would be a major rewrite, and it may not be
possible to provide
Martin v. Löwis added the comment:
>> The best that could be done is to provide a configuration option (e.g.
>> global variable) that should be treated as a default value, and then
>> leave it to people distributing Python to fill out this variable in a
>> sensible way
Martin v. Löwis added the comment:
>> This may not be satisfying to users. For example, our Windows
>> distribution doesn't ship with any certicates (AFAIK); I have no
>> clue where exactly OpenSSL would be looking for them, either.
>> People worried about this prob
Changes by Martin v. Löwis :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10070>
___
___
Python-bugs-
Martin v. Löwis added the comment:
-1. That's a new feature.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10458>
___
___
Python-bugs-l
Martin v. Löwis added the comment:
Marc-Andre: Many of the characters you refer actually do have names assigned,
even if the names don't appear in the Unicode character database. Instead, they
are specified in section 4.8 of the Unicode standard, and unicodedata.c already
implements tha
Martin v. Löwis added the comment:
Kotan: please perform the following procedure:
1. Open pcbuild.sln
2. In the pythoncore project, open errnomodule.c
3. find the reference to EWOULDBLOCK and WSAEWOULDBLOCK
4. for each one, "go to definition"
5. report here what header files Vis
Martin v. Löwis added the comment:
OK, so what's the path to errno.h? In the errno.h included in my copy of VS
2010, the errno values only go up to 42 (80 if you count STRUNCATE), and
EWOULDBLOCK is not defined in this header file.
--
___
P
Martin v. Löwis added the comment:
Oops, I was confused. My copy is VS 2008, of course. So that's another
incompatible change in VS 2010. Tcl, Ruby, and curl are ahead of us, here:
http://redmine.ruby-lang.org/issues/show/3092
http://sourceforge.net/tracker/index.php?func=detail&ai
Martin v. Löwis added the comment:
> Only in the "system_error" file.
> (http://msdn.microsoft.com/en-us/library/ee372194.aspx)
> Seem to be a C++0X standard header file.
(I assume you have actually scanned the crt\src folder as well)
Then it's indeed
Martin v. Löwis added the comment:
The changes look fine to me.
--
___
Python tracker
<http://bugs.python.org/issue6007>
___
___
Python-bugs-list mailin
Martin v. Löwis added the comment:
Antoine,
I was proposing that the Windows installation should have a folder where
OpenSSL looks for certificates, and that users put trusted certificates into
that folder. These should be the ones that set_default_verify_paths will use.
Unfortunately, I
Martin v. Löwis added the comment:
I think it's fairly clear what should be considered executable in this context:
anything that subprocess.Popen is able to launch (because if is_executable
succeeds, this is what will happen to the file). This excludes word files, and
also excludes
Martin v. Löwis added the comment:
> So for python3 is it possible to make attempting to use capath(some
> common ones OR the openssl location capath if this is ok for use) the
> default(with failure to find a valid capath result in an exception
> being raised) ?
The default? That
Martin v. Löwis added the comment:
> The answer depends on what the socket module is trying to do. Is the
> goal simply to provide a pythonic thin wrapper over the underlying OS
> interfaces without altering their semantics, or to provide a
> completely homogeneous abstra
Martin v. Löwis added the comment:
This is a duplicate of issue1284316
--
resolution: -> duplicate
status: open -> closed
superseder: -> Win32: Security problem with default installation directory
___
Python tracker
<http://bug
Martin v. Löwis added the comment:
> Here is the issue (put plainly):
Unfortunately, I still don't understand it. I go through your plain
elaboration below.
> Python sockets support a notion of timeout (note this notion is not
> reflected in the OS socket API).
Correct.
>
Martin v. Löwis added the comment:
> We are talking about the timeout feature, which is a Python feature, not
> a BSD (or Linux) sockets feature. It should work properly, even if that
> means adding some boilerplate around system calls.
I agree that the semantics of the socket timeo
Martin v. Löwis added the comment:
Here is a patch that changes SSLContext into a context manager, allowing to
write code like
with ssl.SSLContext(ssl.PROTOCOL_SSLv23):
ssl.SSLContext.current().set_default_verify_path()
res = urllib.request.urlopen("
Martin v. Löwis added the comment:
> Well, I don't think setting a timeout on a listening socket and then
> expecting the socket received through accept() to be non-blocking (but
> only on BSD) is a legitimate application.
Right. But setting the server socket to nonblocking, and
Martin v. Löwis added the comment:
> The Python implementation sets timeout=None (which implies that the
> underlying socket is blocking).
No, it doesn't. A socket may be non-blocking without having a timeout;
that's the socket API (on all systems, not just BSD).
> The pro
Martin v. Löwis added the comment:
> However, I hope we can all agree that having the Python socket object
> in a different blocking / non-blocking state than the OS socket
> descriptor is wrong. This is what needs to be fixed.
Ok, now I see where your misunderstanding is: you sim
Martin v. Löwis added the comment:
> I got into this by starting with Issue7322, which reports a scenario
> where data is lost using makefile(). The docs for makefile() say,
> "The socket must be in blocking mode (it can not have a timeout)".
> So, we've got pu
Martin v. Löwis added the comment:
> Well, unless someone explains convincingly how the current behaviour is
> desireable (rather than misleading and useless), I really think this is
> a bug that should be fix (then we can also discuss what the fix should
> exactly be).
So please p
Martin v. Löwis added the comment:
> Set blocking or non-blocking mode of the socket: if flag is 0, the
> socket is set to non-blocking, else to blocking mode.
>
> This seems to imply that timeout = None -> blocking.
I see. So gettimeout() should really make a system cal
Martin v. Löwis added the comment:
> Martin, that is an interesting viewpoint, and one I considered, but
> didn't state, because it seems much too restrictive. Most CGI
> programs are written in scripting languages, not compiled to .exe.
> So it seems the solution should allow
Martin v. Löwis added the comment:
For 3.2, this now fixed in r86681.
--
___
Python tracker
<http://bugs.python.org/issue10459>
___
___
Python-bugs-list mailin
Martin v. Löwis added the comment:
The patch for 3.1 is r86685. The patch for 2.7 is r86686.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
> Your suggestion of making CGIHTTPRequestHandler easier to subclass is
> certainly a good one, and is almost imperative to implement to fix
> this bug in a useful manner without implementing an insufficient set
> of Windows extensions (f
Martin v. Löwis added the comment:
Kristjan, can you take a look?
--
assignee: -> krisvale
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issu
Martin v. Löwis added the comment:
What's the objective of this patch? I.e. what precisely is it supposed to
achieve?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
> I doubt this fix will be enough to fix compilation with mingw32.
So somebody will have to verify independently. If it fails to fix
the bug completely, it's out of scope for 2.7 (it's out of scope for
2.7.1 IMO either way).
> With thi
Martin v. Löwis added the comment:
> Please give me some starting point by applying these patches. I don't
> care if it's for 2.7.1 or 2.7.2. I'll try hard to get *everything*
> fixed, but we have to start somewhere.
I'm skeptical that we should do that with 2.7, t
Martin v. Löwis added the comment:
> Why exactly are you skeptical? Because it doesn't fix everything in
> one go? The other changes are also minimal (I'm not even sure if it
> requires more source changes, maybe I have just to get my #defines
> right). If you prefer to se
Martin v. Löwis added the comment:
What file specifically did you download?
--
___
Python tracker
<http://bugs.python.org/issue10500>
___
___
Python-bugs-list m
Martin v. Löwis added the comment:
> Martin, could you check it? Thanks!.
Not in the foreseeable future, sorry.
--
___
Python tracker
<http://bugs.python.org/issu
Changes by Martin v. Löwis :
--
assignee: loewis ->
___
Python tracker
<http://bugs.python.org/issue10493>
___
___
Python-bugs-list mailing list
Unsubscri
Martin v. Löwis added the comment:
> The fix was ported from trunk (2.7) to py3k branch, but it was not
> applied to 3.1 branch, though. I don't know why, but seems to be an
> oversight.
No, it was deliberate: it was not backported all, neither to 3.1, nor
to 2.6. I was concerned
Martin v. Löwis added the comment:
> While I realize Python extension modules are pretty much the norm in
> CPython, it'd be pretty cool if xz support could be written overtop
> of ctypes. ctypes seems to be emerging as the way of doing FFI
> across different python implement
Martin v. Löwis added the comment:
> According to the instructions received at #python-dev, I'm posting a
> new patch with the same fixes made on the most recent SVN sources
> (py3k). Actually the new patch does not include the fixes made on the
> GetFileAttributesEx wrapper
Martin v. Löwis added the comment:
Thanks for the confirmations; closing this report as invalid.
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
In 2.6, there was a manually maintained list, probably dating back to before
Unicode 4.0. Python uses the following criterion for determining white space
characters:
/* Returns 1 for Unicode characters having the bidirectional type
'WS', &#x
Martin v. Löwis added the comment:
> It's not just this character. isspace() is also False for \u200c and \u200d
> (from the same category). and \u2060, \u2800 and \ufeff
What reason do you have to believe that they should be classified as
whitespace, other than the web page you
Martin v. Löwis added the comment:
> I'm not quoting anything. Thank you very much.
Oops, sorry - I confused you with the OP.
--
___
Python tracker
<http://bugs.python.org
Martin v. Löwis added the comment:
>> In 2.6, there was a manually maintained list, probably dating back to before
>> Unicode 4.0.
>
> That's not quite correct: Python 1.6.x - 2.5.x used tables for the
> PyUnicode_ISSPACE() function that were created from the Unico
Martin v. Löwis added the comment:
/pdb:None initially did *not* mean "no debug information", but "no pdb file",
see
http://msdn.microsoft.com/en-us/library/aa278542(VS.60).aspx
Debug information would be embedded to the DLL.
Later versions of the VS documentation fail
Martin v. Löwis added the comment:
I'd like a native speaker (of English) to confirm this request.
The report is about Tools/msi/msi.py.
--
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
> These changes don't affect gencodec.py, but it may be inconvenient to
> run makeunicodedata.py and gencodec.py using different versions of
> Python.
As MAL explains: these are completely unrelated, independent tools,
and gencodec isn't
Martin v. Löwis added the comment:
> I am adding #10552 as a dependency because I think we should fix
> unicode data generation in 3.x before adding new features to the
> scripts.
>
> I am also not sure whether this is a bug or a feature request.
> Martin?
I fail to se
Martin v. Löwis added the comment:
This is not a bug, see
http://www.unicode.org/reports/tr44/#Numeric_Value
Characters have a Numeric_Type property of either null, Decimal, Digit, or
Numeric. For non-Unihan characters, this is denoted by filling out either no
column, or (6,7,and 8), or (7
Martin v. Löwis added the comment:
Ah ok, then removing the option sounds fine to me (not for 2.6, though).
--
versions: -Python 2.6
___
Python tracker
<http://bugs.python.org/issue4
Changes by Martin v. Löwis :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10583>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
> Thanks for the explanation. I wrongly assumed that "make all" is the
> way to regenerate both unicodedata and the encodings and that the two
> are interdependent.
Ah. I never use the Makefile.
--
___
Changes by Martin v. Löwis :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10575>
___
___
Python-bugs-
Martin v. Löwis added the comment:
What is the issue that you are reporting? that the status quo should be
documented, or that isalpha is wrong? These are independent - don't mix them.
--
nosy: +loewis
___
Python tracker
<http://bugs.py
Martin v. Löwis added the comment:
The key requirement to consider for in POSIX compatible mode is, well, POSIX
compatibility, which is defined in
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
Martin v. Löwis added the comment:
This is not a bug. You can't expect that using an arbitrary codec (such as
UTF-8) with the surrogateescape code, and expect to be able that opening the
file will be able to produce the correct filename. This won't work on Unix, in
the general ca
Martin v. Löwis added the comment:
No, there is no indication in the zipfile that it deviates from the spec. That
doesn't stop people from creating such zipfiles, anyway; many zip tools ignore
the spec and use instead CP_ACP (which, of course, will then get misinterpreted
if extracted
Martin v. Löwis added the comment:
When the patch is applied, what's the resulting status of mingw compilation?
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
Am 04.12.2010 09:32, schrieb Johann Hanne:
>
> Johann Hanne added the comment:
>
>> When the patch is applied, what's the resulting status of mingw compilation?
>
> It compiles all C files which I require. Not sure if this is re
Martin v. Löwis added the comment:
Thanks for the report. Fixed in r87042
--
nosy: +loewis
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
> Sure - it actually builds a python.exe which is fully working for me. If you
> need a proof, please let me know, I have no problem uploading it somewhere...
>
> Is there a reason you are so sceptical? After all, Python for Linux is also
> u
Martin v. Löwis added the comment:
> After all, the Win32 platform is not that uncommon. I know, MinGW
> could be seen as a different platform, but I never encountered a
> situation where I required anything but the exe file (no special
> MinGW DLL or something like that).
Traditio
Martin v. Löwis added the comment:
> IMO this is a use case for the new "soabi" tag...
Unfortunately not: these tags are not supported on Windows.
--
___
Python tracker
<http://bugs.pytho
Martin v. Löwis added the comment:
As per
http://mail.python.org/pipermail/python-dev/2010-December/106374.html
I think this checkin should be reverted, as it's breaking the language
moratorium.
--
___
Python tracker
<http://bugs.py
Martin v. Löwis added the comment:
More formally: it's unspecified. I'd like to propose this general principle: If
you pass a relative path to some library that gets stored in the library, it's
unspecified whether the cwd is consider at the point of passing the path or at
the
Martin v. Löwis added the comment:
All README files are automatically packages, and so is this one.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Martin v. Löwis added the comment:
This is not a bug in Python, but in the Microsoft CRT. Rewriting Python to not
use the CRT anymore for this is non-trivial, in particular as the semantics of
environment variables (TZ) needs to be considered.
--
nosy: +loewis
Martin v. Löwis added the comment:
> If when it caught SIGCHLD python pushed an event onto its internal
> event loop to execute the handler, I think that would make sure it's
> deferred until after the assignment.
This is not a reasonable request. How long would you want to
Martin v. Löwis added the comment:
> Very sorry, I created the bug calling CloseHandle twice
> in Modules/posixmodule.c. I think this should be fixed
> before beta1 released. Can I commit it?
Even if you commit it now, it won't get into beta1: the
Windows binaries for that are
Martin v. Löwis added the comment:
The second CloseHandle call will fail. As we are not checking the CloseHandle
result, this has no further consequences, AFAICT.
--
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
quick followup: there is a chance that this closes the wrong file due to race
conditions, in case a different thread opens a file in-between that gets the
same handle. Due to the GIL, this is unlikely
Martin v. Löwis added the comment:
Kristjan, can you take a look?
--
nosy: +krisvale
___
Python tracker
<http://bugs.python.org/issue8194>
___
___
Python-bug
Martin v. Löwis added the comment:
What needs reinitialization is not the time module, but the CRT. This is not
possible without starting a completely new process.
--
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
> As for the reproducibility issue: The configure/Makefile system
> coming with Python simply doesn't support creating a Windows build. I
> hope it's clear that the patch is NOT about creating a Windows
> installer. If this is a requ
Changes by Martin v. Löwis :
--
Removed message: http://bugs.python.org/msg54865
___
Python tracker
<http://bugs.python.org/issue1528154>
___
___
Python-bug
Martin v. Löwis added the comment:
> - Embedding Python by just compiling/linking all the .c files in
> seems to be a major feature to me; so fixing compilation is useful
> for its own
If that's the objective of the patch, I'm -1 on it.
> - The win32 build system has
Martin v. Löwis added the comment:
Please, one issue per report and checkin, and no work-in-progress on the
tracker. The issue of factually correcting claims about the unicodedata module
and elaborations on how it works are unrelated issues.
--
nosy: +loewis
Martin v. Löwis added the comment:
There is no readline support on Windows at all, so I don't think the Windows
installer can be affected. I'm uncertain what the proposed change to Python is
at this point, though.
--
___
Python trac
Martin v. Löwis added the comment:
> Why? I thought "release early, release often" was a good thing.
Create a branch for that, or post an issue on Rietveld. W-I-P IMO
confuses people reviewing the patches, running into the same ones
over-and-over again, only to find out every t
Martin v. Löwis added the comment:
Can you please formulate that is a test case? Use this structure:
1. do this
2. this happens
3. this should happen instead
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
The source is correct. Fixed in r87171.
--
nosy: +loewis
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
It's not an incompatible change, but I added the versionchanged anyway in
r87173.
--
___
Python tracker
<http://bugs.python.org/is
Martin v. Löwis added the comment:
> It's source level incompatible - my extension modules compiled fine with
> v3.2a but failed with v3.2b1.
That's because you are using C++, right? In C, there shouldn't be any
problems.
--
_
Martin v. Löwis added the comment:
It's clearly not a bug: the documented grammar matches the implemented grammar.
Asking for more abstract consistency is a feature request. This also clearly
falls under the PEP 3003 moratorium.
--
nosy: +loewis
type: behavior -> feature
Martin v. Löwis added the comment:
Retargetting, as this falls under the moratorium, and also because 3.2b1 has
been released.
--
nosy: +loewis
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue9
Martin v. Löwis added the comment:
The problem is different: there is a stray " in pythoncore"\getbuildinfo.o.
Kristjan, this is your change: can you take a look?
--
nosy: +krisvale, loewis
___
Python tracker
<http://bugs.python.o
Martin v. Löwis added the comment:
> So, Martin, are you then arguing that this should in fact be
> considered a bug in ZipFile? The documentation for the constructor
> says "Open a ZIP file, where file can be either a path to a file (a
> string) or a file-like object."
Martin v. Löwis added the comment:
Ok, so closing as rejected.
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Martin v. Löwis added the comment:
In #10682, several committers indicated that they would prefer not to change
this. So I'm closing this as rejected. Per convention, it would probably
require a PEP to modify Python in this aspect (as there is no clear consensus).
--
resol
Martin v. Löwis added the comment:
> Are you going to reject say issue2636 on this basis? :-) Has *any*
> patch ever been rejected as incomplete?
I certainly did close patches for that reason. Before that, I keep
asking people not to post W-I-P. As for issue2636, I have been really
t
Martin v. Löwis added the comment:
I stand by my evaluation: there is clearly no consensus about this change, so
it certainly requires more discussion, potentially leading to proponents being
asked to write a PEP.
--
___
Python tracker
<h
Martin v. Löwis added the comment:
2to3 patches should currently be made against and checked into the sandbox.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue10
Martin v. Löwis added the comment:
The question really is whether we want or want not to support RFC 1945 (i.e
HTTP/1.0). If we want to support it, we also must comply to section 3.1, which
says
The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the
Martin v. Löwis added the comment:
I'm rejecting this as "won't fix". Users having the underlying problem (i.e.
need more than 2GB of heap) really should switch to a 64-bit installation. The
risk of something breaking is just not worth it.
That testing showed no issues
Martin v. Löwis added the comment:
Am 17.12.2010 01:56, schrieb STINNER Victor:
>
> STINNER Victor added the comment:
>
> "Ooops", sorry. I just applied the patch suggested by Marc-Andre
> Lemburg in msg22885 (#1054943). As the patch worked for the examples
> giv
901 - 1000 of 4778 matches
Mail list logo
