Re: Request for argmax(list) and argmin(list)

[Peter Otten]

On 01/09/2021 06:25, ABCCDE921 wrote:

I dont want to import numpy

argmax(list)
returns index of (left most) max element



>>> import operator
>>> second = operator.itemgetter(1)
>>> def argmax(values):
return max(enumerate(values), key=second)[0]

>>> argmax([1, 2, 3, 0])
2


  argmin(list)
returns index of (left most) min element


This is left as an exercise;)



--
https://mail.python.org/mailman/listinfo/python-list

Re: Create a real-time interactive TUI using Python.

[Gisle Vanem]

hongy...@gmail.com wrote:


The following are some python TUI framework libraries/projects I have 
discovered so far:

https://github.com/pfalcon/picotui
https://github.com/peterbrittain/asciimatics
https://github.com/bczsalba/pytermgui
https://github.com/GeorgeFilipkin/pulsemixer
https://github.com/jwlodek/py_cui
https://github.com/saulpw/visidata
https://github.com/willmcgugan/textual
https://github.com/urwid/urwid


Tried some of these. But only Asciimatics and
Py_CUI works on Windows.

--
--gv
--
https://mail.python.org/mailman/listinfo/python-list

Re: PEP Idea: Real private attribute

[Calvin Spealman]

On Tue, Aug 31, 2021 at 1:19 PM Mehrzad Saremi 
wrote:

> Calvin, even if the language offered truly private members?
>

I'm saying I don't think they're necessary, especially not for the use case
posited here. Private members in other languages are about things internal
to the class of the object itself. If we *did* have them in Python, you
couldn't use private members of an object from a decorator on it because
the decorator is external to the target class.


