Re: Waht do you think about my repeated_timer class

2022-02-04 Thread Cecil Westerhof via Python-list
Cecil Westerhof  writes:

It was already not a good name, but I am rewriting the class
completely, so now the name is a complete bumper. (No more timer.) I
am thinking about naming the class repeating_thread, but I cannot say
that I find it a very good name. So if someone has a good idea for a
name …

The class starts a thread where every by the user defined interval a
by the user define function is called.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Waht do you think about my repeated_timer class

2022-02-04 Thread Ethan Furman

On 2/4/22 6:28 AM, Cecil Westerhof via Python-list wrote:

> It was already not a good name, but I am rewriting the class
> completely, so now the name is a complete bumper. (No more timer.) I
> am thinking about naming the class repeating_thread, but I cannot say
> that I find it a very good name. So if someone has a good idea for a
> name …
>
> The class starts a thread where every by the user defined interval a
> by the user define function is called.

How about `timed_repeat` or `repeat_timer`?

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


PYTHONPATH vs Python Virtual Environment

2022-02-04 Thread Sina Mobasheri
it's not good title defiantly and I don't mean to compare apples and oranges

when I start using python virtual environment it was because isolation proposes 
and everyone say about its benefits in isolation and working with different 
versions of the same package in different projects

but recently I start using pip install --target  for 
zipapp
 things, and then I use this pip's option (--target) and add its target folder 
to PYTHONPATH and target folder's bin directory to PATH, so it's like virtual 
environment to me

I'm curious what is a problem with this approach (edges), what are other 
benefits of the virtual environment that this way can't offer? most tutorials 
talk about isolation and managing of packages versions but I think maybe it's 
more than that maybe?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Waht do you think about my repeated_timer class

2022-02-04 Thread Cecil Westerhof via Python-list
Ethan Furman  writes:

> On 2/4/22 6:28 AM, Cecil Westerhof via Python-list wrote:
>
>> It was already not a good name, but I am rewriting the class
>> completely, so now the name is a complete bumper. (No more timer.) I
>> am thinking about naming the class repeating_thread, but I cannot say
>> that I find it a very good name. So if someone has a good idea for a
>> name …
>>
>> The class starts a thread where every by the user defined interval a
>> by the user define function is called.
>
> How about `timed_repeat` or `repeat_timer`?

timed_repeat does have something.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: ssl server: how to disable client cert verfication?

2022-02-04 Thread Grant Edwards
On 2022-02-04, Chris Angelico  wrote:
> On Fri, 4 Feb 2022 at 09:37, Grant Edwards  wrote:
>> I've looked through the ssl.Context documentation multiple times, and
>> haven't been able to spot any option or flag that disables client
>> certificate validation or allows the user to override the actual
>> client certificate validation process.
>
> What you're doing is a little unusual, so my first thought would be to
> subclass Context and override whatever method does the checks.

I've done a dir() on the Context object, and I don't see anything that
looks like a method to do the checks. I suspect that the Context
object doesn't actually _do_ anything, it just hold a reference to an
underlying openssl context object and allow to to change its
configuration values.

--
Grant


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


Re: ssl server: how to disable client cert verfication?

2022-02-04 Thread Grant Edwards
On 2022-02-04, Kushal Kumaran  wrote:

>> It's a troubleshooting utility for displaying a client's certificate.
>>
>>> Which kinds of client certificates do you want to permit
>>
>> All of them. Anything that's parsable as an X509 certificate no matter
>> how "invalid" it is.
>>
>
> Does `openssl x509 -in  -text -noout` do what you want?

Where does  come from?

>> I just don't want it validated by the SSL layer: I want to print it
>> out. That seems to be trivial to do for server certificates using
>> "openssl s_client", but I can't find any way to do it for client
>> certficates.
>
> In your place, I would simply use the openssl x509 command.

How does the x509 command obtain the certificate from the
client/server handshake?

> If I wanted more/different info, I would write a script to load the
> certificate and printed out the relevant info.

