Re: Upstream build system, Sphinx autodoc, Python import path

[Florent Rougon]

Or use the following alternative, which lets the user browse the
documentation offline.

$ cat debian/patches/use-local-python3-doc-for-cross-references
>From f519a948173bfd4e9700a4ebc60bc54bf3455018 Mon Sep 17 00:00:00 2001
From: Florent Rougon <f.rou...@free.fr>
Date: Thu, 8 Oct 2015 13:28:35 -0700
Subject: Use local doc from python3-doc for cross references

Forwarded: not-needed
Last-Update: 2014-10-17

Patch-Name: use-local-python3-doc-for-cross-references
---
 doc/conf.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/conf.py b/doc/conf.py
index 728397d..18461c9 100644
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -35,7 +35,8 @@ extensions = [
 'sphinx.ext.viewcode',
 ]
 
-intersphinx_mapping = {'python': ('http://docs.python.org/3', None)}
+intersphinx_mapping = {'python': ('file:///usr/share/doc/python3/html',
+  '/usr/share/doc/python3/html/objects.inv')}
 
 # Add any paths that contain templates here, relative to this directory.
 templates_path = ['_templates']

Then put python3-doc in B-D and Suggests or so.

-- 
Florent

Re: Packaging pythonpy

[Florent Rougon]

Hello,

Dmitry Shachnev  wrote:

> Also, don't you think that /usr/bin/py is too generic? Maybe use
> /usr/bin/pythonpy or something similar instead? (It's easy to change that,
> as the linking is done by packaging rather than upstream buildsystem).

Especially considering that 'py' is the name chosen for the Python
Launcher for Windows by upstream Python developers :

  https://docs.python.org/3/using/windows.html#launcher

-- 
Florent

Re: Using 'pyvenv' or 'python3 -m venv' on unstable

[Florent Rougon]

Barry Warsaw  wrote:

> Since the fix for this is in python3.5, I've already provided a patch to
> Matthias.  I wanted to get his feedback about one particular point of the
> patch, but in the meantime I will attach the patch to that bug and reassign
> it.

Ah, glad to see a fix is on its way. Thank you for your prompt response,
Barry!

Regards

-- 
Florent

Using 'pyvenv' or 'python3 -m venv' on unstable

[Florent Rougon]

Hello,

Sorry for linking to my own bug report, but am I the only one affected
by bug #815864?
()

I'm wondering, because it seems pretty serious to me for people doing
Python development (or users wanting to install stuff with pip without
breaking their Debian system)... Actually, I am really concerned about
users here, because for developers the workaround I posted to the bug
report is easy enough.

Thanks

-- 
Florent

Re: Status of pythondialog in Debian

[Florent Rougon]

Tristan Seligmann mithra...@mithrandi.net wrote:

 Replaces: would not be appropriate or necessary since none of the
 files are overlapping; this is only necessary when two packages
 install files to the same location, and the one package must be
 installed over the other.

 Conflicts: would not be appropriate either, because both packages will
 work just fine when coinstalled, as you mention.

Yes, I know the technical conditions that justify Conflicts and
Replaces, I only proposed them as a means to get users' package managers
to automatically propose the upgrade from python-dialog to
python3-dialog...

 It is indeed possible for a removed package (obsolete package, as
 aptitude etc. call it) to stay on user systems forever, unless the
 user takes some action, but I think the packaging tools and
 documentation provide the necessary tools for users to address this.

[...]

 I
 expect they can just continue to use it, whereas if it is not being
 used then it doesn't really cause any harm by being installed on their
 system.

That is true, I also use aptitude and this feature works well. The main
downside to leaving obsolete packages is when they have security
problems, since they never get fixed in such a case. I am not aware of
any such problem for pythondialog, though, so I suppose we can live with
the current situation.

Thanks

-- 
Florent


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87fvef3q9e@frougon.crabdance.com

Re: Status of pythondialog in Debian

