Re: [Python-Dev] Change Makefile.pre.in based on configure?
On 24 Jan, 2009, at 22:03, [email protected] wrote: I'm working on issue 4111 which will add dtrace support to Python when requested by the builder and when supported by the platform (currently just Solaris and Mac OSX I believe). Sun and Apple have quite different ways to generate the code necessary to link into the executable. Sun's dtrace command supports a -G flag which generates a .o file from a .d file. Apple instead generates an include file using the -h flag to dtrace (-G and .o file generation are not supported). This puts a bit of a crimp in generating Makefile dependencies. In the Sun case you have a couple extra .o files to link into libpython. In the Apple case you have a couple extra .h files which define Dtrace macros. How do I work around this difference in Makefile.pre.in? I can detect Sun vs. Apple in the configure script, but I see no conditional logic in Makefile.pre.in to use as an example. It seems to only use variable expansion on the RHS of stuff. Can I do something like if @WITH_DTRACE_SUN@ = 1 then ... Sun-style dependencies here ... else ... Apple-style dependencies here ... fi where WITH_DTRACE_SUN is a macro defined in pyconfig.h by the configure script? I use configure to paste bits into Makefile.pre.in for the OSX framework support. In Makefile.pre.in: install:@FRAMEWORKINSTALLFIRST@ altinstall bininstall maninstall @FRAMEWORKINSTALLLAST@ FRAMEWORKINSTALLFIRST and FRAMEWORKINSTALLLAST are calculated in configure.in. This should work for dtrace as well. That is, in the configure script define DTRACE_HEADER_DEPS and DTRACE_OBJECT_DEPS and add @DTRACE_HEADER_DEPS@ and @DTRACE_OBJECT_DEPS@ to the proper targets in Makefile.pre.in. Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: [Python-Dev] Additional behaviour for itertools.combinations
On Sun, 25 Jan 2009 02:33:37 pm Raymond Hettinger wrote:
> > Raymond Hettinger wrote:
> >> Since I expect students to be among the users for the comb/perm
> >> functions, there is some merit to keeping the API as simple as
> >> possible. Besides, it is not hard to use the existing tool as a
> >> primitive to get to the one you want:
> >>
> >> def mycombinations(iterable, r_seq):
> >> # mycombinations('abc', [1,2]) --> A B C AB AC BC
> >> iterable = list(iterable)
> >> return chain.from_iterable(imap(combinations,
> >> repeat(iterable), r_seq))
>
> [Nick Coglan]
>
> > Perhaps a reasonable starting point would be to include this as one
> > of the example itertools recipes in the documentation?
>
> I would have suggested that but recipe itself is use case challenged.
> The OP did not mention any compelling use cases or motivations.
> Essentially, he just pointed-out that it is possible, not that it is
> desirable.
>
> I can't the of a case where I've wanted to loop over variable length
> subsequences. Having for-loops with tuple unpacking won't work
> because the combos have more than one possible size.
>
> This seems like a hypergeneralization to me.
Does answering homework questions count as a use-case?
http://mathforum.org/library/drmath/view/56121.html
Also calculating the odds of winning Powerball:
http://mathforum.org/library/drmath/view/56122.html
The number of combinations taken (1, 2, 3, ..., n) at a time is closely
related to the Bell Numbers. And according to Wikipedia, the oldest
known reference to combinatrics included such a question.
http://en.wikipedia.org/wiki/History_of_combinatorics
Having said all that, I'm inclined to agree that this is an
over-generalisation. As far as I can tell, there's no name for this in
mathematics, which suggests that useful applications and theorems are
both rare.
In any case, it's not that difficult to create a generator to yield all
the combinations:
(comb for k in ks for comb in itertools.combinations(seq, k))
I'm with Nick that this would make a good example for the documentation.
I don't object to combinations growing the extra functionality, but if
it does, people will ask why permutations doesn't as well.
--
Steven D'Aprano
___
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
Re: [Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability
>> [SNIP] >> Yes it is enough to encapsulate memory allocation and file functions into >> python shared library. The python provide memory allocation functions, but >> not all modules use them. File functions are hiden by posixmodule and python >> modules can't use them. > > except ... posixmodule gets renamed to ntmodule oh, i see what > you mean: python modules aren't allowed _direct_ access to msvcrtNN's > file functions, they have to go via posixmodule-renamed-to-ntmodule. thinking about this some more... posixmodule.c is linked (by default) into pythonNN.dll, thus making pythonNN.dll totally dependent on a version of msvcrt. decoupling posixmodule.c from pythonNN.dll leaves the possibility to make python independent of msvcrt versioning. it would need to be a custom-compiled .pyd module, due to the early dependency. i'll see if this is possible. l. ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 24, 2009, at 7:48 PM, Brett Cannon wrote: As part of my impressions I plan to also look at usage on top of svn as a viable alternative if no clear winner comes about. That way if they work well directly on top of svn we can write up very clear documentation on how to use any of them directly on top of svn and still gain the benefits of offline checkins and cheap branching. Maintenance then becomes simply keeping a read-only mirror going on code.python.org. There's a possible third way. I've heard (though haven't investigated) that some people are working on supporting the svn wire protocol in the bzr server. This would mean that anybody who's still comfortable with svn and feels no need to change their current habits can continue to work the way they always have. Those that want the extra benefits of a DVCS, or who do not have commit access to the code.python.org branches would have viable alternatives. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSXx8tHEjvBPtnXfVAQK1CgQAoDlHr9KthVr9sA6DfeXE3D35mYUop01X TD06OggbayFDGQYA0Zae+zU050R9UvuTpaF7XtSiSgBlI6n0Bb/rLAgVGskwbMHD LU8BAljNq6FpRp8QY2IHVRWKgOqzSHtz8CvCdlD1yw5CbA/pEvigoLzR0AWAeQJl tzOAetiud2c= =5qIJ -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability
> decoupling posixmodule.c from pythonNN.dll leaves the possibility to
> make python independent of msvcrt versioning.
>
> it would need to be a custom-compiled .pyd module, due to the early
> dependency.
>
> i'll see if this is possible.
i'd added PyExc_OSError, for example, as data exported from dlls. i'm
finding that this causes problems :)
so when posixmodule.c is a module (nt.pyd), doing this works:
PyAPI_FUNC(PyObject *)
PyErr_GetPyExc_OSError(void)
{
return (PyObject*)PyExc_OSError;
}
and thus
oserr = PyErr_GetPyExc_OSError();
Py_INCREF(oserr);
PyModule_AddObject(m, "error", oserr)
but doing _direct_ access to PyExc_OSError fails miserably.
i'll try to track down why (am adding __cdecl to PyAPI_DATA to see if
that helps).
l.
___
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
Re: [Python-Dev] progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
> Have you made some benchmarks like pystone? > Cheers, > Cesare Cesare, hi, thanks for responding: unfortunately, there's absolutely no point in making any benchmark figures under an emulated environment which does things like take 2 billion instruction cycles to start up a program named "c:/msys/bin/sh.exe", due to it inexplicably loading 200 GUI-only truetype fonts. and to do benchmarks on say windows would require that i install ... windows! so if somebody else would like to make some benchmarks, and publish them, they are most welcome to do so. l. ___ 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
Re: [Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability
Luke Kenneth Casson Leighton wrote: [SNIP] Yes it is enough to encapsulate memory allocation and file functions into python shared library. The python provide memory allocation functions, but not all modules use them. File functions are hiden by posixmodule and python modules can't use them. except ... posixmodule gets renamed to ntmodule oh, i see what you mean: python modules aren't allowed _direct_ access to msvcrtNN's file functions, they have to go via posixmodule-renamed-to-ntmodule. thinking about this some more... posixmodule.c is linked (by default) into pythonNN.dll, thus making pythonNN.dll totally dependent on a version of msvcrt. This is not problem. If python*.dll hide msvcrt and other modules depend directly from python*.dll I expect issue to be resolved. i.e. python*.dll to be "portable runtime interface". decoupling posixmodule.c from pythonNN.dll leaves the possibility to make python independent of msvcrt versioning. it would need to be a custom-compiled .pyd module, due to the early dependency. i'll see if this is possible. Румен ___ 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] microsoft dlls apparently don't support data. implications: PyAPI functions required to access data across modules.
according to the wikipedia entry on dlls, dlls do not support data, only functions. which would explain two things: 1) why certain modules are forcibly linked into pythonNN.dll 2) why attempts to move them out of pythonNN.dll cause runtime crashes. so i will continue the experiment, and remove all the "data" references from the pythonNN.def that i added, and deal with the knock-on consequences, which will involve adding "get" functions. for example, PyAPI_FUNC(char*) _PyStructSequence_Get_UnnamedField(void) use of such functions will allow various bits and pieces - such as PyStructSequence_UnnamedField - to be converted back to static in their respective c files. any objections, speak now, because this will involve quite a bit of work. l. ___ 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
Re: [Python-Dev] microsoft dlls apparently don't support data. implications: PyAPI functions required to access data across modules.
On Sun, Jan 25, 2009 at 3:58 PM, Luke Kenneth Casson Leighton wrote: > according to the wikipedia entry on dlls, dlls do not support data, > only functions. which would explain two things: > 1) why certain modules are forcibly linked into pythonNN.dll > 2) why attempts to move them out of pythonNN.dll cause runtime crashes. > so i will continue the experiment, and remove all the "data" > references from the pythonNN.def that i added, and deal with the > knock-on consequences, which will involve adding "get" functions. > > for example, PyAPI_FUNC(char*) _PyStructSequence_Get_UnnamedField(void) > > use of such functions will allow various bits and pieces - such as > PyStructSequence_UnnamedField - to be converted back to static in > their respective c files. > > any objections, speak now, because this will involve quite a bit of work. here is a starting list of data items which will require "getter" functions, found just by creating a posixmodule.pyd: Info: resolving __Py_NoneStruct by linking to __imp___Py_NoneStruct (auto-import) Info: resolving _Py_FileSystemDefaultEncoding by linking to __imp__Py_FileSystemDefaultEncoding (auto-import) Info: resolving _PyExc_OSError by linking to __imp__PyExc_OSError (auto-import) Info: resolving _PyUnicode_Type by linking to __imp__PyUnicode_Type (auto-import) Info: resolving _PyFloat_Type by linking to __imp__PyFloat_Type (auto-import) Info: resolving _PyExc_TypeError by linking to __imp__PyExc_TypeError (auto-impoModules/posixmodule.ort) Info: resolving _PyExc_RuntimeError by linking to __imp__PyExc_RuntimeError (auto-import) Info: resolving _PyExc_ValueError by linking to __imp__PyExc_ValueError (auto-import) Info: resolving _PyExc_RuntimeWarning by linking to __imp__PyExc_RuntimeWarning (auto-import) Info: resolving _PyExc_NotImplementedError by linking to __imp__PyExc_NotImplementedError (auto-import) obviously, auto-import can't happen. so getter-functions it is. l. ___ 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
Re: [Python-Dev] microsoft dlls apparently don't support data. implications: PyAPI functions required to access data across modules.
> here is a starting list of data items which will require "getter" > functions, found just by creating a posixmodule.pyd: > > Info: resolving __Py_NoneStruct by linking to __imp___Py_NoneStruct > (auto-import) by no small coincidence, every single module with which we've had difficulties in the mingw port - _sre, thread, operator, locale, winreg, signal and have been forced to put them into python2N.dll - all of them _happen_ to _directly_ reference the _PyNone_Struct data variable. surpriiise. that means that the Py_None macro must call the "getter" function. l. ___ 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
Re: [Python-Dev] microsoft dlls apparently don't support data. implications: PyAPI functions required to ac cess data across modules.
Luke Kenneth Casson Leighton lkcl.net> writes: > > that means that the Py_None macro must call the "getter" function. Given the negative performance implications that it would have, chances are it is out of question. Also, while not a Windows expert *at all*, I'd question your interpretation of the problem. If data could not be found in a DLL, how could Windows builds of Python (and third-party extensions) work at all? ___ 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
Re: [Python-Dev] microsoft dlls apparently don't support data. implications: PyAPI functions required to access data across modules.
On Sun, Jan 25, 2009 at 4:33 PM, Luke Kenneth Casson Leighton wrote: >> Info: resolving __Py_NoneStruct by linking to __imp___Py_NoneStruct >> (auto-import) > > by no small coincidence, every single module with which we've had > difficulties in the mingw port - _sre, thread, operator, locale, > winreg, signal and have been forced to put them into python2N.dll - > all of them _happen_ to _directly_ reference the _PyNone_Struct data > variable. > > surpriiise. > > that means that the Py_None macro must call the "getter" function. btw - if anyone has any objections, think about this: how is anyone - third party or otherwise - meant to return Py_None from c code in a dynamic module (or any other type) - and expect their code to work on windows?? i mean... has anyone _written_ a third party module that returns Py_None on a c-code module and had it compiled on windows? it wouldn't surprise me in the least if this is one of the severe issues (unresolved and unexplained) that people encounter on win32. l. ___ 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
Re: [Python-Dev] microsoft dlls apparently don't support data. implications: PyAPI functions required to access data across modules.
2009/1/25 Luke Kenneth Casson Leighton : > according to the wikipedia entry on dlls, dlls do not support data, > only functions. What do you mean by "not support data"? Having global data variables in a dll? In wikipedia, it is explicitely told that this is possible to have data (http://en.wikipedia.org/wiki/Dynamic-link_library). Without them, shared library cannot be used. Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ 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
Re: [Python-Dev] microsoft dlls apparently don't support data. implications: PyAPI functions required to access data across modules.
On Sun, Jan 25, 2009 at 9:01 AM, Matthieu Brucher wrote: > 2009/1/25 Luke Kenneth Casson Leighton : >> according to the wikipedia entry on dlls, dlls do not support data, >> only functions. > > What do you mean by "not support data"? Having global data variables in a dll? > In wikipedia, it is explicitely told that this is possible to have > data (http://en.wikipedia.org/wiki/Dynamic-link_library). Without > them, shared library cannot be used. Indeed. That's why the header files contain define PyAPI_DATA(RTYPE) extern __declspec(dllexport) RTYPE define PyAPI_DATA(RTYPE) extern __declspec(dllimport) RTYPE -- Curt Hagenlocher [email protected] ___ 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
Re: [Python-Dev] microsoft dlls apparently don't support data. implications: PyAPI functions required to access data across modules.
Luke Kenneth Casson Leighton schrieb: > i mean... has anyone _written_ a third party module that returns > Py_None on a c-code module and had it compiled on windows? Lot's of people have written 3rd party extensions that work on Windows and can return a Py_None object. Please stop spamming the Python developer list with irrelevant, wrong, confusing and sometimes offensive messages. To be perfectly honest it's annoying. If you want to propose a new feature then python-ideas is the right mailing list. For everything else you should stick to the python-general or capi-sig list. Christian ___ 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
Re: [Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability
On Sun, Jan 25, 2009 at 3:55 PM, Roumen Petrov
wrote:
> Luke Kenneth Casson Leighton wrote:
[SNIP]
Yes it is enough to encapsulate memory allocation and file functions
into
python shared library. The python provide memory allocation functions,
but
not all modules use them. File functions are hiden by posixmodule and
python
modules can't use them.
>>>
>>> except ... posixmodule gets renamed to ntmodule oh, i see what
>>> you mean: python modules aren't allowed _direct_ access to msvcrtNN's
>>> file functions, they have to go via posixmodule-renamed-to-ntmodule.
>>
>> thinking about this some more... posixmodule.c is linked (by
>> default) into pythonNN.dll, thus making pythonNN.dll totally dependent
>> on a version of msvcrt.
>
> This is not problem. If python*.dll hide msvcrt and other modules depend
> directly from python*.dll I expect issue to be resolved. i.e. python*.dll to
> be "portable runtime interface".
ye :)
well - it looks like i am having success with removing all references
to data e.g. Py_NoneStruct, all of the PyExc_*Warning and
PyExc_*Error, all of the Py*_Types and more.
i'm making sure that macros are heavily used - so that on systems
where data _can_ be accessed through dynamic shared objects, it's done
so.
#if defined(MS_WINDOWS) || defined(__MINGW32__)
/* Define macros for conveniently creating "getter" functions,
* to avoid restrictions on dlls being unable to access data.
* see #5056
*/
/* use these for data that is already a pointer */
#define PyAPI_GETHDR(type, obj) \
PyAPI_FUNC(type) _Py_Get_##obj(void);
#define PyAPI_GETIMPL(type, obj) \
PyAPI_FUNC(type) _Py_Get_##obj(void) { return (type)obj; }
#define _PYGET(obj) _Py_Get_##obj()
/* use these for data where a pointer (&) to the object is returned
* e.g. no longer #define Py_None (&Py_NoneStruct) but
* #define Py_None _PTGETPTR(Py_NoneStruct)
*/
#define PyAPI_GETHDRPTR(type, obj) \
PyAPI_FUNC(type) _Py_Get_##obj(void);
#define PyAPI_GETIMPLPTR(type, obj) \
PyAPI_FUNC(type) _Py_Get_##obj(void) { return (type)&obj; }
#define _PYGETPTR(obj) _Py_Get_##obj()
#else
/* on systems where data can be accessed directly in shared modules,
* as an optimisation, return the object itself, directly.
*/
#define PyAPI_GETFNIMPL(obj) ;
#define PyAPI_GETHDR(type, obj) ;
#define PyAPI_GETIMPL(type, obj) ;
#define PyAPI_GETIMPLPTR(type, obj) ;
#define _PYGET(obj) (obj)
#define _PYGETPTR(obj) (&obj)
#endif /* defined(MS_WINDOWS) || defined(__MINGW32__)*/
as you can see from the Py_None example, on non-dll-based systems, you
get... wow, a macro which returns... exactly what was returned before.
zero impact.
on windows, you end up defining, creating and using a "getter"
function. two types. one which returns the object, the other returns
a pointer to the object.
l.
___
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
Re: [Python-Dev] [Python-checkins] PEP 374
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 25, 2009, at 11:49 AM, Antoine Pitrou wrote: Barry Warsaw python.org> writes: Besides, certain developments like support for the svn wire protocol in bzr would make the WFC (we fear change :) argument moot. This is an argument *against* the usefulness of switching! Why? This simply allows those who are happy with the status quo to live peacefully with those who want the benefits of the new capabilities. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSXyjW3EjvBPtnXfVAQLZHwP/UAwA/fcfaDDoaQI1Qa0F50u57AESc/GN bPIgUe6I93fwgAHx/+9jQWxgVJCjIOWlSavZqtLOr7nPR6gN4B27d4XpntLE7O47 3JXkV5QEZL0YDob0M33qAPSgPZsMv1++fWo9FDrk0o9SVzmsrP4OytsUsykRiOkC gkMtAPnzeAQ= =j2t2 -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] [Python-checkins] PEP 374
Barry Warsaw python.org> writes: > >> > >> Besides, certain developments like support for the svn wire protocol > >> in bzr would make the WFC (we fear change :) argument moot. > > > > This is an argument *against* the usefulness of switching! > > Why? > > This simply allows those who are happy with the status quo to live > peacefully with those who want the benefits of the new capabilities. Hmm, perhaps I misunderstood what you were saying... Would the bzr client allow accessing an svn server, or the reverse? (please note that we already have bzr, hg and git mirrors. So it's not like people wanting to use a DVCS are out of solutions) ___ 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
Re: [Python-Dev] [Python-checkins] PEP 374
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 25, 2009, at 12:44 PM, Antoine Pitrou wrote: Barry Warsaw python.org> writes: Besides, certain developments like support for the svn wire protocol in bzr would make the WFC (we fear change :) argument moot. This is an argument *against* the usefulness of switching! Why? This simply allows those who are happy with the status quo to live peacefully with those who want the benefits of the new capabilities. Hmm, perhaps I misunderstood what you were saying... Would the bzr client allow accessing an svn server, or the reverse? The reverse. IIUC, the bzr server would be able to speak to svn clients. bzr supports a centralized model perfectly fine along side a decentralized model, so any current developers who want to continue using their svn client can do so, and everyone else could use the bzr client to work decentralized. (please note that we already have bzr, hg and git mirrors. So it's not like people wanting to use a DVCS are out of solutions) Right, but ideally the server would support the full distributed model and users wold chose which client and models they are most comfortable with. One option would be to promote the mirrors to official status, but this is clunky because svn has a less complete model than a dvcs so it's more difficult to go in that direction. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSXymlXEjvBPtnXfVAQJAoAP/SAqlCiEB883wLH1eXrkiMxc5MlChodqt BHBdaO2kZgs0rJCfGfoVD/ly65tuheahP5lwMsoa6don6uKD7lkzJkvBSNjtg1ZL 4U/MTIQWtg8WbDJUPaPT8ArV9Xo6/Y+B1yeFz+Ge5hY29+PGEop9pAYOXKUl/Jyk hTlhbuXQqkA= =haid -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
> There's a possible third way. I've heard (though haven't investigated) > that some people are working on supporting the svn wire protocol in the > bzr server. This would mean that anybody who's still comfortable with > svn and feels no need to change their current habits can continue to > work the way they always have. Those that want the extra benefits of a > DVCS, or who do not have commit access to the code.python.org branches > would have viable alternatives. Of course, those without commit access *already* have viable alternatives, IIUC, by means of the automatic ongoing conversion of the svn repository to bzr and hg (and, IIUC, git - or perhaps you can use git-svn without the need for server-side conversion). So a conversion to a DVCS would only benefit those committers who see a benefit in using a DVCS (*) (and would put a burden on those committers who see a DVCS as a burden). It would also put a burden on contributors who are uncomfortable with using a DVCS. Regards, Martin (*) I'm probably missing something, but ISTM that committers can already use the DVCS - they only need to create a patch just before committing. This, of course, is somewhat more complicated than directly pushing the changes to the server, but it still gives them most of what is often reported as the advantage of a DVCS (local commits, ability to have many branches simultaneously, ability to share work-in-progress, etc). In essence, committers wanting to use a DVCS can do so today, by acting as if they were non-committers, and only using svn for actual changes to the master repository. ___ 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
Re: [Python-Dev] microsoft dlls apparently don't support data. implications: PyAPI functions required to access data across modules.
> On Sun, Jan 25, 2009 at 9:01 AM, Matthieu Brucher > wrote: > > 2009/1/25 Luke Kenneth Casson Leighton : > >> according to the wikipedia entry on dlls, dlls do not support data, > >> only functions. > > > > What do you mean by "not support data"? Having global data variables in a > > dll? > > In wikipedia, it is explicitely told that this is possible to have > > data (http://en.wikipedia.org/wiki/Dynamic-link_library). Without > > them, shared library cannot be used. matthieu, thank you for responding. from http://en.wikipedia.org/wiki/Dynamic-link_library: "Third, dynamic linking is inherently the wrong model for paged memory managed systems. Such systems work best with the idea that code is invariant from the time of assembly/compilation on. ... Data references do not need to be so vectored because DLLs do not share data." does anyone happen to know what this means? also, what do you mean by "without data, shared library cannot be used"? you can _always_ call a function which returns a pointer to the data, rather than access the data directly. > Indeed. That's why the header files contain > define PyAPI_DATA(RTYPE) extern __declspec(dllexport) RTYPE > define PyAPI_DATA(RTYPE) extern __declspec(dllimport) RTYPE curt, thank you for responding. i'd seen this: i understood it - and... yet... mingw happily segfaults when asked to access _any_ data in _any_ object file of the python2N dll. Py_NoneStruct, PyExc_* (of which there are about 50), Py*_Type - all of them. solutions so far involve ensuring that anything declared with PyAPI_DATA is *NEVER* accessed [across a dll boundary] - by for example moving the module into python2N.dll. also, yes i had looked up how to do .def files, and how __declspec(dllexport) etc. work. of all the examples that you find about dlltool, mingw, dlls, defs, etc. they _all_ say "function." to declare a _function_ you do X, Y and Z. not one of them says "to place data in a dll, you do X Y and Z". then, looking at the wine dlls and .defs, i haven't yet found a _single_ one which returns data - they're _all_ functions (from looking so far. e.g. i expected MSVCRT.DLL errno to be an int - it's not: it's a function). *sigh*. if this turns out to be yet another gcc / mingw bug i'm going to be slightly annoyed. only slightly, because this _is_ free software, after all :) l. ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
Martin v. Löwis v.loewis.de> writes: > In > essence, committers wanting to use a DVCS can do so today, by acting > as if they were non-committers, and only using svn for actual changes > to the master repository. Indeed. It is how I work. Regards Antoine. ___ 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] Issue 4285 Patch
Hello, python-dev! My name is Ross Light. I was a documentation contributor at GHOP a couple years back and I wanted to start contributing to the core interpreter. I found Issue 4285 and decided to write a patch for it. This is my first patch, so I'd like someone to review my patch and make sure I'm doing things right. http://bugs.python.org/issue4285 Thanks! Cheers, Ross Light ___ 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
Re: [Python-Dev] microsoft dlls apparently don't support data. implications: PyAPI functions required to access data across modules.
> Luke Kenneth Casson Leighton schrieb: > > i mean... has anyone _written_ a third party module that returns > > Py_None on a c-code module and had it compiled on windows? > Lot's of people have written 3rd party extensions that work on Windows > and can return a Py_None object. ahh - ok. so... i will have to find out what the heck is going on... ohno, it couldn't be as simple as i left out "DATA" on the lines of the export files, could it?? :) > Please stop spamming the Python developer list with irrelevant, wrong, > confusing and sometimes offensive messages. To be perfectly honest it's > annoying. i'm sorry to hear that you believe my messages to be sometimes offensive. i'm sorry that you are annoyed. i'm sorry that i am learning about things and that i believe that people would like to help cooperate on the development of python as a free software project, by helping point me in the right directions. i'm sorry that i am unable to get things perfect the first time, so that i have to ask people for help and advice, and i'm sorry that you are annoyed by my asking. > If you want to propose a new feature then python-ideas is the right > mailing list. thank you for informing me of that - i was not aware of that list: i believed that the python-dev mailing list would be the location for discussion of development and ports of python. l. ___ 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] Issue 4285 Patch
Hello, python-dev! My name is Ross Light. I was a documentation contributor at GHOP a couple years back and I wanted to start contributing to the core interpreter. I found Issue 4285 and decided to write a patch for it. This is my first patch, so I'd like someone to review my patch and make sure I'm doing things right. http://bugs.python.org/issue4285 Thanks! Cheers, Ross Light ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
On Sun, Jan 25, 2009 at 10:37, "Martin v. Löwis" wrote: >> There's a possible third way. I've heard (though haven't investigated) >> that some people are working on supporting the svn wire protocol in the >> bzr server. This would mean that anybody who's still comfortable with >> svn and feels no need to change their current habits can continue to >> work the way they always have. Those that want the extra benefits of a >> DVCS, or who do not have commit access to the code.python.org branches >> would have viable alternatives. > > Of course, those without commit access *already* have viable > alternatives, IIUC, by means of the automatic ongoing conversion of > the svn repository to bzr and hg (and, IIUC, git - or perhaps you > can use git-svn without the need for server-side conversion). > > So a conversion to a DVCS would only benefit those committers who > see a benefit in using a DVCS (*) (and would put a burden on those > committers who see a DVCS as a burden). It would also put a burden > on contributors who are uncomfortable with using a DVCS. > > Regards, > Martin > > (*) I'm probably missing something, but ISTM that committers can already > use the DVCS - they only need to create a patch just before committing. > This, of course, is somewhat more complicated than directly pushing the > changes to the server, but it still gives them most of what is often > reported as the advantage of a DVCS (local commits, ability to have many > branches simultaneously, ability to share work-in-progress, etc). In > essence, committers wanting to use a DVCS can do so today, by acting > as if they were non-committers, and only using svn for actual changes > to the master repository. > If I can't choose a clear winner I am going to look into what it take to run directly on top of svn to avoid the extra step for committers. Otherwise I will get standardized instructions for the three DVCSs and maybe write a script or three to make it dead-simple to work with the DVCSs but have our official repository be svn so we can all use the DVCSs as we see fit until a clear winner springs up. -Brett ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
Brett Cannon wrote: On Sun, Jan 25, 2009 at 10:37, "Martin v. Löwis" wrote: There's a possible third way. I've heard (though haven't investigated) that some people are working on supporting the svn wire protocol in the bzr server. This would mean that anybody who's still comfortable with svn and feels no need to change their current habits can continue to work the way they always have. Those that want the extra benefits of a DVCS, or who do not have commit access to the code.python.org branches would have viable alternatives. Of course, those without commit access *already* have viable alternatives, IIUC, by means of the automatic ongoing conversion of the svn repository to bzr and hg (and, IIUC, git - or perhaps you can use git-svn without the need for server-side conversion). So a conversion to a DVCS would only benefit those committers who see a benefit in using a DVCS (*) (and would put a burden on those committers who see a DVCS as a burden). It would also put a burden on contributors who are uncomfortable with using a DVCS. Regards, Martin (*) I'm probably missing something, but ISTM that committers can already use the DVCS - they only need to create a patch just before committing. This, of course, is somewhat more complicated than directly pushing the changes to the server, but it still gives them most of what is often reported as the advantage of a DVCS (local commits, ability to have many branches simultaneously, ability to share work-in-progress, etc). In essence, committers wanting to use a DVCS can do so today, by acting as if they were non-committers, and only using svn for actual changes to the master repository. If I can't choose a clear winner I am going to look into what it take to run directly on top of svn to avoid the extra step for committers. Otherwise I will get standardized instructions for the three DVCSs and maybe write a script or three to make it dead-simple to work with the DVCSs but have our official repository be svn so we can all use the DVCSs as we see fit until a clear winner springs up. Well, that sounds like an ideal situation to end up in. Is there a downside other than the work it creates for you? Michael -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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
Re: [Python-Dev] progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
Roumen Petrov wrote: Cesare Di Mauro wrote: Have you made some benchmarks like pystone? Its seems to me version 2.6.1 is not optimized build so I remove(uninstall) it. I repeat the pystone tests with an optimized GCC(mingw32) build. - python-trunk-GCC(mingw32, local, native, optimized) -- shell=cmd.exe 35453,3; 35700,4; 35747,3; 35615,5; 35632,3; 35661,8; 35547,1 average=35622,5 deviation=98,0 -- shell=bash.exe(msys) 36002,1; 35884,4; 35961,7; 35859,5; 35997,3; 36062,9; 35747,1 average=35930,7 deviation=107,2 - python-2.6-MSVC -- shell=cmd.exe 35891,3; 35827,9; 35791,3; 35901,7; 35876,5; 36081,1; 36149,2 average=35931,3 deviation=132,7 -- shell=bash.exe(msys) 35532,9; 35621,1; 35526,8; 35639,4; 35671,2; 35702,4; 35633,0; average=35618,1 deviation=66,1 I don't have idea why performance of official python 2.6 goes down(see previous results below). It is same PC. Every tested program load own files. The result show unexpected behaviour: - the MSVC build is faster by ~0.9% if it is run under cmd.exe then msys bash; - the GCC build is faster by ~0.9% if it is run under msys bash. Otherwise results lock similar but note that builds use different source base and in this case we may can't compare. The old results: There is result from pystone test test run an old PC (NT 5.1): - 2.6(official build): 42194,6; 42302,4; 41990,8; 42658,0; 42660,6; 42770,1 average=42429,4 deviation=311,6 - 2.6.1(official build): 35612,1; 35778,8; 35666,7; 35697,9; 35514,9; 35654,0 average=35654,1 deviation=88,1 - trunk(my mingw based build): 35256,7; 35272,5; 35247,2; 35270,7; 35225,6; 35233,5 average=35251,0 deviation=19,2 There is problem with python performance between 2.6 and 2.6.1 ~ 19% :(. Also the test for GCC-mingw is not with same source base. Roumen Roumen ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
On Sun, Jan 25, 2009 at 13:03, Michael Foord wrote: > Brett Cannon wrote: >> >> On Sun, Jan 25, 2009 at 10:37, "Martin v. Löwis" >> wrote: >> There's a possible third way. I've heard (though haven't investigated) that some people are working on supporting the svn wire protocol in the bzr server. This would mean that anybody who's still comfortable with svn and feels no need to change their current habits can continue to work the way they always have. Those that want the extra benefits of a DVCS, or who do not have commit access to the code.python.org branches would have viable alternatives. >>> >>> Of course, those without commit access *already* have viable >>> alternatives, IIUC, by means of the automatic ongoing conversion of >>> the svn repository to bzr and hg (and, IIUC, git - or perhaps you >>> can use git-svn without the need for server-side conversion). >>> >>> So a conversion to a DVCS would only benefit those committers who >>> see a benefit in using a DVCS (*) (and would put a burden on those >>> committers who see a DVCS as a burden). It would also put a burden >>> on contributors who are uncomfortable with using a DVCS. >>> >>> Regards, >>> Martin >>> >>> (*) I'm probably missing something, but ISTM that committers can already >>> use the DVCS - they only need to create a patch just before committing. >>> This, of course, is somewhat more complicated than directly pushing the >>> changes to the server, but it still gives them most of what is often >>> reported as the advantage of a DVCS (local commits, ability to have many >>> branches simultaneously, ability to share work-in-progress, etc). In >>> essence, committers wanting to use a DVCS can do so today, by acting >>> as if they were non-committers, and only using svn for actual changes >>> to the master repository. >>> >>> >> >> If I can't choose a clear winner I am going to look into what it take >> to run directly on top of svn to avoid the extra step for committers. >> Otherwise I will get standardized instructions for the three DVCSs and >> maybe write a script or three to make it dead-simple to work with the >> DVCSs but have our official repository be svn so we can all use the >> DVCSs as we see fit until a clear winner springs up. >> > > Well, that sounds like an ideal situation to end up in. Is there a downside > other than the work it creates for you? What, isn't creating even more work from me enough of a downside? =) There is also the issue of support. If we as a development team start using four different VCSs then that will severely cut down on who can help whom. The only reason I have been able to keep the dev FAQ full of such key svn commands is because inevitably someone on this list knew how to do something if I didn't. Spread that across three more DVCSs and the chances of someone knowing the best solution for something dwindles. It also means three more VCSs to keep up and running on code.python.org. While it has worked so far, that's just because we have been going with what Debian stable has. If you want some new-fangled thing, e.g. bzr's 1.9 tree support which apparently makes a huge performance difference (Barry is on vacation but I am prodding him to put the details in the PEP when he gets back) someone will then need to step up that we trust to stay on top of security patches, etc. So yes, it's a nice solution if a winner cannot be chosen, but I don't think that should necessarily be the end of this quite yet. -Brett ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 25, 2009, at 1:37 PM, Martin v. Löwis wrote: (*) I'm probably missing something, but ISTM that committers can already use the DVCS - they only need to create a patch just before committing. This, of course, is somewhat more complicated than directly pushing the changes to the server, but it still gives them most of what is often reported as the advantage of a DVCS (local commits, ability to have many branches simultaneously, ability to share work-in-progress, etc). In essence, committers wanting to use a DVCS can do so today, by acting as if they were non-committers, and only using svn for actual changes to the master repository. The approach you outline also has the disadvantages of losing history at the point of patch generation, and causing a discontinuity in the chain of revisions leading up to that point. Depending on the specific changes being merged, this may or may not be important. You're right that we can do this today, but I still believe there are advantages to supporting a DVCS for the official branches. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSXzkjnEjvBPtnXfVAQIUOAP/SLkPAkIqDKNpoIpbaCJTsoLwFsSKj58P ISKqF7QkMgjl+cnw4YngHHwJr+OniX4cR1Wc5S9LPB3xMgsoOtxqYWmvfG1ReJRs fbmI1iOOCmOY1MltRlPErihS3wk7+37pc4lIkEvClvZMRcoLq3JjborIQjiy0ORY pqmovGlx/AI= =wXVD -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] Operator module deprecations
+1 indeedy.
On Sat, Jan 24, 2009 at 5:22 PM, Nick Coghlan wrote:
> Brett Cannon wrote:
>> On Sat, Jan 24, 2009 at 14:46, Raymond Hettinger wrote:
>>> I would like to deprecate some outdated functions in the operator module.
>>>
>>> The isSequenceType(), isMappingType(), and isNumberType()
>>> functions never worked reliably and now their
>>> intended purpose has been largely fulfilled by
>>> ABCs.
>>>
>>> The isCallable() function has long been deprecated
>>> and I think it's finally time to rip it out.
>>>
>>> The repeat() function never really corresponded to an
>>> operator. Instead, it reflected an underlying implementation detail (namely
>>> the naming of the sq_repeat slot and the abstract C API function
>>> PySequence_Repeat). That functionality is already exposed by operator.mul:
>>>
>>> operator.mul('abc', 3) --> 'abcabcabc'
>>
>> +1 to all of it.
>
> What Brett said.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | [email protected] | Brisbane, Australia
> ---
> ___
> Python-Dev mailing list
> [email protected]
> 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
[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] Changes needed for python-2.6.spec to build successfully
Hello, I'm not subscribed to this list, but this is the best place I could think of to send this. Please feel free to ignore if this has already been addressed, or if I've approached it completely wrong. When trying to perform an rpmbuild of the python-2.6.1 tarball on my CentOS 5.1 system using the included python-2.6.spec file, I ran into a bunch of vexing problems. My solution to them is included in the diff to the specfile attached. Some of these fixes are probably not appropriate for everyone (eg: my need for shared libs, vs static). I hope this saves someone else a bit of time. :) python-2.6.spec.diff Description: Binary data Cheers, Pat Patrick Toal [email protected] ___ 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
Re: [Python-Dev] Changes needed for python-2.6.spec to build successfully
Patrick Toal schrieb: > Hello, > > I'm not subscribed to this list, but this is the best place I could > think of to send this. Please feel free to ignore if this has already > been addressed, or if I've approached it completely wrong. > > When trying to perform an rpmbuild of the python-2.6.1 tarball on my > CentOS 5.1 system using the included python-2.6.spec file, I ran into a > bunch of vexing problems. My solution to them is included in the diff > to the specfile attached. Some of these fixes are probably not > appropriate for everyone (eg: my need for shared libs, vs static). > > I hope this saves someone else a bit of time. :) Thanks Patrick! Please open a ticket in our tracker and attach your patch. Patches in mails tend to get lost. Christian ___ 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
Re: [Python-Dev] Changes needed for python-2.6.spec to build successfully
> I hope this saves someone else a bit of time. :) Please submit the parts that you consider of general use to the bug tracker, so we can include it in future releases. Regards, Martin ___ 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
Re: [Python-Dev] Operator module deprecations
For Py3.0.1, can we just rip these out and skip deprecation?
I don't think they will be missed at all.
Raymond
- Original Message -
From: "Guido van Rossum"
To: "Nick Coghlan"
Cc:
Sent: Sunday, January 25, 2009 2:50 PM
Subject: Re: [Python-Dev] Operator module deprecations
+1 indeedy.
On Sat, Jan 24, 2009 at 5:22 PM, Nick Coghlan wrote:
Brett Cannon wrote:
On Sat, Jan 24, 2009 at 14:46, Raymond Hettinger wrote:
I would like to deprecate some outdated functions in the operator module.
The isSequenceType(), isMappingType(), and isNumberType()
functions never worked reliably and now their
intended purpose has been largely fulfilled by
ABCs.
The isCallable() function has long been deprecated
and I think it's finally time to rip it out.
The repeat() function never really corresponded to an
operator. Instead, it reflected an underlying implementation detail (namely
the naming of the sq_repeat slot and the abstract C API function
PySequence_Repeat). That functionality is already exposed by operator.mul:
operator.mul('abc', 3) --> 'abcabcabc'
+1 to all of it.
What Brett said.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python%40rcn.com
___
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
Re: [Python-Dev] Operator module deprecations
Since 3.0.1 is going to do a couple of these already, I think that's fine.
On Sun, Jan 25, 2009 at 3:50 PM, Raymond Hettinger wrote:
> For Py3.0.1, can we just rip these out and skip deprecation?
> I don't think they will be missed at all.
>
> Raymond
>
> - Original Message - From: "Guido van Rossum"
> To: "Nick Coghlan"
> Cc:
> Sent: Sunday, January 25, 2009 2:50 PM
> Subject: Re: [Python-Dev] Operator module deprecations
>
>
>> +1 indeedy.
>>
>> On Sat, Jan 24, 2009 at 5:22 PM, Nick Coghlan wrote:
>>>
>>> Brett Cannon wrote:
On Sat, Jan 24, 2009 at 14:46, Raymond Hettinger wrote:
>
> I would like to deprecate some outdated functions in the operator
> module.
>
> The isSequenceType(), isMappingType(), and isNumberType()
> functions never worked reliably and now their
> intended purpose has been largely fulfilled by
> ABCs.
>
> The isCallable() function has long been deprecated
> and I think it's finally time to rip it out.
>
> The repeat() function never really corresponded to an
> operator. Instead, it reflected an underlying implementation detail
> (namely
> the naming of the sq_repeat slot and the abstract C API function
> PySequence_Repeat). That functionality is already exposed by
> operator.mul:
>
> operator.mul('abc', 3) --> 'abcabcabc'
+1 to all of it.
>>>
>>> What Brett said.
>>>
>>> Cheers,
>>> Nick.
>>>
>>> --
>>> Nick Coghlan | [email protected] | Brisbane, Australia
>>> ---
>>> ___
>>> Python-Dev mailing list
>>> [email protected]
>>> 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
>> [email protected]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/python%40rcn.com
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Incorrect documentation (and possibly implementation) for rlcompleter.Completer?
The documentation at http://docs.python.org/library/rlcompleter.html
claims that
Completer.complete(text, state)¶
Return the state*th completion for *text.
If called for text that doesn’t include a period character
('.'), it will complete from names currently defined in __main__,
__builtin__ and keywords (as defined by the keyword module).
If called for a dotted name, it will try to evaluate anything
without obvious side-effects (functions will not be evaluated, but
it can generate calls to __getattr__()) up to the last part, and
find matches for the rest via the dir() function. Any exception
raised during the evaluation of the expression is caught, silenced
and None is returned.
In other words, it claims to use dir(obj) as part of the tab
completion process. This is not true (using Python 2.6.1 on OS X):
>>> class B(object):
... def __dir__(self): return dir(u"") #Makes B objects look like
strings
...
>>> b = B()
>>> dir(b)
['__add__', '__class__', '__contains__', '__delattr__', '__doc__',
'__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__',
'__getnewargs__', '__getslice__', '__gt__', '__hash__', '__init__',
'__le__', '__len__', '__lt__', '__mod__', '__mul__', '__ne__',
'__new__', '__reduce__', '__reduce_ex__', '__repr__', '__rmod__',
'__rmul__', '__setattr__', '__sizeof__', '__str__',
'__subclasshook__', '_formatter_field_name_split',
'_formatter_parser', 'capitalize', 'center', 'count', 'decode',
'encode', 'endswith', 'expandtabs', 'find', 'format', 'index',
'isalnum', 'isalpha', 'isdecimal', 'isdigit', 'islower', 'isnumeric',
'isspace', 'istitle', 'isupper', 'join', 'ljust', 'lower', 'lstrip',
'partition', 'replace', 'rfind', 'rindex', 'rjust', 'rpartition',
'rsplit', 'rstrip', 'split', 'splitlines', 'startswith', 'strip',
'swapcase', 'title', 'translate', 'upper', 'zfill']
>>> c = rlcompleter.Completer()
>>> c.complete("b.", 0) #Notice that it does NOT return __add__
u'b.__class__('
>>> c.matches #Notice that this list is completely different from the
list given by dir(b)
[u'b.__class__(', u'b.__delattr__(', u'b.__doc__', u'b.__format__(',
u'b.__getattribute__(', u'b.__hash__(', u'b.__init__(', u'b.__new__(',
u'b.__reduce__(', u'b.__reduce_ex__(', u'b.__repr__(',
u'b.__setattr__(', u'b.__sizeof__(', u'b.__str__(',
u'b.__subclasshook__(', u'b.__class__(', u'b.__class__(',
u'b.__delattr__(', u'b.__dict__', u'b.__dir__(', u'b.__doc__',
u'b.__format__(', u'b.__getattribute__(', u'b.__hash__(',
u'b.__init__(', u'b.__module__', u'b.__new__(', u'b.__reduce__(',
u'b.__reduce_ex__(', u'b.__repr__(', u'b.__setattr__(',
u'b.__sizeof__(', u'b.__str__(', u'b.__subclasshook__(',
u'b.__weakref__', u'b.__class__(', u'b.__delattr__(', u'b.__doc__',
u'b.__format__(', u'b.__getattribute__(', u'b.__hash__(',
u'b.__init__(', u'b.__new__(', u'b.__reduce__(', u'b.__reduce_ex__(',
u'b.__repr__(', u'b.__setattr__(', u'b.__sizeof__(', u'b.__str__(',
u'b.__subclasshook__(']
As I see it, there are two ways to fix the problem: Change the
documentation or change rlcompleter.Complete. I think the latter
option is preferable (although it might have to wait for Python
2.7/3.1), but I thought I would ask other people if I'm missing
something and if not which fix is preferred. If other people agree
that it's a bug, I'll file it.
-- Carl Johnson
___
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
Re: [Python-Dev] Incorrect documentation (and possibly implementation) for rlcompleter.Completer?
Carl Johnson wrote: > As I see it, there are two ways to fix the problem: Change the > documentation or change rlcompleter.Complete. I think the latter option > is preferable (although it might have to wait for Python 2.7/3.1), but I > thought I would ask other people if I'm missing something and if not > which fix is preferred. If other people agree that it's a bug, I'll file > it. It needs to go on the tracker regardless of whether the problem is in the documentation or in the implementation, so file away. Given that rlcompleter already evaluates the expression preceding the last "." when asked to perform a completion, you're probably right that actually invoking dir() on the result as the documentation claims is the way to go. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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
Re: [Python-Dev] Incorrect documentation (and possibly implementation) for rlcompleter.Completer?
On 2009/01/25, at 3:22 pm, Nick Coghlan wrote: It needs to go on the tracker regardless of whether the problem is in the documentation or in the implementation, so file away. Issue #5062: http://bugs.python.org/issue5062 -- Carl Johnson ___ 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
Re: [Python-Dev] microsoft dlls apparently don't support data. implications: PyAPI functions required to access data across modules.
Luke Kenneth Casson Leighton wrote: > i'm sorry to hear that you believe my messages to be sometimes > offensive. i'm sorry that you are annoyed. i'm sorry that i am > learning about things and that i believe that people would like to > help cooperate on the development of python as a free software > project, by helping point me in the right directions. i'm sorry that i > am unable to get things perfect the first time, so that i have to ask > people for help and advice, and i'm sorry that you are annoyed by my > asking. Nice job with the fake-apology-that-is-actually-an-attack maneuver there. I believe the main complaint is that you clearly have not exercised enough due diligence to find the answers yourself before asking on the list. There are a number of examples in this very thread of you replying to yourself because you just figured out something new that you didn't in the previous email. You should not consider this list an open forum for stream-of-thought style emails. Pointed, well-explored questions are the only sort that will be useful to you (in getting people to read your questions and answer them) and the community (in not having an enormous amount of low-SNR emails to sort through). These threads with obviously disprovable "facts" are not useful to anyone at-large, whether they are (dubiously) educational to you or not -- it would be more educational for you to explore your assumption and find out it's wrong all on your own. >> If you want to propose a new feature then python-ideas is the right >> mailing list. > > thank you for informing me of that - i was not aware of that list: i > believed that the python-dev mailing list would be the location for > discussion of development and ports of python. As far as I can tell, you have replied to your own threads more than anyone else on the mailing list, and you should interpret that as a general lack of interest from the developers reading this list. I think it's been made clear that nobody is opposed to having an all-free build of Python for Win32, however it is not the focus of anyone's interest here because it's "free enough" for our purposes. I believe Martin wrote you a reply that explained that quite well. -- Scott Dial [email protected] [email protected] ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
Regardless of the outcome, those that want to use SVN can use SVN, and those that want to use "chosen DVCS" can use that. In the end, which is the more "lossy" repository? It seems like if the change is transparent to everyone who is using it, then the only thing that we care about is that the chosen backend will preserve all the information to make it truly transparent to everyone involved. Jared On 25 Jan 2009, at 10:37, Martin v. Löwis wrote: There's a possible third way. I've heard (though haven't investigated) that some people are working on supporting the svn wire protocol in the bzr server. This would mean that anybody who's still comfortable with svn and feels no need to change their current habits can continue to work the way they always have. Those that want the extra benefits of a DVCS, or who do not have commit access to the code.python.org branches would have viable alternatives. Of course, those without commit access *already* have viable alternatives, IIUC, by means of the automatic ongoing conversion of the svn repository to bzr and hg (and, IIUC, git - or perhaps you can use git-svn without the need for server-side conversion). So a conversion to a DVCS would only benefit those committers who see a benefit in using a DVCS (*) (and would put a burden on those committers who see a DVCS as a burden). It would also put a burden on contributors who are uncomfortable with using a DVCS. Regards, Martin (*) I'm probably missing something, but ISTM that committers can already use the DVCS - they only need to create a patch just before committing. This, of course, is somewhat more complicated than directly pushing the changes to the server, but it still gives them most of what is often reported as the advantage of a DVCS (local commits, ability to have many branches simultaneously, ability to share work-in-progress, etc). In essence, committers wanting to use a DVCS can do so today, by acting as if they were non-committers, and only using svn for actual changes to the master repository. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jared.grubb%40gmail.com ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
"Martin v. Löwis" writes: > So a conversion to a DVCS would only benefit those committers who > see a benefit in using a DVCS (*) (and would put a burden on those > committers who see a DVCS as a burden). That's false. Especially with bzr, they would see improved log formats by default, and with git they'd have access to some very advanced and powerful history querying, even if the update-hack- commit side of the workflow doesn't change. Not having used these tools in most cases, the fact that they don't currently *perceive* a benefit from switching doesn't mean there won't be one. There's also the very high likelihood that if Python does switch to a DVCS, many such committers will start to use the distributed VCS features actively. That doesn't mean that it will fully offset the costs of the switch for them; it does mean that the net cost of the switch for them is probably a lot lower than it would appear from your description. > It would also put a burden on contributors who are uncomfortable > with using a DVCS. "Discomfort" is not something I take lightly, but I have to wonder how long that discomfort would persist. All of the DVCSes support exactly the same workflow as CVS/Subversion, with some change in naming, and possibly a need to have a trivial commit+push script to give a single command with the semantics of "svn commit". This is crystal clear if you look at the draft PEP 374, which deliberately emulates the Subversion workflow in a variety of scenarios. It's true that the svn workflow looks more efficient and/or natural in many places, but please remember that the current workflow has evolved to deal with the specific features of Subversion compared to the DVCSes, and has had years to evolve best practices, where the PEP authors have only had a few days. I suspect that (if a DVCS is adopted) both the workflow and the best practices will evolve naturally and without much additional cost of learning to users, and arrive at a similarly efficient, but more powerful, workflow, well within a year after adoption. So there might be some rough places around the edges, especially in coming up with a way to get the functionality of "svnmerge.py block", but as far as I can see, unless the project decides that it wants to adopt a decentralized workflow, the full cost of DVCS is simply learning a new VCS; the "D" has nothing to do with it. It won't be much harder than switching from CVS to Subversion. Again, I don't take the cost of learning a new tool lightly, but please let's call that cost by its name, and not bring "distributed" into it. > (*) I'm probably missing something, but ISTM that committers can already > use the DVCS - they only need to create a patch just before committing. That's true. It's also true that to have the benefit of distributed version control with Subversion, "they only need to run a Subversion server locally". In both cases, it amounts to a fair amount of extra effort, and misses out on all the benefits of improved merging, automatic propagation of history from a merged local branch to the master repo, etc., etc. > In essence, committers wanting to use a DVCS can do so today, by > acting as if they were non-committers, and only using svn for > actual changes to the master repository. That's false. Again, those people who want to use a DVCS as a DVCS will benefit from having the master repository(s) coordinate history for them. This doesn't work very well across VCS systems, essentially forcing all committers who want to use the distributed features to coordinate with each other directly, and only with those who use the same DVCS. The mental models used by git users, hg users, and bzr users differ significantly, though they probably differ more from the model that's appropriate for Subversion. Nevertheless, there is a lot of potential benefit to be gained from having a common DVCS for all developers. Whether the benefits available *today* and in the near future outweigh the costs of an early transition, I make no claims. But those benefits *are* fairly large, and much of the cost is subjective (based on the bad reputation of the DVCSes for UI awkwardness, especially that of git) and *may* (at this stage, I don't say "will") dissipate quickly with a rather small amount of experience. ___ 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
Re: [Python-Dev] PEP 374 (DVCS) now in reST
Michael Foord writes: > > If I can't choose a clear winner I am going to look into what it take > > to run directly on top of svn to avoid the extra step for committers. > Well, that sounds like an ideal situation to end up in. Is there a > downside other than the work it creates for you? I'm with Brett, the extra work for him is more than downside enough. But over and above that, the various DVCSes have different strengths and weaknesses, and their proponents have different mental models of how DVCS is "supposed" to work. I believe this is reflected to a great extent in their capabilities, creating great friction to trying to work with a different VCS from the "native" one of the master repositories. You just end up using a buttload of extra CPU cycles to achieve a Subversion-based workflow. The big advantage, IMO, to going to a DVCS for the master repo is that you can start with the same workflow currently used, and gradually adapt it to the capabilities of the more powerful tools. If we don't do that, the workflow will never really change, and the project-wide advantages of the tools will be lost. ___ 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
Re: [Python-Dev] microsoft dlls apparently don't support data. implications: PyAPI functions required to access data across modules.
On Sun, Jan 25, 2009 at 10:45 AM, Luke Kenneth Casson Leighton
wrote:
>
> from http://en.wikipedia.org/wiki/Dynamic-link_library:
>
> "Third, dynamic linking is inherently the wrong model for paged memory
> managed systems. Such systems work best with the idea that code is
> invariant from the time of assembly/compilation on.
> ... Data references do not need to be so vectored because
> DLLs do not share data."
That section ("The case against DLLs") should probably be ignored. It
appears to have been written by a single individual with a particular
axe to grind. Much of what it contains is opinion rather than fact,
and some of its facts are downright inaccurate -- at least by my
recollection.
I haven't thought much about any of this in well over ten years, but
here's what I remember:
The reason for the vectored importing of function addresses is
strictly performance -- it means that you only need to fixup one
location with the address of the target function instead of each
location in the code. This also has obvious advantages for paging.
But this may very well be a feature of the linker rather than the
operating system; I imagine the loader will happily fixup the same
address multiple times if you ask it to.
There are differences between importing code and importing data: the
code produced by the compiler for calling a function does not depend
on whether or not that function is defined in the current module or in
a different one -- under x86, they're both just CALL instructions.
But when accessing data, addresses in the current module can be used
directly while those in a different module must be indirected -- which
means that different opcodes must be generated. I don't know if it's
up-to-date, but the page at
http://sourceware.org/binutils/docs/ld/WIN32.html suggests some ways
of dealing with this for cygwin/mingw. Look for the section entitled
"automatic data imports".
If you have specific questions related to DLL or loader behavior under
Windows, feel free to ping me off-list. I can't guarantee that I can
provide an answer, but I may be able to point you in a particular
direction.
--
Curt Hagenlocher
[email protected]
___
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