How does one "load the certificate" from the client?

> If this functionality must be provided by a server,

> I would write it so that a certificate could be POSTed to
> the server (without using client certificates),

The problem is in getting the certificate is provided by the client
during the handshake with the server. Don't worry about how to
parse/print it -- I can deal with that.

> I don't know how to use the stdlib's ssl module to do this kind of
> parsing.

I'm not asking about parsing x509 certificates. That's not the
problem.

The problem is _getting_ the client certificate that was provided
during the client/server handshake. That's trivial if the handshake
was successful. The problem is obtaining the client certificate when
the handshake fails. I was hoping there was a way to disable client
certificate validation so that the handshake will succeed and then
allow me to get the client certificate from the connection object.

--
Grant



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


Re: ssl server: how to disable client cert verfication?

2022-02-04 Thread Barry


> On 4 Feb 2022, at 18:17, Grant Edwards  wrote:
> 
> On 2022-02-04, Chris Angelico  wrote:
>>> On Fri, 4 Feb 2022 at 09:37, Grant Edwards  
>>> wrote:
>>> I've looked through the ssl.Context documentation multiple times, and
>>> haven't been able to spot any option or flag that disables client
>>> certificate validation or allows the user to override the actual
>>> client certificate validation process.
>> 
>> What you're doing is a little unusual, so my first thought would be to
>> subclass Context and override whatever method does the checks.
> 
> I've done a dir() on the Context object, and I don't see anything that
> looks like a method to do the checks. I suspect that the Context
> object doesn't actually _do_ anything, it just hold a reference to an
> underlying openssl context object and allow to to change its
> configuration values.

We started with the OpenSSL api and looked see what it provided.
Then looked for how to access that from python.

Barry

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

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


Re: ssl server: how to disable client cert verfication?

2022-02-04 Thread Christian Heimes

On 03/02/2022 19.57, Grant Edwards wrote:

I've got a small ssl server app. I want to require a certificate from
the client, so I'm using a context with

context.verify_mode = ssl.CERT_REQUIRED

But, I want all certificates accepted. How do I disable client
certificate verification?


You can't. Python's ssl module does not expose the necessary feature to 
override the verification callback SSL_CTX_set_verify(). PyOpenSSL lets 
you set a callback and ignore any and all errors.


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


Re: ssl server: how to disable client cert verfication?

2022-02-04 Thread Christian Heimes

On 04/02/2022 19.24, Grant Edwards wrote:

The problem is _getting_ the client certificate that was provided
during the client/server handshake. That's trivial if the handshake
was successful. The problem is obtaining the client certificate when
the handshake fails. I was hoping there was a way to disable client
certificate validation so that the handshake will succeed and then
allow me to get the client certificate from the connection object.


FYI, it's more complicated in TLS 1.3. Post-handshake authentication 
(PHA) can happen out-of-bounce. Only TLS 1.2 performs client cert auth 
during handshake or renegotiation.


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


Re: Waht do you think about my repeated_timer class

2022-02-04 Thread Igor Berger
On Friday, February 4, 2022 at 12:28:53 PM UTC-5, Cecil Westerhof wrote:
> Ethan Furman  writes: 
> 
> > On 2/4/22 6:28 AM, Cecil Westerhof via Python-list wrote: 
> > 
> >> It was already not a good name, but I am rewriting the class 
> >> completely, so now the name is a complete bumper. (No more timer.) I 
> >> am thinking about naming the class repeating_thread, but I cannot say 
> >> that I find it a very good name. So if someone has a good idea for a 
> >> name … 
> >> 
> >> The class starts a thread where every by the user defined interval a 
> >> by the user define function is called. 
> > 
> > How about `timed_repeat` or `repeat_timer`?
> timed_repeat does have something.
> -- 
> Cecil Westerhof 
> Senior Software Engineer 
> LinkedIn: http://www.linkedin.com/in/cecilwesterhof

run_periodically() ?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Waht do you think about my repeated_timer class

2022-02-04 Thread Cecil Westerhof via Python-list
Igor Berger  writes:

