[issue10231] SimpleHTTPRequestHandler directory bugs
Hallvard B Furuseth <h.b.furus...@usit.uio.no> added the comment: On 26/11/17 04:59, Martin Panter wrote: > That leaves the fourth complaint, which I don’t understand: ‘translate_path() > does not handle initial "."/".." on non-Posix systems’. > > As far as I know, in 2010 (and still in 2017) the only non-Posix system > Python supported was Windows. But Windows has os.curdir = "." and os.pardir = > "..", just like Posix. os.macpath has ":" and "::". I don't remember if that's what I was thinking though. Maybe just "non-posixpath.py". A generic problem - you have to think about each os.path implementation to see if the translate_path() is valid. If you someday add support for another OS, that can break a working translate_path(). My proposed code would fix that, at least for that particular code. > There is a quirk where requests like “GET .” and “GET ../path” will retain > the dots after passing through “posixpath.normpath”. If there was a platform > where a single or double dot was a legal file or directory name, the server > will access the corresponding file or directory in these cases. But this does > not seem like a problem. More generally, translate_path() ought to escape characters and character combinations which have special meaning in the filesystem. But that can be hairy, as the *url2path.py modules demonstrate, and it would break compatibility with people's existing directory structures. And with ospath->URL transation elsewhere, I'm sure. -- status: pending -> open ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10133] multiprocessing: conn_recv_string() broken error handling
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Richard Oudkerk rep...@bugs.python.org wrote: Thanks for the patch, I have applied it. (I don't think there was a problem with the promotion rules because res was a never converted to UINT32.) True now that res is a Py_ssize_t. It was int when I wrote the patch. Hallvard -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10231] SimpleHTTPRequestHandler directory bugs
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Senthil Kumaran writes: I have doubts on the validity of this bug itself. - First is, query and fragment are usually for the file being served from the webserver, not on the directories. If there are characters such as '?' and '#' in the directory names, which may get featured in the path, then those should be quoted in the request. So foo/dir?baz is wrong where as foo/dir%3Fbaz it the correct request. That's backwards. Start with the URL spec (RFC 3986), not with thinking of filesystem paths. If '?' or '#' do occur in the URL, they are not part of the path. That is the case this bug report is about. That's because it reserves these characters for query and fragment. So yes, the if filesystem path contains '?' or '#', these must be escaped in the URL. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Éric Araujo writes: That's fair enough. :) Do you want to close this feature request then? Me? No. I just figured that after all this arguing, I should mention that closing it as out of scope is not something I'll be difficult about. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10458] 2.7 += re.ASCII
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: Could Python 2.7 get a dummy re.ASCII = re.A flag, for source code compatibility with 3.2? -- components: Regular Expressions messages: 121520 nosy: hfuru priority: normal severity: normal status: open title: 2.7 += re.ASCII type: feature request versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10458 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10350] errno is read too late
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Terry J. Reedy writes: There is one relocation of memory freeing Modules/timemodule.c does '#if,if(..errno..)' after PyMem_Free(outbuf), which can overwrite the desired errno. Instead of reading errno into a temporary, I moved the free into both branches taken by the #if,if(). and the additions of +if (res = 0) +break; which I cannot evaluate. errno is only needed after an error., so I moved 'res 0' out of the 'while'. if (res == MP_EXCEPTION_HAS_BEEN_SET) break; } while (res 0 errno == EINTR !PyErr_CheckSignals()); -- if (res == MP_EXCEPTION_HAS_BEEN_SET) break; if (! (res 0)) break; } while (errno == EINTR !PyErr_CheckSignals()); -- if (res = 0) break; err = errno; if (res == MP_EXCEPTION_HAS_BEEN_SET) break; } while (err == EINTR !PyErr_CheckSignals()); -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10350 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Martin v. Löwis writes: As this code is in a Python 2.x block: why does this change cause problems to you? You are supposed to run the 2to3 result in Python 3, and this conversion result will run correctly in Python 3. As I've explained, and as the if-statement and the associated comment expresses, that piece of code is intended to work with both Python 2 and 3. 2to3 turns it into code which would break on Python 2. I've explained why I'd run 2to3 on such code, and thus why it'd be convenient if I could ask 2to3 to leave such code alone. So I requested this feature. I don't know exactly how I'm supposed to use 2to3. If you are its inventor, you do. Otherwise it may also be supposed to suit other workflows than yours. Ok, I can propose two different spellings of this without any macro processor: (...) Both your examples fit my request perfectly. Pieces of code which I presume are correct for both Python 2 and 3, and 2to3 break them for both Python versions. With my feature, the code would keep working with both. However, it is true that there are other cases where I'd like to shut up 2to3 but where my suggested solution would not be convenient to use. I am after all requesting a mere convenience feature, and aimed for something I hoped would be a simple matter to implement. I never imagined that merely explaining it would grow into such a discussion. Bobby, thanks for the sa2to3 reference. Doesn't quite do what I wanted, but looks useful and might also be a good starting point for what I did ask for. Hopefully I won't need to understand too much 2to3 code first... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Hallvard B Furuseth writes: Martin v. Löwis writes: Ok, I can propose two different spellings of this without any macro processor: (...) Both your examples fit my request perfectly. Pieces of code which I presume are correct for both Python 2 and 3, (...) Sorry, ignore that. I saw you doing what I would be doing, not what you were doing... Not example A. And Example B looks (to me) like it is intended to work unmodified for both Python 2 and 3, but doesn't. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Éric Araujo writes: I think 2to3 is designed to take 2.x code and turn it into 3.x code. Codebases using tricks and hacks to support both 2.x and 3.x (like the example you linked to) cannot be handled by 2to3. That's fair enough. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10359] ISO C cleanup
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: STINNER Victor writes: Python-ast.c: why do you move req_name and req_type outside PyAST_obj2mod()? Eh, in case I've managed to be sufficiently unclear: The reason I modified it at all was because the initialization is not valid in C90, only in C99. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10359 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Martin v. Löwis writes: And I still don't understand the rationale for this request. Can you please post an example Python module that has this markup you are asking for, so I can show you how to achieve what you want without the markup? Eh. I thought you said you did understand. But here is one: http://folk.uio.no/hbf/ZipHTTPServer.py -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10308] Modules/getpath.c bugs
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: STINNER Victor writes: The following change is useless, it cannot overflow: -if (n + k MAXPATHLEN) +if (k MAXPATHLEN - n) k = MAXPATHLEN - n; n and k maximum values are MAXPATHLEN (and the maximum value of MAXPATHLEN is 4096), (...) OK. I could only tell that for n, not for k. But even so it would certainly be an unlikely overflow. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10308 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10325] PY_LLONG_MAX co - preprocessor constants or not?
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: No, PY_LLONG_MAX lacks a paren. Found by the revolutionary method of actually testing it (made the previous branches #if 0's). bugs.python.org is not responding, but here's what I'm using now: Index: Include/pyport.h === --- Include/pyport.h(revision 86319) +++ Include/pyport.h(working copy) @@ -62,15 +62,20 @@ #define PY_LLONG_MAX LLONG_MAX #define PY_ULLONG_MAX ULLONG_MAX #elif defined(__LONG_LONG_MAX__) -/* Otherwise, if GCC has a builtin define, use that. */ +/* Otherwise, if GCC has a builtin define, use that. (Definition of + * PY_LLONG_MIN assumes two's complement with no trap representation.) */ #define PY_LLONG_MAX __LONG_LONG_MAX__ -#define PY_LLONG_MIN (-PY_LLONG_MAX-1) -#define PY_ULLONG_MAX (__LONG_LONG_MAX__*2ULL + 1ULL) -#else -/* Otherwise, rely on two's complement. */ -#define PY_ULLONG_MAX (~0ULL) -#define PY_LLONG_MAX ((long long)(PY_ULLONG_MAX1)) -#define PY_LLONG_MIN (-PY_LLONG_MAX-1) +#define PY_LLONG_MIN (-PY_LLONG_MAX - 1) +#define PY_ULLONG_MAX (PY_LLONG_MAX * Py_ULL(2) + 1) +#elif defined(SIZEOF_LONG_LONG) +/* Otherwise compute from SIZEOF_LONG_LONG, assuming two's complement, no + padding bits, and no trap representation. Note: PY_ULLONG_MAX was + previously #defined as (~0ULL) here; but that'll give the wrong value in a + preprocessor expression on systems where long long != intmax_t. */ +#define PY_LLONG_MAX\ +(1 + 2 * ((Py_LL(1) (CHAR_BIT * SIZEOF_LONG_LONG - 2)) - 1)) +#define PY_LLONG_MIN (-PY_LLONG_MAX - 1) +#define PY_ULLONG_MAX (PY_LLONG_MAX * Py_ULL(2) + 1) #endif /* LLONG_MAX */ #endif #endif /* HAVE_LONG_LONG */ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10325 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10312] intcatcher() can deadlock
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Sorry, my patch is useless if the OS calls the handler with the signal blocked. It should also unblock the signal before doing anything which can do FILE* operations. And set the handler again? Or just leave the next signal to abort the process? I dunno... Anyway, if you don't do that, just apply the save/restore of errno. Drop the 'if (errno != save_errno)' before restoring, that bit of paranoia was turned down in Issue10311. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10359] ISO C cleanup
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: ,AIric Araujo writes: By the way, do these changes actually fix errors or are they just cleanups and pedantic (not a slight) fixes? I've used compilers where they'd be compile errors, though I found them just with gcc -pedantic in an idle moment. If the latter, I think they won�t go into stable branches. Not until someone has better time anyway... About the .zip, it's 3 files (diff against python 3, 2, and both), I'll upload them as an ascii file with '#'s between when bugs.python.org responds again. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10359 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10359] ISO C cleanup
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment:
STINNER Victor writes:
Python-ast.c: why do you move req_name and req_type outside PyAST_obj2mod()?
Because there's no need to initialize the arrays each time PyAST_obj2mod
is called. C90-friendly code inside PyAST_obj2mod would be
PyAST_obj2mod(PyObject* ast, PyArena* arena, int mode)
{
mod_ty res;
static char *const req_name[] = {Module, Expression, Interactive};
PyObject *req_type[];
req_type[0] = (PyObject*)Module_type;
req_type[1] = (PyObject*)Expression_type;
req_type[2] = (PyObject*)Interactive_type;
...
}
which is what the current code actually executes.
(I moved req_name to keep it next to req_type in the code.)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10359
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10359] ISO C cleanup
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Hallvard B Furuseth writes: (...) which is what the current code actually executes. Er, I mean, that's what it does with req_type. The 'static' for req_name is an optimization of the current code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10359 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9873] urllib.parse: Allow bytes in some APIs that use string literals internally
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: urlunparse(url or params = bytes object) produces a result with the repr of the bytes object if params is set. urllib.parse.urlunparse(['http', 'host', '/dir', b'params', '', '']) -- http://host/dir;b'params' That's confusing since urllib/parse.py goes to a lot of trouble to support both bytes and str. Simplest fix is to only accept str: Index: Lib/urllib/parse.py @@ -219,5 +219,5 @@ def urlunparse(components): scheme, netloc, url, params, query, fragment = components if params: -url = %s;%s % (url, params) +url = ';'.join((url, params)) return urlunsplit((scheme, netloc, url, query, fragment)) Some people at comp.lang.python tell me code shouldn't anyway do str() just in case it is needed like urllib does, not that I can make much sense of that discussion. (Subject: harmful str(bytes)). BTW, the str vs bytes code doesn't have to be quite as painful as in urllib.parse. Here is a patch which just rearranges and factors out some code. http://bugs.python.org/file19525/parse.diff -- nosy: +hfuru ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Hi, I'm back... I've been reading your last message a few times and I'm not sure what I'm to reconsider. We've had a way of talking past each toerh before, as far as I can remember. I think my request still now translates to: - keep the current behavior by default, - add some option which does not translate certain code blocks, - these code blocks could be the syntax we've already discussed, or something else. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10375] 2to3 print(single argument)
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: Could 2to3 without -p notice more cases of print(single argument), to avoid slapping another () around them? For example: print(2*3) print(, .join(dir)) print(very + long + single + argument) My internal bug detector zooms in on ((foo)) when I read Python code - I'm seeing code where something was apparently left out, maybe an inner comma to make it a tuple. [Copied from Issue10070.] -- components: 2to3 (2.x to 3.0 conversion tool) messages: 120866 nosy: hfuru priority: normal severity: normal status: open title: 2to3 print(single argument) type: behavior versions: Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10375 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue960325] --require feature option for configure/make (fail if building not possible)
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Just for the record, I think you read this a bit too fast before closing: Terry J. Reedy writes: I am closing this as some combination of wrong, inapplicable, out-of-date, and postponed. 1. (...) For bz2, there is This module provides a comprehensive interface for the bz2 compression library. If the library is not there, then the module obviously cannot function. The point of the request was to move that error from runtime to compile time. As a configuration option, not by default, since as you say: 2. I think the current default build process is right for most users. Indeed. 4. This seems to have become pretty much a non-issue. The OP says he has no further concrete interest because It's been a while since I had a computer without these libraries I am suspecting this is pretty much true for everyone who might otherwise care enough to provide a patch. Half right - actually I _would_ still prefer that bit of safety, but OTOH I probably won't be providing a patch anytime soon. (Still, I can always reopen the issue if I do write one.) -- title: --require feature option for configure/make (fail if building not possible) - --require feature option for configure/make (fail if building not possible) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue960325 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10325] PY_LLONG_MAX co - preprocessor constants or not?
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Mark Dickinson writes: Here's a patch (against py3k) incorporating your suggestions. Would you be willing to review? Looks fine to me. (Actually the gcc branch makes the same assumptions as the final branch, but then I expect gcc itself does too.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10325 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10350] errno is read too late
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: errno is sometimes read too late after the error: After another call may have modified it. Here's a patch against py3k. Most of it or a variant applies to 2.7 too, but I haven't really looked at that. I've not looked at math code, where I don't even know what sets errno. There might also be a late errno read at Modules/_ctypes/callproc.c line 794: space[0] = errno;. Does it want the errno from before _ctypes_get_errobj()? I'm unsure what's going on there. Modules/_multiprocessing/semaphore.c doesn't need the patch's extra variable, it can instead be rearranged with the commented-out patch. -- components: None files: late-errno.diff keywords: patch messages: 120719 nosy: hfuru priority: normal severity: normal status: open title: errno is read too late type: behavior versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file19539/late-errno.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10350 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10325] PY_LLONG_MAX co - preprocessor constants or not?
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: I wrote: BTW, do you know of any modern non-Windows platforms that don't define LLONG_MIN and LLONG_MAX? It may well be that the two's complement fallback hasn't been exercised in recent years. Anyting compiled with strict ANSI pre-C99 mode, e.g. gcc -ansi, (...) which also disables 'long long', so such examples are moot. duh. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10325 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10359] ISO C cleanup
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: Here are some ISO C conformance patches, and a minor cleanup I encountered along the way. Lib/distutils/tests/test_config_cmd.py // comment -- /* comment */. Lib/distutils/tests/test_build_ext.py, Objects/weakrefobject.c, Modules/_pickle.c, Modules/_testcapimodule.c, Python/import.c . . . . . . . Remove some invalid ',' and ';'s. Python/Python-ast.c, Modules/arraymodule.c . . . . . Non-constant array initializer. Modules/_csv.c . . . . . . . Slight cleanup. Modules/_ctypes/libffi/src/x86/ffi.c Empty translation unit. TODO when bored, if anyone cares for more pedantic ISO patches: - printf(%p, non-void* pointer): The pointer should be cast to void*. - More // comments - /**/, but mostly in system-specific code so I can't test any patches I make. -- components: None files: iso-c.zip messages: 120742 nosy: hfuru priority: normal severity: normal status: open title: ISO C cleanup type: compile error versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file19544/iso-c.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10359 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10325] PY_LLONG_MAX co - preprocessor constants or not?
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Hallvard B Furuseth writes: Looks fine to me. Hold on.. #elif defined SIZEOF_LONG_LONG would be a bit safer than #else. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10325 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10325] PY_LLONG_MAX co - preprocessor constants or not?
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment:
Mark Dickinson writes:
Thanks for the report; I agree that there's a potential issue here, and
I also think that all these definitions *should* be preprocessor
defines.
Indeed, my suggestion to castify everything for uniformity was silly: My
own PY_TIMEOUT_MAX fix illustrates why that won't promote portability.
It breaks code which #ifdefs between using LONG_MAX and PY_LLONG_MAX.
(Idle question: does C99 require that LONG_MAX and friends are
usable in the preprocessor? ...)
5.2.4.2.1p1: Sizes of integer types limits.h.
Can you suggest a suitable fix for the PY_ULLONG_MAX and PY_LLONG_MAX
defines? (...)
As far as I can tell, PC/pyconfig.h already solves it for Windows.
For pyport.h, since you do #define SIZEOF_LONG_LONG:
#define PY_LLONG_MAX \
(1 + 2 * ((Py_LL(1) (CHAR_BIT*SIZEOF_LONG_LONG-2)) - 1))
#define PY_ULLONG_MAX (PY_LLONG_MAX * 2ULL + 1)
You could check PY_ULLONG_MAX with a compile-time assertion if you want:
#ifndef __cplusplus /* this requires different magic in C++ */
/* Compile-time assertion -- max one per post-preprocessed line */
#define Py_static_assert(expr) Py_static_assert1_(expr, __LINE__)
#define Py_static_assert1_(expr, line) Py_static_assert2_(expr, line)
#define Py_static_assert2_(expr, line) struct Py_static_assert##line { \
int Assert1_[(expr) ? 9 : -9]; int Assert2_: (expr) ? 9 : -9; }
Py_static_assert(PY_ULLONG_MAX == (unsigned long long)-1);
#endif /* __cplusplus */
BTW, do you know of any modern non-Windows platforms that don't define
LLONG_MIN and LLONG_MAX? It may well be that the two's complement
fallback hasn't been exercised in recent years.
Anyting compiled with strict ANSI pre-C99 mode, e.g. gcc -ansi, which
you do have a workaround for. But gcc isn't the only one to be slow in
upgrading to C99.
And unfortunately, even if Python is built without a compiler's
equivalent of -ansi, a user embedding Python might be compiling with it.
Beyond that: No, I know none, but I don't know many platforms anyway.
Incidentally, the two's complement comment is wrong.
It also relies on unsigned long long being widest type with no
padding bits, and -LLONG_MAX-1 not being a trap representation.
Agreed---that comment needs to be better. I think it's fine, though,
for practical purposes to assume an absence of padding bits and no trap
representation; IIRC there are places internally (e.g., in the bitwise
operators section of the 'int' type implementation) that already assume
two's complement + no padding bits + no trap representation.
I expect so, yes. It's easy to find breakage with non-two's complement,
just grep the C code for '~'. I just get peeved when people get this
wrong, then document and promote the errors:)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10325
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10343] urllib.parse problems with bytes vs str
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: urlunparse(url or params = bytes object) produces a result with the repr of the bytes object. urllib.parse.urlunparse(['http', 'host', '/dir', b'params', '', '']) -- http://host/dir;b'params' That's confusing since urllib/parse.py goes to a lot of trouble to support both bytes and str. Simplest fix is to only accept str: Index: Lib/urllib/parse.py @@ -219,5 +219,5 @@ def urlunparse(components): scheme, netloc, url, params, query, fragment = components if params: -url = %s;%s % (url, params) +url = ';'.join((url, params)) return urlunsplit((scheme, netloc, url, query, fragment)) Some people at comp.lang.python tell me code shouldn't anyway do str() just in case it is needed like urllib does, not that I can make much sense of that discussion. (Subject: harmful str(bytes)). BTW, the str vs bytes code doesn't have to be quite as painful as in urllib.parse, I enclose patch which just rearranges and factors out some code. -- components: Library (Lib) files: parse.diff keywords: patch messages: 120647 nosy: hfuru priority: normal severity: normal status: open title: urllib.parse problems with bytes vs str type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file19525/parse.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10325] PY_LLONG_MAX co - preprocessor constants or not?
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: I wrote: #define PY_LLONG_MAX \ (1 + 2 * ((Py_LL(1) (CHAR_BIT*SIZEOF_LONG_LONG-2)) - 1)) #define PY_ULLONG_MAX (PY_LLONG_MAX * 2ULL + 1) Eh, Py_ULL(2). (...) I just get peeved when people get this wrong, then document and promote the errors:) Just to be clear, I'm peeving at the comment, not the code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10325 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10320] printf %qd is nonstandard
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: Modules/_ctypes/callproc.c:PyCArg_repr() uses sprintf(%qd, long long), which is a GNU (and more?) extension. ISO C99 says %lld. Instead, use % PY_FORMAT_LONG_LONG d from pyconfig.h/pyport.h. Kills off #ifdef MS_WIN32 too. If Python must support C libraries that handle %qd but not %lld, configure.in seems the right place. Index: ./Modules/_ctypes/callproc.c @@ -468,8 +468,3 @@ PyCArg_repr(PyCArgObject *self) case 'Q': -sprintf(buffer, -#ifdef MS_WIN32 -cparam '%c' (%I64d), -#else -cparam '%c' (%qd), -#endif +sprintf(buffer, cparam '%c' (% PY_FORMAT_LONG_LONG d), self-tag, self-value.q); pyport.h tests (defined(MS_WIN64) || defined(MS_WINDOWS)) instead of #ifdef MS_WIN32 for when to use %I64d. I assume that's more up to date. -- assignee: theller components: ctypes messages: 120473 nosy: hfuru, theller priority: normal severity: normal status: open title: printf %qd is nonstandard type: behavior versions: Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10320 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10313] Reassure user: test_os BytesWarning is OK
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Antoine Pitrou writes: Hallvard, if you update your py3k working copy, do these warnings disappear? Yes, switching to the svn version shuts them up. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Antoine Pitrou writes: By the way, I'd like to clear out a potential misunderstanding: the function you are patching doesn't call Python signal handlers in itself (those registered using signal.signal()). (...) Good point - I'm talking C signal handlers, not Python signal handlers. If you want to save errno around Python signal handlers themselves, PyErr_CheckSignals must be patched as well. Probably not. I don't know Python's errno conventions, if any, but it's usually a bug to use errno at any distance from the error. The C code near the error can save errno if it wants it later. It can't do that around C signal handlers, since those can get called anywhere. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Antoine Pitrou writes: I think it is extremely unlikely that mutating errno in a signal handler is unsafe (after all, the library functions called from that handler can mutate errno too: that's the whole point of the patch IIUC). Adding some configure machinery for this seems unwarranted to me. Fine by me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10325] PY_LLONG_MAX co - preprocessor constants or not?
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: Include/pyport.h invites potential compile errors with the definitions #define PY_LLONG_MIN LLONG_MIN #define PY_LLONG_MAX LLONG_MAX #define PY_ULLONG_MAX ULLONG_MAX which can fall back to gcc variants or to #else /* Otherwise, rely on two's complement. */ #define PY_ULLONG_MAX (~0ULL) #define PY_LLONG_MAX ((long long)(PY_ULLONG_MAX1)) #define PY_LLONG_MIN (-PY_LLONG_MAX-1) Code developed with the former #definitions might use them in '#if's, and then break when it meets a host where the fallbacks are used. It would be safer if either all the macros and pyconfig variants used casts, or all used predefined constants - from configure if needed. The signed variants would break because '#if's do not accept casts. PY_ULLONG_MAX is more insidious: If it meets a host which supports a type bigger than unsigned long long, then preprocessor arithmetic will happen in that type. ~0ULL in #if statements is then actually the same as ~ULLL or whatever it would be spelled. This one definitely needs a cast to protect from the surprise that preprocessor value != value outside preprocessor. You get the same effect with ~0U vs ~0UL on a 64-bit compiler, and ~0U vs ~0ULL on a C99 compiler: #if (~0U) == (~0ULL) # error oops #endif Incidentally, the two's complement comment is wrong. It also relies on unsigned long long being widest type with no padding bits, and -LLONG_MAX-1 not being a trap representation. ~0ULL is not two's complement since it is unsigned, it works because it has the same result as -1ULL which is defined to have the max value. The PY_LLONG_MIN definitions rely on two's complement. If anyone cared, one could avoid that with #define PY_LLONG_MIN (-PY_LLONG_MAX-(/*two's complement*/(-1LL 3)==3)) Anyway. If they use casts, fix PY_TIMEOUT_MAX in 3.2a3 pythread.h: #define PY_MIN(x, y) ((x) (y) ? (x) : (y)) #define PY_TIMEOUT_MAXTMP instead of PY_TIMEOUT_MAX, and then #ifndef NT_THREADS #define PY_TIMEOUT_MAX PY_TIMEOUT_MAXTMP #else #define PY_TIMEOUT_MAX PY_MIN(Py_LL(0x)*1000, PY_TIMEOUT_MAXTMP) #endif -- components: Interpreter Core messages: 120492 nosy: hfuru priority: normal severity: normal status: open title: PY_LLONG_MAX co - preprocessor constants or not? type: compile error versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10325 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10308] Modules/getpath.c bugs
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: Patches for getpath.c in Python 2.7 and 3.2a3: 2.7 chunk#2: copy_absolute() would use uninitialized data if getcwd() failed. The fix is equivalent to what 3.2a3 does. 3.2a3 chunk#2: search_for_exec_prefix() did 'unsigned value = 0' on the PyUnicode_AsWideChar() result. (The fix just renames n to k of signed type, and moves the variables. An outer uninitialized 'size_t n' is in scope, so renaming the inner n to k leaves 'n=fread()' still a size_t.) Chunk #1, both versions: Fix an unlikely 'n+k' wraparound bug while I'm at it. The code has just checked that MAXPATHLEN-n will not wrap. -- files: getpath.diff keywords: patch messages: 120390 nosy: hfuru priority: normal severity: normal status: open title: Modules/getpath.c bugs type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file19486/getpath.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10308 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: dlmalloc uses mremap() which is undeclared on Linux, needs _GNU_SOURCE. This can break at least on hosts where void* = 64 bits and int (default return type) 32 bits, since some bits in the return type are lost. A minimal patch is: --- Modules/_ctypes/libffi/src/dlmalloc.c +++ Modules/_ctypes/libffi/src/dlmalloc.c @@ -459,2 +459,4 @@ #define MMAP_CLEARS 0 /* WINCE and some others apparently don't clear */ +#elif !defined _GNU_SOURCE +#define _GNU_SOURCE 1 /* mremap() in Linux sys/mman.h */ #endif /* WIN32 */ However the (char*)CALL_MREMAP() cast looks like a broken fix for this, it suppresses a warning instead of fixing it. Maybe you should remove the cast and instead assign CALL_MREMAP() to a void*, to catch any similar trouble in the future. -- components: Extension Modules messages: 120391 nosy: hfuru priority: normal severity: normal status: open title: dlmalloc.c needs _GNU_SOURCE for mremap() type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10309 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10310] signed:1 bitfields rarely make sense
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: In Python 2.7 and 3.2a3, Modules/_io/textio.c uses signed:1 bitfields. They have value -1 or 0 in two's complement, but are not used thus here: gcc complains of bitfield = 1 overflow. If the point was that they are assigned signed values, well, unsigned:1 is promoted to signed int. I also fix a strange (int) cast doing (truncate flag to int) 1. My guess is someone shut up a compiler warning about the above, by cleaning up in the wrong place. I kept a cast in case that's not it, and some compiler would get noisy anyway. There are possibly-signed 1-bit fields Modules/_ctypes/_ctypes_test.c: struct BITS too, but I don't know what that code is for. It does not specify signedness of the bitfields, which (as with char) makes it the compiler's choice. That's usually a bad idea, but maybe that code is for exploring the compiler? -- components: IO files: signed-1-bitfield.diff keywords: patch messages: 120392 nosy: hfuru priority: normal severity: normal status: open title: signed:1 bitfields rarely make sense type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file19487/signed-1-bitfield.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10310 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: Signal handlers that can change errno, must restore it. I enclose a patch for 2.7, 3.2a3/Modules/signalmodule.c which also rearranges the code to make this a bit easier. The patch does if (errno != save_errno) errno = save_errno; instead of just errno = save_errno; in case it's less thread-safe to write than to read errno, which would not surprise me but may be pointless paranoia. I don't know what needs to be done on non-Unix systems, like Windows' WSAError stuff. -- components: Interpreter Core files: signalmodule-errno.diff keywords: patch messages: 120395 nosy: hfuru priority: normal severity: normal status: open title: Signal handlers must preserve errno type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file19488/signalmodule-errno.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10312] intcatcher() can deadlock
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: Parser/intrcheck.c:intcatcher() can do FILE* operations, which can deadlock if the interrupt happens while a FILE* operation on the same FILE holds a mutex for the FILE. I've seen this happen elsewhere. It'd rather be a pity to remove Py_Exit(), so I suggest switch(interrupted++) gets a case 3 or 4: which does _exit(1), and 'interrupted = 0;' is moved there from case 2. Also 'interrupted' should be volatile sig_atomic_t, and the function should save/restore errno as in Issue 10311. BTW, you could use strlen(message) instead of sizeof(message)-1. -- components: Interpreter Core files: intrcheck.diff keywords: patch messages: 120399 nosy: hfuru priority: normal severity: normal status: open title: intcatcher() can deadlock type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file19491/intrcheck.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Parser/intrcheck.c:intcatcher() should do the same. Covered in Issue 10312. Antoine Pitrou writes: This is a good idea IMO. It would be better if you minimized style changes, so that the patch is easier to review. I'm afraid the un-rearranged code would be fairly ugly, so I cleaned up first. Single exit point. Also, is the while loop around write() necessary here? Whoops, I'd forgotten I did that too, it was on my TODO list to check if Python makes it unnecessary by making write restartable. I don't remember if that's possible to ensure on all modern Posixes -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10231] SimpleHTTPRequestHandler directory bugs
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no: -- versions: +Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10133] multiprocessing: conn_recv_string() broken error handling
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no: -- versions: +Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10308] Modules/getpath.c bugs
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no: -- versions: +Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10308 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no: -- versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10309 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10312] intcatcher() can deadlock
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no: -- versions: +Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Amaury Forgeot d'Arc writes: This issue is not really relevant on Windows: - signals are actually run in a new thread specially created. - errno is a thread-local variable; its value is thus local to the signal handler, same for WSAGetLastError(). Nice. Then I suggest a config macro for whether this is needed. Either a test for windows, or an autoconf thing in case some Unixes are equally sensible. (Linux isn't, I checked.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10313] Reassure user: test_os BytesWarning is OK
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no:
A test giving a strange warning can make a poor user nervous. Here's
a minimal patch to calm his nerves. It would be better to only give
the message if python -b (not -bb) is active, but I do not know how.
diff -prU2 Lib/test/test_os.py Lib/test/test_os.py
--- Lib/test/test_os.py
+++ Lib/test/test_os.py
@@ -443,4 +443,7 @@ class EnvironTests(mapping_tests.BasicTe
test_env = {'PATH': os.pathsep.join(test_path)}
+if os.supports_bytes_environ:
+print(This test may give some 'BytesWarning's., file=sys.stderr)
+
saved_environ = os.environ
try:
--
components: Tests
messages: 120407
nosy: hfuru
priority: normal
severity: normal
status: open
title: Reassure user: test_os BytesWarning is OK
type: feature request
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10313
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue960325] --require feature option for configure/make (fail if building not possible)
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Once upon a time, Terry J. Reedy wrote: Hallvard, do you still consider this a live issue? If this general behavior remains, yes. It's been a while since I had a computer without these libraries to test it on. (Which is why I punted and then forgot to answer, sorry.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue960325 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Amaury Forgeot d'Arc writes: OTOH this is really a micro optimization. [this = only saving/restoring errno when needed] True, but practically nothing is officially safe to do in signal handlers, so it's good to avoid code which can be avoided there. If one can be bothered to, that is. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10313] Reassure user: test_os BytesWarning is OK
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: R. David Murray writes: I don't see any bytes warnings when I run test_os with -b or -bb on linux on py3k trunk. (If there were such a warning and it was expected, the fix would be to capture the warning and ignore it.) Under what circumstances do you see this warning? Python 3.2a3, test_os with python -b. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10086] test_sysconfig failure with site-packages
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: ,AC�ric Araujo writes: Attaching a patch with your two suggestions. Added file: http://bugs.python.org/file19264/fix10086.diff Not quite, since I suggested global_path.startswith(os.path.join(base, )) instead of global_path.startswith(base) I should have mentioned, the join appends a directory terminator to base. Not sure if that's the correct way to do it. Anyway, your patch does not catch a similar failure (if this can happen): base= /site global_path = /site-nonsense/... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10086 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10231] SimpleHTTPRequestHandler directory bugs
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no:
SimpleHTTPRequestHandler directory bugs
Running 3.2a3 http/server.py or 2.7 SimpleHTTPServer.py as a script:
* Redirection appends / to the unparsed URL instead of to the
pathname component of the parsed URL: foo/dir?baz = foo/dir?baz/.
* The unparsed URL is also used to check if the URL ends with /.
Thus foo/dir?baz/ gives a directory listing instead of redirecting,
which makes the files relative to foo/ instead of to foo/dir/.
* translate_path(directory/) produces filenames without a final /.
Not sure if that is correct for CGI env['PATH_TRANSLATED']. Anyway:
This means a non-directory file with a final slash is accepted, but
again relative URLs in that file will refer to the wrong absolute URL.
.../foo.html/ + relative URL bar.html - .../foo.html/bar.html.
However if translate_path(...foo/) is changed and you use stat() on
the result, I do not know if all relevant directory operations work
with the final directory separator on all OSes. I seem to remember
getting errors in some OS for stat(dirname/, st) in C.
* translate_path() does not handle initial ./.. on non-Posix systems.
If that's wrong, it can (ignoring other issues listed here) do this:
drop = frozenset((os.curdir, os.pardir, '', '.', '..'))
for ...:
if word not in drop: os.path.join(path, word)
Though it looks a bit quicker to do
words, drop = [], frozenset((os.curdir, os.pardir, '', '.', '..'))
for word in filter(None, path.split('/')):
word = os.path.split(os.path.splitdrive(word)[1])[1]
if word not in drop: words.append(word)
return os.path.join(os.getcwd(), *words)
unless that can somehow produce a different result.
--
components: Library (Lib)
messages: 119899
nosy: hfuru
priority: normal
severity: normal
status: open
title: SimpleHTTPRequestHandler directory bugs
type: behavior
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10231
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10133] conn_recv_string() broken error handling
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: Neither conn_recv_string() nor its callers free *newbuffer on error. The promotion rules break negative 'res' for 64-bit Py_ssize_t in the (ulength = buflength) branch: res = -1 == (UINT32)-1 == Py_ssize_t 0x instead of -1. While I'm writing: The _conn_recvall() calls can be factored out of the if(). This patch applies to both 3.2a3 and 2.7. However, the patched failure cases are untested: I do not know how to test them. It passes make test. -- components: IO files: conn_recv_string_failures.diff keywords: patch messages: 118978 nosy: hfuru priority: normal severity: normal status: open title: conn_recv_string() broken error handling type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file19256/conn_recv_string_failures.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10086] test_sysconfig failure with site-packages
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: It's with 'purelib' because my prefix /site matches /site-packages. This fixes it for me, but maybe you should also assert that global_path.startswith(os.path.join(base, )). --- Lib/test/test_sysconfig.py~ 2010-09-20 +++ Lib/test/test_sysconfig.py 2010-10-14 @@ -278 +278 @@ class TestSysConfig(unittest.TestCase): -self.assertEquals(user_path, global_path.replace(base, user)) +self.assertEquals(user_path, global_path.replace(base, user, 1)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10086 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10086] test_sysconfig failure with site-packages
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: test_sysconfig on Python 3.2a3 fails with AssertionError: '/home/sjef/.local/lib/python3.2/site-packages' != '/home/sjef/.local/lib/python3.2/home/sjef/.local-packages' Python-3.2a3$ ./python Lib/test/regrtest.py -v test_sysconfig == CPython 3.2a3 (r32a3:85355, Oct 13 2010, 07:34:15) [GCC 4.4.3] == Linux-2.6.32-25-generic-x86_64-with-debian-squeeze-sid little-endian == /home/sjef/src/python/Python-3.2a3/build/test_python_17497 [1/1] test_sysconfig test_get_config_h_filename (test.test_sysconfig.TestSysConfig) ... ok test_get_config_vars (test.test_sysconfig.TestSysConfig) ... ok test_get_makefile_filename (test.test_sysconfig.TestSysConfig) ... ok test_get_path (test.test_sysconfig.TestSysConfig) ... ok test_get_path_names (test.test_sysconfig.TestSysConfig) ... ok test_get_paths (test.test_sysconfig.TestSysConfig) ... ok test_get_platform (test.test_sysconfig.TestSysConfig) ... ok test_get_scheme_names (test.test_sysconfig.TestSysConfig) ... ok test_ldshared_value (test.test_sysconfig.TestSysConfig) ... ok test_main (test.test_sysconfig.TestSysConfig) ... ok test_symlink (test.test_sysconfig.TestSysConfig) ... ok test_user_similar (test.test_sysconfig.TestSysConfig) ... FAIL == FAIL: test_user_similar (test.test_sysconfig.TestSysConfig) -- Traceback (most recent call last): File /home/sjef/src/python/Python-3.2a3/Lib/test/test_sysconfig.py, line 278, in test_user_similar self.assertEquals(user_path, global_path.replace(base, user)) AssertionError: '/home/sjef/.local/lib/python3.2/site-packages' != '/home/sjef/.local/lib/python3.2/home/sjef/.local-packages' - /home/sjef/.local/lib/python3.2/site-packages ? ^^ + /home/sjef/.local/lib/python3.2/home/sjef/.local-packages ? + ^ -- Ran 12 tests in 0.145s FAILED (failures=1) test test_sysconfig failed -- Traceback (most recent call last): File /home/sjef/src/python/Python-3.2a3/Lib/test/test_sysconfig.py, line 278, in test_user_similar self.assertEquals(user_path, global_path.replace(base, user)) AssertionError: '/home/sjef/.local/lib/python3.2/site-packages' != '/home/sjef/.local/lib/python3.2/home/sjef/.local-packages' - /home/sjef/.local/lib/python3.2/site-packages ? ^^ + /home/sjef/.local/lib/python3.2/home/sjef/.local-packages ? + ^ 1 test failed: test_sysconfig -- components: Tests messages: 118525 nosy: hfuru priority: normal severity: normal status: open title: test_sysconfig failure with site-packages type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10086 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10086] test_sysconfig failure with site-packages
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: ./configure --prefix=/site on Ubuntu. Unedited site.py. I had Python3.2a2 installed, but removing it did not make the test do anything different. Nor did removing /home/sjef/.local/lib/python3.2, which only contained an empty site-packages/. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10086 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10069] 2to3 crash in fix_urllib.py
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: This line: from urllib import quote as quote_url, urlencode makes 2to3 on Python 3.2a2 crash. At lib2to3/fixes/fix_urllib.py line 124, member = None. -- components: 2to3 (2.x to 3.0 conversion tool) messages: 118410 nosy: hfuru priority: normal severity: normal status: open title: 2to3 crash in fix_urllib.py versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: It would be nice with some official way to tell 2to3, Leave this code chunk alone. This is 2.* code, that is 3.* code: try: # Python 2.6 from urlparse import urlparse, urlunparse except ImportError: # Python 3 from urllib.parse import urlparse, urlunparse Could 2to3 without -p notice more cases of print(single argument), to avoid slapping another () around them? For example: print(2*3) print(, .join(dir)) -- components: 2to3 (2.x to 3.0 conversion tool) messages: 118411 nosy: hfuru priority: normal severity: normal status: open title: 2to3 wishes for already-2to3'ed files type: feature request versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10069] 2to3 crash in fix_urllib.py
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no: -- type: - crash ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Martin v. Löwis writes: Martin v. Löwis mar...@v.loewis.de added the comment: I don't understand. If the code is already Python 3 code, why are you running 2to3 on it? I should have clarified - it's still Python 2 code (maybe 2.7), moving one step at a time towards something which will work on Python 3 as well. Or it's just that I'm handling one issue which 2to3 reports at a time, like modifying str vs bytes vs unicode usage, then I come back and look at another thing 2to3 has to say. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Martin v. Löwis writes: I still don't understand. If it's 2.x code, why do you want to say that it is 3.x code? It works on Python 2. It runs on Python 3 - maybe correctly, or maybe it's not that far along yet. Maybe some files in a package work on Python 3, and others have not yet been updated. If you don't want to run a specific fixer, you can exclude it from the list of fixers. I know. So this request is mostly for convenience, but then so is 2to3 in the first place. print(single argument) would be nice to leave alone in any case though, since there can be other reasons for the (). E.g.: print(very long single argument) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Maybe we need to tackle this from a different angle: can you please specify the feature you are asking for exactly, with any syntax, API, or command line changes that you consider necessary? First, nothing here is necessary, since it's just a request for a convenience. The syntax could be a generalization of the example I gave: whatever: # Python version indented block and whatever: # Python version indented block tell 2to3 The code in block it is expected to only run (or succeed) in Python version. Do not modify it, except it is an error if it is a syntax error under Python 3 so the script won't even run. 'whatever:' can be some if,else,try,except, I don't know what else, and is responsible for making different Python versions do the right thing. Omitting redundant parentheses for print is a separate issue (feel free to open an issue); we should not mix it with this issue (which I still don't understand). OK. But I don't understand what you don't understand... I have some Python 2 files in various stages of transition to be runnable and correct in Python 3, while still working in Python 2. It'd be convenient if the parts that do work under both Python 2 and 3 could be written so that 2to3 would be silent about them, without need for different 2to3 command line options for different .py files. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Another syntax could be attached to if-else and try-except. Given: if ...: block 1 else: block 2 or try: block 1 except ...: block 2 if 2to3 would translate block 1 to block 2 or vise versa, sans whitespace/comment differences, then it does not do so. Instead it assumes the blocks are for running under Python 2 and 3 respectively. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment:
[I got failed issue tracker submission, trying again...]
How about this phrasing: “Make 2to3 fixers not touch code in a
block starting with ’if sys.version = '3'’“
(and hexversion, version_info, you get the idea)?
Right, almost... it doesn't need to be flexible, it only needs to be
documented for 2to3. So it also doesn't need to handle the varions
version variables - if e.g. version_info is easiest for 2to3, it need
only handle that. I've been posting with routine avoidance of testing
versions instead of features (learned from javascript frustration:-)
but that concern was misplaced here.
But it should be if sys.version {either or =} '3':, and it should
not touch the else: block either. Just trust that the programmer has
written correct version's code for each block, and parse one of the
blocks to pick up whatever info 2to3 needs to process the rest of the
python file.
So...
I don't think this can work. You may have to write code like
if sys.version_info = (3,):
try:
some_code()
except Exception, e:
pass
(i.e. not use the as syntax), because it otherwise won't parse on
Python 2. Hence, one has to rely on 2to3 fixing it, even though
it will never be run on Python 2.
I assume it should be if sys.version_info (3,): since that looks
like Python 2 code, and that'll work with the above revised suggestion.
So any scheme of skipping code must be opt-in.
Fair enough, if it's a 2to3 option which to obey whatever skip some
code hack is defined. That's the same 2to3 command line for a lot of
files, instead of different commmand lines for different files.
Unless we're still talking past each other - if the example code will
never run on Python 2 as you say, there's no reason not to fix syntax
problems like the above. It's fixing things like bytes vs str which
takes more thought.
While I now understand what is being requested, I still fail to see
the rationale. In my applications of 2to3, I never look at the generated
code, so it doesn't bother me at all if print gets another pairs of
brackets, or if redundant (but dead) import statements are inserted.
Wow. We live in different mental worlds. It would not have occurred
to me to take the 2to3 output as more than helpful suggestions. Some
to be applied straight (like 'except' syntax), other to maybe apply
but also look closer at nearby code.
Indeed, one of my early 2to3 experiences led to a bug in python 3 code
which I'm now discussing in comp.lang.python. Also my internal bug
detector zooms in on ((foo)) when I read Python code - I'm seeing code
where something was apparently left out, maybe an inner comma to make it
a tuple.
--
Hallvard
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10070
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2921] enable embedding: declare/#define only py* symbols in #includes
Hallvard B Furuseth h.b.furus...@usit.uio.no added the comment: Daniel Diniz writes: Would this break existing code? Source code? Not if you use the PYTHON_NAMESPACE_ONLY trick. Old programs will receive all old definitions in addition to the new autoconf symbols, since they didn't #define PYTHON_NAMESPACE_ONLY. Programs that do #define PYTHON_NAMESPACE_ONLY will lose symbols you can't offer because you couldn't be bothered to make them independent of autoconf. BTW, another reduced API variant would be to throw autoconf-independent symbols out to separate .h files. #include those files from the .h files they come from, and document that programs can #include them instead of Python.h. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2921] enable embedding: declare/#define only py* symbols in #includes
Hallvard B Furuseth [EMAIL PROTECTED] added the comment: Duh, I should of course have said defined(PY_HAVE_ACOSH) and not defined(HAVE_ACOSH), that was the whole point:-) And the puts() should print #define PY_HAVE_WHATEVER 1. Hopefully there are not too many #defines which would need to get corresponding PY_* variants. For that matter, PYTHON_NAMESPACE_ONLY could offer a reduced Python C API - omitting parts it would be cumbersome to get right with only py* symbols. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2921 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2921] enable embedding: declare/#define only py* symbols in #includes
New submission from Hallvard B Furuseth [EMAIL PROTECTED]:
It can be cumbersome to embed Python in a program which also #includes
a config.h from autoconf, because Python's and the program's autoconf
macros may interfere with each other. Assuming it compiles at all,
both could define the same features, sometimes the same way and
sometimes differently. Or one could be compiled with a feature macro
undefined and another with it defined, resulting in binary
incompatibility with the library which was compiled with the macro
undefined.
So one has to do something like: put the Python calls in one set of
files, the calls to the embedding program in another set, and make
them communicate via some glue code.
For this reason, please do not declare/#define symbols other than
those starting with 'py' in the include files that an embedded program
needs. Thus, do not #include at least pyconfig.h, pymath.h and
pyport.h as they are today.
Or to keep backwards compatibility, wrap such definitions in
#ifndef PYTHON_NAMESPACE_ONLY
which an application can #define before #including Python files.
Instead, you can #define/declare symbols that match the current
autoconf symbols but are prefixed with PY_, and make use of those in
#ifdefs in the include files. The files defining this can hopefully
be autogenerated, e.g. generate a .c file like
#include pyconfig.h
int main() {
#ifdef HAVE_WHATEVER
puts(PY_HAVE_WHATEVER);
#endif
...
}
Things like acosh() from pymath.h which you define if the system lacks
it, could become something like this:
#include math.h /* get acosh etc */
...
extern double py_acosh(double); /* always present in python */
#if !defined(PYTHON_NAMESPACE_ONLY) !defined(HAVE_ACOSH)
/* an other package's autoconf might do the same, so hide this
* if requested */
extern double acosh(double);
#endif
#if !defined(PYTHON_NAMESPACE_ONLY) || defined(HAVE_ACOSH)
#define py_acosh acosh /* optimization - hide wrapper function */
#endif
--
components: None
messages: 67078
nosy: hfuru
severity: normal
status: open
title: enable embedding: declare/#define only py* symbols in #includes
type: feature request
versions: Python 2.6
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2921
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
