Re: [Python-Dev] Hello, I'm the other new guy

Facundo Batista schrieb: > 2007/11/14, Christian Heimes <[EMAIL PROTECTED]>: > >> After Amaury introduced himself I've decided that I *have* to take some >> time to introduce myself, too. It's probably too late to say welcome to both Christian and Amaury, also we have already met in the bug track

Re: [Python-Dev] Coverity Scan, Python upgraded to rung 2

[EMAIL PROTECTED] schrieb: > Christian> I read the announcement of the Python Users list and figured > Christian> out that some of the other core developers might be > Christian> interested in the news, too. > > Christian> Among other projects Python was upgraded to Rung 2 on the >

Re: [Python-Dev] Coverity Scan, Python upgraded to rung 2

Guido van Rossum schrieb: > On Jan 9, 2008 9:47 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: >> [EMAIL PROTECTED] wrote: >> I shows 6 uninspected defects for Python. How do we see what they are? >> > What is an uninspected defect? Any idea how the Coverity folks compute >> > Defects/KLOC? For

Re: [Python-Dev] Coverity Scan, Python upgraded to rung 2

Christian Heimes schrieb: > Thomas Heller wrote: >> Seems they are referring to the results of the rung 1 run (what ever 'rung' >> means ;-). >> With the account Neal made me some months ago, I can login on this page: >> >>http://scan.coverity.co

Re: [Python-Dev] building _ctypes in trunk fails first time around

Guido van Rossum schrieb: > If I run "make clean" and then "make", builting _ctypes fails with this > message: > > *** WARNING: renaming "_ctypes" since importing it failed: No module > named _weakref > > Typing "make" a second time fixes this -- it seems a simple matter of > _ctypes being built

Re: [Python-Dev] What to do for bytes in 2.6?

Guido van Rossum schrieb: > I believe the issue of whether and how to backport bytes (and > bytearray?) from 3.0 to 2.6 has come up before, but I don't think > we've come to any kind of conclusion. It's quite subtle. In a private > email, Thomas Wouters and I discussed this: > > [Guido] >> > Perha

[Python-Dev] Error in PEP3118?