> On Friday, February 4, 2022 at 12:28:53 PM UTC-5, Cecil Westerhof wrote:
>> Ethan Furman  writes: 
>> 
>> > On 2/4/22 6:28 AM, Cecil Westerhof via Python-list wrote: 
>> > 
>> >> It was already not a good name, but I am rewriting the class 
>> >> completely, so now the name is a complete bumper. (No more timer.) I 
>> >> am thinking about naming the class repeating_thread, but I cannot say 
>> >> that I find it a very good name. So if someone has a good idea for a 
>> >> name … 
>> >> 
>> >> The class starts a thread where every by the user defined interval a 
>> >> by the user define function is called. 
>> > 
>> > How about `timed_repeat` or `repeat_timer`?
>> timed_repeat does have something.
>
> run_periodically() ?

Also better as mine.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: PYTHONPATH vs Python Virtual Environment

2022-02-04 Thread Dieter Maurer
Sina Mobasheri wrote at 2022-2-4 15:55 +:
>it's not good title defiantly and I don't mean to compare apples and oranges
>
>when I start using python virtual environment it was because isolation 
>proposes and everyone say about its benefits in isolation and working with 
>different versions of the same package in different projects
>
>but recently I start using pip install --target  for 
>zipapp
> things, and then I use this pip's option (--target) and add its target folder 
>to PYTHONPATH and target folder's bin directory to PATH, so it's like virtual 
>environment to me
>
>I'm curious what is a problem with this approach (edges), what are other 
>benefits of the virtual environment that this way can't offer? most tutorials 
>talk about isolation and managing of packages versions but I think maybe it's 
>more than that maybe?

Usually, PYTHONPATH is global.
This can make a problem when you have different applications
which require different package versions.

Of course, you can use a wrapper for your application which locally
sets PYTHONPATH appropriately.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: ssl server: how to disable client cert verfication?

2022-02-04 Thread Dieter Maurer
Grant Edwards wrote at 2022-2-3 14:36 -0800:
>On 2022-02-03, Barry  wrote:
> ...
>I've looked through the ssl.Context documentation multiple times, and
>haven't been able to spot any option or flag that disables client
>certificate validation or allows the user to override the actual
>client certificate validation process.

Note that Python does not do the certificate validation itself
but delegates this to the underlying SSL library.
Thus, this library would need to support your use case.
It may not as your scenario is quite special.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: ssl server: how to disable client cert verfication?

2022-02-04 Thread Grant Edwards
On 2022-02-04, Christian Heimes  wrote:
> On 04/02/2022 19.24, Grant Edwards wrote:
>> The problem is _getting_ the client certificate that was provided
>> during the client/server handshake. That's trivial if the handshake
>> was successful. The problem is obtaining the client certificate when
>> the handshake fails. I was hoping there was a way to disable client
>> certificate validation so that the handshake will succeed and then
>> allow me to get the client certificate from the connection object.
>
> FYI, it's more complicated in TLS 1.3. Post-handshake authentication 
> (PHA) can happen out-of-bounce. Only TLS 1.2 performs client cert auth 
> during handshake or renegotiation.

That's fine. I can force TLS 1.2 to be used. I don't think there are
going to be situations where the choice of 1.2 vs 1.3 will affect what
certificate is supplied by the client.

The 1.3 PHA would also be OK as long as

 1. I can disable verification of the client certificate that's
obtained via PHA.

 2. I can obtain the client certificated that was sent during PHA.

What's odd is that it's trivial to do what I want from the client side
using "openssl s_client", but there doesn't seem to be any way to do
the corresponding using "openssl s_server".

I'm beginning to suspect this is a deficiency in the openssl library
itself.

--
Grant


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


Re: ssl server: how to disable client cert verfication?

