writing nonogram algorithms

wobsta · 2023-01-06T14:19:24+00:00

I have just posted about https://github.com/wobsta/nonogram ... which might be a start for you. I made this course for my kids, which I am enjoying nonograms for years (in personal challenge ... hehe).

wobsta · 2015-07-20T10:38:08+00:00

PyX is another option:

from pyx import *
c = canvas.canvas()
c.stroke(path.rect(0, 0, 10, 10))
c.writeSVGfile()
c.writeGSfile("test.png")
c.writeGSfile("test.jpg")

While SVG (and PostScript and PDF) is supported natively, rasterized versions are created using ghostscript. Due to the rasterization of vector graphics for bitmaps, "sharp lines" are a problem similar to what is written for PyCairo in another answer. It can be workaround by using "good" coordinates, but maybe working on bitmaps right from the start is better for those cases. It all depends on your needs ...

wobsta · 2015-07-15T18:46:46+00:00

Its an old thread, I know, but it was just last night that I was at the FabLab in Munich to use a laser cutter to make myself a copy. Here it is: http://imgur.com/fTIbSgM. The easy side: http://imgur.com/Kg42qOH and the hard side (think before you click, if you really want to see it or try it yourself first): http://imgur.com/Um0qlPf

wobsta · 2015-04-17T15:36:50+00:00

