freakboy3742

The full standard library is a work in progress; at the moment, there's only a couple of key parts of sys, os, and the like. But Ouroboros (https://github.com/pybee/ouroboros) is a project to develop a full standard library that can be integrated into any Python implementation. Effectively, you can use all the bits of the standard library that are written in Python by just compiling them; the rest requires native integration (which is the work in progress).

Good news on the generator front - VOC fully supports generators, lambdas, passing functions as arguments, and all sorts of things that Python allows but Java (the language) doesn't.

As for a guide to calling Java from Python - we don't have any good documentation for this (yet), but it's entirely possible. Here's a sample Android application. If you're familiar with the Android APIs, you should be able to see the syntax conventions in place. https://gist.github.com/freakboy3742/7beb22c587e57240610777a...

If you want a smaller target, VOC (http://pybee.org/voc) can generate a "Hello World" APK in about 1.6MB.

VOC is compiler that takes Python code, and output Java bytecode. This means you can use the Android native UI components, because your Python code becomes indistinguishable from code written in Java. Combine with Briefcase (http://pybee.org/briefcase), and you can get an Android app with one command; combine with Toga (http://pybee.org/toga), and you can get a cross platform app using native system components.

If you want to see this in action, here's a video: https://www.youtube.com/watch?v=RisCgSIWwLA

(Full disclosure - I'm the primary author of these tools)

AFAIK, Plyer will give you access to native APIs like accelerometers, but not to the native GUI layer.

An alternative approach is VOC (http://pybee.org/voc) - this is compiler that takes Python code, and output Java bytecode. This means you can use the Android native UI components, because your Python code becomes indistinguishable from code written in Java. Combine with Briefcase (http://pybee.org/briefcase), and you can get an Android app with one command; combine with Toga (http://pybee.org/toga), and you can get a cross platform app using native system components.

If you want to see this in action, here's a video: https://www.youtube.com/watch?v=RisCgSIWwLA

(Full disclosure - I'm the primary author of these tools)

The primary difficulty is that JNI is really limited on Android. It exists, but it's really slow, and there are some hard limits imposed at the kernel level.

An alternative approach is VOC (http://pybee.org/voc) - this is compiler that takes Python code, and output Java bytecode. This means you can use the Android native UI components, because your Python code becomes indistinguishable from code written in Java. Combine with Briefcase (http://pybee.org/briefcase), and you can get an Android app with one command; combine with Toga (http://pybee.org/toga), and you can get a cross platform app using native system components.

If you want to see this in action, here's a video: https://www.youtube.com/watch?v=RisCgSIWwLA

(Full disclosure - I'm the primary author of these tools)

Erm... RTD does none of those things. There's a default site theme that is specific to RTD - they don't try to impersonate anyone. They don't "lift" anything unless the project owner has opened an account and requested that their documentation be hosted on RTD.

I'm at a complete loss how you've even come to the impression that RTD does the things you claim it does - because it does nothing of the sort.

Why you put Read The Docs in the same category? RTD doesn't host anything unless you specifically set up an account and say you want to use them. They don't troll the web looking for projects, and hosting their docs whether they want them to or not.

The Fellow's immediate reporting chain is to a subcommittee of the DSF. Effectively, they're "working" for the DSF (although as a contractor, not as an employee); that committee is responsible for working out if they're doing what they're supposed to do, whether the DSF is getting good value for money, and so on.

The technical board is there to provide decisions on technical issues, whether they come from the Fellows or from the general population. I'd be very surprised if the Fellows didn't regularly identify issues that needed the technical board to render a decision, but the technical board doesn't have any specific control over the fellow.

Thanks for the feedback! I cover some of the "why" in the docs, but I agree the homepage could do a better job of making the case for a new UI toolkit.

The short version:

* System native widgets, not themes

* Installable via "pip install" - no third party or binary dependencies

* Not just naïve wrappers around widgets - capture the underlying use case and provide an API wrapper.

* Genuinely Python native. This means exploiting language specific features (like generators and context managers)

FYI, Toga uses Cassowary as well - natively through Apple's implementation on OSX and iOS, and via a Python implementation of the algorithm (http://pybee.org/cassowary/) for GTK and Windows.

Spotify's UI is many things, but it doesn't even begin to appear system native.

Given that the project was announced publicly 1 week ago, I wouldn't expect to see it in Debian (testing or otherwise) for a little while.

Not yet. Android support is on the todo list once I've processed all the feedback that has come as a result of the initial release.

Thanks for the promotion :-)

Of those tools, the test runner (cricket) is the most mature; the debugger isn't much more than a proof of concept. Those tools are also based in Tkinter at the moment; I started Toga because I've started to hit the limits of Tkinter.

The intention is to port the other PyBee tools to Toga as soon as they get mature enough.

Sounds like you're on Windows. Unfortunately, Windows support is pretty primitive at this point (reflecting my own priorities - OSX, Unix and mobile support is a more pressing concern). I'll update the homepage and docs to better reflect the current project status.

Longer term, I definitely want to support Windows to the same level as other platforms; any assistance on this front would be gratefully accepted.

Project author here; Thanks for the heads up - I haven't come across Enaml before. I'll take a look.

Thanks for the kind words.

Yes, the project is very early stage - I've been tinkering for 6 months in my spare time (and it's not like I had a whole lot of that to start with). Getting cross platform on 4 platforms has, as you might expect, taken a bit of effort.

I started down this path because the existing options didn't satisfy me. When my initial couple of weeks of tinkering proved that it was possible to get widgets without binary dependencies, that gave me the momentum to get to the point that I've publicly announced. There's plenty left to do, but I've got high hopes.

I'll completely agree. This is a project that has been built in the last 6 months of my spare time from all my other projects, and most of that time has been spent getting things to a point where they work. The APIs aren't yet stable enough to warrant me spending a bunch of time formalising them, but I absolutely want to document them as soon as the ground stops moving :-)

Project author here; let me confirm that Toga only uses GTK+ under Ubuntu/Linux. On OS/X, it uses Cocoa. I've just clarified the text in that section of the website. Thanks for the heads up.

The spacing and margins are all manually specified (or, in the case of the example, aren't specified at all, so they default to 0). If you cared to do so, this spacing could be manually adjusted.

Under the hood, it's 100% native widgets (i.e., on OSX, the code is actually instantiating an NSButton, adding it to an NSView, set as content on an NSWindow; on Ubuntu, it uses Gtk.Button etc), so the look and feel of the widgets themselves are exactly as the platform dictates.

Thanks for the compliment. As others have pointed out, this isn't an idea of my own creation - others (e.g., SQLAlchemy) have taken similar approaches in other APIs. I'm just exploiting a pattern that I've seen used to good effect elsewhere.

I'll save you the suspense - we've run the campaign twice, and we're not going to run it again. Part of the sales gimmick was that it was the limited availability.

But, fear not - given the success of the campaign this time, I think it's fair to say that when the time comes, there will be a Django 1.8 release shirt.

One feature that all these tools share is that they're console based. This is nice, but there's a reason we all use graphical environments for our daily computing -- rich graphical user interfaces are a powerful tool for visualising complex data. However, you don't have to adopt a full IDE to get a graphical UI. Bugjar (http://pybee.org/bugjar) is a graphical debugger -- not an IDE, just a debugger. It uses Tkinter, so it's cross platform, and can be installed using "pip install bugjar".

It's an early stage project, but hopefully demonstrates that there is a middle ground between "Everything in an 80x25 text window" and "500lb IDE gorilla".

(Full disclosure: I'm the core developer of Bugjar)

(BugJar core developer here) Thanks for the compliment. Bugjar is a work in progress; it's got some rough edges, and definitely some missing features -- but I'm excited for what it can become.

The amount of work involved is entirely dependent on how different your User model is. If you've got a model where the username is even similar to the normal Django User, you don't need to redefine anything - you can use the existing forms and ModelAdmin.

If your model uses a different identifer field (e.g., email, rather than username), or doesn't share common fields with the default User, then yes, you'll need to redefine some forms. That shouldn't be too surprising, though -- if you've created a model that's nothing like Django's default User model, it shouldn't be surprising that you need to do some work to support it.

However, you shouldn't need to redefine any views, and the forms that need redefinition are fairly simple -- a fully worked example is in the docs.

On top of that, those forms and ModelAdmin definitions should be extremely reusable - it will be easy to package an "email-based" user model for reuse between projects.

Yes - that's the primary goal of the change. However, there's lots of other possibilities, too. The point is to make the definition of the "User" model as flexible as possible.

I'm the author of the feature, so I figured I should give some explanation.

REQUIRED_FIELDS is used internally in one place -- in the createsuperuser management command. When you run that command, you are prompted for the minimal set of fields to create a user object. REQUIRED_FIELDS is that list of fields.

Could this be used elsewhere? Sure. A model form, for example, could use this list as the minimal data to create a user object.

Could this be replaced with some model introspection? Possibly. On my first pass through, this is exactly what I tried to do. And the code got messy really quickly.

At a first approximation, any field with blank=False and no default is essentially "required". However, what about BooleanFields? BooleanFields have an automatically default to False, but that doesn't necessarily mean that False is an appropriate value. And what about custom fields that use the same "built-in default" pattern?

There's also a possible edge case where a field strictly isn't required (e.g., it's blankable) but from a business logic perspective, you always want to have a value.

Ultimately, I came to the conclusion that the mess was worth it. That said, I'm not 100% opposed to cleaning it up. Essentially, if someone can make createsuperuser work without the need for REQUIRED_FIELDS, and the code is robust and isn't a mess, I'm willing to look at the patch before 1.5 final. However, I'm not planning on looking at this problem myself.

There are two main reasons for a project to have a foundation.

Firstly, there's the legal benefits. The foundation can be the legal guardian of copyrights and trademarks associated with a project. Copyrights and trademarks have to be owned by someone -- even if you're open source. Having a foundation provides a way to have some public governance of those legal instruments, instead of having them held by an individual or private company.

Secondly, there's the community organization benefits. If anyone wants to donate money to a project, someone has to accept that money. Having a foundation provides a entity that can accept that money, and then distribute it. As an added bonus, it means that money can be donated in a tax-attractive way (the DSF is a 501(c)(3) not-for-profit, so donations are tax deductible in the US), which makes it easier to attract donations.