On Jul 13, 2010, at 10:43 AM, Asheesh Laroia wrote:
On Mon, 12 Jul 2010, Barry Warsaw wrote:
We had a report in upstream Python from a user who was trying to find
information about dist-packages. He did a Google search and didn't
find any definitive official explanation of this Debuntuism
We had a report in upstream Python from a user who was trying to find
information about dist-packages. He did a Google search and didn't find any
definitive official explanation of this Debuntuism. His suggestion was to add
a note to the official Python documentation, but that doesn't seem quite
On Jun 30, 2010, at 04:58 PM, Scott Kitterman wrote:
On Wednesday, June 30, 2010 04:51:38 pm Piotr Ożarowski wrote:
[Scott Kitterman, 2010-06-30]
For Python3:
1. A new field called X-Python3-Version: It does not support lists of
versions (e.g. (3.0, 3.1)). Acceptable values are a
On Jun 30, 2010, at 06:02 PM, Scott Kitterman wrote:
I don't want to break a lot of packages. Both implicit and explicit
all are widely used in Python packages. I think we have more freedom
to do the right thing for Python 3.
That's what I expected (i.e. cleans up a wart). +1
Thanks,
-Barry
For those of you not closely following python-dev, I've made a proposal for
versioned .so file naming for Python 3.2. It would allow us to place
extension module .so files for different Python versions (or really, Python
builds, e.g. 3.2/3.3, debug, UCS2/4, etc) in the same directory without
On Jun 24, 2010, at 11:58 PM, Jakub Wilk wrote:
What's the point in making distutils produce versioned .so? Such a change is
going to break lots of packages for exactly zero benefit:
Why so?
helper tools will need to do unversioned-versioned renames anyway, in order
to handle non-distutils
On Jun 20, 2010, at 04:28 PM, Scott Kitterman wrote:
I'm going to declare rough consensus around this approach and I'll have a
Python policy patch for review shortly.
I haven't had time to read this through yet, but I recently posted some
information related to Python on Debian and Ubuntu and
On Jun 21, 2010, at 06:30 PM, Scott Kitterman wrote:
I think most people install Python modules and extensions as dependencies of
applications they care to use. For Python developers that actually care
about such things, I think it's better that the just install both manually.
I agree about the
On Jun 22, 2010, at 12:13 AM, Piotr Ożarowski wrote:
[Barry Warsaw, 2010-06-21]
I haven't had time to read this through yet, but I recently posted some
information related to Python on Debian and Ubuntu and requested off-list
feedback. One of the more interesting messages I got was from
On Jun 18, 2010, at 03:45 PM, Piotr Ożarowski wrote:
[Luca Falavigna, 2010-06-18]
Il 18/06/2010 14.37, Scott Kitterman ha scritto:
XS-Python-Version: = 2.x
XS-Python3-Version: = 3.x
+1 (but with XB-Python-Version, i.e. no XB-Python3-Version)
Agreed. This aligns with the decision to
On Jun 18, 2010, at 04:30 PM, Julian Andres Klode wrote:
Another reason against this would be that it will look stupid once there
is no Python 2 anymore.
If it's one thing I've learned in all my years is that it's virtually
impossible not to look stupid 10 or 15 years later wink. I mean, have
On Jun 05, 2010, at 10:43 PM, Scott Kitterman wrote:
I filed a bug on bzr and it was fixed, though I don't know if it's released
yet or not. It was a corner case anyway so probably not a show stopper.
-Barry
signature.asc
Description: PGP signature
On May 29, 2010, at 11:18 PM, Bernd Zeimetz wrote:
On 05/28/2010 09:10 PM, Barry Warsaw wrote:
I realize that I've never formally requested addition to DPMT and PAPT.
Since
I maintain both upstream Python applications and modules, and since I'm on
the
core Python development team, I would
On May 28, 2010, at 04:35 PM, Jakub Wilk wrote:
* Barry Warsaw ba...@python.org, 2010-05-28, 10:21:
Jakub Wilk found the problem and prepared a list of packages affected:
http://people.debian.org/~jwilk/tmp/string-exceptions.ddlist
anyone volunteers to check them and report bugs?
(string
On May 28, 2010, at 01:24 PM, Piotr Ożarowski wrote:
[Barry Warsaw, 2010-05-28]
What I mean is, let's say we have to change something in a helper tool. We
want that change to happen at least also in Debian, if not first in Debian,
but because of our different release cycles, where would we
On May 28, 2010, at 07:21 PM, Jakub Wilk wrote:
Let's try what says grep on the Lucid's vesrion:
$ grep -Er raise\s+[\'] --include='*.py' bzr-2.1.1/
bzr-2.1.1/bzrlib/bundle/bundle_data.py:raise 'Value %r has
no colon' % info_item
bzr-2.1.1/bzrlib/tests/test_hooks.py:
I realize that I've never formally requested addition to DPMT and PAPT. Since
I maintain both upstream Python applications and modules, and since I'm on the
core Python development team, I would like to request admission to both Debian
teams. I'll start off by maintaining the various packages
On May 23, 2010, at 03:58 PM, Piotr Ożarowski wrote:
[Barry Warsaw, 2010-05-22]
So, how can we make sure that doesn't happen? IOW, how can I begin to
experiment with a Python 2.7 transition in a way that will benefit Debian as
well?'
Simply avoid doing transitions with significant changes
On May 16, 2010, at 02:21 PM, Piotr Ożarowski wrote:
What's missing to have full PEP3147 support?
* PEP 384 implementation (will allow us to share (most?) .so files)
I have a concern about this.
While I understand the motivation, I'm not sure implementing PEP 384 will have
any practical help in
On May 10, 2010, at 01:23 PM, Piotr Ożarowski wrote:
Why I think derivatives should not add new versions?
* because it's mostly chasing numbers - I'm pretty sure there are not
more than 10 packages that require Python = 2.6 and are not easy to
port to 2.5 in Ubuntu 10.04,
* because when you
On May 18, 2010, at 11:42 PM, anatoly techtonik wrote:
On Mon, May 10, 2010 at 2:23 PM, Piotr Ożarowski pi...@debian.org wrote:
Why I think derivatives should not add new versions?
* because it's mostly chasing numbers - I'm pretty sure there are not
more than 10 packages that require Python
I know I'm a broken record on this, and I (currently ;) have very little power
to do much about it other than *talk*, but...
On May 11, 2010, at 10:18 PM, Piotr Ożarowski wrote:
Why am I mentioning Ubuntu at all? Because all decisions about Python in
Debian are made there.
My own personal hope
On May 26, 2010, at 05:43 PM, Scott Kitterman wrote:
I think it makes sense for them to be kept separate at runtime.
This would mean separate python-foo and python3-foo binaries where both are
supported from the same source.
It would mean that binaries should not depend on both Python 2 and
On May 19, 2010, at 01:05 PM, Piotr Ożarowski wrote:
[Piotr Ożarowski, 2010-05-19]
we have experimental for aggressive changes...
unless you wanted to use Debian experimental, debian-python mailing list
and our help since the beginning and later sync it in Ubuntu (if you
decide it's ready and
be patient with me asking lots of dumb
questions. You can always tell me to RTFWP (RTF Web Page :).
On Tue, May 18, 2010 at 23:50, Barry Warsaw ba...@python.org wrote:
On May 18, 2010, at 02:30 PM, Scott Kitterman wrote:
We did make the assumption that by the time 2.7 is released Debian
Now that the Ubuntu Developer Summit is over, I'll be able to catch up on this
mailing list. However I wanted to take a moment to summarize the session we
had on Python versions for Maverick Meerkat (Ubuntu 10.10).
First, let me thank the DPL Stefano Zacchiroli for coming to UDS-M and
On May 18, 2010, at 10:52 AM, Kumar Appaiah wrote:
On Tue, May 18, 2010 at 11:38:23AM -0400, Barry Warsaw wrote:
First, let me thank the DPL Stefano Zacchiroli for coming to UDS-M and
representing the Debian community. It was really great meeting and having a
chance to talk with him. He's
On May 18, 2010, at 02:30 PM, Scott Kitterman wrote:
As is usual for discussions involving more than one person, we didn't all
leave the room with quite the same understanding. I think 2.7 as default is a
stretch goal at most. We want 2.7 as a supported version, but I didn't sense
a lot of
On May 08, 2010, at 10:55 AM, Piotr Ożarowski wrote:
The only reason I got from Ubuntu for doing transitions outside Debian
and allowing Debian to do it later (and forcing us to fix after them)
is... because you are slow. All technical reasons (like relative
imports in 2.6) were easy to prove
On May 05, 2010, at 11:54 AM, Piotr Ożarowski wrote:
What do you think about backporting it to Python 3.1 in Squeeze?
I think it's worth to backport it to python3.1 even if it will be the
only 3.X version supported in Squeeze as this should ease the transition
to python3.2 in Squeeze+1 and give
On May 04, 2010, at 04:20 PM, Richard Darst wrote:
I was looking through the talks submitted to DebConf, and noticed
there weren't very many Python related talks. Given the amount there
is to discuss related to Python in Debian, it would be great to see
some more submissions.
I wish I could
On Apr 27, 2010, at 10:01 AM, Nicolas Chauvat wrote:
[discussion started at
http://lists.debian.org/debian-python/2010/04/msg00046
should we continue or trim some of the cc'ed lists ?]
Is there a better place to discuss Python packaging issues that are of
interest to both Debian and Ubuntu? Are
On Apr 27, 2010, at 06:32 PM, Toni Mueller wrote:
I'm not sure about how much the changes in the infrastructure would be
an obstacle, or prevent this from happening (didn't check yet), and I
don'tknow how the group thinks about the political and/or personal
issues involved, either. What I do see
On Apr 20, 2010, at 04:57 PM, Scott Kitterman wrote:
I think it is difficult to know for sure what the future will hold. If the
backport is not technically complex, I think a backport with the default to
off would be a nice tool in the box is things go differently than we plan.
Other than the
On Apr 21, 2010, at 12:01 AM, Piotr Ożarowski wrote:
2to3 is not reliable, at least not for now.
I agree that there's no way we can just enable it by default. Too many
upstream packages need modifications to work in Python 3. However, for those
that are Python 3-ready, it's a useful tool. The
On Apr 21, 2010, at 12:03 AM, Piotr Ożarowski wrote:
[Barry Warsaw, 2010-04-20]
If 10.10 includes
only Python 2.7, then sure, we'll only back port to that version.
why do you want to backport it to 2.X for a single python2.x package?
It would only make sense if we wanted to share source
On Apr 21, 2010, at 02:43 PM, Piotr Ożarowski wrote:
Moreover AFAICT 2.7 is the most compatible-with-the-previous-version
Python release in the last 16 years
did you hear about relative imports in 2.7? (enormous transition for us)
Are you sure about this? Despite what PEP 328 says, I'm not
On Apr 21, 2010, at 08:33 PM, Piotr Ożarowski wrote:
[Piotr Ożarowski, 2010-04-21]
should be easy to check (by creating 2 simple .py files and running
them using python2.7 from experimental). I'll check it later tonight.
It's not enabled (fails only if I import absolute_import from
__future__)
On Apr 20, 2010, at 10:14 AM, Piotr Ożarowski wrote:
[Omer Zak, 2010-04-20]
My take of the situation:
Yes, please backport PEP 3147 to at least Python 2.7.
The rationale: we'll need to support both Python 2.x and Python 3.x for
several years, and it will be nice if the same library package
Apologies for the cross-post, but I want to make sure that everyone who cares
about Python on both Debian and Ubuntu gets a chance to weigh in.
On Friday, Guido approved and I landed the implementation of PEP 3147 on the
py3k trunk (what will be Python 3.2). This allows multiple versions of
On Apr 14, 2010, at 04:14 PM, Jakub Wilk wrote:
python-central seems to have some (at least rudimentary) support for
3.X.
I was told that python-support does not support 3.X (see bug #573560).
I am hoping that none will be necessary. PEP 3147 is very close to acceptance
and merging into the
On Apr 14, 2010, at 07:01 PM, Josselin Mouette wrote:
Le mercredi 14 avril 2010 à 10:29 -0400, Barry Warsaw a écrit :
I was told that python-support does not support 3.X (see bug #573560).
I am hoping that none will be necessary. PEP 3147 is very close to
acceptance
and merging
On Apr 14, 2010, at 09:26 PM, Piotr Ożarowski wrote:
[4] almost ready in pycompile, still waiting for
http://www.python.org/dev/peps/pep-0382/ (and 3147), though
PEPs 382 and 384 are next on my list.
-Barry
signature.asc
Description: PGP signature
On Mar 29, 2010, at 08:39 AM, C.J. Adams-Collier wrote:
I'm pretty new to packaging python. Apologies in advance if I'm making
bad assumptions. I recently packaged IronPython. It can optionally use
the libraries from the standard python library. It doesn't seem that
these libs are distributed
On Mar 15, 2010, at 08:47 PM, Jonathan Wiltshire wrote:
It occurs to me that there's very little guarantee of a stable API in
Python modules - less so in C modules, because upstream tends to be more
aware that this is a library, but in pure Python modules.
There is nothing other than convention
On Feb 14, 2010, at 09:18 AM, Paul Wise wrote:
Unless they can be convinced to undo that, python-json is clearly at a
Very unlikely that will happen.
-Barry
signature.asc
Description: PGP signature
On Jan 31, 2010, at 08:53 PM, Umang wrote:
But I'll never find my data files in sys.prefix +
path_i_asked_distutils_to_install_to. So what according to you, is the
right way to go about distributing? This situation is definitely not ideal.
The Pythonic way (IMO) is to use pkg_resources:
On Jan 29, 2010, at 11:42 PM, Ben Finney wrote:
Umang umang...@gmail.com writes:
What I am talking about is the upstream tarball that, when extracted
into a directory, can run without being installed using distutils.
If the package is designed to be installed by distutils, it seems obtuse
On Jan 30, 2010, at 4:56 PM, Josselin Mouette wrote:
Maybe you don’t understand it is a plague, because you are not trying to
package the things you write with __file__ for a distribution. The
location of module files on the system should be a hidden implementation
detail. Because of
On Jan 31, 2010, at 01:09 AM, Josselin Mouette wrote:
pkg_resources allows to do things correctly, but I find it too complex;
it’s no wonder why people still hack stuff around __file__: it’s much
simpler.
I think it's not so much that pkg_resources is complex, but that it has a lot
of extra API
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 11, 2008, at 6:36 PM, Floris Bruynooghe wrote:
On Tue, Mar 11, 2008 at 09:45:21AM -0400, Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 11, 2008, at 3:43 AM, Matthias Klose wrote:
Currently Debian's python has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 11, 2008, at 3:58 AM, Wichert Akkerman wrote:
- add another path (e.g. /usr/local/python/lib2.x/site-packages),
and remove the /usr/local/lib/python2.x/site-packages path after
the next release. Does provide an upgrade path, but doesn't
701 - 752 of 752 matches
Mail list logo