[Florent Rougon]

Hi,

Tristan Seligmann mithra...@mithrandi.net wrote:

 The package is already uploaded, right?

 It is, and processed through NEW. I uploaded -2 earlier today to fix
 #766041 and I believe it is now in unstable; it looks like the PTS
 isn't updated yet, though, possibly related to some problems with
 Debian infrastructure at the moment[1].

It is in unstable, thank you! I wonder if the new package
(python3-dialog) should not have Conflicts and Replaces with
python-dialog. Although I suppose both packages can be installed at the
same time, the current situation may leave the old, unmaintained
python-dialog forever installed on users' systems (until manual removal
or removal of Python 2...).

What do you think?

-- 
Florent


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/878uk8bl5m@frougon.crabdance.com

Status of pythondialog in Debian

[Florent Rougon]

Hello,

As the upstream maintainer of pythondialog, I feel a bit concerned about
its status in Debian, in particular about what is going to go into
jessie. In short, I'd rather see the package removed from Debian than
stay in the current status.

The package that is currently in unstable is terribly outdated (the
version dates from 2004), has a few bugs, supports neither Unicode
correctly nor Python 3, contrary to current upstream versions, not to
mention a bunch of features including help and extra button support,
easy pythondialog and backend version checking, autowidgetsize and the
new Sphinx-generated manual[1].

In case someone is interested, I've prepared a package of the latest
version for Python 3, using dh, dh_python3 and pybuild, following the
suggestions given on the Debian Python wiki (which is nice to have,
thank you!). It has been built on current sid and is available in the
following GPG-signed APT repository:

  deb http://people.via.ecp.fr/~flo/debian unstable main
  deb-src http://people.via.ecp.fr/~flo/debian unstable main

(along with other packages, don't upgrade blindly if you add the
repository to your sources.list)

Thanks

  [1] http://pythondialog.sourceforge.net/doc/

-- 
Florent


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/871tq62320@frougon.crabdance.com

Re: where is the Python tutorial?

[Florent Rougon]

Hi,

Tshepang Lekhonkhobe [EMAIL PROTECTED] wrote:

 Hi,
 I looked in the packages list and couldn't find the tutorial and was
 wondering if it was removed from the archive. Was it?

Doesn't look so. Install python2.5-doc and you'll have:

  /usr/share/doc/python2.5/html/tut/tut.html

python2.5-doc is in contrib, though (I don't know why).

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#335900: O: pyxmms -- Python interface to XMMS

[Florent Rougon]

Package: wnpp
Severity: normal

Hi,

I cannot work on PyXMMS anymore and am hereby orphaning it.


Description: Python interface to XMMS
 PyXMMS, packaged as python-xmms in Debian, is a set of Python bindings
 for the libxmms library. With PyXMMS, you can control an XMMS session
 and manage the XMMS main configuration file from a program written in
 the Python programming language.

Note: I am also upstream for PyXMMS. However, real bugs in it are quite
  rare as it seems, so there is no urgency to take that part over
  too.

-- 
Florent



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#335901: O: pyxmms-remote -- command-line interface to XMMS

[Florent Rougon]

Package: wnpp
Severity: normal

Hi,

I cannot work on PyXMMS-remote anymore and am hereby orphaning it.


Description: command-line interface to XMMS

 PyXMMS-remote allows you to control (or start, or terminate) an XMMS
 session from your shell's command-line (or a program, or a MIME-aware
 application, or whatever you want).

 There are a lot of queries and actions you can perform with PyXMMS-remote.
 Here are some examples: play or pause the current playlist entry, stop
 playing, jump to a playlist entry, add files or URLs to the playlist, get
 or set the volume, balance or the equalizer settings, toggle the main or
 playlist window, end the XMMS session...

 PyXMMS-remote is written in the Python programming language and uses
 (through PyXMMS, packaged as python-xmms in Debian), the xmms_remote_*
 functions provided by the libxmms library, hence its name.

