Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)
On 2022-03-30 08:48:36 +0200, Marco Sulla wrote: > On Tue, 29 Mar 2022 at 00:10, Peter J. Holzer wrote: > > They are are about a year apart, so they will usually contain different > > versions of most packages right from the start. So the Ubuntu and Debian > > security teams probably can't benefit much from each other. > > Are you sure? Since LTS of Debian and Ubuntu lasts 5 years, I suppose > the versions of the packages should overlap at some point in the past. Standard policy (there are exceptions) on most distros is to stay with the same version of any package for the entire lifetime. So for example, Ubuntu 20.04 was released with Apache 2.4.41 and Python 3.8.10 and Debian 11 was released with Apache 2.4.53 and Python 3.9.2 and they are still on these versions. Any security fixes and other critical bug fixes were back-ported to these versions. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Qualification?
> On 29 Mar 2022, at 20:37, alister via Python-list > wrote: > > I'm currently considering a career change (not much choice actually just > been made redundant). > I'd like to be able to turn my interest in python to my advantage, What > qualifications do employers look for? Where I work we use python in the product and look for expertise in object oriented design and python expertise. But will take people with no python expertise if they are willing the learn python and have experience of other OO languages, C+c, Java, etc. We do not look for formal qualifications. Barry > > > > -- > I'm reporting for duty as a modern person. I want to do the Latin Hustle > now! > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Add a method to list the current named logging levels
在 2021年9月3日星期五 UTC+1 18:50:51， 写道： > > On 2 Sep 2021, at 23:38, Dieter Maurer wrote: > > > > Edward Spencer wrote at 2021-9-2 10:02 -0700: > >> Sometimes I like to pass the logging level up to the command line params > >> so my user can specific what level of logging they want. However there is > >> no easy method for pulling the named logging level names. > >> > >> Looking into the code, it would actually be incredibly easy to implement; > >> > >> in `logging.__init__.py`; > >> > >> def listLevelNames(): > >> return _nameToLevel.keys() > >> > >> You could obviously add some other features, like listing only the > >> defaults, sorted by numerical level or alphabetically, etc. But really > >> this basic implementation would be enough to expose the internal variables > >> which shouldn't be accessed because they change (and in fact, between > >> python 2 and 3, they did). > >> > >> Any thoughts? > > > > Usually, you use 5 well known log levels: "DEBUG", "INFO", "WARNING", > > "ERROR" and "CRITICAL". > > No need to provide a special function listing those levels. > I add my own levels, but then I know I did it. > > Barry > > > > > > > > > -- > > Dieter > > -- > > https://mail.python.org/mailman/listinfo/python-list > > Yes, the names are already well defined. But every software project anyone has that needs to use logging then has to define that list, which is a waste of time since they're already defined inside the logging repo. But no-one can access them unless they use protected variables. If it's a case of not wanting users to be able to modify the defaults, then just define that list of log levels as a tuple. Hiding it is unnecessary. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Qualification?
On Tue, 29 Mar 2022 20:49:53 -0400, Dennis Lee Bieber wrote: > On Tue, 29 Mar 2022 19:26:03 - (UTC), alister > declaimed the following: > >>I'm currently considering a career change (not much choice actually just >>been made redundant). >>I'd like to be able to turn my interest in python to my advantage, What >>qualifications do employers look for? > > Strangely -- knowledge of Python was never a consideration in my > history... Having a familiarity with multiple languages, software > engineering principles, and requirements/design analysis were larger > factors. > > Python was something I used in support of the primary task, but was not > the end-product itself (for example, an evaluation of various secure > network filtering hardware, by sending serial numbered packets out one > NIC, > through the filter, and in through a second NIC; capturing both out&in > via Wireshark; later merging the two captures into a single file of time > delays, and plotting the timing of the packets intended to pass through > and verifying that "classified" contents were blocked or sanitized). Pretty much where I am (only less so) I have used python & flask to make a reasonably sucsessfull web app for my fellow engineers at work, lots of stuff with home Raspberry pi robotics but no formal qualifications in the field. -- Earth is a beta site. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Qualification?
> On 30 Mar 2022, at 15:40, alister.ware wrote: > > OK > > where do you work & are there any vacancies (a junior position would suffice) At the moment we are only hiring in India and for senior rolls. Barry > >> On 30/03/2022 14:52, Barry wrote: >> On 29 Mar 2022, at 20:37, alister via Python-list wrote: >>> >>> I'm currently considering a career change (not much choice actually just >>> been made redundant). >>> I'd like to be able to turn my interest in python to my advantage, What >>> qualifications do employers look for? >> Where I work we use python in the product and look for expertise in >> object oriented design and python expertise. But will take people with >> no python expertise if they are willing the learn python and have experience >> of other OO languages, C+c, Java, etc. >> >> We do not look for formal qualifications. >> >> Barry >> >>> >>> >>> -- >>> I'm reporting for duty as a modern person. I want to do the Latin Hustle >>> now! >>> -- >>> https://mail.python.org/mailman/listinfo/python-list >>> > -- https://mail.python.org/mailman/listinfo/python-list
Re: Add a method to list the current named logging levels
> On 30 Mar 2022, at 16:11, Edward Spencer wrote: > > 在 2021年9月3日星期五 UTC+1 18:50:51， 写道： On 2 Sep 2021, at 23:38, Dieter Maurer wrote: >>> >>> Edward Spencer wrote at 2021-9-2 10:02 -0700: Sometimes I like to pass the logging level up to the command line params so my user can specific what level of logging they want. However there is no easy method for pulling the named logging level names. Looking into the code, it would actually be incredibly easy to implement; in `logging.__init__.py`; def listLevelNames(): return _nameToLevel.keys() You could obviously add some other features, like listing only the defaults, sorted by numerical level or alphabetically, etc. But really this basic implementation would be enough to expose the internal variables which shouldn't be accessed because they change (and in fact, between python 2 and 3, they did). Any thoughts? >>> >>> Usually, you use 5 well known log levels: "DEBUG", "INFO", "WARNING", >>> "ERROR" and "CRITICAL". >>> No need to provide a special function listing those levels. >> I add my own levels, but then I know I did it. >> >> Barry >> >>> >>> >>> >>> -- >>> Dieter >>> -- >>> https://mail.python.org/mailman/listinfo/python-list >>> > > Yes, the names are already well defined. But every software project anyone > has that needs to use logging then has to define that list, which is a waste > of time since they're already defined inside the logging repo. But no-one can > access them unless they use protected variables. If it's a case of not > wanting users to be able to modify the defaults, then just define that list > of log levels as a tuple. Hiding it is unnecessary. Is logging.getLevelNamesMapping() what you are looking for? Barry > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
calling a function asynchronously
I have a django app, and for a certain request I need to kick off a
long running task. I want to do this asynchronously and immediately
return a response. I tried using subprocess.Process() but the forked
process does not have a django database connection. I then tried
posting a request using ajax but that does not have a django session
so it's not authorized. Tried using asyncio but I am finding the
caller of the async function does not return until the async function
returns - maybe I am doing something wrong, as it does appear to be
actually asynchronous. I tried this test:
import asyncio
import time
async def long():
for i in range(100):
time.sleep(10)
asyncio.run(long())
print('after asyncio.run')
The final print does not come out until after long() completes.
Is there any way to do this?
--
https://mail.python.org/mailman/listinfo/python-list
Re: calling a function asynchronously
Hi,
You can use asyncio.create_task and gather results. See docs -
https://docs.python.org/3/library/asyncio-task.html
But think twice what you want to do in async task. Do you use synchronous
requests to database? If yes it will blocks eventloop...
If you use Django it makes sense to use something like
'django-background-tasks'
It just saves your time possibly.
// BR
ср, 30 мар. 2022 г., 19:14 Larry Martell :
> I have a django app, and for a certain request I need to kick off a
> long running task. I want to do this asynchronously and immediately
> return a response. I tried using subprocess.Process() but the forked
> process does not have a django database connection. I then tried
> posting a request using ajax but that does not have a django session
> so it's not authorized. Tried using asyncio but I am finding the
> caller of the async function does not return until the async function
> returns - maybe I am doing something wrong, as it does appear to be
> actually asynchronous. I tried this test:
>
> import asyncio
> import time
>
> async def long():
> for i in range(100):
>time.sleep(10)
>
> asyncio.run(long())
> print('after asyncio.run')
>
> The final print does not come out until after long() completes.
>
> Is there any way to do this?
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Add a method to list the current named logging levels
在 2022年3月30日星期三 UTC+1 16:38:26， 写道：
> > On 30 Mar 2022, at 16:11, Edward Spencer wrote:
> >
> > 在 2021年9月3日星期五 UTC+1 18:50:51， 写道：
> On 2 Sep 2021, at 23:38, Dieter Maurer wrote:
> >>>
> >>> Edward Spencer wrote at 2021-9-2 10:02 -0700:
> Sometimes I like to pass the logging level up to the command line params
> so my user can specific what level of logging they want. However there
> is no easy method for pulling the named logging level names.
>
> Looking into the code, it would actually be incredibly easy to
> implement;
>
> in `logging.__init__.py`;
>
> def listLevelNames():
> return _nameToLevel.keys()
>
> You could obviously add some other features, like listing only the
> defaults, sorted by numerical level or alphabetically, etc. But really
> this basic implementation would be enough to expose the internal
> variables which shouldn't be accessed because they change (and in fact,
> between python 2 and 3, they did).
>
> Any thoughts?
> >>>
> >>> Usually, you use 5 well known log levels: "DEBUG", "INFO", "WARNING",
> >>> "ERROR" and "CRITICAL".
> >>> No need to provide a special function listing those levels.
> >> I add my own levels, but then I know I did it.
> >>
> >> Barry
> >>
> >>>
> >>>
> >>>
> >>> --
> >>> Dieter
> >>> --
> >>> https://mail.python.org/mailman/listinfo/python-list
> >>>
> >
> > Yes, the names are already well defined. But every software project anyone
> > has that needs to use logging then has to define that list, which is a
> > waste of time since they're already defined inside the logging repo. But
> > no-one can access them unless they use protected variables. If it's a case
> > of not wanting users to be able to modify the defaults, then just define
> > that list of log levels as a tuple. Hiding it is unnecessary.
> Is logging.getLevelNamesMapping() what you are looking for?
>
> Barry
>
>
> > --
> > https://mail.python.org/mailman/listinfo/python-list
Hi Barry,
What version for python / logging are you seeing that method in? I don't appear
to be able to find it.
I vaguely remember seeing something similar to it though, did it return a dict
of {: } only or did it also include the reverse of int to
str?
Thanks,
Ed
--
https://mail.python.org/mailman/listinfo/python-list
Re: Add a method to list the current named logging levels
On Thu, 31 Mar 2022 at 03:33, Edward Spencer wrote:
>
> 在 2022年3月30日星期三 UTC+1 16:38:26， 写道：
> > > On 30 Mar 2022, at 16:11, Edward Spencer wrote:
> > >
> > > 在 2021年9月3日星期五 UTC+1 18:50:51， 写道：
> > On 2 Sep 2021, at 23:38, Dieter Maurer wrote:
> > >>>
> > >>> Edward Spencer wrote at 2021-9-2 10:02 -0700:
> > Sometimes I like to pass the logging level up to the command line
> > params so my user can specific what level of logging they want.
> > However there is no easy method for pulling the named logging level
> > names.
> >
> > Looking into the code, it would actually be incredibly easy to
> > implement;
> >
> > in `logging.__init__.py`;
> >
> > def listLevelNames():
> > return _nameToLevel.keys()
> >
> > You could obviously add some other features, like listing only the
> > defaults, sorted by numerical level or alphabetically, etc. But really
> > this basic implementation would be enough to expose the internal
> > variables which shouldn't be accessed because they change (and in
> > fact, between python 2 and 3, they did).
> >
> > Any thoughts?
> > >>>
> > >>> Usually, you use 5 well known log levels: "DEBUG", "INFO", "WARNING",
> > >>> "ERROR" and "CRITICAL".
> > >>> No need to provide a special function listing those levels.
> > >> I add my own levels, but then I know I did it.
> > >>
> > >> Barry
> > >>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Dieter
> > >>> --
> > >>> https://mail.python.org/mailman/listinfo/python-list
> > >>>
> > >
> > > Yes, the names are already well defined. But every software project
> > > anyone has that needs to use logging then has to define that list, which
> > > is a waste of time since they're already defined inside the logging repo.
> > > But no-one can access them unless they use protected variables. If it's a
> > > case of not wanting users to be able to modify the defaults, then just
> > > define that list of log levels as a tuple. Hiding it is unnecessary.
> > Is logging.getLevelNamesMapping() what you are looking for?
> >
> > Barry
> >
> >
> > > --
> > > https://mail.python.org/mailman/listinfo/python-list
>
> Hi Barry,
>
> What version for python / logging are you seeing that method in? I don't
> appear to be able to find it.
> I vaguely remember seeing something similar to it though, did it return a
> dict of {: } only or did it also include the reverse of
> int to str?
>
New in 3.11:
https://docs.python.org/3.11/library/logging.html#logging.getLevelNamesMapping
I'd say it's reasonable to use this, and then to backport it to older
versions by monkeypatching it in (by referencing the internal). You
potentially might have issues with other Python implementations, but
I'm pretty sure CPython has logging._nameToLevel with the same
semantics for quite a while.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Add a method to list the current named logging levels
On 2022-03-30 16:37, Barry wrote: > Is logging.getLevelNamesMapping() what you are looking for? Is this in some version newer than the 3.8 that comes stock on my machine? $ python3 -q >>> import logging >>> logging.getLevelNamesMapping() Traceback (most recent call last): File "", line 1, in AttributeError: module 'logging' has no attribute 'getLevelNamesMapping' -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Add a method to list the current named logging levels
On 3/30/22 10:39, Chris Angelico wrote: > New in 3.11: > > https://docs.python.org/3.11/library/logging.html#logging.getLevelNamesMapping > > I'd say it's reasonable to use this, and then to backport it to older > versions by monkeypatching it in (by referencing the internal). You > potentially might have issues with other Python implementations, but > I'm pretty sure CPython has logging._nameToLevel with the same > semantics for quite a while. since 2013, it looks like. -- https://mail.python.org/mailman/listinfo/python-list
Re: calling a function asynchronously
Hi again,
I changed a bit your example and it works as you expected I hope.
import asyncio
async def long():
for i in range(100):
await asyncio.sleep(10)
print("long is done")
loop = asyncio.get_event_loop()
task = loop.create_task(long())
print('after asyncio.run')
loop.run_until_complete(asyncio.gather(task))
But how I wrote before ... if you are in big Django project just look at
existent django libraries for long task running. One of it I sent you.
There is 'celery' as well.
It's more pragmatic way ...
30.03.2022 19:10, Larry Martell пишет:
import asyncio
import time
async def long():
for i in range(100):
time.sleep(10)
asyncio.run(long())
print('after asyncio.run')
--
https://mail.python.org/mailman/listinfo/python-list
Re: calling a function asynchronously
On Wed, Mar 30, 2022 at 2:40 PM Kirill Ratkin via Python-list
wrote:
>
> Hi again,
>
> I changed a bit your example and it works as you expected I hope.
>
> import asyncio
>
>
> async def long():
> for i in range(100):
> await asyncio.sleep(10)
> print("long is done")
>
>
> loop = asyncio.get_event_loop()
>
> task = loop.create_task(long())
> print('after asyncio.run')
> loop.run_until_complete(asyncio.gather(task))
>
>
> But how I wrote before ... if you are in big Django project just look at
> existent django libraries for long task running. One of it I sent you.
> There is 'celery' as well.
>
> It's more pragmatic way ...
Appreciate the reply. I did not know about django-background-tasks -
thanks. I've been trying to make use of that. I do not get the errors
I was getting before but it does not appear that my long running task
is running at all. Still debugging. But concerting asyncio - doesn't
run_until_complete block until long() completes?
>
> 30.03.2022 19:10, Larry Martell пишет:
> > import asyncio
> > import time
> >
> > async def long():
> > for i in range(100):
> > time.sleep(10)
> >
> > asyncio.run(long())
> > print('after asyncio.run')
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: calling a function asynchronously
Hi
30.03.2022 21:44, Larry Martell пишет:
On Wed, Mar 30, 2022 at 2:40 PM Kirill Ratkin via Python-list
wrote:
Hi again,
I changed a bit your example and it works as you expected I hope.
import asyncio
async def long():
for i in range(100):
await asyncio.sleep(10)
print("long is done")
loop = asyncio.get_event_loop()
task = loop.create_task(long())
print('after asyncio.run')
loop.run_until_complete(asyncio.gather(task))
But how I wrote before ... if you are in big Django project just look at
existent django libraries for long task running. One of it I sent you.
There is 'celery' as well.
It's more pragmatic way ...
Appreciate the reply. I did not know about django-background-tasks -
thanks. I've been trying to make use of that. I do not get the errors
I was getting before but it does not appear that my long running task
is running at all. Still debugging. But concerting asyncio - doesn't
run_until_complete block until long() completes?
Yes, It runs until the /future/ has completed.
In example above 'gather' is not necessary because you create one async
task only.
You can pass 'task' to run_until_complete directly.
But if you create several tasks, all of it need to be run concurently
and 'gather' does it.
import asyncio
import random
async def long(x):
duration = random.randint(2, 5)
await asyncio.sleep(duration)
print(f"long is done {x} slept for {duration} seconds")
loop = asyncio.get_event_loop()
task1 = loop.create_task(long(1))
task2 = loop.create_task(long(2))
task3 = loop.create_task(long(3))
print('after asyncio.run')
loop.run_until_complete(asyncio.gather(task1, task2, task3))
So here run_until_complete will wait untill all three tasks complete or
cancel for some reasons (then exception happens. btw we don't handle it
in example).
In your example you use 'asyncio.run'. Internally it does things like to
this
def run(ft)
loop = asyncio.get_event_loop()
task = loop.create_task(ft())
loop.run_until_complete(asyncio.gather(task))
Of course real asyncio.run is much more complicated but model is same, i
think.
It creates loop and future and 'run_until_complete' for future/task in
the loop.
That's why you never get 'print' before asyncio.run finishes.
You also can split run_until_complete and gather.
s = asyncio.gather(task1, task2, task3)
print('after asyncio.run')
loop.run_until_complete(s)
Then 'gather' starts schedule all tasks before 'print' executes. For
example, if you have some network IO operations instead this 'print' ...
maybe few of your async tasks are done during this time.
30.03.2022 19:10, Larry Martell пишет:
import asyncio
import time
async def long():
for i in range(100):
time.sleep(10)
asyncio.run(long())
print('after asyncio.run')
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