2022-02-04 Thread Grant Edwards
On 2022-02-04, Barry  wrote:
>>
>>> What you're doing is a little unusual, so my first thought would be to
>>> subclass Context and override whatever method does the checks.
>> 
>> I've done a dir() on the Context object, and I don't see anything that
>> looks like a method to do the checks. I suspect that the Context
>> object doesn't actually _do_ anything, it just hold a reference to an
>> underlying openssl context object and allow to to change its
>> configuration values.
>
> We started with the OpenSSL api and looked see what it provided.
> Then looked for how to access that from python.

Right. I now suspect this is something missing from the oponssl server
side library code. It's trivial to do the same thing from the client
side (ignore the validity of the server certificate).

--
Grant



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


Re: ssl server: how to disable client cert verfication?

2022-02-04 Thread Grant Edwards
On 2022-02-04, Christian Heimes  wrote:
> On 03/02/2022 19.57, Grant Edwards wrote:
>> I've got a small ssl server app. I want to require a certificate from
>> the client, so I'm using a context with
>> 
>> context.verify_mode = ssl.CERT_REQUIRED
>> 
>> But, I want all certificates accepted. How do I disable client
>> certificate verification?
>
> You can't. Python's ssl module does not expose the necessary feature to 
> override the verification callback SSL_CTX_set_verify(). PyOpenSSL lets 
> you set a callback and ignore any and all errors.

Thanks! I'll look into that.

Since "openssl s_client" didn't seem to have any option to ignore
client cert validity, I was starting to wonder if ignoring it was
simply impossible with openssl.

--
Grant



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


Re: ssl server: how to disable client cert verfication?

2022-02-04 Thread Grant Edwards
On 2022-02-04, Dieter Maurer  wrote:
> Grant Edwards wrote at 2022-2-3 14:36 -0800:
>>On 2022-02-03, Barry  wrote:
>> ...
>>I've looked through the ssl.Context documentation multiple times, and
>>haven't been able to spot any option or flag that disables client
>>certificate validation or allows the user to override the actual
>>client certificate validation process.
>
> Note that Python does not do the certificate validation itself
> but delegates this to the underlying SSL library.
> Thus, this library would need to support your use case.
> It may not as your scenario is quite special.

The corresponding scenario is easily supported for the client
side. Even "openssl s_client" offers the option to ignore cert
validation failures and print the cert anyway. It seems odd that
s_server can't do the same.

--
Grant

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


Re: Waht do you think about my repeated_timer class

2022-02-04 Thread Chris Angelico
On Sat, 5 Feb 2022 at 04:33, Cecil Westerhof via Python-list
 wrote:
>
> Ethan Furman  writes:
>
> > On 2/4/22 6:28 AM, Cecil Westerhof via Python-list wrote:
> >
> >> It was already not a good name, but I am rewriting the class
> >> completely, so now the name is a complete bumper. (No more timer.) I
> >> am thinking about naming the class repeating_thread, but I cannot say
> >> that I find it a very good name. So if someone has a good idea for a
> >> name …
> >>
> >> The class starts a thread where every by the user defined interval a
> >> by the user define function is called.
> >
> > How about `timed_repeat` or `repeat_timer`?
>
> timed_repeat does have something.
>

What about "interval timer"?

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


Re: Waht do you think about my repeated_timer class

2022-02-04 Thread Martin Di Paola




In _run I first set the new timer and then I execute the function. So
that will go mostly OK.


Yes, that's correct however you are not taking into consideration the 
imprecision of the timers.


Timer will call the next _run() after self._interval *plus* some unknown 
arbitrary time (and extra delay).


Let's assume that when you setup an 1 sec Timer but the Timer calls 
_run() after 1.01 secs due this unknown extra delay.


The first time fn() should be called after 1 sec since the begin but it 
is called after 1.01 secs so the extra delay was of 0.01 sec.


The second time fn() should be called after 2 secs since the begin but 
it is called after 2.02 secs. The second fn() was delayed not by 0.01 
but by 0.02 secs.


The third fn() will be delayed by 0.03 secs and so on.

This arbitrary delay is very small however it will sum up on each 
iteration and depending of your application can be a serious problem.


