Official Python implementation? about common HOT 23 CLOSED

@Zearin, anything to share?

from common.

Whoa… It’s been a little while. :)

I haven’t been able to work on it in a while, but I think I might be able to pick it up again in the coming months. I would still love to see an official Python implementation.

from common.

Great!!

I'm planning to release microcuke later this week - a Cucumber reference implementation in 500 SLOC.

The main purpose of microcuke is to provide a very simple reference implementation that
can be ported to a new programming language in about a day. Think of it as an aid to
developers who wish to implement Cucumber for a new programming language.

Microcuke is written in classic JavaScript (ES5), because that's a language most
programmers can at least read.

Time permitting I'll also publish an early draft of a spec.

Before we can adopt something as an official implementation we need to make sure there is someone willing to maintain it. Ideally I'd like to have at least 2-3 people dedicating time on it for a few months before blessing it as official.

Hang in there while I clean up microcuke and the spec.

from common.

Great!!

Awesome! :)

(Does it matter that I’m only focusing on Gherkin3? I don’t think I can do the older, more complicated implementation style, where there’s a lot more mixing/coupling between Cucumber and Gherkin…)

I'm planning to release microcuke later this week - a Cucumber reference implementation in 500 SLOC.

The main purpose of microcuke is to provide a very simple reference implementation that
can be ported to a new programming language in about a day. Think of it as an aid to
developers who wish to implement Cucumber for a new programming language.

That is an awesome idea.

For projects that span multiple programming languages, I bet something like this would be a huge benefit to many of them.

Microcuke is written in classic JavaScript (ES5), because that's a language most
programmers can at least read.

Good choice! (I don’t really enjoy JavaScript, but your reasoning is totally solid. :P)

Time permitting I'll also publish an early draft of a spec.

Before we can adopt something as an official implementation we need to make sure there is someone willing to maintain it. Ideally I'd like to have at least 2-3 people dedicating time on it for a few months before blessing it as official.

I can commit to maintain this for roughly a year. Around that time, I’m planning to sell an apartment for the first time, buy a house for the first time, move, and lots of other disruptive stuff. I will almost certainly need to step down at that time.

That okay with you?

Hang in there while I clean up microcuke and the spec.

Okay!

:D

from common.

Does it matter that I’m only focusing on Gherkin3?

Not at all. We all want to retire Gherkin2.

I bet something like this would be a huge benefit to many of them.

I hope so. Having something tiny, but functional will help build consistent implementations.

That okay with you?

Wow you've got your life planned! :-) Yeah that's not a problem at all as long as there is someone else to build it.

The best way to ensure more than one people are contributing to a project is to:

1. Don't write all the code yourself - actively try to recruit other people who can help
2. TDD is so it's easy for other people to join and modify the code

from common.

I'm planning to release microcuke later this week - a Cucumber reference implementation in 500 SLOC.

How goes it? :)

from common.

Really well actually! I'll push what I have soon. Still a little rough around the edges.

from common.

Really well actually! I'll push what I have soon. Still a little rough around the edges.

« rubbing hands together in anticipation… »

from common.

Did you miss the microcuke announcement on the cukes list/twitter/gitter?

What are you waiting for?

from common.

As I cmd + F ed I realized nobody mentioned Behave. It is a really identical to cucumber has a good support and community. We have used it in some projects b4 willing to use it again if the client wants to stick to python.

from common.

I’ve been working on a Python implementation based on microcuke in my spare time. I’ve made a great deal of progress, but I’ve had trouble converting a few of the JavaScript-isms to Python.

By design, microcuke is minimalist, and most of it is really easy to understand! :D

However, there are a few places where it is difficult to know what to do for a conversion. Examples:

• EventEmitter is a JS staple, but what should someone using microcuke as a reference do if the target language has no equivalent?
  • Aside: Indeed, Python’s standard library has no built-in equivalent. In my implementation, I’ve been using a naïve 3rd party implementation of the EventEmitter class as a starting point (with plans to move to a more powerful—but trickier to implement—async implementation of EventEmitter for Python 3).
• The TestStep.execute(…) method has a world argument...
  • I don’t know if world is just a requirement of JS’s scoping rules, or something that related to microcuke’s use of Promises.
  • Regarding the comment: We're returning a promise of a boolean here, because JavaScript. Most languages should simply return a boolean and forget about the promise stuff - simpler! That is somewhat helpful, but I still don’t know what the world argument is for—and if (or how) it relates to Promises…
• The tests for TestStep have me scratching my head...
  • Once again, I’m not sure of the role of the world variable here. It seems like it's just filler, and not relevant to the tests themselves. Is this correct?
• Anything glue-related isn’t really working yet. I haven’t yet determined the best syntax for writing glue code in Python yet. (There are a few possibilities; must weigh the pros and cons of each.)

@aslakhellesoy:

• Could you clarify any of the above for me?
• Is there any time in the next couple of weeks when I could chat (video or text) with you about some of JS-isms?

from common.

This is exciting!

I've been working on a Java port of Microcuke (to serve as a basis for the next Cucumber-JVM, using Gherkin 3) and I've run into the same issues as you ;-). The JavaScript-isms are not trivial to translate to a different language.

I'll create new issues in microcuke to address the points you're bringing up here. It's easier to track these issues individually.

from common.

Just ping me on https://gitter.im/cucumber/chat to see if I'm around. My work hours are 9am-4pm GMT, and I'm usually busy mobbing before lunch, except Fridays which I try to dedicate fully to open source.

from common.

w00t! It is encouraging to know that I’m not alone! :)

To be clear, I think choosing JavaScript was absolutely the right choice. I think it is just that some JS-isms need to be rewritten generically, for the sake of other implementors.

from common.

Completely agree about rewriting jsisms!

from common.

Good progress on Python implementation. Stay tuned...

from common.

Nice!

from common.

Ping.

from common.

@webmaven I’ve been working on the Python implementation. :) (Not ready yet, but it’s close.)

from common.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs.

from common.

This issue has been automatically closed because of inactivity. You can support the Cucumber core team on opencollective.

from common.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

from common.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

from common.