The Karlsruhe Python User Group (KaPy) meets again.
Friday, 2012-10-19 (October 19th) at 19:00 (7pm) in the rooms of Entropia eV
(the local affiliate of the CCC). See http://entropia.de/wiki/Anfahrt
on how to get there.
For your calendars: meetings are held monthly, on the 3rd Friday.
There's also a mailing list at
https://lists.bl0rg.net/cgi-bin/mailman/listinfo/kapy.
Six Days of Django Training
===========================
There are still a couple of places in our Django courses
next week.
If you would like to get up to speed with Django, this course is for you:
October 15-17, 2012 (Leipzig, Germany) Introduction to Django [1]
If you already have solid Django knowledge or would like to continue
after the introductory training, you should consider this course:
October 18-20, 2012 (Leipzig, Germany) Advanced Django [2]
Feel free to ask me about it.
BTW, all courses are also available as in-house training.
Mike
[1] http://www.python-academy.com/courses/django_course_introduction.html
[2] http://www.python-academy.com/courses/django_course_advanced.html
Our next courses:
15.10.-17.10.2012 (Leipzig) Introduction to Django (English)
18.10.-20.10.2012 (Leipzig) Advanced Django (English)
27.10.2012 (Leipzig) SQLAlchemy (English)
28.10.2012 (Leipzig) Camelot (English)
12.-14.11.2012 (Antwerp, Belgium) Python for Programmers (English)
15.11.2012 (Antwerp, Belgium) SQLAlchemy (English)
16.11.2012 (Antwerp, Belgium) Camelot (English)
10.12.-12.12.2012 (Leipzig) Python für Programmierer (German)
13.12.-15.12.2012 (Leipzig) Python für Wissenschaftler und Ingenieure (German)
25.01.-27.01.2013 (Leipzig) Advanced Python (English)
28.01.-30.01.2013 (Leipzig) High-Performance Computation with Python (English)
one day each (can be booked separately)
- Optimizing of Python Programs
- Python Extensions with Other Languages
- Fast Code with the Cython Compiler
31.01.-01.02.2013 (Leipzig) High Performance XML with Python (English)
04.03.-08.03.2013 (Chicago, USA) Python for Scientists and Engineers (English)
15.04.-17.04.2013 (Leipzig) Python für Programmierer (German)
18.04.-20.04.2013 (Leipzig) Python für Wissenschaftler und Ingenieure (German)
10.06.-12.06.2013 (Leipzig) Python for Scientists and Engineers (English)
13.06.2013 (Leipzig) Fast Code with the Cython Compiler (English)
14.06.2013 (Leipzig) Fast NumPy Processing with Cython (English)
More information at http://www.python-academy.com
Hi everyone,
it's been a while since the last stable release series appeared, so I'm
proud to announce the final release of lxml 3.0.
http://lxml.de/http://pypi.python.org/pypi/lxml/3.0
In short, lxml is the most feature-rich and easy-to-use library for
processing XML and HTML in the Python language. It's also very fast, in
case you're interested in that. It runs on Python 2.4 - 3.3.
The 3.0 release features initial support for PyPy and a new tree API for
DTDs (by Walter Dörwald), as well as some major cleanups in the code base.
The lxml.cssselect package was moved into a separate PyPI project nicely
extended and maintained by Simon Sapin.
Originally, this release was targeted as lxml 2.4, but some major
improvements as well as a couple of potentially incompatible changes make
"3.0" appear more appropriate.
This release was built using Cython 0.17.1. Development on lxml's sources
now requires this version. Note that the build no longer uses Cython, even
if it is installed. Recompilation of the sources has to be requested
explicitly with the setup.py option "--with-cython".
If you are interested in commercial support or customisations for the lxml
package, please contact me directly.
Have fun,
Stefan
3.0 (2012-10-08)
================
Features added
--------------
Bugs fixed
----------
* End-of-file handling was incorrect in iterparse() when reading from
a low-level C file stream and failed in libxml2 2.9.0 due to its
improved consistency checks.
Other changes
-------------
* The build no longer uses Cython by default unless the generated C files
are missing. To use Cython, pass the option "--with-cython". To ignore
the fatal build error when Cython is required but not available (e.g. to
run special setup.py commands that do not actually run a build), pass
"--without-cython".
3.0beta1 (2012-09-26)
=====================
Features added
--------------
* Python level access to (optional) libxml2 memory debugging features
to simplify debugging of memory leaks etc.
Bugs fixed
----------
* Fix a memory leak in XPath by switching to Cython 0.17.1.
* Some tests were adapted to work with PyPy.
Other changes
-------------
* The code was adapted to work with the upcoming libxml2 2.9.0 release.
3.0alpha2 (2012-08-23)
======================
Features added
--------------
* The .iter() method of elements now accepts tag arguments like "{*}name"
to search for elements with a given local name in any namespace. With
this addition, all combinations of wildcards now work as expected:
"{ns}name", "{}name", "{*}name", "{ns}*", "{}*" and "{*}*". Note that
"name" is equivalent to "{}name", but "*" is "{*}*". The same change
applies to the .getiterator(), .itersiblings(), .iterancestors(),
.iterdescendants(), .iterchildren() and .itertext() methods, the
strip_attributes(), strip_elements() and strip_tags() functions as well
as the iterparse() function.
* C14N allows specifying the inclusive prefixes to be promoted to
top-level during exclusive serialisation.
Bugs fixed
----------
* Passing long Unicode strings into the feed() parser interface failed to
read the entire string.
Other changes
-------------
3.0alpha1 (2012-07-31)
======================
Features added
--------------
* Initial support for building in PyPy (through cpyext).
* DTD objects gained an API that allows read access to their
declarations.
* xpathgrep.py gained support for parsing line-by-line (e.g.
from grep output) and for surrounding the output with a new root
tag.
* E-factory in lxml.builder accepts subtypes of known data
types (such as string subtypes) when building elements around them.
* Tree iteration and iterparse() with a selective tag
argument supports passing a set of tags. Tree nodes will be
returned by the iterators if they match any of the tags.
Bugs fixed
----------
* The .find*() methods in lxml.objectify no longer use XPath
internally, which makes them faster in many cases (especially when
short circuiting after a single or couple of elements) and fixes
some behavioural differences compared to lxml.etree. Note that
this means that they no longer support arbitrary XPath expressions
but only the subset that the ElementPath language supports.
The previous implementation was also redundant with the normal
XPath support, which can be used as a replacement.
* el.find('*') could accidentally return a comment or processing
instruction that happened to be in the wrong spot. (Same for the
other .find*() methods.)
* The error logging is less intrusive and avoids a global setup where
possible.
* Fixed undefined names in html5lib parser.
* xpathgrep.py did not work in Python 3.
* Element.attrib.update() did not accept an attrib of
another Element as parameter.
* For subtypes of ElementBase that make the .text or .tail
properties immutable (as in objectify, for example), inserting text
when creating Elements through the E-Factory feature of the class
constructor would fail with an exception, stating that the text
cannot be modified.
Other changes
--------------
* The code base was overhauled to properly use 'const' where the API
of libxml2 and libxslt requests it. This also has an impact on the
public C-API of lxml itself, as defined in etreepublic.pxd, as
well as the provided declarations in the lxml/includes/ directory.
Code that uses these declarations may have to be adapted. On the
plus side, this fixes several C compiler warnings, also for user
code, thus making it easier to spot real problems again.
* The functionality of "lxml.cssselect" was moved into a separate PyPI
package called "cssselect". To continue using it, you must install
that package separately. The "lxml.cssselect" module is still
available and provides the same interface, provided the "cssselect"
package can be imported at runtime.
* Element attributes passed in as an attrib dict or as keyword
arguments are now sorted by (namespaced) name before being created
to make their order predictable for serialisation and iteration.
Note that adding or deleting attributes afterwards does not take
that order into account, i.e. setting a new attribute appends it
after the existing ones.
* Several classes that are for internal use only were removed
from the lxml.etree module dict:
_InputDocument, _ResolverRegistry, _ResolverContext, _BaseContext,
_ExsltRegExp, _IterparseContext, _TempStore, _ExceptionContext,
__ContentOnlyElement, _AttribIterator, _NamespaceRegistry,
_ClassNamespaceRegistry, _FunctionNamespaceRegistry,
_XPathFunctionNamespaceRegistry, _ParserDictionaryContext,
_FileReaderContext, _ParserContext, _PythonSaxParserTarget,
_TargetParserContext, _ReadOnlyProxy, _ReadOnlyPIProxy,
_ReadOnlyEntityProxy, _ReadOnlyElementProxy, _OpaqueNodeWrapper,
_OpaqueDocumentWrapper, _ModifyContentOnlyProxy,
_ModifyContentOnlyPIProxy, _ModifyContentOnlyEntityProxy,
_AppendOnlyElementProxy, _SaxParserContext, _FilelikeWriter,
_ParserSchemaValidationContext, _XPathContext,
_XSLTResolverContext, _XSLTContext, _XSLTQuotedStringParam
* Several internal classes can no longer be inherited from:
_InputDocument, _ResolverRegistry, _ExsltRegExp, _ElementUnicodeResult,
_IterparseContext, _TempStore, _AttribIterator, _ClassNamespaceRegistry,
_XPathFunctionNamespaceRegistry, _ParserDictionaryContext,
_FileReaderContext, _PythonSaxParserTarget, _TargetParserContext,
_ReadOnlyPIProxy, _ReadOnlyEntityProxy, _OpaqueDocumentWrapper,
_ModifyContentOnlyPIProxy, _ModifyContentOnlyEntityProxy,
_AppendOnlyElementProxy, _FilelikeWriter, _ParserSchemaValidationContext,
_XPathContext, _XSLTResolverContext, _XSLTContext,
_XSLTQuotedStringParam, _XSLTResultTree, _XSLTProcessingInstruction
Hi all,
I'm very pleased to announce new releases of Pylint and
underlying ASTNG library, respectivly 0.26 and 0.24.1. The great
news is that both bring a lot of new features and some bug fixes,
mostly provided by the community effort.
We're still trying to make it easier to contribute on our free
software project at Logilab, so I hope this will continue and
we'll get even more contritions in a near future, and an even
smarter/faster/whatever pylint!
So many thanks to all those who made that release, and enjoy!
--
Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure: http://www.logilab.fr/services
CubicWeb, the semantic web framework: http://www.cubicweb.org
Hey all,
I'm pleased to announce that mock 1.0.0 has been released. This is the "standard library version", mock 1.0.0 has feature parity with "unittest.mock" in the Python 3.3 standard library.
mock is a library for testing in Python. It allows you to replace parts of your system under test with mock objects and make assertions about how they have been used.
You can download mock from the PyPI page or install it with:
pip install -U mock
http://pypi.python.org/pypi/mockhttp://www.voidspace.org.uk/python/mock/http://www.voidspace.org.uk/python/mock/changelog.html#version-1-0-0
Full list of changes since 0.8:
* `mocksignature`, along with the `mocksignature` argument to `patch`, removed
* Support for deleting attributes (accessing deleted attributes will raise an
`AttributeError`)
* Added the `mock_open` helper function for mocking the builtin `open`
* `__class__` is assignable, so a mock can pass an `isinstance` check without
requiring a spec
* Addition of `PropertyMock`, for mocking properties
* `MagicMocks` made unorderable by default (in Python 3). The comparison
methods (other than equality and inequality) now return `NotImplemented`
* Propagate traceback info to support subclassing of `_patch` by other
libraries
* `create_autospec` works with attributes present in results of `dir` that
can't be fetched from the object's class. Contributed by Konstantine Rybnikov
* Any exceptions in an iterable `side_effect` will be raised instead of
returned
* In Python 3, `create_autospec` now supports keyword only arguments
* Added `patch.stopall` method to stop all active patches created by `start`
* BUGFIX: calling `MagicMock.reset_mock` wouldn't reset magic method mocks
* BUGFIX: calling `reset_mock` on a `MagicMock` created with autospec could
raise an exception
* BUGFIX: passing multiple spec arguments to patchers (`spec` , `spec_set` and
`autospec`) had unpredictable results, now it is an error
* BUGFIX: using `spec=True` *and* `create=True` as arguments to patchers could
result in using `DEFAULT` as the spec. Now it is an error instead
* BUGFIX: using `spec` or `autospec` arguments to patchers, along with
`spec_set=True` did not work correctly
* BUGFIX: using an object that evaluates to False as a spec could be ignored
* BUGFIX: a list as the `spec` argument to a patcher would always result in a
non-callable mock. Now if `__call__` is in the spec the mock is callable
All the best,
Michael Foord
Hello,
django-simple-friends 0.5 is released:
http://pypi.python.org/pypi/django-simple-friends/0.5
What is django-simple-friends
-----------------------------
django-simple-friends is a Django app that allows you to define and manage
friendship relations and also blocking between your users. It is released
under BSD license.
You can find the source code and bug tracker here:
https://github.com/muhuk/django-simple-friends/
Changes in version 0.5
----------------------
* friend_list view is removed. See friends template filter.
* View functions are rewritten as class based views. But they still work as
aliases.
* post_syncdb signals to fix the issue of User's without
Friendship's.
* Proper Sphinx powered documentation.
* German & Spanish translations.
I would like to take the opportunity to thank Jannis, Arturo and Petro for
their
contributions.
--
Kind Regards,
Atamert Ölçgen
-+-
--+
+++
www.muhuk.com
http://plumbum.readthedocs.org/en/latest/index.html
Ever wished the wrist-handiness of shell scripts be put into a real programming language? Say hello to Plumbum Shell Combinators. Plumbum (Latin for lead, which was used to create pipes back in the day) is a small yet feature-rich library for shell script-like programs in Python. The motto of the library is “Never write shell scripts again”, and thus it attempts to mimic the shell syntax (shell combinators) where it makes sense, while keeping it all Pythonic and cross-platform.
Apart from shell-like syntax and handy shortcuts, the library provides local and remote command execution (over SSH), local and remote file-system paths, easy working-directory and environment manipulation, and a programmatic Command-Line Interface (CLI) application toolkit.
Dear all,
There are many enhancements and bug fixes, notably
- Tests run in parallel if run locally on a multicore machine
- Improved handling of knownbugs
- New possibility to split up long result files with many different
changes present.
Regards,
Geoff Bache
....
TextTest is a tool for automatic text-based functional testing. This
means running a batch-mode executable in lots of different ways from
the command line, and using the text output produced as a means of
controlling the behavior of that application. As well as being usable
"standalone", it is an extendable framework for black-box testing
written in Python. It's also useful as a test management tool wrapping
some other test tool as a test runner.
Homepage: http://www.texttest.org
Download: http://sourceforge.net/projects/texttest
Mailing list: https://lists.sourceforge.net/lists/listinfo/texttest-users
Bugs: https://bugs.launchpad.net/texttest
Source: https://code.launchpad.net/texttest
Hi all,
The 3.8 release features the following:
- The NameChooser UI has been generalised and enhanced, offering a
hierarchical view and the possibility to create shortcuts.
- Added retry loop when replayed events fail, means some application
events aren't needed
- New file-polling mechanism added for synchronising on external events
- Possibilities to filter out certain widget types from the description
- Many improvements to SWT/Eclipse RCP/GEF support which continues to mature
- Some improvements and fixes for Swing also
- Support for PyGTK apps using gtk.Builder added
Regards,
Geoff Bache
A bit more detail:
StoryText is an unconventional GUI testing tool for PyGTK, Tkinter,
wxPython, Swing and SWT along with a Python framework for testing GUIs
in general.
Instead of recording GUI mechanics directly, it asks the user for
descriptive names and hence builds up a "domain language" along with a
"UI map file" that translates this language into actions on the
current GUI widgets. The point is to reduce coupling, allow very
expressive tests, and ensure that GUI changes mean changing the UI map
file but not all the tests.
Instead of an "assertion" mechanism, it auto-generates a log of the
GUI appearance and changes to it. The point is then to use that as a
baseline for text-based testing, using TextTest.
It also includes support for instrumenting code so that "waits" can be
recorded, making it far easier for a tester to record correctly
synchronized tests without having to explicitly plan for this.
Homepage: http://www.texttest.org/index.php?page=ui_testing
Download: http://sourceforge.net/projects/pyusecase
Mailing list: https://lists.sourceforge.net/lists/listinfo/texttest-users
Bugs: https://bugs.launchpad.net/storytext/
Source: https://code.launchpad.net/storytext/
Hi all,
WinPython v2.7.3.1 has been released and is available for 32-bit and
64-bit Windows platforms:
http://code.google.com/p/winpython/
WinPython is a free open-source portable distribution of Python for
Windows, designed for scientists.
It is a full-featured (see
http://code.google.com/p/winpython/wiki/PackageIndex) Python-based
scientific environment:
* Designed for scientists (thanks to the integrated libraries NumPy,
SciPy, Matplotlib, guiqwt, etc.:
* Regular *scientific users*: interactive data processing and
visualization using Python with Spyder
* *Advanced scientific users and software developers*: Python
applications development with Spyder, version control with Mercurial
and other development tools (like gettext)
* *Portable*: preconfigured, it should run out of the box on any
machine under Windows (without any installation requirements) and the
folder containing WinPython can be moved to any location (local,
network or removable drive)
* *Flexible*: one can install (or should I write "use" as it's
portable) as many WinPython versions as necessary (like isolated and
self-consistent environments), even if those versions are running
different versions of Python (2.7, 3.x in the near future) or
different architectures (32bit or 64bit) on the same machine
* *Customizable*: using the integrated package manager (wppm, as
WinPython Package Manager), it's possible to install, uninstall or
upgrade Python packages (see
http://code.google.com/p/winpython/wiki/WPPM for more details on
supported package formats).
*WinPython is not an attempt to replace Python(x,y)*, this is just
something different (see
http://code.google.com/p/winpython/wiki/Roadmap): more flexible,
easier to maintain, movable and less invasive for the OS, but
certainly less user-friendly, with less packages/contents and without
any integration to Windows explorer [*].
[*] Actually there is an optional integration into Windows explorer,
providing the same features as the official Python installer regarding
file associations and context menu entry (this option may be activated
through the WinPython Control Panel).
Enjoy!