I wrote a post about this and how to create "constant rate loops" which 
fixes this problem:

https://book-of-gehn.github.io/articles/2019/10/23/Constant-Rate-Loop.html

In the post I also describe two solutions (with their trade-offs) for 
when the target function fn() takes longer than the self._interval time.


See if it helps.

Thanks,
Martin.


On Thu, Feb 03, 2022 at 11:41:42PM +0100, Cecil Westerhof via 
Python-list wrote:

Barry  writes:


On 3 Feb 2022, at 04:45, Cecil Westerhof via Python-list 
 wrote:

Have to be careful that timing keeps correct when target takes a 'lot'
of time.
Something to ponder about, but can wait.


You have noticed that your class does call the function at the repeat interval 
but
rather at the repeat interval plus processing time.


Nope:
   def _next(self):
   self._timer = Timer(self._interval, self._run)
   self._timer.start()

   def _run(self):
   self._next()
   self._fn()

In _run I first set the new timer and then I execute the function. So
that will go mostly OK.



The way to fix this is to subtract the last processing elapsed time for the 
next interval.
Sort of a software phase locked loop.

Just before you call the run function record the time.time() as start_time.
Then you can calculate next_interval = max( .001, interval - time.time() - 
start_time)
I use 1ms as the min interval.


But I am working on a complete rewrite to create a more efficient
class. (This means I have to change also the code that uses it.) There
I have to do something like you suggest. (I am already working on it.)


Personally I am also of the opinion that the function should finish in
less as 10% from the interval. (That was one of my rewrites.)

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
--
https://mail.python.org/mailman/listinfo/python-list

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


RuntimeError, or user defined exception

2022-02-04 Thread Cecil Westerhof via Python-list
I am creating a class that will call a user defined function on user
defined intervals. In my opinion it is an error when the function
takes more as 10% of interval, or more as half a second. What is
better: just using RuntimeError, or creating two exception classes for
this?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Waht do you think about my repeated_timer class

2022-02-04 Thread Cecil Westerhof via Python-list
Chris Angelico  writes:

> On Sat, 5 Feb 2022 at 04:33, Cecil Westerhof via Python-list
>  wrote:
>>
>> Ethan Furman  writes:
>>
>> > On 2/4/22 6:28 AM, Cecil Westerhof via Python-list wrote:
>> >
>> >> It was already not a good name, but I am rewriting the class
>> >> completely, so now the name is a complete bumper. (No more timer.) I
>> >> am thinking about naming the class repeating_thread, but I cannot say
>> >> that I find it a very good name. So if someone has a good idea for a
>> >> name …
>> >>
>> >> The class starts a thread where every by the user defined interval a
>> >> by the user define function is called.
>> >
>> > How about `timed_repeat` or `repeat_timer`?
>>
>> timed_repeat does have something.
>>
>
> What about "interval timer"?

It is not really a timer, but on the other hand it seems to be a
timer. (White box, black box.)

I will add it. I do not have to decide before I publish the class, so
I can let it simmer for a while. ;-)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
-- 
https://mail.python.org/mailman/listinfo/python-list


Writing a package

2022-02-04 Thread Paulo da Silva

Hello!

Let's say I have a dir src containing another dir named foo and a script 
test.py.


So, I have
src/foo (dir)
src/test.py (script)

test.py has the folloing code:

import foo as f
c=f.C()

I am inside src and want to run python test.py.

How can I create the class C inside src/foo dir if it is possible at all?

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


Re: Writing a package

2022-02-04 Thread Cameron Simpson
On 05Feb2022 00:37, Paulo da Silva  wrote:
>Let's say I have a dir src containing another dir named foo and a 
>script test.py.
>
>So, I have
>src/foo (dir)
>src/test.py (script)
>
>test.py has the folloing code:
>
>import foo as f
>c=f.C()
>
>I am inside src and want to run python test.py.
>
>How can I create the class C inside src/foo dir if it is possible at 
>all?

Define it in the file "src/foo/__init__.py".

When you go:

import blah

