I think the community would be happy to introduce a python style guide, but I
am not well placed to do so, having chosen throughout my career to limit my
exposure to python. Probably a parallel effort would be best - perhaps you
could work with Stefan and others to produce such a proposal?
+1 to the doc as written. A good portion of it also applies to python code
style (structure, clarity in naming, etc).
Perhaps a python specific addendum as a follow up might make sense Bowen?
On Mon, Mar 14, 2022, at 7:21 AM, bened...@apache.org wrote:
> I think the community would be happy to
I've been wrestling with the python dtests recently and that led to some
discussions with other contributors about whether we as a project should be
writing new tests in the python dtest framework or the in-jvm framework. This
discussion has come up tangentially on some other topics, including
I agree on not using finals as suggested by Marcus, I have been using
them where I could, sometimes for the sake of having them final to be
consistent with other code but I gladly drop this habit. Too bad Java
doesnt have it like Scala where it is the matter of "var" vs "val".
On Mon, 14 Mar 2022
Agreed, how about a section like so:
Variable Mutability
As a general norm, parameters and variables should be treated as immutable and
not be re-used. Where possible, variables that are mutated within a loop should
be declared in the loop guard or body. Sometimes it is necessary for clarity to
> we should add Python code style guides to it
>
Strongly agree. We're hurting ourselves by treating our python as a 2nd class
citizen.
> if we should avoid making method parameters and local variables `final` -
> this is inconsistent over the code base, but I'd prefer not having them. If
>
vnode support for in-jvm dtests is in flight and fairly straightforward:
https://issues.apache.org/jira/browse/CASSANDRA-17332
David's OOO right now but I suspect we can get this in in April some time.
On Mon, Mar 14, 2022, at 8:36 AM, bened...@apache.org wrote:
> This is the limitation I
Looks good
One thing that might be missing is direction on if we should avoid making
method parameters and local variables `final` - this is inconsistent over the
code base, but I'd prefer not having them. If the method is large enough that
we might mistakenly reuse parameters/variables, we
I am strongly in favour of deprecating python dtests in all cases where they
are currently superseded by in-jvm dtests. They are environmentally more
challenging to work with, causing many problems on local and remote machines.
They are harder to debug, slower, flakier, and mostly less
Last time I checked there wasn't support for vnodes on in-jvm dtests, which
seems an important limitation.
On Mon, 14 Mar 2022 at 12:24, bened...@apache.org
wrote:
> I am strongly in favour of deprecating python dtests in all cases where
> they are currently superseded by in-jvm dtests. They
This is the limitation I mentioned. I think this is solely a question of
supplying an initial config that uses vnodes, i.e. that specifies multiple
tokens for each node. It is not really a limitation – I believe a dtest could
be written today using vnodes, by overriding the config’s tokens. It
Our style guide hasn’t been updated in about a decade, and I think it is
overdue some improvements that address some shortcomings as well as modern
facilities such as streams and lambdas.
Most of this was put together for an effort Dinesh started a few years ago, but
has languished since, in
I found there's no mentioning of Python code style at all. If we are
going to update the style guide, can this be addressed too?
FYI, a quick "flake8" style check shows many existing issues in the
Python code, including libraries imported but unused, redefinition of
unused imports and invalid
Hi Bowen,
we were working on that recently, like CASSANDRA-17413 + a lot of
improvements around Python stuff are coming. If you identify more
places for improvements we are definitely interested.
Regards
On Mon, 14 Mar 2022 at 11:53, Bowen Song wrote:
>
> I found there's no mentioning of
I think there's two separate issues, the style guide for Python code,
and fixing the existing code style. In my opinion, the style guide
should come first, and we can follow that to fix the existing code's style.
BTW, I can see the changes you made in CASSANDRA-17413 has already been
merged
Oh, I certainly don't mean to block the purposed update. I'm sorry if it
sounded that way. All I'm saying is we should add Python code style
guides to it, and a follow up addendum can surely do the job.
On 14/03/2022 11:41, Josh McKenzie wrote:
+1 to the doc as written. A good portion of it
On Wed, Mar 9, 2022 at 12:39 PM Patrick McFadin wrote:
> I'm not sure if they can merge groups but from what I'm reading that
> wouldn't work either. What I'm seeing is a desire to not "promote vendors"
> which I believe is working against the project's self-interest. LinkedIn is
> the perfect
I think that is a fair perspective based on the history of this project.
I'm not ready to give up on trying to figure it out though. I worry about
the Cassandra project being isolated when it's really not true.
If there is a clear policy on something like a retweet with clear
intentions and
Thanks to Lorina for offering to be the first contributor to not only offer
to do a Q but submit her answers on the same day!
Who's next? This is a chance to encourage others to get involved and see
the folks behind all the hard work.
Chris Thornett
> senior content strategist, Constantia.io
>
Benedict, I agree. We should not be rigid about applying any style. stylechecks
are meant to bring uniformity in the codebase. I assure you what I am proposing
is neither rigid nor curbs the ability to apply the rules flexibly.
> On Mar 14, 2022, at 4:52 PM, bened...@apache.org wrote:
>
> I’m
I’m a strong -1 on strictly enforcing any style guide. It is there to help
shape contributions, review feedback and responding to said feedback. It can
also be used to setup IntelliJ’s code formatter to configure default behaviours.
It is not meant to be turned into a linter. Plenty of the
I do think that we should at least enforce the import order. What is now is
a complete mess and causes a lot of conflicts during rebasing / merging.
Perhaps we could start enforcing such rules only on modified files, this
way we could gradually go towards consistency... wdyt?
- - -- --- -
I am also in favor of updating the style guide. We should ideally have custom
checkstyle configuration that can ensure adherence to the style guide.
I also don't think this is a contended topic. We want to explicitly codify our
current practices so new contributors have an easier time writing
Regarding interfaces, mocks created by Mockito are not really the
implementations. We also cannot predict tests which will be written in the
future. Having interfaces encourages better unit tests IMHO.
An addendum for exception handling guidelines sounds like a good idea.
For the instance() /
I think it is fine to count generated implementations of interfaces as
interfaces, even if they are not defined. If you would like to explicitly
mention this, that is fine. Though, if I’m perfectly honest, I do not find that
mocking improves testing in many cases (instead making it more tightly
Sorry, I missed your reply. Yes it is what you described.
Le jeu. 10 mars 2022 à 11:25, Claude Warren
a écrit :
> I found it in https://github.com/antlr/grammars-v4.git and I suspected it
> was wrong. I assume it should be that the tuple can contain 1 or more
> elements and the elements may be
Hi,
I was looking at the document and have some thoughts:
- Sometimes, although it would be just a single implementation, interface
can make sense for testing purposes - for mocking in particular
- For exception handling, perhaps we should explicitly mention in the
guideline that we should
Hi Jacek,
> Sometimes, although it would be just a single implementation, interface can
> make sense for testing purposes - for mocking in particular
This would surely mean there are two implementations, one of which is in the
test tree? I think this is therefore already covered.
> For
This Apachecon track sounds fun! I hope someone from the Cassandra
community steps up to help on this track.
I would be happy to help on reviews but not organize the event per se as I
will likely not attend the event.
Em sex., 11 de mar. de 2022 às 09:26, sharanf escreveu:
> Hi All
>
> The
29 matches
Mail list logo
