Graham Dumpleton added the comment:
These days I have no idea who is active on Django.
--
___
Python tracker
<https://bugs.python.org/issue46761>
___
___
Pytho
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:
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
Change by Graham Dumpleton :
--
nosy: +grahamd
___
Python tracker
<https://bugs.python.org/issue46846>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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 my own
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:
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
tak
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 defined
Change by Graham Dumpleton :
--
nosy: +grahamd
___
Python tracker
<https://bugs.python.org/issue45319>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/python
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:
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 as New
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
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 <graham.dumple...@gmail.com> 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 sh
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 call
Graham Dumpleton added the comment:
I always use PyImport_GetModuleDict(). So long as that isn't going away I
should be good.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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 curl see:
'REQUEST_URI': '/a=\xc3\x91\\x82
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:
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:
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': ['тест']}
The PATH_INFO case
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')),
urllib.parse.parse_qs(urllib
Changes by Graham Dumpleton <graham.dumple...@gmail.com>:
--
nosy: +grahamd
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23990>
___
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
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 code
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 process
Changes by Graham Dumpleton graham.dumple...@gmail.com:
--
nosy: +grahamd
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10496
___
___
Python-bugs
Graham Dumpleton added the comment:
Is actually WSGI 1.0.1 and not 1.1. :-)
--
nosy: +grahamd
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22264
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 well. It was the
only practical way
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() instead
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 worked
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 is run
Changes by Graham Dumpleton graham.dumple...@gmail.com:
--
nosy: +grahamd
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20138
___
___
Python-bugs
Graham Dumpleton added the comment:
I don't believe so.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19072
___
___
Python-bugs-list mailing
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 Python
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' attribute
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:
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:
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_RuntimeError
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 instance
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
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:
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 rep...@bugs.python.org
http://bugs.python.org/issue18020
___
___
Python-bugs-list
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 platforms where the str
Changes by Graham Dumpleton graham.dumple...@gmail.com:
--
nosy: +grahamd
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16500
___
___
Python-bugs
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 separator.
What client generated
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
would be right. Whoops
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:
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 sure
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 allow
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 call somehow
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 now
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:
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
New submission from Graham Dumpleton graham.dumple...@gmail.com:
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
New submission from Graham Dumpleton graham.dumple...@gmail.com:
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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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 graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
New submission from Graham Dumpleton graham.dumple...@gmail.com:
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
Graham Dumpleton graham.dumple...@gmail.com added the comment:
Whoops. Missed the error. The fatal error that occurs is:
Fatal Python error: Couldn't create autoTLSkey mapping
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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 rep
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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 change on every single
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
New submission from Graham Dumpleton graham.dumple...@gmail.com:
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
Graham Dumpleton graham.dumple...@gmail.com 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 urgent
Graham Dumpleton graham.dumple...@gmail.com added the comment:
The workaround of using:
#if defined(WIN32) PY_MAJOR_VERSION = 3
_wputenv(LPYTHONIOENCODING=cp1252:backslashreplace);
#endif
Py_Initialize();
gets around the crash on startup.
I haven't done sufficient testing
New submission from Graham Dumpleton graham.dumple...@gmail.com:
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
Graham Dumpleton graham.dumple...@gmail.com added the comment:
Have created issue6531 for my new issue related to this patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4200
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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
Graham Dumpleton graham.dumple...@gmail.com 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 rep...@bugs.python.org
http
Graham Dumpleton graham.dumple...@gmail.com 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
New submission from Graham Dumpleton graham.dumple...@gmail.com:
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
1 - 100 of 120 matches
Mail list logo
