headers
Greg Ewing | 1 Nov 2005 02:03
Picon
Picon
Favicon

Re: Divorcing str and unicode (no more implicit conversions).

François Pinard wrote:

> All development is done in house by French people.  All documentation, 
> external or internal, comments, identifier and function names, 
> everything is in French.

There's nothing stopping you from creating your own
Frenchified version of Python that lets you use all
the characters you want, for your own in-house use.

--

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg.ewing <at> canterbury.ac.nz	   +--------------------------------------+
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 1 comment |
headers
Greg Ewing | 1 Nov 2005 02:24
Picon
Picon
Favicon

Re: a different kind of reduce...

Martin Blais wrote:

> I'm always--literally every time-- looking for a more functional form,
> something that would be like this:
> 
>    # apply dirname() 3 times on its results, initializing with p
>    ... = repapply(dirname, 3, p)

Maybe ** should be defined for functions so that you
could do things like

   up3levels = dirname ** 3

--

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg.ewing <at> canterbury.ac.nz	   +--------------------------------------+
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 6 comments |
headers
François Pinard | 1 Nov 2005 03:51
Picon
Gravatar

Re: Divorcing str and unicode (no more implicit conversions).

[Greg Ewing]

>> All development is done in house by French people.  All documentation, 
>> external or internal, comments, identifier and function names, 
>> everything is in French.

> There's nothing stopping you from creating your own Frenchified 
> version of Python that lets you use all the characters you want, for 
> your own in-house use.

No doubt that we, you and me and everybody, could all have our own 
little version of Python.  :-)

To tell all the truth, the very topic of your suggestion has already 
been discussed in-house already, and the decision has been to stick to 
Python mainstream.  We could not justify to our administration that we 
start modifying our sources, in such a way that we ought to invest 
maintainance each time a new Python version appears, forever.

On the other hand, we may reasonably guess that many people in this 
world would love being as comfortable as possible using Python, while 
naming identifiers naturally.  It is not so unreasonable that we keep 
some _hope_ that Guido will soon choose to help us all, not only me.

--

-- 
François Pinard   http://pinard.progiciels-bpi.ca
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
(Continue reading)

Permalink | Reply | 0 comments |
headers
A.M. Kuchling | 1 Nov 2005 15:35
Picon
Gravatar

python-dev sprint at PyCon

Every PyCon has featured a python-dev sprint.  For the past few years,
hacking on the AST branch has been a tradition, but we'll have to come
up with something new for this year's conference (in Dallas Texas;
sprints will be Monday Feb. 27 through Thursday March 2).

According to Anthony's release plan, a first alpha of 2.5 would be
released in March, hence after PyCon and the sprints.  We should
discuss possible tasks for a python-dev sprint.  What could we do?

When the discussion is over, someone should update the wiki page with
whatever tasks are suggested:
<http://wiki.python.org/moin/PyCon2006/Sprints>.

--amk

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 6 comments |
headers
David Abrahams | 1 Nov 2005 17:25
Picon
Picon
Favicon
Gravatar

Re: [C++-sig] GCC version compatibility

Christoph Ludwig <cludwig <at> cdc.informatik.tu-darmstadt.de> writes:

> Hi,
>
> this is to continue a discussion started back in July by a posting by 
> Dave Abrahams <url:http://thread.gmane.org/gmane.comp.python.devel/69651>
> regarding the compiler (C vs. C++) used to compile python's main() and to link
> the executable.
>
>
> On Sat, Jul 16, 2005 at 12:13:58PM +0200, Christoph Ludwig wrote:
>> On Sun, Jul 10, 2005 at 07:41:06PM +0200, "Martin v. Löwis" wrote:
>> > Maybe. For Python 2.4, feel free to contribute a more complex test. For
>> > Python 2.5, I would prefer if the entire code around ccpython.cc was
>> > removed.
>> 
>> I submitted patch #1239112 that implements the test involving two TUs for
>> Python 2.4. I plan to work on a more comprehensive patch for Python 2.5 but
>> that will take some time.
>
>
> I finally had the spare time to look into this problem again and submitted
> patch #1324762. The proposed patch implements the following:

I just wanted to write to encourage some Python developers to look at
(and accept!) Christoph's patch.  This is really crucial for smooth
interoperability between C++ and Python.

Thank you,
Dave
(Continue reading)

Permalink | Reply | 1 comment |
headers
Phillip J. Eby | 1 Nov 2005 18:16
Gravatar

Re: python-dev sprint at PyCon

At 09:35 AM 11/1/2005 -0500, A.M. Kuchling wrote:
>Every PyCon has featured a python-dev sprint.  For the past few years,
>hacking on the AST branch has been a tradition, but we'll have to come
>up with something new for this year's conference (in Dallas Texas;
>sprints will be Monday Feb. 27 through Thursday March 2).
>
>According to Anthony's release plan, a first alpha of 2.5 would be
>released in March, hence after PyCon and the sprints.  We should
>discuss possible tasks for a python-dev sprint.  What could we do?

* PEP 343 implementation ('with:')
* PEP 308 implementation ('x if y else z')
* A bytes type

Or perhaps some of the things that have been waiting for the AST branch to 
be finished, i.e.:

