Several people have expressed interest in a Python sugar, so I thought, in the interest of organization, we could keep it in a unified location (i.e. this thread). I’ve started working on a syntax file, code below. I only have syntax for comments in what I *think* is the correct syntax, but it’s a start. Let’s go, pythonistas.

<?xml version=“1.0”?>
<syntax name=“text.python.basic”>
  <zones>
      <zone name=“comment.line.python”>
        <starts-with>
          <expression>[^\\]#</expression>
          <capture number"0” name=“punctuation.definition.begin”>
        </starts-with>
        <ends-with>
          <expression>\n</expression>
          <capture number"0” name=“punctuation.definition.end”>
        </ends-with>
      </zone>
      <zone name=“comment.block.python”>
        <starts-with>
          <expression>(\”{3}|\’{3})</expression>
          <capture number=“1” name=“punctuation.definition.begin”>
        </starts-with>
        <ends-with>
          <expression>(\”{3}|\’{3})</expression>
          <capture number=“1” name=“punctuation.definition.end”>
        </ends-with>
      </zone>
  </zones>
<syntax>

I have started a github project for sugar for Python along with Django and Google AppEngine.
I look forward to working along side you.

As for verification of syntax’s correctness you may always look to Python’s language reference.

Chase Colman - 18 November 2008 10:52 PM

I have started a github project for sugar for Python along with Django and Google AppEngine.
I look forward to working along side you.

As for verification of syntax’s correctness you may always look to Python’s language reference.

Just my two cents — due to the power of Espresso’s injection abilities, it makes a lot more sense in the vast majority of circumstances to start a *new Sugar* for frameworks or libraries, that injects into the basic language Sugar. I.E. have a Python.sugar, and then a Google App Engine.sugar the injects into the Python.sugar’s syntaxes and injectors and actions and whatnot.

Good to see some work on Python! (-:

elliottcable - 19 November 2008 07:12 AM

Chase Colman - 18 November 2008 10:52 PM

I have started a github project for sugar for Python along with Django and Google AppEngine.
I look forward to working along side you.

As for verification of syntax’s correctness you may always look to Python’s language reference.

Just my two cents — due to the power of Espresso’s injection abilities, it makes a lot more sense in the vast majority of circumstances to start a *new Sugar* for frameworks or libraries, that injects into the basic language Sugar. I.E. have a Python.sugar, and then a Google App Engine.sugar the injects into the Python.sugar’s syntaxes and injectors and actions and whatnot.

Good to see some work on Python! (-:

Chase Colman - 19 November 2008 09:24 AM

elliottcable - 19 November 2008 07:12 AM

Chase Colman - 18 November 2008 10:52 PM

I have started a github project for sugar for Python along with Django and Google AppEngine.
I look forward to working along side you.

As for verification of syntax’s correctness you may always look to Python’s language reference.

Just my two cents — due to the power of Espresso’s injection abilities, it makes a lot more sense in the vast majority of circumstances to start a *new Sugar* for frameworks or libraries, that injects into the basic language Sugar. I.E. have a Python.sugar, and then a Google App Engine.sugar the injects into the Python.sugar’s syntaxes and injectors and actions and whatnot.

Good to see some work on Python! (-:

I suppose that would keep the update process simple and allow better organization as a whole; however, being such heavily related “extensions” to the Python sugar, I will keep them under the same github project.

The problem is that my Sugar Manager.sugar is going to clone projects directly - that is, github.com/elliottcable/Ruby.sugar is going to be cloned into {espresso’s Sugars directory}/Ruby.sugar, so each sugar kind of needs to be it’s own project.

I suppose I could support multiple sugars in a repo, but I don’t know how I would ‘detect’ what Sugars you have in there, to list them for a user looking for Sugars.

There should definitely be separate Sugars for Python proper and any individual frameworks or libraries.

Okay then.

Only problem is that some features of Google AppEngine rely on Django, so, if the users only update one of the Sugars, it might introduce unwanted errors.

I suppose we should start on the Python syntax and itemizers first, then move on to frameworks once that is relatively stable.

Chase Colman - 20 November 2008 02:57 PM

Okay then.

Only problem is that some features of Google AppEngine rely on Django, so, if the users only update one of the Sugars, it might introduce unwanted errors.

I suppose we should start on the Python syntax and itemizers first, then move on to frameworks once that is relatively stable.

That sounds eminently reasonable. The dependancy thing goes for all such things - frameworks will obviously depend on you having the parent language installed, no reason one framework can’t rely on another framework.

I’m going to drop development of my Python sugar and only branch/contribute to sliceofpi’s work on his python.sugar.
I just wish he would have notified the forums of his progress before I started.