On 2008-03-24 09:22, Lennart Regebro wrote:
I think 2to3 is a procedure that will work well for library type
projects with a reasonably small set of developers that make regular
releases. There you can release both a python 2 and a python 3 version
of the module, for example.
...
So, in
Lennart Regebro wrote:
On Mon, Mar 24, 2008 at 12:14 AM, Martin v. Löwis [EMAIL PROTECTED] wrote:
You are still only seeing this as a case of libraries with a small
number of people developing them and making regular well defined
releases. That is not how the world I am talking about
On Mon, Mar 24, 2008 at 10:23 AM, Martin v. Löwis [EMAIL PROTECTED] wrote:
Yet, there you merely claim that such software exists (within larger
organizations, and within large communities like Zope and Plone),
without giving specific examples.
No I don't. Here is what I said:
In many other
On Mon, Mar 24, 2008 at 12:14 AM, Martin v. Löwis [EMAIL PROTECTED] wrote:
You are still only seeing this as a case of libraries with a small
number of people developing them and making regular well defined
releases. That is not how the world I am talking about looks.
Can you give me
On Mon, Mar 24, 2008 at 2:30 AM, Jean-Paul Calderone [EMAIL PROTECTED]
wrote:
On Mon, 24 Mar 2008 00:14:13 +0100, \Martin v. Löwis\
[EMAIL PROTECTED] wrote:
You are still only seeing this as a case of libraries with a small
number of people developing them and making regular well defined
Nuxeo CPS worked like this, but we can ignore them as that project is
all but dead will never move to Python 3 in any case. Zope/CMF/Plone
works like this.
I don't understand. AFAICT, Zope *is* a library, i.e. you have to run
setup.py for lots of packages. Do you not have to run setup.py, for,
On Mon, Mar 24, 2008 at 11:27 AM, Martin v. Löwis [EMAIL PROTECTED] wrote:
Nuxeo CPS worked like this, but we can ignore them as that project is
all but dead will never move to Python 3 in any case. Zope/CMF/Plone
works like this.
I don't understand. AFAICT, Zope *is* a library, i.e.
On Mon, Mar 24, 2008 at 11:29 AM, Thomas Wouters [EMAIL PROTECTED] wrote:
safe assumption to make. A simple preprocessor step involving 2to3 requires
no such knowledge.
As I understood it nobody has claimed 2to3 to be perfect either, but
that using 2to3 will also require you to test the code in
I don't understand. AFAICT, Zope *is* a library, i.e. you have to run
setup.py for lots of packages. Do you not have to run setup.py, for,
say, zope.interface, or zope.psycopgda?
No, Zope is not a library, it's an application. No, you typically do
not setup packages, although most (but
On Mon, Mar 24, 2008 at 12:26 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
http://svn.zope.org/zope.psycopgda/trunk/
Is that not the right source?
No, and yes. Many of the zope3 modules are installable as separate
modules. Zope 3 in general has been eggified. This is not however
how
On 24/03/2008, Lennart Regebro [EMAIL PROTECTED] wrote:
On Mon, Mar 24, 2008 at 11:29 AM, Thomas Wouters [EMAIL PROTECTED] wrote:
safe assumption to make. A simple preprocessor step involving 2to3 requires
no such knowledge.
As I understood it nobody has claimed 2to3 to be perfect either,
On Mon, Mar 24, 2008 at 1:03 PM, Paul Moore [EMAIL PROTECTED] wrote:
On 24/03/2008, Lennart Regebro [EMAIL PROTECTED] wrote:
On Mon, Mar 24, 2008 at 11:29 AM, Thomas Wouters [EMAIL PROTECTED] wrote:
safe assumption to make. A simple preprocessor step involving 2to3
requires
no such
On 24/03/2008, Lennart Regebro [EMAIL PROTECTED] wrote:
On Mon, Mar 24, 2008 at 1:03 PM, Paul Moore [EMAIL PROTECTED] wrote:
On 24/03/2008, Lennart Regebro [EMAIL PROTECTED] wrote:
As I understood it nobody has claimed 2to3 to be perfect either, but
that using 2to3 will also
On Mon, Mar 24, 2008 at 1:26 PM, Paul Moore [EMAIL PROTECTED] wrote:
Your statement using 2to3 will also require you to test the code in
both environments seemed to me to say that *not* having to use 2to3
would save you from doing this (as if this were either desirable, or
your current
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've missed most of this thread, but let me just put my two cents in.
I'd still like a future import to turn on unicode string literals (or
more accurately, treat unadorned string literals as unicodes). As
someone who is striving mightily to
Lennart Regebro wrote:
On Mon, Mar 24, 2008 at 12:26 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
I guess I could better understand with a very specific example.
You gave Django as a very specific example, and I looked at Django,
and it works just fine with 2to3. The Plone collective is not
On Mon, Mar 24, 2008 at 4:34 PM, Nick Coghlan [EMAIL PROTECTED] wrote:
No it isn't. A specific example would be I have environment X setup on
a machine. I go to website/SVN repository Y and retrieve source code Z
and start using it.
I have environment Plone setup on a machine. I also have
For example, if I'm using the (real source) py2.6 code, and I create a
patch that works for me, it is ready for testing and submission. If
I'm using the (generated) py3 code, then I first have to get a copy of
the (source) 2.6, figure out how I *would* have written it there, then
keep
Maybe it's not apparent to people that hasn't
developed in that kind of environment, and
I'm sorry I'm not able to make this clearer.
I think I understand the issue.
Some contributors will be running under 2.6, others will be running under 3.0.
Either the code forks, or one of them is
Barry Warsaw schrieb:
I've missed most of this thread, but let me just put my two cents in.
I'd still like a future import to turn on unicode string literals (or
more accurately, treat unadorned string literals as unicodes). As
someone who is striving mightily to get various libraries and
I have environment Plone setup on a machine. I also have several
products from the Plone collective which I use from the custom product
that contains the custom site code.
Thats it. It is a specific example. I can't get more specific than
that without you learning Plone.
Ok, let me try to
On Mon, Mar 24, 2008 at 8:30 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
Ah, I see. Your point was that with enough magic there is some way to
run 2to3 automatically. Sure, I never doubted that.
I don't see how that changes anything I said really. I still think the
forwards compatibility
Martin v. Löwis wrote:
For example, if I'm using the (real source) py2.6 code, and I create a
patch that works for me, it is ready for testing and submission. If
I'm using the (generated) py3 code, then I first have to get a copy of
the (source) 2.6, figure out how I *would* have written it
Eric Smith wrote:
It's not implementable because the work has to occur in ast.c (see
Py_UnicodeFlag). It can't occur later, because you need to skip the
encoding being done in parsestr(). But the __future__ import can only
be interpreted after the AST is built, at which time the encoding has
On Sun, Mar 23, 2008 at 8:37 AM, Lennart Regebro [EMAIL PROTECTED] wrote:
Eric Smith wrote:
It's not implementable because the work has to occur in ast.c (see
Py_UnicodeFlag). It can't occur later, because you need to skip the
encoding being done in parsestr(). But the __future__ import
On Sun, Mar 23, 2008 at 2:13 PM, Thomas Wouters [EMAIL PROTECTED] wrote:
That was always the assumption, and also the idea for 2.6 and 2.7. I would
much rather 3.0 isn't widely accepted for a few years longer than that it be
cluttered with backward compatibility crap, and even rather than that
So the question is rather: Do you want to disk a community split, or
add forwards compatibility?
I don't think the risk is big. As far as people start saying I will
only support Python 3, or saying I will not support Python 3 - that's
fine.
In the former case, people can still continue to use
On Sun, Mar 23, 2008 at 10:45 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
So the question is rather: Do you want to disk a community split, or
add forwards compatibility?
I don't think the risk is big. As far as people start saying I will
only support Python 3, or saying I will not
You are still only seeing this as a case of libraries with a small
number of people developing them and making regular well defined
releases. That is not how the world I am talking about looks.
Can you give me examples of such software? Are you perhaps talking
about closed source software?
On Mon, 24 Mar 2008 00:14:13 +0100, \Martin v. Löwis\ [EMAIL PROTECTED]
wrote:
You are still only seeing this as a case of libraries with a small
number of people developing them and making regular well defined
releases. That is not how the world I am talking about looks.
Can you give me
Eric Smith wrote:
This proposal is to add from __future__ import
unicode_string_literals, which would make all string literals in the
importing module into unicode objects in 2.6.
I'm going to withdraw this, for 2 reasons.
1) The more I think about it, the less sense it makes.
2) Without
Eric Smith schrieb:
It's not implementable because the work has to occur in ast.c (see
Py_UnicodeFlag). It can't occur later, because you need to skip the
encoding being done in parsestr(). But the __future__ import can only
be interpreted after the AST is built, at which time the
Christian Heimes wrote:
Eric Smith schrieb:
It's not implementable because the work has to occur in ast.c (see
Py_UnicodeFlag). It can't occur later, because you need to skip the
encoding being done in parsestr(). But the __future__ import can only
be interpreted after the AST is built,
On Fri, Mar 21, 2008 at 11:06 AM, Eric Smith
[EMAIL PROTECTED] wrote:
Christian Heimes wrote:
Eric Smith schrieb:
It's not implementable because the work has to occur in ast.c (see
Py_UnicodeFlag). It can't occur later, because you need to skip the
encoding being done in
It's not implementable because the work has to occur in ast.c (see
Py_UnicodeFlag). It can't occur later, because you need to skip the
encoding being done in parsestr(). But the __future__ import can only
be interpreted after the AST is built, at which time the encoding has
already been
On 2008-03-21 22:32, Martin v. Löwis wrote:
It's not implementable because the work has to occur in ast.c (see
Py_UnicodeFlag). It can't occur later, because you need to skip the
encoding being done in parsestr(). But the __future__ import can only
be interpreted after the AST is built,
Following up on a python-3000 discussion about making porting from 2.6
to 3.0 easier. Martin suggested making this its own thread.
This proposal is to add from __future__ import
unicode_string_literals, which would make all string literals in the
importing module into unicode objects in 2.6.
37 matches
Mail list logo
