implement netcat operating mode #1222

Open
f97ada87 wants to merge 1 commits from f97ada87/opmode-netcat-v2 into v0.6
2 changed files with 199 additions and 3 deletions

View File

@ -66,6 +66,7 @@ from network.downloadthread import DownloadThread
import helper_bootstrap import helper_bootstrap
import helper_generic import helper_generic
import helper_threading import helper_threading
import std_io # for STDIO modes
def connectToStream(streamNumber): def connectToStream(streamNumber):
@ -205,8 +206,8 @@ class Main:
try: try:
opts, args = getopt.getopt( opts, args = getopt.getopt(
sys.argv[1:], "hcdt", sys.argv[1:], "hcdtn",
["help", "curses", "daemon", "test"]) ["help", "curses", "daemon", "test", "mode-netcat"])
except getopt.GetoptError: except getopt.GetoptError:
self.usage() self.usage()
@ -224,6 +225,14 @@ class Main:
elif opt in ("-t", "--test"): elif opt in ("-t", "--test"):
state.testmode = daemon = True state.testmode = daemon = True
state.enableGUI = False # run without a UI state.enableGUI = False # run without a UI
elif opt in ("-n", "--mode-netcat"):
# STDIO MODES - reconfigure threads for netcat mode
state.enableNetwork = True # enable networking
state.enableObjProc = False # disable object processing
state.enableGUI = False # headless
state.enableSTDIO = True # enable STDIO
# STDIN to invQueue, STDOUT from objectProcessorQueue
std_io.stdInputMode = 'netcat'
# is the application already running? If yes then exit. # is the application already running? If yes then exit.
shared.thisapp = singleinstance("", daemon) shared.thisapp = singleinstance("", daemon)
@ -263,7 +272,12 @@ class Main:
sqlLookup.start() sqlLookup.start()
Inventory() # init Inventory() # init
# start network components if networking is enabled
if state.enableNetwork:
Dandelion() # init, needs to be early because other thread may access it early Dandelion() # init, needs to be early because other thread may access it early
else:
state.dandelion = 0
# Enable object processor and SMTP only if objproc enabled # Enable object processor and SMTP only if objproc enabled
if state.enableObjProc: if state.enableObjProc:
@ -283,6 +297,12 @@ class Main:
objectProcessorThread.daemon = False # DON'T close the main program even the thread remains. This thread checks the shutdown variable after processing each object. objectProcessorThread.daemon = False # DON'T close the main program even the thread remains. This thread checks the shutdown variable after processing each object.
objectProcessorThread.start() objectProcessorThread.start()
elif state.enableSTDIO and std_io.stdInputMode == 'netcat':
# Start the thread that outputs objects to stdout in netcat mode
objectStdOutThread = std_io.objectStdOut()
objectStdOutThread.daemon = False # same as objectProcessorThread
objectStdOutThread.start()
# Start the cleanerThread # Start the cleanerThread
singleCleanerThread = singleCleaner() singleCleanerThread = singleCleaner()
singleCleanerThread.daemon = True # close the main program even if there are threads left singleCleanerThread.daemon = True # close the main program even if there are threads left
@ -309,6 +329,12 @@ class Main:
singleAPIThread.daemon = True # close the main program even if there are threads left singleAPIThread.daemon = True # close the main program even if there are threads left
singleAPIThread.start() singleAPIThread.start()
# STDIO MODES - Start the STDIN thread
if state.enableSTDIO:
stdinThread = std_io.stdInput(sys.stdin)
stdinThread.daemon = True
stdinThread.start()
# start network components if networking is enabled # start network components if networking is enabled
if state.enableNetwork: if state.enableNetwork:
BMConnectionPool() BMConnectionPool()
@ -440,7 +466,10 @@ Options:
-h, --help show this help message and exit -h, --help show this help message and exit
-c, --curses use curses (text mode) interface -c, --curses use curses (text mode) interface
-d, --daemon run in daemon (background) mode -d, --daemon run in daemon (background) mode
Advanced modes:
-t, --test dryrun, make testing -t, --test dryrun, make testing
-n, --mode-netcat no GUI, read and write raw objects on STDIO
All parameters are optional. All parameters are optional.
''' '''

167
src/std_io.py Normal file
View File

