ANN: Celery 3.0 (chiastic slide) released!

[Ask Solem]

===
 Celery 3.0 (Chiastic Slide) Released!
===

Celery is a simple, flexible and reliable distributed system to
process vast amounts of messages, while providing operations with
the tools required to maintain such a system.

It's a task queue with focus on real-time processing, while also
supporting task scheduling.

Celery has a large and diverse community of users and contributors,
you should come join us on IRC (freenode.net: #celery)
or our mailing-list (http://groups.google.com/group/celery-users).

To read more about Celery you should go read the introduction:
  - http://docs.celeryproject.org/en/latest/getting-started/introduction.html

If you use Celery in combination with Django you must also
read the django-celery changelog and upgrade to django-celery 3.0
  - http://github.com/celery/django-celery/tree/master/Changelog

This version is officially supported on CPython 2.5, 2.6, 2.7, 3.2 and 3.3,
as well as PyPy and Jython.

/*
You should read the full changelog which contains important notes at:

- http://docs.celeryproject.org/en/latest/whatsnew-3.0.html
*/

Highlights
==

- A new and improved API, that is both simpler and more powerful.

Everyone must read the new "first-steps" tutorial,
and the new "next-steps" tutorial

  - http://bit.ly/celery-first-steps
  - http://bit.ly/celery-next-steps

Oh, and why not reread the user guide while you're at it :)

There are no current plans to deprecate the old API,
so you don't have to be in a hurry to port your applications.

- The worker is now thread-less, giving great performance improvements.

- The new "Canvas" makes it easy to define complex workflows.

Ever wanted to chain tasks together? This is possible, but
not just that, now you can even chain together groups and chords,
or even combine multiple chains.

Read more in the Canvas user guide:
  - http://docs.celeryproject.org/en/latest/userguide/canvas.html

- All of Celery's command line programs are now available from a single
umbrella command: ``celery``.

- This is the last version to support Python 2.5.

Starting with Celery 3.1, Python 2.6 or later is required.

- Support for the new librabbitmq C client.

Celery will automatically use the librabbitmq module
if installed, which is a very fast and memory-optimized
replacement for the amqplib module.

- Redis support is more reliable with improved ack emulation.

- Celery now always uses UTC

- Over 600 commits, 30k additions/36k deletions.

In comparison 1.0 to 2.0 had 18k additions/8k deletions.

Thank you to all users and contributors!

- http://celeryproject.org/



-- 
Ask Solem
twitter.com/asksol | +44 (0)7713357179



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: import bug

[Ask Solem]

On Nov 3, 1:52 am, Carl Banks  wrote:
> On Oct 31, 7:12 am, kj  wrote:
>
>
>
>
>
> > I'm running into an ugly bug, which, IMHO, is really a bug in the
> > design of Python's module import scheme.  Consider the following
> > directory structure:
>
> > ham
> > |-- __init__.py
> > |-- re.py
> > `-- spam.py
>
> > ...with the following very simple files:
>
> > % head ham/*.py
> > ==> ham/__init__.py <==
>
> > ==> ham/re.py <==
>
> > ==> ham/spam.py <==
> > import inspect
>
> > I.e. only ham/spam.py is not empty, and it contains the single line
> > "import inspect".
>
> > If I now run the innocent-looking ham/spam.py, I get the following
> > error:
>
> > % python26 ham/spam.py
> > Traceback (most recent call last):
> >   File "ham/spam.py", line 1, in 
> >     import inspect
> >   File "/usr/local/python-2.6.1/lib/python2.6/inspect.py", line 35, in 
> > 
> >     import string
> >   File "/usr/local/python-2.6.1/lib/python2.6/string.py", line 122, in 
> > 
> >     class Template:
> >   File "/usr/local/python-2.6.1/lib/python2.6/string.py", line 116, in 
> > __init__
> >     'delim' : _re.escape(cls.delimiter),
> > AttributeError: 'module' object has no attribute 'escape'
>
> > or, similarly,
>
> > % python3 ham/spam.py
> > Traceback (most recent call last):
> >   File "ham/spam.py", line 1, in 
> >     import inspect
> >   File "/usr/local/python-3.0/lib/python3.0/inspect.py", line 36, in 
> > 
> >     import string
> >   File "/usr/local/python-3.0/lib/python3.0/string.py", line 104, in 
> > 
> >     class Template(metaclass=_TemplateMetaclass):
> >   File "/usr/local/python-3.0/lib/python3.0/string.py", line 98, in __init__
> >     'delim' : _re.escape(cls.delimiter),
> > AttributeError: 'module' object has no attribute 'escape'
>
> > My sin appears to be having the (empty) file ham/re.py.  So Python
> > is confusing it with the re module of the standard library, and
> > using it when the inspect module tries to import re.
>
> Python is documented as behaving this way, so this is not a bug.
>
> It is arguably poor design.  However, Guido van Rossum already ruled
> against using a single package for the standard library, and its not
> likely that special case code to detect accidental name-clashes with
> the standard library is going to be added, since there are legitimate
> reasons to override the standard library.
>
> So for better or worse, you'll just have to deal with it.
>
> Carl Banks

Just have to add that you're not just affected by the standard
library.
If you have a module named myapp.django, and someone writes a cool
library called
django that you want to use, you can't use it unless you rename your
local django module.


file myapp/django.py:

from django.utils.functional import curry

ImportError: No module named utils.functional

At least that's what I get, maybe there is some workaround, some way
to say this is an absolute path?
-- 
http://mail.python.org/mailman/listinfo/python-list