Graham Dumpleton added the comment:
Did anyone test this fix for case of fork() being called from Python sub
interpreter?
Getting a report of fork() failing in sub interpreters under mod_wsgi that may
be caused by this change. Still investigating.
Specifically throwing up error:
Couldn&#
New submission from Graham Dumpleton :
This is a followup bug report to fix wrong implementation of
_PyGILState_Reinit() introduced by http://bugs.python.org/issue10517.
I don't have a standalone test case yet. Problem occurs under mod_wsgi with
Python 2.7.2 and thus similarly 3.2
Graham Dumpleton added the comment:
Whoops. Missed the error. The fatal error that occurs is:
Fatal Python error: Couldn't create autoTLSkey mapping
--
___
Python tracker
<http://bugs.python.org/is
Graham Dumpleton added the comment:
The PyGILState_Ensure() function is only for when working with the main
interpreter. These external threads are not calling into the main interpreter.
Because they are external threads, calling PyGILState_Ensure() and then
PyGILState_Release() will cause a
Graham Dumpleton added the comment:
True. Doesn't appear to be an issue with Python 3.2.2. Only Python 2.7.2.
I was not aware that the TLS mechanism was changed in Python 3.X so assumed
would also affect it.
So, looks like the change shouldn't have been applied to Python 2.7.
How
Graham Dumpleton added the comment:
Right back at the start it was said:
"""
We haven't agreed whether the randomization should be enabled by default or
disabled by default. IMHO it should be disabled for all releases except for the
upcoming 3.3 release. The env var PYTH
Graham Dumpleton added the comment:
Segmentation fault. The original description explains the problem is
dereferencing of a NULL pointer which has a tendency to invoke such behaviour.
--
___
Python tracker
<http://bugs.python.org/issue6
Graham Dumpleton added the comment:
I wouldn't use mod_python as any guide for how to use sub interpreters as its
usage of sub interpreters and threading in conjunction with them is technically
broken, not following properly the Python C API requirements. It doesn't even
shutdown
Graham Dumpleton added the comment:
Hmmm, I wander if that is related to the workaround I have added in mod_wsgi
recently of:
/*
* Force loading of codecs into interpreter. This has to be
* done as not otherwise done in sub interpreters and if not
* done, code running in
Graham Dumpleton added the comment:
FWIW, keep in mind that cgi.FieldStorage is also quite often used in WSGI
scripts in arbitrary WSGI servers which have got nothing to do with CGI. Having
cgi.FieldStorage muck around with stdout/stderr under WSGI, even where using a
CGI/WSGI bridge, would
Graham Dumpleton added the comment:
Can you please provide an example of what user would do and what changes
existing extension modules would need to make?
When I looked at this exact problem some time back, I worked out that you
probably only need a single new public API function. This
Graham Dumpleton added the comment:
The bulk of use cases is going to be simple callbacks via the same thread that
called out of Python in the first place. Thus ultimately all it is doing is:
Py_BEGIN_ALLOW_THREADS
Call into some foreign C library.
C library wants to do a callback into
Graham Dumpleton added the comment:
As to the comment:
"""IMO we should really promote clean APIs which allow solving the whole
problem, rather than devise an internal hack to try to "improve" things
slightly."""
The reality is that if you force a
Graham Dumpleton added the comment:
Nick, I think you are making the wrong assumption that an external threads will
only ever call into the same interpreter. This is not the case. In mod_wsgi and
mod_python there is a pool of external threads that for distinct HTTP requests,
delegated to a
Graham Dumpleton added the comment:
As has been pointed out to you already in other forums, the correct way of
detecting in a compliant WSGI application that a SSL connection was used is to
check the value of the wsgi.url_scheme variable. If your code does not do this
then it is not a
Graham Dumpleton <[EMAIL PROTECTED]> added the comment:
I know the discussions more or less says this, but I want to add some
additional information.
For the record, the reason that mod_python crashes with 'Invalid thread state
for this thread' when Py_DEBUG is defined in
Graham Dumpleton <[EMAIL PROTECTED]> added the comment:
Franco, you said 'I found that you cannot create additional thread
states against the first interpreter and swap between them w/o this
assertion occurring. ...'
Since the Py_DEBUG check is checking against the simplifie
Graham Dumpleton <[EMAIL PROTECTED]> added the comment:
I do understand.
The initial thread, which is effectively a foreign thread to Python to
begin with, when used to initialise Python, ie., call Py_Initialize(),
is treated in a special way in as much as as a side effect it doe
New submission from Graham Dumpleton <[EMAIL PROTECTED]>:
Somewhere between Python 3.0a3 and Python 3.0b3, a call to PySys_SetObject()
after having used Py_NewInterpreter() to create a sub interpreter causes a
crash. This appears to be due to interp->sysdict being NULL after
Py_NewIn
Graham Dumpleton <[EMAIL PROTECTED]> added the comment:
Sorry, should also mention that this was on MacOS X 10.4 (Tiger).
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Graham Dumpleton <[EMAIL PROTECTED]> added the comment:
Adding the functions as initfunc in module init table is of no use as
they aren't invoked when creating a sub interpreter.
One thing that does appear to work, although no idea of whether it is
correct way to solve pro
Graham Dumpleton <[EMAIL PROTECTED]> added the comment:
Argh. Personally I like to provide context diff's but more often than not
get abused for providing them over a unified diff. Was in a hurry this
time as had only a couple of minutes of battery life left on the laptop,
so qui
Changes by Graham Dumpleton <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11660/pythonrun.c.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Graham Dumpleton <[EMAIL PROTECTED]> added the comment:
Unified diff now attached.
Added file: http://bugs.python.org/file11661/pythonrun.c.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Graham Dumpleton :
Back in time, the function PyImport_ImportModuleNoBlock() was introduced and
used in modules such as the time module to supposedly avoid deadlocks when
using threads. It may well have solved that problem, but only served to cause
other problems.
To
New submission from Graham Dumpleton <[EMAIL PROTECTED]>:
In Python 3.0 the atexit module was translated from Python code to C code.
Prior to Python 3.0, because it was implemented at C code level, the list of
callbacks was specific to each sub interpreter. In Python 3.0 that appears
Graham Dumpleton <[EMAIL PROTECTED]> added the comment:
I wouldn't be concerned about mod_python as likelihood that it will be ported
is
very low and even if it was it would be a long long way in the future. There is
too
much in mod_python itself unrelated to Python 3.0 that
New submission from Graham Dumpleton <[EMAIL PROTECTED]>:
Because the readline module uses PyGILState_Ensure() to facilitate triggering
callbacks into Python code, this would make the ability to use the hook
functions incompatible with use in sub interpreters.
If this is the case, the
Graham Dumpleton <[EMAIL PROTECTED]> added the comment:
By visual inspection the intent looks correct, but can't actually test it
until I can checkout Python code from source repository and apply patch as
patch doesn't apply cleanly to 3.0rc1.
With #3723 and #4213 now als
Graham Dumpleton <[EMAIL PROTECTED]> added the comment:
In conjunction with #4213, the attached subinterpreter.patch appears to
fix issue for mod_wsgi.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Graham Dumpleton <[EMAIL PROTECTED]> added the comment:
In conjunction with #3723 and #4213, the attached atexit_modulestate.patch
appears to fix issue for mod_wsgi.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Graham Dumpleton added the comment:
Note that the page:
http://www.wsgi.org/wsgi/Amendments_1.0
contains clarifications for WSGI PEP in respect of Python 3.0. This list
was previously come up with on WEB-SIG list.
As another reference implementation for Python 3.0, you might look at
Graham Dumpleton added the comment:
If making changes in wsgireg.validate, may be worthwhile also fixing up one
area where it isn't strictly correct
according to WSGI PEP.
As per discussion:
http://groups.google.com/group/python-web-sig/browse_frm/thread/b14b862ec4c620c0
the chec
Graham Dumpleton added the comment:
One interesting thing of note that has occurred to me looking at the patch
is that although with Python <3.0 you technically could return a str as
iterable from application, ie., because iteration over str returns str for
each character, the same does
Graham Dumpleton added the comment:
I don't know about the comment "he has far more experience than I do with this
sort of object proxying wizardry". I read what you said and my brain melted. I
am getting too old for this and trying to understand how anything works anymore
Graham Dumpleton added the comment:
Let me try and summarise what I do understand about this.
The existing wrapt code as written and its tests, work fine for Python 2.7 and
3.6-3.11. No special case handling is done in tests related to checking
annotations that I can remember.
The only
Graham Dumpleton added the comment:
My vague recollection was that I identified some time back that partial()
didn't behave correctly regards introspection for some use case I was trying to
apply it to in the wrapt implementation. As a result I ended up creating m
Graham Dumpleton added the comment:
I am still working through this and thinking about implications, but my first
impression is that the functools.partial object should provide an attribute
(property) __signature__ which yields the correct result.
When you think about it, any user who wants
Change by Graham Dumpleton :
--
nosy: +grahamd
___
Python tracker
<https://bugs.python.org/issue46846>
___
___
Python-bugs-list mailing list
Unsubscribe:
Graham Dumpleton added the comment:
It is Django I would worry about and look at closely as they do stuff with
decorators on instance methods that uses partials.
https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/django/utils/decorators.py#L43
```
def
Graham Dumpleton added the comment:
Another example in Django, albeit in a test harness.
*
https://github.com/django/django/blob/7119f40c9881666b6f9b5cf7df09ee1d21cc8344/tests/urlpatterns_reverse/views.py#L65
--
___
Python tracker
<ht
Graham Dumpleton added the comment:
These days I have no idea who is active on Django.
--
___
Python tracker
<https://bugs.python.org/issue46761>
___
___
Pytho
New submission from Graham Dumpleton :
The Python standard library has two effective implementations of helpers for
the ABCMeta class. A C implementation, and a pure Python version which is only
used if the C implementation isn't available (perhaps for PyPy).
* https://github.com/p
Change by Graham Dumpleton :
--
nosy: +grahamd
___
Python tracker
<https://bugs.python.org/issue45319>
___
___
Python-bugs-list mailing list
Unsubscribe:
Graham Dumpleton added the comment:
Too much to grok right now.
There is already a convention for what a decorator wraps. It is __wrapped__.
https://github.com/python/cpython/blob/3405792b024e9c6b70c0d2355c55a23ac84e1e67/Lib/functools.py#L70
Don't use __func__ as that has other de
Graham Dumpleton added the comment:
Just to make few things clear. It isn't mod_wsgi itself that relies on daemon
threads, it is going to be users WSGI applications (or the things they need)
that do.
As a concrete example of things that would stop working are monitoring systems
such a
Graham Dumpleton added the comment:
For the record. Since virtualenv 20.0.0 (or there about) switched to the python
-m venv style virtual environment structure, the C API for embedding when using
a virtual environment is now completely broken on Windows. The same workaround
used on UNIX
Graham Dumpleton added the comment:
What are the intentions with respect to atexit and sub interpreters?
The original report was only about ensuring that the main interpreter doesn't
crash if an atexit function was registered in a sub interpreter. So, was not
expecting a change t
Graham Dumpleton added the comment:
My take on this is that if wanting to interact with a thread from an atexit
callback, you are supposed to call setDaemon(True) on the thread. This is to
ensure that on interpreter shutdown it doesn't try and wait on the thread
completing before getti
Graham Dumpleton added the comment:
Reality is that the way Python behaviour is defined/implemented means that it
will wait for non daemonised threads to complete before exiting.
Sounds like the original code is wrong in not setting it to be daemonised in
the first place and should be
Graham Dumpleton added the comment:
At the moment you have showed some code which is causing you problems and a
vague idea. Until you show how that idea may work in practice it is a bit hard
to judge whether what it does and how it does it is reasonable
Graham Dumpleton added the comment:
I haven't said I am against it. All I have done so far is explain on the
WEB-SIG how mod_wsgi works and how Python currently works and how one would
normally handle this situation by having the thread be daemonised.
As for the proposed solution, whe
Graham Dumpleton added the comment:
Except that calling it at the time of current atexit callbacks wouldn't change
the current behaviour. As quoted in WEB-SIG emails the sequence is:
wait_for_thread_shutdown();
/* The interpreter is still entirely intact at this point, an
New submission from Graham Dumpleton :
When parsing for inline comments, ConfigParser will only check the first
occurrence of the delimiter in the line. If that instance of the delimiter
isn't preceded with a space, it then assumes no comment. This ignores the fact
that there could
New submission from Graham Dumpleton :
The code:
#include
int
main(int argc, char *argv[])
{
FILE *fp = NULL;
PyObject *co = NULL;
struct _node *n = NULL;
const char * filename = "/dev/null";
Py_Initialize();
fprintf(stderr, "START\n");
fp
Graham Dumpleton added the comment:
FWIW, this was occurring on macOS. Not been able to test on other platforms.
--
type: -> crash
___
Python tracker
<https://bugs.python.org/issu
Graham Dumpleton added the comment:
FWIW, that atexit callbacks were not called for sub interpreters ever was a
pain point for mod_wsgi.
What mod_wsgi does is override the destruction sequence so that it will first
go through each sub interpreter when and shutdown threading explicitly, then
New submission from Graham Dumpleton :
This issue was raised first on secur...@python.org. Guido responded that not
sensitive enough to be kept to the list and that okay to log a bug report.
This issue may not warrant any action except perhaps an update to
documentation for the logging module
Graham Dumpleton added the comment:
Just to clarify. One can still tell WSGI applications under mod_wsgi to run in
the main interpreter and in that case modules using PyGILState* do work. By
default though, sub interpreters are used as noted.
The mechanism for forcing use of main interpreter
Graham Dumpleton added the comment:
In both embedded mode and daemon mode of mod_wsgi, albeit how thread pool is
managed is different, there is a fixed number of threads with those being
dedicated to handling web requests.
On a request arriving next available thread from the thread pool
Graham Dumpleton added the comment:
Those macros only work for general GIL releasing and pop straight away, not for
the case where released, calls into some non Python C library, which then calls
back into Python.
My recollection is, and so unless they have changed it, SWIG generated calls
Graham Dumpleton added the comment:
If you have a Ex version of Ensure, then if the interpreter argument is NULL,
then it should assume main interpreter. That way the normal version of Ensure
can just call PyGILState_EnsureEx(NULL).
--
___
Python
Graham Dumpleton added the comment:
It is past my bed time and not thinking straight, but I believe Antoine is
aligned with what I had in mind, as need multiple thread states per OS thread
where each is associated with separate interpreter.
My main reason for allowing NULL to EnsureEX rather
Graham Dumpleton added the comment:
Sorry, Mark. Is not for associating thread state specified by embedding
application. In simple terms it is exactly like existing PyGILState_Ensure() in
that caller doesn't have a thread state, whether it has already been created.
Only difference is to
Graham Dumpleton added the comment:
Nick. Valid point.
I guess I hadn't been thinking about case of one thread calling out of one
interpreter and then into another, as I don't do it in mod_wsgi and even I
regard doing that as partly evil.
Does that mean this switch interpreter ca
Graham Dumpleton added the comment:
So you are saying that as user of this I am meant to call it as:
PyGILState_INFO info;
PyGILState_EnsureEx(interp, &info);
...
PyGILState_ReleaseEx(&info);
What is the potential error code from PyGILState_EnsureEx() considering that
right
Graham Dumpleton added the comment:
If PyGILState_STATE is a struct, what happens if someone naively does:
PyGILState_Release(PyGILState_UNLOCKED)
I know they shouldn't, but I actually do this in mod_wsgi in one spot as it is
otherwise a pain to carry around the state when I know for su
Graham Dumpleton added the comment:
Hmmm. Wonders if finally finding this was prompted in part by recent post about
this very issue. :-)
http://blog.dscpl.com.au/2012/10/obligations-for-calling-close-on.html
Also related is this issue from Django I highlighted long time ago.
https
Graham Dumpleton added the comment:
That's right, the Django bug report I filed was actually for Django 1.3, which
didn't use wsgiref. I wasn't using Django 1.4 at the time so didn't bother to
check its new implementation based on wsgiref. Instead I just assumed wsgiref
wo
Graham Dumpleton added the comment:
For that cookie string to be valid in the first place, shouldn't it have been
sent as:
'HTTP_COOKIE': 'yaean_djsession=23ab7bf8b260cbb2f2bc80b1c1fd98fa;
yaean_yasession=ff2a3030ee3f428f91c6f554a63b459c'
IOW, semicolon as separato
Changes by Graham Dumpleton :
--
nosy: +grahamd
___
Python tracker
<http://bugs.python.org/issue16500>
___
___
Python-bugs-list mailing list
Unsubscribe:
Graham Dumpleton added the comment:
The requirement per PEP is that the original byte string needs to be
converted to native string (Unicode) with the ISO-8891-1 encoding. This is to
ensure that the original bytes are preserved so that the WSGI application, with
its own knowledge of what
Graham Dumpleton added the comment:
You can't try UTF-8 and then fall back to ISO-8859-1. PEP requires it
always be ISO-8859-1. If an application needs it as something else, it is the
web applications job to do it.
The relevant part of the PEP is:
"""On Python platfo
New submission from Graham Dumpleton:
When a weakref.proxy() is used to wrap a class instance which implements in
place operators, when one applies the in place operator to the proxy, one could
argue the variable holding the proxy should still be a reference to the proxy
after the in place
New submission from Graham Dumpleton:
In the documentation for Python 2.X at:
http://docs.python.org/2/extending/extending.html#a-simple-example
it says:
"""
The self argument points to the module object for module-level functions; for a
method it would point to the object in
New submission from Graham Dumpleton:
The classmethod decorator when applied to a function of a class, does not
honour the descriptor binding protocol for whatever it wraps. This means it
will fail when applied around a function which has a decorator already applied
to it and where that
New submission from Graham Dumpleton:
Python 3 introduced __qualname__. This attribute exists on class types and also
instances of certain class types, such as functions. For example:
def f(): pass
print(f.__name__)
print(f.__qualname__)
class Class: pass
print(Class.__name__)
print(Class
Graham Dumpleton added the comment:
The classmethod __get__() method does:
static PyObject *
cm_descr_get(PyObject *self, PyObject *obj, PyObject *type)
{
classmethod *cm = (classmethod *)self;
if (cm->cm_callable == NULL) {
PyErr_SetString(PyExc_RuntimeEr
Graham Dumpleton added the comment:
If you have the time, would be great if you can have a quick look at my wrapt
package. That will give you an idea of where I am coming from in suggesting
this change.
http://wrapt.readthedocs.org/en/latest/
http://wrapt.readthedocs.org/en/latest/issues.html
Graham Dumpleton added the comment:
@shishkander I can't see how what you are talking about has got anything to do
with the issue with in place operators. The results from your test script are
expected and normal.
What result are you expecting?
The one thing you cannot override in Pyth
Graham Dumpleton added the comment:
The proxy is intended as a wrapper around an object, it is not intended to
merge in some way with the wrapped object. The wrapped object shouldn't really
ever be aware that it was being accessed via a proxy. Thus the expectation that
the 'self
Graham Dumpleton added the comment:
The __del__() method is generally something to be avoided. As this is a design
issue with how you are doing things, I would suggest you move the discussion to:
https://groups.google.com/forum/#!forum/comp.lang.python
You will no doubt get many suggestions
Graham Dumpleton added the comment:
I don't believe so.
--
___
Python tracker
<http://bugs.python.org/issue19072>
___
___
Python-bugs-list mailing list
New submission from Graham Dumpleton:
In am embedded system, as the 'python' executable is itself not run and the
Python interpreter is initialised in process explicitly using PyInitialize(),
in order to find the location of the Python installation, an elaborate sequence
of checks
Graham Dumpleton added the comment:
It is actually very easy for me to work around and I released a new mod_wsgi
version today which works.
When I get a Python home option, instead of calling Py_SetPythonHome() with it,
I append '/bin/python' to it and call Py_SetProgramName
Graham Dumpleton added the comment:
I only make the change to Py_SetProgramName() on UNIX and not Windows. This is
because back in mod_wsgi 1.0 I did actually used to use Py_SetProgramName() but
it didn't seem to work in sane way on Windows so changed to Py_SetPythonHome()
which work
Graham Dumpleton added the comment:
Is actually WSGI 1.0.1 and not 1.1. :-)
--
nosy: +grahamd
___
Python tracker
<http://bugs.python.org/issue22264>
___
___
Pytho
Graham Dumpleton added the comment:
>From memory, the term sometimes used on the WEB-SIG when discussed was
>transcode.
I find the idea that it needs 'fixing' or is 'incorrect', as in 'fix the
original incorrect decoding to latin-1' is a bit misleading as
Changes by Graham Dumpleton :
--
nosy: +grahamd
___
Python tracker
<http://bugs.python.org/issue20138>
___
___
Python-bugs-list mailing list
Unsubscribe:
Graham Dumpleton added the comment:
I see this problem on both MacOS X 10.5 and on Windows. This is when using
Python embedded inside of Apache/mod_wsgi.
On MacOS X the error is:
Fatal Python error: Py_Initialize: can't initialize sys standard streams
ImportError: No module
Graham Dumpleton added the comment:
Hmmm, actually my MacOS X error is different, although Windows one is
same, except that encoding is listed and isn't empty.
--
___
Python tracker
<http://bugs.python.org/i
Graham Dumpleton added the comment:
You can ignore my MacOS X example as that was caused by something else.
My question still stands as to whether the fix will address the similar
problem I saw on Windows.
--
___
Python tracker
<h
New submission from Graham Dumpleton :
When using Python 3.1 for Apache/mod_wsgi (3.0c4) on Windows, Apache will
crash on startup because Python is forcing the process to exit with:
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: c
Graham Dumpleton added the comment:
I have created issue6501 for my Windows variant of this problem given that
it appears to be subtly different due to there being an encoding where as
the MacOS X variant doesn't have one.
Seeing that the fix for the MacOS X issue is in Python code, I
Graham Dumpleton added the comment:
Yes, Apache remaps stdout and stderr to the Apache error log to still
capture anything that errant modules don't log via the Apache error log
functions. In mod_wsgi it replaces sys.stdout and sys.stderr with special
file like objects that redirec
Graham Dumpleton added the comment:
I know this issue is closed, but for this patch, the code:
+modstate = get_atexitmodule_state(module);
+
+if (modstate->ncallbacks == 0)
+return;
was added.
Is there any condition under which modstate could be NULL.
Haven't touche
Graham Dumpleton added the comment:
This new problem I am seeing looks like it may be linked to where the
'atexit' module is initialised/imported in a sub interpreter but never
in the main interpreter. I can avoid the crash by having:
PyImport_ImportModule("atexit"
New submission from Graham Dumpleton :
I am seeing a crash within Py_Finalize() with Python 3.0 in mod_wsgi. It looks
like the
patches for issue-4200 were not adequate and that this wasn't picked up at the
time.
This new problem I am seeing looks like it may be linked to where the &#
Graham Dumpleton added the comment:
Have created issue6531 for my new issue related to this patch.
--
___
Python tracker
<http://bugs.python.org/issue4
Graham Dumpleton added the comment:
As a provider of software that others use I am just making mod_wsgi usable
with everything so users can use whatever they want. You telling me to use
Python 3.1 isn't going to stop people from using Python 3.0 if that is
what they happen to have inst
1 - 100 of 123 matches
Mail list logo
