[Python-Dev] negative PyLong integer -> unsigned integer, TypeError or OverflowError?
While hacking on Cython to make it recognize 'size_t' as a pre-defined
C integral type, I've found somethig that seems to be (pretty small)
inconsistency.
At Objects/longobject.c, you should see that in almost all cases
OverflowError is raised when a unsigned integral is requested from a
negative PyLong. However, See this one:
int
_PyLong_AsByteArray(PyLongObject* v,
unsigned char* bytes, size_t n,
int little_endian, int is_signed)
{
<...>
if (!is_signed) {
PyErr_SetString(PyExc_TypeError,
"can't convert negative long to unsigned");
return -1;
}
<...>
}
Does it make sense to change that code to raise OverflowError?
--
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] negative PyLong integer -> unsigned integer, TypeError or OverflowError?
Done, http://bugs.python.org/issue5175
On Fri, Feb 6, 2009 at 6:25 PM, Mark Dickinson wrote:
> On Fri, Feb 6, 2009 at 9:04 PM, Lisandro Dalcin wrote:
>> At Objects/longobject.c, you should see that in almost all cases
>> OverflowError is raised when a unsigned integral is requested from a
>> negative PyLong. However, See this one:
>> [...]
>> if (!is_signed) {
>> PyErr_SetString(PyExc_TypeError,
>> "can't convert negative long to unsigned");
>> return -1;
>> }
>
> I agree that TypeError seems wrong here.
>
> Please could you file a bug report at bugs.python.org?
>
> Mark
>
--
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
[Python-Dev] Adding T_SIZET to structmember.h
After a rather long hacking on Cython in order to support 'Py_ssize_t' and 'size_t' the right way, I would like to propose the inclusion of a new T_SIZET in structmember.h in order to suport 'size_t' struct fields with PyMemberDef. Would such addition be accepted for 2.7 and 3.1? -- 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] Adding T_SIZET to structmember.h
Done, http://bugs.python.org/issue5248 Mark, the patch is not trivial, I cannot spend time on this until this is accepted. Hope you understand. On Fri, Feb 13, 2009 at 1:15 PM, Mark Dickinson wrote: > On Thu, Feb 12, 2009 at 8:42 PM, Lisandro Dalcin wrote: >> I would like to propose the inclusion of a new T_SIZET in structmember.h >> in order to suport 'size_t' struct fields with PyMemberDef. Would such >> addition be accepted for 2.7 and 3.1? > > Please open a feature request at bugs.python.org, and we'll find out! A > working patch would probably be helpful. > > (It sounds like a sensible addition to me.) > > Mark > -- 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] Adding T_SIZET to structmember.h
Martin, I was not clear enough. Please, just tell me: Do you believe that this addition do make sense? Would you reject it for some reason (other than a bad patch) ? On Fri, Feb 13, 2009 at 10:35 PM, "Martin v. Löwis" wrote: >> Mark, the patch is not trivial, I cannot spend time on this until this >> is accepted. Hope you understand. > > I certainly do understand. So it's likely not going to happen. > > Regards, > Martin > -- 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] Let's update CObject API so it is safe and regular!
On Wed, Apr 1, 2009 at 11:58 PM, Larry Hastings wrote: > > Guido van Rossum wrote: >> >> Yeah, any two CAPI objects can be used to play this trick, as long as >> you have some place that calls them. :-( > > FWIW, I can't take credit for this observation. Neal Norwitz threw me at > this class of problem at the Py3k sprints in August 2007 at Google Mountain > View, specifically with curses, though the approach he suggested then was > removing the CObjects. > IMHO, removing them would be a really bad idea... PyCObject's are the documented recommended way to make ext modules export its API's, and that works pretty well in practice, and more well now with your approach. > >> So what's your solution? If it was me I'd change the API to put the >> full module name and variable name of the object inside the object and >> have the IMPORT call check that. Then you can only have crashes if >> some extension module cheats, and surely there are many other ways >> that C extensions can cheat, so that doesn't bother me. :) > > My proposed API requires that the creator of the CObject pass in a "type" > string, which must be of nonzero length, and the caller must pass in a > matching string. I figured that was easy to get right and sufficient for > "consenting adults". Just for reference, I'll comment how Cython uses this. First, Cython exports API in a function-by-function basis (instead of a single pointer to a C struct with function pointers, as e.g. cStringIO, or an array of func pointers, as e.g. NumPy). All these are cached in a "private" module global (a dict) named "__pyx_api__". See the link below, for example: http://mpi4py.scipy.org/docs/api/mpi4py.MPI-module.html#__pyx_capi__ So the dict keys are the exported function names. Moreover, the PyCObject's "desc" are a C string with the function signature. Cython retrieves a function by name from the dict and checks that the expected signature match. BTW, now I believe Cython should also use the function name for the "descr" :-) The only issue with this approach for Cython is that PyCObject currently stores "void*" (i.e., pointers to data), but does not have room for "void(*)(void)" (i.e. pointers to functions, aka code). Recently I had to write some hackery using type-punning with unions to avoid the illegal conversion problem between pointers to data and functions. Larry, I did not understand your comments in the tracker about this. Why do you see the above approach a miss-use of the API? All this works extremely well in practice... A Cython-implement extension module can export its API, and next you can consume it from Cython, and moreover from hand-written C extension (and then you can easily write SWIG typemaps). And as the function are exported one by one, you can even add stuff to some module API, and the consumers will not notice the thing (API tables implemented with pointer to C struct or array of function pointers, you need to be more careful for API exporting being backward) -- 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] calling dictresize outside dictobject.c
Did you read the post until the end? The OP is asking a question related to a very low level detail of dict implementation and making an offer to write a patch that could speed-up dict.setdefault() in core CPython... IMHO, a poll on python-dev do makes sense... On Tue, Apr 7, 2009 at 1:34 PM, Aahz wrote: > On Mon, Apr 06, 2009, Dan Schult wrote: >> >> I'm trying to write a C extension which is a subclass of dict. >> I want to do something like a setdefault() but with a single lookup. > > python-dev is for core development, not for questions about using Python. > Please use comp.lang.python or the capi-sig list. > -- > Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ > > "...string iteration isn't about treating strings as sequences of strings, > it's about treating strings as sequences of characters. The fact that > characters are also strings is the reason we have problems, but characters > are strings for other good reasons." --Aahz > ___ > 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] Why does read() return bytes instead of bytearray?
On Wed, Apr 15, 2009 at 12:05 AM, Dan Eloff wrote: >>No, the read() method did not change from the 2.x series. It returns a new >>object on each call. > > I think you misunderstand me, but the readinto() method looks like a > perfectly reasonable solution, I didn't realize it existed, as it's > not in the library reference on file objects. Thanks for enlightening > me, I feel a little stupid now :) > However, your original question is still valid ... Why a binary read() returns an immutable type? -- 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
[Python-Dev] PEP 384: a request for PyType_Slot
Martin, a small request.
Any chance you consider defining PyType_Slot like below?
typedef struct{
int slot;/* slot id, see below */
void *pdata; /* data pointer */
void (*pfunc)(void); /* function pointer */
} PyType_Slot
Or perhaps other way? Just to avoid compilers complaining about the
illegal conversion between pointers to data and pointers to
functions... It would be really annoying being force to do
type-punning using an union in order to get "correct" C code...
--
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] Serious regression in doctest in Py3.1rc1
http://bugs.python.org/issue6195 (with patch) On Wed, Jun 3, 2009 at 8:26 AM, Amaury Forgeot d'Arc wrote: > Hello, > > 2009/6/3 Stefan Behnel : >> Hi, >> >> I can't currently file a bug report on this, but I was told by Lisandro >> Dalcín that there is a serious problem with the doctest module in Py3.1rc1. >> In Cython, we use doctests to test the compiler in that we compile a >> Python/Cython module with doctests into a C module and then run doctest on >> the imported extension module. >> >> >From the error report it seems to me that doctest is now trying to read the >> module itself through linecache for some reason, which horribly fails for a >> binary module. >> >> Could someone please look into this? I'll open up a bug report tomorrow >> unless someone beats me to it. > > I don't have the time either, but the problem looks very similar to > http://bugs.python.org/issue4050 > The fix was to replace: > file = inspect.getsourcefile(object) or inspect.getfile(object) > was replaced with > file = inspect.getsourcefile(object) > > -- > 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/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
[Python-Dev] Suggested PySys_SetArgv use with a (char **) argv ?
Sorry... -- Forwarded message -- From: Lisandro Dalcin Date: Tue, Jul 7, 2009 at 7:16 PM Subject: Re: [Python-Dev] Suggested PySys_SetArgv use with a (char **) argv ? To: "Martin v. Löwis" On Tue, Jul 7, 2009 at 6:46 PM, "Martin v. Löwis" wrote: >> Since many C applications take argv as a (char **) it seems reasonable >> for python to keep a function for the C api that accepts a (char **) >> argument for argv. > I've run in the same issue, and basically had to copy&paste from Python sources... > > I'm not quite sure what you are suggesting: either that there is a > function in the C API that accepts a (char**), or that PySys_SetArgv > be that function. > > The latter alternative is out of question, as it breaks the Windows > port of Python - there is simply no way of representing argv with > char** in a meaningful way. It also breaks backwards compatibility. > Indeed... > As for creating another function: please provide a patch to > bugs.python.org. I believe this patch is *very* difficult to > implement, unless the function can accept some severe limitations. > What about the Python lib exposing a public PyOS_char2wchar() ? No idea how to write a Windows implementation, though.. -- 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 -- 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] pthreads, fork, import, and execvp
On Thu, May 18, 2006 at 3:02 PM, "Martin v. Löwis" wrote: > > Right. With some googling, I found that one solution is pthread_atexit: > a pthread_atexit handler is a triple (before, in_parent, in_child). > You set it to (acquire, release, release). Did you mean pthread_atfork() ? > When somebody forks, > the pthread library will first acquire the import lock in the thread > that wants to fork. Then the fork occurs, and the import lock gets > then released both in the parent and in the child. > > I would like to see this approach implemented, but I agree with you > that a test case should be created first. > Whould some new C-API functions do the trick? PyOS_AtForkPrepare() # acquire import lock pid = fork() if (pid == 0) PyOS_AtForkChild() # current PyOS_AfterFork() + release import lock else PyOS_AtForkParent() # release import lock -- 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] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile
On Wed, Jul 22, 2009 at 12:33 PM, Amaury Forgeot d'Arc wrote: > > These questions should be redirected to comp.lang.python. > Eric seems to be working on a GSoC for PFS related to improving subprocess. Even in such case this list is not the right place to make these posts?? -- 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] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile
On Thu, Jul 23, 2009 at 9:57 AM, Jean-Paul Calderone wrote: > > True, CPython has C infrastructure. What about the other Python runtimes, > though? > Perhaps these other Python runtimes could implement the functionality of PC/_subprocess.c and use ctypes for that ? -- 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] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile
On Thu, Jul 23, 2009 at 5:42 PM, Terry Reedy wrote: > Lisandro Dalcin wrote: >> >> On Thu, Jul 23, 2009 at 9:57 AM, Jean-Paul Calderone >> wrote: >> >>> True, CPython has C infrastructure. What about the other Python >>> runtimes, >>> though? >>> >> >> Perhaps these other Python runtimes could implement the functionality >> of PC/_subprocess.c and use ctypes for that ? > > Is it sensibly possible to augment a C file with #ifdefs so that it can be > compiled either as a directly importable module or as a ctypes-accessible > shared library? > Of course it is posible... Moreover, you could likely reuse 100 % of code intended for ctypes in implementing the extension module calls intended for Python. Mac OS X could have some issues though (IIUC, .so ext modules are not the same as .dylib dynamic libs, though perhaps ctypes can still dlopen() .so files?) However, how that would help these other Python runtimes without C infraestructure ?? -- 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 2.6.4rc2
I'm getting this warning. It seems nothing is actually broken, but the fix is pretty easy. gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c Objects/unicodeobject.c: In function 'PyUnicodeUCS2_FromFormatV': Objects/unicodeobject.c:687: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness /usr/include/string.h:397: note: expected 'const char *' but argument is of type 'unsigned char *' Objects/unicodeobject.c:687: warning: pointer targets in passing argument 1 of 'PyUnicodeUCS2_DecodeUTF8' differ in signedness Include/unicodeobject.h:752: note: expected 'const char *' but argument is of type 'unsigned char *' BTW, should Python build with a C++ compiler? It seems this is not possible with 2.6.4rc2 (and GCC 4.4.1) On Mon, Oct 19, 2009 at 8:55 AM, Barry Warsaw wrote: > On Oct 19, 2009, at 3:59 AM, Vinay Sajip wrote: > >> Barry Warsaw python.org> writes: >> >>> http://www.python.org/download/releases/2.6.4/ >> >> Good news, but just one little nit: the page above appears to link to the >> NEWS >> file for 2.6.4rc1. > > Ooops! Fixed, thanks. > -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/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] PyPI comments and ratings, *really*?
On Thu, Nov 12, 2009 at 12:32 PM, Jesse Noller wrote: > On Thu, Nov 12, 2009 at 9:25 AM, Barry Warsaw wrote: >> On Nov 12, 2009, at 8:06 AM, Jesse Noller wrote: >> >>> Frankly, I agree with him. As implemented, I *and others* think this >>> is broken. I've taken the stance of not publishing things to PyPi >>> until A> I find the time to contribute to make it better or B> It >>> changes. >> >> That's distressing. For better or worse PyPI is the central repository of >> 3rd party packages. It should be easy, desirable, fun and socially >> encouraged to get your packages there. >> > > PyPI isn't a place to file bugs, complain something didn't work for > you if you didn't even have the common decency in some cases to email > them. Being unable, as an author, to remove, moderate, or even respond > to issues there bothers me quite a bit. > I also agree with you. I do not see the point to make PyPI yet another social network. -- 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] PyPI comments and ratings, *really*?
On Thu, Nov 12, 2009 at 5:46 PM, "Martin v. Löwis" wrote: >> (more seriously, the problem with a comment system is that once it takes off, >> you need a whole array of functionalities to maintain a good S/N ratio. Just >> allowing people to "comment" without any sort of moderation, filtering or >> community building doesn't work) > > The current rate is roughly 1 comment per day (with peaks of 5 > comments), so it takes of rather slowly. > Until spammers decide to attack... -- 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] mingw support?
On 12 August 2010 20:37, Michael Foord wrote: > On 13/08/2010 00:44, Greg Ewing wrote: >> >> Cesare Di Mauro wrote: >> >>> You must suggest at least an equivalent "free" alternative to make the >>> switch convenient. >>> >>> Otherwise we are talking about philosophy or religion, and nobody will >>> change his ideas. >> >> I think the point is that *because* people don't want to change >> their ideas, it would be good to have a mingw-based alternative. >> Otherwise everyone is forced to convert to the Windows religion. >> > You mean people using Windows are forced to use Windows? > I would say people that want to support Windows but are not using it. -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169 ___ 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] r85028 - in python/branches/py3k: Doc/c-api/init.rst Include/pythonrun.h Modules/getpath.c PC/getpathp.c
On 27 September 2010 11:57, Georg Brandl wrote: > Am 27.09.2010 07:32, schrieb kristjan.jonsson: >> Author: kristjan.jonsson >> Date: Mon Sep 27 07:32:54 2010 >> New Revision: 85028 >> >> Log: >> issue 9910 >> Add a Py_SetPath api to override magic path computations when starting up >> python. >> >> Modified: >> python/branches/py3k/Doc/c-api/init.rst >> python/branches/py3k/Include/pythonrun.h >> python/branches/py3k/Modules/getpath.c >> python/branches/py3k/PC/getpathp.c >> >> Modified: python/branches/py3k/Doc/c-api/init.rst > >> +.. cfunction:: void Py_SetPath(const wchar_t *) >> + >> + .. index:: >> + triple: module; search; path >> + single: path (in module sys) >> + single: Py_GetPath() >> + >> + Set the default module search path. If this function is called before >> + :cfunc: `Py_Initialize` then :cfunc: Py_GetPath won't attempt to compute >> + a default serarch path but uses the provided one in stead. This is >> useful >> + if Python is being embedded by an application that has full knowledge >> + of the location of all modules. The path components should be separated >> + by semicolons. >> + >> + This also causes `sys.executable` to be set only to the raw program name >> + (see :cfunc:`Py_SetProgramName`) and `for sys.prefix` and >> + `sys.exec_prefix` to be empty. It is up to the caller to modify these if >> + required after calling :cfunc: `Py_Initialize`. >> + > > This needs a versionadded. > > Georg > Did you noticed " ... The path components should be separated by semicolons." ? I would expect os.path.pathsep, after all paths are not OS-independent. -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169 ___ 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] Strategy for converting the decimal module to C
On 7/18/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [Raymond Hettinger] > > ... > > If the current approach gets in their way, the C implementers should feel > > free to > > make an alternate design choice. > > I expect they will, eventually. Converting this to C is a big job, > and at the NFS sprint we settled on an "incremental" strategy allowing > most of the module to remain written in Python, converting methods to > C one at a time. Changing the user-visible API is a hard egg to > swallow, and it's unfortunate that the Python code used a dict to hold > "flags" to begin with. The dict doesn't just record whether an > exception has occurred, it also counts how many times the exception > occurred. It's possible that someone, somewhere, has latched on to > that as "a feature". Why not a 'cDecimal' module instead? -- 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 3118: Extended buffer protocol (new version)
On 4/9/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
Travis, all this is far better and simpler than previous approaches...
Just a few comments
> The bufferinfo structure is::
>
> struct bufferinfo {
>void *buf;
>Py_ssize_t len;
>int readonly;
>char *format;
>int ndims;
>Py_ssize_t *shape;
>Py_ssize_t *strides;
>Py_ssize_t *suboffsets;
>void *internal;
> };
1) I assume that 'bufferinfo' structure will be part of public Python
API. In such a case, I think it should be renamed and prefixed.
Something like 'PyBufferInfo' sounds good?
2) I also think 'bufferinfo' could also have an 'itemsize' field
filled if Py_BUF_ITEMSIZE flag is passed. What do you think? Exporters
can possibly fill this field more efficiently than next parsing
'format' string, it can also save consumers from an API call.
3) It does make sense to make 'format' be 'const char *' ?
4) I am not sure about this, but perhaps 'buferingo' should save the
flags passed to 'getbuffer' in a 'flags' field. This can be possibly
needed at 'releasebuffer' call.
> typedef struct {
> PyObject_HEAD
> PyObject *base;
> struct bufferinfo view;
> int itemsize;
> int flags;
> } PyMemoryViewObject;
5) If my previous comments go in, so 'PyMemoryViewObject' will not
need 'itemsize' and 'flags' fields (they are in 'bufferinfo'
structure).
6) Perhaps 'view' field can be renamed to 'info'.
> int PyObject_SizeFromFormat(char *)
7) Why not 'const char *' here?
> int PyObject_GetContiguous(PyObject *obj, void **buf, Py_ssize_t *len,
>int fortran)
>
> Return a contiguous chunk of memory representing the buffer. If a
> copy is made then return 1. If no copy was needed return 0.
8) If a copy was made, What should consumers call to free memory?
> If the object is multi-dimensional, then if
> fortran is 1, the first dimension of the underlying array will vary
> the fastest in the buffer. If fortran is 0, then the last dimension
> will vary the fastest (C-style contiguous). If fortran is -1, then it
> does not matter and you will get whatever the object decides is more
> efficient.
9) What about using a char, like 'c' or 'C', and 'f' or 'F', and 0 or
'a' or 'A' (any) ?
> int PyObject_CopyToObject(PyObject *obj, void *buf, Py_ssize_t len,
> int fortran)
10) Better name? Perhaps PyObject_CopyBuffer or PyObject_CopyMemory?
> int PyObject_SizeFromFormat(char *)
>
> int PyObject_IsContiguous(struct bufferinfo *view, int fortran);
>
> void PyObject_FillContiguousStrides(int *ndims, Py_ssize_t *shape,
> int itemsize,
> Py_ssize_t *strides, int fortran)
>
> int PyObject_FillBufferInfo(struct bufferinfo *view, void *buf,
> Py_ssize_t len,
> int readonly, int infoflags)
>
11) Perhaps the 'PyObject_' prefix is wrong, as those functions does
not operate with Python objects.
Regards,
--
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 3118: Extended buffer protocol (new version)
On 4/13/07, Travis Oliphant <[EMAIL PROTECTED]> wrote: > >> int PyObject_GetContiguous(PyObject *obj, void **buf, Py_ssize_t > >> *len, > >>int fortran) > >> > >> Return a contiguous chunk of memory representing the buffer. If a > >> copy is made then return 1. If no copy was needed return 0. > > > > 8) If a copy was made, What should consumers call to free memory? > > You are right. We need a free function. > I think now the memory perhaps should be allocated with PyMem_New and deallocated with PyMem_Free. Additionally, the return should perhaps indicate success or failure, and a new argument should be passed in order to know if a copy was made, something like int PyObject_GetContiguous(PyObject *obj, void **buf, Py_ssize_t *len, int *copy, char layout) -- 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 [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Py3k: error byte-compiling with distutils
I'm porting some of my code to py3k, and I started from the C size.
After this, all extensions compiled fine, but after a 'setup.py
install', I got the following:
File "/usr/local/python/3.0/lib/python3.0/distutils/util.py", line
498, in byte_compile
compile(file, cfile, dfile)
File "/usr/local/python/3.0/lib/python3.0/py_compile.py", line 127, in compile
py_exc = PyCompileError(err.__class__,err.args,dfile or file)
File "/usr/local/python/3.0/lib/python3.0/py_compile.py", line 48, in __init__
tbtext = ''.join(traceback.format_exception_only(exc_type, exc_value))
File "/usr/local/python/3.0/lib/python3.0/traceback.py", line 196,
in format_exception_only
lines.append("%s: %s\n" % (stype, str(msg)))
UnboundLocalError: local variable 'msg' referenced before assignment
At this point, I had not updated my python code, so it surelly had
some py3k-invalid things. Looking at 'traceback.py', it seems there is
something wrong in 'format_exception_only', so this error.
--
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
[Python-Dev] Py3k: 'range' fail
I did a fresh checkout as below (is p3yk the right branch?) $ svn co http://svn.python.org/projects/python/branches/p3yk python-3k after building and installing, I get $ python3.0 Python 3.0x (p3yk:56529, Jul 24 2007, 15:58:59) [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> range(0,10,2) Traceback (most recent call last): File "", line 1, in SystemError: NULL result without error in PyObject_Call >>> -- 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
[Python-Dev] Py3k: error during 'make install' in py3k-struni ?
Afther checking out the py3k-struni branch, 'make install' issued this:
Compiling /usr/local/python/3.0/lib/python3.0/test/test_tarfile.py ...
*** SyntaxError: ('expected string, bytes found',
('/usr/local/python/3.0/lib/python3.0/test/test_tarfile.py', 0, 0,
None))
If this is expected to fail, please forget this.
--
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
[Python-Dev] interaction between locals, builtins and except clause
Porting to Py3K, I modified a function like the followin, using a trick for it working in Py2.x . def __iter__(self): if self == _mpi.INFO_NULL: return try:range = xrange except: pass nkeys = _mpi.info_get_nkeys(self) for nthkey in range(nkeys): yield _mpi.info_get_nthkey(self, nthkey) However, I've got in my unittests (running with py3k) ERROR: testPyMethods (__main__.TestInfo) -- Traceback (most recent call last): File "tests/unittest/test_info.py", line 123, in testPyMethods for key in INFO: File "/u/dalcinl/lib/python/mpi4py/MPI.py", line 937, in __iter__ for nthkey in range(nkeys): UnboundLocalError: local variable 'range' referenced before assignment I am not completelly sure if this is expected (it is, regarding implementation, but perhaps not regarding Python as a language), so I post this for your consideration. -- 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 Package Index hostname change
On 7/31/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > The Python Packaging Index (the software formerly known > as Cheeseshop) is now available at > > http://pypi.python.org/pypi Please, update 'DEFAULT_REPOSITORY' in Lib/distutils/command/upload.py (py-2.6 and py3k-struni branches) -- 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 Package Index hostname change
Martin, could you please verify if this change did not break the download counter? -- 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] optimizing [x]range
On 8/2/07, Stargaming <[EMAIL PROTECTED]> wrote: > >> made into an O(1) operation. here's a demo code (it should be trivial > >> to implement this in CPython) > [snipped algorithm] Did you taked into account that your patch is not backward compatible with py2.5?? Just try to do this with your patch, $ python Python 2.5.1 (r251:54863, Jun 1 2007, 12:15:26) >>> class A: ... def __eq__(self, other): ... return other == 3 ... >>> A() in xrange(3) False >>> A() in xrange(4) True >>> I know, my example is biased, but I have to insist. With this patch, 'a in xrange' will in general not be the same as 'a in range(...)'. I am fine with this for py3k, but not sure if all people will agree on this for python 2.6. -- 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
[Python-Dev] building with -Wwrite-strings
I'm trying to build Python (2.6) with GCC the option -Wwrite-strings.
1 - Is there any interest on this?
2 - What should I do for the very common (taken from int_new):
static char *kwlist[] = {"x", "base", 0};
I was able to remove all the warning in Objects/*, except those related to (2).
--
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] building with -Wwrite-strings
Yes, you are completely right. I ended up realizing that a change like
this would break almost all third-party extension.
But... What about of doing this for Py3K? Third-party extension have
to be fixed anyway.
On 10/1/07, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Martin,
>
> On Fri, Sep 28, 2007 at 11:09:54PM +0200, "Martin v. Löwis" wrote:
> > What's wrong with
> >
> > static const char *kwlist[] = {"x", "base", 0};
>
> The following goes wrong if we try again to walk this path:
> http://mail.python.org/pipermail/python-dev/2006-February/060689.html
>
>
> Armin
>
--
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
[Python-Dev] PyTuple_Pack with NULL argument
Currently, PyTuple_Pack() does not check for NULL arguments, so it is going to segfault in this case. Is this intended for performance reasons? -- 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] Error in PEP3118?
On 2/11/08, Travis Oliphant <[EMAIL PROTECTED]> wrote: > My perception is that you are seeing too much of a connection between > the C-compiler and the PEP description of memory. Perhaps that's not > it, and I'm missing something else. > Travis, all this make me believe that (perhaps) the 'format' specification in the new buffer interface is missing the 'C' or 'F' ordering in the case of a countiguos block. I'm missing something? Or should we always assume a 'C' ordering? -- 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] trunk-math
On 2/16/08, Mark Dickinson <[EMAIL PROTECTED]> wrote: > * New float methods: is_finite, is_inf, is_integer and is_nan. Just a question... is_integer or is_integral? -- 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)
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] [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] PEP3118, python 2.6
On 6/5/08, Thomas Heller <[EMAIL PROTECTED]> wrote: Thomas, Iff this helps, you have attached the backport but as an extension module. Sorry, I do not have time for the full backport. But at least, I've found that the Py3K implementation works You will need to build it with 'python2.6 setup.py build' and copy 'memvwr.so' somewhere in your $PYTHONPATH, then in you 'site.py' or whatever, you can do 'import memvwr; del memvwr' . This will automaticall add the module to the __builtin__ module. Some notes: * I had to add Py_TPFLAGS_HAVE_NEWBUFFER to the type object structure. Should'nt this be already included in Py_TPFLAGS_DEFAULT ? * I have to monkey-copy two auxiliary functions 'abstrac.c' for Py3k, as ther are employed in memoryobject.c Travis, I believe you should have to review this. I'm not sure iff that is the right approach, regarding symbol visibility in shared libs in different OS's, compilers, etc.. But perhaps all is OK. Just a warning about possible problems :-). * I've not implemented the former buffer interface, I just put NULL's for the slots. Not sure if implementing the former interface is relly needed. * I've used PyString_XXX API calls. Not sure what will be the final status of the C API cleanup for Py2.6. Perhaps this should be replaced with PyBytes_ > Thomas Heller schrieb: > > > I'm currently trying to port the pep3118 ctypes changes which are already in > > the py3k branch to the trunk. > > > > In py3k the tests for this stuff (in Lib/ctypes/test/test_pep3118.py) use > > the memoryview object which exposes attributes like .format, .shape, > .strides > > and so on for objects implementing the new buffer interface. > > > > In Python 2.6 memoryview does not exist so the question is how to write a > test > > that checks for the correct attributes. My idea is to implement the > > __array_interface__ property for ctypes instances, as described in this > document > > http://numpy.scipy.org/array_interface.shtml. > > > In private email Travis told me that he has no time to backport the memoryview > object to Python 2.6. Maybe there is someone who could do this (Myself I > have > no time either for this)? > > > 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/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 memoryview-py2.6.tar.gz Description: GNU Zip compressed data ___ 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] Documentation idea
On Thu, Oct 9, 2008 at 8:50 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Christian Heimes] >> >> The idea sounds great! >> >> Are you planing to embed the pure python code in C code? > > Am experimenting with a descriptor that fetches the attribute string from a > separate text file. Have you ever considered the same approach for docstrings in C code? As reference, NumPy already has some trickery for maintaining docstrings outside C sources. Of course, descriptors would be a far better for implementing and support this in core Python and other projects... > This keeps the C build from getting fat. More > importantly, it let's us write the execable string in a more natural way (it > bites to write C style docstrings using \n and trailing backslashes). The > best part is that people without C compilers can still submit patches to the > text files. > > > 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/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] Issue 4195: Can't execute packages with -m in Python 2.6/3.0
Unless this is considered a regression... On Tue, Nov 18, 2008 at 12:51 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I think it crosses the line. > > On Tue, Nov 18, 2008 at 2:55 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> I need a release manager call on whether or not the proposed resolution >> of this issue goes beyond what is acceptable for a bug fix in 2.6.1. >> >> Short version: >> - Python 2.5 allowed packages to be executed with -m, but in a broken way >> - I disabled the broken way for 2.6, but didn't provide a replacement >> - The patch attached to 4195 once again allows execution of packages >> with -m, but in a clean way similar to the way directories and zipfiles >> can now be executed >> - I would like to commit that patch for 3.0/2.6.1, but I'm concerned >> that it crosses the "no new features" line >> >> Long version: >> >> There was a bug in python 2.5 that allowed a package name to be passed >> to the -m switch or runpy.run_module() and it would mostly work. >> >> However, the 'mostly' was due to the fact that doing this put the >> internal import machinery into a slightly inconsistent state: the >> interpreter was running code from inside a package, but that package >> wasn't actually present in sys.modules. This could lead to assorted hard >> to trace import-related weirdness, similar to what you can get when >> executing a file from inside a package by name. You would often get away >> with it, but good luck figuring out what is happening if things go wrong >> (and you aren't already an expert on Python import mechanics). >> >> Since the ability to execute packages wasn't intentional, I added the >> missing check to block it explicitly in 2.6 (but left it alone for 2.5). >> It seemed like a really niche feature, so I didn't figure out a clean >> replacement for it at the time. >> >> Benjamin noticed this change earlier in the 2.6 release cycle, I pointed >> out it was a deliberate change, and that's the way it stayed until after >> 2.6 was released. >> >> After the release, Andi Vajda (from the JCC project [1]) contacted me, >> and together we worked out a better implementation of package support >> for the -m switch (and runpy.run_module) [2] by extending the >> __main__.py approach used to support direct execution of zipfiles and >> directories [3]. >> >> That's what I would like to add, since it nicely complements the ability >> to execute zipfiles and directories, while also restoring the ability to >> pass a package name to the -m switch (but in a way that keeps the import >> machinery in a consistent state). >> >> Cheers, >> Nick. >> >> [1] http://pypi.python.org/pypi/JCC >> >> [2] http://bugs.python.org/issue4195 (package execution with -m) >> [3] http://bugs.python.org/issue1739468 (zipfile execution) >> >> -- >> Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia >> --- >> ___ >> 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/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/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
[Python-Dev] PEP 3000 and new style classes
PEP 3000 - Core language says (http://www.python.org/peps/pep-3000.html#core-language) : - Support only new-style classes; classic classes will be gone Any possibility to add something like from __future__ import new_style_classes to have newly defined classes implicitly derive from 'object' (I understand this will be the implicit behavior when classic classes go away in Py3.0). -- 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
[Python-Dev] PEP 3000 and new style classes
On 9/8/05, Aahz <[EMAIL PROTECTED]> wrote: > > You can already do > > __metaclass__ = type > > within each module > Yes, you are right. But this way, you are making explicit a behavior that will be implicit in the future. For example, we could also do: two = float(4)/float(2) instead of from __future__ import division two = 4/2 -- 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
[Python-Dev] PEP 3000 and iterators
PEP 3000 says (http://www.python.org/peps/pep-3000.html) : Core language - Return iterators instead of lists where appropriate for atomic type methods (e.g. dict.keys(), dict.values(), dict.items(), etc.) Built-in Namespace - Make built-ins return an iterator where appropriate (e.g. range(), zip(), etc.) - Relevant functions should consume iterators (e.g. min(), max()) To be removed: - xrange(): use range() instead [1] Any possibility to add one (or more) __future__ statement to implicitly get this behavior? Any suggestion about naming? -- 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 3000 and new style classes
On 9/9/05, holger krekel <[EMAIL PROTECTED]> wrote: > > > > It matters because "metaclass = type" is completely obscure. How would > > any non-expert have a clue what it means? > > How would this non-expert have a clue what > "from __future__ import new_style_classes" means? > That is the point!!! If I am a developer, I think is better to have a __future__ statement for things that are planned to change in the future. If you are a non-expert, you will google for new style classes, and I think is far easier to understand what a new style class is than metaclasses. How many non-expert knows about nested scopes subjects introduced in Py2.1? it has a __future__ statement. Additionaly, a __future__ statement can be easily removed when a new Python release cames. We could simply use the script Tools/scripts/cleanfuture.py to eliminate those __future__ imports when Py3.0 is available. The same applies for generators in Py2.4 ... -- 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 3000 and new style classes
On 9/9/05, Michael Chermside <[EMAIL PROTECTED]> wrote: > I think it would > provide a REALLY nice migration path if it were possible to write > Python 3.0 code in Python 2.x (for large values of x) so long as you > included an appropriate preamble of "from __future__ import" statements. Perhaps I was not clear, but that was the reason of my proposal. I agree it is not necesary, but this will help developers to transition from Py2.X to Py3.0 in a consistent way. I will vote +1 for any attemps to populate __future__ module if that enables writing working Py3K code as soon as possible in Py2.X .. > I love making Perl users jealous, So I love! ;) -- 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 3000 and iterators
On 9/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > For the builtins, it would actually be possible to do this by simply > importing an alternate builtins module. Something like > > from future_builtins import min, max, zip, range > Yes. A straightforward solution... > For methods on standard objects like dicts it's not really possible > either way; the type of a dict is determined by the module containing > the code creating it, not the module containing the code using it. > I had that in mind when I wrote my post; changing types is not the way, that will not work. That is why I proposed __future__ (I really do not know very well the implementation details of that feature) because I think the parser/compiler can (magically) make the replacements, e.g. dict.items -> dict.iteritems for Py2.X series in codes *using* dicts . Do you think something like this could be implemented in a safer way? -- 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] Wanting to learn
Jason, this mailing list is related to Python development. If you are a new at Python, a far better place for help is comp.lang.python group. Please go to Google Grups and take a look. If you do a search in those archives, you will find many good links. -- 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] bool(container) [was bool(iter([])) changedbetween 2.3 and 2.4]
On 9/30/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Guido van Rossum] > > __len__ is for sequences and mappings specifically -- everything that > > supports __getitem__ should have __len__ and everything that has > > __len__ should have __getitem__. > > That's going a bit far. Unordered collections (like sets and bags) are > a good counter-example. > I've implemented many extension types in C, always to interface external libraries (the main examples, MPI and PETSc). In those libraries, some object are invalid (MPI_COMM_NULL) or can get deallocated in the C side. I always implement a __nonzero__ method for testing those situations. It sounds a bit bizarre to me to have to implement a number method for a object that is far from being a number, and of course __len__ do not make any sense. Perhaps Py3k could have a more explicit mechanism for definig the truth value of an object? Something like __bool__ method to be filled in type object? Any opinions? Lisandro Dalcín ___ 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] enumerate with a start index
On 10/19/05, Martin Blais <[EMAIL PROTECTED]> wrote: > Just wondering, would anyone think of it as a good idea if the > enumerate() builtin could accept a "start" argument? And why not an additional "step" argument? Anyway, perhaps all this can be done with a 'xrange' object... -- 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
