Graham Dumpleton added the comment:
The workaround of using:
#if defined(WIN32) && PY_MAJOR_VERSION >= 3
_wputenv(L"PYTHONIOENCODING=cp1252:backslashreplace");
#endif
Py_Initialize();
gets around the crash on startup.
I haven't done sufficient t
Graham Dumpleton added the comment:
Python should be as robust as possible and thus should be fixed, but I am
happy with using the workaround so if this is more a question of what
priority to mark this, I wouldn't see it as being u
New submission from Graham Dumpleton :
In multiprocessing.process it contains the code:
def _bootstrap(self):
if sys.stdin is not None:
try:
os.close(sys.stdin.fileno())
except (OSError, ValueError
Graham Dumpleton added the comment:
Worth noting is that Python documentation in:
http://docs.python.org/library/stdtypes.html
says:
"""
file.fileno()
Return the integer “file descriptor” that is used by the underlying
implementation to request I/O operations from the operati
Graham Dumpleton added the comment:
Nick, there is no main module in the same way there is when using the Python
command line. Ie., there is no module that has __name__ being __main__. The
closest thing is the WSGI script file which holds the application object for
the WSGI application
Graham Dumpleton added the comment:
How is this going to deal with cyclical imports where different threads could
import at the same time different modules within that cycle? I need to look
through the proposed patch and work out exactly what it does, but am concerned
about whether this
Graham Dumpleton added the comment:
The actual reported problem was likely because of known issues with running
subversion Python wrappers in a sub interpreter.
The rest of the conversation was for a completely different issue which relates
to mod_python not using thread APIs in Python in
Graham Dumpleton added the comment:
@surajd Why aren't you using the Python S2I builders for OpenShift?
When you run anything under OpenShift, it will assign your project a UID which
any containers are forced to run under. The OpenShift containers include a
mechanism using a package
Graham Dumpleton added the comment:
Importing the cgi module the first time even in Python 2.X was always very
expensive. I would suggest you redo the test using timing done inside of the
script after modules have been imported so as to properly separate module
import time in both cases from
Graham Dumpleton added the comment:
Whoops. Missed the quoting.
--
___
Python tracker
<http://bugs.python.org/issue18020>
___
___
Python-bugs-list mailin
Changes by Graham Dumpleton :
--
nosy: +grahamd
___
Python tracker
<http://bugs.python.org/issue10496>
___
___
Python-bugs-list mailing list
Unsubscribe:
Graham Dumpleton added the comment:
That GC happens on an object in the wrong interpreter in this case is the
problem as it can result in used code execution against the wrong interpreter
context.
If you are saying this can happen anytime in the life of a sub interpreter and
not just in this
Graham Dumpleton added the comment:
If this issue with GC can't be addressed and sub interpreters isolated better,
then there is no point pursing then the idea that has been raised at the
language summit of giving each sub interpreter its own GIL and then provide
mechanisms to allow
Graham Dumpleton added the comment:
Right now mod_wsgi is the main user of sub interpreters. I wasn't even aware of
this issue until Jesse found it. Thus in 7+ years, it never presented a problem
in practice, possibly because in mod_wsgi sub interpreters are only ever
destroyed on pr
Changes by Graham Dumpleton :
--
nosy: +grahamd
___
Python tracker
<http://bugs.python.org/issue23990>
___
___
Python-bugs-list mailing list
Unsubscribe:
Graham Dumpleton added the comment:
Your code should be written as:
res = """\
e:
{}
pi:
{}
qs:
{}
""".format(
pprint.pformat(e),
urllib.parse.unquote(e['PATH_INFO'].encode('Latin-1').decode('UTF-8')),
Graham Dumpleton added the comment:
There does appear to be something wrong with wsgiref, because with that
rewritten code you should for:
curl http://127.0.0.1:8000/тест
get:
pi:
/тест
qs:
{}
and for:
curl http://127.0.0.1:8000/?a=тест
get:
pi:
/
qs:
{'a': ['тест']}
Graham Dumpleton added the comment:
As I commented on Issue 26808, it actually looks to me like the QUERY_STRING is
processed fine and it is actually PATH_INFO that is not. I am confused at this
point. I hate dealing with these WSGI level details now
Graham Dumpleton added the comment:
This gets even weirder.
Gunicorn behaves same as wsgiref.
However, it turns out they both only show the unexpected result if using curl.
If you use safari they are both fine.
Waitress blows up altogether on it with an exception when you use curl as
client
Graham Dumpleton added the comment:
What I get in Apache for:
http://127.0.0.1:8000/a=тест
in Safari browser is:
'REQUEST_URI': '/a=%D1%82%D0%B5%D1%81%D1%82',
'PATH_INFO': '/a=\xc3\x91\\x82\xc3\x90\xc2\xb5\xc3\x91\\x81\xc3\x91\\x82',
Where as for cur
Graham Dumpleton added the comment:
Double back slashes would possibly be an artefact of the some mess that happens
when logging out through the Apache error log.
--
___
Python tracker
<http://bugs.python.org/issue16
Graham Dumpleton added the comment:
If someone is going to try and do anything in the area of better proxy object
support, I hope you will also look at all the work I have done on that before
for wrapt (https://github.com/GrahamDumpleton/wrapt).
Two related issue this has already found are
Graham Dumpleton added the comment:
I always use PyImport_GetModuleDict(). So long as that isn't going away I
should be good.
--
___
Python tracker
<http://bugs.python.org/is
101 - 123 of 123 matches
Mail list logo