Note: I am also upstream for PyXMMS-remote. As for PyXMMS, there is no
  real urgency to take that part over too.

  It would be nice to merge pyxmms-remote into the python-xmms
  binary package. The prerequisite to do this properly is to merge
  the two upstream packages; the only issue has to do with the
  build systems (PyXMMS uses distutils, whereas PyXMMS-remote uses
  autoconf and automake for automatic detection of programs like
  texi2html in order to build its documentation...).

-- 
Florent



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Python only packages and the new Python policy

[Florent Rougon]

Matthias Klose [EMAIL PROTECTED] wrote:

 look at the archives. python-central is a step forward, but it doesn't
 do anything to solve the forward conflicts for python applications and
 modules outside of sys.path.

OK, thanks for the explanation.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Python only packages and the new Python policy

[Florent Rougon]

Sergio Talens-Oliag [EMAIL PROTECTED] wrote:

   OK, then I'll take a look and see if I can write a script to support it, it
   seems quite simple but maybe I'm missing something...

Before you write another script, I think it would be useful to know why
python-central was not adopted. I have asked this question several times
here and never got an answer.

PS: I am not the author of python-central. No bias here.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Question about python policy

[Florent Rougon]

Fabian Fagerholm [EMAIL PROTECTED] wrote:

 It probably doesn't solve the case where you need a certain version of
 python to run build-time test cases and such. I guess it might have been
 a good idea, but since it didn't catch on, perhaps it was too
 complicated.

Build-time tests are run, well, at build-time. Nothing prevents you from
build-depending on every pythonX.Y you wish and doing every test that
might please you, regardless of whether you are using python-central.