Hi Travis, The pep contains this sample: """ Nested array :: struct { int ival; double data[16*4]; } """i:ival: (16,4)d:data: """ """ I think it is wrong and must be changed to the following; is this correct? """ Nested

Re: [Python-Dev] Error in PEP3118?

Travis Oliphant schrieb: [...] > I responded off list to this email and wanted to summarize my response > for others to peruse. > > Basically, the answer is that the struct syntax proposed for > multi-dimensional arrays is not intended to mimic how the C-compiler > handles statically defined

Re: [Python-Dev] struct module docs vs reality

Gregory P. Smith schrieb: > The documentation for the struct module says: > > http://docs.python.org/dev/library/struct.html#module-struct > > "short is 2 bytes; int and long are 4 bytes; long long (__int64 on Windows) > is 8 bytes" > > and lists 'l' and 'L' as the pack code for a C long. > >

Re: [Python-Dev] 2.5.2 release coming up

Neal Norwitz schrieb: > We need to fix the Windows buildbots. 2 tests are currently failing > for 2.5.2: test_mailbox test_winreg The test_winreg failure is a funny one: The py3k test_winreg fails because of a bug in the test itself; I fixed this in rev. 60236. The failing test leaves a key in

[Python-Dev] pep3118, ctypes, py3k

Hi Travis, I have started the pep3118 implementation for ctypes. If you have time, could you please review , especially the tests in file Lib/ctypes/test/test_pep3118.py to ensure that I have understood and implemented the pep correctly? Thanks, Thomas _

Re: [Python-Dev] Error in PEP3118?

Travis Oliphant schrieb: > Thomas Heller wrote: >> Travis Oliphant schrieb: >> >>> So, I think the example is correct (and intentional). >> >> Sorry, I do not think so. If you use a 2-d array in the example, you >> must describe it correctly. The diff

Re: [Python-Dev] Buildbots for trunk are all red

Neal Norwitz schrieb: > On Tue, Feb 26, 2008 at 11:47 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> >> Well, in my opinion "batteries included" is great, but not when one of >> the batteries consistently acts up and requires a good shake to get >> working again. The bsddb module has consistent

Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows

Trent Nelson schrieb: > Howdy, > > I'm going through the motions of getting my newly added build slave in a half > decent state. I think the buildbot should have a name different from 'x86 XP'. (Martin, Neal?) Thomas ___ Python-Dev mailing list Pytho

Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows

Trent Nelson schrieb: > Howdy, > > I'm going through the motions of getting my newly added build slave in a half > decent state. The external.bat and external-amd64.bat files needed the > following in order to build db-4.4.20: > > Index: external.bat > =

Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows

Trent Nelson schrieb: > Christian Heimes: >> Trent Nelson wrote: >> > - vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug >> /project db_static >> > + devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln >> > + devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug >> /project db

Re: [Python-Dev] Windows buildbots randomly die with twisted ConnectionLost errors?

Trent Nelson schrieb: > I've started to see my build slave dying every so often with a > twisted error half way through tests: ... test_htmlparser > test_httplib > > remoteFailed: [Failure instance: Traceback (failure with no frames): > twisted.internet.error.ConnectionLost: Connection to the oth

Re: [Python-Dev] Windows buildbots randomly die with twisted ConnectionLost errors?

Trent Nelson schrieb: > Had a chat with some Twisted/buildbot folk and they can confirm > they've seen it as well on Windows. They've given me a few things to > look into. Out of interest, how are you running your buildbot? Via > the command line in an interactive desktop session, as a service,

Re: [Python-Dev] Auto-Assignment

Martin v. Löwis schrieb: > I just implemented auto-assignment for the tracker, i.e. a component > can be linked to a developer so that issues mentioning the component > get assigned to that developer (unless an explicit assignment is > made). > You can autoassign ctypes issues to me, as you might

Re: [Python-Dev] Auto-Assignment

Martin v. Löwis schrieb: > Thomas Heller wrote: >> Martin v. Löwis schrieb: >>> I just implemented auto-assignment for the tracker, i.e. a component >>> can be linked to a developer so that issues mentioning the component >>> get assigned to that develop

Re: [Python-Dev] Auto-Assignment

Jeroen Ruigrok van der Werven schrieb: > -On [20080307 11:05], Guilherme Polo ([EMAIL PROTECTED]) wrote: >>When you create a new issue, you have to select a component from a >>list, those are the available components. > > I think Thomas was wondering what the definition for a component was within

Re: [Python-Dev] [Python-3000] PEP 361: Python 2.6/3.0 release schedule

Barry Warsaw schrieb: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Mar 18, 2008, at 2:04 AM, Travis Oliphant wrote: >> >> Hey Barry, >> >> Thanks for putting this PEP together. This is really helpful. > > Hi Travis... thanks! > >> I didn't see discussion of PEP 3118 and it's feature

Re: [Python-Dev] First green Windows x64 buildbots!

Trent Nelson schrieb: > We've just experienced our first 2.6 green x64 Windows builds on the > build slaves! Well, almost green. Thomas's 'amd64 XP trunk' ran out > of disk: > > 304 tests OK. 1 test failed: test_largefile > ==

Re: [Python-Dev] trunk buildbot status

>> Neal/Martin, I'd like to promote the following slaves to the stable list: >> [g4 osx.4] >> [x86 W2k8] >> [AMD64 W2k8] >> [ppc Debian unstable] >> [sparc Ubuntu] >> [sparc Debian] >> [PPC64 Debian] >> [S-390 Debian] >> [x86 XP-3] >> [amd64 XP] >> [x86 FreeBSD] >> [x86 FreeBSD 3] >> >

Re: [Python-Dev] Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows)

M.-A. Lemburg schrieb: > About the platform.py changes: if someone could provide the return > values of sys.getwindowsversion() for 64bit versions of Windows > XP and Vista, I could add support for it (don't have a 64bit version > of Windows available to check myself). This is the output of a 32-b

[Python-Dev] osx x86 buildbot offer

I can offer an OS X x86 machine to run a buildbot on. This is a physical machine, running OS X 10.5 Leopard. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.o

Re: [Python-Dev] Remove "current" Windows executables from Lib/distutils/command in svn?

Martin v. Löwis schrieb: >> I'd like to propose we delete Lib/Distutils/command/wininst-9.0.exe, and >> enable the building of that project by default in the standard build process >> (and I'll setup the x64 build of the executable similarly). > > There are two issues here: > a) how does the binar

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Ulrich Berning schrieb: > Nick Craig-Wood wrote: > >>Jesse Noller <[EMAIL PROTECTED]> wrote: >> >> >>> I am looking for any questions, concerns or benchmarks python-dev has >>> regarding the possible inclusion of the pyprocessing module to the >>> standard library - preferably in the 2.6 timelin

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Bill Janssen schrieb: >> Hmm, perhaps the ctypes documentation could use a more prominent warning >> that it may not be available on some Unix platforms (HP-UX, AIX, IRIX), >> and that it may require the use of GCC rather than the vendor compiler >> on others (Solaris). >> >> At the moment, I s

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Charles Cazabon schrieb: > A.M. Kuchling <[EMAIL PROTECTED]> wrote: >> On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote: >> > Myself I would rather spend my energy to make ctypes more portable, within >> > my >> > skills and the platforms

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Martin v. Löwis schrieb: >>> We actually have a couple of Solaris buildbots already - as I >>> understand it, the issue there isn't Solaris as such, it's being able >>> to use the Sun compiler instead of GCC to compile ctypes/libffi. >> >> Does that mean that we need access to the Sun compiler or

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Bill Janssen schrieb: > What happens on those platforms where ctypes doesn't work? Does the > module fail to import, either because it isn't present, or because it > can't load the libffi library? Or does it fail silently in some way? It doesn't compile, and Python's setup.py script removes if a

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

A.M. Kuchling schrieb: > On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote: >> Myself I would rather spend my energy to make ctypes more portable, within my >> skills and the platforms I have access to. > > Someone could run Solaris x86 inside a hosted virtual

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Ulrich Berning schrieb: > > If porting libffi to AIX, HP-UX, IRIX, Solaris... (especially using > vendor compilers) would be an easy job, I'm sure it would have been done > already. If more and more essential packages depend on ctypes, we should > make a clear statement, that Python isn't suppo

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Michael Foord schrieb: > James Y Knight wrote: >> >> On May 21, 2008, at 11:26 AM, Michael Foord wrote: >> >>> And what about platforms like the JVM or CLR? >>> >>> Incidentally there were a small but vocal group of Pythonistas who >>> were (are?) certain that IronPython is not Python because it d

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Martin v. Löwis schrieb: >> As said before, PyOpenGL is an example of an extension that moved from C >> code to Python/ctypes, luckily we don't use it, but what if the >> maintainers of MySQL-Python or cx_Oracle decide to move to ctypes. >> Having the ctypes extension in the stdlib doesn't imply it

Re: [Python-Dev] PEP 371 Discussion (pyProcessing Module)

Jesse Noller schrieb: > On Fri, May 30, 2008 at 2:19 AM, Farshid Lashkari <[EMAIL PROTECTED]> wrote: >> On Wed, May 28, 2008 at 10:03 AM, Jesse Noller <[EMAIL PROTECTED]> wrote: >>> I would like to renew the discussion now that "there is a PEP" to see >>> if there are any outstanding things people

[Python-Dev] PEP3118, python 2.6

Hi Travis, I'm currently trying to port the pep3118 ctypes changes which are already in the py3k branch to the trunk. In py3k the tests for this stuff (in Lib/ctypes/test/test_pep3118.py) use the memoryview object which exposes attributes like .format, .shape, .strides and so on for objects imple

Re: [Python-Dev] PEP3118, python 2.6

Thomas Heller schrieb: > I'm currently trying to port the pep3118 ctypes changes which are already in > the py3k branch to the trunk. > > In py3k the tests for this stuff (in Lib/ctypes/test/test_pep3118.py) use > the memoryview object which exposes attributes like .format, .s

Re: [Python-Dev] PEP3118, python 2.6

Lisandro Dalcin schrieb: > On 6/5/08, Thomas Heller <[EMAIL PROTECTED]> wrote: > Thomas, Iff this helps, you have attached the backport but as an > extension module. Sorry, I do not have time for the full backport. > But at least, I've found that the Py3K implementatio

[Python-Dev] rest markup in ctypes docs

There are a few cases where the ctypes docs are rendered incorrectly: http://docs.python.org/dev/library/ctypes.html#function-prototypes This looks as if 'prototype' would be a symbol exposed by ctypes; it is not - it is used as a placeholder for the object returned by calls to the ctypes.CFUNCT

Re: [Python-Dev] rest markup in ctypes docs

Thomas Heller schrieb: > There are a few cases where the ctypes docs are rendered incorrectly: > > http://docs.python.org/dev/library/ctypes.html#function-prototypes > > This looks as if 'prototype' would be a symbol exposed by ctypes; it is > not - it is used as

[Python-Dev] Vacation

FYI: I'm going to a vacation for the next two or three weeks. I will shutdown my buildbots, and restart them when I'm back: x86 osx.5, x86 XP-3, amd64 XP. Sorry for the inconvenience, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail

Re: [Python-Dev] ctypes assertion failure

Tim Golden schrieb: > This problem was raised on the comtypes-users list > as it prevents comtypes from being imported on Python 2.6 > at the moment. > > http://bugs.python.org/issue3258 > > I'll try to find the time to step through to code to work out > what's going on, but it's inside the innar

Re: [Python-Dev] PEP 3101: floats format 'f' and 'F'

Guido van Rossum schrieb: > On Thu, Jul 17, 2008 at 9:25 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> From: "Eric Smith" <[EMAIL PROTECTED]> >>> >>> I have this ready for checkin (with docs and tests). I'd like to get it >>> in for this beta, since it does involved changed behavior, no matt

[Python-Dev] Windows buildbot trick

The most annoying thing on the windows buildbots is when Python crashes hard (with a general protection fault or stack overflow, for example). Usually the system pops up a dialog in this case which allows to attach a debugger to the process. This dialog will stay open until the maintainer manually

Re: [Python-Dev] Windows buildbot trick

Sidnei da Silva schrieb: > On Fri, Jul 18, 2008 at 12:42 PM, Sidnei da Silva > <[EMAIL PROTECTED]> wrote: >> That's a great trick! I seem to remember that there is a way to turn >> that off globally though, but not sure where. Maybe running >> drwtsn32.exe and un-checking 'Visual Notification' does

Re: [Python-Dev] "error: None" when building extensions under 2.6

Fredrik Lundh schrieb: > Amaury Forgeot d'Arc wrote: > >>> when I'm trying to build extensions under Python 2.6 on Windows XP, the >>> build process terminates with single line that says: >>> >>>error: None >>> >>> which is about as useless as an error message can be. Googling for this >>> br

Re: [Python-Dev] Add python.exe to PATH environment variable

> > Perhaps we could have an option to place a "python.bat" > > into C:\Windows\ or C:\Windows\System\. > > Except you still have the "last in wins" issue, and you have to make a > decision on whether or not to delete the file. If this is done the batch file should be named "python25.bat" or s

Re: [Python-Dev] Add python.exe to PATH environment variable

Paul Moore schrieb: > Bat files don't work when called from another bat file. This hits me > regularly, when people supply wrapper bat files. Example: > > myscript.bat: > @echo off > do some stuff > python my_py_script.py > do some more stuff > > If "python" is a bat file, "do some more stuff" wi

Re: [Python-Dev] Real segmentation fault handler

Victor Stinner schrieb: > Hi, > > I would like to be able to catch SIGSEGV in my Python code! So I started to > hack Python trunk to support this feature. The idea is to use a signal > handler which call longjmp(), and add setjmp() at Py_EvalFrameEx() enter. On windows, ctypes catches fatal err

[Python-Dev] python dll no longer in system directory?

Is it intended that python30.dll and python26.dll are not longer installed in the \windows\system32 directory? This (pythonxy.dll not on $PATH) causes problems for COM objects implemented in Python. Thanks, Thomas ___ Python-Dev mailing list Python-Dev

Re: [Python-Dev] python dll no longer in system directory?

Christian Heimes schrieb: > Thomas Heller wrote: >> Is it intended that python30.dll and python26.dll are not longer >> installed in the \windows\system32 directory? >> >> This (pythonxy.dll not on $PATH) causes problems for COM objects >> implemented in Python

Re: [Python-Dev] python dll no longer in system directory?

Amaury Forgeot d'Arc schrieb: > 2008/10/8 "Martin v. Löwis" <[EMAIL PROTECTED]>: >> Thomas Heller wrote: >>> Is it intended that python30.dll and python26.dll are not longer >>> installed in the \windows\system32 directory? >> >> No,

Re: [Python-Dev] No manifest files on Windows?

Mark Hammond schrieb: >> In http://bugs.python.org/issue4120, the author suggests that it might >> be possible to completely stop using the manifest mechanism, for VS >> 2008. Given the many problems that this SxS stuff has caused, this >> sounds like a very desirable route, although I haven't done

Re: [Python-Dev] is the 'path' argument to an importer's find_module() just a hint?

Brett Cannon schrieb: > I just discovered frozen packages set their __path__ simply to their > name and not to a list as expected (http://bugs.python.org/issue4211). > This made me think about the 'path' argument to find_module() and > whether it can be treated as simply a hint or should always be

[Python-Dev] svnmerge init in the release26-maint branch?

I have a fix for a modulefinder crash that I'm going to commit into the trunk. Since the bug is also in release26-maint I will also backport it. While preparing this I noticed that in the release26-maint branch 'svnmerge init' has not yet been done. I assume that we will use svnmerge to merge fro

Re: [Python-Dev] svnmerge init in the release26-maint branch?

Christian Heimes schrieb: > Thomas Heller wrote: >> I have a fix for a modulefinder crash that I'm going to commit >> into the trunk. Since the bug is also in release26-maint I will >> also backport it. While preparing this I noticed that in the >> release26-main

[Python-Dev] buildbots

AFAICS there are no buildbots for the release26-maint branch. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-arch

Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.

Christian Heimes schrieb: > Nick Coghlan wrote: >> If I recall correctly, the main blocker to ctypes portability is libffi >> portability. So if anyone would like to see ctypes on more platforms, >> then that's the limitation they really need to attack. > > ctypes is also missing utilities to writ

Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.

Victor Stinner schrieb: > Le Friday 31 October 2008 14:13:01 Christian Heimes, vous avez écrit : >> ctypes is also missing utilities to write code that works on 32 and >> 64bit platforms. Without a tool like >> http://pypi.python.org/pypi/ctypes_configure it's very hard and tedious >> to avoid and

Re: [Python-Dev] The endless GIL debate: why not remove thread support instead?

Christian Heimes schrieb: > Nick Coghlan schrieb: >> Actually, I believe 3.0 already took a big step towards allowing this by >> changing the way modules are initialised. > > You are believing correctly. Martin has designed and implemented a > nicely working API to store extension module data per

Re: [Python-Dev] a few strdup() questions...

>> BTW: there is another implementation (called my_strdup) in >> Modules/_ctypes/_ctypes_test.c, why not use the one in Python/strdup.c there? > > I guess that's historical, from the times when ctypes was still a > separate package. my_strdup is an exported function in _ctypes_test.pyd (on Windo

Re: [Python-Dev] FormatError() in callproc.c under win32

Ulrich Eckhardt schrieb: > Hi! > > In callproc.c from trunk is a function called SetException(), which calls > FormatError() only to discard the contents. Can anyone enlighten me to the > reasons thereof? Is it just to check if the errorcode is registered in the > stringtables? I think that yo

[Python-Dev] Include C++ code in the ctypes test suite?

I'm currently working on a patch that adds the __thiscall calling convention to ctypes. This calling convention is used on Windows for calling member functions from C++ classes. The idea is to eventually allow ctypes to wrap C++ classes. To test this functionality it is required to add some C++

[Python-Dev] 2.7 releases

Will there be more 2.7 bugfix releases, and when the next one? In other words; if I submit a patch and it is accepted, can I expect that patch be committed also to the 2.7 branch? Thanks, Thomas Been a long time that I've been here - but still using Python (2.7 now) more and more... __

Re: [Python-Dev] 2.7 releases

Am 26.07.2012 20:16, schrieb mar...@v.loewis.de: Will there be more 2.7 bugfix releases Yes. and when the next one? That's up for Benjamin to decide. My view is that one bugfix release every year is more than enough. Ok. I expect we will still be using 2.7 next year in my company. In o

[Python-Dev] importlib.find_loader

In Python3.3, I thought that every loaded module has a __loader__ attribute. Apparently this is not the case for a few builtin modules: Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more inform

Re: [Python-Dev] importlib.find_loader

Am 01.02.2013 01:42, schrieb Nick Coghlan: Yep, looks like a bug in the bootstrapping, failing to set __loader__ properly. It also has the effect that reload does not work: Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> import math >>> imp.reload(math

[Python-Dev] importlib hooray!

I have become a fan of the new python 3.3 importlib in the last few days. It has allowed me to write a ModuleMapper which I put into sys.metapath (in sitecustomize.py, for Python 3.3). This mapper currently does rename modules like 'Queue' or '_winreg' to the Python3 modules 'queue' or 'winreg'

[Python-Dev] Python.org current docs

http://www.python.org/doc/current/ and http://docs.python.org/ still point to 2.3.4 docs. Thomas ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/pytho

Re: [Python-Dev] Trouble installing 2.4

"Andrew Koenig" <[EMAIL PROTECTED]> writes: > Follow-up: When I install Python as Administrator, all is well. In that > case (but not when installing it as me), it asks whether I want to install > it for all users or for myself only. I then install pywin32 and it works. > > So it may be that a

Re: [Python-Dev] 2.4 news reaches interesting places

Skip Montanaro <[EMAIL PROTECTED]> writes: > >> The other thing we can do is finish the portable backend for psyco > >> and make it a standard module. Then Python won't be slow, it will be > >> compiled, and py2exe will be able to make a single-file executable. > > Armin> You prob

Re: [Python-Dev] MinGW And The other Py2.4 issue

Paul Moore <[EMAIL PROTECTED]> writes: > The biggest problem with CRT compatibility issues is that (AFAIK) > no-one has actually been able to trigger a *real* error, all of the > problems are still theoretical. There have been problems with the bdist_wininst exe-stub linking to the wrong CRT dll,

[Python-Dev] Mac questions

I'm working on refactoring Python/import.c, currently the case_ok() function. I was wondering about these lines: /* new-fangled macintosh (macosx) */ #elif defined(__MACH__) && defined(__APPLE__) && defined(HAVE_DIRENT_H) Is this for Mac OSX? Does the Mac have a case insensitive file system (

Re: [Python-Dev] an idea for improving struct.unpack api

Paul Moore <[EMAIL PROTECTED]> writes: > On Thu, 6 Jan 2005 21:28:26 +1100, Anthony Baxter > <[EMAIL PROTECTED]> wrote: >> My take on this: >> >> struct.pack/struct.unpack is already one of my least-favourite parts >> of the stdlib. Of the modules I use regularly, I pretty much only ever

Re: [Python-Dev] an idea for improving struct.unpack api

> Bob Ippolito <[EMAIL PROTECTED]> writes: >> This is my ctypes-like attempt at a high-level interface for struct. >> It works well for me in macholib: >> http://svn.red-bean.com/bob/py2app/trunk/src/macholib/ptypes.py Michael Hudson <[EMAIL PROTECTED]> writes: > > Unsurprisingly, that's fairly s

Re: [Python-Dev] PEP 246, redux

Alex Martelli <[EMAIL PROTECTED]> writes: > PEP: 246 > Title: Object Adaptation Minor nit (or not?): You could provide a pointer to the Liskov substitution principle, for those reader that aren't too familiar with that term. Besides, the text mentions three times that LiskovViolation is a subcla

getattr and __mro__ (was Re: [Python-Dev] PEP 246, redux)

Armin Rigo <[EMAIL PROTECTED]> writes: > ... is that the __adapt__() and __conform__() methods should work just > like all other special methods for new-style classes. The confusion > comes from the fact that the reference implementation doesn't do that. > It should be fixed by replacing: > >

[Python-Dev] Re: 2.3.5 delayed til next week

Anthony Baxter <[EMAIL PROTECTED]> writes: > As I'd kinda feared, my return to work has left me completely > buried this week, and so I'm going to have to push 2.3.5 until > next week. Thomas and Fred: does one of the days in the > range 25-27 January suit you? The 26th is a public holiday here, >

[Python-Dev] Is msvcr71.dll re-redistributable?

The 2.4 python.org installer installs msvcr71.dll on the target system. If someone uses py2exe or a similar tool to create a frozen application, is he allowed to redistribute this msvcr71.dll to other users together with his application or not, even if he doesn't own MSVC? This was asked on the p

Re: [Python-Dev] mimetypes and _winreg

Mike Brown <[EMAIL PROTECTED]> writes: > Following up on this 12 Jun 2004 post... > > Garth wrote: >> Thomas Heller wrote: >> >Mike Brown <[EMAIL PROTECTED]> writes: >> >>I thought it would be nice to try to improve the mimetypes module by >>

Re: [Python-Dev] Is msvcr71.dll re-redistributable?

"Neil Hodgson" <[EMAIL PROTECTED]> writes: > Anders J. Munch: > >> 1. John X. Programmer buys the product, agrees to the EULA and puts >>the DLL up for download, with the explicit and stated intent of >>distributing it to anyone who needs it. > >Disallowed in 3.1(a): > # you agree: ...

Re: [Python-Dev] Re: Is msvcr71.dll re-redistributable?

Alexander Schremmer <[EMAIL PROTECTED]> writes: > On Tue, 01 Feb 2005 21:17:17 +0100, Thomas Heller wrote: > >> The 2.4 python.org installer installs msvcr71.dll on the target system. >> >> If someone uses py2exe or a similar tool to create a frozen application, &g

Re: [Python-Dev] ViewCVS on SourceForge is broken

Tim Peters <[EMAIL PROTECTED]> writes: > [Trent Mick] >> Has anyone else noticed that viewcvs is broken on SF? > > It failed the same way from Virginia just now. I suppose that's your > reward for kindly updating the Python copyright . > The failure lasts already for several days: http://sourcef

Re: [Python-Dev] ViewCVS on SourceForge is broken

that you can use this lull in your Python work to > contribute to ZODB development! ViewCVS at zope.org is always happy > to see you: > > http://svn.zope.org/ZODB/trunk/ Thomas Heller <[EMAIL PROTECTED]> writes: > The failure lasts already for several days: > > http:

Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents

[About an ordered dictionary] > Delaney, Timothy C (Timothy) wrote: >> Does anyone else think it would be worthwhile adding these to >> collections, or should I just make a cookbook entry? Greg Ward <[EMAIL PROTECTED]> writes: > +1 on a cookbook entry. +0 on adding to stdlib. "Martin v. Löwis"

Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents

Steven Bethard <[EMAIL PROTECTED]> writes: > Thomas Heller <[EMAIL PROTECTED]> wrote: >> [About an ordered dictionary] > [snip] >> I cannot understand why people are against adding it to stdlib (after >> the name, the implementation, and the exact place hav

[Python-Dev] Re: Python 2.4, distutils, and pure python packages

The following message is a courtesy copy of an article that has been posted to comp.lang.python as well. [CC to python-dev] "Fuzzyman" <[EMAIL PROTECTED]> writes: > Python 2.4 is built with Microsoft Visiual C++ 7. This means that it > uses msvcr7.dll, which *isn't* a standard part of the windows

Re: [Python-Dev] (no subject)

"Phillip J. Eby" <[EMAIL PROTECTED]> writes: > At 05:34 AM 3/14/05 -0800, Michael Chermside wrote: >>Nice... thanks. But I have to ask: is this really the right set of metadata to >> be updating? Here are a few things that perhaps ought be copied by >> update_meta: >> >> f.__name__ (alread

[Python-Dev] Re: [Python-checkins] python/dist/src/Lib/distutils/tests test_dist.py, 1.1, 1.2

[EMAIL PROTECTED] writes: > PEP 314 implementation (client side): I'm not sure where I should post this, but shouldn't there be a way to specify the encoding of the metadata? There are people (not me, fortunately), with umlauts in their names, for example. Thomas __

[Python-Dev] Error checking in init functions

I always wondered why there usually is very sloppy error checking in init functions. Usually it goes like this (I removed declarations and some other lines for clarity): PyMODINIT_FUNC PyInit_zlib(void) { m = Py_InitModule4("zlib", zlib_methods, zlib_module_documentatio

Re: [Python-Dev] New Py_UNICODE doc

Nicholas Bastin <[EMAIL PROTECTED]> writes: > The current documentation for Py_UNICODE states: > > "This type represents a 16-bit unsigned storage type which is used by > Python internally as basis for holding Unicode ordinals. On platforms > where wchar_t is available and also has 16-bits, P

Re: [Python-Dev] New Py_UNICODE doc

"Fredrik Lundh" <[EMAIL PROTECTED]> writes: > Thomas Heller wrote: > >> AFAIK, you can configure Python to use 16-bits or 32-bits Unicode chars, >> independend from the size of wchar_t. The HAVE_USABLE_WCHAR_T macro >> can be used by extension writers t

Re: [Python-Dev] Five patch reviews & patch request

"Michiel De Hoon" <[EMAIL PROTECTED]> writes: > I'd like to ask your attention to this patch: > > [ 1049855 ] PyOS_InputHook inconsistency on Windows > > Kurt Kaiser has already looked at this patch, but was hesitant to check it in > because he wasn't able to test it on Windows. I'd be happy to se

Re: [Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]

Jason Orendorff wrote: > Instead of byte literals, how about a classmethod bytes.from_hex(), which > works like this: > > # two equivalent things > expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a') I hope this will also be equivalent: > expected_md5_hash = bytes.from_he

Re: [Python-Dev] Proposal: defaultdict

> Guido van Rossum wrote: > >> d = DefaultDict([]) >> >> can be written as simply >> >> d[key].append(value) > >> Feedback? > Ok, setdefault is a horrible name. Would it make sense to come up with a better name? Georg Brandl wrote: > Probably a good idea, has been proposed multiple time

Re: [Python-Dev] Proposal: defaultdict

Guido van Rossum wrote: > So here's a new proposal. > > Let's add a generic missing-key handling method to the dict class, as > well as a default_factory slot initialized to None. The implementation > is like this (but in C): > > def on_missing(self, key): > if self.default_factory is not None:

Re: [Python-Dev] Proposal: defaultdict

[cc to py-dev again] Guido van Rossum wrote: > On 2/17/06, Thomas Heller <[EMAIL PROTECTED]> wrote: >> Guido van Rossum wrote: >>> So here's a new proposal. >>> >>> Let's add a generic missing-key handling method to the dict class, as >>

Re: [Python-Dev] Proposal: defaultdict

Guido van Rossum wrote: > On 2/17/06, Thomas Heller <[EMAIL PROTECTED]> wrote: >> Ahem, I'm still looking for ways to 'overtake' the dict to implement >> weird and fancy things. Can on_missing be overridden in subclasses (writing >> the subclass i

<    1   2   3   4   >