CyberRoam Python Alternative for network security
This is question more about product information and less technical but Hope It will be use-able at some context, I use Cyeberoam(https://www.cyberoam.com/) Is there any Python alternative available for that? or If I have to write/implement something like this(https://github.com/netkiller/firewall) should I need to install it inside every computer or I can create a server and all the internet requests will pass through that, But that will be slow down the speed of the internet as well? -- https://mail.python.org/mailman/listinfo/python-list
Re: Clean Singleton Docstrings
Rob Gaddi wrote:
> I've got a package that contains a global ensmartened dict that allows
> all the various parts of my program to share state. Things like device
> handles, information about the application environment, etc. that are
> inherantly global (i.e. we're not having that debate).
>
> Implementation is:
>
> class _Registry(UserDict):
> """Docstring!"""
> ...
> Registry = _Registry()
>
> So Registry is now a globally accessible mutable object; no reason to
> complicate things with singletons or borgs or whathave you. From
> within the interactive console, help(foobar.Registry) gives me the
> _Registry documentation as expected.
>
> From the (Linux) command line though:
> $ pydoc3 foobar._Registry
> [lots of good documentation stuff]
> $ pydoc3 foobar.Registry
> no Python documentation found for 'foobar.Registry'
>
> Is this a thing that can be fixed with a commensurate amount of effort?
There is a test
if not object:
raise ImportError('no Python documentation found for %r' % thing)
in the pydoc module. So all you need is to ensure that your Registry
evaluates to True in a boolean context, e. g. by putting something into it:
$ cat foobar.py
from collections import UserDict
class _Registry(UserDict):
"""Docstring!"""
Registry = _Registry()
Registry["dummy"] = 42
$ pydoc3 foobar.Registry | head -n 10
Help on _Registry in foobar object:
foobar.Registry = class _Registry(collections.UserDict)
| Docstring!
|
| Method resolution order:
| _Registry
| collections.UserDict
| collections.abc.MutableMapping
| collections.abc.Mapping
You might also file a bug report asking to replace
if not object: ...
with
if object is None: ...
--
https://mail.python.org/mailman/listinfo/python-list
Re: Clean Singleton Docstrings
Peter Otten wrote: > You might also file a bug report asking to replace I take that back; the problem is fixed in Python 3.5. -- https://mail.python.org/mailman/listinfo/python-list
Re: Clean Singleton Docstrings
On Friday, July 8, 2016 at 1:15:04 PM UTC+5:30, Peter Otten wrote [slightly edited] > Peter Otten wrote: > > > You might also file a bug report asking to replace > > if not object: ... > > > > with > > > >if object is None: ... > > I take that back; the problem is fixed in Python 3.5. Hoo boy! And then there are those that claim that bool vs boolishness true vs True is cakewalk -- https://mail.python.org/mailman/listinfo/python-list
Re: Clean Singleton Docstrings
On Fri, 8 Jul 2016 05:38 pm, Peter Otten wrote:
[...]
>> Is this a thing that can be fixed with a commensurate amount of effort?
>
> There is a test
>
> if not object:
> raise ImportError('no Python documentation found for %r' % thing)
>
> in the pydoc module. So all you need is to ensure that your Registry
> evaluates to True in a boolean context, e. g. by putting something into
> it:
Nicely spotted! I had seen the test but hadn't realised the implications.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Clean Singleton Docstrings
Steven D'Aprano wrote:
> On Fri, 8 Jul 2016 05:38 pm, Peter Otten wrote:
>
> [...]
>>> Is this a thing that can be fixed with a commensurate amount of effort?
>>
>> There is a test
>>
>> if not object:
>> raise ImportError('no Python documentation found for %r' % thing)
>>
>> in the pydoc module. So all you need is to ensure that your Registry
>> evaluates to True in a boolean context, e. g. by putting something into
>> it:
>
>
> Nicely spotted! I had seen the test but hadn't realised the implications.
>
As speedy problem resolutions go, before I mentioned it is pretty good.
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Clean Singleton Docstrings
Michael Selik wrote: > > >> On Jul 7, 2016, at 7:46 PM, Rob Gaddi >> wrote: >> >> I've got a package that contains a global ensmartened dict that allows >> all the various parts of my program to share state. > > The simplest solution would be to use a module as your singleton. For > example, "registry.py" would work. Pydoc will show its docstring, and it will > have all the features you had been using, with the added benefit of not > needing to enforce its singletonness. > REALLY needs to be an object, preferably dict-like. For instance, one of the things it does is provide a .getKeyChanged(self, key) method that returns a keyChanged QSignal so that various elements of the program can all register for notifications triggered by __setitem__. That way, when Registry['dut'] gets updated, all of the various GUI elements reliant on information about the dut all dump their old data and find out about the newly connected device. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix. -- https://mail.python.org/mailman/listinfo/python-list
Re: Clean Singleton Docstrings
On 07/08/2016 09:57 AM, Rob Gaddi wrote: Michael Selik wrote: On Jul 7, 2016, at 7:46 PM, Rob Gaddi wrote: I've got a package that contains a global ensmartened dict that allows all the various parts of my program to share state. The simplest solution would be to use a module as your singleton. For example, "registry.py" would work. Pydoc will show its docstring, and it will have all the features you had been using, with the added benefit of not needing to enforce its singletonness. REALLY needs to be an object, preferably dict-like. For instance, one of the things it does is provide a .getKeyChanged(self, key) method that returns a keyChanged QSignal so that various elements of the program can all register for notifications triggered by __setitem__. That way, when Registry['dut'] gets updated, all of the various GUI elements reliant on information about the dut all dump their old data and find out about the newly connected device. Get the best of both worlds -- insert your Registry object into sys.modules. It is then importable from anywhere, yet still has all its native object power. Something like this should do the trick: # untested import sys sys.modules['%s.registry' % __name__] = _Register() and then elsewhere: from blah import registery registry.whatever() -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
input vs. readline
If "readline" is imported, "input" gets "readline" capabilities. It also loses the ability to import control characters. It doesn't matter where "readline" is imported; an import in some library module can trigger this. You can try this with a simple test case: print(repr(input())) as a .py file, run in a console. Try typing "aaaESCbbb". On Windows 7, output is "bbb". On Linux, it's "aaa\x1". So it looks like "readline" is implicitly imported on Windows. I have a multi-threaded Python program which recognizes ESC as a command to stop something. This works on Linux, but not on Windows. Apparently something in Windows land pulls in "readline". What's the best way to get input from the console (not any enclosing shell script) that's cross-platform, cross-version (Python 2.7, 3.x), and doesn't do "readline" processing? (No, I don't want to use signals, a GUI, etc. This is simulating a serial input device while logging messages appear. It's a debug facility to be able to type input in the console window.) John Nagle -- https://mail.python.org/mailman/listinfo/python-list
Re: input vs. readline
On 08Jul2016 16:17, John Nagle wrote: If "readline" is imported, "input" gets "readline" capabilities. It also loses the ability to import control characters. It doesn't matter where "readline" is imported; an import in some library module can trigger this. You can try this with a simple test case: print(repr(input())) as a .py file, run in a console. Try typing "aaaESCbbb". On Windows 7, output is "bbb". On Linux, it's "aaa\x1". So it looks like "readline" is implicitly imported on Windows. _Or_ that the Windows console app does its own input processing. I would be _very_ surprised if Python were behaving differently on the two platforms in this regard, though it is possible. (Disclaimer: I pretty much don't use Windows). Remember that any terminal program does some processing of keystrokes before they reach your program, even if that is "no" processing. On a UNIX system this is called the "line discipline", and doubtless Windows does something of that nature. On a UNIX system in normal circumstances your terminal's line discipline is in "cooked" mode, where various things happen to the raw bytes delivered by the terminal emulator. For example, when you press which sends byte 13, in cooked mode, this is converted the a newline (byte 10) for receipt by the program. Also in cooked mode, backspace (or DEL, depends, see "stty -a") is handled by the line disciple: your program sees the text as it was _after_ you did all the backspacing. And so forth. Perhaps the Windows console is treating ESC specially, apparently as "line erase", discarduing any preceeding text. Hence your results. On a UNIX program the normal thing would be to either to: - accept this, and use the liternal-next kestroke (usually ^V) to tell it not to the bytes special to the line discipline. So you might type ^V^H to get a literal ^H code in your input and so forth. - use termios to turn off all the control keystrokes (erase, kill and so forth) - put the terminal into "raw" mode where keystroke bytes are sent through unchanged (although them you need to hand carriage return yourself, etc) Perhaps Windows has a "literal-next" keystroke line UNIX does. I have a multi-threaded Python program which recognizes ESC as a command to stop something. This works on Linux, but not on Windows. Apparently something in Windows land pulls in "readline". Unlikely. See above. What's the best way to get input from the console (not any enclosing shell script) that's cross-platform, cross-version (Python 2.7, 3.x), and doesn't do "readline" processing? sys.stdin.readline() input() is a conveience function, now very low level. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: input vs. readline
On 7/8/2016 7:17 PM, John Nagle wrote: If "readline" is imported, "input" gets "readline" capabilities. It also loses the ability to import control characters. It doesn't matter where "readline" is imported; an import in some library module can trigger this. You can try this with a simple test case: print(repr(input())) as a .py file, run in a console. Try typing "aaaESCbbb". On Windows 7, output is "bbb". The escape key erasing input back to the beginning of the line is Command Prompt or cmd.exe behavior. Type anything at a normal command prompt and hit ESC. Input one. It has nothing to do with Python or the readline module. On Linux, it's "aaa\x1". The interpretation of control characters is terminal-specific. IDLE's shell uses the same editing keys as the editor window, which depend on OS and user customization. Note that Python statement input is multiline, not single line. It does not try to imitate any particular terminal and does not normally recognize ESC. What's the best way to get input from the console (not any enclosing shell script) that's cross-platform, cross-version (Python 2.7, 3.x), and doesn't do "readline" processing? Run Python in a cross-platform, cross-verson shell. IDLE with a fixed key set would qualifiy except a) inputting literal control chars would not work, and b) normal key sets do not work on both Mac and other systems. I don't know how close other IDEs come. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: input vs. readline
I was typing in a hurry. There are several unreadable items below. Let me correct myself... On 09Jul2016 09:45, Cameron Simpson wrote: Perhaps the Windows console is treating ESC specially, apparently as "line erase", discarduing any preceeding text. Hence your results. [...] - accept this, and use the liternal-next kestroke (usually ^V) to tell it not to the bytes special to the line discipline. So you might type ^V^H to get a literal ^H code in your input and so forth. "literal", not "liternal". "not to the" => "not to treat the". "special" => "specially". - put the terminal into "raw" mode where keystroke bytes are sent through unchanged (although them you need to hand carriage return yourself, etc) "then", not "them". "handle", not "hand". Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: input vs. readline
On Fri, Jul 8, 2016 at 11:17 PM, John Nagle wrote:
> If "readline" is imported, "input" gets "readline" capabilities.
> It also loses the ability to import control characters. It doesn't
> matter where "readline" is imported; an import in some library
> module can trigger this. You can try this with a simple test
> case:
>
>print(repr(input()))
>
> as a .py file, run in a console. Try typing "aaaESCbbb".
> On Windows 7, output is "bbb". On Linux, it's "aaa\x1".
The readline module isn't automatically imported for a script, and it
isn't even distributed with Windows Python. You have to install
pyreadline to get readline support on Windows.
You're seeing the readline-like behavior of a Windows console
processed read, i.e. with the console mode ENABLE_PROCESSED_INPUT [1].
The supported command-line editing and history functions are
documented for doskey.exe [2], though in modern Windows systems (based
on NT), it's actually the console (conhost.exe) that implements all of
the doskey functionality. For example, ESC "[c]lears the command from
the display".
Unfortunately processed input is all or nothing; the console doesn't
even process the enter key if processed input is disabled. You'd have
to do a lot of lowish-level ctypes or PyWin32 scripting to get
something usable, but maybe the CRT's getwche() function is good
enough. Try the following:
#! /usr/bin/python3
import sys
if sys.platform == 'win32':
import msvcrt
def input(prompt=''):
if prompt:
print(prompt, end='', flush=True)
s = []
while True:
c = msvcrt.getwche()
if c == '\r':
break
s.append(c)
s = ''.join(s)
print(prompt, s, sep='')
return s
if __name__ == '__main__':
print(repr(input('test: ')))
[1]: https://msdn.microsoft.com/en-us/library/ms683167
[2]: https://technet.microsoft.com/en-us/library/cc753867
--
https://mail.python.org/mailman/listinfo/python-list
Re: input vs. readline
On Sat, Jul 9, 2016 at 12:20 AM, Terry Reedy wrote: > The escape key erasing input back to the beginning of the line is Command > Prompt or cmd.exe behavior. cmd.exe is just a shell that uses the console (if the standard handles are console handles). The console window is hosted by conhost.exe. It processes the input buffer for command-line editing, and it maintains command history and a set of aliases (matching at the start of a line) for each attached executable (e.g. cmd.exe, powershell.exe, chcp.com, mode.com, doskey.exe, python.exe, etc). Every Windows process can attach to a single console window via AllocConsole or AttachConsole, and detach via FreeConsole. -- https://mail.python.org/mailman/listinfo/python-list
Quick poll: gmean or geometric_mean
As requested in issue 27181 on the bug tracker, I'm adding functions to calculate the harmonic and geometric means to the statistics module. I'd like to get a quick show of hands regarding the names. Which do you prefer? hmean and gmean harmonic_mean and geometric_mean Remember that the arithmetic mean is just called "mean". http://bugs.python.org/issue27181 -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Quick poll: gmean or geometric_mean
Steven D'Aprano writes: > As requested in issue 27181 on the bug tracker, I'm adding functions > to calculate the harmonic and geometric means to the statistics > module. > > I'd like to get a quick show of hands regarding the names. Which do > you prefer? > > hmean and gmean > > harmonic_mean and geometric_mean > > > Remember that the arithmetic mean is just called "mean". > > http://bugs.python.org/issue27181 First reaction: hmean and gmean. After reading the issue: hmean and gmean. After a brief glance at the statistics module: hmean and gmean. Or also change pstdev and pvariance to population_stdev and population_variance for consistency. Still: hmean and gmean. -- https://mail.python.org/mailman/listinfo/python-list
Re: Quick poll: gmean or geometric_mean
On Sat, Jul 9, 2016, at 01:26, Steven D'Aprano wrote: > hmean and gmean > > harmonic_mean and geometric_mean The latter, definitely. > Remember that the arithmetic mean is just called "mean". so? (also maybe it shouldn't be?) -- https://mail.python.org/mailman/listinfo/python-list
Re: Quick poll: gmean or geometric_mean
On 07/08/2016 10:49 PM, Random832 wrote: On Sat, Jul 9, 2016, at 01:26, Steven D'Aprano wrote: hmean and gmean harmonic_mean and geometric_mean The latter, definitely. My preference is also for the latter. However, if the rest of the module is filled with abbreviated names you may as well be consistent with them. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
