Re: [Python-Dev] Any PEP about 2.6 -> 3000 code transition?
On Sun, May 25, 2008 at 6:25 AM, Jesus Cea <[EMAIL PROTECTED]> wrote: > Since I need to port bsddb3 to py3k, what I need to know?. Is any > *updated* document out there?. No, but there is a not yet complete, but quite updated set of examples. http://code.google.com/p/python-incompatibility/ This is a collection of code snippets that will show code that does work under 2.x but not under 3.x, and the 3.x way of doing it (as well as a way that works under both 2.6 and 3.0, in applicable cases). There is no tests for changes in the C-API, if you (or somebody else) would like to add that (or any other tests) that would be very appreciated! -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371 Discussion (pyProcessing Module)
>> If the 3.0 API of a module is going to involve breakage which >> requires authors to update their applications wouldn't this be a good >> time to PEP-8-ify the module? (Not suggesting that threading would >> fall into this category.) Nick> Updating application code to deal with a module name change is Nick> easy - just use an "import x as y" statement. Catching the Nick> ImportError for the 3.0 name and falling back to the 2.6 name (or Nick> vice-versa) even makes it possible to support both names fairly Nick> easily. Nick> Changing the names of actual objects within the modules is tougher Nick> though - there are many more ways to access those. I think you misunderstood what I wrote. Suppose you decided that the API for the threading modules needs significant rework, changes which will break much, if not all current usage. I'm only suggesting that if you decide the API change is worthwhile that you take the opportunity to make the class, method and data names PEP8-compliant. I'm not talking about gratuitous change to the identifier names, but situations where the user is going to have to rework their code anyway. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371 Discussion (pyProcessing Module)
On Sat, May 31, 2008 at 6:31 PM, r.m.oudkerk <[EMAIL PROTECTED]> wrote: > On 31/05/2008, Paul Moore <[EMAIL PROTECTED]> wrote: >> 2008/5/30 Farshid Lashkari <[EMAIL PROTECTED]>: >>> I'm not sure if there will be any side affects to modifying >>> sys.executable though. Should this be the official way of supporting >>> embedded interpreters or should there be a >>> multiprocessing.setExecutable() method? >> >> +1 for setExecutable (I'd prefer set_executable, to be PEP 8 >> compliant). Make it explicit, rather than fiddling with stuff in sys >> manually. > > That is easy to do. Also note - someone just pointed out to me that the executable manipulation as-is breaks when you execute things within IDLE. I'll add all of this to the PEP. -jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371 Discussion (pyProcessing Module)
[EMAIL PROTECTED] wrote: Nick> We fixed the module names that used mixed case - the amount of Nick> work that turned out to be involved in just doing that much for Nick> PEP 3108 makes me shudder at the thought of trying to fix all of Nick> the standard library APIs that currently don't follow the style Nick> guide... If the 3.0 API of a module is going to involve breakage which requires authors to update their applications wouldn't this be a good time to PEP-8-ify the module? (Not suggesting that threading would fall into this category.) Updating application code to deal with a module name change is easy - just use an "import x as y" statement. Catching the ImportError for the 3.0 name and falling back to the 2.6 name (or vice-versa) even makes it possible to support both names fairly easily. Changing the names of actual objects within the modules is tougher though - there are many more ways to access those. Cheers, Nick -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mini-Pep: An Empty String ABC
Guido van Rossum wrote: This PEP is incomplete without specifying exactly which built-in and stdlib types should be registered as String instances. I'm also confused -- the motivation seems mostly "so that you can skip iterating over it when flattening a nested sequence" but earlier you rejected my "Atomic" proposal, saying "Earlier in the thread it was made clear that that atomicity is not an intrinsic property of a type; instead it varies across applications [...]". Isn't this String proposal just that by another name? Finally, I fully expect lots of code writing isinstance(x, String) and making many more assumptions than promised by the String ABC. For example that s[0] has the same type as s (not true for bytes). Or that it is hashable (the Sequence class doesn't define __hash__). Or that s1+s2 will work (not in the Sequence class either). And many more. I think the PEP also needs to explain why having multiple small one-off string ABCs is a bad thing. The whole point of providing a standard ABC mechanism is to enable exactly that: allowing a library to say "Here is my concept of what a string class needs to provide - register with this ABC to tell me that I can use your class without blowing up unexpectedly". The library can then preregister a bunch of other classes it knows about that do the right thing (such as the builtin str type) That is, to write a flatten operation with ABC's you might do something along the lines of: from abc import ABCMeta class Atomic(metaclass=ABCMeta): """ABC for iterables that the flatten function will not expand""" Atomic.register(str) # Consider builtin strings to be atomic def flatten(obj, atomic=Atomic): itr = None if not isinstance(obj, atomic): try: itr = iter(obj) except (TypeError, AttributeError): pass if itr is not None: for item in itr: for x in flatten(item): yield x else: yield obj Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mini-Pep: An Empty String ABC
From: "Guido van Rossum" <[EMAIL PROTECTED]> All this makes me lean towards a rejection of this proposal -- it seems worse than no proposal at all. It could perhaps be rescued by adding some small set of defined operations. By subclassing Sequence, we get index() and count() mixins for free. We can also add other mixin freebies like __hash__(), __eq__(), __ne__(), endswith(), startswith(), find(), rfind(), and rindex(). It's tempting to add center, lust, rjust, and zfill, but those require some sort of constructor that accepts an iterable argument. As important as what is included are the methods intentionally left out. I'm trying to avoid insisting on abstractmethods like encode(), split(), join(), and other methods that place an undue burden on a class being registered as a String. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mini-Pep: An Empty String ABC
Please try to find the largest set of methods that you're comfortable with. __add__ comes to mind. Note that if you add __hash__, this rules out bytearray -- is that your intention? __hash__ is intentionally not part of the "read-only" ABCs because read-only doesn't mean immutable. Also, (again) please list which built-in types you want to register. On Mon, Jun 2, 2008 at 1:54 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > From: "Guido van Rossum" <[EMAIL PROTECTED]> >> >> All this makes me lean towards a rejection of this proposal -- it >> seems worse than no proposal at all. It could perhaps be rescued by >> adding some small set of defined operations. > > By subclassing Sequence, we get index() and count() mixins for free. > > We can also add other mixin freebies like __hash__(), __eq__(), __ne__(), > endswith(), startswith(), find(), rfind(), and rindex(). > > It's tempting to add center, lust, rjust, and zfill, but those require some > sort of constructor that accepts an iterable argument. > > As important as what is included are the methods intentionally left out. > I'm trying to avoid insisting on abstractmethods like encode(), split(), > join(), and other methods that place an undue burden on a class being > registered as a String. > > > Raymond > > > > > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On 2008-06-02 01:30, Gregory P. Smith wrote:
On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
Sorry, I probably wasn't clear enough:
Why can't we have both PyString *and* PyBytes exposed as C
APIs (ie. visible in code and in the linker) in 2.x, with one redirecting
to the other ?
* Why should the 2.x code base turn to hacks, just because 3.x wants
to restructure itself ?
With the better explanation from Greg of what the checked in approach
achieves (i.e. preserving exact ABI compatibility for PyString_*, while
allowing PyBytes_* to be used at the source code level), I don't see what
has been done as being any more of a hack than the possibly more common
"#define " (which *would* break binary compatibility).
The only things that I think would tidy it up further would be to:
- include an explanation of the approach and its effects on API and ABI
backward and forward compatibility within 2.x and between 2.x and 3.x in
stringobject.h
- expose the PyBytes_* functions to the linker in 2.6 as well as 3.0
Which is what I was suggesting all along; sorry if I wasn't
clear enough on that.
The standard approach is that you provide #define redirects from the
old APIs to the new ones (which are then picked up by the compiler)
*and* add function wrappers to the same affect (to make linkers,
dynamic load APIs such ctypes and debuggers happy).
Example from pythonrun.h|c:
---
/* Use macros for a bunch of old variants */
#define PyRun_String(str, s, g, l) PyRun_StringFlags(str, s, g, l, NULL)
/* Deprecated C API functions still provided for binary compatiblity */
#undef PyRun_String
PyAPI_FUNC(PyObject *)
PyRun_String(const char *str, int s, PyObject *g, PyObject *l)
{
return PyRun_StringFlags(str, s, g, l, NULL);
}
Okay, how about this? http://codereview.appspot.com/1521
Using that patch, both PyString_ and PyBytes_ APIs are available using
function stubs similar to the above. I opted to define the stub
functions right next to the ones they were stubbing rather than
putting them all at the end of the file or in another file but they
could be moved if someone doesn't like them that way.
Thanks. I was working on a similar patch. Looks like you beat
me to it.
The only thing I'm not sure about is having the wrappers in the
same file - this is likely to cause merge conflicts when doing
direct merging and even with an automated renaming approach,
the extra code would be easier to remove if it were e.g. at
the end of the file or even better: in a separate file.
My patch worked slightly differently: it adds wrappers PyString*
that forward calls to the PyBytes* APIs and they all live in
stringobject.c. stringobject.h then also provides aliases
so that recompiled extensions pick up the new API names.
While working on my patch I ran into an issue that I haven't
been able to resolve: the wrapper functions got optimized away
by the linker and even though they appear in the libpython2.6.a,
they don't end up in the python binary itself.
As a result, importing Python 2.5 in the resulting 2.6
binary still fails with a unresolved PyString symbol.
Please check whether that's the case for your patch as well.
I still believe that we should *not* make "easy of merging" the
primary motivation for backporting changes in 3.x to 2.x. Software
design should not be guided by restrictions in the tool chain,
if not absolutely necessary.
The main argument for a backport needs to be general usefulness
to the 2.x users, IMHO... just like any other feature that
makes it into 2.x.
If merging is difficult then this needs to be addressed, but
there are more options to that than always going back to the
original 2.x trunk code. I've given a few suggestions on how
this could be approached in other emails on this thread.
I am not the one doing the merging or working on merge tools so I'll
leave this up to those that are.
I'm not sure whether there are any specific merge tools around -
apart from the 2to3.py script.
There also doesn't seem to be any documentation on the merge
process itself (at least nothing that Google can find in the
PEPs), so it's difficult to make any suggestions.
Thanks,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 02 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2008-07-07: EuroPython 2008, Vilnius, Lithuania34 days to go
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
Re: [Python-Dev] PEP 371 Discussion (pyProcessing Module)
On 5/31/08, Mark Hammond <[EMAIL PROTECTED]> wrote: > So it seems that maybe simply "setExecutable()" isn't the correct > abstraction here, but maybe a "factory" approach, so the entire process > creation mechanism can be replaced rather than just the name of the > executable to spawn? Indeed. If the spawn mechanisms (and even the connection mechanisms) were fully abstracted, then I believe that extending pyProcessing to work in clusters with something like MPI would be far easier. But perhaps I'm just dreaming... -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371 Discussion (pyProcessing Module)
Nick> We fixed the module names that used mixed case - the amount of Nick> work that turned out to be involved in just doing that much for Nick> PEP 3108 makes me shudder at the thought of trying to fix all of Nick> the standard library APIs that currently don't follow the style Nick> guide... If the 3.0 API of a module is going to involve breakage which requires authors to update their applications wouldn't this be a good time to PEP-8-ify the module? (Not suggesting that threading would fall into this category.) Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
Are you completelly sure of adding those guys: PyBytes_InternXXX ???
On 6/1/08, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> > On 2008-05-30 00:57, Nick Coghlan wrote:
> >>
> >> M.-A. Lemburg wrote:
> >>>
> >>> * Why can't we have both PyString *and* PyBytes exposed in 2.x,
> >>> with one redirecting to the other ?
> >>
> >> We do have that - the PyString_* names still work perfectly fine in 2.x.
> >> They just won't be used in the Python core codebase anymore - everything
> in
> >> the Python core will use either PyBytes_* or PyUnicode_* regardless of
> which
> >> branch (2.x or 3.x) you're working on. I think that's a good thing for
> ease
> >> of maintenance in the future, even if it takes people a while to get their
> >> heads around it right now.
> >
> > Sorry, I probably wasn't clear enough:
> >
> > Why can't we have both PyString *and* PyBytes exposed as C
> > APIs (ie. visible in code and in the linker) in 2.x, with one redirecting
> > to the other ?
> >
> >>> * Why should the 2.x code base turn to hacks, just because 3.x wants
> >>> to restructure itself ?
> >>
> >> With the better explanation from Greg of what the checked in approach
> >> achieves (i.e. preserving exact ABI compatibility for PyString_*, while
> >> allowing PyBytes_* to be used at the source code level), I don't see what
> >> has been done as being any more of a hack than the possibly more common
> >> "#define " (which *would* break binary compatibility).
> >>
> >> The only things that I think would tidy it up further would be to:
> >> - include an explanation of the approach and its effects on API and ABI
> >> backward and forward compatibility within 2.x and between 2.x and 3.x in
> >> stringobject.h
> >> - expose the PyBytes_* functions to the linker in 2.6 as well as 3.0
> >
> > Which is what I was suggesting all along; sorry if I wasn't
> > clear enough on that.
> >
> > The standard approach is that you provide #define redirects from the
> > old APIs to the new ones (which are then picked up by the compiler)
> > *and* add function wrappers to the same affect (to make linkers,
> > dynamic load APIs such ctypes and debuggers happy).
> >
> >
> > Example from pythonrun.h|c:
> > ---
> >
> > /* Use macros for a bunch of old variants */
> > #define PyRun_String(str, s, g, l) PyRun_StringFlags(str, s, g, l, NULL)
> >
> > /* Deprecated C API functions still provided for binary compatiblity */
> >
> > #undef PyRun_String
> > PyAPI_FUNC(PyObject *)
> > PyRun_String(const char *str, int s, PyObject *g, PyObject *l)
> > {
> >return PyRun_StringFlags(str, s, g, l, NULL);
> > }
> >
>
>
> Okay, how about this? http://codereview.appspot.com/1521
>
> Using that patch, both PyString_ and PyBytes_ APIs are available using
> function stubs similar to the above. I opted to define the stub
> functions right next to the ones they were stubbing rather than
> putting them all at the end of the file or in another file but they
> could be moved if someone doesn't like them that way.
>
>
> > I still believe that we should *not* make "easy of merging" the
> > primary motivation for backporting changes in 3.x to 2.x. Software
> > design should not be guided by restrictions in the tool chain,
> > if not absolutely necessary.
> >
> > The main argument for a backport needs to be general usefulness
> > to the 2.x users, IMHO... just like any other feature that
> > makes it into 2.x.
> >
> > If merging is difficult then this needs to be addressed, but
> > there are more options to that than always going back to the
> > original 2.x trunk code. I've given a few suggestions on how
> > this could be approached in other emails on this thread.
>
>
> I am not the one doing the merging or working on merge tools so I'll
> leave this up to those that are.
>
> -gps
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/dalcinl%40gmail.com
>
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On Mon, Jun 2, 2008 at 5:33 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > >> Okay, how about this? http://codereview.appspot.com/1521 >> >> Using that patch, both PyString_ and PyBytes_ APIs are available using >> function stubs similar to the above. I opted to define the stub >> functions right next to the ones they were stubbing rather than >> putting them all at the end of the file or in another file but they >> could be moved if someone doesn't like them that way. >> > > Thanks. I was working on a similar patch. Looks like you beat > me to it. > > The only thing I'm not sure about is having the wrappers in the > same file - this is likely to cause merge conflicts when doing > direct merging and even with an automated renaming approach, > the extra code would be easier to remove if it were e.g. at > the end of the file or even better: in a separate file. > > My patch worked slightly differently: it adds wrappers PyString* > that forward calls to the PyBytes* APIs and they all live in > stringobject.c. stringobject.h then also provides aliases > so that recompiled extensions pick up the new API names. > > While working on my patch I ran into an issue that I haven't > been able to resolve: the wrapper functions got optimized away > by the linker and even though they appear in the libpython2.6.a, > they don't end up in the python binary itself. > > As a result, importing Python 2.5 in the resulting 2.6 > binary still fails with a unresolved PyString symbol. > > Please check whether that's the case for your patch as well. I think that is going to happen no matter which approach is used (yours or mine) unless we force some included code to call each of the stubs (needlessly inefficient). One way to do that is to reference them all from a section of code called conditionally based upon an always false condition that the compiler and linker can never predetermine is false so that it cannot be eliminated as dead code. Given that, should we bother? I don't think we really need PyBytes_ to show up in the binary ABI for 2.x even if that is how we write the calls in the python internals code. The arguments put forth that debugging is easier if you can just set a breakpoint on what you read may be true but including stub functions doesn't help this when most of the time they're compiled under the alternate name using #defines so a breakpoint set on the stub name will not actually trigger. API wise we're really providing the PyBytes* names to make module author's work of writing code that targets 2.6 and 3.x easier but isn't it reasonable for authors to just be told that they're just #defined aliases for PyString*. There is no goal, nor should there be, of a module binary compiled against 2.x loading and working in 3.x. I expect most module authors, code generators and such will want to target Python 2.x earlier than 2.6 as well so should we provide PyBytes_ names as a public API in 2.6 at all? (regardless of if we use the PyBytes names internally for any reason) -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
-cc: python-3000
I believe those APIs are already there in the existing interface. Why does
that concern you?
On Mon, Jun 2, 2008 at 9:17 AM, Lisandro Dalcin <[EMAIL PROTECTED]> wrote:
> Are you completelly sure of adding those guys: PyBytes_InternXXX ???
>
>
> On 6/1/08, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> > On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> > > On 2008-05-30 00:57, Nick Coghlan wrote:
> > >>
> > >> M.-A. Lemburg wrote:
> > >>>
> > >>> * Why can't we have both PyString *and* PyBytes exposed in 2.x,
> > >>> with one redirecting to the other ?
> > >>
> > >> We do have that - the PyString_* names still work perfectly fine in
> 2.x.
> > >> They just won't be used in the Python core codebase anymore -
> everything in
> > >> the Python core will use either PyBytes_* or PyUnicode_* regardless
> of which
> > >> branch (2.x or 3.x) you're working on. I think that's a good thing
> for ease
> > >> of maintenance in the future, even if it takes people a while to get
> their
> > >> heads around it right now.
> > >
> > > Sorry, I probably wasn't clear enough:
> > >
> > > Why can't we have both PyString *and* PyBytes exposed as C
> > > APIs (ie. visible in code and in the linker) in 2.x, with one
> redirecting
> > > to the other ?
> > >
> > >>> * Why should the 2.x code base turn to hacks, just because 3.x wants
> > >>> to restructure itself ?
> > >>
> > >> With the better explanation from Greg of what the checked in approach
> > >> achieves (i.e. preserving exact ABI compatibility for PyString_*,
> while
> > >> allowing PyBytes_* to be used at the source code level), I don't see
> what
> > >> has been done as being any more of a hack than the possibly more
> common
> > >> "#define " (which *would* break binary
> compatibility).
> > >>
> > >> The only things that I think would tidy it up further would be to:
> > >> - include an explanation of the approach and its effects on API and
> ABI
> > >> backward and forward compatibility within 2.x and between 2.x and 3.x
> in
> > >> stringobject.h
> > >> - expose the PyBytes_* functions to the linker in 2.6 as well as 3.0
> > >
> > > Which is what I was suggesting all along; sorry if I wasn't
> > > clear enough on that.
> > >
> > > The standard approach is that you provide #define redirects from the
> > > old APIs to the new ones (which are then picked up by the compiler)
> > > *and* add function wrappers to the same affect (to make linkers,
> > > dynamic load APIs such ctypes and debuggers happy).
> > >
> > >
> > > Example from pythonrun.h|c:
> > > ---
> > >
> > > /* Use macros for a bunch of old variants */
> > > #define PyRun_String(str, s, g, l) PyRun_StringFlags(str, s, g, l,
> NULL)
> > >
> > > /* Deprecated C API functions still provided for binary compatiblity
> */
> > >
> > > #undef PyRun_String
> > > PyAPI_FUNC(PyObject *)
> > > PyRun_String(const char *str, int s, PyObject *g, PyObject *l)
> > > {
> > >return PyRun_StringFlags(str, s, g, l, NULL);
> > > }
> > >
> >
> >
> > Okay, how about this? http://codereview.appspot.com/1521
> >
> > Using that patch, both PyString_ and PyBytes_ APIs are available using
> > function stubs similar to the above. I opted to define the stub
> > functions right next to the ones they were stubbing rather than
> > putting them all at the end of the file or in another file but they
> > could be moved if someone doesn't like them that way.
> >
> >
> > > I still believe that we should *not* make "easy of merging" the
> > > primary motivation for backporting changes in 3.x to 2.x. Software
> > > design should not be guided by restrictions in the tool chain,
> > > if not absolutely necessary.
> > >
> > > The main argument for a backport needs to be general usefulness
> > > to the 2.x users, IMHO... just like any other feature that
> > > makes it into 2.x.
> > >
> > > If merging is difficult then this needs to be addressed, but
> > > there are more options to that than always going back to the
> > > original 2.x trunk code. I've given a few suggestions on how
> > > this could be approached in other emails on this thread.
> >
> >
> > I am not the one doing the merging or working on merge tools so I'll
> > leave this up to those that are.
> >
> > -gps
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/dalcinl%40gmail.com
> >
>
>
> --
> Lisandro Dalcín
> ---
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
>
_
[Python-Dev] Postponing the first betas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We are going to postpone the first beta releases by one week. We had some problems with mail.python.org today, which prompted a query to Guido from me about the postponement. mail.python.org should now be back up normally now, as evidenced by the emailfloodl but in the meantime, Guido said: "I'd also like to see PEP 3138 (CJK-friendly repr()) and the pyprocessing PEP implemented by then, and perhaps some other small stuff." So we're going to do the first beta releases next Wednesday, June 11. Please take this time to stabilize all APIs and features, both in Python and C. Next week, I'll do a gut check on critical and release blocker bugs, so please also take a look at those and try to fix what you can. Cheers, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSER5gnEjvBPtnXfVAQJlBAQAgfmRwGQzwNFrwvMusIoDNVRuyIObkKO0 FeDYb26RAL1jLXt0x/7jE0fBc5FvhDzUJnnNj3sydfyKU5MCb0eB0VeBTmjHU05l yncX6zYSoU14OUW+bkG4y7vf+aLD9zlFsj/ybMEZTQh0RMpZ+HBNhup3NJFEDTBM 97q4SIvltAg= =NBRW -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
I will freely admit that I haven't followed this thread in any detail, but if it were up to me, I'd have the 2.6 internal code use PyString (as both what the linker sees and what the human reads in the source code) and the 3.0 code use PyBytes for the same thing. Let the merges be damed -- most changes to 2.6 these days seem to be blocked explicitly from being merged anyway. I'd prefer the 2.6 code base to stay true to 2.x, and the 3.0 code base start afresh where it makes sense. We should reindent more of the 3.0 code base to use 4-space-indents in C code too. I would also add macros that map the PyBytes_* APIs to PyString_*, but I would not start using these internally except in code newly written for 2.6 and intended to be "in the spirit of 3.0". IOW use PyString for 8-bit strings containing text, and PyBytes for 8-bit strings containing binary data. For 8-bit strings that could contain either text or data, I'd use PyString, in the spirit of 2.x. --Guido On Mon, Jun 2, 2008 at 3:21 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > > > On Mon, Jun 2, 2008 at 5:33 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: >>> >>> Okay, how about this? http://codereview.appspot.com/1521 >>> >>> Using that patch, both PyString_ and PyBytes_ APIs are available using >>> function stubs similar to the above. I opted to define the stub >>> functions right next to the ones they were stubbing rather than >>> putting them all at the end of the file or in another file but they >>> could be moved if someone doesn't like them that way. >> >> Thanks. I was working on a similar patch. Looks like you beat >> me to it. >> >> The only thing I'm not sure about is having the wrappers in the >> same file - this is likely to cause merge conflicts when doing >> direct merging and even with an automated renaming approach, >> the extra code would be easier to remove if it were e.g. at >> the end of the file or even better: in a separate file. >> >> My patch worked slightly differently: it adds wrappers PyString* >> that forward calls to the PyBytes* APIs and they all live in >> stringobject.c. stringobject.h then also provides aliases >> so that recompiled extensions pick up the new API names. >> >> While working on my patch I ran into an issue that I haven't >> been able to resolve: the wrapper functions got optimized away >> by the linker and even though they appear in the libpython2.6.a, >> they don't end up in the python binary itself. >> >> As a result, importing Python 2.5 in the resulting 2.6 >> binary still fails with a unresolved PyString symbol. >> >> Please check whether that's the case for your patch as well. > > I think that is going to happen no matter which approach is used (yours or > mine) unless we force some included code to call each of the stubs > (needlessly inefficient). One way to do that is to reference them all from > a section of code called conditionally based upon an always false condition > that the compiler and linker can never predetermine is false so that it > cannot be eliminated as dead code. > > Given that, should we bother? I don't think we really need PyBytes_ to show > up in the binary ABI for 2.x even if that is how we write the calls in the > python internals code. The arguments put forth that debugging is easier if > you can just set a breakpoint on what you read may be true but including > stub functions doesn't help this when most of the time they're compiled > under the alternate name using #defines so a breakpoint set on the stub name > will not actually trigger. > > API wise we're really providing the PyBytes* names to make module author's > work of writing code that targets 2.6 and 3.x easier but isn't it reasonable > for authors to just be told that they're just #defined aliases for > PyString*. There is no goal, nor should there be, of a module binary > compiled against 2.x loading and working in 3.x. > > I expect most module authors, code generators and such will want to target > Python 2.x earlier than 2.6 as well so should we provide PyBytes_ names as a > public API in 2.6 at all? (regardless of if we use the PyBytes names > internally for any reason) > > -gps > > > ___ > Python-3000 mailing list > [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/guido%40python.org > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I will freely admit that I haven't followed this thread in any detail, > but if it were up to me, I'd have the 2.6 internal code use PyString ... Should we read this as a BDFL pronouncement and make it so? All that would mean change wise is that trunk r63675 as well as possibly r63672 and r63677 would need to be rolled back and this whole discussion over if such a big change should have happened would turn into a moot point. I would also add macros that map the PyBytes_* APIs to PyString_*, but > I would not start using these internally except in code newly written > for 2.6 and intended to be "in the spirit of 3.0". IOW use PyString > for 8-bit strings containing text, and PyBytes for 8-bit strings > containing binary data. For 8-bit strings that could contain either > text or data, I'd use PyString, in the spirit of 2.x. > > --Guido > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue2889: Add Curses for Windows as native module for 2.6
On Sat, May 24, 2008 at 3:15 PM, Paul Moore <[EMAIL PROTECTED]> wrote: > > > As for PDCurses library itself there is a Makefile in PDCurses > distribution > > for Microsoft Visual C++ 2.0+ named vcwin32.mak I can't afford buying > > Visual Studio to test if it works with newer versions, but logically > Visual > > Studio should be able to convert Makefile to a newer format. > > Visual C++ 9.0 Express Edition builds Python quite happily these days. > So you can certainly do the integration without buying anything. If > you get stuck on technical details, there are people here who would > happily give you advice. Windows developers are always welcome! Finally, I've downloaded Microsoft Visual Studio Express 2008, but it requires Windows XP to install and I have only Windows2000 at hand. I will try to get MS Visual Studio Express 2005 and see if it works. > If you don't have the knowledge needed, and can't spare the time to > learn (which is entirely acceptable) then you are indeed relying on > another Windows developer to pick this up. You may be out of luck > there - nobody has been interested enough to do this before now (it's > not as if PDCurses is new) so there's not much reason to expect things > to have changed. > > I'll try to spare the time to learn how to include curses support in windows, but I will appreciate if anybody could review the patches and convert project to MSVC 2008 in the end. -- --anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Postponing the first betas
On Mon, Jun 2, 2008 at 3:51 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > We are going to postpone the first beta releases by one week. We had some > problems with mail.python.org today, which prompted a query to Guido from me > about the postponement. mail.python.org should now be back up normally now, > as evidenced by the emailfloodl but in the meantime, Guido said: > > "I'd also like to see PEP 3138 (CJK-friendly repr()) and the > pyprocessing PEP implemented by then, and perhaps some other small > stuff." > > So we're going to do the first beta releases next Wednesday, June 11. > Please take this time to stabilize all APIs and features, both in Python > and C. Next week, I'll do a gut check on critical and release blocker bugs, > so please also take a look at those and try to fix what you can. > Now is as good a time as any to mention that on Wednesday I am flying out to help my mother move. I don't know when she is going to have her Internet connection set up, so I might not be back online until June 16. But thanks to all the help I have been receiving on PEP 3108, I trust the various people involved to continue to do the right thing in my absence. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Postponing the first betas
On Mon, Jun 2, 2008 at 7:22 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> > > Now is as good a time as any to mention that on Wednesday I am flying > out to help my mother move. I don't know when she is going to have her > Internet connection set up, so I might not be back online until June > 16. But thanks to all the help I have been receiving on PEP 3108, I > trust the various people involved to continue to do the right thing in > my absence. That reminds me of those Dilbert cartoons where his mother ends up knowing much more about computers than he does. :) -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] converting the stdlib to str.format
Hi all, As a newly converted fan of str.format, it gives me pangs to see the whole stdlib using "%." I realize that str.format is not quite up to the speed standards we'd like, but I'm sure that will change. In any case, I'm willing to give the TLC to convert the whole stdlib to str.format, so I just need your permission! -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] converting the stdlib to str.format
On Mon, Jun 2, 2008 at 5:49 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > As a newly converted fan of str.format, it gives me pangs to see the > whole stdlib using "%." I realize that str.format is not quite up to > the speed standards we'd like, but I'm sure that will change. > > In any case, I'm willing to give the TLC to convert the whole stdlib > to str.format, so I just need your permission! So glad you asked! There's a standard answer whenever someone suggests a sweeping conversion of the entire stdlib to some new feature. It's "No." :-) In the past, we've tried things like this a few times, and it was nearly always a mistake. Things like this can't be automated 100%, and doing a manual audit of the changes is so incredibly tedious that inevitably a few incorrect changes slip by. In theory these would be caught by unittests, but in practice the difference between practice and theory is larger than in theory, so inevitably the honor falls to some poor schmuck whose application fails in a non-trivial way, often months later. I recall one particularly ill-fated conversion where we some bogus conversions weren't fixed until several years (and releases!) later. And these were pretty badly botched too, something like foo(bar(x, y)) vs. foo(bar(x), y) -- it was just in rarely executed code and due to the complexity of the expressions (and the fact that the parentheses were balanced ;-) nobody had noticed before. It's much better to do this piecemeal, when you are revising a particular module for some other reason. Then you (presumably) have the time to review every change thoroughly -- and hopefully you can even add unittests for all code you touch. I realize that 2to3 might make such conversions less error-prone. But most 2to3 conversions are not 100% correct either, and the problem of falling asleep while reviewing the changes exists especially where there are so many correct conversions! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
