Bypassing firewall
How will i bypass web application firewall -- https://mail.python.org/mailman/listinfo/python-list
Re: Bypassing firewall
On Mon, Mar 5, 2018 at 7:37 PM, Faruq Bashir via Python-list wrote: > How will i bypass web application firewall Easy! Talk to the person who's in charge of it. Use a $5 wrench if you have to. https://xkcd.com/538/ ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Bypassing firewall
On Mon, 05 Mar 2018 08:37:14 +, Faruq Bashir wrote: > How will i bypass web application firewall For what purpose? is this your firewall? -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Monday, March 5, 2018 at 6:38:49 AM UTC, Mark Lawrence wrote:
> On 05/03/18 01:01, Ooomzay wrote:
> > On Sunday, 4 March 2018 23:57:24 UTC, Mark Lawrence wrote:
> >> On 04/03/18 02:28, Ooomzay wrote:
> >>> On Friday, 2 March 2018 15:37:25 UTC, Paul Moore wrote:
> >>> [snip]
> def fn():
> for i in range(1):
> with open(f"file{i}.txt", "w") as f:
> f.write("Some text")
>
> How would you write this in your RAII style - without leaving 10,000
> file descriptors open until the end of the function?
> >>>
> >>> def fn():
> >>> for i in range(1):
> >>> f = RAIIFile(f"file{i}.txt", "w")
> >>> f.write("Some text")
> >>>
> >
> >> Over my dead body.
> >
> > Care to expand on that?
> >
>
> Sure, when you state what you intend doing about reference cycles, which
> you've been asked about countless times.
Nothing. No change whatever. As I stated in my second post ref cycles are
orthogonal to this PEP.
If you want to use RAII objects then you will make sure you avoid adding them
to orphan cycles by design. If you don't know how to do that then don't write
applications that manage critical resources.
--
https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Sunday, 4 March 2018 23:56:09 UTC, Chris Angelico wrote:
> On Sun, Mar 4, 2018 at 10:37 PM, Ooomzay wrote:
> > Please consider the case of a composite resource: You need to implement
> > __enter__, __exit__ and track the open/closed state at every level in
> > your component hierarchy - even if some levels hold no resources directly.
> >
> > This is burdensome, breaks encapsulation, breaks invariance and is error
> > prone
> > ...very unpythonic.
>
> Why do you need to? I don't understand your complaint here - can you
> give an example of a composite resource that needs this kind of
> special management?
Here is an example of a composite resource using RAII:-
class RAIIFileAccess():
def __init__(self, fname):
print("%s Opened" % fname)
def __del__(self):
print("%s Closed" % fname)
class A():
def __init__(self):
self.res = RAIIFileAccess("a")
class B():
def __init__(self):
self.res = RAIIFileAccess("b")
class C():
def __init__(self):
self.a = A()
self.b = B()
def main():
c = C()
Under this PEP this is all that is needed to guarantee that the files "a"
and "b" are closed on exit from main or after any exception has been handled.
Also note that if you have a reference to these objects then they are
guaranteed to be in a valid/useable/open state (invariant) - no danger
or need to worry/check about enter/exit state.
Now repeat this exercise with "with".
--
https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Mon, Mar 5, 2018 at 10:09 PM, Ooomzay wrote:
> Here is an example of a composite resource using RAII:-
>
> class RAIIFileAccess():
> def __init__(self, fname):
> print("%s Opened" % fname)
> def __del__(self):
> print("%s Closed" % fname)
>
> class A():
> def __init__(self):
> self.res = RAIIFileAccess("a")
>
> class B():
> def __init__(self):
> self.res = RAIIFileAccess("b")
>
> class C():
> def __init__(self):
> self.a = A()
> self.b = B()
>
> def main():
> c = C()
>
> Under this PEP this is all that is needed to guarantee that the files "a"
> and "b" are closed on exit from main or after any exception has been handled.
Okay. And all your PEP needs is for reference count semantics, right?
Okay. I'm going to run this in CPython, with reference semantics. You
guarantee that those files will be closed after an exception is
handled? Right.
>>> def main():
... c = C()
... c.do_stuff()
...
>>> main()
a Opened
b Opened
Traceback (most recent call last):
File "", line 1, in
File "", line 3, in main
AttributeError: 'C' object has no attribute 'do_stuff'
>>>
Uhh I'm not seeing any messages about the files getting closed.
Maybe exceptions aren't as easy to handle as you think? Or maybe you
just haven't tried any of this (which is obvious from the bug in your
code - but even if I fix that, there's still a problem with exception
handling).
You keep insisting that this is an easy thing. We keep pointing out
that it isn't. Now you're proving that you haven't even attempted any
of this. Do you believe me now? (Probably not.)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Ways to make a free variable local to a function?
Hi, At the moment, in order to slightly speed up the function in Python, free variables are passed as local variables to the function, thereby getting rid of extra look ups. For example, for the following function, I especially do not use list comprehension) and therefore maybe it's not the best example: def func(numb): res = [] for i in range(numb): res.append(int(i) + float(i)) return res You can get rid of additional look ups, in the following ways: # 1. By passing through local variable's default values def func_local_1(numb, _int = int, _float = float, _range = range): res = [] for i in _range(numb): res.append(_int(i) + _float(i)) return res # 2. Through importing them into the function scope def func_local_2(numb): from builtins import int, float, range res = [] for i in range(numb): res.append(int(i) + float(i)) return res # 3. With the help of various types of closures, version 1 def func_closure_1(numb): _int = int _float = float _range = range def inner(numb): res = [] for i in _range(numb): res.append(_int(i) + _float(i)) return res return inner(numb) # 4. With the help of various types of closures, version 2 def func_closure_2(numb): from builtins import int, float, range def inner(numb): res = [] for i in range(numb): res.append(int(i) + float(i)) return res return inner(numb) Option 1 allows you to achieve the maximum result for both small and a large `numb` values. Option 2 yields a significant overhead, when it is required to call function many times with a small number of iterations. For option 3 and 4, notes are the same, but since they are implemented through closures they give additional small overhead. In case of big `numb` (many iterations, many look ups) these options give a gain of ~10%. Option 1 and 3 I do not like because: - syntax highlighting stops working - the signature function is greatly distorted - additional typing (especially with type annotations) I like options 2 and 4, but they yield a significant overhead, for a small number of iterations. Actually, I have the following question: 1. Is there any other way to make the variable local to the function? a. When you compile (define) a function... b. Inject into an already existing function through decorator...(is it possible?) p.s.: I had the following idea, maybe it was already discussed, the possibility of setting _static_ variables for functions, with the following syntax: def func(numb): static int, float, range res = [] for i in range(numb): res.append(int(i) + float(i)) return res Where identifiers for `static` should correspond to free variables for a function, they must be defined at compile time (like for default arguments) and can not be changed inside the function scope. With kind regards, -gdg -- https://mail.python.org/mailman/listinfo/python-list
Re: Ways to make a free variable local to a function?
On 3/5/2018 7:12 AM, Kirill Balunov wrote: Hi, At the moment, in order to slightly speed up the function in Python, free variables are passed as local variables to the function, thereby getting rid of extra look ups. For example, for the following function, I especially do not use list comprehension) and therefore maybe it's not the best example: def func(numb): res = [] for i in range(numb): res.append(int(i) + float(i)) return res You can get rid of additional look ups, in the following ways: # 1. By passing through local variable's default values def func_local_1(numb, _int = int, _float = float, _range = range): You are not required to mangle the names. def func_local_1(numb, int = int, float = float, range = range): ... res = [] for i in _range(numb): res.append(_int(i) + _float(i)) return res # 2. Through importing them into the function scope def func_local_2(numb): from builtins import int, float, range res = [] for i in range(numb): res.append(int(i) + float(i)) return res # 3. With the help of various types of closures, version 1 def func_closure_1(numb): _int = int _float = float _range = range def inner(numb): res = [] for i in _range(numb): res.append(_int(i) + _float(i)) return res return inner(numb) # 4. With the help of various types of closures, version 2 def func_closure_2(numb): from builtins import int, float, range def inner(numb): res = [] for i in range(numb): res.append(int(i) + float(i)) return res return inner(numb) Option 1 allows you to achieve the maximum result for both small and a large `numb` values. Option 2 yields a significant overhead, when it is required to call function many times with a small number of iterations. For option 3 and 4, notes are the same, but since they are implemented through closures they give additional small overhead. In case of big `numb` (many iterations, many look ups) these options give a gain of ~10%. Option 1 and 3 I do not like because: - syntax highlighting stops working Only because you unnecessarily mangle the names. - the signature function is greatly distorted - additional typing (especially with type annotations) I like options 2 and 4, but they yield a significant overhead, for a small number of iterations. Actually, I have the following question: 1. Is there any other way to make the variable local to the function? a. When you compile (define) a function... b. Inject into an already existing function through decorator...(is it possible?) p.s.: I had the following idea, maybe it was already discussed, the possibility of setting _static_ variables for functions, with the following syntax: def func(numb): static int, float, range res = [] for i in range(numb): res.append(int(i) + float(i)) return res Where identifiers for `static` should correspond to free variables for a function, they must be defined at compile time (like for default arguments) and can not be changed inside the function scope. With kind regards, -gdg -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Monday, 5 March 2018 11:24:37 UTC, Chris Angelico wrote:
> On Mon, Mar 5, 2018 at 10:09 PM, Ooomzay wrote:
> > Here is an example of a composite resource using RAII:-
> >
> > class RAIIFileAccess():
> > def __init__(self, fname):
> > print("%s Opened" % fname)
> > def __del__(self):
> > print("%s Closed" % fname)
> >
> > class A():
> > def __init__(self):
> > self.res = RAIIFileAccess("a")
> >
> > class B():
> > def __init__(self):
> > self.res = RAIIFileAccess("b")
> >
> > class C():
> > def __init__(self):
> > self.a = A()
> > self.b = B()
> >
> > def main():
> > c = C()
> >
> > Under this PEP this is all that is needed to guarantee that the files "a"
> > and "b" are closed on exit from main or after any exception has been
> > handled.
>
> Okay. And all your PEP needs is for reference count semantics, right?
> Okay. I'm going to run this in CPython, with reference semantics. You
> guarantee that those files will be closed after an exception is
> handled? Right.
>
> >>> def main():
> ... c = C()
> ... c.do_stuff()
> ...
> >>> main()
> a Opened
> b Opened
> Traceback (most recent call last):
> File "", line 1, in
> File "", line 3, in main
> AttributeError: 'C' object has no attribute 'do_stuff'
> >>>
>
> Uhh I'm not seeing any messages about the files getting closed.
Then that is indeed a challenge. From CPython back in 2.6 days up to
Python36-32 what I see is:-
a Opened
b Opened
Traceback (most recent call last):
...
AttributeError: 'C' object has no attribute 'dostuff'
a Closed
b Closed
> Maybe exceptions aren't as easy to handle as you think?
Well there is a general issue with exceptions owing to the ease
with which one can create cycles that may catch out newbs. But
that is not the case here.
> Or maybe you
> just haven't tried any of this (which is obvious from the bug in your
> code
Or maybe I just made a typo when simplifying my test case and failed to retest?
Here is my fixed case, if someone else could try it in CPython and report back
that would be interesting:-
class RAIIFileAccess():
def __init__(self, fname):
print("%s Opened" % fname)
self.fname = fname
def __del__(self):
print("%s Closed" % self.fname)
class A():
def __init__(self):
self.res = RAIIFileAccess("a")
class B():
def __init__(self):
self.res = RAIIFileAccess("b")
class C():
def __init__(self):
self.a = A()
self.b = B()
def main():
c = C()
c.dostuff()
main()
> You keep insisting that this is an easy thing. > We keep pointing out
> that it isn't. Now you're proving that you haven't even attempted any
> of this.
Nonsense. But you have got a result I have never seen in many years
and I would like to get to the bottom of it.
--
https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Tue, Mar 6, 2018 at 12:58 AM, Ooomzay wrote:
> Then that is indeed a challenge. From CPython back in 2.6 days up to
> Python36-32 what I see is:-
>
> a Opened
> b Opened
> Traceback (most recent call last):
> ...
> AttributeError: 'C' object has no attribute 'dostuff'
> a Closed
> b Closed
>
>> Maybe exceptions aren't as easy to handle as you think?
>
> Well there is a general issue with exceptions owing to the ease
> with which one can create cycles that may catch out newbs. But
> that is not the case here.
>
>> Or maybe you
>> just haven't tried any of this (which is obvious from the bug in your
>> code
>
> Or maybe I just made a typo when simplifying my test case and failed to
> retest?
>
> Here is my fixed case, if someone else could try it in CPython and report
> back that would be interesting:-
>
> class RAIIFileAccess():
> def __init__(self, fname):
> print("%s Opened" % fname)
> self.fname = fname
>
> def __del__(self):
> print("%s Closed" % self.fname)
>
> class A():
> def __init__(self):
> self.res = RAIIFileAccess("a")
>
> class B():
> def __init__(self):
> self.res = RAIIFileAccess("b")
>
> class C():
> def __init__(self):
> self.a = A()
> self.b = B()
>
> def main():
> c = C()
> c.dostuff()
>
> main()
Tried this in the interactive interpreter again.
>>> main()
a Opened
b Opened
Traceback (most recent call last):
File "", line 1, in
File "", line 3, in main
AttributeError: 'C' object has no attribute 'dostuff'
>>>
Same problem! If you can't handle this situation, there's something
fundamentally wrong with your system.
Here's how I'd do it with context managers.
from contextlib import contextmanager
@contextmanager
def file_access(fname):
try:
print("%s Opened" % fname)
yield
finally:
print("%s Closed" % fname)
@contextmanager
def c():
try:
print("Starting c")
with file_access("a") as a, file_access("b") as b:
yield
finally:
print("Cleaning up c")
def main():
with c():
dostuff() # NameError
>>> main()
Starting c
a Opened
b Opened
b Closed
a Closed
Cleaning up c
Traceback (most recent call last):
File "", line 1, in
File "", line 3, in main
NameError: name 'dostuff' is not defined
>>>
And if you want different semantics, you can lay out c() differently -
maybe have the try/finally not contain within the 'with' but be
contained within it, or whatever else you like. Exceptions move
through the stack exactly the way you'd expect them to. Instead of
having an object to represent each resource, you simply have a
function with the code needed to allocate and deallocate it. They nest
perfectly.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Monday, 5 March 2018 13:59:35 UTC, Ooomzay wrote:
> On Monday, 5 March 2018 11:24:37 UTC, Chris Angelico wrote:
> > On Mon, Mar 5, 2018 at 10:09 PM, Ooomzay wrote:
> > > Here is an example of a composite resource using RAII:-
> > >
> > > class RAIIFileAccess():
> > > def __init__(self, fname):
> > > print("%s Opened" % fname)
> > > def __del__(self):
> > > print("%s Closed" % fname)
> > >
> > > class A():
> > > def __init__(self):
> > > self.res = RAIIFileAccess("a")
> > >
> > > class B():
> > > def __init__(self):
> > > self.res = RAIIFileAccess("b")
> > >
> > > class C():
> > > def __init__(self):
> > > self.a = A()
> > > self.b = B()
> > >
> > > def main():
> > > c = C()
> > >
> > > Under this PEP this is all that is needed to guarantee that the files "a"
> > > and "b" are closed on exit from main or after any exception has been
> > > handled.
> >
> > Okay. And all your PEP needs is for reference count semantics, right?
> > Okay. I'm going to run this in CPython, with reference semantics. You
> > guarantee that those files will be closed after an exception is
> > handled? Right.
> >
> > >>> def main():
> > ... c = C()
> > ... c.do_stuff()
> > ...
> > >>> main()
> > a Opened
> > b Opened
> > Traceback (most recent call last):
> > File "", line 1, in
> > File "", line 3, in main
> > AttributeError: 'C' object has no attribute 'do_stuff'
> > >>>
> >
> > Uhh I'm not seeing any messages about the files getting closed.
>
> Then that is indeed a challenge. From CPython back in 2.6 days up to
> Python36-32 what I see is:-
>
> a Opened
> b Opened
> Traceback (most recent call last):
> ...
> AttributeError: 'C' object has no attribute 'dostuff'
> a Closed
> b Closed
>
> > Maybe exceptions aren't as easy to handle as you think?
>
> Well there is a general issue with exceptions owing to the ease
> with which one can create cycles that may catch out newbs. But
> that is not the case here.
>
> > Or maybe you
> > just haven't tried any of this (which is obvious from the bug in your
> > code
>
> Or maybe I just made a typo when simplifying my test case and failed to
> retest?
>
> Here is my fixed case, if someone else could try it in CPython and report
> back that would be interesting:-
>
> class RAIIFileAccess():
> def __init__(self, fname):
> print("%s Opened" % fname)
> self.fname = fname
>
> def __del__(self):
> print("%s Closed" % self.fname)
>
> class A():
> def __init__(self):
> self.res = RAIIFileAccess("a")
>
> class B():
> def __init__(self):
> self.res = RAIIFileAccess("b")
>
> class C():
> def __init__(self):
> self.a = A()
> self.b = B()
>
> def main():
> c = C()
> c.dostuff()
>
> main()
>
> > You keep insisting that this is an easy thing. > We keep pointing out
> > that it isn't. Now you're proving that you haven't even attempted any
> > of this.
>
> Nonsense. But you have got a result I have never seen in many years
> and I would like to get to the bottom of it.
Ahah... I see now you are running it from a shell so the exception is staying
in scope. We just need to include normal exception handling in the example to
fix this:-
class RAIIFileAccess():
def __init__(self, fname):
print("%s Opened" % fname)
self.fname = fname
def __del__(self):
print("%s Closed" % self.fname)
class A():
def __init__(self):
self.res = RAIIFileAccess("A")
class B():
def __init__(self):
self.res = RAIIFileAccess("B")
class C():
def __init__(self):
self.a = A()
self.b = B()
def main():
try:
c = C()
c.dostuff()
except:
print("Boom!")
main()
--
https://mail.python.org/mailman/listinfo/python-list
Re: Ways to make a free variable local to a function?
On Tue, Mar 6, 2018 at 12:52 AM, Terry Reedy wrote: > On 3/5/2018 7:12 AM, Kirill Balunov wrote: >> # 1. By passing through local variable's default values >> >> def func_local_1(numb, _int = int, _float = float, _range = range): > > > You are not required to mangle the names. > > def func_local_1(numb, int = int, float = float, range = range): > ... > Even so, this does mess up the function's signature, leaving your callers wondering if they can call it with some sort of range parameter. (Though in this particular instance, range() is only called once, so it's pretty much useless to try to optimize it.) In theory, the CPython bytecode compiler (don't know about other Python implementations) could just add these as constants. They'd then be bound at either compile time or function definition time (by default the former, I think, but the latter would be more useful), and be looked up as quickly as locals. I'm not sure how useful this would be, though. If PEP 572 [1] were to be accepted, you could do something like this: def func(numb): if ((int as int), (float as float)): res = [] for i in range(numb): res.append(int(i) + float(i)) return res Syntactically a bit clunky, but keeps everything inside the function, and DOES create local variables. Not sure it's better than your other options, but it is another option. [1] PEP 572: https://www.python.org/dev/peps/pep-0572/ ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Tue, Mar 6, 2018 at 1:25 AM, Ooomzay wrote:
> Ahah... I see now you are running it from a shell so the exception is staying
> in scope. We just need to include normal exception handling in the example to
> fix this:-
>
> def main():
> try:
> c = C()
> c.dostuff()
> except:
> print("Boom!")
>
> main()
>
So RAII depends on absorbing every exception close to where the
resource is being managed? You can't permit that exception to bubble
up lest the resource get leaked??
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Monday, 5 March 2018 14:36:30 UTC, Chris Angelico wrote:
> On Tue, Mar 6, 2018 at 1:25 AM, Ooomzay wrote:
> > Ahah... I see now you are running it from a shell so the exception is
> > staying in scope. We just need to include normal exception handling in the
> > example to fix this:-
> >
> > def main():
> > try:
> > c = C()
> > c.dostuff()
> > except:
> > print("Boom!")
> >
> > main()
> >
>
> So RAII depends on absorbing every exception close to where the
> resource is being managed? You can't permit that exception to bubble
> up lest the resource get leaked??
The exception can bubble up as many layers as you like but in python the
exception leaks out of the handling context and needs its scope limiting. I
have previously pointed out that such scoping is still recommended and that a
function is pythons scoping construct - so use them for the job.
--
https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On 05/03/2018 13:58, Ooomzay wrote:
On Monday, 5 March 2018 11:24:37 UTC, Chris Angelico wrote:
On Mon, Mar 5, 2018 at 10:09 PM, Ooomzay wrote:
Here is an example of a composite resource using RAII:-
class RAIIFileAccess():
def __init__(self, fname):
print("%s Opened" % fname)
def __del__(self):
print("%s Closed" % fname)
class A():
def __init__(self):
self.res = RAIIFileAccess("a")
class B():
def __init__(self):
self.res = RAIIFileAccess("b")
class C():
def __init__(self):
self.a = A()
self.b = B()
def main():
c = C()
Under this PEP this is all that is needed to guarantee that the files "a"
and "b" are closed on exit from main or after any exception has been handled.
Okay. And all your PEP needs is for reference count semantics, right?
Okay. I'm going to run this in CPython, with reference semantics. You
guarantee that those files will be closed after an exception is
handled? Right.
def main():
... c = C()
... c.do_stuff()
...
main()
a Opened
b Opened
Traceback (most recent call last):
File "", line 1, in
File "", line 3, in main
AttributeError: 'C' object has no attribute 'do_stuff'
Uhh I'm not seeing any messages about the files getting closed.
Then that is indeed a challenge. From CPython back in 2.6 days up to
Python36-32 what I see is:-
a Opened
b Opened
Traceback (most recent call last):
...
AttributeError: 'C' object has no attribute 'dostuff'
a Closed
b Closed
Maybe exceptions aren't as easy to handle as you think?
Well there is a general issue with exceptions owing to the ease
with which one can create cycles that may catch out newbs. But
that is not the case here.
Or maybe you
just haven't tried any of this (which is obvious from the bug in your
code
Or maybe I just made a typo when simplifying my test case and failed to retest?
Here is my fixed case, if someone else could try it in CPython and report back
that would be interesting:-
class RAIIFileAccess():
def __init__(self, fname):
print("%s Opened" % fname)
self.fname = fname
def __del__(self):
print("%s Closed" % self.fname)
class A():
def __init__(self):
self.res = RAIIFileAccess("a")
class B():
def __init__(self):
self.res = RAIIFileAccess("b")
class C():
def __init__(self):
self.a = A()
self.b = B()
def main():
c = C()
c.dostuff()
main()
I get A and B closed messages when running on CPython 2.7 and 3.6, with
the code run from a .py file. (I never use interactive mode.)
But not when running on a PyPy version of 2.7 (however that is not CPython).
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Monday, 5 March 2018 15:17:13 UTC, bartc wrote:
> On 05/03/2018 13:58, Ooomzay wrote:
> > On Monday, 5 March 2018 11:24:37 UTC, Chris Angelico wrote:
> >> On Mon, Mar 5, 2018 at 10:09 PM, Ooomzay wrote:
> >>> Here is an example of a composite resource using RAII:-
> >>>
> >>> class RAIIFileAccess():
> >>> def __init__(self, fname):
> >>> print("%s Opened" % fname)
> >>> def __del__(self):
> >>> print("%s Closed" % fname)
> >>>
> >>> class A():
> >>> def __init__(self):
> >>> self.res = RAIIFileAccess("a")
> >>>
> >>> class B():
> >>> def __init__(self):
> >>> self.res = RAIIFileAccess("b")
> >>>
> >>> class C():
> >>> def __init__(self):
> >>> self.a = A()
> >>> self.b = B()
> >>>
> >>> def main():
> >>> c = C()
> >>>
> >>> Under this PEP this is all that is needed to guarantee that the files "a"
> >>> and "b" are closed on exit from main or after any exception has been
> >>> handled.
> >>
> >> Okay. And all your PEP needs is for reference count semantics, right?
> >> Okay. I'm going to run this in CPython, with reference semantics. You
> >> guarantee that those files will be closed after an exception is
> >> handled? Right.
> >>
> > def main():
> >> ... c = C()
> >> ... c.do_stuff()
> >> ...
> > main()
> >> a Opened
> >> b Opened
> >> Traceback (most recent call last):
> >>File "", line 1, in
> >>File "", line 3, in main
> >> AttributeError: 'C' object has no attribute 'do_stuff'
> >
> >>
> >> Uhh I'm not seeing any messages about the files getting closed.
> >
> > Then that is indeed a challenge. From CPython back in 2.6 days up to
> > Python36-32 what I see is:-
> >
> > a Opened
> > b Opened
> > Traceback (most recent call last):
> > ...
> > AttributeError: 'C' object has no attribute 'dostuff'
> > a Closed
> > b Closed
> >
> >> Maybe exceptions aren't as easy to handle as you think?
> >
> > Well there is a general issue with exceptions owing to the ease
> > with which one can create cycles that may catch out newbs. But
> > that is not the case here.
> >
> >> Or maybe you
> >> just haven't tried any of this (which is obvious from the bug in your
> >> code
> >
> > Or maybe I just made a typo when simplifying my test case and failed to
> > retest?
> >
> > Here is my fixed case, if someone else could try it in CPython and report
> > back that would be interesting:-
> >
> > class RAIIFileAccess():
> > def __init__(self, fname):
> > print("%s Opened" % fname)
> > self.fname = fname
> >
> > def __del__(self):
> > print("%s Closed" % self.fname)
> >
> > class A():
> > def __init__(self):
> > self.res = RAIIFileAccess("a")
> >
> > class B():
> > def __init__(self):
> > self.res = RAIIFileAccess("b")
> >
> > class C():
> > def __init__(self):
> > self.a = A()
> > self.b = B()
> >
> > def main():
> > c = C()
> > c.dostuff()
> >
> > main()
>
> I get A and B closed messages when running on CPython 2.7 and 3.6, with
> the code run from a .py file. (I never use interactive mode.)
>
> But not when running on a PyPy version of 2.7 (however that is not CPython).
Thanks bartc, I have made the example more complete by adding an exception
scope - this means it works as designed - in any context. See my reply to Chris.
We do not expect this to work in PyPy.
--
https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Sun, 04 Mar 2018 16:58:38 -0800, Ooomzay wrote:
> Here is an example of a composite resource using RAII:-
>
> class RAIIFileAccess():
> def __init__(self, fname):
> print("%s Opened" % fname)
> def __del__(self):
> print("%s Closed" % fname)
>
> class A():
> def __init__(self):
> self.res = RAIIFileAccess("a")
>
> class B():
> def __init__(self):
> self.res = RAIIFileAccess("b")
>
> class C():
> def __init__(self):
> self.a = A()
> self.b = B()
>
> def main():
> c = C()
Looking at that code, my major thought is that there is far too much OO
design, not enough simplicity.
Perhaps I'm missing something, but I have no idea what benefit there is
in that style of code over:
with open('a') as a:
with open('b') as b:
process(a, b)
So long as you only process a or b inside the nested block, you are
guaranteed that they will be open.
And unlike your RAII example, they will be closed when you exit,
regardless of how many references to them you have, regardless of whether
an exception occurs or not, regardless of whether there are cycles or
whether they are globals or whether the interpreter is shutting down.
I think that at this point, you have convinced me that you want to impose
enormous costs on all Python interpreters *and* Python developers, in
order to allow you to write C++ code in Python rather than learn Pythonic
idioms like the with statement.
I don't think this is a good tradeoff.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Mon, 05 Mar 2018 07:31:57 -0800, Ooomzay wrote: > We do not expect this to work in PyPy. Or Jython, IronPython, possibly not Stackless either, or in the interactive interpreter of (probably) any implementation, or CPython if the object is garbage collected during interpreter shutdown or is in a cycle or has a global reference, or if the object simply doesn't go out of scope as quickly as you would like. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Monday, 5 March 2018 16:47:02 UTC, Steven D'Aprano wrote:
> On Sun, 04 Mar 2018 16:58:38 -0800, Ooomzay wrote:
>
> > Here is an example of a composite resource using RAII:-
> >
> > class RAIIFileAccess():
> > def __init__(self, fname):
> > print("%s Opened" % fname)
> > def __del__(self):
> > print("%s Closed" % fname)
> >
> > class A():
> > def __init__(self):
> > self.res = RAIIFileAccess("a")
> >
> > class B():
> > def __init__(self):
> > self.res = RAIIFileAccess("b")
> >
> > class C():
> > def __init__(self):
> > self.a = A()
> > self.b = B()
> >
> > def main():
> > c = C()
>
> Looking at that code, my major thought is that there is far too much OO
> design, not enough simplicity.
If this is far too much OO for you then RAII will be of no
interest to you.
This example was specifically in response to a request to
illustrate the relative simplicity of RAII in the case of a
composite (OO) resource.
> Perhaps I'm missing something, but I have no idea what benefit there is
> in that style of code over:
>
> with open('a') as a:
> with open('b') as b:
> process(a, b)
Encapsulation. Your application code is now managing details
that should be hidden in the object. This PEP and RAII are
unashamedly targeted at OO designs.
If you would like to have a shot at coding this without RAII,
but preserving the OO design, you will find that it is
considerably _simpler_ than the with/context manager approach.
> So long as you only process a or b inside the nested block, you are
> guaranteed that they will be open.
>
> And unlike your RAII example, they will be closed when you exit,
> regardless of how many references to them you have, regardless of whether
> an exception occurs or not, regardless of whether there are cycles or
> whether they are globals or whether the interpreter is shutting down.
If you choose RAII you will not be cavalier with your references.
> I think that at this point, you have convinced me that you want to impose
> enormous costs on all Python interpreters *and* Python developers, in
> order to allow you to write C++ code in Python rather than learn Pythonic
> idioms like the with statement.
On interpreters yes. On developers no. You can carry on exactly as you are.
--
https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Monday, 5 March 2018 14:21:54 UTC, Chris Angelico wrote:
> On Tue, Mar 6, 2018 at 12:58 AM, Ooomzay wrote:
> > Here is my fixed example, if someone else could try it in CPython and
> > report back that would be interesting:-
> >
> > class RAIIFileAccess():
> > def __init__(self, fname):
> > print("%s Opened" % fname)
> > self.fname = fname
> >
> > def __del__(self):
> > print("%s Closed" % self.fname)
> >
> > class A():
> > def __init__(self):
> > self.res = RAIIFileAccess("a")
> >
> > class B():
> > def __init__(self):
> > self.res = RAIIFileAccess("b")
> >
> > class C():
> > def __init__(self):
> > self.a = A()
> > self.b = B()
> >
> > def main():
> > c = C()
> > c.dostuff()
> >
> > main()
>
> Here's how I'd do it with context managers.
>
> from contextlib import contextmanager
>
> @contextmanager
> def file_access(fname):
> try:
> print("%s Opened" % fname)
> yield
> finally:
> print("%s Closed" % fname)
>
> @contextmanager
> def c():
> try:
> print("Starting c")
> with file_access("a") as a, file_access("b") as b:
> yield
> finally:
> print("Cleaning up c")
>
> def main():
> with c():
> dostuff() # NameError
Thank you for having a go...
However you have broken the encapsulation of class A and B. These
are trivial for the sake of example. I should have used
_underscores (i.e. self._res) to make the intent of
this example more obvious.
Please try again but preserving the integrity/encapsulation
of class A & B & C, just as the RAII example does.
--
https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Tue, Mar 6, 2018 at 4:53 AM, Ooomzay wrote:
> On Monday, 5 March 2018 14:21:54 UTC, Chris Angelico wrote:
>> On Tue, Mar 6, 2018 at 12:58 AM, Ooomzay wrote:
>> > Here is my fixed example, if someone else could try it in CPython and
>> > report back that would be interesting:-
>> >
>> > class RAIIFileAccess():
>> > def __init__(self, fname):
>> > print("%s Opened" % fname)
>> > self.fname = fname
>> >
>> > def __del__(self):
>> > print("%s Closed" % self.fname)
>> >
>> > class A():
>> > def __init__(self):
>> > self.res = RAIIFileAccess("a")
>> >
>> > class B():
>> > def __init__(self):
>> > self.res = RAIIFileAccess("b")
>> >
>> > class C():
>> > def __init__(self):
>> > self.a = A()
>> > self.b = B()
>> >
>> > def main():
>> > c = C()
>> > c.dostuff()
>> >
>> > main()
>>
>> Here's how I'd do it with context managers.
>>
>> from contextlib import contextmanager
>>
>> @contextmanager
>> def file_access(fname):
>> try:
>> print("%s Opened" % fname)
>> yield
>> finally:
>> print("%s Closed" % fname)
>>
>> @contextmanager
>> def c():
>> try:
>> print("Starting c")
>> with file_access("a") as a, file_access("b") as b:
>> yield
>> finally:
>> print("Cleaning up c")
>>
>> def main():
>> with c():
>> dostuff() # NameError
>
>
> Thank you for having a go...
>
> However you have broken the encapsulation of class A and B. These
> are trivial for the sake of example. I should have used
> _underscores (i.e. self._res) to make the intent of
> this example more obvious.
>
> Please try again but preserving the integrity/encapsulation
> of class A & B & C, just as the RAII example does.
What is B? Is it something that's notionally a resource to be managed?
If so, you can trivially add another level to the nesting.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Ways to make a free variable local to a function?
On 3/5/2018 9:34 AM, Chris Angelico wrote: On Tue, Mar 6, 2018 at 12:52 AM, Terry Reedy wrote: On 3/5/2018 7:12 AM, Kirill Balunov wrote: # 1. By passing through local variable's default values def func_local_1(numb, _int = int, _float = float, _range = range): You are not required to mangle the names. def func_local_1(numb, int = int, float = float, range = range): ... Even so, this does mess up the function's signature, Which I why I only said that using the original names solves the syntax highlighting issue (of marking built-ins as built-ins). leaving your callers wondering if they can call it with some sort of range parameter. (Though in this particular instance, range() is only called once, so it's pretty much useless to try to optimize it.) In theory, the CPython bytecode compiler (don't know about other Python implementations) could just add these as constants. Yes, what we really want for this sort of thing are unrebindable local constants. A simple syntax change could do it. def func_local_1(numb; int = int, float = float, range = range): The binding after ';' belong in the header because they should be done once. They'd then be bound at either compile time or function definition time (by default the former, I think, but the latter would be more useful), and be looked up as quickly as locals. I'm not sure how useful this would be, though. I believe that the occasional practice of re-binding built-in names to locals can be shown to speed up loops run enough times. If PEP 572 [1] were to be accepted, you could do something like this: def func(numb): if ((int as int), (float as float)): res = [] for i in range(numb): res.append(int(i) + float(i)) return res Syntactically a bit clunky, but keeps everything inside the function, and DOES create local variables. Not sure it's better than your other options, but it is another option. Code in the body should be executed everytime the function is called. Those binding should not be as they only need to be done once. [1] PEP 572: https://www.python.org/dev/peps/pep-0572/ -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Bitstream -- Binary Data for Humans
Hi everyone, I have released bitstream, a Python library to manage binary data (at the byte or bit level), hopefully without the pain that this kind of thing usually entails :) If you have struggled with this topic in the past, please take a look at the documentation (http://boisgera.github.io/bitstream/) and tell me what you think. Cheers, Sébastien -- https://mail.python.org/mailman/listinfo/python-list
Re: Bitstream -- Binary Data for Humans
Thanks On 6/03/2018 7:13 AM, "Sébastien Boisgérault" < [email protected]> wrote: Hi everyone, I have released bitstream, a Python library to manage binary data (at the byte or bit level), hopefully without the pain that this kind of thing usually entails :) If you have struggled with this topic in the past, please take a look at the documentation (http://boisgera.github.io/bitstream/) and tell me what you think. Cheers, Sébastien -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Monday, 5 March 2018 17:58:40 UTC, Chris Angelico wrote:
> On Tue, Mar 6, 2018 at 4:53 AM, Ooomzay wrote:
> > On Monday, 5 March 2018 14:21:54 UTC, Chris Angelico wrote:
> >> On Tue, Mar 6, 2018 at 12:58 AM, Ooomzay wrote:
> >> > Here is my fixed example, if someone else could try it in CPython and
> >> > report back that would be interesting:-
> >> >
> >> > class RAIIFileAccess():
> >> > def __init__(self, fname):
> >> > print("%s Opened" % fname)
> >> > self.fname = fname
> >> >
> >> > def __del__(self):
> >> > print("%s Closed" % self.fname)
> >> >
> >> > class A():
> >> > def __init__(self):
> >> > self.res = RAIIFileAccess("a")
> >> >
> >> > class B():
> >> > def __init__(self):
> >> > self.res = RAIIFileAccess("b")
> >> >
> >> > class C():
> >> > def __init__(self):
> >> > self.a = A()
> >> > self.b = B()
> >> >
> >> > def main():
> >> > c = C()
> >> > c.dostuff()
> >> >
> >> > main()
> >>
> >> Here's how I'd do it with context managers.
> >>
> >> from contextlib import contextmanager
> >>
> >> @contextmanager
> >> def file_access(fname):
> >> try:
> >> print("%s Opened" % fname)
> >> yield
> >> finally:
> >> print("%s Closed" % fname)
> >>
> >> @contextmanager
> >> def c():
> >> try:
> >> print("Starting c")
> >> with file_access("a") as a, file_access("b") as b:
> >> yield
> >> finally:
> >> print("Cleaning up c")
> >>
> >> def main():
> >> with c():
> >> dostuff() # NameError
> >
> >
> > Thank you for having a go...
> >
> > However you have broken the encapsulation of class A and B. These
> > are trivial for the sake of example. I should have used
> > _underscores (i.e. self._res) to make the intent of
> > this example more obvious.
> >
> > Please try again but preserving the integrity/encapsulation
> > of class A & B & C, just as the RAII example does.
>
> What is B? Is it something that's notionally a resource to be managed?
Yes. For example a supply of electrical power controlled via a serial protocol
to a programmable power supply - the file is a private detail used for the
communications. And lets imagine that this powersupply object needs to keep
track of some state such as the voltage - and it has a long lifetime - not just
created then destroyed in scope of one function i.e. it is a substantial object.
> If so, you can trivially add another level to the nesting.
Please illustrate. I really do want to be able to compare like for like.
--
https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Monday, 5 March 2018 19:14:05 UTC, Paul Rubin wrote: > Ooomzay writes: > > If you want to use RAII objects then you will make sure you avoid > > adding them to orphan cycles by design. If you don't know how to do > > that then don't write applications that manage critical resources. > > My claim is managing critical resources with refcounts is bug-prone in > the case where the refcounts can become arbitrarily large at runtime. What case is that? Don't go there! You may be jaded because python forgives bad design practices and peeps are inclined to leak resources all over the place for no good reason whatever and then complain when they have trouble cleaning up or exiting! > You say you wrote a program that worked that way, but it sounds > horrendous and I'd like to know how you tested it, maintained it, kept > it maintainable by other programmers, etc. > It's painful to even think about. I too used to suffer pain with python - until I saw that light and worked out how to use it for RAII. So here's the keys for much less pain:- * Use CPython (or C++ ;) * Use RAII for every resource-holding class: Implement __del__ to release any resources acquired in __init__. (This is significantly less effort, and more reliable than adding __enter__ & __exit__ to every class). * Wrap your try-except blocks in functions to prevent exceptions persisting outside the handler because in python they leak. This is typically a very natural factorization. * Take care not to create Cyclic Exceptions in your Exception handling logic. This was the one that had me scratching my head for a couple of hours the first time I inadvertantly created a cycle. * If you have no application-level requirement for persistent orphan cycles, and few, if any, applications do, then disable gc on entry and raise an exception on exit, or any other convenient moment if there is any garbage to be collected. * Immediately plug/bug any leaks that you discover. Do not let them build up or you will drown and loose faith that there can be a better way. -- https://mail.python.org/mailman/listinfo/python-list
Re: "built-in" callables?
Stefan Ram wrote: . So, what does "built-in" in the sense of »isbuiltin« actually mean? It means "implemented in C". Yes, this is confusing. The term "built-in" is used in two different ways, and you just have to disambiguate them from context. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Mon, 05 Mar 2018 09:22:33 -0800, Ooomzay wrote:
[...]
>> Looking at that code, my major thought is that there is far too much
>> OO design, not enough simplicity.
>
> If this is far too much OO for you then RAII will be of no interest to
> you.
I think this is probably the wisest thing you have said in this entire
discussion. OO design is often over-rated and elevated to the position of
Holy Writ, full of over-engineered design patterns needed to overcome the
flaws of OO design. I see no reason to design my application using OO
principles when they aren't needed.
You say you have had great success with the RAII pattern in your own
Python code. Great! I mean that sincerely. I'm really happy for you. But
you now want to force that on *everyone*, even onto implementers where
this will be an enormous burden to re-write their interpreter from the
ground up to add a reference counter.
Why?
Do you have even the tiniest interest in running your RAII application
under IronPython or Jython? Why do you care that your code, using CPython-
only features, must be portable to other implementations?
If your PEP is accepted, will you be volunteering your time for the next
two or four years to re-write Jython and IronPython? To say nothing of
PyPy and possibly Stackless?
CPython does what you want. So be satisfied that if you target CPython,
you can use the RAII pattern to your heart's desire.
[...]
>> Perhaps I'm missing something, but I have no idea what benefit there is
>> in that style of code over:
>>
>> with open('a') as a:
>> with open('b') as b:
>> process(a, b)
>
> Encapsulation. Your application code is now managing details that should
> be hidden in the object. This PEP and RAII are unashamedly targeted at
> OO designs.
Encapsulation for the sake of encapsulation leads to monstrously over-
engineered heights of abstraction. Without a concrete use-case, I have no
confidence that this *should* be "hidden in the object". Even if it
should, I have no confidence that this specific design for encapsulation
and/or data hiding[1] (they aren't the same thing) is the best design.
> If you would like to have a shot at coding this without RAII, but
> preserving the OO design, you will find that it is considerably
> _simpler_ than the with/context manager approach.
Preserving the OO design, you say? Okay, since my application apparently
isn't allowed to know that it is processing two files, I'll simply
delegate that to the object:
class C(A, B):
def run(self):
with open(self.a) as a:
with open(self.b) as b:
process(a, b)
# Later.
if __name__ = '__main__':
# Enter the Kingdom of Nouns.
c = C()
c.run()
There you go. Encapsulation and OO design.
Look, I'm sure that we could go back and forth for weeks trading more and
more complicated, convoluted, esoteric or just plain unlikely scenarios
leading up to the conclusion you want. I'm even willing to accept for the
sake of discussion that in *your specific application's case*, you have
come up with the best possible solution.
I'm not trying to dissuade you from using RAII in your own applications,
if it works for you, great.
But I think it is unjustified to try to force that on all implementers
unless you have a real need, not just as a matter of principle, to use
RAII while still insisting on your code being implementation independent.
[...]
> If you choose RAII you will not be cavalier with your references.
You mean, "if you choose RAII, you cannot afford to be cavalier with your
references, because if you fail to meet the rigorous demands of this
pattern, your code will be buggy".
CPython has a long history of people relying on RAII and ending up with
buggy code that doesn't close resources in a timely manner. The reason
the with statement was invented was to be a simple and effective
alternative to the RAII pattern, which promises the world in theory and
fails to deliver in practice when it runs up against the reality that
most people *are* cavalier with their references.
Not for you, obviously. I'm glad that it works for you. But as a
community, we've been there and done that.
[1] They aren't the same thing.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: Bitstream -- Binary Data for Humans
Sébastien Boisgérault schreef op 5/03/2018 20:05: I have released bitstream, a Python library to manage binary data (at the byte or bit level), > hopefully without the pain that this kind of thing usually entails :) If you have struggled with this topic in the past, please take a look at the documentation > (http://boisgera.github.io/bitstream/) and tell me what you think. Hi Sébastien, At work I have some Python code to decode AIS[1] messages, for which I created my own code for handling binary data. It works, but is pretty slow. Not surprising, since handling data at the bit level is not exactly Python's strength. If I find the time, I'll try to replace my code with your bitstream and see if it does what I need it to do, and if it's any faster. If/when I actually get around to it, I'll keep you informed. [1] https://en.wikipedia.org/wiki/Automatic_identification_system Best regards, Roel -- The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom. -- Isaac Asimov Roel Schroeven -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Sat, Mar 03, 2018 at 08:18:03AM +1100, Chris Angelico wrote: > > Python is often a preferred solution because it is often fantastic for > > rapid implementation and maintainability. The GIL's interference > > with threaded code performance has, for me at least, on several > > occasions been... disappointing (perf costs of removing it aside) > > because it gets in the way of choosing Python for such solutions. > > Jython and IronPython are simply not feasible options for me, for > > multiple reasons that have zero to do with their technical > > suitability. > > Have you actually tried it and run into problems, Yes. It was years ago and I forget the details, but I even posted some sample code here and was told (quite possibly by you) that it was the GIL that was eating my lunch. Someone suggested writing the bits I wanted to thread as a C extension, which largely defeated the purpose of using Python. In at least one case I just used C++, and in another I just ignored the problem until it went away. -- https://mail.python.org/mailman/listinfo/python-list
Re: RFC: Proposal: Deterministic Object Destruction
On Tue, Mar 6, 2018 at 10:04 AM, Steven D'Aprano wrote: > # Later. > if __name__ = '__main__': > # Enter the Kingdom of Nouns. Don't you need a NounKingdomEnterer to do that for you? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Mon, Mar 5, 2018 at 3:53 PM, Python wrote: > On Sat, Mar 03, 2018 at 08:18:03AM +1100, Chris Angelico wrote: >> > Python is often a preferred solution because it is often fantastic for >> > rapid implementation and maintainability. The GIL's interference >> > with threaded code performance has, for me at least, on several >> > occasions been... disappointing (perf costs of removing it aside) >> > because it gets in the way of choosing Python for such solutions. >> > Jython and IronPython are simply not feasible options for me, for >> > multiple reasons that have zero to do with their technical >> > suitability. >> >> Have you actually tried it and run into problems, > > Yes. It was years ago and I forget the details, but I even posted > some sample code here and was told (quite possibly by you) that it was > the GIL that was eating my lunch. Someone suggested writing the bits > I wanted to thread as a C extension, which largely defeated the > purpose of using Python. In at least one case I just used C++, and in > another I just ignored the problem until it went away. So how about a little Cython? It has decent GIL control, isn't much different from Python syntactically, and can be used to create C extension modules callable from CPython. It allows you to pretty freely intermix Python data types and C data types - just be careful about implicit conversions from one to the other - they can slow things down. -- https://mail.python.org/mailman/listinfo/python-list
How to access the help page of SRE_Pattern?
Hi,
>>> import re
>>> prog=re.compile('[a-f]+')
>>> help(prog)
I can use the above command to access SRE_Pattern. But this involves
the creation of an object of the class.
I tried to directly access the class. But it does not work. Does
anybody know if there is a way to directly access the class help page?
Thanks.
>>> help(_sre.SRE_Pattern)
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'module' object has no attribute 'SRE_Pattern'
>>> help(SRE_Pattern)
Traceback (most recent call last):
File "", line 1, in
NameError: name 'SRE_Pattern' is not defined
--
Regards,
Peng
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to access the help page of SRE_Pattern?
On Mon, 05 Mar 2018 18:13:59 -0600, Peng Yu wrote:
> Hi,
>
import re
prog=re.compile('[a-f]+')
help(prog)
>
> I can use the above command to access SRE_Pattern. But this involves the
> creation of an object of the class.
If you're using help() interactively, the cost of creating the instance
is about a millionth of the cost of actually reading the help text.
help(re.compile(''))
should be perfectly acceptable, performance-wise, even though it is a
tiny bit longer to write than:
help(re)
If you really want a reference to the SRE_Pattern class, I'm afraid it is
not public name. It is technically an implementation detail subject to
change without notice. It could change its name, its internal details,
its location, so long as it still offers the public regular expression
interface.
I believe that SRE_Pattern is a built-in class, literally built into the
interpreter.
The best way to get access to it is to do this once, at the beginning of
your code:
SRE_Pattern = type(re.compile(''))
If you are doing this in the interactive interpreter, you might want to
include that in your Python startup file.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
Re: "except" and "subclasscheck" changed between CPython2 and 3
On Sat, 03 Mar 2018 04:28:24 +, 高岡陽太 wrote: > Hello, > > I found a difference of behavior about `except` statement between > CPython 2.7 and 3.x . > `except EXC_CLASS:` calls `__subclasscheck__` in 2.7, but does not in > 3.x . Python 3 does not accept virtual subclasses for exception handling. They have to be concrete subclasses of BaseException. There is a feature-request to support that (as Python 2.7 does): https://bugs.python.org/issue12029 but it is stalled. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
