Hi,
just in case it is of any help/relevance: I can reproduce the
problem with pyx.__version__ 0.12.1.
Best, Arnd
On Fri, 9 Jan 2015, Michael SCHINDLER wrote:
> Hello André,
>
> I found a strange behaviour of the axis partitioning, when combining
> it with manual ticks and a divisor. The x2-axis (which is
> automatically linked to x) has a tick at 10pi instead of a tick at pi.
> See the joint example.
>
> It would be great if you could see to it...
>
> Best,
> Michael
>
>

Hello André,
I found a strange behaviour of the axis partitioning, when combining
it with manual ticks and a divisor. The x2-axis (which is
automatically linked to x) has a tick at 10pi instead of a tick at pi.
See the joint example.
It would be great if you could see to it...
Best,
Michael

Gert,
Thank you for the suggestion. You're right, and we should probably rethink the data handling. It is rather old code, and its design probably predates the Python 2.2 release, where iterators have been introduced. At least it was working on older Python versions for many years. I'm making myself a note and we can probably address this in one of the next releases.
Best,
André
Am 06.01.2014 um 09:19 schrieb Gert Ingold <gert.ingold@...>:
> Dear André and Jörg,
>
> first of all a happy (and productive;-) new year!
>
> I just started to make my first plots with PyX 0.13 and came across
> the following problem. In graph.data.points I frequently use something
> like zip(xvals, yvals) where xvals would be e.g. a Numpy linspace and
> yvals is evaluated by applying Numpy functions to xvals. With Python 2
> this
> works fine because zip produces a list. However, in Python 3, zip
> produces an
> iterable which is not compatible with graph.data.points requiring an
> object
> with a len-method. I am wondering whether it would make sense to
> rewrite
> graph.data.points in such a way that it accepts iterables. It seems
> that
> this would be more Python3-like. What do you think?
>
> Best regards,
> Gert
>
> --
> Gert-Ludwig Ingold email: Gert.Ingold@...
> Institut für Physik Phone: +49-821-598-3234
> Universität Augsburg Fax: +49-821-598-3222
> D-86135 Augsburg WWW: http://www.physik.uni-augsburg.de/theo1/ingold
> Germany PGP: 86FF5A93, key available from homepage
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> PyX-devel mailing list
> PyX-devel@...
> https://lists.sourceforge.net/lists/listinfo/pyx-devel
--
by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
/ \ \ / ) wobsta@..., http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript and PDF figures
(_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/

Dear André and Jörg,
first of all a happy (and productive;-) new year!
I just started to make my first plots with PyX 0.13 and came across
the following problem. In graph.data.points I frequently use something
like zip(xvals, yvals) where xvals would be e.g. a Numpy linspace and
yvals is evaluated by applying Numpy functions to xvals. With Python 2
this
works fine because zip produces a list. However, in Python 3, zip
produces an
iterable which is not compatible with graph.data.points requiring an
object
with a len-method. I am wondering whether it would make sense to
rewrite
graph.data.points in such a way that it accepts iterables. It seems
that
this would be more Python3-like. What do you think?
Best regards,
Gert
--
Gert-Ludwig Ingold email: Gert.Ingold@...
Institut für Physik Phone: +49-821-598-3234
Universität Augsburg Fax: +49-821-598-3222
D-86135 Augsburg WWW: http://www.physik.uni-augsburg.de/theo1/ingold
Germany PGP: 86FF5A93, key available from homepage

Hi all,
We're prod to to announce the release of PyX 0.13. In this release PyX has been ported to Python 3. It now requires Python 3.2 and above, Python 2 is not supported by this release anymore. If you need to use Python 2, please use one of the previous releases.
Along with the port to Python 3 a major modernization of the text module was done, including some new documentation (based on Sphinx autodoc). We also added a sphinx theme to make the manual and the FAQ look like the PyX website.
The normpath now removes cusps by splitting normcurves as necessary. Thus there are no points on a normpath anymore, where no tangent, curvature, transformation, etc. are defined. The only discontinuities left are at the parameter values a switch from one path element to the next occurs (which is fine). Michael Schindler contributed some major improvements on the parallel deformer.
We also improved the usability within IPython and provide IPython notebook files for the examples. In fact, the gallery has completely removed from the subversion repository and is now a wiki on the sourceforge website featuring IPython notebooks as well. You are welcome to contribute to this resource [*].
Various improvements and fixes complete the release. Please find the full changelog below.
Happy PyXing,
Jörg and André
[*] At the moment I have troubles enabling this wiki for all sourceforge users. I have already opened a ticket to get the issue resolved.
List of changes
===============
0.13 (2013/12/20):
- Requires at least Python 3.2
- The gallery has been moved to https://sourceforge.net/p/pyx/gallery/, which
is a wiki. Contributions are welcome.
- filelocator module:
- cygwin LaTeX with windows python patch (thanks to Sybren A. Stüvel)
- graph styles:
- fix numerical instability of line clippings
- remove errorbar range checks, as they fail on a reverse axis, which is
correct (reported by Néstor Espinoza)
- path module:
- fix internal name clash when generating a normpath from an empty path
(reported by Brendon Higgins)
- normpath module:
- several stability and precision improvements and bugfixes
- cusp removal at normpath construction (and getting rid of invalid
results for curvature, rotation, tangent, and trafo methods)
- remove curveradius methods as they are invalid for straigt paths
- deco module:
- apply text trafos to each character in curvedtext (reported by Hans L)
- properly apply all textattrs in curvedtext (for example colors or scalings)
- canvas module:
- layer method takes layer names above or below (instead of an instance),
also reorders layer accordingly when layer is already existing
- remove the before and after arguments of insert
- handle trafo and clip separately in constructor and write methods
- allow for one clipping instance only
- optimize graphics state stack usage
- dvi/dvifile module:
- change special handling for transformations and colors to use subcanvases
- apply transformations to markers
- trafos and styles are no longer canvasitems
- style module:
- fillrules are now fillstyles and handled within the PS/PDF context
- text module:
- new texenc setting
- major code reorganization and documentation revision (now using autodoc)
- font/afmfile module:
- parse more AFM files, also some with common inconsistencies (thanks to
Markus Schwienbacher for reporting these issues)
- color module:
- functiongradient has been split into functiongradient_rgb, etc. and
the function parameters are now passed directly
- lineargradient has been removed for factory functions lineargradient_rgb, etc.
that provide linear gradients between colors of a particular color model
- bitmap module:
- fix jpegimage for progressive jpeg files (thanks to Michael Schindler)
- pyxrc:
- use APPDATA environment variable to locate the pyxrc on windows
- tex, latex, kpsewhich, and locate executables are now customizable in the pyxrc
- on the package level:
- add pyxinfo to enable output of some useful information
- manual:
- PyX theme and various sphinx tweaks
--
by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
/ \ \ / ) wobsta@..., http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript and PDF figures
(_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/

On 7/14/2013 4:26 PM, André Wobst wrote:
> The surrogate escape error handling allows us the take
> Postscript code as ASCII, and if a file contains some non
> ASCII data (for example in comments or in strings, like
> a textual font name (we're not interested and just need to
> copy into the output)), it does not break. Another very
> helpful thing is, that you can use regular expressions
> both on strings and on bytes, either by using strings or
> bytes in the pattern to be matched.
Thank you for the interesting details.
Cheers,
Alan

Hi Alan,
Am 14.07.2013 um 22:01 schrieb Joerg Lehmann:
>> It would be great to have your thoughts on what you ran
>> into in the conversion process as true limits on the
>> practice of coding for Python 2.7 with an eye on using
>> the 2to3 tool to produce Python 3 code.
>
> I cannot really comment on this because we did not try this. In
> retrospect, I would expect it to be possible to obtain a Python 2.7
> based version that would allow an automatic porting to Python 3. But
> given our limited resources we realy wanted to minimize the effort - and
> thought it to be more important, in the long run, to have a Python 3
> based version of PyX at all.
Jörg is right, we don't have experience in that. But it might still be interesting to you to learn about some of the major troubles we faced when switching to Python 3:
First of all I guess it really depends on the code base and the problems you're solving. In PyX we had (amongst others) two major problems to fix. First there where cyclic imports, which magically happened to work in Python 2 but needed to be resolved in Python 3. Secondly, PyX does reads and writes files, and we cannot assume a certain encoding for this. For example, when reading a Type 1 font, it contains both Postscript code (which is mostly ASCII), but also binary data (glyph programs in a special, very compact binary language). In addition, part of the file is encoded and encrypted at first ... you need to do this using bytes. On the other hand, the postscript code we write is ASCII (with minor exceptions), and in order to write something like "0.123 4.567 moveto" into the output, you have to use strings (formatting a number as a "string" can be done by creating strings only, not for bytes). In the end we needed to decide where to decode and encode the bytes and the strings. We hope to have found a proper solution, which happens to be more explicit and thus does for the better in the end. I still like the more explicit handling of encoded and decoded data, and fortunately, there are some very nice features available in Python. The surrogate escape error handling allows us the take Postscript code as ASCII, and if a file contains some non ASCII data (for example in comments or in strings, like a textual font name (we're not interested and just need to copy into the output)), it does not break. Another very helpful thing is, that you can use regular expressions both on strings and on bytes, either by using strings or bytes in the pattern to be matched. All this helped us a lot.
We decided to convert the PyX code by 2to3 and then resolve all the issues one by one. It would have been *way* more work to fix the original code and improve the translation step. In the end of the day we still have a working solution for Python 2, but the future is Python 3 only. Given our limited resources, this is the best we can offer. For our users the message should be rather clear: PyX is alive! You can use PyX 0.12 on Python 2.7 down to Python 2.3. And if you want to go for Python 3 in the future, just join our new releases to come.
Best,
André
--
by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
/ \ \ / ) wobsta@..., http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript and PDF figures
(_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/

Alan,
On 14.07.13, Alan G Isaac wrote:
> On 7/14/2013 8:27 AM, Joerg Lehmann wrote:
> > Note that the next PyX release, which be plan to make in autumn, will
> > require at least Python 3.3! The alternative of supporting Python 2.7
> > and Python 3.3 in parallel is too cumbersome
>
>
> It would be great to have your thoughts on what you ran
> into in the conversion process as true limits on the
> practice of coding for Python 2.7 with an eye on using
> the 2to3 tool to produce Python 3 code.
I cannot really comment on this because we did not try this. In
retrospect, I would expect it to be possible to obtain a Python 2.7
based version that would allow an automatic porting to Python 3. But
given our limited resources we realy wanted to minimize the effort - and
thought it to be more important, in the long run, to have a Python 3
based version of PyX at all.
Cheers,
Jörg

On 7/14/2013 8:27 AM, Joerg Lehmann wrote:
> Note that the next PyX release, which be plan to make in autumn, will
> require at least Python 3.3! The alternative of supporting Python 2.7
> and Python 3.3 in parallel is too cumbersome
It would be great to have your thoughts on what you ran
into in the conversion process as true limits on the
practice of coding for Python 2.7 with an eye on using
the 2to3 tool to produce Python 3 code.
Thanks for PyX.
Alan

Thanks for your continued work on PyX! Much appreciated.
Cheers
David
On Jul 14, 2013 2:12 PM, "Joerg Lehmann" <joergl@...>
wrote:
> Dear PyX users,
>
> We just finished a couple of days of hacking on porting PyX to
> Python 3.3. The results of this effort are available in a separate
> branch, which you can checkout from
>
> svn://svn.code.sf.net/p/pyx/code/branches/py3k
>
> All of our tests and examples (with one small exception) run, but there
> will for sure be corner cases we have not covered. So if you're
> interested in a PyX version compatible with Python 3, give it a try and
> report problems and bugs.
>
> Note that the next PyX release, which be plan to make in autumn, will
> require at least Python 3.3! The alternative of supporting Python 2.7
> and Python 3.3 in parallel is too cumbersome for us and we believe
> anyway that it is about time to move forward. For all who cannot
> follow us (yet), the current 0.12.1 release of PyX should work well for
> the next years.
>
> Cheers,
>
> André and Jörg
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> PyX-devel mailing list
> PyX-devel@...
> https://lists.sourceforge.net/lists/listinfo/pyx-devel
>

Dear PyX users,
We just finished a couple of days of hacking on porting PyX to
Python 3.3. The results of this effort are available in a separate
branch, which you can checkout from
svn://svn.code.sf.net/p/pyx/code/branches/py3k
All of our tests and examples (with one small exception) run, but there
will for sure be corner cases we have not covered. So if you're
interested in a PyX version compatible with Python 3, give it a try and
report problems and bugs.
Note that the next PyX release, which be plan to make in autumn, will
require at least Python 3.3! The alternative of supporting Python 2.7
and Python 3.3 in parallel is too cumbersome for us and we believe
anyway that it is about time to move forward. For all who cannot
follow us (yet), the current 0.12.1 release of PyX should work well for
the next years.
Cheers,
André and Jörg