@ -0,0 +1,167 @@
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
"""
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
STDIO handling threads for netcat and airgap modes
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
stdInput thread: receives hex-encoded bitmessage objects on STDIN
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
Supported input formats, format is auto-detected:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
- each line a hex-encoded object
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
- each line formatted: hex_timestamp - tab - hex-encoded_object
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
(the output format of netcat mode)
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
objectStdOut thread: replaces the objectProcessor thread in netcat mode,
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
outputs to STDOUT in format: hex_timestamp - tab - hex-encoded_object
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
"""
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
import threading
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:53:23 +02:00 (Migrated from github.com)
Review

Maintain a order all the imports should be first.
from statements should be written after import statements.

Maintain a order all the imports should be first. from statements should be written after import statements.
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:38:10 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
import time
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
import protocol
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
import queues
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
import state
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
import shutdown
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
import shared # statusIconColor
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
from struct import unpack
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
from binascii import hexlify, unhexlify
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
from addresses import decodeVarint, calculateInventoryHash
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
from debug import logger
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
from inventory import Inventory
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
from helper_sql import sqlQuery, sqlExecute, SqlBulkExecute
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
stdInputMode = 'netcat' # process STDIN in netcat mode by default
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
netcatExitOnEOF = True # exit program if EOF on STDIN
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
class stdInput(threading.Thread):
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
"""
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
Standard Input thread reads objects from STDIN, posts them to Inventory
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
"""
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
def __init__(self, inputSrc):
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
threading.Thread.__init__(self, name="stdInput")
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
self.inputSrc = inputSrc
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
logger.info('stdInput thread started.')
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
def run(self):
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
omkar1117 commented 2018-04-16 14:57:32 +02:00 (Migrated from github.com)
Review

Please write a method with only 15 or 20 lines.

Please write a method with only 15 or 20 lines.
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
f97ada87 commented 2018-04-16 17:40:56 +02:00 (Migrated from github.com)
Review

No. Go big or go home :)

No. Go big or go home :)
PeterSurda commented 2018-04-16 18:17:01 +02:00 (Migrated from github.com)
Review

Over longer term, I would also prefer to have shorter methods, some parts of the old code, like the class_objectProcessor are too long, but for this PR it's fine the way it is.

Over longer term, I would also prefer to have shorter methods, some parts of the old code, like the class_objectProcessor are too long, but for this PR it's fine the way it is.
f97ada87 commented 2018-04-17 04:23:21 +02:00 (Migrated from github.com)
Review

Noted with thanks. I think the ad-hoc object parsing accounts for a lot of avoidable LLOC wastage, however, as discussed in PR #1149 , there was no readily usable parser function to use instead.

Noted with thanks. I think the ad-hoc object parsing accounts for a lot of avoidable LLOC wastage, however, as discussed in PR #1149 , there was no readily usable parser function to use instead.
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
while True:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# read a line in hex encoding
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
line = self.inputSrc.readline()
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
if not line:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
logger.info("STDIN: End of input")
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
if netcatExitOnEOF:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
shutdown.doCleanShutdown()
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
break
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
hexObject = line.rstrip()
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
hexTStamp = ''
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# detect timestamp-tab-object format (as output by netcat mode)
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
if "\t" in hexObject:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
hexTStamp = hexObject.split("\t")[0]
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
hexObject = hexObject.split("\t")[-1]
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# unhex the input with error rejection
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
try:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
binObject = unhexlify(hexObject)
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
except TypeError: # fix codacy warning
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
logger.info("STDIN: Invalid input format")
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
continue
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# sanity check on object size
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
if len(binObject) < 22:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
logger.info("STDIN: Invalid object size")
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
continue
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
if not state.enableNetwork and state.enableGUI:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:42:44 +02:00 (Migrated from github.com)
Review

You set state.enableGUI = False above. Will this conditional ever be reached?

You set `state.enableGUI = False` above. Will this conditional ever be reached?
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:16:40 +02:00 (Migrated from github.com)
Review

state.enableGUI is only false in netcat mode; std_io may have other uses outside of netcat mode, which are not currently included. Yes, the conditional makes sense from a logical perspective.

