Fuzzyman wrote:
> Hello all,
>
> Feel free to shoot this down, but a suggestion.
>
> The operator module defines two functions :
>
> isMappingType
> isSquenceType
>
>
> These return a guesstimation as to whether an object passed in supports
> the mapping and sequence protocols.
>
> T
I know that my unittests should not rely on this, but is this change
intended?
c:\sf\ctypes_head>py24
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> str(Exception)
'exceptions.Exception'
>>>
Paul Moore wrote:
> On 3/7/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> At 06:29 AM 3/7/2006 +0100, Fredrik Lundh wrote:
>>> see subject and http://python.org/sf/1368955
>>>
>>> comments ?
>> would be nice if you could just call UUID() to create a generic UUID in a
>> platform-appropriate way.
Oleg Broytmann wrote:
> On Tue, Mar 07, 2006 at 10:19:03PM +0100, Thomas Heller wrote:
>> Too bad that ctypes whill be an optional module, so I'm
>> not sure if it could be used in the Python library itself.
>
> try:
>import ctypes
> except ImportError:
>
Brett Cannon wrote:
> On 3/7/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> I know that my unittests should not rely on this, but is this change
>> intended?
>>
>> c:\sf\ctypes_head>py24
>> Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310
Thomas Wouters wrote:
> [ Mailed to python-dev and python-list, as that should cover most of the
> users ;P ]
>
> There was a slight disruption on mail.python.org this morning. For about
> three and a half hours, it was rejecting most of its mail with the message:
>
> Client host [] blocked u
ctypes is in SVN now, and the buildbot is green, after I disabled a test that
dumped core
on sparc solaris. The crash was apparently caused
Missing are .vcproj files for Windows, both for the _ctypes.pyd extension and
the _ctypes_test.pyd
extension needed for testing. IIRC, Martin promised to
Giovanni Bajo wrote:
> Thomas Heller <[EMAIL PROTECTED]> wrote:
>
>> Missing are .vcproj files for Windows, both for the _ctypes.pyd extension
>> and the _ctypes_test.pyd extension needed for testing. IIRC, Martin
>> promised to create them - is this offer still va
Giovanni Bajo wrote:
> Thomas Heller <[EMAIL PROTECTED]> wrote:
>
>>> I discussed with Martin a bit about the opportunity of generating
>>> .vcproj files with a script-driven tool. I'm going to try and
>>> setup something as soon as I find some spare ti
Thomas Wouters wrote:
> On 3/9/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> ctypes is in SVN now, and the buildbot is green,
>
>
> Well, only by accident; Neal's amd64 machine has been offline, or you would
> have seen yellow blocks for warnings: ctypes has
t;> mindlessly from time to time, checking in whatever it
>>> happens to do ;-)
>
> [Thomas Heller]
>> Should 'sln' and 'vcproj' be added to the extensions list? I think these are
>> text-files too. Although PCBuild\pcbuild.sln has a binary mime-ty
Tim Peters wrote:
> [Thomas Heller]
>> ...
>> And I never had tried it before on a sparc machine - all the intel and ppc
>> processors
>> seem to have no problems with it.
>
> Pentiums don't enforce "natural" alignment restrictions, but run much
&
Tim Peters wrote:
> [Thomas Heller]
>> ...
>> I could do that myself, but only for x86, while other .pyd files also have
>> build
>> settings for Itanium and x86_64. (I find it always very painful to click
>> through
>> the settings dialog in MSVC - is
Tim Peters wrote:
> [Thomas Heller]
>> ...
>> The Linux-head is the release manager, prepaing the release on
>> a unixish platform, in combination with the windows guy who downloads
>> the source distribution and tries to compile that on Windows.
>
> That s
Thomas Wouters wrote:
(about ctypes and Py_ssize_t)
>> you want to do that yourself, or do you want me to submit a patch? (Or I
>>> could just check it in ;)
>> You can do it faster then me, I assume - so go ahead and check it in.
>> I'll backport it to the upstream ctypes CVS repository.
>
>
> I
[CC to python-dev again]
Hye-Shik Chang wrote:
> On 3/10/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> Hye-Shik Chang wrote:
>>> On 3/9/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>>>> I've now committed ctypes 0.9.9.4 into SVN. It seems to build
Thomas Wouters wrote:
> On 3/10/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>
>> Would it be a solution to move the 'official' ctypes development into
>> Python SVN external/ctypes, or would this be considered abuse? Another
>> location in SVN could b
Tim Peters wrote:
> [Thomas Heller]
>> ...
>> In the meantime, please: If anyone is going to make fixes to the ctypes
>> source
>> code (apart from Tim's regular whitespace cleanup), please do this in the
>> ctypes CVS repository on sourceforge, in the
Tim Peters wrote:
> [Thomas Heller]
>> ...
>> And I never had tried it before on a sparc machine - all the intel and ppc
>> processors
>> seem to have no problems with it.
>
> Pentiums don't enforce "natural" alignment restrictions, but run much
&
Martin v. Löwis wrote:
> Thomas Heller wrote:
>> BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine:
>
> FWIW, ctypes doesn't even build on a Windows AMD64 machine. It wants to
> use the Windows x86 FFI code, which does not compile with the AMD64
Neal Norwitz wrote:
> On 3/10/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine:
>>
>> http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0
>>
>> Is
Martin v. Löwis wrote:
> Josiah Carlson told me had has given up getting a Windows
> buildbot running, because every time he installed VS.NET
> on his machine, the installation would immediately crash.
>
> So if anybody wants to contribute both a machine and time
> to operate it (including the lik
Thomas Wouters wrote:
> On 3/10/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Thomas Heller wrote:
>>> BTW: The buildbot reports ctypes test failures on the gentoo amd64
>> machine:
>>>
>> http://www.python.org/dev/buildbot/trunk/amd64
Trent Mick wrote:
> Yup. Looks like my build worked. Another TODO now though:
>
> - Figure out why usage of:
> winsound.PlaySound(, winsound.SND_ALIAS)
> fails on my Win2k box. This is why the test suite fails on that box.
>
Doesn't that always fail when there is no soundcard in the machi
Neal Norwitz wrote:
> On 3/9/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> Would it be a solution to move the 'official' ctypes development into
>> Python SVN external/ctypes, or would this be considered abuse? Another
>> location in SVN could be used as w
Tim Peters wrote:
> [Martin]
>> ...
>> I believe it does: the ctypes maintainer wants to keep the
>> code identical across releases (AFAICT).
Correct, that's why I listed it in PEP 291.
> Fair enough -- I reverted the checkin. It's going to need #if'ery on
> the Python version, though, if it wan
Fredrik Lundh wrote:
> the definition of sys.executable is a bit unclear, something that has led to
> incompatible use in deployed code.
>
> the docstring for sys.executable says "pathname of this Python interpreter",
> which can be interpreted as either
>
> a) sys.executable points to the ex
Martin v. Löwis wrote:
> Thomas Heller wrote:
>> BTW: Is a "porting guide" to make extension modules compatible with 2.5
>> available somewhere? PEP 353 scratches only the surface...
>
> Wrt. ssize_t changes, PEP 353 is meant to be comprehensive. Which
> par
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> I think it's only fair that I ask the patch authors to complete
>> the PEP, since the ssize_t patch is causing extension authors
>> enough trouble already.
>
> Well, the PEP is complete as it stands. It's possible to provide
> more guidelines, but t
Travis E. Oliphant wrote:
> Last year, during development of NumPy, the concept of the array
> interface was developed as a means to share array_like data. It was
> realized that it is this concept that needs to be explored further and
> pushed into Python itself, rather than a particular incar
M.-A. Lemburg wrote:
> Martin v. Löwis wrote:
>> Thomas Heller wrote:
>>> I'm not sure if this is what Marc-Andre means, but maybe these definitions
>>> could go into a new include file:
>> How would that include file be used? You would have to copy it into y
I'm trying out to build Python for 64-bit Windows, running the tools on WinXP
SP2 (32-bit).
I have installed:
- MSVC .NET 2003
- Platform SDK Feb 2003
- vsextcomp 0.6
Then I fire up MSVC, select the ReleaseAMD64 configuration, and try to build the
pythoncore project.
After lots of compiler warni
Martin v. Löwis wrote:
> Thomas Heller wrote:
>> Then I fire up MSVC, select the ReleaseAMD64 configuration, and try to
>> build the
>> pythoncore project.
>> After lots of compiler warnings, the build fails with this message:
>>
...
>
> For some r
Martin v. Löwis wrote:
> Thomas Heller wrote:
>> Then, from only reading the PEP without looking up the sources,
>> it is not clear to me what the PY_SIZE_T_CLEAN definition does.
>
> The description says
>
> The conversion codes 's#' and '
Thomas Heller wrote:
> Martin v. Löwis wrote:
>> Thomas Heller wrote:
>>> Then I fire up MSVC, select the ReleaseAMD64 configuration, and try to
>>> build the
>>> pythoncore project.
>>> After lots of compiler warnings, the build fails with this
Trent Mick wrote:
> [Thomas Heller wrote]
>> Linking...
>>Creating library .\./python25.lib and object .\./python25.exp
>> zipimport.obj : error LNK2001: unresolved external symbol __security_cookie
>> traceback.obj : error LNK2001: unresolved extern
Travis E. Oliphant wrote:
> Last year, during development of NumPy, the concept of the array
> interface was developed as a means to share array_like data. It was
> realized that it is this concept that needs to be explored further and
> pushed into Python itself, rather than a particular incar
Guido van Rossum wrote:
> On 3/24/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> I'm astonished that our BDFL doesn't speak up on this issue. IIRC,
>> it was the (his?) plan to let the numpy community develop an interface,
>> which would then be included i
Fred L. Drake, Jr. wrote:
> On Monday 27 March 2006 16:26, Phillip J. Eby wrote:
> > Any thoughts on where documentation for the new "contextlib" module should
> > go in the library reference?
>
> Most definately in "Python Runtime Services."
>
> > A similar issue exists for "ctypes" module, a
Georg Brandl wrote:
> Hi,
>
> (this makes test_ctypes fail, therefore I noticed)
>
> currently with -Qnew:
>
2/0
> Traceback (most recent call last):
> File "", line 1, in ?
> ZeroDivisionError: float division
2L/0
> Traceback (most recent call last):
> File "", line 1, in ?
> Zero
Phillip J. Eby wrote:
> At 10:44 AM 3/29/2006 +0200, Gerhard Häring wrote:
>> Creating latex docs sounds like I could do it, too.
>
> FYI, there's a reST->PythonDoc converter somebody wrote:
>
> http://www.rexx.com/~dkuhlman/rstpythonlatex_intro.html
>
> I'm planning to try it for porting the se
Gregory P. Smith wrote:
> On Sat, Mar 11, 2006 at 07:08:14PM +0100, Thomas Heller wrote:
>> Martin v. L?wis wrote:
>>> Josiah Carlson told me had has given up getting a Windows
>>> buildbot running, because every time he installed VS.NET
>>> on his machine, the
Martin v. Löwis wrote:
> I have now produces a snapshot of a Win64 build for AMD64
> processors (also known as EM64T or x64); this is different
> from IA-64 (which is also known as Itanium)...
>
> Anyway, the binaries are
>
> http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13199.amd64.ms
Neal Norwitz wrote:
> These issues are on HEAD. There might be some others I missed.
>
> With cc there are at least 2 issues:
> * test_file causes interpreter exit due to sys.stdin.seek(-1)
> * test_pty fails apparently due to whitespace differences
>
> http://www.python.org/dev/buildbot/all/a
Martin v. Löwis wrote:
> Thomas Heller wrote:
>> Is this no longer available?
>
> Sorry, I just deleted that. I now replaced it with
> python-2.5.13231.amd64.msi
Thanks, I'll try that.
>> BTW: When I build Python for ReleaseAMD64 myself, the exe crashes at the
&
Martin v. Löwis wrote:
> Thomas Heller wrote:
>> In sys_getwindowsversion:
>>
>> return Py_BuildValue("s",
>> ver.dwMajorVersion,
>> ver.dwMinorVersion,
&g
Martin v. Löwis wrote:
> I just tried creating a pysqlite VS project, and ran into a naming
> conflict: the Windows DLL is called sqlite3.dll. So if it is on
> sys.path
>
> import sqlite3
>
> might find the DLL, instead of finding the package. Python then
> finds that there is no entry point in s
Martin v. Löwis wrote:
> Thomas Heller wrote:
>> But if you make the change to implement option 3, IMO it would be a
>> good idea to add the Python version number to the .pyd basename as
>> well.
>
> Can you please elaborate? In the name of what .pyd file do you want
Is there are #define symbol which allows to determine if
'char' is signed or unsigned? __CHAR_UNSIGNED__, maybe?
I guess the buildbot failures on the ppc debian box are caused by
ctypes using signed chars always.
Thanks,
Thomas
___
Python-Dev mailing
t some point). Anyone who has
> info on them that I need, please let me know the details. Also, if I
> missed any, obviously speak up:
>
> - bsddb (still external?)
> - sqlite
> - ctypes
Maintainer: Thomas Heller
Homepage: http://starship.python.net/crew/theller/ctypes/
Where
ntaining ctypes in SVN trunk
> -------
>
> Thomas Heller put ctypes into the Python SVN repository, and with the
> help of perky, Neal Norwitz and Thomas Wouters, updated it to take
> advantage of the new ssize_t feature. Thomas Heller has now moved the
> "official" ctypes development to the
[Please let me know if this should go to the machine owner instead]
Why does the ia64 debian buildbot now complain about unaligned accesses,
and how can we find out where they occur?
http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/123/step-test/0
Thanks,
Thomas
Martin v. Löwis wrote:
> Thomas Heller wrote:
>> Why does the ia64 debian buildbot now complain about unaligned accesses,
>> and how can we find out where they occur?
>
> I don't know why they started show up suddenly; on Debian-Itanium, it
> is a configuration opti
Paul Moore wrote:
> On 4/17/06, tomer filiba <[EMAIL PROTECTED]> wrote:
>> after several people (several > 10) contacted me and said "IMHO 'construct'
>> is a good candidate for stdlib",
>> i thought i should give it a try. of course i'm not saying it should be
>> included right now, but in 6 month
Neal Norwitz wrote:
> On 4/18/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> On Wed, 2006-04-19 at 14:57 +1000, Anthony Baxter wrote:
>>> I'm not sure how people would prefer this be handled. I don't think we
>>> need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
>>> pysqlite or
Neal Norwitz wrote:
> This was run on linux amd64. It would be great to run purify on
> windows and other platforms. If you do, please report back here, even
> if nothing was found. That would be a good data point.
>
> Summary of tests with problems:
>
> test_codecencodings_jp (1 invalid read)
Ganesan Rajagopal wrote:
>> Neal Norwitz <[EMAIL PROTECTED]> writes:
>
>> Please add your project ideas to the existing set at
>
>> http://wiki.python.org/moin/SummerOfCode
>
> I'd like to see ctypes supported on GCC ARM platforms. ARM is the only major
> Debian architecture that's not s
I'm about to import the 0.9.9.6 tag of ctypes into Python svn.
Should this be done in exact the same way as before, so first
commit it into external/ctypes-0.9.9.6, and then 'svn copy'
the two relevant directories into the trunk, and afterwards set
all the svn props again, or is this done in anoth
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
Greg Ewing wrote:
> Paul Moore wrote:
>
>> I do things like
>>
>> python setup.py build --compiler=mingw32 bdist_wininst
>>
>> which seem to work for me. Is that any help?
>
> Possibly. I'll have to try it next time I have the
> problem and see.
>
> BTW, does that do anything different from
Martin v. Löwis wrote:
> Thomas Heller wrote:
>>>> return Py_BuildValue("s",
>>>> ver.dwMajorVersion,
>>>> ver.dwMinorVersion,
>>>> ver.
Martin v. Löwis wrote:
> Thomas Heller wrote:
>> On XP (32-bit), I can compile python25.dll and python.exe for AMD64 now,
>> after adding bufferoverflowU.lib to the linker options.
>
> On what project? There should be /GS- options on all projects that need
> it, which, i
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?
>
Thomas Heller wrote:
> Martin v. Löwis wrote:
>> Thomas Heller wrote:
>>> On XP (32-bit), I can compile python25.dll and python.exe for AMD64 now,
>>> after adding bufferoverflowU.lib to the linker options.
>> On what project? There should be /GS- options on all pr
> ctypes
> --
> - Web page
> http://starship.python.net/crew/theller/ctypes/
> - Standard library name
> ctypes
> - Contact person
> Thomas Heller
> - Synchronisation history
* 0.9.9.4 (2.5a1)
* 0.9.9.6 (2.5a2)
Michael Hudson wrote:
> Gerhard Häring <[EMAIL PROTECTED]> writes:
>
>> Currently I'm not subscribed to python-checkins and didn't see a need
>> to. Is there a need to for Python core developers?
>
> I would say it's "encouraged".
>
>> I think there's no better way except subscribing and defin
Neal Norwitz wrote:
> The following PEPs are open according to PEP 0 and haven't seen much
> activity recently IIRC. I'd like everyone to take a cut and bring
> these up to date. For all the PEPs that aren't going anywhere, can we
> close them? Please update your PEP if appropriate.
>
> S 2
Neal Norwitz wrote:
> If you are addressed on this message, it means you have open issues
> that need to be resolved for 2.5. Some of these issues are
> documentation, others are code issues.
> Documentation missing:
> +++
> Fredrik: ElementTree
> Gerhard: pysqlite
> Martin: msili
Gerhard Häring wrote:
> Thomas Heller wrote:
>> [...] I'm now happy with the tool that converts the ctypes tutorial
>> from reST to LaTeX,
>> I will later (today or tomorrow) commit that into Python SVN.
>
> Did you commit that already? Alternativel
Thomas Wouters wrote:
> On 4/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>> Alrighty then. The list has about 12 hours to convince me (and you) that
>> it's a bad idea to generate that warning. I'll be asleep by the time the
>> trunk un-freezes, and I have a string of early meetings tomorrow.
[EMAIL PROTECTED] wrote:
> On Fri, 28 Apr 2006, Thomas Heller wrote:
>
>> Gerhard Häring wrote:
>>> Thomas Heller wrote:
>>>> [...] I'm now happy with the tool that converts the ctypes tutorial
>>>> from reST to LaTeX,
>>>> I will late
Georg Brandl wrote:
> Martin v. Löwis wrote:
>> Neal Norwitz wrote:
>>> Who is the owner for getting new icons installed with the new logo?
>> Nobody, so far (for Windows). Somebody should contact the owner and
>> find out what the license on this work is, and then tell me what
>> to do with them.
Fredrik Lundh wrote:
> Josiah Carlson wrote:
>
>> At least for the examples of buffers that I've seen, using the buffer
>> interface for objects that support it is equivalent to automatically
>> applying str() to them. This is, strictly speaking, an optimization.
>
> >>> a = array.array("i",
Guido van Rossum wrote:
> I see test failures in current HEAD on my Google Red Hat Linux desktop
> that the buildbots don't seem to have:
>
> ./python -E -tt ../Lib/test/regrtest.py test_ctypes
> test_ctypes
> test test_ctypes failed -- errors occurred; run in verbose mode for details
>
> More de
[Crossposting to both python-dev and ctypes-users, please respond to the list
that seems most appropriate]
Guido van Rossum wrote:
> I see test failures in current HEAD on my Google Red Hat Linux desktop
> that the buildbots don't seem to have:
>
> ./python -E -tt ../Lib/test/regrtest.py test_cty
Thomas Wouters wrote:
> On 5/8/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>
>> test_ctypes
>> test test_ctypes failed -- Traceback (most recent call last):
>> File "/home/neal/python/trunk/Lib/ctypes/test/test_python_api.py", line
>> 41, in test_PyInt_Long
>> self.failUnlessEqual(grc(42), r
[EMAIL PROTECTED] wrote:
> On Fri, 28 Apr 2006, Thomas Heller wrote:
>
>> I must work on the docs themselves, so I currently have only two things:
>>
>> - the table in the ctypes tutorial has a totally different look than the
>> other
>> tables in the docs.
Thomas Wouters wrote:
> On 5/9/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>>
>> Thomas Wouters wrote:
>> > On 5/8/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>> >
>> >> test_ctypes
>> >> test test_ctypes failed -- Traceba
Luke Dunstan wrote:
> Hi,
>
> This patch submitted in March allows Python trunk to be built using MSVC 6:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1457736&group_id=5470&atid=305470
>
> It is not my patch but I am quite interested because the code changes are
> also required
test_ctypes fails on the ppc64 machine. I don't have access to such
a machine myself, so I would have to do some trial and error, or try
to print some diagnostic information.
This should not be done in the trunk, so the question is: can the buildbots
build branches?
I assume I just have to enter
Tim Peters wrote:
> [Thomas Heller]
>> test_ctypes fails on the ppc64 machine. I don't have access to such
>> a machine myself, so I would have to do some trial and error, or try
>> to print some diagnostic information.
>>
>> This should not be done in
In Include/structmember.h, there is no T_... constant for Py_ssize_t
member fields. Should there be one?
Thomas
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
Brett Cannon wrote:
> I fixed the crasher for ``int(buffer(array.array('c')))`` by making
> buffer objects operate properly. Problem is that by doing so I broke
> the ctypes tests with a bunch of similar errors::
You have not yet committed this fix, right?
> =
Neal Norwitz wrote:
> It's June 9 in most parts of the world. The schedule calls for beta 1
> on June 14. That means there's less than 4 days until the expected
> code freeze. Please don't rush to get everything in at the last
> minute. The buildbots should remain green to keep Anthony happy an
Neal Norwitz wrote:
> It's June 9 in most parts of the world. The schedule calls for beta 1
> on June 14. That means there's less than 4 days until the expected
> code freeze. Please don't rush to get everything in at the last
> minute. The buildbots should remain green to keep Anthony happy an
Neal Norwitz wrote:
> It's June 9 in most parts of the world. The schedule calls for beta 1
> on June 14. That means there's less than 4 days until the expected
> code freeze. Please don't rush to get everything in at the last
> minute. The buildbots should remain green to keep Anthony happy an
Ka-Ping Yee wrote:
> Finally, Phillip brought up PEAK:
>> PEAK's uuid module does this such that if win32all is present,
>> you get a Windows GUID, or if you have a FreeBSD 5+ or
>> NetBSD 2+ kernel you use the local platform uuidgen API. See e.g.:
>
> ...so i looked at PEAK's getnodeid48() routi
Ka-Ping Yee wrote:
> Hi Thomas,
>
>> This does not work, for several reasons.
>>
>> 1. (pythoncom|pywintypes).CreateGuid() return a PyIID instance, which you
>> cannot slice:
>
> You're right. The PEAK code must have been based on an earlier
> version of the CreateGuid() routine.
>
> I've fixe
Phillip J. Eby wrote:
> At 08:22 AM 6/10/2006 -0500, Ka-Ping Yee wrote:
>>Finally, Phillip brought up PEAK:
>> > PEAK's uuid module does this such that if win32all is present,
>> > you get a Windows GUID, or if you have a FreeBSD 5+ or
>> > NetBSD 2+ kernel you use the local platform uuidgen API.
Phillip J. Eby wrote:
> At 06:39 PM 6/10/2006 +0200, Thomas Heller wrote:
>>I don't know if this is the uuidgen you're talking about, but on linux there
>>is libuuid:
>>
>> >>> from ctypes import *
>> >>> lib = CDLL("libuuid.so.1
Barry Warsaw wrote:
> On Fri, 9 Jun 2006 09:54:29 -0700
> "Brett Cannon" <[EMAIL PROTECTED]> wrote:
>
>> Do enough people use Google Calendar or a calendar app that support
>> iCal feeds that it would be useful for someone to maintain a Gcal
>> calendar that has the various Python dev related date
Martin v. Löwis wrote:
> Guido van Rossum wrote:
>>> 4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want
>>> to get rid of it, *now* would be the time.
>>
>> I'm all for it.
>>
>> While I am an enthusiastic supporter of several of those additions, I
>> am *not* in favor of t
Guido van Rossum wrote:
> On 6/12/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>> I will be happy to say "ctypes is part of Python" (although I *fear* it
>> is not one of the packages enthusiastically supported by Guido ;-).
>
> I don't plan to use it m
Neal Norwitz wrote:
> It's June 9 in most parts of the world. The schedule calls for beta 1
> on June 14.
It*s June 14 no longer in too many parts of the world ;-).
Any *official* news about beta1? I guess the release will not be started
as long as the tests fail, but is there a new plan?
Thoma
It should be noted that I once started to convert the import machinery
to be fully unicode aware. As far as I can tell, a *lot* has to be changed
to make this work.
I started with refactoring Python/import.c, but nobody responded to the question
whether such a refactoring patch would be accepted
Martin v. Löwis schrieb:
> Thomas Heller wrote:
>> It should be noted that I once started to convert the import machinery
>> to be fully unicode aware. As far as I can tell, a *lot* has to be changed
>> to make this work.
>
> Is that code available somewhere still? Doe
Trent Mick schrieb:
> Thomas and others,
>
> Has anyone else seen failures in test_ctypes on older Mac OS X/PowerPC?
> Results are below. This is running a build of the trunk from last night:
>
> ./configure && make && ./python.exe Lib/test/test_ctypes.py
>
> Note that the test does NOT fa
Ronald Oussoren schrieb:
>
> On 20-jun-2006, at 20:50, Ronald Oussoren wrote:
>
>>
>> On 20-jun-2006, at 20:06, Thomas Heller wrote:
>>
>>> Trent Mick schrieb:
>>>> Thomas and others,
>>>>
>>>> Has anyone else seen failure
Ronald Oussoren schrieb:
> On 20-jun-2006, at 20:50, Ronald Oussoren wrote:
>
>>
>> On 20-jun-2006, at 20:06, Thomas Heller wrote:
>>
>>> Trent Mick schrieb:
>>>> Thomas and others,
>>>>
>>>> Has anyone else seen failures i
Ronald Oussoren schrieb:
>
> On Wednesday, June 21, 2006, at 09:43AM, Thomas Heller <[EMAIL PROTECTED]>
> wrote:
>
>>Ronald Oussoren schrieb:
>>>> will have a look.
>>>
>>> It is a platform bug, RTLD_LOCAL doesn't work on 10.3. The f
201 - 300 of 363 matches
Mail list logo