* One of the "global variable speedup" PEPs
* Guido's instance variable speedup idea (LOAD_SELF_IVAR and 
STORE_SELF_IVAR, see 
http://mail.python.org/pipermail/python-dev/2002-February/019854.html)

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 3 comments |
headers
Guido van Rossum | 1 Nov 2005 18:22
Favicon

Re: python-dev sprint at PyCon

On 11/1/05, Phillip J. Eby <pje <at> telecommunity.com> wrote:
> At 09:35 AM 11/1/2005 -0500, A.M. Kuchling wrote:
> >Every PyCon has featured a python-dev sprint.  For the past few years,
> >hacking on the AST branch has been a tradition, but we'll have to come
> >up with something new for this year's conference (in Dallas Texas;
> >sprints will be Monday Feb. 27 through Thursday March 2).
> >
> >According to Anthony's release plan, a first alpha of 2.5 would be
> >released in March, hence after PyCon and the sprints.  We should
> >discuss possible tasks for a python-dev sprint.  What could we do?
>
> * PEP 343 implementation ('with:')
> * PEP 308 implementation ('x if y else z')
> * A bytes type

* PEP 328 - absolute/relative import
* PEP 341 - unifying try/except and try/finally (I believe this was
accepted; it's still marked Open in PEP 0)

> Or perhaps some of the things that have been waiting for the AST branch to
> be finished, i.e.:
>
> * One of the "global variable speedup" PEPs
> * Guido's instance variable speedup idea (LOAD_SELF_IVAR and
> STORE_SELF_IVAR, see
> http://mail.python.org/pipermail/python-dev/2002-February/019854.html)

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Neal Norwitz | 1 Nov 2005 18:59
Picon

Re: python-dev sprint at PyCon

On 11/1/05, Guido van Rossum <guido <at> python.org> wrote:
> On 11/1/05, Phillip J. Eby <pje <at> telecommunity.com> wrote:
> > At 09:35 AM 11/1/2005 -0500, A.M. Kuchling wrote:
> > >Every PyCon has featured a python-dev sprint.  For the past few years,
> > >hacking on the AST branch has been a tradition, but we'll have to come
> > >up with something new for this year's conference (in Dallas Texas;
> > >sprints will be Monday Feb. 27 through Thursday March 2).
> > >
> > >According to Anthony's release plan, a first alpha of 2.5 would be
> > >released in March, hence after PyCon and the sprints.  We should
> > >discuss possible tasks for a python-dev sprint.  What could we do?

I added the 4 PEPs mentioned and a few more ideas here:

  http://wiki.python.org/moin/PyCon2006/Sprints/PythonCore

n
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Phillip J. Eby | 1 Nov 2005 19:02
Gravatar

Re: python-dev sprint at PyCon

At 10:22 AM 11/1/2005 -0700, Guido van Rossum wrote:
>* PEP 328 - absolute/relative import

I assume that references to 2.4 in that PEP should be changed to 2.5, and 
so on.

It also appears to me that the PEP doesn't record the issue brought up by 
some people about the current absolute/relative ambiguity being useful for 
packaging purposes.  i.e., being able to nest third-party packages such 
that they end up seeing their dependencies, even though they're not 
installed at the "root" package level.

For example, I have a package that needs Python 2.4's version of pyexpat, 
and I need it to run in 2.3, but I can't really overwrite the 2.3 pyexpat, 
so I just build a backported pyexpat and drop it in the package, so that 
the code importing it just ends up with the right thing.

Of course, that specific example is okay since 2.3 isn't going to somehow 
grow absolute importing.  :)  But I think people brought up other examples 
besides that, it's just the one that I personally know I've done.

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 2 comments |
headers
Guido van Rossum | 1 Nov 2005 19:14
Favicon

Re: python-dev sprint at PyCon

On 11/1/05, Phillip J. Eby <pje <at> telecommunity.com> wrote:
> At 10:22 AM 11/1/2005 -0700, Guido van Rossum wrote:
> >* PEP 328 - absolute/relative import
>
> I assume that references to 2.4 in that PEP should be changed to 2.5, and
> so on.

For the part that hasn't been implemented yet, yes.

> It also appears to me that the PEP doesn't record the issue brought up by
> some people about the current absolute/relative ambiguity being useful for
> packaging purposes.  i.e., being able to nest third-party packages such
> that they end up seeing their dependencies, even though they're not
> installed at the "root" package level.
>
> For example, I have a package that needs Python 2.4's version of pyexpat,
> and I need it to run in 2.3, but I can't really overwrite the 2.3 pyexpat,
> so I just build a backported pyexpat and drop it in the package, so that
> the code importing it just ends up with the right thing.
>
> Of course, that specific example is okay since 2.3 isn't going to somehow
> grow absolute importing.  :)  But I think people brought up other examples
> besides that, it's just the one that I personally know I've done.

I guess this ought to be recorded. :-(

The issue has been beaten to death and my position remains firm:
rather than playing namespace games, consistent renaming is the right
thing to do here. This becomes a trivial source edit, which beats the
problems of debugging things when it doesn't work out as expected
(Continue reading)

Permalink | Reply | 1 comment |

Gmane