Re: [Python-Dev] Packaging and binary distributions for Python 3.3
Paul Moore gmail.com> writes: > To summarise, then: > > 1. By using setup.cfg technology, it would be easy enough to zip up a > binary build in a way that pysetup could unpack and install. >1a. A packaging command to build such an archive would be worth providing. > 2. A GUI installer would still be valuable for many people >2a. Having the GUI work by doing a pysetup install passing the > installer exe (which would have a zipfile as noted in 1 above > appended) could make sense to avoid duplicating work. >2b. The GUI could do the extra needed to integrate with the OS, > which pysetup wouldn't do >2c. There's a question over a GUI install followed by a pysetup > uninstall, which wouldn't remove the add/remove entry... > 3. Ideally, the GUI should co-operate with venvs, by offering some > form of browse facility. The command line does this automatically. > > I'll do some research into setup.cfg capabilities and do some proof of > concept work to see how all this would work. > > Does the above make sense? To me it does, and it would be useful to have some validation from the packaging folks. I looked at the dialog resources for wininst-x.y.exe and noticed that there is a "Find other ..." button which is hidden, and its handler (in PC\bdist_wininst\install.c) is commented out. However, the code called by the handler - GetOtherPythonVersion - is still there. Does anyone here know why the button has been made unavailable? Regards, Vinay Sajip ___ 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] Test failures on Windows 7
I just cloned and built CPython default on Windows 7 32-bit (in a VM). The build was successful, but I get crashes when running the regression tests: test test_capi failed -- Traceback (most recent call last): File "C:\Users\Vinay\Projects\cpython\lib\test\test_capi.py", line 51, in test _no_FatalError_infinite_loop b'Fatal Python error:' AssertionError: b"Fatal Python error: PyThreadState_Get: no current thread\n\r\n This application has requested the Runtime to terminate it in an unusual way.\nP lease contact the application's support team for more information." != b'Fatal P ython error: PyThreadState_Get: no current thread' test test_faulthandler failed -- Traceback (most recent call last): File "C:\Users\Vinay\Projects\cpython\lib\test\test_faulthandler.py", line 175 , in test_fatal_error 'xyz') File "C:\Users\Vinay\Projects\cpython\lib\test\test_faulthandler.py", line 105 , in check_fatal_error self.assertRegex(output, regex) AssertionError: Regex didn't match: '^Fatal Python error: xyz\n\nCurrent\\ threa d\\ XXX:\n File "", line 2 in $' not found in 'Fatal Python err or: xyz\n\nCurrent thread XXX:\n File "", line 2 in \n\nThis ap plication has requested the Runtime to terminate it in an unusual way.\nPlease c ontact the application\'s support team for more information.' It's been a few weeks since I built and tested on Windows 7, so I'm not sure what to make of these. I notice that at least some of the Windows 7 buildbots are green, so can someone advise whether there is any special configuring I need to do? I've just built from the solution file (using Visual Studio 2008 SP1). Regards, Vinay Sajip ___ 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] Test failures on Windows 7
Vinay Sajip wrote: > test test_capi failed -- Traceback (most recent call last): > test test_faulthandler failed -- Traceback (most recent call last): The tests call abort(), and the handling on Windows is slightly peculiar. See: http://bugs.python.org/issue9116 http://bugs.python.org/issue11732 Stefan Krah ___ 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] Test failures on Windows 7
Hi, 2011/10/11 Vinay Sajip : > AssertionError: b"Fatal Python error: PyThreadState_Get: no current > thread\n\r\n > This application has requested the Runtime to terminate it in an unusual > way.\nP > lease contact the application's support team for more information." != > b'Fatal P > ython error: PyThreadState_Get: no current thread' Can these additional lines "This application has requested the Runtime to terminate..." be the equivalent of the infamous popups we had sometimes? I know that buildbots modified a specific registry key, I don't remember which one though :-( -- Amaury Forgeot d'Arc ___ 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] Where are the build files for recent wininst-x.y.exe programs in packaging?
The packaging/command folder contains wininst executables with the following suffixes: -6.0.exe, -7.1.exe, -8.0.exe, -9.0.exe, -9.0.amd64.exe, -10.0.exe, and -10.0-amd64.exe. However, the build files in PC\bdist_wininst only seem to cover building up to -8.0.exe; there are no build files for -9.0 and -10.0 versions. Where can these be found? Thanks, Vinay Sajip ___ 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] Where are the build files for recent wininst-x.y.exe programs in packaging?
Vinay Sajip yahoo.co.uk> writes: Never mind, found the answer from closed issue 9818 - bdist_wininst.vcproj. ___ 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] Identifier API
On 10/08/2011 04:54 PM, "Martin v. Löwis" wrote:
tmp = PyObject_CallMethod(result, "update", "O", other);
would be replaced with
PyObject *tmp;
Py_identifier(update);
...
tmp = PyObject_CallMethodId(result,&PyId_update, "O", other);
An alternative I am fond of is to to avoid introducing a new type, and
simply initialize a PyObject * and register its address. For example:
PyObject *tmp;
static PyObject *s_update;// pick a naming convention
PY_IDENTIFIER_INIT(update);
tmp = PyObject_CallMethodObj(result, s_update, "O", other);
(but also PyObject_GetAttr(o, s_update), etc.)
PY_IDENTIFIER_INIT(update) might expand to something like:
if (!s_update) {
s_update = PyUnicode_InternFromString("update");
_Py_IdentifierAdd(&s_update);
}
_PyIdentifierAdd adds the address of the variable to a global set of C
variables that need to be decreffed and zeroed-out at interpreted shutdown.
The benefits of this approach is:
* you don't need special "identifier" versions of functions such as
PyObject_CallMethod. In my example I invented a
PyObject_CallMethodObj, but adding that might be useful anyway.
* a lot of Python/C code implements similar caching, often
leaking strings.
Hrvoje
___
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] Identifier API
2011/10/11 Hrvoje Niksic
> An alternative I am fond of is to to avoid introducing a new type, and
> simply initialize a PyObject * and register its address. For example:
>
> PyObject *tmp;
> static PyObject *s_update;// pick a naming convention
>
> PY_IDENTIFIER_INIT(update);
> tmp = PyObject_CallMethodObj(result, s_update, "O", other);
>
> (but also PyObject_GetAttr(o, s_update), etc.)
>
> PY_IDENTIFIER_INIT(update) might expand to something like:
>
> if (!s_update) {
>s_update = PyUnicode_InternFromString("**update");
>_Py_IdentifierAdd(&s_update);
> }
>
It should also check for errors; in this case the initialization is a bit
more verbose:
if (PY_IDENTIFIER_INIT(update) < 0)
;
--
Amaury Forgeot d'Arc
___
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] Bring new features to older python versions
On 10/10/2011 21:21, Giampaolo Rodolà wrote: Thanks everybody for your feedback. I created a gcode project here: http://code.google.com/p/pycompat/ 2011/10/8 Antoine Pitrou: There's also some stuff there that is coded in C, or that will rely on some functionality of the core interpreter that is not easily emulated on previous versions. But I suppose you'll find that out by yourself. Yep, I'm still not sure what to do about this. I guess I'll just ignore that stuff in all those cases where rewriting it in python is too much effort. Toshio Kuratomi wrote: I have a need to support a small amount of code as far back as python-2.3 I don't suppose you're interested in that as well? ;-) I'm still not sure; 2.3 version is way too old (it doesn't even have decorators). It might make sense only in case the lib gets widely used, which I doubt. Personally, at some point I deliberately dropped support for 2.3 from all of my code/lib, mainly because I couldn't use decorators. so I don't have a real need to do this. Yes, rewriting code from Python 2.7 to support Python 2.3 (pre-decorators) is a real nuisance. In my projects I'm currently supporting Python 2.4+. I'll probably drop support for Python 2.4 soon which will allow for the use of the with statement. 2011/10/9 Éric Araujo: The issues I foresee with your lib are more technical: First, it looks like a big bag of backported modules, classes and functions without defined criterion for inclusion (“cool new stuff”?). I'd say the criterion for inclusion is putting in everything which can be (re)written in python 2.4, such as any, all, collections.defaultdict and property setters/deleters (2.6). Pretty much all the stuff written in C would be left out, maybe with the exception of functools module which is important (for me at least), in which case I might try to rewrite it in pure Python. I'm sharing your same doubts though. Maybe this isn't worth the effort in the first place. I'll try to write some more code and see whether this is a good candidate for a "public module". If not I'll just get back to use it as an internal "private" module. 2011/10/9 Éric Araujo: keep on lumping new things until Python 3.4? 3.8? Won’t that become unmanageable (boring/huge/hard)? I don't think it makes sense to go over than 3.2 version. Folks which are forced to use python 2.4 are already avoing to use 2.6 and 2.7 features, let alone 3.X only features. Plus, python 3.2 was already the latest 3.X version which still had something in common with 2.7. However, if you can include Python 3.2+ features then projects that also support Python 3 can still use new features without having to worry about compatibility (it solves the same problem). All the best, Michael Foord --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] Identifier API
On Oct 11, 2011, at 02:36 PM, Hrvoje Niksic wrote: >On 10/08/2011 04:54 PM, "Martin v. Löwis" wrote: >> tmp = PyObject_CallMethod(result, "update", "O", other); >> >> would be replaced with >> >>PyObject *tmp; >>Py_identifier(update); >>... >>tmp = PyObject_CallMethodId(result,&PyId_update, "O", other); > >An alternative I am fond of is to to avoid introducing a new type, and simply >initialize a PyObject * and register its address. For example: > > PyObject *tmp; > static PyObject *s_update;// pick a naming convention > > PY_IDENTIFIER_INIT(update); > tmp = PyObject_CallMethodObj(result, s_update, "O", other); > > (but also PyObject_GetAttr(o, s_update), etc.) I like this better too because of the all-caps macro name. Something about seeing "Py_identifier" look like a function call and having it add the magical PyId_update local bugs me. It just looks wrong, whereas the all-caps is more of a cultural clue that something else is going on. -Barry ___ 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] Identifier API
On 10/11/2011 02:45 PM, Amaury Forgeot d'Arc wrote: It should also check for errors; in this case the initialization is a bit more verbose: if (PY_IDENTIFIER_INIT(update) < 0) ; Error checking is somewhat more controversial because behavior in case of error differs between situations and coding patterns. I think it should be up to the calling code to check for s_update remaining NULL. In my example, I would expect PyObject_CallMethodObj and similar to raise InternalError when passed a NULL pointer. Since their return values are already checked, this should be enought to cover the unlikely case of identifier creation failing. Hrvoje ___ 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] Identifier API
On Tue, 11 Oct 2011 09:19:43 -0400 Barry Warsaw wrote: > On Oct 11, 2011, at 02:36 PM, Hrvoje Niksic wrote: > > >On 10/08/2011 04:54 PM, "Martin v. Löwis" wrote: > >> tmp = PyObject_CallMethod(result, "update", "O", other); > >> > >> would be replaced with > >> > >>PyObject *tmp; > >>Py_identifier(update); > >>... > >>tmp = PyObject_CallMethodId(result,&PyId_update, "O", other); > > > >An alternative I am fond of is to to avoid introducing a new type, and simply > >initialize a PyObject * and register its address. For example: > > > > PyObject *tmp; > > static PyObject *s_update;// pick a naming convention > > > > PY_IDENTIFIER_INIT(update); > > tmp = PyObject_CallMethodObj(result, s_update, "O", other); > > > > (but also PyObject_GetAttr(o, s_update), etc.) > > I like this better too because of the all-caps macro name. Something about > seeing "Py_identifier" look like a function call and having it add the magical > PyId_update local bugs me. It just looks wrong, whereas the all-caps is more > of a cultural clue that something else is going on. +1 for something more recognizable. I think "const string" is more accurate than "identifier" as well. Regards Antoine. ___ 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] Identifier API
2011/10/11 Antoine Pitrou : > +1 for something more recognizable. > I think "const string" is more accurate than "identifier" as well. It should only really be used for identifiers, though, because the result is interned. -- Regards, Benjamin ___ 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] Identifier API
"Martin v. Löwis", 08.10.2011 16:54:
In benchmarking PEP 393, I noticed that many UTF-8 decode
calls originate from C code with static strings, in particular
PyObject_CallMethod. Many of such calls already have been optimized
to cache a string object, however, PyObject_CallMethod remains
unoptimized since it requires a char*.
Yes, I noticed that in Cython, too. We often use PyObject_CallMethod() as a
fallback for optimistically optimised method calls when the expected fast
path does not hit, and it always bugged me that this needs to generate a
Python string on each call in order to look up the method.
I propose to add an explicit API to deal with such identifiers.
With this API,
tmp = PyObject_CallMethod(result, "update", "O", other);
would be replaced with
PyObject *tmp;
Py_identifier(update);
...
tmp = PyObject_CallMethodId(result, &PyId_update, "O", other);
Py_identifier expands to a struct
typedef struct Py_Identifier {
struct Py_Identifier *next;
const char* string;
PyObject *object;
} Py_Identifier;
string will be initialized by the compiler, next and object on
first use.
As I understand it, the macro expands to both the ID variable declaration
and the init-at-first-call code, right? This is problematic when more than
one identifier is used, as some C compilers strictly require declarations
to be written *before* any other code. I'm not sure how often users will
need more than one identifier in a function, but if it's not too hard to
come up with a way that avoids this problem all together, it would be
better to do so right from the start.
Also note that existing code needs to be changed in order to take advantage
of this. It might be possible to optimise PyObject_CallMethod() internally
by making the lookup either reuse a number of cached Python strings, or by
supporting a lookup of char* values in a dict *somehow*. However, this
appears to be substantially more involved than just moving a smaller burden
on the users.
Stefan
___
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] Bring new features to older python versions
On Tue, Oct 11, 2011 at 12:22:12AM -0400, Terry Reedy wrote: > On 10/10/2011 4:21 PM, Giampaolo Rodolà wrote: > >Thanks everybody for your feedback. > >I created a gcode project here: > >http://code.google.com/p/pycompat/ > > This project will be easier if the test suite for a particular > function/class/module is up to par. If you find any gaping holes, you > might file an issue on the tracker. > About testsuites... one issue that you'll run into is that while some stdlib modules are written with backporting to older versions in mind, their testsuites are not. For instance, subprocess from python-2.7 runs fine on python-2.3+. The testsuite for subprocess in python-2.7 makes use of the with statement, though, so it has to be ported. -Toshio pgpgjOvmVVUJ7.pgp Description: 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] Bring new features to older python versions
On 11/10/2011 16:39, Toshio Kuratomi wrote: On Tue, Oct 11, 2011 at 12:22:12AM -0400, Terry Reedy wrote: On 10/10/2011 4:21 PM, Giampaolo Rodolà wrote: Thanks everybody for your feedback. I created a gcode project here: http://code.google.com/p/pycompat/ This project will be easier if the test suite for a particular function/class/module is up to par. If you find any gaping holes, you might file an issue on the tracker. About testsuites... one issue that you'll run into is that while some stdlib modules are written with backporting to older versions in mind, their testsuites are not. For instance, subprocess from python-2.7 runs fine on python-2.3+. The testsuite for subprocess in python-2.7 makes use of the with statement, though, so it has to be ported. Some of the tests will use newer features of unittest as well. These can of course be run with unittest2 which has been backported to Python 2.4 (although use of the with statements in the tests themselves will have to be changed still). All the best, Michael Foord -Toshio ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] Bring new features to older python versions
On Tue, Oct 11, 2011 at 01:49:43PM +0100, Michael Foord wrote: > On 10/10/2011 21:21, Giampaolo Rodolà wrote: > > > >Toshio Kuratomi wrote: > >>I have a need to support a small amount of code as far back as python-2.3 > >>I don't suppose you're interested in that as well? ;-) > >I'm still not sure; 2.3 version is way too old (it doesn't even have > >decorators). > >It might make sense only in case the lib gets widely used, which I doubt. > >Personally, at some point I deliberately dropped support for 2.3 from > >all of my code/lib, mainly because I couldn't use decorators. so I > >don't have a real need to do this. > > Yes, rewriting code from Python 2.7 to support Python 2.3 > (pre-decorators) is a real nuisance. In my projects I'm currently > supporting Python 2.4+. I'll probably drop support for Python 2.4 > soon which will allow for the use of the with statement. > So actually, decorators aren't a big deal when thinking about porting a limited set of code to python-2.3. decorators are simply syntactic sugar after all, so it's only a one-line change:: @cache() def function(arg): # do_expensive_something return result becomes:: def function(arg): # do_expensiv_something return result function = cache(function) This may not be the preferred manner to write decorators but it's fairly straightforward and easy to remember compared to, say, porting away from the with statement. That said, this was in the nature of hopeful, finger crossing, not really expecting that I'd get someone else to commit to this as a limitation than a, "this is not worthwhile unless you go back to python-2.3". I only have to bear this burden until February 29 and believe me, I'm anxiously awaiting that day :-) -Toshio pgpVhXAYYRc0x.pgp Description: 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] Bring new features to older python versions
On Tue, Oct 11, 2011 at 12:14 PM, Toshio Kuratomi wrote: > This may not be the preferred manner to write decorators but it's fairly > straightforward and easy to remember compared to, say, porting away from > the > with statement. > You can emulate 'with' using decorators, actually, if you don't mind a nested function. Some code from my Contextual library (minus the tests): *def* *call_with*(ctxmgr): *"""Emulate the PEP 343 "with" statement for Python versions <2.5 The following examples do the same thing at runtime:: Python 2.5+ Python 2.4 - with x as y: @call_with(x) print y def do_it(y): print y ``call_with(foo)`` returns a decorator that immediately invokes the function it decorates, passing in the same value that would be bound by the ``as`` clause of the ``with`` statement. Thus, by decorating a nested function, you can get most of the benefits of "with", at a cost of being slightly slower and perhaps a bit more obscure than the 2.5 syntax. Note: because of the way decorators work, the return value (if any) of the ``do_it()`` function above will be bound to the name ``do_it``. So, this example prints "42":: @call_with(x) def do_it(y): return 42 print do_it This is rather ugly, so you may prefer to do it this way instead, which more explicitly calls the function and gets back a value:: def do_it(y): return 42 print with_(x, do_it) """* *return* with_.__get__(ctxmgr, type(ctxmgr)) *def* *with_*(ctx, func): *"""Perform PEP 343 "with" logic for Python versions <2.5 The following examples do the same thing at runtime:: Python 2.5+ Python 2.3/2.4 -- with x as y: z = with_(x,f) z = f(y) This function is used to implement the ``call_with()`` decorator, but can also be used directly. It's faster and more compact in the case where the function ``f`` already exists. """* inp = ctx.__enter__() *try*: retval = func(inp) *except*: *if* *not* ctx.__exit__(*sys.exc_info()): *raise* *else*: ctx.__exit__(None, None, None) *return* retval This version doesn't handle the multi-context syntax of newer pythons, but could probably be extended readily enough. ___ 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 393 close to pronouncement
Victor Stinner wrote: >> Given that I've been working on and maintaining the Python Unicode >> implementation actively or by providing assistance for almost >> 12 years now, I've also thought about whether it's still worth >> the effort. > > Thanks for your huge work on Unicode, Marc-Andre! Thanks. I enjoyed working it on it, but priorities are different now, and new projects are waiting :-) >> My interests have shifted somewhat into other directions and >> I feel that helping Python reach world domination in other ways >> makes me happier than fighting over Unicode standards, implementations, >> special cases that aren't special enough, and all those other >> nitty-gritty details that cause long discussions :-) > > Someone said that we still need to define what a character is! By the way, > what > is a code point? I'll leave that as exercise for the interested reader to find out :-) (Hint: Google should find enough hits where I've explained those things on various mailing lists and in talks I gave.) >> So I feel that the PEP 393 change is a good time to draw a line >> and leave Unicode maintenance to Ezio, Victor, Martin, and >> all the others that have helped over the years. I know it's >> in good hands. > > I don't understand why you would like to stop contribution to Unicode, but I only have limited time available for these things and am nowadays more interested in getting others to recognize just how great Python is, than actually sitting down and writing patches for it. Unicode was my baby for quite a few years, but I now have two kids which need more love and attention :-) > well, as you want. We will try to continue your work. Thanks. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 11 2011) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface 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 http://www.egenix.com/company/contact/ ___ 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] PEP 3151 accepted
As the BDFOP for PEP 3151, I hereby accept it for inclusion into Python 3.3. Congratulations to Antoine for producing a great PEP that has broad acceptance in the Python development community, with buy-in from all the major implementations of Python. Antoine's branch is ready to go and it should now be merged into the default branch. PEP 3151 will bring some much needed sanity to this part of the standard exception hierarchy, and I for one look forward to being able to write code directly using it, one day finally eliminating most of my `import errno`s! Cheers, -Barry signature.asc Description: 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] PEP 3151 accepted
On Tue, 11 Oct 2011 18:22:43 -0400 Barry Warsaw wrote: > As the BDFOP for PEP 3151, I hereby accept it for inclusion into Python 3.3. > > Congratulations to Antoine for producing a great PEP that has broad acceptance > in the Python development community, with buy-in from all the major > implementations of Python. Antoine's branch is ready to go and it should now > be merged into the default branch. > > PEP 3151 will bring some much needed sanity to this part of the standard > exception hierarchy, and I for one look forward to being able to write code > directly using it, one day finally eliminating most of my `import errno`s! Thanks Barry! I expect to merge the PEP 3151 into default soon (it's basically ready). cheers Antoine. ___ 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] cpython: Backed out changeset 952d91a7d376
On Wed, 12 Oct 2011 00:53:52 +0200 victor.stinner wrote: > http://hg.python.org/cpython/rev/2abd48a47f3b > changeset: 72878:2abd48a47f3b > user:Victor Stinner > date:Wed Oct 12 00:54:35 2011 +0200 > summary: > Backed out changeset 952d91a7d376 > > If maxchar == PyUnicode_MAX_CHAR_VALUE(unicode), we do an useless copy. Ah, that was the purpose of this assert. Fair enough :) Regards Antoine. ___ 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