state.enableGUI is only false in netcat mode; std_io may have other uses outside of netcat mode, which are not currently included. Yes, the conditional makes sense from a logical perspective.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# in airgap mode, trick the status icon that we are in fact
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# NOT waiting for a connection
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# (may be removed after impact analysis)
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
shared.statusIconColor = 'yellow'
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
if stdInputMode == 'airgap':
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# airgap mode uses the timestamp
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# unhex the timestamp with error rejection
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
if len(hexTStamp) == 16:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
try:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# stdioStamp, = unpack('>Q', unhexlify(hexTStamp))
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
_, = unpack('>Q', unhexlify(hexTStamp))
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
except (struct.error, TypeError): # fix codacy warning
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
logger.info("STDIN: Invalid timestamp format: " + hexTStamp)
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
continue
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# check that proof of work is sufficient.
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
if not protocol.isProofOfWorkSufficient(binObject):
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
logger.info('STDIN: Insufficient Proof of Work')
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
continue
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# extract expiry time, object type
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
eTime, = unpack('>Q', binObject[8:16])
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
objectType, = unpack('>I', binObject[16:20])
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# extract version number and stream number
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
readPosition = 20 # bypass the nonce, time, and object type
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# versionNumber, versionLength
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
_, versionLength = decodeVarint(binObject[readPosition:readPosition + 10])
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
readPosition += versionLength
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
streamNumber, streamNumberLength = decodeVarint(binObject[readPosition:readPosition + 10])
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
readPosition += streamNumberLength
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# calculate inventory hash
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
inventoryHash = calculateInventoryHash(binObject)
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# duplicate check on inventory hash (both netcat and airgap)
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
if inventoryHash in Inventory():
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
logger.debug("STDIN: Already got object " + hexlify(inventoryHash))
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
continue
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# in netcat mode, push object to inventory and id to output queue
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
if stdInputMode == 'netcat':
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
Inventory()[inventoryHash] = (objectType, streamNumber, binObject, eTime, '')
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
logger.debug("STDIN: Accepted object (type=%u) " % objectType + hexlify(inventoryHash))
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
queues.invQueue.put((streamNumber, inventoryHash))
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# honour global shutdown flag
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
if state.shutdown != 0:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
logger.info('stdInput thread shutdown.')
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
break
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
class objectStdOut(threading.Thread):
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
"""
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
The objectStdOut thread receives network objects from the receiveDataThreads.
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
"""
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
def __init__(self):
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
omkar1117 commented 2018-04-16 16:24:00 +02:00 (Migrated from github.com)
Review

Follow Pep8 styling format.

Follow Pep8 styling format.
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
f97ada87 commented 2018-04-16 17:41:04 +02:00 (Migrated from github.com)
Review

done

done
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
threading.Thread.__init__(self, name="objectStdOut")
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# REFACTOR THIS with objectProcessor into objectProcessorQueue
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
queryreturn = sqlQuery(
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
'''SELECT objecttype, data FROM objectprocessorqueue''')
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
for row in queryreturn:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
coffeedogs commented 2018-05-09 12:39:24 +02:00 (Migrated from github.com)
Review

By waiting until we have synchronously pulled all objects from the database and put all objects on the queue we are missing out on some benefits of parallelism and we'll hit a memory limit with large data sets. Maybe this is unavoidable or related to your suggested refactoring.

Also, keeping the number of places where raw SQL is used to a minimum is a good idea. Again, I assume this would be part of your suggested refactoring.

By waiting until we have synchronously pulled all objects from the database and put all objects on the queue we are missing out on some benefits of parallelism and we'll hit a memory limit with large data sets. Maybe this is unavoidable or related to your suggested refactoring. Also, keeping the number of places where raw SQL is used to a minimum is a good idea. Again, I assume this would be part of your suggested refactoring.
f97ada87 commented 2018-05-13 05:22:20 +02:00 (Migrated from github.com)
Review

The block marked by refactor ... /refactor is duplicated verbatim from class objectProcessor; the comment indicates my intention to refactor it into class objectProcessorQueue, a task which is outside the scope of this PR.

The block marked by `refactor ... /refactor` is duplicated verbatim from class `objectProcessor`; the comment indicates my intention to refactor it into class `objectProcessorQueue`, a task which is outside the scope of this PR.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
objectType, data = row
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
queues.objectProcessorQueue.put((objectType, data))
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
sqlExecute('''DELETE FROM objectprocessorqueue''')
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
logger.debug('Loaded %s objects from disk into the objectProcessorQueue.' % str(len(queryreturn)))
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
omkar1117 commented 2018-04-16 16:24:18 +02:00 (Migrated from github.com)
Review

Pep8 styling missing

