[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child
New submission from Luke : I have found that when using multiprocessing.Connection objects to pass data between two processes, closing one end of the pipe is not properly communicated to the other end. My expectation was that when calling recv() on the remote end, it should raise EOFError if the pipe has been closed. Instead, the remote recv() blocks indefinitely. This behavior exists on Linux and Cygwin, but NOT on native Windows. Example: import multiprocessing as m def fn(pipe): print "recv:", pipe.recv() print "recv:", pipe.recv() if __name__ == '__main__': p1, p2 = m.Pipe() pr = m.Process(target=fn, args=(p2,)) pr.start() p1.send(1) p1.close() ## should generate EOFError in remote process -- messages: 139754 nosy: lcampagn priority: normal severity: normal status: open title: multiprocessing.Connection does not communicate pipe closure between parent and child type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child
Luke added the comment: That's interesting, thanks for your response. It is also a bit awkward.. Might I recommend adding a note to the documentation? It is not really intuitive that each child should need to close the end of the pipe it isn't using (especially since it is possible to create a child that has no explicit access to that end of the pipe, even though it has inherited the file descriptor). 2011/7/4 Charles-François Natali > > Charles-François Natali added the comment: > > That's because the other end of the pipe (p1) is open in the child process > (FDs are inherited on fork()). > Just add > p1.close() > > at the beginning of fn() and you'll get EOF. > Closing as invalid. > > -- > nosy: +neologix > resolution: -> invalid > stage: -> committed/rejected > status: open -> closed > > ___ > Python tracker > <http://bugs.python.org/issue12488> > ___ > -- Added file: http://bugs.python.org/file22569/unnamed ___ Python tracker <http://bugs.python.org/issue12488> ___That's interesting, thanks for your response.It is also a bit awkward.. Might I recommend adding a note to the documentation? It is not really intuitive that each child should need to close the end of the pipe it isn't using (especially since it is possible to create a child that has no explicit access to that end of the pipe, even though it has inherited the file descriptor). 2011/7/4 Charles-François Natali <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> Charles-François Natali <mailto:neolo...@free.fr";>neolo...@free.fr> added the comment: That's because the other end of the pipe (p1) is open in the child process (FDs are inherited on fork()). Just add p1.close() at the beginning of fn() and you'll get EOF. Closing as invalid. -- nosy: +neologix resolution:  -> invalid stage:  -> committed/rejected status: open -> closed ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue12488"; target="_blank">http://bugs.python.org/issue12488> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)
Luke added the comment: I recently started getting this warning message (see bottom) that seems to be due to the changes from this issue. I'm running a submodule as main using the `-m` flag, but I'm not doing any modification to `sys.modules`, or even `sys.path`... I've taken a look at [The double-import trap](http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html#the-double-import-trap), but it doesn't really seem to apply. I really have no idea how to go about debugging this. 1) Would it be possible for the warning to include information about how/where the double import is happening? 2) Are there other, common ways of this occurring when the `sys` module isn't being messed with? The issue on stackexchange (https://stackoverflow.com/questions/43393764/python-3-6-project-structure-leads-to-runtimewarning) seems similar, although this one in particular isn't reproducible. Any help would be greatly appreciated. Thanks! File "/n/home00/lkelley/.conda/envs/py35/lib/python3.6/runpy.py", line 183, in _run_module_as_main mod_name, mod_spec, code = _get_module_details(mod_name, _Error) File "/n/home00/lkelley/.conda/envs/py35/lib/python3.6/runpy.py", line 125, in _get_module_details warn(RuntimeWarning(msg)) File "/n/home00/lkelley/.conda/envs/py35/lib/python3.6/warnings.py", line 99, in _showwarnmsg msg.file, msg.line) File "/n/home00/lkelley/zcode/zcode/inout/inout_core.py", line 835, in warn_with_traceback traceback.print_stack() /n/home00/lkelley/.conda/envs/py35/lib/python3.6/runpy.py:125: RuntimeWarning: 'mbhmergers.gwb.deterministic.grid_calc' found in sys.modules after import of package 'mbhmergers.gwb.deterministic', but prior to execution of 'mbhmergers.gwb.deterministic.grid_calc'; this may result in unpredictable behaviour warn(RuntimeWarning(msg)) -- nosy: +lzkelley ___ Python tracker <http://bugs.python.org/issue27487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26847] filter docs unclear wording
New submission from Luke: The current docs for both filter and itertools.filterfalse use the following wording (emphasis added): all elements that are false are removed returns the items that are false This could be confusing for a new Python programmer, because the actual behaviour is that elements are equality-compared, not identity-compared. Suggested wording: "are equal to False" https://docs.python.org/3.5/library/functions.html#filter https://docs.python.org/3.5/library/itertools.html#itertools.filterfalse -- assignee: docs@python components: Documentation messages: 264206 nosy: docs@python, unfamiliarplace priority: normal severity: normal status: open title: filter docs unclear wording type: enhancement versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue26847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26847] filter docs unclear wording
Luke added the comment: josh, we're saying the same thing but misunderstanding each other. :) I realize that they can be empty containers, etc., and that's why I think "equal to False" is appropriate -- because those things *are* equal to False: >>> [] == False True >>> 0 == False True etc. However, they are not identical to False: >>> [] is False False >>> 0 is False False And that's why I think the wording "are false" is potentially misleading. Perhaps there's a better wording than "equal to False" (compares equivalently to False? or simply: are falsey? :p), but anyhow, we're identifying the same behaviour here. -- ___ Python tracker <http://bugs.python.org/issue26847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26847] filter docs unclear wording
Luke added the comment: For shame! ... I deserved that callout. :S My examples should have included the cast to bool, which is indeed not the same as the values' being "equal to False" in themselves... I didn't realize that "is false" was conventional shorthand for that cast and comparison. Thanks! -- ___ Python tracker <http://bugs.python.org/issue26847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1114] _curses issues on 64-bit big-endian (e.g, AIX)
New submission from Luke Mewburn:
Attempting to use curses attributes with python 2.3.5 on AIX (64bit
powerpc) doesn't work, and occasionally results in exceptions being raised.
_cursesmodule.c assumes that attr_t is a `long' and uses the "l"
decoding of PyArg_ParseTuple() to read values from python to C. On
platforms where sizeof(int) == sizeof(long), this isn't a problem.
However, on LP64, especially big-endian LP64, this results in the wrong
value being stored in the target address.
My solution is to use ParseTuple("l") into a variable with an explicit
type of 'long', and then assign that to the attr_t variable that the
underlying curses(3) functions are called with.
(I don't know if there's a different convention for dealing with reading
numbers from python into underlying C types where the C type size isn't
consistently an `int' or a `long', other that reading into an explicit
int/long and then assigning/casting to the final type)
The code in question doesn't appear to have changed much between python
2.3.5 and the svn trunk (as at 20070906), and my patch for the former
applied fairly cleanly to my checkout of the latter. I've attached a
diff from the svn checkout.
--
components: Extension Modules
files: curses-attr_t-long.diff
messages: 55675
nosy: lukemewburn
severity: normal
status: open
title: _curses issues on 64-bit big-endian (e.g, AIX)
type: behavior
versions: Python 2.3
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1114>
__Index: Modules/_cursesmodule.c
===
--- Modules/_cursesmodule.c (revision 57996)
+++ Modules/_cursesmodule.c (working copy)
@@ -315,9 +315,6 @@
Window_NoArg2TupleReturnFunction(getmaxyx, int, "ii")
Window_NoArg2TupleReturnFunction(getparyx, int, "ii")
-Window_OneArgNoReturnFunction(wattron, attr_t, "l;attr")
-Window_OneArgNoReturnFunction(wattroff, attr_t, "l;attr")
-Window_OneArgNoReturnFunction(wattrset, attr_t, "l;attr")
Window_OneArgNoReturnFunction(clearok, int, "i;True(1) or False(0)")
Window_OneArgNoReturnFunction(idlok, int, "i;True(1) or False(0)")
#if defined(__NetBSD__)
@@ -372,6 +369,7 @@
PyObject *temp;
chtype ch = 0;
attr_t attr = A_NORMAL;
+ long lattr;
switch (PyTuple_Size(args)) {
case 1:
@@ -379,8 +377,9 @@
return NULL;
break;
case 2:
-if (!PyArg_ParseTuple(args, "Ol;ch or int,attr", &temp, &attr))
+if (!PyArg_ParseTuple(args, "Ol;ch or int,attr", &temp, &lattr))
return NULL;
+attr = lattr;
break;
case 3:
if (!PyArg_ParseTuple(args,"iiO;y,x,ch or int", &y, &x, &temp))
@@ -389,8 +388,9 @@
break;
case 4:
if (!PyArg_ParseTuple(args,"iiOl;y,x,ch or int, attr",
- &y, &x, &temp, &attr))
+ &y, &x, &temp, &lattr))
return NULL;
+attr = lattr;
use_xy = TRUE;
break;
default:
@@ -418,6 +418,7 @@
int x, y;
char *str;
attr_t attr = A_NORMAL , attr_old = A_NORMAL;
+ long lattr;
int use_xy = FALSE, use_attr = FALSE;
switch (PyTuple_Size(args)) {
@@ -426,8 +427,9 @@
return NULL;
break;
case 2:
-if (!PyArg_ParseTuple(args,"sl;str,attr", &str, &attr))
+if (!PyArg_ParseTuple(args,"sl;str,attr", &str, &lattr))
return NULL;
+attr = lattr;
use_attr = TRUE;
break;
case 3:
@@ -436,8 +438,9 @@
use_xy = TRUE;
break;
case 4:
-if (!PyArg_ParseTuple(args,"iisl;int,int,str,attr", &y, &x, &str, &attr))
+if (!PyArg_ParseTuple(args,"iisl;int,int,str,attr", &y, &x, &str, &lattr))
return NULL;
+attr = lattr;
use_xy = use_attr = TRUE;
break;
default:
@@ -464,6 +467,7 @@
int rtn, x, y, n;
char *str;
attr_t attr = A_NORMAL , attr_old = A_NORMAL;
+ long lattr;
int use_xy = FALSE, use_attr = FALSE;
switch (PyTuple_Size(args)) {
@@ -472,8 +476,9 @@
return NULL;
break;
case 3:
-if (!PyArg_ParseTuple(args,"sil;str,n,attr", &str, &n, &attr))
+if (!PyArg_ParseTuple(args,"sil;str,n,attr", &str, &n, &lattr))
return NULL;
+attr = lattr;
use_attr = TRUE;
break;
case 4:
@@ -482,8 +487,9 @@
use_xy = TRUE;
break;
case 5:
-if (!PyArg_ParseTuple(args,"iisil;y,x,str,n,attr", &y, &x, &str, &n, &attr))
+if (!PyArg_ParseTuple(args,"iisil;y,x,str,n,attr", &y, &x, &str, &n, &lattr))
return NULL;
+attr = lattr;
use_xy = use_attr = TRUE;
break;
default:
@@ -510,6 +516,7 @@
PyO
[issue1711603] syslog syscall support for SysLogLogger
Luke-Jr added the comment: So label it a "design flaw" if not a bug. Syscalls are the primary and only guaranteed method of writing to the system log. Very few applications or users use sockets for syslog, and socket support should only be required when logging to a remote system. Even if this is treated as a 'feature' (which it clearly is more than), it should still be merged into the current development branch. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1711603> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1429] FD leak in SocketServer
New submission from Luke-Jr: SocketServer.ThreadingUnixStreamServer leaks file descriptors when a request handler throws an exception. -- components: Library (Lib) messages: 57396 nosy: luke-jr severity: normal status: open title: FD leak in SocketServer versions: Python 2.4 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1429> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1434] SocketServer creates non-blocking files
New submission from Luke-Jr: SocketServer recently started giving my request handler rfiles that don't block: readfile() gives me a timeout exception. This used to work fine. I begin writing this server with 2.4.3, and it is currently running under 2.4.4, so my suspicious is somewhere in between it changed. -- components: Library (Lib) messages: 57445 nosy: luke-jr severity: normal status: open title: SocketServer creates non-blocking files versions: Python 2.4 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1434> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Luke Plant added the comment: David, Thanks again for the time on this. Can I push to get the patches included, or is there work that still needs to be done on the patches now that the idea is accepted in principle? I did experiment with a few approaches to implement, and it seemed like the most sensible. Thanks, Luke -- ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Luke Plant added the comment: First, I agree with others who say that RFCs are basically irrelevant for cookies. For Django we've discovered this in various ways e.g. issue 9824 - http://bugs.python.org/issue9824 - which has now been applied. We have also had to work around the stdlib behaviour here. Second, I have implemented a patch for this, with tests, against trunk - please review. After looking at the implementation, this seems like the best way to make Python conservative in what is produces and liberal in what it accepts, which seems to be what the thread converged on. BaseCookie will now silently discard cookie 'morsels' with a colon in their name (and all other irregularities) when loading from a string, rather than raise an exception. This allows cookie parsing to continue, so that other cookies in the HTTP header will be found. However, if in Python code you attempt to directly set a morsel with an illegal name, you will still get the error. There is a more lax strategy: Simply add ':' to the _LegalChars variable. This would allow morsels to be *read* that have a colon in their name. However, from the current implementation, it would be very hard to add that ability without also allowing the BaseCookie class to produce such cookies. This would also raise other issues about at what point an error should be raised for setting invalid cookies etc. Also, allowing these illegal cookies to be read is a corner case that is much less important - it isn't needed either for Trac or for our needs in Django. For these reasons, I decided against the more lax strategy. -- keywords: +patch nosy: +spookylukey Added file: http://bugs.python.org/file22513/issue2193_patch_trunk.diff ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Luke Plant added the comment: Same patch backported to python 2.7 branch -- Added file: http://bugs.python.org/file22514/issue2193_patch_python27.diff ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Luke Plant added the comment: Found a bug with patch - this supersedes old one. -- Added file: http://bugs.python.org/file22515/issue2193_patch_2_trunk.diff ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Luke Plant added the comment: Same against Python 2.7 -- Added file: http://bugs.python.org/file22516/issue2193_patch_2_python27.diff ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Changes by Luke Plant : Removed file: http://bugs.python.org/file22513/issue2193_patch_trunk.diff ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Changes by Luke Plant : Removed file: http://bugs.python.org/file22514/issue2193_patch_python27.diff ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Luke Plant added the comment: I had a quick look, and there are these relevant bits: << There are two audiences for this specification: developers of cookie-generating servers and developers of cookie-consuming user agents. >> And: << To maximize interoperability with user agents, servers should limit themselves to the well-behaved profile defined in Section 4 when generating cookies. >> So, the document doesn't tell servers how to parse cookies, only how to generate them. With regards to generation, there is basically no change - we still disallow programmers to set cookie names that are not a 'token', as defined by section 4 of that document, which is the same as RFC 2109 in terms of valid cookie names if you look at it. It is not obvious to me that Python's BaseCookie implementation obeys RFC 2109 (due to the way character lists are defined in the opposite way), but if you believe the comments in the module then it does. I haven't read the rest of RFC 6265 and checked BaseCookie against it - that would be a much bigger job. But with respect to the change in my patch, it looks like we are all OK. -- ___ Python tracker <http://bugs.python.org/issue2193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2193] Cookie Colon Name Bug
Luke Plant added the comment:
@ David Murray:
Thanks for taking the time to look at this - can I trouble you to keep going
and read my response?
Thanks.
You wrote:
> IMO the thing that needs to be fixed here is that receiving an invalid cookie
> makes it difficult to receive the valid cookies.
I agree absolutely, and my patch implements exactly that aim. So I don't
understand why the rest of your reply goes on to assume a very different goal -
handling RFC-invalid cookies such that we can read their values.
> I'd love to accept your patch, but "silently ignore" sounds like a bad
> idea and is something we try to avoid in Python where practical.
"silently ignore" is what the current BaseCookie implementation does for
**every other** type of invalid input, with the only exception (I can find)
being the case where everything is correct apart from the name:
>>> from Cookie import SimpleCookie
>>> c = SimpleCookie()
>>> c.load('rubbish')
>>> c
>>> c.output()
''
>>> c.load('more:rubbish')
>>> c
>>> c.load('name=value')
>>> c
>>> c.load('name=value; invalidattribute;')
>>> c.output()
'Set-Cookie: name=value'
>>> c.load('xyz123"sfs;;=-abc')
>>> c
>>> c.load('namewith:colon=value')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/Cookie.py", line 632, in load
self.__ParseString(rawdata)
File "/usr/lib/python2.7/Cookie.py", line 665, in __ParseString
self.__set(K, rval, cval)
File "/usr/lib/python2.7/Cookie.py", line 585, in __set
M.set(key, real_value, coded_value)
File "/usr/lib/python2.7/Cookie.py", line 460, in set
raise CookieError("Illegal key value: %s" % key)
Cookie.CookieError: Illegal key value: namewith:colon
As you said, I think this ticket is about fixing that last one, which is the
gross exception to the rule, and the only thing that is causing major problems
for people.
I agree that handling cookies with invalid names so that we can read them would
be nice, but I think it is **very** difficult to find a rationale for saying
that this bug fix should have to wait for that change.
In addition, I do not think there is any sensible way to implement that
suggestion given the API of BaseCookie at the moment - it's not just the
implementation I baulked at, it is the API of BaseCookie that works against you
every step of the way.
The API of BaseCookie works like this in the typical case:
Consuming:
input -> load()-> store in BaseCookie -> __getitem__()
Generating:
input -> __setitem__() -> store in BaseCookie -> output()
(Of course you don't have to do it that way, but looking at the docs and
examples, http://docs.python.org/library/cookie.html, it's very clear that it's
meant to be used that way).
The fact that both modes involves storing in BaseCookie really messes up any
attempt to make these two work differently, and means you would have a really
surprising and strange API whichever way you do it.
So, option (1): you could allow BaseCookie to store invalid cookie names if
they come via load, but not via __setitem__(). This means that you've got an
easy work-around for BaseCookie refusing to store your value - just use
'load()' instead. It also means that simple code like this fails:
>>> c['name:val'] = c['name:val']
which can be a problem if you are trying to do some generalised processing of
the contents of a BaseCookie.
This leads us to option (2): allow RFC-invalid cookies to be stored, but then
quietly sanitise (i.e. discard) in output().
But this becomes a much worse example of "silently ignoring" - the former is
tolerant handling of data that is outside the programmers control - Postel's
law. But this would be accepting incorrect data from a programmer, and then
silently discarding it, is what we should do our utmost to avoid.
Neither of these options is any good, and it is because the API of BaseCookie
was just not designed for it. The only sensible things to do, given our API, is
sanitise on input. We could have an 'RFC-invalid' mode, but it would have to be
turned on for the whole Cookie instance, and it would be a feature addition. An
alternative implementation would be a 'badmorsels' attribute which preserves
the rubbish where possible, in case you want it - but again, it's a feature
addition.
Finally, I think the behaviour you are aiming at is unreasonable to ask for,
especially in this ticket. You are essentially asking for a tolerant kind of
cookie parsing which does its best to do 'do-what-I-mean'. But:
1) You haven'
[issue9824] SimpleCookie should escape commas and semi-colons
New submission from Luke Plant : In developing Django, we found that some browsers don't treat commas and semi-colons in cookie values (i.e. the Set-Cookie header) the way that RFC 2109 says they should. (Safari splits the header on a comma followed by space, Internet Explorer splits on semi-colons - both irrespective of any 'quoting'). The result is that if you use SimpleCookie to create Set-Cookie headers, where the cookie value contains a comma or semi-colon, you can get all kinds of breakage. In the end, we realised that the RFCs are kind of irrelevant, and we have to look at what browsers actually do. So, it would be much more useful if semi-colons and commas were escaped the way that other characters are by SimpleCookie. Our discussion/findings are here: http://code.djangoproject.com/ticket/12470#comment:4 http://groups.google.com/group/django-developers/msg/2cb729938e8e67ca The patch to Cookie.py (Python 2.X) or http/cookies.py (Python 3.X) is simple and follows. I'm assuming that this applies to Python 3.2 and 3.3, but I haven't checked. -- components: Library (Lib) files: simplecookie_fix.diff keywords: patch messages: 116030 nosy: spookylukey priority: normal severity: normal status: open title: SimpleCookie should escape commas and semi-colons type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file18833/simplecookie_fix.diff ___ Python tracker <http://bugs.python.org/issue9824> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9824] SimpleCookie should escape commas and semi-colons
Luke Plant added the comment: I forgot to mention backwards compatibility: In the context of Cookie being used in a web application, if developers were relying on literal commas and semi-colons being present in the client side cookie value (e.g. in javascript), the patch will introduce an incompatibility. A quick review of cookies on my computer shows that 22 out of 3079 have commas in them, and none have semi-colons in them. For those with commas, there would still only be a problem if they were reading them client side, or not using Python's Cookie library to decode the values server side. -- ___ Python tracker <http://bugs.python.org/issue9824> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10148] st_mtime differs after shutil.copy2
New submission from Luke McCarthy : When copying a file with shutil.copy2() between two ext4 filesystems on 64-bit Linux, the mtime of the destination file is different after the copy. It appears as if the resolution is slightly different, so the mtime is truncated slightly. For example: source file mtime: 1287367331.8433506 destination file mtime: 1287367331.84335 -- components: Library (Lib) messages: 119176 nosy: shaurz priority: normal severity: normal status: open title: st_mtime differs after shutil.copy2 type: behavior versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue10148> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11001] Various obvious errors in cookies documentation
New submission from Luke Plant : Docs for SimpleCookie, BaseCookie.value_encode and BaseCookie.value_decode are obviously incorrect. Attempt at patch attached. The error has existed in every Python version I've seen, I've tagged the ones I believe can receive fixes, sorry if I've made a mistake. Thanks. -- assignee: docs@python components: Documentation files: http_cookies_doc_corrections.diff keywords: patch messages: 126962 nosy: docs@python, spookylukey priority: normal severity: normal status: open title: Various obvious errors in cookies documentation versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file20507/http_cookies_doc_corrections.diff ___ Python tracker <http://bugs.python.org/issue11001> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8374] Some locales are unsupported
New submission from Luke Jennings : In the locale module there are some locales that are not supported these the ones that I am aware of are nl_AW, sr_RS sr_ME. This information was due to a project that captures screenshots in different languages and we have to retrieve the language code. Related to the origin of the bug https://bugs.edge.launchpad.net/quickshot/+bug/554861 . If any more information is required please let me know. -- components: Extension Modules messages: 102891 nosy: ubuntujenkins severity: normal status: open title: Some locales are unsupported type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8374> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8374] Some locales are unsupported
Luke Jennings added the comment: Other programs do work with the local. I am working on dealing with exceptions, I am rather new to programing and thought it would also be good to try and get this fixed in the original module. -- ___ Python tracker <http://bugs.python.org/issue8374> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8374] Some locales are unsupported
Luke Jennings added the comment: Sorry for the confusion but that bug report has two very similar problems to it if you look at https://bugs.edge.launchpad.net/quickshot/+bug/554861/comments/7 and https://bugs.edge.launchpad.net/quickshot/+bug/554861/comments/6 . I think that is calling the locale module. I apologize if i have put this down to the wrong thing I am new to python. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue8374> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44705] Support Windows file open modes for `open` built-in function
New submission from Luke Deller : Microsoft Windows supports some extra file open modes including: "S"Specifies that caching is optimized for, but not restricted to, sequential access from disk. "T"Specifies a file as temporary. If possible, it is not flushed to disk. "D"Specifies a file as temporary. It is deleted when the last file pointer is closed Python 2 used to allow "T" and "D" flags in the built-in `open` function (though this was not documented): https://github.com/python/cpython/blob/2.7/Objects/fileobject.c#L214 It would be great if these flags were allowed in Python 3. I see that Python3 implementation uses `open`/`_wopen` rather than `fopen` now. The mapping to numeric flags for `_wopen` is shown in the documentation here: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen (search for "Equivalent oflag value") -- components: IO messages: 397971 nosy: lukedeller1 priority: normal severity: normal status: open title: Support Windows file open modes for `open` built-in function type: enhancement versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45013] os.path.isfile fails on path exactly 260 Chars long in Windows
New submission from Luke Rossi : I saw 33105, but believe this to be a different issue as path length 260 is valid. I did testing by crafting a path that is exactly 260 by hand - A path 259 in length reports .isfile() as True. -- components: Library (Lib) messages: 400341 nosy: serhiy.storchaka, ubermidget2 priority: normal severity: normal status: open title: os.path.isfile fails on path exactly 260 Chars long in Windows type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45013] os.path.isfile fails on path exactly 260 Chars long in Windows
Luke Rossi added the comment: I saw 33105, but believe this to be a different issue as path length 260 is valid. I did testing by crafting a path that is exactly 260 by hand - A path 259 in length reports .isfile() as True. The Stack Error: [WinError 3] The system cannot find the path specified -- ___ Python tracker <https://bugs.python.org/issue45013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45013] os.path.isfile fails on path exactly 260 Chars long in Windows
Luke Rossi added the comment: What an annoying edge case - makes sense that there isn't an easy fix. The extended path prefix worked perfectly - thanks -- ___ Python tracker <https://bugs.python.org/issue45013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42723] Unclear why dict unpacking cannot be used in dict comprehension
New submission from Luke Davis :
Why am I unable to do:
dict = { **sub_dict for sub_dict in super_dict.values() }
which throws: "dict unpacking cannot be used in dict comprehension"
Whereas the equivalent code below doesn't throw any errors?:
dict = {}
for sub_dict in super_dict.values():
dict = { **dict, **sub_dict }
Am I wrong in thinking the first and second block of code should do the same
thing behind the scenes?
--
messages: 383641
nosy: PartlyFluked
priority: normal
severity: normal
status: open
title: Unclear why dict unpacking cannot be used in dict comprehension
type: enhancement
___
Python tracker
<https://bugs.python.org/issue42723>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13637] binascii.a2b_* functions could accept unicode strings
Luke-Jr added the comment: Has this been fixed in 3.2 yet? Somehow it seems to have been "reclassified" as an enhancement when it's really a regression. str worked fine in these functions in 3.1. ------ nosy: +luke-jr ___ Python tracker <http://bugs.python.org/issue13637> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14282] lib2to3.fixer_util.touch_import('__future__', ...) can lead to SyntaxError in code
New submission from Luke Macken :
Problem:
lib2to3.fixer_util.touch_import('__future__', ...) will insert the import
statement below all other imports. This will then trigger the following error:
SyntaxError: from __future__ imports must occur at the beginning of the file
How to reproduce the issue (using modernize, which uses lib2to3):
$ git clone https://github.com/mitsuhiko/python-modernize.git
$ cd python-modernize
$ echo << EOF >> test.py
# test.py
"Test case for lib2to3.fixer_util.touch_import('__future__', ...)"
import os
print "hi"
EOF
$ python modernize.py test.py
--- test.py (original)
+++ test.py (refactored)
@@ -1,4 +1,5 @@
# test.py
"Test case for lib2to3.fixer_util.touch_import('__future__', ...)"
import os
-print "hi"
+from __future__ import print_function
+print("hi")
$ python3 test.py
File "test.py", line 4
from __future__ import print_function
^
SyntaxError: from __future__ imports must occur at the beginning of the
file
The following patch to lib2to3 seems to solve the issue:
--- /usr/lib64/python2.7/lib2to3/fixer_util.py.orig 2012-03-09
21:53:10.841083479 -0800
+++ /usr/lib64/python2.7/lib2to3/fixer_util.py 2012-03-09
21:58:18.678946683 -0800
@@ -306,14 +306,15 @@
# figure out where to insert the new import. First try to find
# the first import and then skip to the last one.
insert_pos = offset = 0
-for idx, node in enumerate(root.children):
-if not is_import_stmt(node):
-continue
-for offset, node2 in enumerate(root.children[idx:]):
-if not is_import_stmt(node2):
-break
-insert_pos = idx + offset
-break
+if package != '__future__':
+for idx, node in enumerate(root.children):
+if not is_import_stmt(node):
+continue
+for offset, node2 in enumerate(root.children[idx:]):
+if not is_import_stmt(node2):
+break
+insert_pos = idx + offset
+break
# if there are no imports where we can insert, find the docstring.
# if that also fails, we stick to the beginning of the file
After the patch, all is well:
$ python modernize.py test.py
--- test.py (original)
+++ test.py (refactored)
@@ -1,4 +1,5 @@
# test.py
"Test case for lib2to3.fixer_util.touch_import('__future__', ...)"
+from __future__ import print_function
import os
-print "hi"
+print("hi")
$ python3 test.py
hi
--
components: 2to3 (2.x to 3.x conversion tool)
messages: 155569
nosy: lmacken
priority: normal
severity: normal
status: open
title: lib2to3.fixer_util.touch_import('__future__', ...) can lead to
SyntaxError in code
type: behavior
___
Python tracker
<http://bugs.python.org/issue14282>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14282] lib2to3.fixer_util.touch_import('__future__', ...) can lead to SyntaxError in code
Changes by Luke Macken : -- keywords: +patch Added file: http://bugs.python.org/file24814/python-lib2to3-touch-future-import.patch ___ Python tracker <http://bugs.python.org/issue14282> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14282] lib2to3.fixer_util.touch_import('__future__', ...) can lead to SyntaxError in code
Luke Macken added the comment: Yep, that seems like the right solution. Thanks, Martin. -- ___ Python tracker <http://bugs.python.org/issue14282> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30203] AttributeError in Popen.communicate()
New submission from Luke Campagnola:
In my application, calling communicate() on a Popen instance is giving the
following exception:
. . .
File "/usr/lib/python3.5/subprocess.py", line 1072, in communicate
stdout, stderr = self._communicate(input, endtime, timeout)
File "/usr/lib/python3.5/subprocess.py", line 1693, in _communicate
stdout = self._fileobj2output[self.stdout]
AttributeError: 'Popen' object has no attribute '_fileobj2output'
I have not been able to reproduce this in a simple example, but I imagine this
could happen if Popen._communicate() raises an exception in the first 20 lines
or so--this would cause _communication_started to be set True, even though
_fileobj2output has not been initialized.
I suggest setting self._fileobj2output = None in Popen.__init__() and changing
the relevant code in _communicate() from
if not self._communication_started:
self._fileobj2output = {}
to:
if self._fileobj2output is None:
self._fileobj2output = {}
--
messages: 292575
nosy: Luke Campagnola
priority: normal
severity: normal
status: open
title: AttributeError in Popen.communicate()
type: behavior
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue30203>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30203] AttributeError in Popen.communicate()
Luke Campagnola added the comment: Update: this appears to be the prior exception that causes _communication_started and _fileobj2ouput to be out of sync: File "/usr/lib/python3.5/subprocess.py", line 1072, in communicate stdout, stderr = self._communicate(input, endtime, timeout) File "/usr/lib/python3.5/subprocess.py", line 1672, in _communicate self.stdin.flush() ValueError: flush of closed file -- ___ Python tracker <http://bugs.python.org/issue30203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14683] os.path.isdir.__name__ is "_isdir" on Windows (2.7.3)
New submission from Luke McCarthy : This caused something to break in our code. I know, maybe it shouldn't rely on that. -- messages: 159460 nosy: shaurz priority: normal severity: normal status: open title: os.path.isdir.__name__ is "_isdir" on Windows (2.7.3) versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue14683> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9216] FIPS support for hashlib
Luke Carrier added the comment: I've not done enough digging on the issue I'm presently experiencing to draw any conclusions make any suggestions, but this change seems to break the present distribute module (version 0.6.27). It appears it will likely break a great deal of other code too. I've pasted the relevant output here and attached the full traceback. File "/usr/lib64/python3.2/hashlib.py", line 112, in __get_openssl_constructor f(usedforsecurity=False) TypeError: openssl_md5() takes no keyword arguments Whilst I agree with the notion behind this change, Fedora's quick actions have led to me spending the best part of an hour of the night before ship day diagnosing issues caused by undocumented (or at least under-documented) changes to code I haven't written or interfaced with. _Please_ publicise the change a little better? Pretty please!? -- nosy: +lukecarrier Added file: http://bugs.python.org/file26205/virtualenv_distribute ___ Python tracker <http://bugs.python.org/issue9216> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
Changes by Luke Dunstan : -- nosy: +Luke.Dunstan versions: +Python 3.4 ___ Python tracker <http://bugs.python.org/issue17797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16708] Module: shutil will not import when writen in the text editor but will in the python shell
Changes by luke wood : -- components: Library (Lib) files: dropbox dropper.py nosy: dj_law priority: normal severity: normal status: open title: Module: shutil will not import when writen in the text editor but will in the python shell type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file28346/dropbox dropper.py ___ Python tracker <http://bugs.python.org/issue16708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16708] Module: shutil will not import when writen in the text editor but will in the python shell
luke wood added the comment:
ok i dont really know what python list is. i googled it but it just came up
with the documentation.
Traceback (most recent call last):
File "C:\Users\luke\Documents\Python Code\dropbox dropper.py", line 1, in
import shutil
File "C:\Python33\lib\shutil.py", line 14, in
import tarfile
File "C:\Python33\lib\tarfile.py", line 48, in
import copy
File "C:\Users\luke\Documents\Python Code\copy.py", line 4, in
shutil.copy2(source, destination)
AttributeError: 'module' object has no attribute 'copy2'
--
status: pending -> open
___
Python tracker
<http://bugs.python.org/issue16708>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6534] os.makedirs returns EACCES for "C:\"
New submission from Luke-Jr : Should return EEXIST or EISDIR provided C:\ actually exists -- components: Windows messages: 90764 nosy: luke-jr severity: normal status: open title: os.makedirs returns EACCES for "C:\" type: behavior versions: Python 2.5 ___ Python tracker <http://bugs.python.org/issue6534> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6534] os.makedirs returns EACCES for "C:\"
Luke-Jr added the comment: At least fix the documentation, then... -- ___ Python tracker <http://bugs.python.org/issue6534> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Luke Taylor added the comment: Are you aware of Pythonista? I have no affiliation, but I'm a fan of the app and the community surrounding it. See http://omz-software.com/pythonista/ for details. I'm sure communication with the developer of the app could yield some useful insights. -- nosy: +Luke Taylor ___ Python tracker <http://bugs.python.org/issue23670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23670] Modifications to support iOS as a cross-compilation target
Luke Taylor added the comment: Ok, great! On Fri, Jun 3, 2016 at 7:34 AM Luke Taylor wrote: > Ah, cool! > On Fri, Jun 3, 2016 at 2:58 AM Russell Keith-Magee > wrote: > >> >> Russell Keith-Magee added the comment: >> >> Yes - I'm aware of Pythonista; the author of that app contracted me to >> develop the 3.5 patch that is attached to this ticket :-) >> >> -- >> >> ___ >> Python tracker >> <http://bugs.python.org/issue23670> >> ___ >> > -- ___ Python tracker <http://bugs.python.org/issue23670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17340] Handle malformed cookie
Luke Plant added the comment: I'm a core developer on Django, and I've looked into cookies a lot, and also Python's SimpleCookie, and I've found that all accepted RFCs are completely irrelevant for this issue. No accepted RFC was ever widely implemented - instead browsers mainly did something like the original "Netscape cookies", with various interpretations. Opera attempted RFC 2965, at least at one point, but no-one else. RFC 6265, whatever its status, is probably the closest thing to a useful document of how cookies "should" work. But even then, I'm afraid that the main guiding principle has to be sheer pragmatism. Read the source code or bug trackers of any other project that has to handle cookies and you'll find they have all come to that conclusion, unfortunately. -- ___ Python tracker <http://bugs.python.org/issue17340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24627] Import bsddb result in error on OS X (Python 2.7.10)
New submission from Luke Jang: As title. I installed Python using brew. $ python Python 2.7.10 (default, Jul 9 2015, 13:34:07) [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb Traceback (most recent call last): File "", line 1, in File "/usr/local/Cellar/python/2.7.10_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/bsddb/__init__.py", line 67, in import _bsddb ImportError: No module named _bsddb >>> -- components: Library (Lib) messages: 246682 nosy: Luke Jang priority: normal severity: normal status: open title: Import bsddb result in error on OS X (Python 2.7.10) versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue24627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12346] Python source code build fails with old mercurial
Luke Erlacher added the comment: This is not fixed in 2.7.10. -- nosy: +Luke Erlacher ___ Python tracker <http://bugs.python.org/issue12346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26255] symtable.Symbol.is_referenced() returns false for valid use
New submission from Luke Schubert:
If the following function is saved in listcomp.py:
def encode(inputLetters):
code = {'C':'D', 'F':'E'}
return set(code[x] for x in inputLetters)
and the following code is used to create a symtable for this function:
import symtable
if __name__ == "__main__":
fileName = 'listcomp.py'
f = open(fileName, 'r')
source = f.read()
table = symtable.symtable(source, fileName, 'exec')
children = table.get_children()
for childTable in children:
symbols = childTable.get_symbols()
for s in symbols:
if (not s.is_referenced()):
print ("Unused symbol '%s' in function '%s'"
% (s.get_name(), childTable.get_name()))
then is_referenced() returns false for the 'code' symbol.
If the following function is saved instead:
def encode2(inputLetters):
code = {'C':'D', 'F':'E'}
return [ code[x] for x in inputLetters ]
then is_referenced() returns true for the 'code' symbol.
Possibly I'm misunderstanding what is_referenced() means, but I thought it
should return true in both cases?
--
messages: 259316
nosy: luke.schubert
priority: normal
severity: normal
status: open
title: symtable.Symbol.is_referenced() returns false for valid use
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue26255>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34027] python 3.7 openpty/forkpty build failure using nix package manager macOS environment
Luke Granger-Brown added the comment: Still seems to be a problem with everything up to Py3.11. -- nosy: +lukegb versions: +Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue34027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with packaging
Luke Kenneth Casson Leighton added the comment: eric, if you recall there was some discussion that it was acceptable to use distutils but *only* for python 2.N (on the basis that its use is so well entrenched that it would be impossible to force python2.N applications to start using distutils2), and i agreed wholeheartedly with you that the expectation to use distutils2 would be reasonable for python3.N just as an aside: have all python 3.N packaging scripts, for all python-dev scripts *and* all 3rd party packages world-wide, been using distutils2 by default instead of distutils? -- ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton added the comment: On Sun, Aug 8, 2010 at 12:27 AM, Éric Araujo wrote: > > Éric Araujo added the comment: > > FYI, distutils is frozen because even minor bug fixes have broken third-party > tools in the past, that’s why new features and bug fixes land in distutils2. > Only some bug fixes that are sure not to break things make their way into > distutils. distutils2 will be reintegrated into the stdlib in 3.2 or 3.3, but > standalone releases will be made for Python 2.4 up to 2.7 and 3.x. eric, it's been a year since i did the mingw32 port so i'll try to recall what it was that i did, but i have recollections of also having to add to distutils, specifically adding an extra compiler class and an extra linker class, derived from cygwin i believe (and then adding, obviously, platform detection logic and options to make use of them). using logic analysis on the conditions, it can be shown that there is nothing that can satisfy the conditions (one of which is "distutils is frozen", another is "distutils will not go into python2.N or 3.x" etc). thus, something has to give. detailed analysis and recommendations follow: if distutils2 is to be "standalone" it literally makes it impossible to build python 2.4 up to 2.7 and 3.x using mingw32, because the build infrastructure will be entirely missing. how can you build python 2.7 using mingw32 if one of the critical dependencies - actually saying "use mingw32" - is missing?!! the decision to keep distutils frozen therefore forces the mingw32 developers to create a "special" version of distutils, one which has to be added as a patch to python - let's call it distutils_mingw32 - which has the exact same functionality as distutils except that it is extended to have a mingw32 compiler and linker class. adding such a patch (which adds a copy of distutils called distutils_mingw32) would be extremely disruptive, as it would defeat the entire purpose of distutils, and i would be extremely surprised if it was accepted. so, unpalatable-as-defined-by-previous-negative-experience as it may be, the only sensible option is to do an extremely careful and thorough review of LRN's distutils compiler and linker class additions, and ensure that they are _purely_ additional classes, even at the expense of duplicated code. please remember that mingw32 is an _additional_ platform, not a change to any _existing_ platforms. l. p.s. the only other option i can think of would be to add in build-time options where you can specify the fully-qualified path to where distutils2 can be found. this would be somewhat... contrived, but would "work". -- ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton added the comment: sorry to have to ask, but could we get some feedback please so that this issue may move forward? currently there is a conflict between what is required and what is stated as being "absolute law". let's imagine that it is reasonable to expect distutils2 to be used. python proceeds with the mingw32 patches using distutils2, python 2.N is compiled and released. an average user installs python 2.N mingw32 and they run "python setup.py install" on a package - what happens? they get a compile error, don't they? why do they get a compile error? because the setup.py tries to build some c code, and at the top of *their* setup.py is "import distutils". so you now force thousands of developers to patch a their setup.py scripts - scripts which have worked for years - _just_ so that those packages can cope with the use of distutils2 for the mingw32 platform? so we have another "reducto ad absurdum" which demonstrates that it is impractical to expect distutils to be frozen. thus, we are forced to consider alternative options, such as "monkey-patching" of distutils, to satisfy the requirements. would the following be acceptable, to be inserted somewhere in the path so that it is guaranteed to work at all times? import mingw32_distutils_compiler import sys if "distutils.compiler" in sys.modules: sys.modules['distutils.compiler'] = mingw32_distutils_compiler where mingw32_distutils_compiler performs an import of distutils.compiler and performs a monkey-patch mish-mash to combine and replace various parts of the compiler module at run-time, to get round the "freeze" objections. would that be acceptable? please say no, because the long-term viability and maintainability of such practices is virtually nil. basically i'm pointing out to you, eric, that the freeze on distutils is unworkable and impractical and unnecessary. this isn't "bug-fixing" of distutils, it's absolutely necessary and critically required because this is an entirely new platform. * it's not cygwin: cygwin uses standard gcc but with weird outputs and quirks. * it's not standard unix gcc: you need to output ".dll" not ".so" * it's not msvc: mingw32-gcc doesn't accept "/this /that" for options. therefore i'm very sorry to have to spell it out but a new compiler and linker type - a NEW compiler and linker type - an ADDITIONAL compiler and linker type - IS required in order to cater for this platform, and there's no getting away from that fact. please could we have some acknowledgement of this fact, and acceptance of this fact, and a plan for moving forward with careful review of this patch, so that LRN and others do not have their time spent pursuing a direction involving distutils2 which will be completely fruitless? many many thanks, l. -- ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted
Luke Kenneth Casson Leighton added the comment: erik, i'm really sorry, but the freeze on distutils simply cannot be accepted: there really is no other way, as you can see from the previous walkthrough analysis, and is reinforced by the further analysis below. simply put: if the freeze on distutils is not lifted, then this entire set of work, which has been going on for years and _precedes_ the distutils freeze by at least 18 months, is completely, utterly and totally wasted. let's walk through the situation where distutils2 is forced to be used. what you're asking for is, basically, that every single third party package, of which there must be tens of thousands, must be patched for compilation on mingw32... _just_ so that it says "if sys.platform == 'mingw32': from distutils2.core import setup else: from distutils.core import setup", is that correct? does that strike you as being completely and utterly unreasonable an expectation, to ask third parties to modify setup.py scripts which have worked perfectly well for years, many of which are likely to no longer even have a maintainer? that leaves patching - which should be nothing more than _adding_ to - not "changing existing compilers" - ADDING an extra compiler - distutils as the only option. now, that can be done monkey-patch style (i.e. at runtime, by adding in code very early on in python startup, or perhaps by patching the import system to replace the word "distutils" with "distutilsmingw32") or it can be done... by lifting the distutils freeze. perhaps i should ask: what _exactly_ is the problem, and why do several teams complete and utter failure to do the correct thing by making changes to _existing_ compile platforms have anything to do with _this_ team's patches which add a new totally separate platform that has absolutely nothing to do with any of the other platforms? i could say more, but i believe the point is clear: none of the people involved in seeing mingw32 added as a platform had _anything_ to do with the past failures, so why "punish" and mis-trust the python-mingw32 for other peoples' failures? -- nosy: +lkcl ___ Python tracker <http://bugs.python.org/issue3781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted
Luke Kenneth Casson Leighton added the comment: NUTS. many apologies: my comments should have gone to issue 3871 not 3781. arse! is it possible to delete comments? :) -- ___ Python tracker <http://bugs.python.org/issue3781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton added the comment: erik, i'm really sorry, but the freeze on distutils simply cannot be accepted: there really is no other way, as you can see from the previous walkthrough analysis, and is reinforced by the further analysis below. simply put: if the freeze on distutils is not lifted, then this entire set of work, which has been going on for years and _precedes_ the distutils freeze by at least 18 months, is completely, utterly and totally wasted. let's walk through the situation where distutils2 is forced to be used. what you're asking for is, basically, that every single third party package, of which there must be tens of thousands, must be patched for compilation on mingw32... _just_ so that it says "if sys.platform == 'mingw32': from distutils2.core import setup else: from distutils.core import setup", is that correct? does that strike you as being completely and utterly unreasonable an expectation, to ask third parties to modify setup.py scripts which have worked perfectly well for years, many of which are likely to no longer even have a maintainer? that leaves patching - which should be nothing more than _adding_ to - not "changing existing compilers" - ADDING an extra compiler - distutils as the only option. now, that can be done monkey-patch style (i.e. at runtime, by adding in code very early on in python startup, or perhaps by patching the import system to replace the word "distutils" with "distutilsmingw32") or it can be done... by lifting the distutils freeze. perhaps i should ask: what _exactly_ is the problem, and why do several teams complete and utter failure to do the correct thing by making changes to _existing_ compile platforms have anything to do with _this_ team's patches which add a new totally separate platform that has absolutely nothing to do with any of the other platforms? i could say more, but i believe the point is clear: none of the people involved in seeing mingw32 added as a platform had _anything_ to do with the past failures, so why "punish" and mis-trust the python-mingw32 for other peoples' failures? -- ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton added the comment: > I'm trying to read the patch. It contains many interesting things (and > others I have no opinon about), but it is very large, and makes it > difficult to comment or find why some change were made etc. amaury: unfortunately, the development on adding mingw32 as a platform has been ongoing for well over three years, with absolute silence and rejection of its existence. it was only when a fourth person showed interest in it (LRN) that it became "accepted" - but that was... only two months ago! basically, this situation should never have been allowed to get this far: the very first patch that was created, three nearly four years ago, should have been accepted, and then an incremental process could have been taken, _and_ the silly situation in which distutils gets frozen during the time when people have been completely ignoring this ongoing work would never have occurred. but, that's the situation: the bed has been made, and now developers have to lie in it. sorry to be the one that's pointing this out, but... anyway. your idea to split this into a series has merit: personally i much prefer git, because of git-format-patch, but i have to say i've never done "patch regeneration" based on a "review / change-patch-in-middle-of-series / regenerate git-format-patch" cycle. should be fun! :) but the very very first thing that has to happen - before any of this work is begun - is for the distutils freeze to be lifted, or for someone to come up with a _sensible_ alternative solution. if that cannot be done, then roumen and LRN won't _stop_ working on python-mingw32: the end result will be that they just... continue to create a single patch file that will just get larger and larger. -- ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton added the comment: > I am not sure how we should do this, but here's my proposal > for distutils2 at least: > - make this new feature a standalone package that patches distutils > - release it for 2.x > - let's add your work in distutils2 as well, so it's back in the stdlib in 3.x that would work very well: people doing new setup.py files, converting from python2 etc., will, duh, need to do _some_ conversion: they'll expect breakage and to be using distutils2 anyway. thank you tarek. -- ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton added the comment: > The current patch makes too many changes in core distutils functions; > it cannot be accepted in this form. I'm sure that most of the needed > changes can be made in a subclass of the present Mingw32CCompiler. that's what i did when creating the _other_ (yet another) mingw32 patch - however _some_ minimal changes to core distutils _are_ unfortunately required. and to sys.py and os.py - this is, after all, a new platform! it starts off with "sys.platform == 'mingw32'", requiring detection of gcc compiler type BUT and os type of win32, and goes from there. right now, detection logic is: * "if gcc on win32 platform, platform MUST be cygwin" * "if msvc compiler, platform MUST be win32" both of which are... well... wrong! :) so, i found that it was necessary to start in os.py and sys.py, create a platform-type "mingw32" and _then_ it was easy to do a MingW32Compiler etc. with (mostly) additions not modifications to distutils, but _necessary_ to add in detection of the type. if distutils was designed to do "exec import distutils.compiler.%s as compiler" % sys.platform and go from there then this would be an entirely non-issue: no modifications to distutils would be required, just a completely separate module containing the new compiler... ... but distutils isn't designed that way, is it? :) l. -- ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton added the comment:
> I disagree;
i would say that you're entitled to disagree, but i have to point
out that unless you've actually been through the process of trying
to port python to mingw32 you're not really in a position of ...
how can i put this best... you're entitled to say "i disagree"
but that doesn't actually carry any weight.
if you said "i've tried compiling this patch, and i looked at
it and i disagreed with the decision to create a new platform,
so i removed that code, here's an updated patch, i found it to
work absolutely fine" THEN i would say that you are in a position
of authority to "disagree".
so - question: have you actually _tried_ compiling python with
mingw32, with the latest patch?
> programs compiled with mingw32 run on Windows, and use the MSVC
> runtime.
they do indeed. this however has absolutely no relevance.
> It's the same platform as the current win32 build.
> It's even possible to use mingw32 to compile extensions
> for the VS9.0 based python.exe.
it is indeed. the patch that i did allowed you to specify
a gcc spec file which did exactly that: i added options to
compile not only extensions but also the entire python.exe
to use a different MSVCRT runtime.
_and_ it did assemblies, too.
> A different compiler does not make a new platform.
ok.
unfortunately, as the work that i did was well over a year ago,
i'm going from memory - but basically, i'm very very sorry to
have to point out that you don't know what you're talking about,
here.
let me try and go through it.
look at the platform detection code: it parses the gcc version
string. it goes "if compiler has string gcc but also has win32
then it must be cygwin platform".
otherwise it goes "this must be MSVC win32 platform".
this _simply_ doesn't work, hence the need to do further
detection, hence the need to have a separate compiler type.
... but it doesn't end there: there are subtle differences
between MSVC win32 and MINGW32 win32 (differences in the
build .lib files that specify what functions are available
in the DLLs. mingw32 is a reverse-engineering project,
remember?)
to be honest i can't remember if i actually set sys.platform to
mingw32 - but the more time i spent getting more and more modules
to compile, the more blindingly obvious it was that a new platform
type was needed.
i encountered dozens of assumptions that "if sys.platform == 'win32'
then you MUST be building using visual studio: f*** off with your
attempt to compile this module using gcc".
over the eight to ten week period in which i focussed on this
non-stop for about 13 hours a day, the list just went on and on
of discrepancies that had to be solved, and if i _hadn't_ set a
new platform type, it would have been necessary to add extra
tests instead:
"if sys.platform == 'win32' and not {something to detect mingw32}":
mingw32 _really_ does fall between both worlds: not just the
compiler type is different, but there are even features and
functions _missing_ from mingw32 that are present in MSVC.
i had to work with roumen to get patches to mingw32 upstream
in some cases!
so please _do_ stop putting road-blocks in the way. this is
a complex enough project, having to fit half way between
two disparate worlds, without it being stymied by "disagreement"
when you haven't _actually_ tried compiling this code (if you
have, i apologise).
btw if you'd like to try compiling it, but are adamant about
staying away from proprietary operating systems, i _did_
manage to get python 2.5 and 2.6 cross-compiled to run under wine.
ironically there were long-standing bugs in wine that ended up
getting fixed as a result of running the 25,000 python unit tests,
but that's another story... :)
l.
p.s. msys runs under wine as well, but the configure stage takes
well over an hour. the patch i created cut out most of configure
and replaced it with a pcconfig.h just like win32, which i had
to create by hand. this was quicker than waiting for configure
to run.
--
___
Python tracker
<http://bugs.python.org/issue3871>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton added the comment: perhaps, amaury, you might like to, instead of saying "i disagree", you might like instead to say something like this: "that sounds... interesting, and a little scary - creating an entirely new platform! are you absolutely sure it's necessary?? could you please perhaps elaborate and give a good justification behind why that decision was taken?" you see how radically different that is? on the one hand you're telling three volunteers who have spent considerable time and resources - unpaid - on improving python's reach that they are, to put it bluntly, complete ignorant f*g morons, and on the other you're engaging with them, encouraging them, and generally trusting them. i'm really sorry: i really don't like having to be the one to point these kinds of things out, but... you see what i'm saying? -- ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5043] get_msvcr() returns None rather than []
Luke Kenneth Casson Leighton added the comment: i'm really sorry, eric, but the decision to ban me from interacting with python developers for 18 months+ has left me with zero working knowledge of many of these complex issues which i was heavily and actively involved in at the time, and could have answered immediately. the opportunity to interact with me and to move the mingw32 port forward was "at the time", not 18+ months later. i've since *removed* the highly complex development environment which was tricky as hell to set up (mingw32 cross compiler, mingw32 native compiler, python, native python, wine, MSYS under wine, python-win32 under wine) because it was declared that the work being carried out was worthless. i'll have to leave it to roumen to answer this one. l. -- ___ Python tracker <http://bugs.python.org/issue5043> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue708007] TelnetPopen3, TelnetBase, Expect split
Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment: finally! i accidentally found this, when looking for my own work for yet another project that requires this split. comments - several 1) the patch was relevant in 2001 at the time of creation; it was relevant for python 2.0, 2.1, 2.2, 2.3 2.4 2.5 and is still relevant now. 2) out of all of the python projects that i've done, some of which were really quite large (for one person), over half of them have required interaction with other programs - complex interaction - that required the telnetpopen class. calling out to php, calling out to c programs and using python to perform parallelisation of simple scripts onto multiple systems (a simple version of beowulf clustering), calling out to ssh to manage remote servers - the list goes on. 3) the changes that guido asked me to make, back in 2001, we talked at cross purposes (and i wasn't up to the task of saying so - sorry guido!). the changes to split along the expectlib and telnetbase classes have nothing to do whatsoever with the telnet "protocol". in fact, the enhancements that i've made _totally_ isolate the telnet protocol itself into the "Telnet" derived class, and it can clearly be seen that absolutely zero changes to the underlying implementation of the telnet "protocol" are touched. however, guido was asking me, as part of the acceptance of the changes, to perform what he believed would be some "simple" bug-fixes to the actual _inner workings_ of the (original) telnet code, which required detailed knowledge of the telnet _protocol_ which i simply ... did not have. something to do with IAC. on the basis of this miscommunication, guido's decision (seen in http://bugs.python.org/issue405228) was to close the issue and reject the code. however - there is absolutely nothing "irrelevant" about the enhancements, and the original reasons for rejection have absolutely nothing to do with the enhancements. overall, these enhancements should never have been left to rot - there was never any real reason to leave them for so long, unused; the "expect" command - see wikipedia page - has been available since 1995 and the concept is clearly well-understood as being extremely powerful; many many people in the intervening years since 2001 have written expect libraries in python - e.g. http://www.noah.org/wiki/Pexpect that one library alone - pexpect - would not need to have been written, if this patch had been accepted at the time it was written. Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue708007> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment: > In particular, I think that X-compiling is a common request added another one to the list. justification: pywebkitgtk cross-compiling for win32, using mingw32. i'm not paying for microsoft license fees, i'm not paying for a computer capable of running msvc, i'm not paying for the bandwidth to download msvc and/or set it up. much happier with mingw32, but mingw32 runs like an absolute dog under wine - and often wine_server hangs. (at least a 20x performance hit for running msys and mingw32 under wine). so... that leaves cross-compiling. i need the development libraries from python 2.5 in order to create a windows version of pywebkitgtk. -- nosy: +lkcl ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1597850> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment: the cross-compile fails on Parser/acceler.c the reason is because the included file, pyconfig.h, has "#define gid_t int" for use by the mingw32 compiler, which is... bad! removing gid_t from pyconfig.h bizarrely fixes the compile without.. so far.. any issues ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1597850> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment: pyport.h line 773 - commenting out the test for LONG_BIT != 8 * SIZEOF_LONG - we're cross-compiling amd64 host, target mingw32 - 32-bit. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1597850> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment: line 199 of thread_pthread.h and line 221: Python/thread_pthread.h:200: error: aggregate value used where an integer was expected hmmm... maybe this is due to me using mingw32 based on gcc 4.4.4. well, a quick #if 0 seems to fix it :) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1597850> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment: posixmodule.c - line 2328: add this: #if ( defined(__MINGW32__) || defined(__WATCOMC__) || defined(PYCC_VACPP) ) && !defined(__QNX__) res = mkdir(path); #else res = mkdir(path, mode); #endif ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1597850> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment: posixmodule: line 3530: #ifdef __MINGW32__ master_fd = open(DEV_PTY_FILE, O_RDWR); /* open master */ #else master_fd = open(DEV_PTY_FILE, O_RDWR | O_NOCTTY); /* open master */ #endif not sure i should be compiling posixmodule under mingw32 :) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1597850> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment: line 6193: #if !defined(__MINGW32__) && !defined(MS_WINDOWS) && defined(HAVE_FCNTL_H) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1597850> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> added the comment: ok. what's not explained, and isn't clear, is exactly whether you're supposed to - or even _capable_ of - cross-compiling the _entire_ python sourcecode base with mingw32, or whether you're supposed to get _just_ the python.exe interpreter, and, maybe if you're lucky, libpython.a (or libpython.dll - whatever). i got quite a long way, as you can see, in cross-compiling posixmodule.c _by mistake_ - before realising that the whole python sourcecode base is completely inadequately set up for cross-compiling, but is specialised "hard-coded" to compile python under msvc _only_. so, when doing the cross-compile, it was actually being detected as a _unix_ compile, not a _win32_ compile. #define WIN32 wasn't even being listened to. the end result was that entire areas of posixmodule.c were being compiled when they shouldn't have been. later, i tried to correctly #define WIN32 (or whatever was required), only to find that the mingw32 libraries don't support many of the necessary functions. for example, it's assumed that crypto libraries exist, and many other things. all in all, it didn't go too well :) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1597850> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
New submission from Luke Kenneth Casson Leighton :
there's probably a better way to do this (or a better reason), but
LONG_MIN and LONG_MAX end up as the wrong constant types when compiling
python2.5.2 under wine (don't ask...)
PyObject *
PyInt_FromSsize_t(Py_ssize_t ival)
{
if ((long)ival >= (long)LONG_MIN && (long)ival <= (long)LONG_MAX)
{
return PyInt_FromLong((long)ival);
}
return _PyLong_FromSsize_t(ival);
}
--
messages: 79411
nosy: lkcl
severity: normal
status: open
title: PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
versions: Python 2.5
___
Python tracker
<http://bugs.python.org/issue4880>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4883] Compiling python 2.5.2 under Wine on linux.
New submission from Luke Kenneth Casson Leighton :
messy patches which get python 2.5.2 compiling - and producing
python.exe.so - under wine.
the setup.py is presently _wholly_ unsuited to use for building
the modules - get_sysconfig("srcdir") returns None because...
it's supposed to!
but, the actual libpython2.5.a and the actual python.exe _are_
successfully built - and, amazingly, useable.
--
components: Build
files: f
messages: 79420
nosy: lkcl
severity: normal
status: open
title: Compiling python 2.5.2 under Wine on linux.
versions: Python 2.5
Added file: http://bugs.python.org/file12653/f
___
Python tracker
<http://bugs.python.org/issue4883>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
Luke Kenneth Casson Leighton added the comment: oh, duh - 2L not 1L yes you're right :) yeh i believe it's likely to be because in PC/pyconfig.h LONG_MAX is #defined to 7fff not 7fffL i'll double-check. you're right that would make life a looot easier. ___ Python tracker <http://bugs.python.org/issue4880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4880] PyInt_FromSsize_t LONG_MIN and LONG_MAX typecasts needed
Luke Kenneth Casson Leighton added the comment: hmmm... noo, it's already #defined to 0x7fffL in both PC/pyconfig.h _and_ in /usr/include/wine/msvcrt/limits.h so this works (Include/pyports.h) #ifdef __WINE__ /* weird: you have to typecast 0x7fffL to long */ #undef LONG_MAX #undef LONG_MIN #define LONG_MAX ((long)0x7FFFL) #define LONG_MIN ((long)(-LONG_MAX-1)) #else #ifndef LONG_MAX #if SIZEOF_LONG == 4 #define LONG_MAX 0X7FFFL #elif SIZEOF_LONG == 8 #define LONG_MAX 0X7FFFL #else #error "could not set LONG_MAX in pyport.h" #endif #endif #ifndef LONG_MIN #define LONG_MIN (-LONG_MAX-1) #endif #endif /* __WINE__ */ ___ Python tracker <http://bugs.python.org/issue4880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Changes by Luke Kenneth Casson Leighton : -- nosy: +lkcl ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
New submission from Luke Kenneth Casson Leighton : this patch uses work from #3871 to get a build of python for win32 by running msys under Wine, the windows emulator, on linux. no proprietary operating system or proprietary software was used. /bin/sh.exe is so ing unbelievably slow on msys under wine (each sh.exe takes two seconds to start up, loads 240 fonts and 40 libraries) that running configure was completely intolerable. consequently, given that PC/config.h is perfectly useable on nt, this patch totally bypasses the majority of autoconf tests, and thus cuts the configure time down from three hours to (only!) fifteen minutes. configure must be run as: ./configure --prefix/python25 --enable-win32build=yes \ --enable=shared=yes there is an additional bug in msys /bin/sh which stops python.exe from executing scripts that are handed to it on the command-line. scripts that are fed as standard-input are absolutely fine (even the same script). running the same script from python.exe from wineconsole cmd prompt is _also_ fine. as a result, the build process terminates at: ./python.exe -E setup.py build to complete the build, "wineconsole cmd" must be run, cd $(BUILDDIR) and then run the commands manually: ./python.exe -E setup.py build ./python.exe -E setup.py install then, back in the borked /bin/sh.exe, make install can be run. stunningly, this does actually work: python.exe is build, libpython2.5.dll and libpython2.5.dll.a are built... amazing. other necessary workarounds: * gcc -shared --out-implib=libpython2.5.dll.a etc fails spectacularly to create both the .a implib _and_ the .dll. consequently, it was necessary to split these up and use dlltool to create the dll, implib and .def file etc. etc. * ar and ranlib on msys, versions 2.16, 2.17 _and_ 2.19 of binutils are borked. 2.16 and 2.17 throw an exception; 2.19 segfaults. consequently, building of $LIBRARY had to be terminated with prejudice. --enable-shared=no will fail miserably. regarding testing: it's all a bit... odd. * ctypes tests cause segfaults! the S8H one manages a segfault all on its own, but there are other tests that cause corruption that only shows up later... euurgh. * builtin test_open fails due to putting \r\n instead of \n in the file * test_file.py gets a sharing violation * test_str gets a great one! test_str^M fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored err:seh:setup_exception_record stack overflow 872 bytes in thread 001e eip 7bc3b1dc esp 00410fc8 stack 0x41-0x411000-0x61 yup test_floatformatting. ahh, this is gd :) overall it's a damn good start - i'm dead impressed with wine and msys in that they exist at all. compiling and testing python under wine + msys should help test and improve both those projects, and both this patch and #3871 will help get python off of its dependence on proprietary software. -- components: Build files: f messages: 79916 nosy: lkcl severity: normal status: open title: native build of python win32 using msys under wine. versions: Python 2.5 Added file: http://bugs.python.org/file12755/f ___ Python tracker <http://bugs.python.org/issue4954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Changes by Luke Kenneth Casson Leighton : -- type: -> feature request ___ Python tracker <http://bugs.python.org/issue4954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
New submission from Luke Kenneth Casson Leighton : this is a _very_ strange case where the file contents cannot be read, under msys+wine, but under _just_ wine (cmd.exe) everything goes absolutely fine. by moving Py_Initialize() to _before_ the file load, it works! -- components: Build files: f messages: 79924 nosy: lkcl severity: normal status: open title: Py_Initialize needs to be done before file load (on msys+wine) type: crash versions: Python 2.5 Added file: http://bugs.python.org/file12758/f ___ Python tracker <http://bugs.python.org/issue4956> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
Luke Kenneth Casson Leighton added the comment: hi gabriel, thanks for looking at this, and my apologies for not editing the patch to remove debug and other information: i'm in the middle of a comprehensive porting session. WEIRD_DEBUG was me endeavouring to find out what the hell is going on test_str.py segfaulted python under wine due to HAVE_SNPRINTF not being defined - but that's irrelevant to this issue likewise ignore the modification to setup.py regarding the advice to "seek out and understand the cause", i have to say that i much prefer to ... how can i put this best... @BEGIN CAVEAT THE FOLLOWING STATEMENTS ARE MADE WITH ABSOLUTELY NO INTENTION TO CAUSE OFFENSE DO NOT TAKE THIS PERSONALLY IN ANY WAY DO NOT TAKE IT AS A DELIBERATE INTENT TO OFFEND, CAUSE OFFENSE, CRITICISE OR OTHERWISE INDICATE MALICIOUS OR HOSTILE INTENT being absolutely honest: i genuinely do not care about "the cause". what i care about is "working". "does it work if this code is moved? yes." "does it work if the code is not moved? no". does it _matter_ if the "cause" is identified? no. will someone else, possibly in the future, accidentally encounter or deliberately and actively seek out the "cause"? possibly. so - many many apologies for saying this, but i have much better and more interesting and valuable things to be doing with my time than _finding out_ why moving specific bits of code "makes things works". yes it would be nice to know... but i don't care!! because, most importantly, me _knowing_ makes absolutely -all difference to the outcome of whether "it will work" or not. so, on balance, i'd rather spend my time finding out the additional code-moving and code-improving required to debug the additional bug where "python.exe -i" will give me a prompt but "python.exe" with no arguments will not (and hangs). @END CAVEAT gabriel, hi, debugging python.exe under msys under wine under linux is _really_ tricky. * gdb.exe under msys under wine under linux not only segfaults on exit but also refuses to fork() in order to spawn the process to be debugged! * strace obviously cannot be used _inside_ msys / wine * strace _outside_ - on the /usr/bin/wine process - often interferes with the processes it is tracking, causing them to run out of resources and also to fail to start up. * gdb cannot be attached from _outside_ of wine (/usr/bin/winegdb) to an internal process. fortunately, segfaults inside wine result in quite a good stacktrace report, including line numbers and filenames inside python, but in this case it's "hanging" - and there's something _really_ weird going on with the stdin, stdout and stderr. overall, then, the payoff in time invested in "understanding" what is going on by using non-standard and laborious debugging techniques is extremely small. small enough so that, i am very very sorry to say, i'm not going to put any further time into this _other_ than to _actually_ fix bugs, rather than "understand" bugs. it's a development technique that has saved me _vast_ amounts of time. i never worry about "why" - i just "get on with it". ___ Python tracker <http://bugs.python.org/issue4956> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
Luke Kenneth Casson Leighton added the comment: here's a clue: $ ./python.exe -i Python 2.5.2 (r252:60911, Jan 16 2009, 10:34:33) [gcc] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> >>> exit() close failed: [Errno 0] Success $ ___ Python tracker <http://bugs.python.org/issue4956> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
Luke Kenneth Casson Leighton added the comment: here's another clue: $ ./python.exe stdin_is_interactive: 0 ___ Python tracker <http://bugs.python.org/issue4956> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
Luke Kenneth Casson Leighton added the comment: here's an updated version, without the cruft. this has a workaround for the problem of stdin being seen as not a tty (!) until _after_ Py_Initialize() is run. Added file: http://bugs.python.org/file12763/x ___ Python tracker <http://bugs.python.org/issue4956> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton added the comment: martin, hi, thanks for responding. * graminit and configure were removed because they are built automatically. no project should ever include auto-generated files so i assumed that it would be reasonable to remove them from the python_2.5.2 "original" git commit that i did, in order to produce the diff. on a build, graminit got _replaced_ with one that had ^M after eery siiingle line. so - if graminit and configure _are_ in the main python source tree, it's a serious mistake that should be rectified _immediately_. ... but i doubt that, and so graminit and configure "appearing" to be "removed" can be ignored. * regarding your comment that compiling python under msys under wine is a "minority platform", i believe that that is also a serious assumption. the reason why it's a minority platform is because... THERE WASN'T ANY CHOICE. i.e. msys and wine simply have not been good enough - and certainly not _demonstrated_ as being "good enough" - which this patch shows that they now most definitely are - to _have_ any choice about whether python should be compiled with purely free software tools. instead of depending on some ing proprietary piece of double- operating system _and_ the development IDE it walked in on. sorry about that - just to emphasise how distasteful i find it to be _forced_ to use proprietary software, and i'm not the only person. basically, it should be pretty clear that now that python _can_ be compiled for win32 using an entirely free-software platform, the proprietary build chain should be absolutely dropped like a red-hot stone. ... but regarding "minority platform"? that's really quite funny and ironic. it was a _non-existent_ platform until about... yesterday :) ___ Python tracker <http://bugs.python.org/issue4954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton added the comment: hi amaury, thanks for responding. > Is Msys+Mingw32 (running on a regular Windows) an interesting > configuration to support? [wine+]msys+mingw32 is used to _build_ python - not depend on it. [wine+]msys+mingw32 _replaces_ the proprietary build toolchain MSVC. clarification: * in the case of #3871, msys+mingw32 replaces MSVC. * in the case of #4954, wine+msys+mingw32 replaces MSVC _and_ windows but in either case, you end up with a complete build of python.exe, libpython2.5.dll and modules that is perfectly well capable of running under both wine _and_ native windows... ... WITHOUT requiring, in any way shape or form, EITHER msys OR mingw32. in other words, it's a big damn deal. no more proprietary dependence. ... let me put it this way, martin: if i told richard stallman that you said that "msys+mingw32 was a minority platform" he'd have a fit!! :) > The build tools are similar to the ones used by cygwin, except that the > C runtime is msvcrt. ys sort-of - but if you do s/#ifdef __CYGWIN__/#if defined (__CYGWIN__) || defined(__MINGW32__) it all goes _horribly_ wrong :) you actually have to do s/#ifdef _MSC_VER/#if defined(_MSC_VER) || defined(__MINGW32__) because _MSC_VER is used alll over the place to detect and indicate a win32 build (as separate and distinct from a cygwin build). ___ Python tracker <http://bugs.python.org/issue4954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton added the comment: updated patch - also removes quotes removal quotes of graminit and configure so that martin is happier :) also included is an updated version of #4956 as it's an essential integral part of compiling and using python.exe under msys that it actually WORK! :) Added file: http://bugs.python.org/file12764/x ___ Python tracker <http://bugs.python.org/issue4954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Changes by Luke Kenneth Casson Leighton : Removed file: http://bugs.python.org/file12755/f ___ Python tracker <http://bugs.python.org/issue4954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4956] Py_Initialize needs to be done before file load (on msys+wine)
Changes by Luke Kenneth Casson Leighton : Removed file: http://bugs.python.org/file12758/f ___ Python tracker <http://bugs.python.org/issue4956> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton added the comment: roumen, hi, i'm interested in collaborating with you to get python compiled under wine (running msys+mingw32 under wine, on linux). #4954 incorporates much of your work, and takes a slightly different direction for the configure setup - the time taken to complete configure under wine is intolerable (3 hours). also i have found that by setting PATH=%PATH%;c:/mingw/bin in the environment vars, the python.exe that's produced can successfully be used to run setup.py build. ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton added the comment: > Please trust that Python puts generated files into the repository for > good reasons. i can respect that :) for no reason other than if somone says "please trust", i do :) ___ Python tracker <http://bugs.python.org/issue4954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton added the comment: > So what CRT do you link with? Is it msvcrt? Which version? i was _just_ beginning to wonder about that, after i saw rpetrov's comments about MSCVER stuff. http://www.mingw.org/wiki/SpecsFileHOWTO aww, _frick_. :) well... it's _going_ to be msvcr80. why don't mingw ship with a pre-prepared msvcr80 specfile?? *sigh*. will get back to you on that one - it may make a difference on the regression tests (250 passed, 12 failed, 8 skpped). ___ Python tracker <http://bugs.python.org/issue4954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton added the comment: > It is certainly desirable to be able to build extension modules > with this configuration; yeah, and the nice thing is - it works, too! :) > AFAIU, distutils already supports that case. not without modification, it doesn't: #3871 adds "proper" mingw32 compiler detection and link options, such as support for dll.a which isn't auto-detected (but is on cygwin) etc. etc. > Whether or not it is desirable to be build Python from > source in this configuration, I don't know - most people that > want to build with mingw seem to be using the Python binaries > available from python.org, or from ActiveState. i tried that a few months ago. 1) there is no .tgz for python-win32 so i was forced to install from a binary package 2) there is no .exe so i was forced to install from msi, a proprietary installer - which as a free software developer, i have issues with, but i tried it anyway. 3) msi installed, thanks to winetricks, but segfaulted and borked. as i didn't really want to use it, i wasn't that unhappy. 4) the msi turns out to be understood by the free software cabextract package. but... the filenames are all borked and mangled. at that point, i decided i'd had enough: i wasn't going to go through 100 files looking for the one that _might_ be the python25.lib implib, plus other files that i'd need to do a non-proprietary-dependent build of python software. > I'm not sure > whether mingw is capable of building Python correctly, with > assembly manifests and all. python setup.py build seems quite happy: rpetrov added .S to the compile-extensions and happily compiled win32.S in libffi with it. the only slight issue there is that the assembly file is incompatible with MSVC and so it borked (not at build time, unfortunately - at runtime). there's been a gcc bugreport raised, to get interoperability back (urk). GCC issue #36834. ___ Python tracker <http://bugs.python.org/issue4954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton added the comment: yaay! here's the regression test log, including some loovely wine segfaults :) summary: 250 tests OK. 12 tests failed: test_builtin test_cpickle test_file test_gzip test_locale test_mailbox test_os test_pep277 test_socket test_unicode_file test_xpickle test_zipfile 60 tests skipped: 8 skips unexpected on win32: test_bz2 test_cProfile test_bsddb test_profile test_tcl test_sundry test_sqlite test_winsound not baaad :) Added file: http://bugs.python.org/file12765/regressiontest.log ___ Python tracker <http://bugs.python.org/issue4954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton added the comment: http://www.winehq.org/pipermail/wine-users/2006-May/021624.html _drat_. a rebuild of wine, adding a workaround to cope with lack of support for msvcrt80 xml-based process files, is required, commenting out a couple of functions from kernel32! euuw :) so - that's going to delay things somewhat. i'll test with msvcr71, anyway, for the time-being, see if that is any better than msvcrt (default). ___ Python tracker <http://bugs.python.org/issue4954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton added the comment: roumen, hi, can you add: BASECFLAGS="-mthreads $BASECFLAGS" LDFLAGS="-mthreads $LDFLAGS" when compiling with threads, and... a second request: _block_ people from compiling without mthreads, because there's a bug in wine's msvcrt _filbuf routine where it doesn't perform CRLF (at all) and it should. http://bugs.winehq.org/show_bug.cgi?id=16970 ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Luke Kenneth Casson Leighton added the comment: roumen, hi, can you add: BASECFLAGS="-mthreads $BASECFLAGS" LDFLAGS="-mthreads $LDFLAGS" when compiling with threads, and... a second request: _block_ people from compiling without mthreads, because there's a bug in wine's msvcrt _filbuf routine where it doesn't perform CRLF (at all) and it should. http://bugs.winehq.org/show_bug.cgi?id=16970 ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4977] test_maxint64 fails on 32-bit systems due to assumption that 64-bit fits into "long"
New submission from Luke Kenneth Casson Leighton :
the assumption is made that the result will fit into a PyInt.
obviously, on a 32-bit system, where SIZEOF_LONG is 4 bytes,
that ain't happening.
a complex test would be something like this:
if len <= 9: it's an int, definitely.
if len > 10: it's a long, definitely.
if len == 10, and first char is a "-", it's an int, definitely
if len == 10, and first char is 5,6,7,8,9, it's a long, definitely.
if len == 10, and first char is 0,1,2,3, it's an int, definitely.
if len == 10, and first char is 4, it _might_ be a long, but it might
also be an int, so... uh... let's assume it's a long!
and you know what? that for a game of soldiers: just use
"if len >= 10" assume it's a long :)
diff --git a/Modules/cPickle.c b/Modules/cPickle.c
index 537276c..e56f8e5 100644
--- a/Modules/cPickle.c
+++ b/Modules/cPickle.c
@@ -3143,7 +3143,15 @@ load_int(Unpicklerobject *self)
errno = 0;
l = strtol(s, &endptr, 0);
- if (errno || (*endptr != '\n') || (endptr[1] != '\0')) {
+ if (errno || (*endptr != '\n') || (endptr[1] != '\0')
+#if SIZEOF_LONG == 4
+/* integers of 10 chars or over could be bigger than 32-bit.
+ * just keep it simple: 10 or more chars, it goes into
+ * a PyLong.
+ */
+|| (len >= 10)
+#endif
+ ) {
/* Hm, maybe we've got something long. Let's try reading
it as a Python long object. */
errno = 0;
--
components: Build
messages: 80052
nosy: lkcl
severity: normal
status: open
title: test_maxint64 fails on 32-bit systems due to assumption that 64-bit fits
into "long"
versions: Python 2.5
___
Python tracker
<http://bugs.python.org/issue4977>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Luke Kenneth Casson Leighton added the comment: workarounds for a couple of wine bugs, also includes e.g. #4977 64-bit assumptions on 32-bit systems. Added file: http://bugs.python.org/file12780/f ___ Python tracker <http://bugs.python.org/issue4954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4954] native build of python win32 using msys under wine.
Changes by Luke Kenneth Casson Leighton : Removed file: http://bugs.python.org/file12764/x ___ Python tracker <http://bugs.python.org/issue4954> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