Also, python-central was not complicated. For version 0.3 (0.4 was
released later but I didn't install it):

% wc -l /usr/sbin/register-python-package
182 /usr/sbin/register-python-package

It is a simple shell script.

-- 
Florent

Re: Question about python policy

[Florent Rougon]

Fabian Fagerholm [EMAIL PROTECTED] wrote:

 Hello all,

Hi,

 Firstly, it seems a little silly to duplicate all the code in both
 packages. I guess there's really no other way of doing it, since there

There used to be a tool called python-central (look in the mailing list
archives) that allowed packages to ship pure-python modules *once* under
/usr/lib/python/site-packages/ and have them automatically byte-compiled
for the various pythonX.Y installed (through Debian packages, of course,
your custom Python in /usr/local was not affected).

It was said that it would integrate the main python packages after the
initial proof of concept and testing period, but I never saw that
happen. I don't know why.

-- 
Florent

Re: installing stuff to sbin with distutils

[Florent Rougon]

Andreas Schuldei [EMAIL PROTECTED] wrote:

 how do i install python progs to /usr/sbin with pythons
 distutils?

 i manage to install stuff to bin, using scripts=[...] but not
 sbin

I am not a distutils guru (but I use it for a set of extension modules I
wrote), but it may well be that you cannot do this without subclassing
some distutils stuff.

The problem with this approach is that since the full distutils API was
never documented (so you cannot tell once you start subclassing things
whether you are relying on the API or an internal feature that could
change across releases), distutils cannot easily evolve towards
something more flexible because almost every change could break some
existing setup.py.

I sincerely hope a future release will break the old API for something
more flexible and thoroughly document the new one (it would have to be
parallel-installable with the old distutils). Or a new tool such as
SCons. Unfortunately, I haven't found the time yet to play with the
latter.

In order to help you solve your problem, I would suggest to:
  - learn enough about Python to feel comfortable (considering what you
wrote in [EMAIL PROTECTED]);
  - read the distutils documentation;
  - post on distutils-sig *at* python *dot* org if you still have
questions. It is *the* mailing list for distutils-related problems.

 i am not on this list, please cc me!

Done.

-- 
Florent

Re: Bug#230704: zope-testcase: SOFTWARE_HOME and INSTANCE_HOME can break install.

[Florent Rougon]

Donovan Baarda [EMAIL PROTECTED] wrote:

 G'day,

Hi,

 I was going to reply this is why many packages sanitize PATH in their
 scripts, but after checking through /var/lib/dpkg/info/* it seems they
 don't.

Indeed, Policy § 6.1 says they should not:

,
| Programs called from maintainer scripts should not normally have a path
| prepended to them. Before installation is started, the package
| management system checks to see if the programs ldconfig,
| start-stop-daemon, install-info, and update-rc.d can be found via the
| PATH environment variable. Those programs, and any other program that
| one would expect to be on the PATH, should thus be invoked without an
| absolute pathname. Maintainer scripts should also not reset the PATH,
| though they might choose to modify it by prepending or appending
| package-specific directories. These considerations really apply to all
| shell scripts.
`

 Does dpkg do any path sanitization itself? I'm kinda surprised if it
 doesn't, because as you say many things can break.

Well, that depends on what you call sanitization. As indicated by the
paragraph I quoted from Policy, dpkg will bomb if e.g. it doesn't find
start-stop-daemon in its PATH (I've seen it happen). However, it seems
it will not set PATH to a minimum, conservative value.

 Most security sensitive scripts do sanitize PATH before they execute,
 because PATH munging can be used as a security attack on scripts that don't.
 I would have thought dpkg would fall into that catagory.

Well, this can only be a problem when dpkg is run by root (otherwise
maintainer scripts are not run). If root's PATH has been mangled, the
attacker is already root (he could also mangle IFS and use whatever
technique makes setuid root shell scripts very risky [and therefore not
supported under Linux]).

I suppose the current Policy wants to allow the admin to use custom
executables (e.g., compiled with SSP) instead of the canonical Debian
ones if he so desires.

-- 
Florent

Re: Bug#221523: Causes build failures

[Florent Rougon]

Junichi Uekawa [EMAIL PROTECTED] wrote:

  The configure script is checking for 'python' script.
  
  What was the original reason for the 'recommends' instead of 
  'depends'? It's not really clear to me.
 
 some people wanted to be able to keep the default python version at
 version 2.2, but install packages from unstable, when the default
 versions were different in testing and unstable.

 I do doubt such special needs should be forced upon all of 
 us.

I am not the one who asked for this change, but I do find a somewhat
strange to have pythonX.Y depend on python (along with the inverse
dependency, which looks normal to me). I also think that a package
(build-)?depending on pythonX.Y specifically should call pythonX.Y
specifically.

If the configure script hard-codes the check for python (instead of
pythonX.Y), why not (in the present case, where X.Y is 2.3) build-depend
on python (= 2.3) and, if necessary, on python-dev (= 2.3) (cf.
http://people.debian.org/~joss/python/python-policy-draft.html/ap-build_dependencies.html)?

-- 
Florent

Re: Correct location of .py and .pyc files

[Florent Rougon]

Terry Hancock [EMAIL PROTECTED] wrote:

 Okay, I stand corrected.

 Three people including two I know are long-time developers
 have replied that .pyc/.pyo files are indeed architecture
 independent, and that changing this is unlikely:

Thanks for having asked the question on comp.lang.python. There has been
no reply since tuesday that contradicts their statements, so we are
probably safe letting the Policy allow packages to have .py{c,o} files
under /usr/share/package/.

For those interested, and for the archive, the aforementioned thread on
comp.lang.python can be read at:

http://groups.google.com/groups?threadm=LemdnTe8n5ZcsSeiRVn-jA%40august.net

-- 
Florent

Re: Correct location of .py and .pyc files

[Florent Rougon]

Terry Hancock [EMAIL PROTECTED] wrote:

 There was some discussion on comp.lang.python about 
 standardizing the bytecode awhile back, but the consensus
 was that the standardized part of Python is *the source code*.
 IMHO, they (/we) don't want to encourage obfuscated
 distributions of Python packages.  Python is a very open-source
 centric language and community.

Rest assured, nobody on this list so far has been trying to have Debian
ship bytecode-only Python modules. In fact, the current policy draft
clearly discourages distributing bytecode at all. .pyc and .pyo in most
Python packages in Debian are generated from the .py files at
installation time (postinst). They are not shipped in debs.

What we are trying to know is if we can safely store sets of
.{py,pyc,pyo} in /usr/share/package/ (in the case of .py files that are
architecture-independent, which is almost always true). This requires
the .pyc and .pyo to be architecture-independent because /usr/share is
supposed to be shareable between several machines (via NFS, usually)
whose architectures can differ.

-- 
Florent

Re: Correct location of .py and .pyc files

[Florent Rougon]

Matthias Klose [EMAIL PROTECTED] wrote:

 Joss proposal is already incorporated into the proposed policy found
 in the python package.

 There is no reason why /usr/share/module should be disallowed. I
 changed the proposed policy to:

[private modules can now go to /usr/share/package/]

Good, thanks.

-- 
Florent

Re: Correct location of .py and .pyc files

[Florent Rougon]

Marco Paganini [EMAIL PROTECTED] wrote:

 So, it would be /usr/share after all, as the .py modules in question are
 not architecture dependent, but *are* private.

 Correct?

Yes, I think you can go for /usr/share/package.

-- 
Florent

Re: linda ... Re: Correct location of .py and .pyc files

[Florent Rougon]

Cory Dodt [EMAIL PROTECTED] wrote:

 I note that applications written in python, such as my aap package, go into
 /usr/lib/package per the policy (section 3.1.1), but linda does not support
 this.  _all packages (most things written in Python) belong in /usr/share
 according to linda, but /usr/lib according to Python policy.

Well, that is the case if the modules need not be imported by a user
(private modules).

 Of course I obey the policy and not linda, but this is annoying.
 (Particularly so when linda itself is written in Python -- and doesn't obey
 the Python policy! :-)

Perhaps it will be time to file a bug when the Python policy is not a
draft any more...

 As long as I'm on my rant chair, is there any reason why packages with private
 modules need to be in /usr/lib?  Python upstream doesn't care about private
 modules one way or the other.

You're right. I fail to understand this requirement of the Python policy
draft.

,
| A program using /usr/bin/python as interpreter can come up with private
| python modules. These modules should be installed in
| /usr/lib/site-python/module, /usr/lib/pythonX.Y/site-packages/module
| (where pythonX.Y is the current python version) or /usr/lib/package. In
| the latter case, this directory should be added to sys.path at the
| program startup.
`

If sys.path is to be altered by the program to make use of the modules,
it could very well be altered to contain /usr/share/package instead of
/usr/lib/package, at no cost.

The only reason I can see to the current recommendation is for
consistency within Python-related packages, since about everything else
belongs to /usr/lib.

Thoughts?

-- 
Florent

Re: Correct location of .py and .pyc files

[Florent Rougon]

[Ugh, sorry for the double message, Marco]

Marco Paganini [EMAIL PROTECTED] wrote:

 Hi All,

Hi,

 I need to package a Python application that depends on multiple modules.
 I've been wondering about the correct location for the modules (both .py and
 .pyc files) in Debian. FHS states that architecture independent files should
 go under /usr/share/packagename, which was my first guess at where to put
 them.  However, I checked some packages in the repository and they put those
 files in /usr/lib/packagename (!?). What is, after all, the blessed location
 for these files?

I think the status quo is: /usr/share would be better, but is not
supported upstream, and no one yet has been willing to put the energy
needed to solve this problem. OTOH, there could be some weird cases
where a Python script would be intended for specific architectures
(hence would have to live in /usr/lib), but I think most of them would
be fairly pathological and could be changed to work in /usr/share.

As for now, the best location for these modules is
/usr/lib/pythonX.Y/site-packages. If the modules are
Python-version-independent, /usr/lib/python/site-packages (looks
deprecated; I have /usr/lib/site-python on my sid chroot instead) with
some mecanism like python-central would be better, but it seems to me it
isn't officially supported (there is no python-central package in
unstable and no register-python-package command in the
python(x.y)?(-dev)? packages), even though I used it on a package of
mine in my private apt repository, and found it to work well.

 Another point is what should be done with the compiled versions? Should the
 package installation scripts pre-compile the modules for faster execution?

Yes, but obviously you haven't read the Python policy draft
(/usr/share/doc/python/python-policy.txt.gz) nor Josselin's proposal at
http://people.debian.org/~joss/python/python-policy-draft.html/index.html.
They are must reads for anyone packaging something that is
python-related.

-- 
Florent

Re: python related packages out of date on m68k/mips/mipsel/arm/s390/powerpc

[Florent Rougon]

Hi,

Matthias Klose [EMAIL PROTECTED] wrote:

 missing builds:

[...]

   pyxmms (m68k, mips, not in testing)

The mips build hasn't happenned yet according to

  http://buildd.debian.org/build.php?arch=pkg=pyxmms

(pyxmms entered the archive recently). As for the problem on m68k, it
seems to me that the m68k buildd is not functioning properly:

,
| Automatic build of pyxmms_1.07-2 on crest by sbuild/m68k 1.170.4
| Build started at 20030928-1608
| **
| Checking available source versions...
| /usr/bin/apt-cache failed
| Giving back package pyxmms_1.07-2 after failure in fetch-src stage.
| **
| Finished at 20030928-1609
| Build needed 00:00:00, 0k disk space
`

I did not see this problem referenced on debian-m68k. Who should I
contact?

Thanks,

-- 
Florent

Re: python-gtk and python-gtk2 (and gnome packages), please comment

[Florent Rougon]

Hi,

Torsten Landschoff [EMAIL PROTECTED] wrote:

 that route. But - do we want to continue supporting the old gnome
 for sarge? Otherwise I would be for removing the old binding
 entirely before the next release. Just wondering if any dependent 
 package will be updated for the new gnome.

Of course I understand that the transition between python-gnome and
python-gnome2 is not an easy task, but Debian packages are probably not
the only thing to consider when it comes to removing the old binding.
People may have local apps that are not packaged and use the old
binding. However, they will presumably have time to speak up or port
their apps to gnome2 before sarge is released.

-- 
Florent

Re: Bytecode compilation

[Florent Rougon]

Dave Swegen [EMAIL PROTECTED] wrote:

 Surely the right way to handle this is using debconf in the main python
 packages, and subsequently any packages check this to see if python
 scripts should be compiled or not. Or have I missed anything?

You are talking about (compiling the .py in postinst | installing them
on the system without any compiled version); what was discussed
previously is (compiling the .py in postinst | including the .py, .pyc
and optionally .pyo in the .deb to avoid postinst byte-compilation).

With the latter, a debconf question would not be very helpful since the
.deb would have to ship the .pyc and/or .pyo anyway...

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bytecode compilation

[Florent Rougon]

Dave Swegen [EMAIL PROTECTED] wrote:

 Not having really followed the discussion, and being faaar too bone-idle
 to actually look it up in the archives, this is my view on it: Shipping
 pre-compiled really isn't an option, as the size increase would be
 unacceptable - not only from a debian archive/bandwidth POV, but also
 from an older machine/tiddy HD POV.

Agreed.

 install python2.2 + friends on a 486 with 16 meg'o'ram :) Maybe it would
 be an idea to provide a script that the user can run when he feels the
 machine isn't needed for anything else.

This doesn't sound like a bad idea, but the compiled file for python
packages are currently put in /usr (not /usr/local), along with their
corresponding .py. The packages create them in postinst and therefore
take the responsibility of deleting them when the package is removed. If
we let the admin create the compiled files in /usr with a script (à la
compileall.py), he might be surprised to see them removed with the
corresponding package. This can be argued about, however.

 Anyway, I've done my uninformed butting in, and will return to lurk
 mode.

Well, noone asked you to do so (that is, to return to lurk), AFAIK. My
answer wasn't meant to sound offensive.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Emacs in build-depends of python2.1

[Florent Rougon]

Florent Rougon [EMAIL PROTECTED] wrote:

 immutable, so repeatedly inserting/replacing small strings into the
 whole document's string, having all the includes recursively
 expanded would be quite bad) or something like (c)StringIO. But then
 you have to do heavy regexp matching on the whole doc, so your list
 idea is not so great any more. StringIO seems to do the trick,
 though.

Em, I posted a bit late, and made a little mistake here. StringIO does
not offer out of the box the possibility of *inserting* text in the
middle of your string (you can just overwrite, truncate, or append). But
the way it implements overwriting seems no less costly (and looks costly
to me in its Python 2.2 implementation) than what it would be after the
very little modification required to allow insertion.

cStringIO is different: overwriting is efficient (it is a memcpy).
Appending is as it can be (reasonable use of realloc). Anyway, cStringIO
does not show how to implement insertion efficiently (with the data
structures used, it would require realloc + memmove...).

So, what would be needed is something like an efficient Python
implementation of Emacs buffers basic properties if you want to stick to
py2texi.el's algorithm. I don't know if such a beast exists, but adding
this to the rest suggests that Milan Zamazal had some reasons for
choosing ELisp instead of Python to write his converter.

I'll mail him about this thread. He probably has valuable comments to do
on all this.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Emacs in build-depends of python2.1

[Florent Rougon]

Sean 'Shaleh' Perry [EMAIL PROTECTED] wrote:

 The problem is we now have a piece of a fairly common package using
 script(s) in a language few understand. So if you get hit by a bus
 someone WILL have to reverse engineer that script. This is the same

Well, I guess you mean py2texi.el's upstream maintainer instead of
you. Has someone had problems contacting him? Does his script often
break? The home page, http://www.zamazal.org/software/python/py2texi/,
is mentioned at the beginning of py2texi.el.

Now, for reverse engineer, I think you are a bit harsh. I read
py2texi.el from top to bottom, and I must say it's quite tidy for that
kind of hack (as I already said, converting (La)TeX to something else
without using the TeX engine is not an easy task if you want it a bit
robust). At least, it is not so ugly as mentioned in the Commentary.

Judging from the source not-so-bad-quality and (FWIW) from the
Copyright (C) 1998, 1999, 2001, 2002 Milan Zamazal, I think py2texi.el
is maintained. Am I wrong?

 I understand you not feeling the need is high to change now.  But bear these
 thoughts in mind in the future.

I understand the chroot issue. I won't accept arguments about Emacs or
py2texi.el sucking: py2texi.el looks well written for what it is
supposed to be; I think it performs a reasonably good job.

I thought a bit about a python implementation while reading it. It would
probably be a *bit* tedious, for the following reasons:
  - regexp lookup/insertion/edition capabilities in Emacs buffers are
heavily used. Efficient insertion in Python would probably mean
using lists to represent the document (because strings are
immutable, so repeatedly inserting/replacing small strings into the
whole document's string, having all the includes recursively
expanded would be quite bad) or something like (c)StringIO. But then
you have to do heavy regexp matching on the whole doc, so your list
idea is not so great any more. StringIO seems to do the trick,
though. Then you have to adapt carefully all the regexps and their
context of operation. Tedious, for sure.
  - py2texi.el uses /text properties/ to protect verbatim environments
from being fscked up by later processing. These would have to be
hacked into or emulated on top of StringIO, I think.
  - py2texi.el is not completely self-contained, but calls
texinfo-all-menus-update from the 50Mb-or-so Emacs package you've
happily installed. This is used to build the individual menus for
each node of the info file that has menu entries as well as for
updating all the nodes references to each other. Doesn't look very
hard conceptually, I think you just have to be able to parse the doc
and get its structure (the nodes have to refer to each other in the
info file as previous, next, up, etc.; yes, this leads to somewhat
redundant informations).

These are the implementation quirks. Now:
 - is it the only .el file used in the whole Python build?
 - are you sure the locally-and-not-installed python binary would be
   able to use modules like re, StringIO, etc.?
 - does someone actually use these info files, which are not supported
   by upstream and may be incorrect:

 The result code is ugly and need not contain complete information
  from Python manuals. I apologize for my ignorance, especially
  ignorance to python.sty

   due to the difficult nature of such a conversion?

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Emacs in build-depends of python2.1

[Florent Rougon]

Bastian Kleineidam [EMAIL PROTECTED] wrote:

 python2.1 (2.1.3-3) from sid
 py2texi.el is a generated file
 it is included in debian/patches/info-docs.dpatch
 the fixinfo.el is replaced by it, fixinfo.el is not run.

OK, py2texi and fixinfo have nothing in common.

 Dont know, seems that a lot of string-scanning and -replacing is done.

Yes, it converts a TeX file (the official Python documentation is
written in TeX) to texinfo. This is a hack (just have a look at the
Commentary at the top). Converting TeX to anything without acting at the
TeX driver level is always hard (and/or not robust) and hackish.

As it is only a build-dependency of python2.1, I can't see how it can be
a *real* problem. You don't build python packages on an embedded system.
Emacs packages are seldom updated (and you could put them on hold), so
bandwidth is not an excuse either.

Converting a hack to another hack with no strong reason nor fun is not
exactly what I dream of every night.

So, I am not sure that such a conversion would be worth the time spent.
If despite all of this you still want to tackle on this task and have
some ELisp questions (I think it should be OK with Python ;-), feel
free to ask me, but don't count on me to do this. Sorry.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Python and Emacs

[Florent Rougon]

Jonne Itkonen [EMAIL PROTECTED] wrote:

 And I again opposite to your opinion. If everybody uses tab to indent,
 then everyone can set his or her environment to render that tab with
 as many spaces as necessary, _or_ when using proportional fonts, as
 long an empty space as needed. I really don't understand why one would

That argument is not void, but using spaces only to indent ensures that
everyone writes code that has a reasonably depth (i.e., doesn't consist
of 1 function whose code is 200 columns wide). If someone is using tabs
with a length of e.g. 2 spaces, he will presumably write awful code as
I just described.

 like to use spaces to indent, but because of his or her inability to
 configure the programming environment used, or in the case of emacs, the
 impossibility of configuration (yes, I use vim and I'm happy with it,

Er, WTF are you talking about ?

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Python and Emacs

[Florent Rougon]

[EMAIL PROTECTED] (Jérôme Marant) wrote:

 Hi,

Hi,

   I'm sorry, this may be a bit off topic but I don't really know
   where I can post this question.

fr.comp.applications.emacs would be quite OK. ;-)

   I'm a bit annoyed with Emacs when editing Python programs because
   Emacs always replaces TABs with spaces ; this wouldn't bother me if
   Emacs was the only editor in the world. But when you share programs
   with others, it is better to have real TABs instead of spaces.
   I know about the C-q TAB but I don't want to use it every time
   I want automatic indentation. 

   Does anyone know how to achieve this?

I *hate* tabs in files, but here it goes...

(add-hook 'python-mode-hook #'(lambda ()
(local-set-key \t
   #'(lambda ()
   (interactive)
   (insert \t)

Please, don't spread this two much... nice Python code with ugly tabs
makes me depressed. :)

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]