Pep8 styling missing
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
f97ada87 commented 2018-04-16 17:41:10 +02:00 (Migrated from github.com)
Review

done

done
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# /REFACTOR THIS
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
def run(self):
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
while True:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
coffeedogs commented 2018-05-09 12:42:07 +02:00 (Migrated from github.com)
Review

When the queue is empty would this not cause unnecessary 100% CPU? Perhaps a small sleep is needed inside the while loop?

Edit: no it wouldn't, Queue.get(block=True) blocks when the queue is empty. I was thinking of the AMQP library I was most recently using.

When the queue is empty would this not cause unnecessary 100% CPU? Perhaps a small sleep is needed inside the while loop? Edit: no it wouldn't, Queue.get(block=True) blocks when the queue is empty. I was thinking of the AMQP library I was most recently using.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
objectType, data = queues.objectProcessorQueue.get()
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# Output in documented format
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
print "%016x" % int(time.time()) + '\t' + hexlify(data)
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
coffeedogs commented 2018-05-09 12:44:50 +02:00 (Migrated from github.com)
Review

Should we use sys.stdout.write() instead of print here?

Should we use sys.stdout.write() instead of print here?
f97ada87 commented 2018-05-13 05:24:46 +02:00 (Migrated from github.com)
Review

It would be indeed the logical choice, I'm just not sure how cross-platform it would be. Print is 100% portable and not wrong.

It would be indeed the logical choice, I'm just not sure how cross-platform it would be. Print is 100% portable and _not wrong_.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
if state.shutdown:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
time.sleep(.5) # Wait just a moment for most of the connections to close
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# REFACTOR THIS with objectProcessor into objectProcessorQueue
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
numberOfObjectsInObjProcQueue = 0
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
with SqlBulkExecute() as sql:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
while queues.objectProcessorQueue.curSize > 0:
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
objectType, data = queues.objectProcessorQueue.get()
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
sql.execute('''INSERT INTO objectprocessorqueue VALUES (?,?)''',
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
objectType, data)
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
numberOfObjectsInObjProcQueue += 1
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
logger.debug('Saved %s objects from the objectProcessorQueue to disk. objectProcessorThread exiting.' %
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
str(numberOfObjectsInObjProcQueue))
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
# /REFACTOR THIS
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
coffeedogs commented 2018-05-09 12:43:18 +02:00 (Migrated from github.com)
Review

Yes please!

Yes please!
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
state.shutdown = 2
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246
break
omkar1117 commented 2018-04-16 14:51:43 +02:00 (Migrated from github.com)
Review

PEP8 validation missing here

PEP8 validation missing here
omkar1117 commented 2018-04-16 14:56:21 +02:00 (Migrated from github.com)
Review

why can't we use
if not line or if not line.strip() ?

why can't we use if not line or if not line.strip() ?
f97ada87 commented 2018-04-16 17:38:01 +02:00 (Migrated from github.com)
Review

done

done
f97ada87 commented 2018-04-16 17:39:16 +02:00 (Migrated from github.com)
Review

"if not line" - can't strip an EOF :)

"if not line" - can't strip an EOF :)
coffeedogs commented 2018-05-09 11:41:06 +02:00 (Migrated from github.com)
Review

According to the docs unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.

According to the [docs](https://docs.python.org/2/library/binascii.html) unhexlify might throw TypeError. Can we be more specific here otherwise codacy will complain of a bare except.
coffeedogs commented 2018-05-09 11:55:26 +02:00 (Migrated from github.com)
Review

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.

Can we just catch struct.error here? Oh, plus TypeError for unhexlify.
coffeedogs commented 2018-05-09 12:24:11 +02:00 (Migrated from github.com)
Review

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.

Not sure how many of these one might expect during 'normal' operation. Is 'info' the right log level? Maybe this and the next log statement could be debug level if it would otherwise lead to info being spammed. Maybe we expect people running in this mode to not care about other info level statements but be very interested in knowing that messages were or were not added, I don't know.
f97ada87 commented 2018-05-13 05:36:45 +02:00 (Migrated from github.com)
Review

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug.
I guess what I really need here is not logger.info pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that.
EDIT - Done: #1246

You're probably right. It's only useful when running in manual mode and pasting objects in console, useless in most other scenarios. I'll change it to debug. I guess what I really need here is not `logger.info` pollution, but the ability to switch logging levels as needed via getopt; I might actually open an issue about that. EDIT - Done: #1246