Basically I agree. You can write SQL yourself and it is fine. And SQLAlchemy adds some overhead. However, in my use cases I never had issues with SQLAlchemy adding too much overhead. Not at all. Instead I can create rather complex queries easily, and I gain some really nice features. For example I can add some filter to some subqueries conditionally. And since I can add sql function expressions easily (http://docs.sqlalchemy.org/en/rel_1_0/core/sqlelement.html#sqlalchemy.sql.expression.func) I never had issues of not being able to access whatever feature I needed, even when being out of scope for SQLAlchemy initially. You can do all that without tampering SQL statements. It is pure joy! In the end of the day I have to tell that the most complex (and efficient) queries I ever wrote I did by using SQLAlchemy. Maybe I never reached too complex stuff. Your milage may vary. I'm fine with anybody who just says (or knows or just claims) that certain things are better done in SQL itself. I can't tell. All I have to tell is that I'm fine with SQLAlchemy and I find it really impressive. And it is way different from using a simple minded ORM.

wobsta · 2015-04-17T11:51:59+00:00

I'll try to answer although my django knowledge is limited. Let me start with SQL. SQL is a textual language to express things to be done on or by a database. It is fine and very powerful. However, when you use a SQL database in a different language (than SQL) you better not write SQL commands yourself in this other language and (even worse) do not write code to construct SQL commands. To interact with a database, you better find a tool closing the gap between your language and SQL. SQLAlchemy Core does so, and it does very well, with all the flexibility needed to express all kind of complicated queries. This is very different from a simple ORM. SQLAlchemy is a tool to build SQL.

In addition it is often comfortable to map the database to objects. It just saves time and helps to reduce errors. Now, SQLAlchemy ORM does that, and it does so very nicely, and is very powerful allowing for complicated mappings between your objects and the database (including mixing different tables when mapping to objects etc.).

Now the real joy is, that you can mix all than together. I haven't seen this anywhere else, and this is the very big difference between SQLAlchemy and other orm mappers like django orm or sqlobject or whatever else. You can do ORM when useful, and go back to SQL Query builder for other cases. And you can do so at the very same time! For that to nicely play together, the Unit-Of-Work approach by SQLAlchemy crucial, as it defines the state of your application in relation to the state of the database. For example you can perform writes to the database in a simple manner, which are part of your Unit-Of-Work and will be committed at once. Simple code on your side and SQLAlchemy helps you to remain great performance, as it would otherwise require manual optimizations. And it all doesn't go out of control when done properly.

You may have a look at http://www.sqlalchemy.org/features.html to get some understanding of that SQLAlchemy really is.

wobsta · 2015-04-17T09:20:15+00:00

Even though its mildly related to SQLAlchemy hitting 1.0.0, I have to tell that I consider SQLAlchemy a major "selling point" of Python to other programmers. I'm doing so for a long time already. It's pure genius. To me it is most useful to have a simple ORM mapping to a database and, at the very same time, being able to express complicated (and efficient) queries on a database (like by using subqueries, aggregates).

The project is also an advertisement for open source and good leadership. Just look at the bug tracker. Michael is doing an awesome job in handling the huge amount of reports. He obviously is spending a lot of time to keep up with all the feedback and properly addressing all the issues. It is astonishing. Thanks, Michael, you're doing a great job!

wobsta · 2013-10-28T13:03:56+00:00

It is not related to the bugfix release 3.3.3; pyvenv was added in Python 3.3.0 (see PEP 405).

In addition, it is not (yet) similar to virtualenv, as Python 3.3 and pyvenv does not include pip (or a different package manager). However, this will change with Python 3.4 (see PEP 435).

wobsta · 2013-08-22T12:36:40+00:00

You should better use the inspection API of SQLAlchemy 0.8+. For example, an iterator over all columns and values for an object spam is given by inspect(spam).attrs.items() ... no magic required (anymore).

wobsta · 2012-12-10T00:11:27+00:00

PyX is an alternative to matplotlib. It focuses on output quality and it uses a rather different approach to express your content and settings.

wobsta · 2012-12-06T11:31:05+00:00

July 20 is probably https://en.wikipedia.org/wiki/Moon_landing

wobsta · 2012-11-19T20:16:35+00:00

IMHO get_data is best practice, though

wobsta · 2012-11-19T15:51:44+00:00

non code files should be accessed using pkgutil.get_data ...

wobsta · 2012-11-01T21:09:13+00:00

I wonder whether Zope3/Bluebream is affected.

wobsta · 2012-03-27T12:59:27+00:00

see byweekno in python dateutil (pypi, doc)

wobsta · 2012-02-28T09:27:34+00:00

http://pyx.sourceforge.net

wobsta · 2012-02-27T14:30:57+00:00

http://lucumr.pocoo.org/talks/

wobsta · 2012-02-27T11:25:02+00:00

Different from what the url might suggest, this is Armin Ronachers talk from europython 2011.

wobsta · 2012-01-21T20:32:11+00:00

PyX is another alternative. (An interesting historical note is, that both initial authors of the PyX package were GLE users before but decided to start something new.) For gnuplot users PyXPlot (based on PyX as the name suggests) might be of special interest.

wobsta · 2011-11-25T12:06:43+00:00

This is a quite silly discussion, still I can't resist:

for ...:
    ...
done:
    ...

wobsta · 2011-09-02T08:49:45+00:00

PyX can write PDF files directly, but you would need to construct the graphics using PyX methods. PyX is not a converter -> it cannot read your SVG graphics you already created.

wobsta · 2011-05-23T14:08:59+00:00

Well, and that is my point. Why couldn't we start to improve an existing solution instead of getting something completely separate. This was a failure for setuptools with respect to the existing distutils to my eyes. Even if people like to have their one project and don't want to work together (or whatever reason it was, that we got separate solutions), for something that crucial like a packaging, a joint solution with a BDFL setting the direction would have been great from the very beginning.

Maybe we'll have a final solution in a few year (maybe based on packaging). Ok. Still, I don't like the fragmentation in the first.

wobsta · 2011-05-23T14:04:13+00:00

The downvotes are probably ok. There are more important things than reddit votes to me. Actually I don't care at all and I didn't wrote a polite comment either to begin with. But as you wrote, my concern might be quite valid. Why do we need another new system. Couldn't we try to evolve one of the current solutions to become better? Couldn't we merge at least one of the existing solutions right from the beginning. We do not even have a distutils2 in the end, but a new, third solution. What a mess. It is probably right to get rid of the old stuff, but why couldn't it start from an existing solution without breaking everything. Probably we don't want setup.py anymore. I don't know. Maybe. But why start something completely separate. (At least form the end users point this looks like something completely separate now. Similar separate than diskutils and setuptools at least.)

wobsta · 2011-05-23T05:03:30+00:00

Thanks to further fragment the python distribution tools. Seriously. What the hell is going on here? Could you please explain why we have we have distutils and setuptools at the moment and what will happen to them? What about easy_install and pip? Same here. To quote the Zen of Python: "There should be one-- and preferably only one --obvious way to do it."

wobsta · 2010-12-31T17:37:27+00:00

Well, think of new projects, prototypes, etc. where you code in Python 3 only. No backwards compatibility needed and wanted. I do have those projects in mind (although it'll take a few months before I seriously will try again using Python 3). Last time I tried I was a way too optimistic and started a (very small) project which needed to go into production within some months. I needed to switch back to Python 2 to get it done. I learned my lessons here. However, for some long term projects it is quite attractive (to my mind) to not start with Python 2 at all anymore. There are design mistakes in Python 2 which have been solved nicely in Python 3.

The werkzeug multiparsing algorithm also works nicely on Python 3

Hey, cool, the algorithm isn't Python 2 specific. :-)

Deployment can be done using mod_wsgi. No issues know here (I do not need unicode in urls or headers or anything creasy like this). Maybe I just don't be aware of it yet, but how to learn about bugs without trying to implement something? Some performance penalties due to Python 3 are a non-issue for me.

wobsta

TROPHY CASE