> On Tue, 31 Aug 2021 at 17:31, Calvin Spealman  wrote:
>
>> The right way for those decorators to hold some private information,
>> imho, isn't to put anything on the decorated object at all, but to use a
>> weak-ref dictionary using the target object as a key.
>>
>> On Sat, Aug 28, 2021 at 5:42 PM Mehrzad Saremi 
>> wrote:
>>
>>> Python currently uses name mangling for double-underscore attributes.
>>> Name
>>> mangling is not an ideal method to avoid name conflicting. There are
>>> various normal programming patterns that can simply cause name
>>> conflicting
>>> in double-underscore members. A typical example is when a class is
>>> re-decorated using the same decorator. The decorator can not take
>>> double-underscore members without name conflicts. For example:
>>>
>>> ```
>>> @custom_decorator("a")
>>> @custom_decorator("b")
>>> class C:
>>> pass
>>> ```
>>>
>>> The `@custom_decorator` wrapper may need to hold private members, but
>>> Python's current name conflict resolution does not provide any solution
>>> and
>>> the decorator cannot hold private members without applying tricky
>>> programming methods.
>>>
>>> Another example is when a class inherits from a base class of the same
>>> name.
>>>
>>> ```
>>> class View:
>>> """A class representing a view of an object; similar to
>>> numpy.ndarray.view"""
>>> pass
>>>
>>> class Object:
>>> class View(View):
>>> """A view class costumized for objects of type Object"""
>>> pass
>>> ```
>>>
>>> Again, in this example, class `Object.View` can't take double-underscore
>>> names without conflicting with `View`'s.
>>>
>>> My idea is to introduce real private members (by which I do not mean to
>>> be
>>> inaccessible from outside the class, but to be guaranteed not to conflict
>>> with other private members of the same object). These private members are
>>> started with triple underscores and are stored in a separate dictionary
>>> named `__privs__`. Unlike `__dict__` that takes 'str' keys, `__privs__`
>>> will be a double layer dictionary that takes 'type' keys in the first
>>> level, and 'str' keys in the second level.
>>>
>>> For example, assume that the user runs the following code:
>>> ```
>>> class C:
>>> def __init__(self, value):
>>> self.___member = value
>>>
>>> c = C("my value")
>>> ```
>>>
>>> On the last line, Python's attribute setter creates a new entry in the
>>> dictionary with key `C`, adds the value "my value" to a new entry with
>>> the
>>> key 'member'.
>>>
>>> The user can then retrieve `c.___member` by invoking the `__privs__`
>>> dictionary:
>>>
>>> ```
>>> print(c.__privs__[C]['member'])  # prints 'my value'
>>> ```
>>>
>>> Note that, unlike class names, class objects are unique and there will
>>> not
>>> be any conflicts. Python classes are hashable and can be dictionary keys.
>>> Personally, I do not see any disadvantage of using __privs__ over name
>>> mangling/double-underscores. While name mangling does not truly guarantee
>>> conflict resolution, __privs__ does.
>>>
>>> Please discuss the idea, let me know what you think about it, whether
>>> there
>>> are possible disadvantages, and if you think it will be approved as a
>>> PEP.
>>>
>>> Thanks,
>>> Mehrzad Saremi
>>>
>>> AI M.Sc. grad. from AUT
>>> --
>>> https://mail.python.org/mailman/listinfo/python-list
>>>
>>>
>>
>> --
>>
>> CALVIN SPEALMAN
>>
>> SENIOR QUALITY ENGINEER
>>
>> calvin.speal...@redhat.com  M: +1.336.210.5107
>> [image: https://red.ht/sig] 
>> TRIED. TESTED. TRUSTED. 
>>
>

-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Trouble propagating logging configuration

[Loris Bennett]

"Dieter Maurer"  writes:

> Loris Bennett wrote at 2021-8-31 15:25 +0200:
>>I am having difficulty getting the my logging configuration passed on
>>to imported modules.
>>
>>My initial structure was as follows:
>>
>>  $ tree blorp/
>>  blorp/
>>  |-- blorp
>>  |   |-- __init__.py
>>  |   |-- bar.py
>>  |   |-- foo.py
>>  |   `-- main.py
>>  `-- pyproject.toml
>>
>>whereby the logging configuration is done in main.py.
>>
>>After thinking about it, I decided maybe the inheritance wasn't working
>>because main.py is in the same directory as the other files.
>
> Should you speak about Python's `logging` module, then
> the "inheritance" does not depend on the source layout.
> Instead, it is based on the hierarchy of dotted names.
> It is completely up to you which dotted names you are using
> in your `getLogger` calls.

Yes, but to quote from 
https://docs.python.org/3.6/howto/logging.html#logging-basic-tutorial:

  A good convention to use when naming loggers is to use a module-level
  logger, in each module which uses logging, named as follows:

logger = logging.getLogger(__name__)

  This means that logger names track the package/module hierarchy, and
  it’s intuitively obvious where events are logged just from the logger
  name.

so in this case the source layout is relevant, isn't it?

> Furthermore, the place of the configuration (and where in the
> code it is activated) is completely irrelevant for the "inheritance".

OK, so one issue is that I was getting confused by the *order* in which
modules are being called.  If I have two modules, 'foo' and 'bar', in
the same directory, configure the logging just in 'foo' and then call


  foo.some_method()  
  bar.some_method()  

then both methods will be logged.   If I do

  bar.some_method()  
  foo.some_method()  

then only the method in 'foo' will be logged.

However, I still have the following problem.  With the structure

  $ tree .
  .
  |-- log_test
  |   |-- __init__.py
  |   |-- first.py
  |   `-- second.py
  |-- pyproject.toml
  |-- README.rst
  |-- run.py
  `-- tests
  |-- __init__.py
  |-- config
  `-- test_log_test.py

I have __name__ variables as follows:

  __file__: /home/loris/log_test/log_test/first.py, __name__: log_test.first
  __file__: /home/loris/log_test/log_test/second.py, __name__: log_test.second
  __file__: ./run.py, __name__: __main__

If I have

  [loggers]
  keys=root,main,log_test   

in my logging configuration and initialise  the logging in run.py with

  logging.config.fileConfig("/home/loris/log_test/tests/config")
  logger = logging.getLogger()

or

  logging.config.fileConfig("/home/loris/log_test/tests/config")
  logger = logging.getLogger("log_test")

then only calls in 'run.py' are logged.

I can obviously initialise the logging within the subordinate package,
i.e. in 'log_test/__init__.py', but that seems wrong to me.

So what is the correct way to initialise logging from a top-level script
such that logging is activated in all modules requested in the logging
configuration?

> For details, read the Python documentation for the `logging` module.

If they were sufficient, I wouldn't need the newsgroup :-)

Thanks for the help,

Loris
-- 
This signature is currently under construction.
-- 
https://mail.python.org/mailman/listinfo/python-list

Mutually exclusive options with argparse.

[hongy...@gmail.com]

See the following code snippets [1] for implementation of the exclusive options 
with argparse:

def query_builder(args):
if args.r and args.s:
sys.exit(Term.FAIL + 'Only one of -re and -sql should be set' + 
Term.ENDC)
sum_status = sum(1 for x in [args.failure, args.code != -1] if x)
if sum_status > 1:
sys.exit(Term.FAIL + ('Only one of --failure and --code has to be set') 
+ Term.ENDC)

[1] 
https://github.com/hongyi-zhao/recent2/blob/5486afbd56a6b06bb149a3ea969fb33d9d8b288f/recent2.py#L391

It seems that the above method is awkward, but I'm out of idea to work out more 
graceful solutions. Any comment/suggestion/enhancement will be highly 
appreciated.

Regards,
HY
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Request for argmax(list) and argmin(list)

[ABCCDE921]

Because that does 2 passes over the entire array when you only need one and 
there is no option to specify if you want the leftmost or rightmost element 


On Wednesday, September 1, 2021 at 12:02:29 PM UTC+5:30, Paul Bryan wrote:
> Why not: 
> 
> >>> l = [1, 3, 5, 9, 2, 7] 
> >>> l.index(max(l)) 
> 3 
> >>> l.index(min(l)) 
> 0
> On Tue, 2021-08-31 at 21:25 -0700, ABCCDE921 wrote: 
> > I dont want to import numpy 
> > 
> > argmax(list) 
> > returns index of (left most) max element 
> > 
> > argmin(list) 
> > returns index of (left most) min element
-- 
https://mail.python.org/mailman/listinfo/python-list

my python progress

[songbird]

  i've had some fun recently when i've had a chance to work
on it.  i needed some kind of project that would encourage
me to learn more python.  i still consider myself very new
to the language and a long ways to go (and i don't consider
the code as a great example, but it is progress to me in my
own understanding of python).

  pyglet the opengl graphics modules have been providing some
fun too.


  here is my recent update to this project:

  https://github.com/flowerbug/npath

  which took the following code and then changes it into a more
general framework and then as a practical result i was able to use
this framework to create and test the first version of the class 
(posted at the bottom).

  https://github.com/flowerbug/ngfp


  one thing i would like to have is a version of the GIMP
button border code converted from the GIMP version of lisp
to python.  i used to be fluent enough in lisp that i can
actually figure out most of what the code does but i am
not familiar enough with GIMP and graphics to fully understand
the code to be able to convert it.  if you are up for the
challenge i would appreciate it.


=
; GIMP - The GNU Image Manipulation Program
; Copyright (C) 1995 Spencer Kimball and Peter Mattis
;
; This program is free software: you can redistribute it and/or modify
; it under the terms of the GNU General Public License as published by
; the Free Software Foundation; either version 3 of the License, or
; (at your option) any later version.
;
; This program is distributed in the hope that it will be useful,
; but WITHOUT ANY WARRANTY; without even the implied warranty of
; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
; GNU General Public License for more details.
;
; You should have received a copy of the GNU General Public License
; along with this program.  If not, see .
;
; Copyright (C) 1997 Andy Thomas a...@picnic.demon.co.uk
;
; Version 0.2 10.6.97 Changed to new script-fu interface in 0.99.10

; Delta the color by the given amount. Check for boundary conditions
; If < 0 set to zero
; If > 255 set to 255
; Return the new value

(define (script-fu-addborder aimg adraw xsize ysize color dvalue)

  (define (deltacolor col delta)
(let* ((newcol (+ col delta)))
  (if (< newcol 0) (set! newcol 0))
  (if (> newcol 255) (set! newcol 255))
  newcol
)
  )

  (define (adjcolor col delta)
(mapcar (lambda (x) (deltacolor x delta)) col)
  )

  (define (gen_top_array xsize ysize owidth oheight width height)
(let* ((n_array (cons-array 10 'double)))
  (aset n_array 0 0 )
  (aset n_array 1 0 )
  (aset n_array 2 xsize)
  (aset n_array 3 ysize)
  (aset n_array 4 (+ xsize owidth))
  (aset n_array 5 ysize)
  (aset n_array 6 width)
  (aset n_array 7 0 )
  (aset n_array 8 0 )
  (aset n_array 9 0 )
  n_array)
  )

  (define (gen_left_array xsize ysize owidth oheight width height)
(let* ((n_array (cons-array 10 'double)))
  (aset n_array 0 0 )
  (aset n_array 1 0 )
  (aset n_array 2 xsize)
  (aset n_array 3 ysize)
  (aset n_array 4 xsize)
  (aset n_array 5 (+ ysize oheight))
  (aset n_array 6 0 )
  (aset n_array 7 height )
  (aset n_array 8 0 )
  (aset n_array 9 0 )
  n_array)
  )

  (define (gen_right_array xsize ysize owidth oheight width height)
(let* ((n_array (cons-array 10 'double)))
  (aset n_array 0 width )
  (aset n_array 1 0 )
  (aset n_array 2 (+ xsize owidth))
  (aset n_array 3 ysize)
  (aset n_array 4 (+ xsize owidth))
  (aset n_array 5 (+ ysize oheight))
  (aset n_array 6 width)
  (aset n_array 7 height)
  (aset n_array 8 width )
  (aset n_array 9 0 )
  n_array)
  )

  (define (gen_bottom_array xsize ysize owidth oheight width height)
(let* ((n_array (cons-array 10 'double)))
  (aset n_array 0 0 )
  (aset n_array 1 height)
  (aset n_array 2 xsize)
  (aset n_array 3 (+ ysize oheight))
  (aset n_array 4 (+ xsize owidth))
  (aset n_array 5 (+ ysize oheight))
  (aset n_array 6 width)
  (aset n_array 7 height)
  (aset n_array 8 0 )
  (aset n_array 9 height)
  n_array)
  )

  (let* ((img (car (gimp-item-get-image adraw)))
 (owidth (car (gimp-image-get-width img)))
 (oheight (car (gimp-image-get-height img)))
 (width (+ owidth (* 2 xsize)))
 (height (+ oheight (* 2 ysize)))
 (layer (car (gimp-layer-new img
 width height
 (car (gimp-drawable-type-with-alpha adraw))
 _"Border Layer" 100 LAYER-MODE-NORMAL

(gimp-context-push)
(gimp-context-set-paint-mode LAYER-MODE-NORMAL)
(gimp-context-set-opacity 100.0)
(gimp-context-set-antialias FALSE)
(gimp-context-set-feather FALSE)

(gimp-image-undo-group-start img)

(gimp-image-resize img
   width
  

Re: Trouble propagating logging configuration

[Peter Otten]

On 01/09/2021 13:48, Loris Bennett wrote:

"Dieter Maurer"  writes:


Loris Bennett wrote at 2021-8-31 15:25 +0200:

I am having difficulty getting the my logging configuration passed on
to imported modules.

My initial structure was as follows:

  $ tree blorp/
  blorp/
  |-- blorp
  |   |-- __init__.py
  |   |-- bar.py
  |   |-- foo.py
  |   `-- main.py
  `-- pyproject.toml

whereby the logging configuration is done in main.py.

After thinking about it, I decided maybe the inheritance wasn't working
because main.py is in the same directory as the other files.


Should you speak about Python's `logging` module, then
the "inheritance" does not depend on the source layout.
Instead, it is based on the hierarchy of dotted names.
It is completely up to you which dotted names you are using
in your `getLogger` calls.


Yes, but to quote from 
https://docs.python.org/3.6/howto/logging.html#logging-basic-tutorial:

   A good convention to use when naming loggers is to use a module-level
   logger, in each module which uses logging, named as follows:

 logger = logging.getLogger(__name__)

   This means that logger names track the package/module hierarchy, and
   it’s intuitively obvious where events are logged just from the logger
   name.

so in this case the source layout is relevant, isn't it?


In most cases you will only add handlers to the root logger. If you want 
special treatment of a specific logger you need to know its name 
including its package, i. e. log_test.first, not first. If you have the 
log_test directory in your path and use


import first

instead of

import log_test.first

then not only the __name__ will be wrong/unexpected, relative imports 
will fail, too.

In other words, this is generally a bad idea.


Furthermore, the place of the configuration (and where in the
code it is activated) is completely irrelevant for the "inheritance".


OK, so one issue is that I was getting confused by the *order* in which
modules are being called.  If I have two modules, 'foo' and 'bar', in
the same directory, configure the logging just in 'foo' and then call


   foo.some_method()
   bar.some_method()

then both methods will be logged.   If I do

   bar.some_method()
   foo.some_method()

then only the method in 'foo' will be logged.

However, I still have the following problem.  With the structure

   $ tree .
   .
   |-- log_test
   |   |-- __init__.py
   |   |-- first.py
   |   `-- second.py
   |-- pyproject.toml
   |-- README.rst
   |-- run.py
   `-- tests
   |-- __init__.py
   |-- config
   `-- test_log_test.py

I have __name__ variables as follows:

   __file__: /home/loris/log_test/log_test/first.py, __name__: log_test.first
   __file__: /home/loris/log_test/log_test/second.py, __name__: log_test.second
   __file__: ./run.py, __name__: __main__

If I have

   [loggers]
   keys=root,main,log_test

in my logging configuration and initialise  the logging in run.py with

   logging.config.fileConfig("/home/loris/log_test/tests/config")
   logger = logging.getLogger()

or

   logging.config.fileConfig("/home/loris/log_test/tests/config")
   logger = logging.getLogger("log_test")

then only calls in 'run.py' are logged.

I can obviously initialise the logging within the subordinate package,
i.e. in 'log_test/__init__.py', but that seems wrong to me.

So what is the correct way to initialise logging from a top-level script
such that logging is activated in all modules requested in the logging
configuration?


For details, read the Python documentation for the `logging` module.


If they were sufficient, I wouldn't need the newsgroup :-)

Thanks for the help,


Perhaps you can start with logging.basicConfig() in run.py. If the 
imported modules contain module-level logging messages you have to put 
the import statements after the basicConfig() invocation.


You should see that simple changes like setting the logging level affect 
messages from all loggers. If that's not enough to get the granularity 
you want give your loggers fixed names


# in test_log/first.py
logger = logging.getLogger("test_log.first")

or make sure that __name__ is what you expect

# in test_log/first.py
assert __name__ == "test_log.first"

during the debugging phase.


--
https://mail.python.org/mailman/listinfo/python-list

Re: Request for argmax(list) and argmin(list)

[Calvin Spealman]

If only there were a library that already provides exactly the functions
you're asking for... 🤔

On Wed, Sep 1, 2021 at 9:54 AM ABCCDE921 
wrote:

> Because that does 2 passes over the entire array when you only need one
> and there is no option to specify if you want the leftmost or rightmost
> element
>
>
> On Wednesday, September 1, 2021 at 12:02:29 PM UTC+5:30, Paul Bryan wrote:
> > Why not:
> >
> > >>> l = [1, 3, 5, 9, 2, 7]
> > >>> l.index(max(l))
> > 3
> > >>> l.index(min(l))
> > 0
> > On Tue, 2021-08-31 at 21:25 -0700, ABCCDE921 wrote:
> > > I dont want to import numpy
> > >
> > > argmax(list)
> > > returns index of (left most) max element
> > >
> > > argmin(list)
> > > returns index of (left most) min element
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>

-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Mutually exclusive options with argparse.

[Lee Congdon]

Does a mutually exclusive group, as described in "Mutual exclusion" at
https://docs.python.org/3/library/argparse.html meet your needs?

On Wed, Sep 1, 2021 at 9:48 AM hongy...@gmail.com 
wrote:

> See the following code snippets [1] for implementation of the exclusive
> options with argparse:
>
> def query_builder(args):
> if args.r and args.s:
> sys.exit(Term.FAIL + 'Only one of -re and -sql should be set' +
> Term.ENDC)
> sum_status = sum(1 for x in [args.failure, args.code != -1] if x)
> if sum_status > 1:
> sys.exit(Term.FAIL + ('Only one of --failure and --code has to be
> set') + Term.ENDC)
>
> [1]
> https://github.com/hongyi-zhao/recent2/blob/5486afbd56a6b06bb149a3ea969fb33d9d8b288f/recent2.py#L391
>
> It seems that the above method is awkward, but I'm out of idea to work out
> more graceful solutions. Any comment/suggestion/enhancement will be highly
> appreciated.
>
> Regards,
> HY
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
+1-202-507-9867, Twitter @lcongdon
-- 
https://mail.python.org/mailman/listinfo/python-list

ANN: Wing Python IDE 8.0.3 has been released

[Wingware]

Wing 8.0.3 allows specifying the Django settings module for unit tests 
with --settings= in Run Args on the Testing page of Project 
Properties, fixes using an Activated Env that contains spaces in its 
path, prevents failure to reformat code on remote hosts and containers, 
fixes searching in files with non-ascii characters, and makes several 
other improvements.


Details:  https://wingware.com/news/2021-08-31
Downloads:   https://wingware.com/downloads

== About Wing ==

Wing is a light-weight but full-featured Python IDE designed 
specifically for Python, with powerful editing, code inspection, 
testing, and debugging capabilities. Wing's deep code analysis provides 
auto-completion, auto-editing, and refactoring that speed up 
development. Its top notch debugger works with any Python code, locally 
or on a remote host, container, or cluster. Wing also supports 
test-driven development, version control, UI color and layout 
customization, and includes extensive documentation and support.


Wing is available in three product levels:  Wing Pro is the 
full-featured Python IDE for professional developers, Wing Personal is a 
free Python IDE for students and hobbyists (omits some features), and 
Wing 101 is a very simplified free Python IDE for beginners (omits many 
features).


Learn more at https://wingware.com/



--
https://mail.python.org/mailman/listinfo/python-list

Re: Trouble propagating logging configuration

[Dieter Maurer]

Loris Bennett wrote at 2021-9-1 13:48 +0200:
> ...
>Yes, but to quote from 
>https://docs.python.org/3.6/howto/logging.html#logging-basic-tutorial:
>
>  A good convention to use when naming loggers is to use a module-level
>  logger, in each module which uses logging, named as follows:
>
>logger = logging.getLogger(__name__)
>
>  This means that logger names track the package/module hierarchy, and
>  it’s intuitively obvious where events are logged just from the logger
>  name.
>
>so in this case the source layout is relevant, isn't it?

Relevant in this case is the package/module hierarchy.

Often the package/module hierarchy follows the source layout
**BUT** this is not necessarily the case.

In particular, the "start" module of a script is called `__main__`
indepently of its location.
Furthermore, so called "namespace packages" consist of
decentralized (i.e. located at different places in the file system)
subpackages.

Thus, in general, the connection between pachage/module hierarchy
and the source layout is loose.


>> Furthermore, the place of the configuration (and where in the
>> code it is activated) is completely irrelevant for the "inheritance".
>
>OK, so one issue is that I was getting confused by the *order* in which
>modules are being called.  If I have two modules, 'foo' and 'bar', in
>the same directory, configure the logging just in 'foo' and then call
>
>
>  foo.some_method()
>  bar.some_method()
>
>then both methods will be logged.   If I do
>
>  bar.some_method()
>  foo.some_method()
>
>then only the method in 'foo' will be logged.

Usually, log configuration is considered a (global) application
(not a (local) package/module) concern:
The components (modules) decide what to log at what level
and global configuration decides what to do with those messages.

Thus, typically, you configure the complete logging in
your main application module and then start to import modules
and call their functions.

> ...
>If I have
>
>  [loggers]
>  keys=root,main,log_test
>
>in my logging configuration and initialise  the logging in run.py  ...

This logging configuration is obviously not complete (thus, I cannot
check what happens in your case).
You may have made errors at other places in your configuration
which may explain your observations.

At your place, I would look at the `logging` source code
to find out where you can see (in an interactive Python session)
which loggers have been created by your configuration and
how they are configured. For the last part you use "vars(logger)".



--
Dieter
-- 
https://mail.python.org/mailman/listinfo/python-list