Re: [Python-Dev] Search-friendly shortcuts for Windows?
Microsoft recommendations: Avoid putting a version number in a program name unless that is how users normally refer to your program. Put only program shortcuts on the Start menu. Don't put shortcuts to the following items on the Start menu: - Program uninstallers. Users access uninstallers through the Programs control panel item. - Help files. Users access Help topics directly from your program. http://msdn.microsoft.com/en-us/library/aa511447.aspx I think it's fine for Python to use a version number and to put links to the manual in the Start Menu (since Python doesn't have a Help menu). But the uninstall shortcut should go. I also don't think that "command line" should be used in the title. And why is the .CHM file called "Manuals"? Why the plural? When seeing this title I thought that maybe it's a link to the Doc directory. Most of the .CHM files that I have in my Start Menu are called "abc Documentation", and a couple "abc Users Manual". The help file it's also titled "Python v2.7 documentation" when opened, so maybe it should be renamed to "Python 3.2 Documentation". > Initial proposal for 32 bit builds: > - Python 3.2 (command line - 32 bit) > - Python 3.2 Manuals > - Python 3.2 Docs Server (pydoc - 32 bit) > - IDLE (Python 3.2 GUI - 32 bit) > - Uninstall Python 3.2 (32 bit) > > Initial proposal for 64 bit builds: > - Python 3.2 (command line - 64 bit) > - Python 3.2 Manuals > - Python 3.2 Docs Server (pydoc - 64 bit) > - IDLE (Python 3.2 GUI - 64 bit) > - Uninstall Python 3.2 (64 bit) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 status
On Wed, Sep 1, 2010 at 1:42 AM, Antoine Pitrou wrote: > What I think would be a mistake would be to define the API in terms of > Windows-specific quirks. All this discussion seems bent on satisfying > the needs of Windows developers at the expense of non-Windows > developers. "FILE*" is a perfectly standard C feature (and a > widely-used one at that). If Windows doesn't handle it correctly then > it's a Windows issue and we shouldn't annoy other people by refusing > access to that feature. As an alternative the stable ABI could use the native system file handle instead of FILE*. HANDLE (returned by CreateFile) on Windows and int (returned by open) on Linux (or even FILE*). The extension writer would have to write it's own abstraction over this. Python could provide a default wrapper (as a sample). Unfortunately you would also lose the buffering provided by fopen (unless the sample also does this). As a side note, I wrote a plugin for a big Windows application (Mastercam) once. There were at least 5 different CRTs running in that process - 3 different release versions and 2 different debug versions. Besides a few other statically linked into other plugin DLLs. This is quite common, especially since you can have foreign CRTs injected into your process by various shell extensions like TortoiseSVN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] CHM filename (was Released: Python 2.6.6)
On Thu, Aug 26, 2010 at 1:08 AM, "Martin v. Löwis" wrote: > Now, why do the other formats have a version number in them? So that you > can have them all in the same directory, and they won't overwrite each > other. And so that if you downloaded one of them, you'd still know what > it is that you downloaded afterwards. The one deployed with the binaries installer could still be renamed to python.chm. When you start the CHM file, the first thing hitting you is a huge "Python v2.6.5 documentation" header, so I don't think anybody would be confused. And there doesn't seem to be a link to download the CHM files (the last I could find on python.org is for Python 2.6.2). Anyway, this is not a big issue. Regards, Adal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] CHM filename (was Released: Python 2.6.6)
> The question really is whether there is any chance that they will get > released, in some form. There won't be further binary releases (at least > not from python.org), so there definitely won't be a CHM release. Speaking about the CHM, why does it include the version number in it's filename? Why isn't it named python.chm instead of python266.chm, just like we have python.exe and not python266.exe? I have shortcut links in the QuickLaunch area to the documentation for quick access and in a different launcher program. Each time I upgrade Python I must update them because of the embedded version number. Regards, Adal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
Hello, Fred Drake fdrake at acm.org wrote: > +0.5 > > I'd like to see a more complete proposal, including: > > - what to do with Windows, Mac OS X PEP 370 already specifies a directory for Python config files: > user data directory > > Usually the parent directory of the user site directory. It's meant for > Python version specific data like config files, docs, > images and > translations. > > Unix (including Mac) > ~/.local/lib/python2.6 > Windows > %APPDATA%/Python/Python26 Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When do sets shrink?
I did a little test using MSVC 8.0 on WinXP. I allocated 128 MB using 128 different buffers of 1 MB each, freed half of them (alternatively) then freed the remaining half. I monitored memory usage using the Task Manager and memory is really freed as indicated by both the "Mem Usage" and "VM Size" process counters and also by the global "Commit Charge". After exiting the process the commit charge remains the same, suggesting that all the memory was indeed released. Even if the Windows heap documentation says that once memory is allocated, it won't be released until the heap is destroyed, this seems to not be true when allocating large chunks. There probably is a threshold after which VirtualAlloc is used. #include #include #include #define COUNT 128 void main() { char** ptr = malloc(COUNT * sizeof(char*)); int i; for (i = 0; i < COUNT; ++i) { ptr[i] = malloc(1024 * 1024); // Touch memory to really commit it. SecureZeroMemory(ptr[i], 1024 * 1024); } printf("Mem allocated\n"); Sleep(5000); for (i = 0; i < COUNT; i += 2) free(ptr[i]); printf("Half memory deallocated\n"); Sleep(1); for (i = 1; i < COUNT; i += 2) free(ptr[i]); printf("Full memory deallocated\n"); Sleep(1); } ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] When do sets shrink?
On Thursday, December 29, 2005 "Martin v. Löwis" wrote: > Noam Raphael wrote: > In this specific case, perhaps. malloc will typically return memory to > the system only if that memory is at the end of the heap. If there > is more memory after block to be released, it can't return the memory > block, because it won't punch a whole into the heap. > So as soon as you have more than one object, things become interesting. > Different systems use different, enhance strategies, of course. For > example, Linux glibc malloc will allocate "large" blocks through > mmap (instead of sbrk), such blocks then can be returned individually. MSVC 7.1 and 8.0 malloc always uses the Windows heap functions (HeapAlloc & friends) if running on Windows 2000 or newer (malloc.c and heapinit.c). So it seems that for both Linux (gcc) and Win (msvc) the memory is released to the operating system. Of course, fragmentation is still an issue, but now it's on the OS side of things. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Keep default comparisons - or add a second set?
On Wednesday, December 28, 2005 Noam Raphael wrote: > I came to think that, when forgetting backwards compatibility for a > while, the best thing for comparison operators to do is to raise a > TypeError by default, and work only for types that it makes sense to > compare. I think it is more "explicit is better than implicit", and I > have now two reasons for that: > 1. Things like "Decimal(3.0) == 3.0" will make more sense (raise an > exception which explains that Decimals should not be compared to > floats, instead of returning false constantly). > 2. It is more forward compatible - when it is discovered that two > types can sensibly be compared, the comparison can be defined, without > changing an existing behaviour which doesn't raise an exception. I agree. Here's what happens if you try to compare a string and an int in .NET (it's a compiler error): error CS0019: Operator '<' cannot be applied to operands of type 'string' and 'int' error CS0019: Operator '==' cannot be applied to operands of type 'string' and 'int' Of course, C# is not a dynamic language so things are stricter in general. Maybe having == and != work for whatever combination of types is not such a bad thing. After all, 10 != "text", but then what about Decimal(3.0) == 3.0? It doesn't make sense to say that a function object is smaller or bigger than a string. And if you sort a list of different objects based on theirs address or something similar, can you really consider that list sorted? If you want to normalize a list, you can sort it by using id(item) as a key and not rely on default comparasions. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python + Visual C++ 8.0?
On Tuesday, December 27, 2005 Ralf W. Grosse-Kunstleve wrote: > Sorry, the manifests are new to me. How can I check if the manifest is > correctly embedded? > FWIW: I already tried copying the manifest into the directory with the > extensions. To check if you have a manifest you need to use a tool like "Resource Hacker" or "XN Resource Editor". http://www.wilsonc.demon.co.uk/d10resourceeditor.htm Where did you get that manifest? You need one listing the MSVC runtime (not one which enables the XP look). Of course, it must be named exactly like you dll/pyd, with an additional .manifest extension. > In case it matters, here are the compiler and liker switches I am using > (commands issued by scons): > cl /nologo /D_CRT_SECURE_NO_DEPRECATE /wd4996 /Zm800 /MD /GR /EHsc > /DBOOST_DISABLE_THREADS /DNDEBUG /Ox -DBOOST_PYTHON_MAX_BASES=2 > -DBOOST_PYTHON_SOURCE > link /nologo /incremental:no /dll /out:lib\cctbx_math_ext.pyd > /implib:lib\cctbx_math_ext.lib /LIBPATH:lib > Am I missing some magic new switch? Add /manifest to the linker options. This will generate cctbx_math_ext.pyd.manifest either in the output folder or in the intermediate one. Then you need to run mt.exe to embedd the manifest: mt.exe /outputresource:"cctbx_math_ext.pyd;#2" /manifest cctbx_math_ext.pyd.manifest ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a quit that actually quits
On Wednesday, December 28, 2005 Fredrik Lundh wrote: > WinXP or WinXP+Cygwin ? here's what I get: Normal WinXP, without Cygwin. >>python > Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. ^Z >> >>python > Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. ^D > File "", line 1 > ? > ^ > SyntaxError: invalid syntax I tracked this down to having IPython installed. I was able to get the exact behaviour you've got by disabling the "readline" package from "site-packages". I have a solution proposal (I have no idea if it's feasible): why not intercept "exit" and "quit" in the interpreter command line parser? A simple regexp should do. Is the interactive interpreter implemented in Python or on the C side? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a quit that actually quits
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. >>> exit 'Use Ctrl-Z plus Return to exit.' >>> I've just tried Ctrl+Z (plus Return) and some variations on Win XP and it doesn't work! Ctrl+D does. Beside, it should be spelled Ctrl+Z and not Ctrl-Z (at least this is the Windows way). I think it's intuitive for exit/quit to exit the interactive interpreter. That's what I did the first time I've tried Python. In another one (I think CLISP, but I'm not sure) I couldn't figure out how to exit. And definatly in CLISP when trying simple things I always got stuck in some kind or different error mode (with a different prompt). That's why I gave up playing with it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python + Visual C++ 8.0?
Python uses LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag which means that DLLs used by the extension will be searched IN THE EXTENSION FOLDER and not on PATH. Try putting msvcp80.dll right next to your extension DLL. It is a little strange that it is not loaded directly from the Windows side by side folder (%WINDIR%\WinSxS). You should check if the manifest is embedded correctly inside the DLL. And like Martin said, mixing Python and extensions compiled with different compilers is a bad idea. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com