Re: argparse support of/by argparse
>>> [1] https://pypi.org/project/clize/ I use and like docopt (https://github.com/docopt/docopt). Is clize a better choice? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and Ubuntu versions
On Fri, Jul 23, 2021 at 2:55 PM אורי wrote: > > Hi, > > I have a production server with Ubuntu 18.04 LTS (currently upgraded to > Ubuntu 18.04.5 LTS) and I use Python in virtualenv - currently Python > 3.6.9. I'm using Django and I read that from Django 4.0, a minimal version > of Python 3.8 will be required. I would like to know how I use the latest > version of Python (3.10 or 3.9) with my production server - do I have to > reinstall a new server with the latest Ubuntu LTS version? Or do I have to > upgrade my current server's Ubuntu version by upgrading the same machine? > Or should I keep the Ubuntu version and only upgrade Python? I'm also using > other software such as PostgreSQL which is currently psql (PostgreSQL) > 10.17 (Ubuntu 10.17-0ubuntu0.18.04.1). Should I upgrade this too? And what > is the risk that things will not work after I upgrade this? > It's probably easiest to build Python from source. Clone the source repository from GitHub, and build it right there. You can then upgrade your venv to use it, reinstall packages, and everything should work. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: argparse support of/by argparse
On Fri, Jul 23, 2021 at 5:34 PM Albert-Jan Roskam wrote: > > >>> [1] https://pypi.org/project/clize/ > > > I use and like docopt (https://github.com/docopt/docopt). Is clize a better > choice? > Not necessarily. Both are good. Explore both, see which one makes more sense. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Defining a Python enum in a C extension - am I doing this right?
Hi!
I'm working on a Python C extension and I would like to expose a
custom enum (as in: a class inheriting from enum.Enum) that would be
entirely defined in C.
It turned out to not be a trivial task and the regular mechanism for
inheritance using .tp_base doesn't work - most likely due to the
Enum's meta class not being pulled in.
Basically I'm trying to do this:
import enum
class FooBar(enum.Enum):
FOO = 1
BAR = 2
in C.
After a lot of digging into cpython's internals, this is what I came
up with, wrapped in an example buildable module:
#include
PyDoc_STRVAR(module_doc,
"C extension module defining a class inheriting from enum.Enum.");
static PyModuleDef module_def = {
PyModuleDef_HEAD_INIT,
.m_name = "pycenum",
.m_doc = module_doc,
.m_size = -1,
};
struct enum_descr {
const char *name;
long value;
};
static const struct enum_descr foobar_descr[] = {
{
.name = "FOO",
.value = 1,
},
{
.name = "BAR",
.value = 2,
},
{ }
};
static PyObject *make_bases(PyObject *enum_mod)
{
PyObject *enum_type, *bases;
enum_type = PyObject_GetAttrString(enum_mod, "Enum");
if (!enum_type)
return NULL;
bases = PyTuple_Pack(1, enum_type); /* Steals reference. */
if (!bases)
Py_DECREF(enum_type);
return bases;
}
static PyObject *make_classdict(PyObject *enum_mod, PyObject *bases)
{
PyObject *enum_meta_type, *classdict;
enum_meta_type = PyObject_GetAttrString(enum_mod, "EnumMeta");
if (!enum_meta_type)
return NULL;
classdict = PyObject_CallMethod(enum_meta_type, "__prepare__",
"sO", "FooBarEnum", bases);
Py_DECREF(enum_meta_type);
return classdict;
}
static int fill_classdict(PyObject *classdict, PyObject *modname,
const struct enum_descr *descr)
{
const struct enum_descr *entry;
PyObject *key, *val;
int ret;
key = PyUnicode_FromString("__module__");
if (!key)
return -1;
ret = PyObject_SetItem(classdict, key, modname);
Py_DECREF(key);
if (ret < 0)
return -1;
for (entry = descr; entry->name; entry++) {
key = PyUnicode_FromString(entry->name);
if (!key)
return -1;
val = PyLong_FromLong(entry->value);
if (!val) {
Py_DECREF(key);
return -1;
}
ret = PyObject_SetItem(classdict, key, val);
Py_DECREF(key);
Py_DECREF(val);
if (ret < 0)
return -1;
}
return 0;
}
static PyObject *make_new_type(PyObject *classdict, PyObject *bases,
const char *enum_name)
{
PyObject *name, *args, *new_type;
int ret;
name = PyUnicode_FromString(enum_name);
if (!name)
return NULL;
args = PyTuple_Pack(3, name, bases, classdict);
if (!args) {
Py_DECREF(name);
return NULL;
}
Py_INCREF(bases);
Py_INCREF(classdict);
/*
* Reference to name was stolen by PyTuple_Pack(), no need to
* increase it here.
*/
new_type = PyObject_CallObject((PyObject *)&PyType_Type, args);
Py_DECREF(args);
if (!new_type)
return NULL;
ret = PyType_Ready((PyTypeObject *)new_type);
if (ret < 0) {
Py_DECREF(new_type);
return NULL;
}
return new_type;
}
static PyObject *make_enum_type(PyObject *modname, const char *enum_name,
const struct enum_descr *descr)
{
PyObject *enum_mod, *bases, *classdict, *new_type;
int ret;
enum_mod = PyImport_ImportModule("enum");
if (!enum_mod)
return NULL;
bases = make_bases(enum_mod);
if (!bases) {
Py_DECREF(enum_mod);
return NULL;
}
classdict = make_classdict(enum_mod, bases);
if (!classdict) {
Py_DECREF(bases);
Py_DECREF(enum_mod);
return NULL;
}
ret = fill_classdict(classdict, modname, descr);
if (ret < 0) {
Py_DECREF(bases);
Py_DECREF(enum_mod);
Py_DECREF(classdict);
return NULL;
}
new_type = make_new_type(classdict, bases, enum_name);
Py_DECREF(bases);
Py_DECREF(enum_mod);
Py_DECREF(classdict);
return new_type;
}
PyMODINIT_FUNC PyInit_pycenum(void)
{
PyObject *module, *modname, *sub_enum_type;
int ret;
module = PyModule_Create(&module_def);
if (!module)
return NULL;
ret = PyModule_AddStringConstant(module, "__version__", "0.0.1");
if (ret < 0) {
Py_DECREF(module);
return NULL;
}
modname = PyModule_GetNameObject(module);
if (!modname) {
Py_DECREF(module);
return NULL;
}
sub_enum_type = make_enum_type(modname, "FooBar", foobar_descr);
Py_DECREF(modname);
if (!sub_enum_type) {
Py_DECREF(module);
return NULL;
}
ret = PyModule_AddObject(module, "FooBar", sub_enum_type);
if (r
Re: Python and Ubuntu versions
On 23Jul2021 07:54, אורי wrote: >I have a production server with Ubuntu 18.04 LTS (currently upgraded to >Ubuntu 18.04.5 LTS) and I use Python in virtualenv - currently Python >3.6.9. I'm using Django and I read that from Django 4.0, a minimal version >of Python 3.8 will be required. I would like to know how I use the latest >version of Python (3.10 or 3.9) with my production server - do I have to >reinstall a new server with the latest Ubuntu LTS version? Or do I have to >upgrade my current server's Ubuntu version by upgrading the same machine? >Or should I keep the Ubuntu version and only upgrade Python? I'm also using >other software such as PostgreSQL which is currently psql (PostgreSQL) >10.17 (Ubuntu 10.17-0ubuntu0.18.04.1). Should I upgrade this too? And what >is the risk that things will not work after I upgrade this? I would install a totally separate Python from the vendor (ubunut) provided one. This prevents subtle changes to what the OS has been tested against. You can built Python from source and install it, for example with a prefix like /usr/local/ptyhon-3.10. That gets you a different version; nothing in the OS stuff will try to use it, but you use it to invoke your Django app. Both Python and PostgreSQL tend to be very forward compatible - your code should not need to change. By making a separate install you're avoiding breaking OS stuff. Do the build and install as yourself. I usually do the install step by making the install directory as root, then chowning it to me. Then you can do the install as you - this has the advantage the you're unprivileged and can't accidentally damage the OS install. If you're just doing this for personal use then you can of course just install it in your own home directory, not root owned steps required at all. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and Ubuntu versions
On Fri, Jul 23, 2021 at 7:48 PM Cameron Simpson wrote: > Do the build and install as yourself. I usually do the install step by > making the install directory as root, then chowning it to me. Then you > can do the install as you - this has the advantage the you're > unprivileged and can't accidentally damage the OS install. That's interesting, in that it leaves you vulnerable to accidentally damaging your alternate installation, but you're putting it into a directory that normally would look privileged. I'd be inclined to leave /usr as a privileged directory, and do this sort of installation entirely within ~/bin or something equivalent. But hey, this is the flexibility of Unix file system permissions! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Defining a Python enum in a C extension - am I doing this right?
On 2021-07-23 09:20, Bartosz Golaszewski wrote:
Hi!
I'm working on a Python C extension and I would like to expose a
custom enum (as in: a class inheriting from enum.Enum) that would be
entirely defined in C.
It turned out to not be a trivial task and the regular mechanism for
inheritance using .tp_base doesn't work - most likely due to the
Enum's meta class not being pulled in.
Basically I'm trying to do this:
[snip]
static PyObject *make_bases(PyObject *enum_mod)
{
PyObject *enum_type, *bases;
enum_type = PyObject_GetAttrString(enum_mod, "Enum");
if (!enum_type)
return NULL;
bases = PyTuple_Pack(1, enum_type); /* Steals reference. */
PyTuple_Pack doesn't steal references, as far as I can tell.
if (!bases)
Py_DECREF(enum_type);
return bases;
}
[snip]
--
https://mail.python.org/mailman/listinfo/python-list
Re: Defining a Python enum in a C extension - am I doing this right?
On Fri, Jul 23, 2021 at 5:08 PM MRAB wrote:
>
> On 2021-07-23 09:20, Bartosz Golaszewski wrote:
> > Hi!
> >
> > I'm working on a Python C extension and I would like to expose a
> > custom enum (as in: a class inheriting from enum.Enum) that would be
> > entirely defined in C.
> >
> > It turned out to not be a trivial task and the regular mechanism for
> > inheritance using .tp_base doesn't work - most likely due to the
> > Enum's meta class not being pulled in.
> >
> > Basically I'm trying to do this:
> >
> [snip]
> >
> > static PyObject *make_bases(PyObject *enum_mod)
> > {
> > PyObject *enum_type, *bases;
> >
> > enum_type = PyObject_GetAttrString(enum_mod, "Enum");
> > if (!enum_type)
> > return NULL;
> >
> > bases = PyTuple_Pack(1, enum_type); /* Steals reference. */
>
> PyTuple_Pack doesn't steal references, as far as I can tell.
>
Right, the doc says it's equivalent to Py_BuildValue("(OO...)", ...)
and it does increase the reference count on stored objects. It doesn't
answer the main question though. :)
Bartosz
> > if (!bases)
> > Py_DECREF(enum_type);
> >
> > return bases;
> > }
> >
> [snip]
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
a clean exit
Hello everybody,
I wrote a bot for telegram which consists of some processes of which the
main ones are:
- the main process: a list of callback functions
- a second process: managed with a message queue
- a third process: started by the library I use (python-telegram-bot)
which is used for the event/error log ('logging' module).
The problem is that sometimes I get an error from the library (python-
telegram-bot) via logging that my bot has no way of intercepting. The
error is "connection reset by pear" after which my program is no longer
called and I need to restart it. Typically this happens when Telegram
runs an update.
In any case I can know this error because, to write a log in a telegram
channel, I inherit the 'emit' function of the 'logging.Handler' class.
Hoping to have explained clearly enough the context in which the program
receives information about the error (we are inside a process not
launched directly from the main program), my question is: do you have
advice on how I can close my program in the way as clean as possible in
a easy way?
Thanks in advance.
--
https://mail.python.org/mailman/listinfo/python-list
Where to keep local Python modules?
This isn't a question about how to set PYTHONPATH so that Python code can find imported modules, it's about what is a sensible layout for one's home directory - i.e. where to put Python modules. I'm running Linux and have a number of Python modules that are only used by my own code. My top level Python code is all in ~/bin. I'd prefer to separate the modules so that they don't clutter the name space. Currently I have my Python modules in a subdirectory of ~/bin and my Python path is set as:- PYTHONPATH=/home/chris/bin/pymods Is this a reasonable approach? Is there a 'standard' name for the directory containing modules, or a standard place for it? (I don't mean a system-wide standard place, I mean a 'my' standard place). -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Re: Where to keep local Python modules?
Hello, pe 23. heinäk. 2021 klo 21.44 Chris Green ([email protected]) kirjoitti: > This isn't a question about how to set PYTHONPATH so that Python code > can find imported modules, it's about what is a sensible layout for > one's home directory - i.e. where to put Python modules. > > I'm running Linux and have a number of Python modules that are only > used by my own code. My top level Python code is all in ~/bin. I'd > prefer to separate the modules so that they don't clutter the name > space. > > Currently I have my Python modules in a subdirectory of ~/bin and my > Python path is set as:- > > PYTHONPATH=/home/chris/bin/pymods > > Is this a reasonable approach? Is there a 'standard' name for the > directory containing modules, or a standard place for it? (I don't > mean a system-wide standard place, I mean a 'my' standard place). > > Under recent Linux distros there is $HOME/.local/ containing bin and lib directories. May be it's ok to use this for user-specific python settings under Linux. E.g. in .bashrc export PYTHONPATH=$HOME/.local/python Result can be checked then in Python: python >>> import sys >>> sys.path ['', '/home/someuser/.local/lib/python', '/usr/lib64/python39.zip', '/usr/lib64/python3.9', '/usr/lib64/python3.9/lib-dynload', '/usr/local/lib/python3.9/site-packages', '/usr/lib64/python3.9/site-packages', '/usr/lib/python3.9/site-packages'] BR, Roland > > -- > Chris Green > · > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Where to keep local Python modules?
On my Arch Linux box, slightly different path, but still in .local/bin: pbryan@dynamo:~$ python3 Python 3.9.6 (default, Jun 30 2021, 10:22:16) [GCC 11.1.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', '/usr/lib/python39.zip', '/usr/lib/python3.9', '/usr/lib/python3.9/lib-dynload', '/home/pbryan/.local/lib/python3.9/site-packages', '/usr/lib/python3.9/site-packages'] >>> On Fri, 2021-07-23 at 22:46 +0300, Roland Mueller via Python-list wrote: > Hello, > > pe 23. heinäk. 2021 klo 21.44 Chris Green ([email protected]) kirjoitti: > > > This isn't a question about how to set PYTHONPATH so that Python > > code > > can find imported modules, it's about what is a sensible layout for > > one's home directory - i.e. where to put Python modules. > > > > I'm running Linux and have a number of Python modules that are only > > used by my own code. My top level Python code is all in ~/bin. > > I'd > > prefer to separate the modules so that they don't clutter the name > > space. > > > > Currently I have my Python modules in a subdirectory of ~/bin and > > my > > Python path is set as:- > > > > PYTHONPATH=/home/chris/bin/pymods > > > > Is this a reasonable approach? Is there a 'standard' name for the > > directory containing modules, or a standard place for it? (I don't > > mean a system-wide standard place, I mean a 'my' standard place). > > > > Under recent Linux distros there is $HOME/.local/ containing bin > > and lib > directories. May be it's ok to use this for user-specific python > settings > under Linux. > > E.g. in .bashrc > export PYTHONPATH=$HOME/.local/python > > Result can be checked then in Python: > python > > > > import sys > > > > sys.path > ['', '/home/someuser/.local/lib/python', '/usr/lib64/python39.zip', > '/usr/lib64/python3.9', '/usr/lib64/python3.9/lib-dynload', > '/usr/local/lib/python3.9/site-packages', > '/usr/lib64/python3.9/site-packages', '/usr/lib/python3.9/site- > packages'] > > BR, > Roland > > > > > > > > -- > > Chris Green > > · > > -- > > https://mail.python.org/mailman/listinfo/python-list > > -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and Ubuntu versions
On 7/23/2021 12:54 AM, אורי wrote: Hi, I have a production server with Ubuntu 18.04 LTS (currently upgraded to Ubuntu 18.04.5 LTS) and I use Python in virtualenv - currently Python 3.6.9. I'm using Django and I read that from Django 4.0, a minimal version of Python 3.8 will be required. I would like to know how I use the latest version of Python (3.10 or 3.9) with my production server - do I have to 3.9 is the latest production release. Others packages should all be available. 3.10 is still in beta, and updated versions of some packages will not be available for a few months after its release in Sept. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Where to keep local Python modules?
Roland Mueller wrote: > Hello, > > pe 23. heinäk. 2021 klo 21.44 Chris Green ([email protected]) kirjoitti: > > > This isn't a question about how to set PYTHONPATH so that Python code > > can find imported modules, it's about what is a sensible layout for > > one's home directory - i.e. where to put Python modules. > > > > I'm running Linux and have a number of Python modules that are only > > used by my own code. My top level Python code is all in ~/bin. I'd > > prefer to separate the modules so that they don't clutter the name > > space. > > > > Currently I have my Python modules in a subdirectory of ~/bin and my > > Python path is set as:- > > > > PYTHONPATH=/home/chris/bin/pymods > > > > Is this a reasonable approach? Is there a 'standard' name for the > > directory containing modules, or a standard place for it? (I don't > > mean a system-wide standard place, I mean a 'my' standard place). > > > > Under recent Linux distros there is $HOME/.local/ containing bin and lib > directories. May be it's ok to use this for user-specific python settings > under Linux. > > E.g. in .bashrc > export PYTHONPATH=$HOME/.local/python > > Result can be checked then in Python: > python > >>> import sys > >>> sys.path > ['', '/home/someuser/.local/lib/python', '/usr/lib64/python39.zip', > '/usr/lib64/python3.9', '/usr/lib64/python3.9/lib-dynload', > '/usr/local/lib/python3.9/site-packages', > '/usr/lib64/python3.9/site-packages', '/usr/lib/python3.9/site-packages'] > That's certainly a possibility, thanks. -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and Ubuntu versions
On 23Jul2021 19:51, Chris Angelico wrote: >On Fri, Jul 23, 2021 at 7:48 PM Cameron Simpson wrote: >> Do the build and install as yourself. I usually do the install step by >> making the install directory as root, then chowning it to me. Then you >> can do the install as you - this has the advantage the you're >> unprivileged and can't accidentally damage the OS install. > >That's interesting, in that it leaves you vulnerable to accidentally >damaging your alternate installation, but you're putting it into a >directory that normally would look privileged. I'd be inclined to >leave /usr as a privileged directory, and do this sort of installation >entirely within ~/bin or something equivalent. But hey, this is the >flexibility of Unix file system permissions! Rereading this, maybe I was unclear. This is for install directories like /opt/Python-3.whatever or /usr/local/python-3.whatever. Create the install point, chown, install as yourself. I agree about the risk of future mangling - there's a good case for chowning it all to root _after_ the install. I'm just trying to do the install itself in an unprivileged mode. Probably for the OP, the simplest way is a local install as themselved, eg in ~/opt/python-3.whatever. Not rootneed needed at all, and a few symlinks in ~/bin (or adding ~/opt/python-3.whatever/bin to $PATH) are all that's needed to make use of it. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Where to keep local Python modules?
On 23Jul2021 11:33, Chris Green wrote: >This isn't a question about how to set PYTHONPATH so that Python code >can find imported modules, it's about what is a sensible layout for >one's home directory - i.e. where to put Python modules. > >I'm running Linux and have a number of Python modules that are only >used by my own code. My top level Python code is all in ~/bin. I'd >prefer to separate the modules so that they don't clutter the name >space. > >Currently I have my Python modules in a subdirectory of ~/bin and my >Python path is set as:- > >PYTHONPATH=/home/chris/bin/pymods > >Is this a reasonable approach? Is there a 'standard' name for the >directory containing modules, or a standard place for it? (I don't >mean a system-wide standard place, I mean a 'my' standard place). I don't know if this is sensible, but here is what I do. I use virtualenvs. By default I keep these in ~/var/venv. Here's my local MacOS: % ls -la ~/var/venv/ total 0 drwxr-xr-x 9 cameron cameron 288 1 Mar 19:47 . drwx--S--- 41 cameron cameron 1312 24 Jul 08:27 .. lrwxrwxr-x 1 cameron cameron14 1 Mar 19:47 3 -> 3.9.2-homebrew drwxrwxr-x 8 cameron cameron 256 14 Jun 2020 3.7.7-homebrew drwxrwxr-x 6 cameron cameron 192 16 Aug 2020 3.8.5-hggit drwxrwxr-x 8 cameron cameron 256 23 Jul 2020 3.8.5-homebrew drwxrwxr-x 8 cameron cameron 256 21 Nov 2020 3.8.6-homebrew drwxrwxr-x 8 cameron cameron 256 28 Dec 2020 3.9.1_2-homebrew drwxrwxr-x 9 cameron cameron 288 26 May 15:17 3.9.2-homebrew I get my default Pythons from homebrew (again, because I'm on a Mac). So the Python came this way: % brew install [email protected] and the virtualenv got made like this: % python3.9 -m venv ~/var/venv/3.9.2-homebrew giving it a nice detailed directory name. I keep the convenience symlink "3" pointing at the preferred venv (usually the latest). Then I have ~/var/venv/3/bin in my $PATH. With that near the front of $PATH so that "python3" and "pip3" come from there, modules are installed with pip3, eg: % pip3 install cs.upd They land in the venv, and "python3" (which comes from the venv) knows to find them automatically. Almost everything I use comes either from pip or from my own modules. My $PYTHONPATH on the Mac has this: /Users/cameron/lib/python:/Users/cameron/rc/python being, respectively, my personal modules and a place for third party modules which do not come from pip. That latter is an empty set, but it's there. I doubt you'd need to bother with the latter; I doubt I need to either. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and Ubuntu versions
On Sat, Jul 24, 2021 at 9:03 AM Cameron Simpson wrote: > > On 23Jul2021 19:51, Chris Angelico wrote: > >On Fri, Jul 23, 2021 at 7:48 PM Cameron Simpson wrote: > >> Do the build and install as yourself. I usually do the install step by > >> making the install directory as root, then chowning it to me. Then you > >> can do the install as you - this has the advantage the you're > >> unprivileged and can't accidentally damage the OS install. > > > >That's interesting, in that it leaves you vulnerable to accidentally > >damaging your alternate installation, but you're putting it into a > >directory that normally would look privileged. I'd be inclined to > >leave /usr as a privileged directory, and do this sort of installation > >entirely within ~/bin or something equivalent. But hey, this is the > >flexibility of Unix file system permissions! > > Rereading this, maybe I was unclear. This is for install directories > like /opt/Python-3.whatever or /usr/local/python-3.whatever. Create the > install point, chown, install as yourself. > > I agree about the risk of future mangling - there's a good case for > chowning it all to root _after_ the install. I'm just trying to do the > install itself in an unprivileged mode. Ah, I see what you mean. In that case, it's probably fine, but I'd just take the simpler approach and "sudo make install" (or altinstall as the case may be). > Probably for the OP, the simplest way is a local install as themselved, > eg in ~/opt/python-3.whatever. Not rootneed needed at all, and a few > symlinks in ~/bin (or adding ~/opt/python-3.whatever/bin to $PATH) are > all that's needed to make use of it. > Yeah, exactly. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and Ubuntu versions
On 24Jul2021 09:22, Chris Angelico wrote: >On Sat, Jul 24, 2021 at 9:03 AM Cameron Simpson wrote: >> Rereading this, maybe I was unclear. This is for install directories >> like /opt/Python-3.whatever or /usr/local/python-3.whatever. Create the >> install point, chown, install as yourself. >> >> I agree about the risk of future mangling - there's a good case for >> chowning it all to root _after_ the install. I'm just trying to do the >> install itself in an unprivileged mode. > >Ah, I see what you mean. In that case, it's probably fine, but I'd >just take the simpler approach and "sudo make install" (or altinstall >as the case may be). Ah, but to me this is the moral equivalent of: wget random-install-script-url | sh Ideally I'd be doing the install, and arguably the build, as a third user, neither root (keep the system intact) nor myself (my data! mine! don't you touch it!) >> Probably for the OP, the simplest way is a local install as themselved, >> eg in ~/opt/python-3.whatever. Not rootneed needed at all, and a few >> symlinks in ~/bin (or adding ~/opt/python-3.whatever/bin to $PATH) are >> all that's needed to make use of it. > >Yeah, exactly. Aye. But they seemed to be on the route of installing over the system Python, and I was trying to talk them down to just a "system wide but off to the side" install. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Python and Ubuntu versions
On Sat, Jul 24, 2021 at 9:52 AM Cameron Simpson wrote: > > On 24Jul2021 09:22, Chris Angelico wrote: > >On Sat, Jul 24, 2021 at 9:03 AM Cameron Simpson wrote: > >> Rereading this, maybe I was unclear. This is for install directories > >> like /opt/Python-3.whatever or /usr/local/python-3.whatever. Create the > >> install point, chown, install as yourself. > >> > >> I agree about the risk of future mangling - there's a good case for > >> chowning it all to root _after_ the install. I'm just trying to do the > >> install itself in an unprivileged mode. > > > >Ah, I see what you mean. In that case, it's probably fine, but I'd > >just take the simpler approach and "sudo make install" (or altinstall > >as the case may be). > > Ah, but to me this is the moral equivalent of: > > wget random-install-script-url | sh Ehhh, it's not nearly that bad. The biggest risk with the wget command is that, even if you fully trust the source, all it takes is one small network issue and you're running a half a script. > Ideally I'd be doing the install, and arguably the build, as a third > user, neither root (keep the system intact) nor myself (my data! mine! > don't you touch it!) Oh, definitely the build is done as a non-root user. (I usually do that as my own user for simplicity, though.) And while I can see the benefits to installing as a dedicated separate user, it's also just way too fiddly, so I just sudo it and do things the easy way :) (That is, assuming I'm installing into /usr. If it's installed outside of those sorts of directories, then root won't be involved at all - for instance, if I'm developing OBS Studio, I'll build it into ~/tmp/obs/bin and its friends, and it'll all be done as my own user.) > >> Probably for the OP, the simplest way is a local install as themselved, > >> eg in ~/opt/python-3.whatever. Not rootneed needed at all, and a few > >> symlinks in ~/bin (or adding ~/opt/python-3.whatever/bin to $PATH) are > >> all that's needed to make use of it. > > > >Yeah, exactly. > > Aye. > > But they seemed to be on the route of installing over the system Python, > and I was trying to talk them down to just a "system wide but off to the > side" install. > Fair enough. And I absolutely agree with NOT installing over the system Python, although that's usually not going to happen anyway (since this is a different minor version). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Defining a Python enum in a C extension - am I doing this right?
On Fri, Jul 23, 2021 at 1:20 AM Bartosz Golaszewski wrote: > Hi! > > I'm working on a Python C extension and I would like to expose a > custom enum (as in: a class inheriting from enum.Enum) that would be > entirely defined in C. > I'm probably missing something obvious, but why would you write new code in C when you can just use Cython? Cython is a lot easier, and quite fast, and should (eventually?) allow compiling to HPY instead of just "the" C extension module interface. https://news.ycombinator.com/item?id=26627683 -- https://mail.python.org/mailman/listinfo/python-list
