Using inconsistent I/O formats

For example, for a hypothetical challenge where the output could only ever be two or eleven, submitting the python program

lambda x:print"11"

and claiming that it outputs in unary for certain inputs and in decimal for other inputs should not be allowed, even though outputting in either of these bases is usually allowed.

Likewise, for a decision-problem challenge, submitting the python function

lambda i:type(i)is str

and claiming it takes input as a singleton list for inputs that match the challenge's criteria and as a string otherwise shouldn't be allowed, even though taking input as a singleton list is usually allowed.

Using an inconsistent I/O format to encode information

For example, for a hypothetical challenge where the output could only ever be two or eleven, submitting the python program

lambda x:print"11"

and claiming that it outputs in unary for certain inputs and in decimal for other inputs should not be allowed, even though outputting in either of these bases is usually allowed.

Likewise, for a decision-problem challenge, submitting the python function

lambda i:type(i)is str

and claiming it takes input as a singleton list for inputs that match the challenge's criteria and as a string otherwise shouldn't be allowed, even though taking input as a singleton list is usually allowed.

#Using inconsistent I/O formats

For example, for a hypothetical challenge where the output could only ever be two or eleven, submitting the python program

lambda x:print"11"

and claiming that it outputs in unary for certain inputs and in decimal for other inputs should not be allowed, even though outputting in either of these bases is usually allowed.

Likewise, for a decision-problem challenge, submitting the python function

lambda i:type(i)is str

and claiming it takes input as a singleton list for inputs that match the challenge's criteria and as a string otherwise shouldn't be allowed, even though taking input as a singleton list is usually allowed.

Using inconsistent I/O formats

For example, for a hypothetical challenge where the output could only ever be two or eleven, submitting the python program

lambda x:print"11"

and claiming that it outputs in unary for certain inputs and in decimal for other inputs should not be allowed, even though outputting in either of these bases is usually allowed.

Likewise, for a decision-problem challenge, submitting the python function

lambda i:type(i)is str

and claiming it takes input as a singleton list for inputs that match the challenge's criteria and as a string otherwise shouldn't be allowed, even though taking input as a singleton list is usually allowed.

#Input-dependent I/O formats

For example, for a hypothetical challenge where the output could only ever be two or eleven, submitting the python program

lambda x:print"11"

and claiming that it outputs in unary for certain inputs and in decimal for other inputs should not be allowed, even though outputting in either of these bases is usually allowed.

Likewise, for a decision-problem challenge, submitting the python function

lambda i:type(i)is str

and claiming it takes input as a singleton list for inputs that match the challenge's criteria and as a string otherwise shouldn't be allowed, even though taking input as a singleton list is usually allowed.

#Using inconsistent I/O formats

For example, for a hypothetical challenge where the output could only ever be two or eleven, submitting the python program

lambda x:print"11"

and claiming that it outputs in unary for certain inputs and in decimal for other inputs should not be allowed, even though outputting in either of these bases is usually allowed.

Likewise, for a decision-problem challenge, submitting the python function

lambda i:type(i)is str

and claiming it takes input as a singleton list for inputs that match the challenge's criteria and as a string otherwise shouldn't be allowed, even though taking input as a singleton list is usually allowed.