webmaster has already heard from 4 people who cannot install it.
I sent them to the bug tracker or to python-list but they seem
not to have gone either place. Is there some guide I should be
sending them to, 'how to debug installation problems'?
Laura
Hola!
(I was doubting in sending this mail to this list or to the normal
one, but as it affects a "style recommendation" we propose for the
whole community, I finally sent it here)
I was reading PEP 257 and it says that all public methods from a class
(including __init__) should have a docstring.
Why __init__?
It's behaviour is well defined (inits the instance), and the
initialization parameters should be described in the class' docstring
itself, right?
Or I am missing something?
Should we remove "__init__" (the class method, *not* the package file)
as to require docstrings in the PEP?
Thanks!
--
. Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
Twitter: @facundobatista
Hi,
Trying to run a specific command (ibstat) installed in /usr/sbin on an
Ubuntu 15.04 machine, using subprocess.check_output and getting "/bin/sh:
/usr/sbin/ibstat: No such file or directory"
I tried the following:
- running the command providing full path
- running with executable=bash
- running with (['/bin/bash', '-c' , "/usr/sbin/ibstat"])
Nothing worked ...
Any idea?
-carlos
Hi.
Looking at ceval.c and peephole.c, there is - of course - lots of
specific hard-coded knowledge of the bytecode (e.g., number of operands
and other attributes). I'd like to experiment at this level, but I can't
seem to find a reference for the bytecode.
Is there the equivalent of something like the ARM ARM(*) for Python
bytecode? I can read Python or C code if it's encoded that way, but I'm
looking for something that's a bit more immediate than deciphering what
an interpreter or optimizer is trying to do (i.e., some sort of table
layout or per-opcode set of attributes).
BR,
E.
(*)
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0406c/index.…
I just wanted to quickly thank everyone for the work they put into this
project. I realize most of us either get only a little bit of paid time to
work on Python or none at all, so contributing easily ends up using
personal time which I know is a precious thing. So thank you for caring
enough about this project to put in your valuable time and effort while
trying to keep it enjoyable for everyone else.
As we go into 2016, I hope to do my part to indirectly thank everyone by
making our developer workflow easier to work with so that not only the
lives of the core developers become easier but we once again become a
project that is viewed as welcoming to outside contribution (instead of our
current reputation as having patches sit in the issue tracker, languishing;
join core-workflow if you want to help out with that). I also hope to see
zipimport rewritten -- either by someone else or me if necessary -- so that
my importlib.resources idea can land in time for Python 3.6 (join the
import-sig if that interests you). Otherwise I plan to keep promoting
Python 3 as we get ever closer to 2020. :)
Hi All,
I hit this every time I install packages on Mac OS X that use libssl, it
looks like extensions are built linking to .dylib's that are not
resolveable when the library is actually used:
>>> from OpenSSL import SSL
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "python2.7/site-packages/OpenSSL/__init__.py", line 8, in <module>
from OpenSSL import rand, crypto, SSL
File "python2.7/site-packages/OpenSSL/rand.py", line 11, in <module>
from OpenSSL._util import (
File "python2.7/site-packages/OpenSSL/_util.py", line 6, in <module>
from cryptography.hazmat.bindings.openssl.binding import Binding
File
"python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
line 13, in <module>
from cryptography.hazmat.bindings._openssl import ffi, lib
ImportError:
dlopen(python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so,
2): Library not loaded: libssl.1.0.0.dylib
Referenced from:
python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so
Reason: image not found
Looking at what this links to, I see:
$ otool -L
lib/python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so
lib/python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so:
libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
Whereas the functional _ssl that ships with Python distributions on Mac
OS X look like this:
$ otool -L .../lib/python2.7/lib-dynload/_ssl.so
.../lib/python2.7/lib-dynload/_ssl.so:
@loader_path/../../libssl.1.0.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
What's going wrong here and what can be done differently to have
'pip install package_using_libssl' build a usable binary installation?
Here's a couple of examples of this problem in the wild:
https://github.com/alekstorm/backports.ssl/issues/9http://stackoverflow.com/questions/32978365/how-do-i-run-psycopg2-on-el-cap…https://github.com/psycopg/psycopg2/issues/385
I'm well out of my depth here, I just want to use these libraries, but
I'm happy to try and do the work to make the world a better place for
Mac users of these libraries...
Chris
Hi All,
I hit this every time I install packages on Mac OS X that use libssl, it
looks like extensions are built linking to .dylib's that are not
resolveable when the library is actually used:
>>> from OpenSSL import SSL
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "python2.7/site-packages/OpenSSL/__init__.py", line 8, in <module>
from OpenSSL import rand, crypto, SSL
File "python2.7/site-packages/OpenSSL/rand.py", line 11, in <module>
from OpenSSL._util import (
File "python2.7/site-packages/OpenSSL/_util.py", line 6, in <module>
from cryptography.hazmat.bindings.openssl.binding import Binding
File
"python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py",
line 13, in <module>
from cryptography.hazmat.bindings._openssl import ffi, lib
ImportError:
dlopen(python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so,
2): Library not loaded: libssl.1.0.0.dylib
Referenced from:
python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so
Reason: image not found
Looking at what this links to, I see:
$ otool -L
lib/python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so
lib/python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so:
libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
Whereas the functional _ssl that ships with Python distributions on Mac
OS X look like this:
$ otool -L .../lib/python2.7/lib-dynload/_ssl.so
.../lib/python2.7/lib-dynload/_ssl.so:
@loader_path/../../libssl.1.0.0.dylib (compatibility version 1.0.0,
current version 1.0.0)
What's going wrong here and what can be done differently to have
'pip install package_using_libssl' build a usable binary installation?
Here's a couple of examples of this problem in the wild:
https://github.com/alekstorm/backports.ssl/issues/9http://stackoverflow.com/questions/32978365/how-do-i-run-psycopg2-on-el-cap…https://github.com/psycopg/psycopg2/issues/385
I'm well out of my depth here, I just want to use these libraries, but
I'm happy to try and do the work to make the world a better place for
Mac users of these libraries...
Chris
