Re: [Python-Dev] Addition of pyprocessing module to standard lib.
Nick Coghlan wrote: Ulrich Berning wrote: More and more people tend to say Runs on Un*x when they really mean Tested on Linux. Un*x is not Linux. Hmm, perhaps that would be why there are Solaris, FreeBSD and Tru64 machines amongst the main Python buildbots, to go along with the assorted OS X, Windows and Linux boxes - and as far as I know test_ctypes runs quite happily on all of them. On the specific problems with AIX, HP-UX and ctypes, was it ctypes itself that was failing to build, or the underlying libffi? Cheers, Nick. On HP-UX-11.00, HP ANSI C++ B3910B A.03.73, Python-2.5.2, I get configure: error: libffi has not been ported to hppa2.0w-hp-hpux11.00. On AIX-4.3.3, C for AIX Compiler Version 6, Python-2.5.2, I get build/temp.aix-4.3-2.5/libffi/include/ffi.h, line 123.4: 1506-205 (S) #error no 64-bit data type supported On Solaris-10/x86, Sun C 5.8 Patch 121016-07 2007/10/03, Python-2.5.2, I get build/temp.solaris-2.10-i86pc-2.5/libffi/include/ffitarget.h, line 64: undefined symbol: FFI_DEFAULT_ABI On Solaris-8/sparc, Sun C 5.8 2005/10/13, Python-2.5.2, I get build/temp.solaris-2.8-sun4u-2.5/libffi/include/ffi.h, line 225: syntax error before or at: __attribute__ On IRIX-6.5, gcc-3.4.4, Python-2.5.2, ffi_closure is undefined, because only the old O32 binary format is supported, not the new N32/N64 format. I'm trying to use the vendor specific compilers whenever possible, because using gcc puts in additional dependencies (libgcc), I want to avoid, and even if I could live with these dependencies, it's not easy to get/build the 'right' gcc version, if your software also depends on other big packages like Qt and PyQt. I'm not using these platforms for my own pleasure (in fact, I would be happy if these platforms would disappear from the market), but as long as our customers use these platforms, we want to promise our software runs on those platforms. I have no problem with the fact that ctypes doesn't build on those platforms because I don't use it, but if more and more essential packages depend on ctypes, I'm running into trouble. PyOpenGL is an example of an extension, that moved completely from C-Source (SWIG generated) to ctypes usage. Ulli ___ 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] Addition of pyprocessing module to standard lib.
Gregory P. Smith wrote: On Fri, May 16, 2008 at 1:32 AM, Ulrich Berning [EMAIL PROTECTED] wrote: As long as the ctypes extension doesn't build on major Un*x platforms (AIX, HP-UX), I don't like to see ctypes dependend modules included into the stdlib. Please keep the stdlib as portable as possible. Nice in theory but ctypes already works on at least the top 3 popular platforms. Lets not hold Python's stdlib back because nobody who uses IBM and HP proprietary stuff has contributed the necessary support. Making nice libraries available for other platforms is a good way to encourage people to either pitch in and add support or consider their platform choices in the future. -gps It's not my platform choice, it's the choice of our customers. I'm not using these platforms just for fun (in fact it isn't fun compared to Linux or Windows). If porting libffi to AIX, HP-UX, IRIX, Solaris... (especially using vendor compilers) would be an easy job, I'm sure it would have been done already. If more and more essential packages depend on ctypes, we should make a clear statement, that Python isn't supported any longer on platform/compiler combinations where libffi/ctypes doesn't build. This would give me arguments to drop support of our software on those platforms. Ulli ___ 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] Conditional For Statements
On Mon, May 19, 2008 at 5:55 AM, Terry Reedy [EMAIL PROTECTED] wrote:
Ryan Hitchman [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| I'd like to propose an addition to the for statement's syntax:
|
| for {variable} in {iterable} if {condition}:
|{block}
|
| which is equivalent to
|
| for {variable} in {iterable}:
|if not {condition}:
|continue
|{block}
Is this different from
for var in filter(lambda x: condition(x), iterable)):
?
| and
|
| for {variable} in filter(lambda: {condition}, iterable):
|{block}
IDLE 3.0a5
for i in filter(lambda i: i%2, range(10)):
print(i)
1
3
5
7
9
How was it again? One and only one way? :-)
--
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] Addition of pyprocessing module to standard lib.
Ulrich Berning wrote: I'm trying to use the vendor specific compilers whenever possible, because using gcc puts in additional dependencies (libgcc), I want to avoid, and even if I could live with these dependencies, it's not easy to get/build the 'right' gcc version, if your software also depends on other big packages like Qt and PyQt. I'm not using these platforms for my own pleasure (in fact, I would be happy if these platforms would disappear from the market), but as long as our customers use these platforms, we want to promise our software runs on those platforms. I have no problem with the fact that ctypes doesn't build on those platforms because I don't use it, but if more and more essential packages depend on ctypes, I'm running into trouble. PyOpenGL is an example of an extension, that moved completely from C-Source (SWIG generated) to ctypes usage. Hmm, perhaps the ctypes documentation could use a more prominent warning that it may not be available on some Unix platforms (HP-UX, AIX, IRIX), and that it may require the use of GCC rather than the vendor compiler on others (Solaris). At the moment, I suspect some projects may be switching to using it without realising the implications for cross-platform portability. 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] Module renaming and pickle mechanisms
On 2008-05-18 22:24, Brett Cannon wrote: On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan [EMAIL PROTECTED] wrote: M.-A. Lemburg wrote: Perhaps I have a misunderstanding of the reasoning behind doing the renaming in the 2.x branch, but it appears that the only reason is to get used to the new names. That's a rather low priority argument in comparison to the breakage the renaming will cause in the 2.x branch. I think this is the key point here. The possibility of breaking pickling compatibility never came up during the PEP 3108 discussions, so wasn't taken into account in deciding whether or not backporting the name changes was a good idea. I think it's pretty clear that the code needs to be moved back into the modules with the old names for 2.6. The only question is whether or not we put any effort into making the new stdlib organisation usable in 2.x, or just rely on 2to3 to fix it (note that the increasing the common subset argument doesn't really apply, since you can catch the import errors in order to try both names). Problem with this is it makes forward-porting revisions to 3.0 a PITA. By keeping the module names consistent between the versions merging a revision is just a matter of ``svnmerge merge`` with the usual 3.0-specific changes. Reverting the modules back to the old name will make forward-porting much more difficult as I don't think svn keeps rename information around (and thus map the old name to the new name in terms of diffs). svnmerge is written in Python, so wouldn't it be possible to add support for maintaining such renaming to that tool ? I don't think that an administrative problem such as forward- porting patches to 3.x warrants breakage in the 2.x branch. After all, the renaming was approached for Python 3.0 and not 2.6 *because* it introduces major breakage. AFAIR, the discussion on the stdlib-sig also didn't include the plan to backport such changes to 2.6. Otherwise, we would have hashed them out there. Alexandre's idea of teaching pickle the mapping of old names to new might be the best solution. We could have a flag to pickle that deactivates the renaming. Otherwise we could bump the pickle version number so that the new number doesn't do the mapping while the old versions to the implicit module mapping. And as Greg and Glpyh have pointed out, this is a problem that might need to be addressed in the future with some changes to our serialization method (I have no clue how since I don't deal with pickle very much). It is possible to make pickle aware of the module renames, but that doesn't solve problems with other forms of serialization or use of the .__module__ attribute in general. Why can't we just provide a from __future__ import renamed_modules which then provides all the new name to old name mappings in some form (e.g. module proxies or whatever) and leave the existing modules in 2.x untouched ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 19 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/ 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 ___ 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] Module renaming and pickle mechanisms
M.-A. Lemburg wrote: I don't think that an administrative problem such as forward- porting patches to 3.x warrants breakage in the 2.x branch. After all, the renaming was approached for Python 3.0 and not 2.6 *because* it introduces major breakage. AFAIR, the discussion on the stdlib-sig also didn't include the plan to backport such changes to 2.6. Otherwise, we would have hashed them out there. I think MAL is 100% correct here (and I expect Raymond will chime in to support him at some point as well). Taking the time to fix out mistake may mean we need to do another alpha rather than being able to go into the betas as planned, but I think that would be a much better option than breaking any 2.x code that relies on __module__ staying the same across releases. 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] Module renaming and pickle mechanisms
Nick Coghlan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | M.-A. Lemburg wrote: | I don't think that an administrative problem such as forward- | porting patches to 3.x warrants breakage in the 2.x branch. | | After all, the renaming was approached for Python 3.0 and not | 2.6 *because* it introduces major breakage. | | AFAIR, the discussion on the stdlib-sig also didn't include the | plan to backport such changes to 2.6. Otherwise, we would have | hashed them out there. | | I think MAL is 100% correct here (and I expect Raymond will chime in to | support him at some point as well). For what little it's worth, I was surprised too that the 3.0 renames were backported as thr default versions. It strikes me as possibly a 'bridge too far' ;-). tjr ___ 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] Conditional For Statements
On Mon, 19 May 2008 08:42:29 pm Lennart Regebro wrote: How was it again? One and only one way? :-) Certainly not. What on earth gave you the idea that that ridiculous statement is a Python philosophy? I know some Perl developers like to contrast the supposed flexibility of Perl (more than one way to do it) with the imagined poverty of Python, but that really is a silly claim to make about any Turing Complete language. If nothing else, any programming language that lets you perform arithmetic would not be so restrictive: x = (1+2)*3 + 3*3 x = (3+2)*3 + 1*3 Which one should the compiler prohibit? I strongly suggest that you look at the Zen of Python: import this The Zen of Python, by Tim Peters ... There should be one-- and preferably only one --obvious way to do it. There should be ONE OBVIOUS way to do it, not only one way. -- Steven ___ 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] Symbolic errno values in error messages
Alexandre Vassalotti [EMAIL PROTECTED] writes:
So now I am not sure what OP is proposing. Do you want to replace 21
with EISDIR in the above?
Yes, that's what I had in mind.
Then, check out EnvironmentError_str in Objects/exceptions.c. You
should be able import the errno module and fetch its errorcode
dictionary.
It wasn't as hard as I expected. It's the first time that I play with
the Python C API; I didn't expect the API to be that high level.
I attached a patch to convert errno to its symbolic value when an
EnvironmentError is printed. Should attach it to a ticket on
bugs.python.org?
I'm sure there is a style guide like PEP-8 for C code, feel free to
point me to it because my patch is probably not fully style compliant.
With Emacs, doing
M-x c-set-style python
doesn't seems to do the right thing. Are you all using a bunch of
shared settings in you .emacs files?
--
Yannick Gingras
Index: Objects/exceptions.c
===
--- Objects/exceptions.c (revision 63365)
+++ Objects/exceptions.c (working copy)
@@ -604,13 +604,32 @@
EnvironmentError_str(PyEnvironmentErrorObject *self)
{
PyObject *rtnval = NULL;
+PyObject *errnomod = NULL;
+PyObject *errorcode_dict = NULL;
+PyObject *errno_str = NULL;
+PyObject *printed_errno = NULL;
+/* Extract the symbolic value for errno.
+ Ex: use 'ENOTDIR' instead of 20 */
+if (self-myerrno) {
+errnomod = PyImport_ImportModule(errno);
+if (errnomod == NULL)
+ Py_FatalError(Can't import errno module.);
+
+ errorcode_dict = PyObject_GetAttrString(errnomod, errorcode);
+ if (errorcode_dict == NULL)
+ Py_FatalError(Can't access errorcode dict.);
+
+ errno_str = PyDict_GetItem(errorcode_dict, self-myerrno);
+ printed_errno = errno_str ? errno_str : self-myerrno;
+}
+
if (self-filename) {
PyObject *fmt;
PyObject *repr;
PyObject *tuple;
-fmt = PyString_FromString([Errno %s] %s: %s);
+fmt = PyString_FromString([Errno=%s] %s: %s);
if (!fmt)
return NULL;
@@ -627,8 +646,8 @@
}
if (self-myerrno) {
-Py_INCREF(self-myerrno);
-PyTuple_SET_ITEM(tuple, 0, self-myerrno);
+Py_INCREF(printed_errno);
+PyTuple_SET_ITEM(tuple, 0, printed_errno);
}
else {
Py_INCREF(Py_None);
@@ -654,7 +673,7 @@
PyObject *fmt;
PyObject *tuple;
-fmt = PyString_FromString([Errno %s] %s);
+fmt = PyString_FromString([Errno=%s] %s);
if (!fmt)
return NULL;
@@ -665,8 +684,8 @@
}
if (self-myerrno) {
-Py_INCREF(self-myerrno);
-PyTuple_SET_ITEM(tuple, 0, self-myerrno);
+Py_INCREF(printed_errno);
+PyTuple_SET_ITEM(tuple, 0, printed_errno);
}
else {
Py_INCREF(Py_None);
@@ -688,7 +707,9 @@
}
else
rtnval = BaseException_str((PyBaseExceptionObject *)self);
-
+
+Py_XDECREF(errnomod);
+Py_XDECREF(errorcode_dict);
return rtnval;
}
___
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] Module renaming and pickle mechanisms
Nick writes: M.-A. Lemburg wrote: I don't think that an administrative problem such as forward- porting patches to 3.x warrants breakage in the 2.x branch. After all, the renaming was approached for Python 3.0 and not 2.6 *because* it introduces major breakage. AFAIR, the discussion on the stdlib-sig also didn't include the plan to backport such changes to 2.6. Otherwise, we would have hashed them out there. I think MAL is 100% correct here (and I expect Raymond will chime in to support him at some point as well). And until then, a +1 for MAL's position from me as well. 2.x should be quite conservative about such changes... Cheers, Mark ___ 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] Conditional For Statements
Ryan Hitchman wrote:
This would make the syntax closer to that of generators, which have
'for variable in iterable if condition',
Incorporating the filter condition into the list comprehension syntax
(and later into generator expressions) is necessary because they need to
be written as a single expression. The same doesn't hold true for loop
filters: it is quite possible to keep the looping and filtering concerns
separated into different statements, and there's no compelling reason
for merging them.
would improve code clarity by increased brevity
Increased brevity != improved code clarity (in fact, being too terse can
obfuscate things - just look at Perl)
not negating boolean expressions.
Except, of course, for those cases where it is easier to define the
condition for items to skip than it is to define the condition for items
to include.
Following are examples of current code with what the new code would
be, taken from the Python 3.0a5 tarball.
Using just the standard idiom of a separate if statement to do the
filtering:
for (x, y), cell in self.cells.items():
if x = 0 or y = 0:
continue
# ...
for modname in modnames:
if not modname or '.' in modname:
continue
# ...
for w in wafter:
if dict.get(w):
continue
# ...
for K,V in items:
if V == : continue
if K not in attrs: continue
# ...
for opensslFuncName in dir(_hashlib):
if opensslFuncName.startswith('openssl_'):
continue
# ...
I'm not really seeing how the readability of any of those examples is
enhanced by being able to merge the filter condition into the first line
of the for loop. The one example which was already written that way
through the use of filter() is actually easy to read with the addition
of the vertical whitespace needed for the idiomatic form.
The separate statement approach also scales far more cleanly to more
complex filter conditions. For example, some code of mine includes a
loop that looks like:
for name in dirnames:
if not os.path.exists(name):
continue
if not os.path.isdir(name):
continue
# Process named directory
This conveys the order of checks far more clearly than would be the case
if the os.path calls were hidden on the end of the loop invocation.
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] Conditional For Statements
On Mon, May 19, 2008 at 5:33 AM, Steven D'Aprano [EMAIL PROTECTED] wrote:
...
import this
The Zen of Python, by Tim Peters
...
There should be one-- and preferably only one --obvious way to do it.
There should be ONE OBVIOUS way to do it, not only one way.
The only one way phrasing is in the Spirit of C section of the ISO
C Standard `Rationale' (non-normative, but highly informative),
specifically in point four, provide only one way to do an operation.
I contend that the somewhat different phrasing is somewhat accidental
and not particularly relevant: the *intent* of this *language design
guideline* is exactly the same (Tim was writing on his own, while the
C Standard was written by a committee, so it's hardly surprising that
the Standard's wording is drier and less funny than Tim's;-). IOW,
I've often argued that this is a deep commonality between the design
philosophy of C and Python (together with trust the programmer and
keep the language small and simple, two more points in the Spirit
of C section) which makes them conceptually closer to each other
than C is to languages sharing more of its syntax, from C++ to
Javascript; it should be particularly easy to see the contrast with
languages deliberately designed to provide multiple equivalent
synonyms (such as foo.size and foo.length meaning the same thing in
Ruby) or going out of their way to provide multiple equivalent syntax
approaches for exactly the same semantics (such as Cobol's ADD A TO B
GIVING C and C = A + B, or SQL's explicit [INNER] JOIN form and the
equivalent form where the inner join is left implicit in the WHERE
clause).
A design guideline is not a strict rule -- e.g., every C programmer
has met situations where a while statement, and a for statement with
some of the three subparts in the control clause omitted, can both
make sense, and of course every time you write within your loop some
if(condition) continue you wonder if in this case it might not be
better to instead use if(!condition) { ... } around the rest of the
loop's body, etc, etc -- so much for only one way, as the various
ways to perform elementary operations can click together in a large
number of combinations and permutations; and adding obvious would
not help much either, since both alternatives can easily happen to be
equally obvious. Python is just in the same situation. Nevertheless,
keeping the guideline firmly in mind (e.g., eschewing synonyms in APIs
you design that provide no added value beyond that of catering to
different tastes or to a meta-taste for variety over uniformity;-) is
still a helpful heuristic -- with or without the obvious word (i.e.,
whether you're working with C, which doesn't have the obvious in its
phrasing of the principle, or with Python, which does).
Alex
___
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] oct and hex Py3k warnings
On Sat, May 17, 2008 at 5:42 PM, Benjamin Peterson [EMAIL PROTECTED] wrote: I know Guido has opposed adding Py3k warnings to oct and hex for practical reasons, but I would like to make the case again. future_buitlins oct and hex will give you the correct Py3k behavior, but 2to3 can't convert old hex and oct usage to the new ones. That's why is would be helpful to warn about it and encourage people to import from future_builtins. But the difference only matters for people who are parsing the output, right? I think they'd find out soon enough. I'm still -1. -- --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] Module renaming and pickle mechanisms
Nick writes: M.-A. Lemburg wrote: I don't think that an administrative problem such as forward- porting patches to 3.x warrants breakage in the 2.x branch. After all, the renaming was approached for Python 3.0 and not 2.6 *because* it introduces major breakage. AFAIR, the discussion on the stdlib-sig also didn't include the plan to backport such changes to 2.6. Otherwise, we would have hashed them out there. I think MAL is 100% correct here (and I expect Raymond will chime in to support him at some point as well). And until then, a +1 for MAL's position from me as well. 2.x should be quite conservative about such changes... I concur. 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] Module renaming and pickle mechanisms
On Mon, May 19, 2008 at 2:08 PM, M.-A. Lemburg [EMAIL PROTECTED] wrote: Why can't we just provide a from __future__ import renamed_modules which then provides all the new name to old name mappings in some form (e.g. module proxies or whatever) and leave the existing modules in 2.x untouched ? If I understand this correctly, the pickles would then be compatible between 2.6 and 2.5, unless you did from __future__ import renamed_modules, which would make the pickles compatible between 2.6 and 3.0. This sounds like the best solution to me, especially if the old names are still available after the future import, as all that would then be needed it to repickle all the pickles to convert from 2.5 to 3.0 pickles, right? So, if I understood this correctly, that sounds like a perfect solution. :) -- 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] Module renaming and pickle mechanisms
On Mon, May 19, 2008 at 8:39 AM, Raymond Hettinger [EMAIL PROTECTED] wrote: Nick writes: M.-A. Lemburg wrote: I don't think that an administrative problem such as forward- porting patches to 3.x warrants breakage in the 2.x branch. After all, the renaming was approached for Python 3.0 and not 2.6 *because* it introduces major breakage. AFAIR, the discussion on the stdlib-sig also didn't include the plan to backport such changes to 2.6. Otherwise, we would have hashed them out there. I think MAL is 100% correct here (and I expect Raymond will chime in to support him at some point as well). And until then, a +1 for MAL's position from me as well. 2.x should be quite conservative about such changes... I concur. And a me too post about being conservative by default as well. I'm not sure how effective a from __future__ import renamed_modules would be, since such future imports are meant to affect the semantics of the *current* module only, whereas which name to use when pickling a module reference is most likely a global choice. So perhaps some other way to changing the default behavior globally would be more appropriate. Assuming it's really the pickle module that needs to know about this, how about making this a per-Pickler-instance flag? if you wanted to write 3.0 compatible pickles you'd have to do something like p = pikle.Pickler() p.use_new_module_names(True) pkl = p.dump(object) We could supply an extra flag to the dump() and dumps() convenience functions as well. -- --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] Addition of pyprocessing module to standard lib.
Hmm, perhaps the ctypes documentation could use a more prominent warning that it may not be available on some Unix platforms (HP-UX, AIX, IRIX), and that it may require the use of GCC rather than the vendor compiler on others (Solaris). At the moment, I suspect some projects may be switching to using it without realising the implications for cross-platform portability. I think it's a tad more problematic. As other modules, both in and out of the standard library, move to use ctypes, it implies that *Python* isn't supported on those combinations. Personally, that's fine with me (as long as there's a workaround for Solaris!), but I think that Ulrich is right in saying this should be more prominent. Bill ___ 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] Addition of pyprocessing module to standard lib.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A.M. Kuchling wrote: | Python development doesn't seem to have any volunteers who use AIX or | HP-UX and can fix bugs on these platforms. Searching bugs.python.org, | I find about 20 open AIX issues, 4 or 5 HP-UX issues, 6 IRIX bugs, and | about 15 Solaris bugs; but I don't know if any of the developers here | use these platforms. (There is a Solaris buildbot, at least.) I develop under Solaris 10 x86. My environment is 64 bits, but my python deployment/development in 32 bits. I could try 64 bits if asked for. I can look at any Solaris related issue. Just ask. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ ~ _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDGz2Jlgi5GaxT1NAQIx6wP+NudycEV/nkaCEGLUwnj5BP19urVURedj x6Udb690/Hon/fv6tkplIw5pLramdv3hH8KKsxWr+kzrp4iHUZ7JPyItC0DBXImQ 3wRrV7Yhu1nVmFV2qm5Kdbu8+x7fCiWnzESLzQmIjEKQd0dlO2vStXUNmndoJ21h pDwIW0bUriA= =jbHH -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] Conditional For Statements
On Sun, May 21, 2006 at 17:38:49 CEST, Guido van Rossum guido at python.org wrote ... Also, it would be a parsing conflict for the new conditional expressions (x if T else y). ... That's all I needed to know. Sorry, everyone, I'll try not to waste your time in the future. ___ 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] Addition of pyprocessing module to standard lib.
Bill Janssen schrieb: Hmm, perhaps the ctypes documentation could use a more prominent warning that it may not be available on some Unix platforms (HP-UX, AIX, IRIX), and that it may require the use of GCC rather than the vendor compiler on others (Solaris). At the moment, I suspect some projects may be switching to using it without realising the implications for cross-platform portability. I think it's a tad more problematic. As other modules, both in and out of the standard library, move to use ctypes, it implies that *Python* isn't supported on those combinations. Personally, that's fine with me (as long as there's a workaround for Solaris!), but I think that Ulrich is right in saying this should be more prominent. I won't object if anyone adds this notice to the Python docs, so please go ahead. A table of platforms (on the wiki?) where ctypes builds/works or does not may also be helpful. Myself I would rather spend my energy to make ctypes more portable, within my skills and the platforms I have access to. Thomas ___ 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] Module renaming and pickle mechanisms
On Mon, May 19, 2008 at 9:22 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 8:39 AM, Raymond Hettinger [EMAIL PROTECTED] wrote: Nick writes: M.-A. Lemburg wrote: I don't think that an administrative problem such as forward- porting patches to 3.x warrants breakage in the 2.x branch. After all, the renaming was approached for Python 3.0 and not 2.6 *because* it introduces major breakage. AFAIR, the discussion on the stdlib-sig also didn't include the plan to backport such changes to 2.6. Otherwise, we would have hashed them out there. I think MAL is 100% correct here (and I expect Raymond will chime in to support him at some point as well). And until then, a +1 for MAL's position from me as well. 2.x should be quite conservative about such changes... I concur. And a me too post about being conservative by default as well. I will update the PEP some time today. I think if we take MAL's idea of doing the __dict__.update() trick and suppress the Py3K warnings then it should be able to keep the warnings (it will require a very specific filter). Otherwise the Py3K warnings will just have to go. -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] Module renaming and pickle mechanisms
On Mon, May 19, 2008 at 5:08 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2008-05-18 22:24, Brett Cannon wrote: On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan [EMAIL PROTECTED] wrote: M.-A. Lemburg wrote: Perhaps I have a misunderstanding of the reasoning behind doing the renaming in the 2.x branch, but it appears that the only reason is to get used to the new names. That's a rather low priority argument in comparison to the breakage the renaming will cause in the 2.x branch. I think this is the key point here. The possibility of breaking pickling compatibility never came up during the PEP 3108 discussions, so wasn't taken into account in deciding whether or not backporting the name changes was a good idea. I think it's pretty clear that the code needs to be moved back into the modules with the old names for 2.6. The only question is whether or not we put any effort into making the new stdlib organisation usable in 2.x, or just rely on 2to3 to fix it (note that the increasing the common subset argument doesn't really apply, since you can catch the import errors in order to try both names). Problem with this is it makes forward-porting revisions to 3.0 a PITA. By keeping the module names consistent between the versions merging a revision is just a matter of ``svnmerge merge`` with the usual 3.0-specific changes. Reverting the modules back to the old name will make forward-porting much more difficult as I don't think svn keeps rename information around (and thus map the old name to the new name in terms of diffs). svnmerge is written in Python, so wouldn't it be possible to add support for maintaining such renaming to that tool ? Don't know, possibly. But I am not about to try to figure out. I don't think that an administrative problem such as forward- porting patches to 3.x warrants breakage in the 2.x branch. That's why I suggested changing pickle to deal with the rename, but obviously I am in the minority in that idea. After all, the renaming was approached for Python 3.0 and not 2.6 *because* it introduces major breakage. AFAIR, the discussion on the stdlib-sig also didn't include the plan to backport such changes to 2.6. Otherwise, we would have hashed them out there. Never came up. Alexandre's idea of teaching pickle the mapping of old names to new might be the best solution. We could have a flag to pickle that deactivates the renaming. Otherwise we could bump the pickle version number so that the new number doesn't do the mapping while the old versions to the implicit module mapping. And as Greg and Glpyh have pointed out, this is a problem that might need to be addressed in the future with some changes to our serialization method (I have no clue how since I don't deal with pickle very much). It is possible to make pickle aware of the module renames, but that doesn't solve problems with other forms of serialization or use of the .__module__ attribute in general. Why can't we just provide a from __future__ import renamed_modules which then provides all the new name to old name mappings in some form (e.g. module proxies or whatever) and leave the existing modules in 2.x untouched ? I have started a discussion on the stdlib SIG on how to handle this, so I will defer this discussion to there. But one thing that needs to be decided is if we are ever going to allow ourselves to rename modules without a major version bump, and if so how to deal with this problem. I would hope we don't have to wait another eight years before there is another chance to shift things around if it becomes apparent that some new package should be introduced since 2to3 gives us a very nice way to handle the mechanical aspect of porting code. -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] Module renaming and pickle mechanisms
On Mon, May 19, 2008 at 7:08 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2008-05-18 22:24, Brett Cannon wrote: On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan [EMAIL PROTECTED] wrote: M.-A. Lemburg wrote: Perhaps I have a misunderstanding of the reasoning behind doing the renaming in the 2.x branch, but it appears that the only reason is to get used to the new names. That's a rather low priority argument in comparison to the breakage the renaming will cause in the 2.x branch. I think this is the key point here. The possibility of breaking pickling compatibility never came up during the PEP 3108 discussions, so wasn't taken into account in deciding whether or not backporting the name changes was a good idea. I think it's pretty clear that the code needs to be moved back into the modules with the old names for 2.6. The only question is whether or not we put any effort into making the new stdlib organisation usable in 2.x, or just rely on 2to3 to fix it (note that the increasing the common subset argument doesn't really apply, since you can catch the import errors in order to try both names). Problem with this is it makes forward-porting revisions to 3.0 a PITA. By keeping the module names consistent between the versions merging a revision is just a matter of ``svnmerge merge`` with the usual 3.0-specific changes. Reverting the modules back to the old name will make forward-porting much more difficult as I don't think svn keeps rename information around (and thus map the old name to the new name in terms of diffs). svnmerge is written in Python, so wouldn't it be possible to add support for maintaining such renaming to that tool ? svnmerge.py is mostly a wrapper over svn merge, and svn merge can't handle it, so I don't think is easily possible. I don't think that an administrative problem such as forward- porting patches to 3.x warrants breakage in the 2.x branch. I am a bit worried for the sanity of the Merger, though. Merges into non-existent files are skipped automatically, so it doesn't make life any easier. shameless_advertisingBazaar can handle renames correctly./shameless_advertising -- 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] Importing bsddb 4.6.21; with or without AES encryption?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trent Nelson wrote: | I downloaded the source that includes AES encryption, for no reason | other than it was first on the list. I'm now wondering if we should | only be importing the 'NC' source that doesn't contain any | encryption? Jesus, does pybsddb use any of the Berkeley DB | encryption facilities? Would anything break if we built the | bsddb module without encryption? Yes, pybsddb3 4.6.4 supports cryptography if the underlying Berkeley DB library is crypto enabled. In principle, you can compile BDB without crypto, and pybsddb3 should work, but you would lose ability to open any DB formerly created using page encryption or page checksum. Export laws aside, we better compile with crypto :). Details: http://www.jcea.es/programacion/pybsddb_doc/dbenv.html#set_encrypt http://www.oracle.com/technology/documentation/berkeley-db/xml/api_c/db_set_flags.html#DB_CHKSUM - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ ~ _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDIDWplgi5GaxT1NAQKaagP+Myn6t364B9cVMUtlKjTIX1LBZkkEG7SX pv+hjUZ68r0Suw8SkhXnBbL2Ek3/yFhvNHH8qAZvEtRGsFGmKiNXccn9Ce3oy0me rAYhuuICleAUJ8RO8FZz+sGK3SR4kITrqnGfMnG46u0rXDQy82NSRW2+uWz/D96d U+X/wfV2HgQ= =io+q -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
[Python-Dev] Unaccompanied Patch
Hi all, I created a patch on 2007-08-15: http://bugs.python.org/issue1775025 I wonder, will it just stay in patches unnoticed until it has its very own associated bug report to keep it company? Thanks, Graham ___ 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] Module renaming and pickle mechanisms
On Mon, May 19, 2008 at 3:26 PM, Benjamin Peterson [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 7:08 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2008-05-18 22:24, Brett Cannon wrote: On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan [EMAIL PROTECTED] wrote: M.-A. Lemburg wrote: Perhaps I have a misunderstanding of the reasoning behind doing the renaming in the 2.x branch, but it appears that the only reason is to get used to the new names. That's a rather low priority argument in comparison to the breakage the renaming will cause in the 2.x branch. I think this is the key point here. The possibility of breaking pickling compatibility never came up during the PEP 3108 discussions, so wasn't taken into account in deciding whether or not backporting the name changes was a good idea. I think it's pretty clear that the code needs to be moved back into the modules with the old names for 2.6. The only question is whether or not we put any effort into making the new stdlib organisation usable in 2.x, or just rely on 2to3 to fix it (note that the increasing the common subset argument doesn't really apply, since you can catch the import errors in order to try both names). Problem with this is it makes forward-porting revisions to 3.0 a PITA. By keeping the module names consistent between the versions merging a revision is just a matter of ``svnmerge merge`` with the usual 3.0-specific changes. Reverting the modules back to the old name will make forward-porting much more difficult as I don't think svn keeps rename information around (and thus map the old name to the new name in terms of diffs). svnmerge is written in Python, so wouldn't it be possible to add support for maintaining such renaming to that tool ? svnmerge.py is mostly a wrapper over svn merge, and svn merge can't handle it, so I don't think is easily possible. I think MAL was suggesting add some property that kept track of skipped merges or something. I don't think that an administrative problem such as forward- porting patches to 3.x warrants breakage in the 2.x branch. I am a bit worried for the sanity of the Merger, though. Merges into non-existent files are skipped automatically, so it doesn't make life any easier. It will either have to be done in 2.6 and the immediately forward-ported or done in 3.0 and backported. I will follow the latter IF I feel like bothering with the backport. shameless_advertisingBazaar can handle renames correctly./shameless_advertising Yeah, yeah. One thing at a time. -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] Unaccompanied Patch
On Mon, May 19, 2008 at 3:46 PM, Graham Horler [EMAIL PROTECTED] wrote: Hi all, I created a patch on 2007-08-15: http://bugs.python.org/issue1775025 I wonder, will it just stay in patches unnoticed until it has its very own associated bug report to keep it company? Being a patch does not mean it is ignore (actually, it raises the chance it will be noticed). It's just that developer time is limited and so someone has to just take enough interest in the patch to review it, apply it, etc. We no longer distinguish issues between patches and bugs; when a bug gets an attached patch we just set the proper keyword. So creating a separate issue will just lead to it being closed as being superceded by the patch. -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] Unaccompanied Patch
On Mon, May 19, 2008 at 5:46 PM, Graham Horler [EMAIL PROTECTED] wrote: Hi all, I created a patch on 2007-08-15: http://bugs.python.org/issue1775025 I wonder, will it just stay in patches unnoticed until it has its very own associated bug report to keep it company? At the moment, I only see a doc patch. -- 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] Unaccompanied Patch
On Mon, May 19, 2008 at 6:00 PM, Benjamin Peterson [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 5:46 PM, Graham Horler [EMAIL PROTECTED] wrote: Hi all, I created a patch on 2007-08-15: http://bugs.python.org/issue1775025 I wonder, will it just stay in patches unnoticed until it has its very own associated bug report to keep it company? At the moment, I only see a doc patch. Sorry, that didn't come out they way I wanted it to. I meant that the doc patch will have to be converted to reST. -- 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] buffer interface for C extensions
On Sun, 18 May 2008 22:59:05 +, Dan Lenski wrote:
So here's what I don't understand. Why doesn't the t# argument
specifier support read-write buffers as well as read-only buffers?
Aren't read-write buffers a *superset* of read-only buffers?? Is there
something I'm doing wrong or a quick fix to get this to work
appropriately?
So... I've answered my own question on this. I had a look in getargs.c,
and apparently the t# argument specifier only accepts *character-based*
readable buffers.
Is there any chance anyone of adding an argument specifier for readable
buffers in general? Say, r#?
Can anyone explain to me the rationale for having some data type support
the readable buffer interface, but /NOT/ the character-based buffer
interface? I can't find any information that explains the fundamental
distinction between the two... and I don't see why array('B') shouldn't
support both.
Dan
___
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] Addition of pyprocessing module to standard lib.
If you can run a pure Python module that does not depend on any C extension, then that platform has the support needed to run Python. This is certainly a point of view. One that many end-users wouldn't understand :-). Bill ___ 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] Addition of pyprocessing module to standard lib.
On Mon, May 19, 2008 at 5:15 PM, Bill Janssen [EMAIL PROTECTED] wrote: If you can run a pure Python module that does not depend on any C extension, then that platform has the support needed to run Python. This is certainly a point of view. One that many end-users wouldn't understand :-). Perhaps, but it's clear-cut. Is OS X not properly supported because it can't run the _winreg module? I just don't like labeling a platform as unsupported just because ctypes doesn't compile on it. -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] Addition of pyprocessing module to standard lib.
On Mon, May 19, 2008 at 5:15 PM, Bill Janssen [EMAIL PROTECTED] wrote: If you can run a pure Python module that does not depend on any C extension, then that platform has the support needed to run Python. This is certainly a point of view. One that many end-users wouldn't understand :-). Perhaps, but it's clear-cut. Is OS X not properly supported because it can't run the _winreg module? I just don't like labeling a platform as unsupported just because ctypes doesn't compile on it. I assume _winreg runs everywhere Python is said to run, and there's a Windows registry to examine, so I think it's a different kettle of fish. ctypes doesn't run everywhere Python is said to run, and there are dynamic libraries to call into. I think it would be great if we could get some AIX, HP-UX, and Solaris boxes for Thomas to work on. What would motivate IBM, H-P, and Sun to donate such gear? Perhaps each of the companies have an office somewhere that could help with this resource allocation? For instance, talking to the AIX Collaboration Center of IBM ([EMAIL PROTECTED])? And these are all SYSV derivatives, aren't they? So perhaps it's some common fix for all three? Bill ___ 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] Addition of pyprocessing module to standard lib.
Bill Janssen wrote: On Mon, May 19, 2008 at 5:15 PM, Bill Janssen [EMAIL PROTECTED] wrote: If you can run a pure Python module that does not depend on any C extension, then that platform has the support needed to run Python. This is certainly a point of view. One that many end-users wouldn't understand :-). Perhaps, but it's clear-cut. Is OS X not properly supported because it can't run the _winreg module? I just don't like labeling a platform as unsupported just because ctypes doesn't compile on it. I assume _winreg runs everywhere Python is said to run, and there's a Windows registry to examine, so I think it's a different kettle of fish. ctypes doesn't run everywhere Python is said to run, and there are dynamic libraries to call into. I think it would be great if we could get some AIX, HP-UX, and Solaris boxes for Thomas to work on. What would motivate IBM, H-P, and Sun to donate such gear? Perhaps each of the companies have an office somewhere that could help with this resource allocation? For instance, talking to the AIX Collaboration Center of IBM ([EMAIL PROTECTED])? And these are all SYSV derivatives, aren't they? So perhaps it's some common fix for all three? OK, I know people in Sun and possibly H-P I could ask, and I may have an arm or two to twist to get to IBM. But worst-case, what budget would the infrastructure committee need for the hardware and (more importantly) if the hardware materialized, would there be manpower to maintain the platforms as Python supported? The more libraries that use ctypes to call into native functionality, the more important it becomes to have ctypes run, even if only to implement platform-specific functionality on the given platforms. I would like being able to call a wide range of native libraries to be a Python claim on all platforms, even when the native libraries are platform-proprietary. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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] Unaccompanied Patch
Benjamin Peterson wrote: On Mon, May 19, 2008 at 6:00 PM, Benjamin Peterson [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 5:46 PM, Graham Horler [EMAIL PROTECTED] wrote: Hi all, I created a patch on 2007-08-15: http://bugs.python.org/issue1775025 I wonder, will it just stay in patches unnoticed until it has its very own associated bug report to keep it company? At the moment, I only see a doc patch. Sorry, that didn't come out they way I wanted it to. I meant that the doc patch will have to be converted to reST. Well, looky here: zipfile_62920.diff grahamh, 2008-05-19 23:49 Updated + doc - reST That was quick. I'm not in a position to svn update were I am. Looks like someone's paying attention, though. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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] Module renaming and pickle mechanisms
On Mon, May 19, 2008 at 12:26 PM, Brett Cannon [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 5:08 AM, M.-A. Lemburg [EMAIL PROTECTED] wrote: On 2008-05-18 22:24, Brett Cannon wrote: On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan [EMAIL PROTECTED] wrote: M.-A. Lemburg wrote: Perhaps I have a misunderstanding of the reasoning behind doing the renaming in the 2.x branch, but it appears that the only reason is to get used to the new names. That's a rather low priority argument in comparison to the breakage the renaming will cause in the 2.x branch. I think this is the key point here. The possibility of breaking pickling compatibility never came up during the PEP 3108 discussions, so wasn't taken into account in deciding whether or not backporting the name changes was a good idea. I think it's pretty clear that the code needs to be moved back into the modules with the old names for 2.6. The only question is whether or not we put any effort into making the new stdlib organisation usable in 2.x, or just rely on 2to3 to fix it (note that the increasing the common subset argument doesn't really apply, since you can catch the import errors in order to try both names). Problem with this is it makes forward-porting revisions to 3.0 a PITA. By keeping the module names consistent between the versions merging a revision is just a matter of ``svnmerge merge`` with the usual 3.0-specific changes. Reverting the modules back to the old name will make forward-porting much more difficult as I don't think svn keeps rename information around (and thus map the old name to the new name in terms of diffs). svnmerge is written in Python, so wouldn't it be possible to add support for maintaining such renaming to that tool ? Don't know, possibly. But I am not about to try to figure out. I don't think that an administrative problem such as forward- porting patches to 3.x warrants breakage in the 2.x branch. That's why I suggested changing pickle to deal with the rename, but obviously I am in the minority in that idea. After all, the renaming was approached for Python 3.0 and not 2.6 *because* it introduces major breakage. AFAIR, the discussion on the stdlib-sig also didn't include the plan to backport such changes to 2.6. Otherwise, we would have hashed them out there. Never came up. Alexandre's idea of teaching pickle the mapping of old names to new might be the best solution. We could have a flag to pickle that deactivates the renaming. Otherwise we could bump the pickle version number so that the new number doesn't do the mapping while the old versions to the implicit module mapping. And as Greg and Glpyh have pointed out, this is a problem that might need to be addressed in the future with some changes to our serialization method (I have no clue how since I don't deal with pickle very much). It is possible to make pickle aware of the module renames, but that doesn't solve problems with other forms of serialization or use of the .__module__ attribute in general. Why can't we just provide a from __future__ import renamed_modules which then provides all the new name to old name mappings in some form (e.g. module proxies or whatever) and leave the existing modules in 2.x untouched ? I have started a discussion on the stdlib SIG on how to handle this, so I will defer this discussion to there. The decision was made (by me) to just revert all of the renames in 2.6. A note will be in the docs stating the rename, but otherwise 2to3 will be relied upon for all transitions from old names to new names. I have updated the PEP to note about which modules need to be reverted and the new steps to rename a module, and added/re-opened the appropriate issues (all attached to issue 2775). -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
