Martin v. Löwis wrote:
> Thomas Heller wrote:
>> Personally, I *like* the ctypes name. But I'm open for suggestions,
>> and it might have intersting consequences if the Python core package
>> would be renamed to something else.
>>
>> Any suggestions?
>
> Well, my only concern was py_object. I won
Thomas Heller wrote:
> Personally, I *like* the ctypes name. But I'm open for suggestions,
> and it might have intersting consequences if the Python core package
> would be renamed to something else.
>
> Any suggestions?
Well, my only concern was py_object. I wondered whether the py_
prefix is r
I suggest to ignore this thread. The OP seems clueless and the names
are fine. Don't waste your time.
On 4/21/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > Dennis Heuer wrote:
> >> Module names
> >> like hashlib are not python-like too (too c/lowlevel-like).
> >
> > I a
Martin v. Löwis wrote:
> Dennis Heuer wrote:
>> Module names
>> like hashlib are not python-like too (too c/lowlevel-like).
>
> I agree with Greg: hashlib is a Pythonic name for a module,
> just like httplib, mhlib, xmlrpclib, cookielib, contextlib,
> difflib, ...
>
> OTOH, it might be indeed tha
Dennis Heuer wrote:
> Module names
> like hashlib are not python-like too (too c/lowlevel-like).
I agree with Greg: hashlib is a Pythonic name for a module,
just like httplib, mhlib, xmlrpclib, cookielib, contextlib,
difflib, ...
OTOH, it might be indeed that the ctypes name need to be
aligned wi
> Module names like hashlib are not python-like too (too c/lowlevel-like).
what is python-like?
hashlib was chosen because it is a library of hash functions and
hash() is already taken as a builtin function (otherwise i'd leave off
the lib).
-g
___
Pyt
I read the python 2.5alpha release notes and found that some module and
class names should not make it into the official release. For example,
the name of the ctypes module is ok because the module is only of
special interest, but calls like py_object or create_string_buffer
should definetly be cha
