Demur Rumed added the comment:
I had considered this, for some reason I didn't realize code[1] could be equal
to YIELD_FROM, felt it'd always be false
f_lasti being -2 has always been my preference, lasti.patch lgtm
--
___
Python tracker <
Demur Rumed added the comment:
I don't think lack of precedence is a reason to say new opcodes are new
features. More that generally new opcodes are created for new features
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.p
Demur Rumed added the comment:
Since the most common use of CALL_FUNCTION_EX is..
def f(*x,*kw):
other_func(*x, **kw)
I've added some code to BUILD_MAP_UNPACK_WITH_CALL & BUILD_TUPLE_UNPACK to not
allocate a new object if called with oparg of 1 & TOP() is correct type
Changes by Demur Rumed <gunkm...@gmail.com>:
--
nosy: +rhettinger
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27078>
___
__
Changes by Demur Rumed <gunkm...@gmail.com>:
--
type: enhancement -> performance
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Demur Rumed added the comment:
I'm not understanding your message. We don't call FORMAT_VALUE on constant
strings in f"x is {x}" & FORMAT_VALUE doesn't take an argument. Are you saying
in a hypothetical FORMAT_VALUE where BUILD_STRING takes a set of objects &
applies format
Demur Rumed added the comment:
fstrtup2.patch is a bit more of an involved optimization for when we are
joining 2 strings. Instead it emits BINARY_ADD. This may be considered too
'niche' since it only triggers when the substitution occurs at the start or end
of a string & there is only
Demur Rumed added the comment:
Benchmarked f'X is {x}' with BUILD_TUPLE change:
Before: 6.62 usec per loop
After: 6.33 usec per loop
f'X is {x} {x+2} {x+3}'
Before: 15.1 usec per loop
After: 14.7 usec per loop
Attached patch
--
keywords: +patch
Added file: http://bugs.python.org
Demur Rumed added the comment:
The simplest perf fix is to first use BUILD_TUPLE instead of BUILD_LIST
timeit 'x=1;(x,x,x)'
0.36 usec per loop
timeit 'x=1;[x,x,x]'
0.425 usec per loop
Introducing a new opcode BUILD_STRING to inline PyTuple_New + PyUnicode_Join to
replace BUILD_TUPLE
Demur Rumed added the comment:
Xiang: pause a moment to read the code being discussed. event before the |= is
0. You're saying flag must READ xor WRITE xor neither. Then only one if can be
taken. Therefore events |= EVENT_* will always happen with events == 0,
therefore it can be events
Demur Rumed added the comment:
callfunc3 addresses most feedback. Doesn't address _PyEval_EvalCodeWithName2
code bloat, & I disagree with mentioning BUILD_MAP_UNPACK_WITH_CALL change in
magic number update as the ABI of BUILD_MAP_UNPACK_WITH_CALL is unchanged. ie
if we were to imple
Demur Rumed added the comment:
(returning None wouldn't work because that may be the key, but something like
returning the dict itself (ie an unhashable) or keeping this as a C API &
returning NULL would work)
--
___
Python tracker
Demur Rumed added the comment:
mapaca2 heavy handily deals with the must-work-with-all-mappings by converting
any non dict mappings on the stack with dicts when with_call is true
I'm not sure if it'd be better to seek a less opcode centric fix-- ie introduce
a method to dictobject which
Changes by Demur Rumed <gunkm...@gmail.com>:
--
nosy: +serhiy.storchaka
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27358>
___
Changes by Demur Rumed <gunkm...@gmail.com>:
--
components: +Interpreter Core
type: -> performance
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
New submission from Demur Rumed:
BUILD_MAP_UNPACK_WITH_CALL is _really_ slow, wasting much of its time asserting
that keys are non overlapping. This patch optimizes a fast path for distinct
dicts, especially useful for #27213 where BUILD_MAP_UNPACK_WITH_CALL is
generated for a single **kw
Demur Rumed added the comment:
callfunc2 fixes test_dis, addresses code review, currently implements a copy of
_PyEval_EvalCodeWithName as _PyEval_EvalCodeWithName2 which changes a few lines
to work with new keyword stack layout so that we can use fast_function with
kwargs
CALL_FUNCTION_EX
Demur Rumed added the comment:
Attaching first iteration. Very drafty. Still need to fix test_dis; will run
test suite this evening. Perf on pybench went from 16.5s to 17.5s. It was 18.3s
prior to reintroducing use of fast_function. Code still needs clean up besides
investigation into how
Demur Rumed added the comment:
I've been working on this, may have the ceval portion mostly worked out but
can't test until I finish the compile portion. Haven't had time this week, will
have time to focus this weekend
--
___
Python tracker <
Demur Rumed added the comment:
Kind of amusing how visit_argannoation logic went full circle. Makes sense
considering pre-mkfu patch the ABI was quite similar on that front
--
Added file: http://bugs.python.org/file43362/mkfu5.patch
___
Python
Demur Rumed added the comment:
mkfu4 implements #27140. It doesn't special case 1-tuples into `BUILD_MAP 1`
It may be easier to have `BUILD_CONST_KEY_MAP 1` peepholed if it's really
preferable to strength reduce
I'm also noticing that it could've been suggested to go to the extreme
Demur Rumed added the comment:
The patches LGTM & seem to be implementation of follow up ideas outlined in the
first portion. It'd be good to verify that benchmarks are relatively unaffected
--
___
Python tracker <rep...@bugs.python.org
Changes by Demur Rumed <gunkm...@gmail.com>:
--
resolution: -> rejected
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Demur Rumed added the comment:
I should've kept gitfit & forbegin more separated as issues. Attached is
gitfit2, which only folds the GET_ITER into the comprehension if it isn't a
generator so to pass test_genexps
--
Added file: http://bugs.python.org/file43300/gitfit2.p
Demur Rumed added the comment:
Didn't see Raymond's response before posting, forbegin3 at least exists as a
completion of the experiment to a passes-tests state. The tracing hacks to
support an instruction corresponding to two separate lines support rejecting
this idea
Demur Rumed added the comment:
Attaching forbegin3.patch. It reintroduces GET_ITER for the sole purpose of
eagerly throwing. I decided to reuse GET_ITER over something like TEST_ITER as
this way we can have GET_ITER flow into FOR_BEGIN & rely on the fast path of
iter(iter(x))
GET_
Changes by Demur Rumed <gunkm...@gmail.com>:
Added file: http://bugs.python.org/file43271/forbegin2.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Demur Rumed <gunkm...@gmail.com>:
Removed file: http://bugs.python.org/file43270/forbegin2.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Demur Rumed added the comment:
Attached is a patch which fixes test_sys_settrace & test_pdb & test_trace.
Still failing is test_genexps. I'm unsure the best way to fix this one:
1. Allow generator expressions to defer type errors about non iterables until
the initial call to next
2
Demur Rumed added the comment:
@rhettinger can you clarify your opinion in relation to #27140 with #27095 &
#27213 in mind?
I agree that CHAINED_COMPARE_OP is unnecessary
--
___
Python tracker <rep...@bugs.python.org>
<http://bu
Demur Rumed added the comment:
I've gotten most tests to past by having FOR_ITER be traced as if the
instruction index is that of the corresponding FOR_BEGIN. test_sys_settrace
still fails on test_15_loops because an empty loop body doesn't have the 'pass'
line traced (ie when FOR_ITER starts
Demur Rumed added the comment:
I'd like to take on creating a patch for this proposal once #27140 lands
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Demur Rumed added the comment:
Java duplicates finally bytecode too:
http://cliffhacks.blogspot.ca/2008/02/java-6-tryfinally-compilation-without.html
Tho they avoid jsr instruction because it causes non trivial bytecode
validation. Still, they would've had to concluded that finally blocks
Demur Rumed added the comment:
When is this intended to be merged? I've been waiting on this before updating
the patch @ #27095 with fixes to other code review comments
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Demur Rumed added the comment:
Perhaps BUILD_CONST_KEY_MAP?
Ideally the opcode could ellide the LOAD_CONST for the tuple. ie have
LOAD_CONST 2 (1, 2, 3), BUILD_CONST_KEY_MAP 3 be BUILD_CONST_KEY_MAP 2 (1, 2,
3). However that'd require stack_effect to somehow lookup the const tuple
Thinking
Demur Rumed added the comment:
Two issues:
One: `a = (i for i in 6)` does not throw until calling next(a). This applies to
the first patch. If it's unacceptable to defer the throw then this whole issue
should be closed unless there's interest in having a GET_ITER, FOR_ITER,
FOR_BEGIN
Demur Rumed added the comment:
Summer heat is getting to me. Please ignore this issue until I've uploaded a
fixed patch
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Demur Rumed added the comment:
Microbenchmark of continue regression: timeit("for a in range(256):\n\tif
a:continue",number=10)
Without patch: ~3.57
With patch: ~3.64
--
___
Python tracker <rep...@bugs.python.org>
<htt
Demur Rumed added the comment:
Pretty small perf increase:
timeit("for a in range(256):pass", number=10)
Without patch: ~2.1
With patch: ~1.84
pybench is 1-2% faster. Would prefer others' results. Especially a benchmark
where it doesn't wrap payloads in
Demur Rumed added the comment:
Currently it'll work since in an except it'll generate a CONTINUE_LOOP that'll
jump to the end of the loop & either jump back to the start or to the end
Your example is incorrect. If the continue's JUMP_ABS were a FOR_ITER then if
we were on the last itera
Changes by Demur Rumed <gunkm...@gmail.com>:
Removed file: http://bugs.python.org/file43048/forbegin.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Demur Rumed added the comment:
Attached is the larger potential change of replacing GET_ITER/FOR_ITER with
FOR_BEGIN/FOR_ITER. I took awhile to getting this put together due to missing
that CONTINUE_LOOP was jumping to the top of the loop, skipping past FOR_ITER
--
Added file: http
Demur Rumed added the comment:
Oops wrong issue, sorry. Please delete?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27129>
___
__
Demur Rumed added the comment:
Attached is the larger potential change of replacing GET_ITER/FOR_ITER with
FOR_BEGIN/FOR_ITER. I took awhile to getting this put together due to missing
that CONTINUE_LOOP was jumping to the top of the loop, skipping past FOR_ITER
--
Added file: http
Demur Rumed added the comment:
https://github.com/search?q=f_lasti=Code
Popular use of f_lasti is checking it for -1, checking the instruction at the
byte offset of f_lasti, checking the argument with code[f_lasti+1] (Some bad
code checking f_lasti+3 which'll break with 3.6)
abarnert
Demur Rumed added the comment:
PREDICT could be optimized by having a HAS_ARG check on the constant op to
decide whether we assign oparg = OPARG(word)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Demur Rumed:
This is a small change to comprehensions pass in their iterable rather than
calling GET_ITER before CALL_FUNCTION. This makes it so that the compiler never
generates GET_ITER without following it with FOR_ITER, nor does it generate
FOR_ITER without preceding
Demur Rumed added the comment:
A documentation touch up for EXTENDED_ARG is included in #27095
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Demur Rumed added the comment:
There's some difficulty in changing next_instr to an unsigned short* unless
pointer arithmetic converts it back to unsigned char*. Code relies on f_lasti
to be a byte index more than it relies on f_lasti to be -1 at first. Should
this change include converting
Demur Rumed added the comment:
There is no strict aliasing issues because aliasing is explicitly allowed for
char buffers. The only issue is unaligned memory reads, but allocations are
well aligned, so there'd have to be explicit work to allocate & then put code
at an uneven offset. CPy
Demur Rumed added the comment:
May've been best to wait on posting a patch, but long weekend yesterday made
time available
mkfu3 updates mkfu2 with wordcode. Includes fix to EXTENDED_ARG documentation
--
Added file: http://bugs.python.org/file42965/mkfu3.patch
Changes by Demur Rumed <gunkm...@gmail.com>:
--
components: +Extension Modules
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Demur Rumed:
Attached is a patch based off #26647 which converts ceval to read opcode/oparg
by casting next_instr to an unsigned short. I don't believe we need to
complicate the code with checking the pointer alignment of the instruction
stream; some effort must be gone
Demur Rumed added the comment:
Attached are modifications to the patch based on feedback from Nikita. It
produces a larger patch tho. The changes are to combine return branches in
compiler_make_closure & to combine code between compiler_function &
compile
Changes by Demur Rumed <gunkm...@gmail.com>:
--
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27095>
___
_
New submission from Demur Rumed:
Implemented as per
https://mail.python.org/pipermail/python-dev/2016-April/144135.html
--
files: mkfu.patch
keywords: patch
messages: 266187
nosy: Demur Rumed
priority: normal
severity: normal
status: open
title: Simplify MAKE_FUNCTION
type: performance
New submission from Demur Rumed:
gcc6 now warns about indentation of code. find_paireencmap raised such
warnings. This patch silences that warning while updating the code to be more
PEP7 friendly wrt curlies
--
files: cjkcodecs.patch
keywords: patch
messages: 266148
nosy: Demur Rumed
Demur Rumed added the comment:
Removes 0 <= unsigned assertion & fixes j < 0 check to avoid overflow bug
--
Added file: http://bugs.python.org/file42950/wpyD.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Demur Rumed added the comment:
I have verified that wpyC does not produce signed/unsigned warnings with make
DEBUG=1
--
Added file: http://bugs.python.org/file42949/wpyC.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Demur Rumed added the comment:
Sorry for the nuisance of uploading another patch so soon. wpyB modifies
test_ctypes now that __phello__ is smaller, & fixes a typo in a comment I made
& removes a blank line I had added in when adding in if(0) logic
--
Added file: http://bugs.py
Demur Rumed added the comment:
I've tracked down the lnotab issue after modifying master/wpy to not vacuum
NOPs. Old code puts LOAD_CONST at after NOPs, on the same line as return op,
whereas new code is putting LOAD_CONST before NOPs, on it's own line
I've attached a fix along
Demur Rumed added the comment:
Compiler warnings can be fixed by using h instead of j in case RETURN_VALUE &
casting CONST_LEN() to unsigned is safe
As for the failing tests: I've finally figured out how to use Tools/freeze to
fix __phello__ et al. I've brought up the trace test failure a
Demur Rumed added the comment:
Based on serhiy's LGTM I'm uploading hopefully final touches based on his
feedback
New in this are changes to Makefile.pre & PCbuild files. I can't really test
PCbuild but I did test that make followed by modifying wordcode_helpers.h
followed by make rebu
Demur Rumed added the comment:
I've replaced wpy8 which I uploaded a few days ago as the previous version had
a blank line removed from dis.rst by accident
--
Added file: http://bugs.python.org/file42886/wpy8.patch
___
Python tracker <
Changes by Demur Rumed <gunkm...@gmail.com>:
Removed file: http://bugs.python.org/file42835/wpy8.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Demur Rumed <gunkm...@gmail.com>:
Added file: http://bugs.python.org/file42835/wpy8.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Demur Rumed added the comment:
I've been waiting on storchaka to finish code reviewing peephole based on his
statement of 'Reviewing peephole.c still is not completed.' before uploading a
patch which addresses the issues raised since
--
___
Python
Demur Rumed added the comment:
I should mention a change in dis which hasn't come up for the sake of explicit
discussion: I modified dis to not print EXTENDED_ARG. Instead one can tell by
the byte indices having a hole (since they uniformly count up by 2 otherwise) &
the argument value b
Demur Rumed added the comment:
Plain git diff formatted patch. I installed mercurial but then `hg clone
https://hg.python.org/cpython` failed twice over weird protocol errors (2nd one
had to do with negative length) so I gave up
--
Added file: http://bugs.python.org/file42659/wpy7
Demur Rumed added the comment:
I should be able to submit a wpy7.patch this evening, though I was never able
to generate a patch in the format you prefer. Should I fall back to piping git
diff? At this point it may be better if you take in the last suggestions as I'd
probably end up removing
Demur Rumed added the comment:
This code could be made to look a lot less hackish if the potential tuple reuse
was abstracted by a PyTuple_UniqueOrNew(PyTuple) which returns its argument if
REFCNT==1 otherwise allocates a tuple of the same size & returns that. It
decrefs PyTuple if RE
Demur Rumed added the comment:
Made changes from code review, did a little extra on fixing up type
consistency, not sure if this is exactly the patch format you wanted; I tried
`git difftool --extcmd='diff -u' python/master` but it's listing the original
files as being from /tmp
I've updated
Demur Rumed added the comment:
I submitted a patch years ago that addressses the ''x,y = 1, 2' case:
http://bugs.python.org/issue10648 & it was not met with enthusiasm
2016-04-10 5:08 GMT+00:00 Alexander Marshalov <rep...@bugs.python.org>:
>
> Alexander Marshalov added the com
Demur Rumed added the comment:
[12:36] Could I get a code review for wordcode's 4th patchset?
http://bugs.python.org/review/26647/#ps16875
...
[13:13] serprex: you'd be better off bumping the issue
--
___
Python tracker <rep...@bugs.python.
Demur Rumed added the comment:
Do you have any numbers on how common constant comparisons are in real code?
--
nosy: +Demur Rumed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Demur Rumed added the comment:
Got f_lasti working as -1. Applied PEP7. Unrelated: fixed a misnamed variable
in test_grammar because it ran into a peephole bug (const -> jump_if_false
erase didn't work when EXTENDED_ARGs were involved). dis has argval/arg set to
None instead of the unu
Changes by Demur Rumed <gunkm...@gmail.com>:
Added file: http://bugs.python.org/file42339/wpy3.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Demur Rumed <gunkm...@gmail.com>:
Removed file: http://bugs.python.org/file42338/wpy3.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Demur Rumed added the comment:
Addressed feedback from josh.rosenberg besides reintroducing FOURTH/SET_FOURTH
--
Added file: http://bugs.python.org/file42338/wpy3.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Demur Rumed added the comment:
Added back HAVE_ARGUMENT & HAS_ARG. As a result printing has removed arguments
Removed some code which was labelled unrelated
This does _not_ include having f_lasti be -1 instead of -2
--
Added file: http://bugs.python.org/file42331/wpy2.p
Demur Rumed added the comment:
While it's good to know benchmarking in core Python goes beyond the
microbenchmarks included in the distribution, I'm having some trouble with
hg.python.org/benchmarks due to my system only having 256MB of ram
I've attached results for 2 benchmarks: 2to3 & r
Demur Rumed added the comment:
To clarify format of extended arg listings: 1st column is the number of
instances of EXTENDED_ARG being emitted, 2nd column is length of bytecode,
followed by filename
The previous numbers were of modules, which generally are run-once and listing
many constants
Demur Rumed added the comment:
I've attached some benchmarking results as requested
There is 1 failing test which doesn't fail in master for test_trace; the unit
test for #9936
--
Added file: http://bugs.python.org/file42324/wcpybm.txt
___
Python
Changes by Demur Rumed <gunkm...@gmail.com>:
--
nosy: +abarnert
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26647>
___
__
Demur Rumed added the comment:
I'll dig up benchmark results when I get home, but I'd be interested to get
results on a less wannabe RISC CPU
The change is to have all instructions take an argument. This removes the
branch on each instruction on whether to load oparg. It then also aligns
Demur Rumed added the comment:
Implementing tp_traverse & tp_clear seems to runs into complications due to
slice_cache
--
nosy: +Demur Rumed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.o
Demur Rumed added the comment:
Fixes syntax & line length issues in previous patch
--
Added file: http://bugs.python.org/file42312/imaplib2.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.o
Demur Rumed added the comment:
Also missing from this patch is modification of the bytecode magic number
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Demur Rumed added the comment:
I've attached a patch file of the proposed change which seems correct
--
keywords: +patch
nosy: +Demur Rumed
Added file: http://bugs.python.org/file42310/imaplib.patch
___
Python tracker <rep...@bugs.python.org>
New submission from Demur Rumed:
Originally started @ https://github.com/abarnert/cpython/tree/wpy
This patch is based off of https://github.com/serprex/cpython/tree/wpy
It omits importlib.h & importlib_external.h as those are generated
It omits https://github.com/serprex/cpython/blob
New submission from Demur Rumed junkm...@hotmail.com:
This modifies the peepholer's BUILD/UNPACK_SEQUENCE for the case when all
stores are simple, or all loads are simple
It first scans to see if the pushing is done with simple LOADs. If so, it
reverses the loads and removes the build unpack
New submission from Demur Rumed junkm...@hotmail.com:
http://docs.python.org/dev/library/imp.html
acquire_lock and release_lock are listed twice. The first iteration of
acquire_lock repeats On platforms without threads, this function does
nothing. twice and advises release, while the latter
Demur Rumed junkm...@hotmail.com added the comment:
That doesn't appear to remove the repetition of their listing. Something I
failed to mention: The duplication occurs after imp.reload
--
___
Python tracker rep...@bugs.python.org
http
New submission from Demur Rumed junkm...@hotmail.com:
DUP_TOPX(3) is never used, nor is ROT_FOUR. This patch removes the opcodes,
replacing DUP_TOPX with DUP_TOP_TWO
Oddly, at least with pybench, use of PREDICT(BINARY_SUBSCR) in DUP_TOP_TWO
seems to show an always right PREDICT as slower than
Changes by Demur Rumed junkm...@hotmail.com:
--
versions: +Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9225
___
___
Python-bugs-list
Demur Rumed junkm...@hotmail.com added the comment:
The seperation of COMPARE_OP into multiple opcodes shouldn't affect cache size
since the opcodes are aliased. Spreading out the switch statement shouldn't
cause issue from flattening, since GCC would inline the single use of
cmp_outcome
Demur Rumed junkm...@hotmail.com added the comment:
Replaced TARGET_DUP_TOPX with _unknown_opcode
I recompiled with --with-computed-gotos, and the results remain promising,
though the interpreter instead grows from 6756023B to 6765167B
--
Added file: http://bugs.python.org/file17903
Demur Rumed junkm...@hotmail.com added the comment:
I've fixed the segfaulting in IN and NOT_IN, though the code requires cleaning
due to the obtusely cargo culted nature of those opcodes
I'm also including an incrementation which completely removes COMPARE_OP, using
the opcode to determine
Demur Rumed junkm...@hotmail.com added the comment:
It seems the lack of benefits from replacing COMPARE_OP with a set of aliased
bytecodes was repairable through TARGET_WITH_IMPL. Also fixed was the lack of
amendments to dis
--
versions: -Python 3.3
Added file: http
New submission from Demur Rumed junkm...@hotmail.com:
Currently, COMPARE_OP is burdened by a needless, and unorthogonal, extra layer
of indirection. I've modified it to only handle the rich comparison case,
moving the other five cases to BINARY_IN, BINARY_NOT_IN, BINARY_IS,
BINARY_IS_NOT
1 - 100 of 115 matches
Mail list logo