Python reaches for the file "blah.py" or "blah/__init__.py" (this second 
path is for "packages").

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Waht do you think about my repeated_timer class

2022-02-04 Thread Avi Gross via Python-list
time_after_time
But to be more pythonic, throw some double underscores before and after.

-Original Message-
From: Igor Berger 
To: python-list@python.org
Sent: Fri, Feb 4, 2022 12:40 pm
Subject: Re: Waht do you think about my repeated_timer class

On Friday, February 4, 2022 at 12:28:53 PM UTC-5, Cecil Westerhof wrote:
> Ethan Furman  writes: 
> 
> > On 2/4/22 6:28 AM, Cecil Westerhof via Python-list wrote: 
> > 
> >> It was already not a good name, but I am rewriting the class 
> >> completely, so now the name is a complete bumper. (No more timer.) I 
> >> am thinking about naming the class repeating_thread, but I cannot say 
> >> that I find it a very good name. So if someone has a good idea for a 
> >> name … 
> >> 
> >> The class starts a thread where every by the user defined interval a 
> >> by the user define function is called. 
> > 
> > How about `timed_repeat` or `repeat_timer`?
> timed_repeat does have something.
> -- 
> Cecil Westerhof 
> Senior Software Engineer 
> LinkedIn: http://www.linkedin.com/in/cecilwesterhof

run_periodically() ?
-- 
https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Writing a package

2022-02-04 Thread Paulo da Silva

Às 02:01 de 05/02/22, Cameron Simpson escreveu:

On 05Feb2022 00:37, Paulo da Silva  wrote:

Let's say I have a dir src containing another dir named foo and a
script test.py.

So, I have
src/foo (dir)
src/test.py (script)

test.py has the folloing code:

import foo as f
c=f.C()

I am inside src and want to run python test.py.

How can I create the class C inside src/foo dir if it is possible at
all?


Define it in the file "src/foo/__init__.py".

When you go:

 import blah

Python reaches for the file "blah.py" or "blah/__init__.py" (this second
path is for "packages").



Yes, thank you.
--
https://mail.python.org/mailman/listinfo/python-list


Re: RuntimeError, or user defined exception

2022-02-04 Thread Cameron Simpson
On 04Feb2022 21:39, Cecil Westerhof  wrote:
>I am creating a class that will call a user defined function on user
>defined intervals. In my opinion it is an error when the function
>takes more as 10% of interval, or more as half a second. What is
>better: just using RuntimeError, or creating two exception classes for
>this?

You could reuse TimeoutError, a builtin exception raised by OS calls 
which time out: https://docs.python.org/3/library/exceptions.html#TimeoutError

I wouldn't use RuntimeError. Its core purpose is interpreter failures 
IIRC, and I use it myself for situations which should never occur - 
things indicating an actual bug in my code.

Specificly, I do not expect to try to catch RuntimeError, and broadly 
don't expect anything else too either (with some narrow exceptions).  
Whereas you would very reasonably catch TimeoutError as a situation 
which can readily occur. _Particularly_ with a tool which runs code 
supplied from outside - it _might_ do anything.

IMO your situation is a misbehaviour, not an internal bug. I'd reach for 
TimeoutError.

An example from my own code where I use a RuntimeError:

class FSTagsCommand(BaseCommand, TagsCommandMixin):
  ''' `fstags` main command line utility.
  '''
  GETOPT_SPEC = 'o:'
  [...]
  def apply_opt(self, opt, val):
''' Apply command line option.
'''
options = self.options
if opt == '-o':
  options.ontology_path = val
else:
  raise RuntimeError("unhandled option")

Here, the BaseCommand superclass parses command line options according 
to GETOPT_SPEC. The apply_opt() method gets called with any valid 
options. GETOPT_SPEC='o:', so seeing anything except '-o' in apply_opt() 
indicates a mismatch between GETOPT_SPEC and my apply_opt implementation 
(other options get rejected by BaseCommand). So _if_ my code gets there, 
that is an internal bug of my own.

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list