Follow up:
Neal and I've created a working patch, http://bugs.python.org/issue2477
We had to modify the parser API and add two functions. The two new
functions are slightly modified versions of existing functions. We
needed the flag argument to be an input/output variable (pointer)
instead of a i
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
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 talkin
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
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 writt
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 compatibil
> "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
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
> 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 work
> 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 tw
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
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 collec
-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 ge
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 curr
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 wi
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
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 perfe
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
>> 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 mos
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
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 libra
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
> 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, fo
On Mon, Mar 24, 2008 at 2:30 AM, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> I'm also curious about why Lennart thinks that this would only be relevant
> for large projects with lots of developers making regular releases.
No, you misunderstood, or I miswrote.
I think 2to3 is a procedure th
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
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
> 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 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
> 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
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 t
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__
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
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 b
> 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
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
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 i
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 enco
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
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.
39 matches
Mail list logo
