Re: [Python-Dev] distutils, win32, multiple C extensions
Python-List (http://mail.python.org/mailman/listinfo/python-list) is the better place for this kind of question; Python-Dev is for the development of Python itself, not for development using Python. When you built E1, it should have also built a .lib file in addition to the .pyd. It's the .lib that needs to be referenced when building E2. If it did not, you may find this link helpful: http://www.mingw.org/wiki/CreateImportLibraries On Tue, Apr 23, 2013 at 4:18 AM, Emmanuel Bacry emmanuel.ba...@polytechnique.fr wrote: Hello, I am a researcher in Applied Math. For my work I write a lot of code and right now I am moving to python. I am writing some C extensions (using swig). I wrote a first extension (a python module) which I'll call E1. I wrote a setup.py which works fine on all platforms. On Windows 7 it creates a library which is a .pyd file Now I want to write a second C extension E2 that is calling some functions of E1. The same kind of setup.py works fine on all platforms but Windows where it says (during the link) that the function sof E1 that are called by E2 are unreferenced. I am clearly not a Windows pro ... I am using mingw32 on Windows. Surfing the web, I understood that shared libraries work differently on windows than on other platforms. And that I should 1- export the symbols (i.e., the functions) of E1 when I build E1. In the distutils.Extension this seems to be done using argument export_symbols=[list of symbols to export] Now I have one problem : each time I specify in this list the name of a function in E1 it says that it doesn't know this symbol What am I doing wrong here, is there a special syntax ? 2- Now in the setup.py of E2 how do I declare that I want to use the E1 shared lib.? Is the information on the exported symbol of E1 in the .pyd file or in the .def file ? I tried to specify the .pyd library in the arguments of the distutils.Extension but I have the feeling that's not the right thing to do (I have the feeling the .pyd is not the right file to point to) Not mentioning the problem specifying the path of the library with runtime_library_dirs ... which does not seem to work at all. Is there a simple way to do what I want to do ? I did not find anything on the web explaining clearly what to do ... I am really really stuck I would appreciate any kind of help Emmanuel ___ 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/curt%40hagenlocher.org ___ 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] VS 11 Express is Metro only.
On Fri, May 25, 2012 at 5:06 AM, mar...@v.loewis.de wrote: It is better documented here, and seems something to start thinking about: http://arstechnica.com/**information-technology/2012/** 05/no-cost-desktop-software-**development-is-dead-on-**windows-8/http://arstechnica.com/information-technology/2012/05/no-cost-desktop-software-development-is-dead-on-windows-8/ This isn't actually better documentation, since it talks about the future, without being official (i.e. it's Peter Bright's opinion, not a Microsoft announcement). I hereby predict that Microsoft will revert this decision, and that VS Express 11 will be able to build CPython. But will it be able to target Windows XP? http://connect.microsoft.com/VisualStudio/feedback/details/690617/bug-apps-created-with-crt-and-mfc-vnext-11-cannot-be-used-on-windows-xp-sp3 (Disclaimer: I work at Microsoft, but I know nothing about either of these topics.) -Curt ___ 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] Does trunk still support any compilers that *don't* allow declaring variables after code?
On Wed, May 2, 2012 at 6:56 AM, Stefan Behnel stefan...@behnel.de wrote: I'm not sure if MSVC and MSVC++ are the same thing, but I surely remember reports by MSVC users only a few years ago that Cython generated C code contained a declaration after an executed code at some point, and that failed to compile for them. So, assuming that MSVC++ added this extension in the early 90s and didn't remove it in the meantime, they must be two different things. I believe you need to tell MSVC that it's a C++ source file by using /Tp in order to make this work. And of course, there would be other ramifications for doing that. -Curt ___ 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] Draft PEP and reference implementation of a Python launcher for Windows
On Sun, Mar 20, 2011 at 6:27 PM, Martin v. Löwis mar...@v.loewis.de wrote: I'm primarily bothered about the failure to implement TerminateProcess correctly. I don't actually know what use cases would be affected, other then saying that anything launching py.exe could be affect, in particular applications using ShellExecuteEx. I don't think it is feasible to change them all to launch something different instead; some may be out of our control. Potential candidates would be web servers. This can be worked around, depending on the level of inelegance you're willing to accept. A third watchdog process could wait on the launcher being terminated, and use that to terminate the child Python.exe process. Alternatively, the launcher could inject a sentinel thread into the Python.exe process using CreateRemoteThread. Both approaches would work for any target implementation or bitness of Python. -Curt ___ 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] Windows
On Wed, Aug 4, 2010 at 8:25 AM, Paul Moore p.f.mo...@gmail.com wrote: However, from my own experience, the Windows buildbot environment is fairly flaky, and I spend far too much time killing stuck python processes and VS JIT debugger processes, rather than actually usefully debugging real issues. I would turn off JIT debugging. On an unattended machine, it's more annoying than useful. http://msdn.microsoft.com/en-us/library/5hs4b7a6(VS.80).aspx -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Why is nan != nan?
On Thu, Mar 25, 2010 at 7:08 AM, Nick Coghlan ncogh...@gmail.com wrote: Jesus Cea wrote: But IEEE 754 was created by pretty clever guys and sure they had a reason for define things in the way they are. Probably we are missing something. Yes, this is where their implementable in a hardware circuit focus comes in. They were primarily thinking of a floating point representation where the 32/64 bits are *it* - you can't have multiple NaNs because you don't have the bits available to describe them. Wait, what? I haven't been paying much attention, but this is backwards. There are multiple representations of NaN in the IEEE encoding; that's actually part of the problem with saying that NaN = NaN or NaN != NaN. If you want to ignore the payload in the NaN, then you're not just comparing bits any more. -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Why is nan != nan?
On Thu, Mar 25, 2010 at 7:54 AM, Mark Dickinson dicki...@gmail.com wrote: Hmm. I take it back. I was being confused by the fact that sqrt(nan) returns a nan with a new identity; but it does apparently preserve the payload. An example: I played with this some a few months ago, and both the FPU and the C libraries I tested will preserve the payload. I imagine Python just inherits their behavior. -- Curt Hagenlocher c...@hagenlocher.org ___ 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 3148] futures - execute computations asynchronously
On Fri, Mar 5, 2010 at 8:35 AM, Jesse Noller jnol...@gmail.com wrote: On Fri, Mar 5, 2010 at 11:21 AM, Daniel Stutzbach dan...@stutzbachenterprises.com wrote: On Fri, Mar 5, 2010 at 12:03 AM, Brian Quinlan br...@sweetapp.com wrote: import futures +1 on the idea, -1 on the name. It's too similar to from __future__ import Futures is a common term for this, and implemented named this in other languages. I don't think we should be adopting things that are common, and found elsewhere and then renaming them. Another common term for this is a promise. -- Curt Hagenlocher c...@hagenlocher.org ___ 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 3147: PYC Repository Directories
On Sun, Jan 31, 2010 at 11:16 AM, Terry Reedy tjre...@udel.edu wrote: 'pycache' would be pretty clear. Heh -- without the underscores, I read this as pyc ache. Seems appropriate. -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Integer behaviour in Python 2.6.4
On Sun, Nov 1, 2009 at 8:22 PM, Sturla Molden stu...@molden.no wrote: Why does this happen? type(2**31-1) type 'long' Does that not happen on non-Windows platforms? 2**31 can't be represented as a 32-bit signed integer, so it's automatically promoted to a long. -- Curt Hagenlocher c...@hagenlocher.org ___ 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] time.clock() on windows
On Wed, Oct 21, 2009 at 1:51 PM, Antoine Pitrou solip...@pitrou.net wrote: Kristján Valur Jónsson kristjan at ccpgames.com writes: You are right, on windows time.clock() is based relative to its first call in the process. There is no such promise made on unix. QueryPerformanceCounter() (what time.clock uses()) is a robust high resolution timer that is processor/core independent. It should be possible to use it across different processes too, if this annoying rebasing wasn't there. Well, could we simply have a high-resolution time.time()? Or is Windows just too limited to provide this? Presumably you could fake something like this by combining output from an initial time(), an initial QueryPerformanceCounter() and the current QueryPerformanceCounter(). But it makes more sense to understand why someone chose to implement time.clock() on Windows the way they did -- this seems very broken to me, and I think it should be changed. Of course, there are no doubt people relying on the broken behavior... -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Support for Python/Windows
On Tue, Jul 21, 2009 at 2:36 PM, Christian Heimes li...@cheimes.de wrote: Does the MSDN subscription also include the permission to create and release binaries? Sam Ramji wrote just developing and testing. Me and probably all other subscribers like to use the MSDN subscription to build Windows binaries of Python and Python related extensions. Can you please verify that we are allowed to use the subscription for that purpose, too? Considering that the compilers are all freely downloadable as part of the Windows SDK, it would be weird if the subscription were *more* restrictive than what you can get without it. Disclaimer: I work for Microsoft, but eh, I'm just guessing. -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Support for Python/Windows
On Tue, Jul 21, 2009 at 3:04 PM, Christian Heimesli...@cheimes.de wrote: Some features like PGO aren't available in VS Express Edition or Windows SDK. I'm not sure about all aspects of X86_64 builds, too. I'm prefer better safe than sorry. Ah, you're right -- the PGO bits probably need VS Pro. The 64-bit compilers should be in the Windows SDK, but it wouldn't surprise me if they were not included in Express. -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Windows Toolchain
On Mon, Jul 13, 2009 at 2:04 PM, Nick Coghlan ncogh...@gmail.com wrote: P.S. I must admit I've never really understood how Data Execution Prevention is ever going to work in a world with interpreted languages and just in time compilers... the line between data and code is fuzzier than one might think for a lot of programs... The OS has to provide a mechanism to enable execution for a particular region of memory. Under Windows, this is done by the VirtualProtect function. -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Windows Toolchain
On Mon, Jul 13, 2009 at 2:55 PM, Antoine Pitrou solip...@pitrou.net wrote: Curt Hagenlocher curt at hagenlocher.org writes: The OS has to provide a mechanism to enable execution for a particular region of memory. Under Windows, this is done by the VirtualProtect function. More surprising is that Microsoft didn't whitelist their own toolchain. But dev tools don't actually execute the code they create in-process; they write the executable code out to disk and a new process is spun up from that image. So there should be no need to disable DEP for anything that the toolchain creates directly. Given that this was affecting multiple programs, the most likely culprit is either an anti-virus program or a virus -- though you probably can't rule out some kind of glitch in the OS itself. :/ -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Making the GIL faster lighter on Windows
On Wed, May 27, 2009 at 4:24 AM, Nick Coghlan ncogh...@gmail.com wrote: CriticalSections are first come first served on Windows, just like a regular mutex. Starting with Windows Server 2003 with Service Pack 1 (SP1), threads waiting on a critical section do not acquire the critical section on a first-come, first-serve basis. http://msdn.microsoft.com/en-us/library/ms682530(VS.85).aspx Windows critical sections use events for kernel-level synchronization. The user-mode code basically consists of an interlocked instruction inside the spin loop. When the likelihood of contention is low, a critical section should be a big win because it won't need to switch into the kernel. I suspect that contention will be frequent for the GIL A good description of pre-Vista Windows critical sections can be found here: http://msdn.microsoft.com/en-us/magazine/cc164040.aspx -- Curt Hagenlocher c...@hagenlocher.org ___ 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 suggestion ... Re: PEP 383 (again)
On Wed, Apr 29, 2009 at 8:16 PM, Thomas Breuel tmb...@gmail.com wrote: Also, what are Jython and IronPython supposed to do on UNIX? Can they implement these semantics at all? IronPython will inherit whatever behavior Mono has implemented. The Microsoft CLR defines the native string type as UTF-16 and all of the managed APIs for things like file names and environmental variables operate on UTF-16 strings -- there simply are no byte string APIs. I assume that Mono does the same but I don't have any Mono experience. -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Test failures under Windows?
2009/3/25 Kristján Valur Jónsson krist...@ccpgames.com: I'm going to poke my contacts at Microsoft and ask them if there is a way to disable popups like this for a process that runs unattended and/or is running as a windows service. MSVC has shipped with runtime library source since the 16-bit days, so the easier thing is just to read the source code. :) It looks like there are two possible code paths for the assertion. The first code path uses functions in dbgrpt[t].c and its behavior is controlled by CrtSetReportMode and CrtSetReportFile. The second uses functions in assert.c and its behavior is controlled by _set_error_mode. Both code paths use __crtMessageBox in crtmbox.c to actually display the message box. This function -- when running as a service -- will helpfully set MB_SERVICE_NOTIFICATION before calling the USER32 MessageBox, which ensures that you'll see exactly why your service has hung the next time you actually log in with sufficient rights. :/ The variation that goes through assert.c should write to stderr for a console-mode application, so it's reasonable to assume that we're hitting the other code path -- and that Mark's suggestion to use CrtSetReportMode would address the issue. -- Curt Hagenlocher c...@hagenlocher.org ___ 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] setuptools has divided the Python community
On Wed, Mar 25, 2009 at 5:25 AM, Antoine Pitrou solip...@pitrou.net wrote: I'm not a Windows user, but I suppose it boils down to whether people are comfortable with the command-line or not (which even many Windows /developers/ aren't). Since having GUIs for everything is part of the Windows philosophy, it's a fair expectation that Python libraries come with graphical Windows installers. MSIs aren't only about the GUI; they're also about management. For instance, an MSI can be pushed out to clients using Active Directory. This simplifies not only initial deployment but also subsequent updates -- particularly when you're dealing with many clients. -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Test failures under Windows?
On Tue, Mar 24, 2009 at 11:49 AM, David Bolen db3l@gmail.com wrote: Kristján Valur Jónsson krist...@ccpgames.com writes: These issues should be resolved in the py3k branch, but it will need porting to 2.6. Dialogue boxes are annoying, but do they pop up if you run your buildslave as a service without access to the console? Not sure what the MSVC++ runtime does with assertion dialogs if run without interactive access (they aren't console messages, but UI dialog popups). At least at some point in the past, it didn't check to see if there was an attached window station. But the dialog can be disabled in debug mode by using the _set_error_mode function. (http://msdn.microsoft.com/en-us/library/sas1dkb2(VS.71).aspx) -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Test failures under Windows?
On Tue, Mar 24, 2009 at 3:45 PM, Antoine Pitrou solip...@pitrou.net wrote: Mark Hammond skippy.hammond at gmail.com writes: Note that I previously opened http://bugs.python.org/issue5116 with a patch to enable this to be controlled from Python via the msvcrt module. This would enable the test suite to disable assertions for its entire run. We certainly don't want to disable assertions during the test suite if it silences bugs which can crash the user's interpreter. I assume the goal would be to write them to stdout or stderr instead of hanging the process by throwing up a dialog box. For that matter, you could use CrtSetReportFile to redirect them to any given file and then assert at the end of the test run that the file is empty. -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Are property descriptors intended to be immutable?
On Fri, Feb 6, 2009 at 4:04 PM, Guido van Rossum gu...@python.org wrote: On Fri, Feb 6, 2009 at 2:44 PM, Curt Hagenlocher c...@hagenlocher.org wrote: ...because they're not quite :). Should I file this as a bug report? No, this is just how it works. I hope they aren't documented as immuable? Not that I know of :). But the individual properties of the descriptor are all read-only and that the implementations of setter, getter and deleter return new objects instead of mutating and returning the old descriptor. So it seemed a little odd that there was just one way remaining in which the object could be mutated. (I'm a recent convert to the joys of immutability. :) -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Are property descriptors intended to be immutable?
...because they're not quite :). Should I file this as a bug report? (I get the same results under 2.6 and 3.0.) PS C:\Program Files (x86)\CCP\EVE C:\Python25\python.exe Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. class x(object): ... @property ... def foo(self): return 1 ... inst = x() inst.foo 1 x.foo.__init__(lambda self: 2) inst.foo 2 ^Z -- Curt Hagenlocher c...@hagenlocher.org ___ 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] 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 matthieu.bruc...@gmail.com wrote: 2009/1/25 Luke Kenneth Casson Leighton l...@lkcl.net: 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 c...@hagenlocher.org ___ 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] 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 l...@lkcl.net 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 c...@hagenlocher.org ___ 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] __del__ and tp_dealloc in the IO lib
On Thu, Jan 22, 2009 at 5:22 PM, Giovanni Bajo ra...@develer.com wrote: On Mon, 19 Jan 2009 01:38:18 +, Gregory P. Smith wrote: I regularly point out in code reviews that the very convenient and common idiom of open(name, 'w').write(data) doesn't guarantee when the file will be closed; its up to the GC implementation details. Which, to me, sounds like please, don't assume that bytes are 8-bits wide; this depends on implementation details of your CPU. I think it's a lot more like please, don't assume that there's a Global Interpreter Lock -- something that the implementation shouldn't change without good reason and sufficient warning, but which isn't actually part of the language specification. And of course, such advice always carries more weight for code that's intended to be reusable than it does for code that has little chance of escaping the application it's in. -- Curt Hagenlocher c...@hagenlocher.org ___ 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] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Tue, Jan 20, 2009 at 6:18 AM, Luke Kenneth Casson Leighton l...@lkcl.net wrote: yeah they said the same thing about gas ovens, too. not the nazi gas ovens, the phrase my mother used to say if someone stuck their head in a gas oven, would you do the same?. I don't know who is forcing you to use a platform that you hate so much, but I respectfully suggest that this person is not on any of these mailing lists. -- Curt Hagenlocher c...@hagenlocher.org ___ 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-3.0, unicode, and os.environ
On Fri, Dec 12, 2008 at 5:06 AM, Antoine Pitrou solip...@pitrou.net wrote: Curt Hagenlocher curt at hagenlocher.org writes: There's this other obscure platform called Java... ;) Does it have a filesystem? No, but it also has to interact with filesystems of possibly invalid or indeterminate encodings. What does java.io do? -- Curt Hagenlocher c...@hagenlocher.org ___ 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-3.0, unicode, and os.environ
On Fri, Dec 12, 2008 at 6:19 AM, Antoine Pitrou solip...@pitrou.net wrote: Curt Hagenlocher curt at hagenlocher.org writes: No, but it also has to interact with filesystems of possibly invalid or indeterminate encodings. What does java.io do? My point was that Python doesn't have to interact with the Java IO libraries, while it has to interact with the Unix and Windows IO APIs. Of course. But the Java IO libraries have to interact with the Unix and Windows IO APIs as well. It might be interesting to know how they handle similar situations. -- Curt Hagenlocher c...@hagenlocher.org ___ 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] Fwd: Removal of GIL through refcounting removal.
On Mon, Nov 3, 2008 at 11:50 AM, Josiah Carlson [EMAIL PROTECTED]wrote: On Sun, Nov 2, 2008 at 3:51 PM, [EMAIL PROTECTED] wrote: Antoine I think it is important to remind that the GIL doesn't prevent Antoine (almost) true multithreading. The only thing it prevents is Antoine full use of multi-CPU resources in a single process. I believe everyone here knows that. I believe what most people are clamoring for is to make full use of their multi-CPU resources in a single process. Which is, arguably, silly. As we've seen in the last 2 months with Chrome, multiple processes for a single program is actually a pretty good idea. With the multiprocessing module in the standard library offering a threading-like interface, people no longer have any excuses for not fully exploiting their multiple cores in Python. There is no shortage of algorithms (such as matrix multiplication) that are parallelizable but not particularly good candidates for an IPC-based multiprocessing paradigm. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] bsddb
On Thu, Sep 4, 2008 at 7:33 AM, Oleg Broytmann [EMAIL PROTECTED] wrote: SQLite is public domain; the licensing terms of Berkeley DB[1] are not friendly to commercial applications: Our open source license ... permits use of Berkeley DB in open source projects or in applications that are not distributed to third parties. I am not sure if using of PyBSDDB in commercial applications is considered using of Berkeley DB in open source projects; Wow, I hadn't realized that it was such a restrictive license. When I see Berkeley I think BSD license. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] Add python.exe to PATH environment variable
One of these days, I'm actually going to remember that I need to click Reply All when posting to this list... . Sorry for the duplicate, Greg. On Tue, Sep 2, 2008 at 6:45 PM, Greg Ewing [EMAIL PROTECTED] wrote: A better way would be to start a command process with the Python directory added to PATH just for that process. This is similar to what Visual Studio or the Windows SDK do to give you a command prompt with the PATH and other environmental variables setup correctly -- they add a shortcut to a batch file that's set to keep the command prompt open after the batch file runs. How easy would that be to do on Windows? Do environment variables get inherited by child processes the way they do on Unix? Generally, yes. I think there's a catch in that there are ways to start processes that don't make them children of your process, but I don't remember why I think that. One other reason not to mess with the PATH -- at least by default -- is that the user may have multiple copies of Python installed. I know I have at least one machine with 2.4.5, 2.5.2, 2.6b2 and 3.0b2 installed -- and I don't want *any* of them in my path. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] subprocess insufficiently platform-independent?
On Wed, Aug 27, 2008 at 9:43 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 8:08 PM, Mark Hammond [EMAIL PROTECTED] wrote: Then it works on Linux, but fails on Windows because it does not perform the Windows %PATHEXT% search that allows it to find that svn.exe is the actual executable to be invoked. I can't reproduce this as described. Which Windows version? This sounds like one of those things that could well vary by Windows version; if it works for you in Vista it may well be broken in XP. It could also vary by other setup parameters besides PATHEXT. When passing the executable name to CreateProcess via the lpCommandLine parameter, PATH is considered but PATHEXT is ignored. The only extension that's automatically appended is .exe, and only if no other extension is present. This has been true for as long as I can remember. I've found the documentation for CreateProcess (http://msdn.microsoft.com/en-us/library/ms682425.aspx) to be pretty reliable. And the mention of a .com in the docs suggests that the description has been around for a while... -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] RELEASED Python 2.6b3 and 3.0b3
On Thu, Aug 21, 2008 at 7:09 AM, Cesare Di Mauro [EMAIL PROTECTED] wrote: import Tkinter Traceback (most recent call last): File stdin, line 1, in module File c:\tmp\Python-2.6b3\lib\lib-tk\Tkinter.py, line 38, in module import FixTk File c:\tmp\Python-2.6b3\lib\lib-tk\FixTk.py, line 28, in module import _tkinter ImportError: DLL load failed: Impossibile trovare il modulo specificato. It seems that its impossible to find the _tkinter module, but in PCbuild I've found these files: 21/08/2008 10.3534.304 _tkinter.pyd The most likely explanation for this is that _tkinter.pyd has a static dependency that can't be loaded. If, for instance, the TCL and TK DLLs themselves are neither in PCbuild nor elsewhere in the path, then you wouldn't be able to load _tkinter. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] Milestones in IronPython
We reached an important milestone in the IronPython project this week with the release of IronPython 2.0 beta 4. But it's not our code that makes this release so remarkable -- it's yours, the Python developers. For the first time, Microsoft is including the standard Python library as part of what you can download from CodePlex. Previously, users of IronPython who wanted to make use of the urllib module (to give just one example) would have to download the CPython distribution separately and then fiddle with the bits on the disk to make them work together. That is no longer the case. Of course, this isn't any kind of great technical achievement -- but it is legal and cultural progress here at Microsoft. All of us working on the IronPython and IronRuby projects are committed to pulling the company in a more open source direction, so it's very gratifying to see this happening. Links: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=14353 http://devhawk.net/2008/08/06/Including+The+Batteries+In+IronPython.aspx (IronPython 2.0 targets compatibility with Python 2.5.) -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] Infix operators
On Wed, Jul 23, 2008 at 4:48 PM, Sebastien Loisel [EMAIL PROTECTED] wrote: On Wed, Jul 23, 2008 at 7:11 PM, Josiah Carlson [EMAIL PROTECTED] wrote: language, I would ask you if logix (http://www.livelogix.net/logix/intro.html) would suit you better. It seems to allow you to use arbitrary punctuation for operators. Thank you for the pointer. I have taken a look and it does look interesting, on first blush I would love to use that language. The main thing is that I worry about being out on the fringe, using a language that nobody uses, and which may get abandoned without warning (like Sun abandoned `self'), or be buggier just because people don't use it... Have you considered OCaml? (http://en.wikipedia.org/wiki/Ocaml) It's in reasonably broad use and is actively maintained, and it allows user-defined infix operators. A programming language can't be all things to all people. That's why there's room in the world for more than one. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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 FAQ: Why doesn't Python have a with statement?
On Thu, Jun 19, 2008 at 4:54 AM, C. Titus Brown [EMAIL PROTECTED] wrote: More generally, I've never understood why some people insist that certain features make Ruby better for DSLs -- are code blocks really that important to DSLs? Or is it just the lack of parens?? Code blocks let Ruby-based DSLs do flow control, while the lack of parens make ordinary method names look like keywords. These things are a mixed bag -- on the one hand, they can certainly make the resulting DSL a lot easier to read. On the other, they seem to encourage a lot of over-the-top cleverness in terms of creating fluent interfaces. I fail to see much value in being able to write code that says 7.seconds.ago. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] Epoch and Platform
Any chance of an Official Pronouncement on this topic? It would help us greatly -- even if only to figure out who'll be paying for the next round of beer. On Mon, Jun 16, 2008 at 4:38 PM, Guido van Rossum [EMAIL PROTECTED] wrote: ISTR that we force the epoch to be 1970 on all major platforms -- or perhaps it happens to be 1970 even on Windows when using MS's C runtime. On Mon, Jun 16, 2008 at 4:08 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote: The documentation for the time module says that the epoch is the point where the time starts. On January 1st of that year, at 0 hours, the ``time since the epoch'' is zero. For Unix, the epoch is 1970. To find out what the epoch is, look at gmtime(0). This confirms that the epoch is platform-specific. As such, the only legal uses of the timestamp should be 1) comparing with another timestamp to determine elapsed time in seconds 2) passing to another standard Python library function which expects a timestamp 3) as a source of randomness. However, the following files in the standard library have hardcoded the assumption that the Python epoch will always be the same as the Unix epoch: In gzip.py, method GzipFile._write_gzip_header In tarfile.py, method _Stream._init_write_gz In uuid.py, function uuid1 Additionally, the following files in the standard library have hardcoded the assumption that the Python epoch will cause timestamps to fall within the range of a 32-bit unsigned integer value: In imputil.py, function _compile In py_compile.py, function compile So there's some kind of a potential discrepancy here, albeit a minor one. This discrepancy can be resolved in one of at least three ways: 1) The documentation for the time module is wrong, and the epoch for Python (at least versions 2.x) should be the Unix epoch. 2) These library functions are slightly wrong and should be modified by subtracing an epoch offset before doing other calculations. This offset can be calculated as time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - time.timezone. 3) These library files should be considered part of the platform-specific implementation, and an alternate platform should provide its own version of these files if necessary. Any thoughts on this? From the perspective of implementing IronPython, I'd prefer that the answer is 1 or 2 -- but mainly I just want to be as compatible with the spec as possible, while respecting CLR-specific norms for functionality which is left up to individual implementations. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Epoch and Platform
I don't *feel* anxious, but my doctor *has* been trying to persuade me to switch to decaf... There's no real urgency. The reason this came up is because I just implemented zlib, which automatically enabled the gzip unit tests. The gzip tests are failing because the current timestamp can't be written as a 32-bit value. In order to checkin my changes, I can't have any failing tests -- so my choices are 1) change the IronPython epoch so that the timestamp works for gzip and tarlib 2) change gzip and tarlib to work with a less standard epoch, or 3) disable the failing test(s) ...and I'd rather not resort to #3, if possible. On Tue, Jun 17, 2008 at 10:03 AM, Guido van Rossum [EMAIL PROTECTED] wrote: Can you explain why you are so anxious to get this resolved (apart from the beer :-) ? On Tue, Jun 17, 2008 at 9:26 AM, Curt Hagenlocher [EMAIL PROTECTED] wrote: Any chance of an Official Pronouncement on this topic? It would help us greatly -- even if only to figure out who'll be paying for the next round of beer. On Mon, Jun 16, 2008 at 4:38 PM, Guido van Rossum [EMAIL PROTECTED] wrote: ISTR that we force the epoch to be 1970 on all major platforms -- or perhaps it happens to be 1970 even on Windows when using MS's C runtime. On Mon, Jun 16, 2008 at 4:08 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote: The documentation for the time module says that the epoch is the point where the time starts. On January 1st of that year, at 0 hours, the ``time since the epoch'' is zero. For Unix, the epoch is 1970. To find out what the epoch is, look at gmtime(0). This confirms that the epoch is platform-specific. As such, the only legal uses of the timestamp should be 1) comparing with another timestamp to determine elapsed time in seconds 2) passing to another standard Python library function which expects a timestamp 3) as a source of randomness. However, the following files in the standard library have hardcoded the assumption that the Python epoch will always be the same as the Unix epoch: In gzip.py, method GzipFile._write_gzip_header In tarfile.py, method _Stream._init_write_gz In uuid.py, function uuid1 Additionally, the following files in the standard library have hardcoded the assumption that the Python epoch will cause timestamps to fall within the range of a 32-bit unsigned integer value: In imputil.py, function _compile In py_compile.py, function compile So there's some kind of a potential discrepancy here, albeit a minor one. This discrepancy can be resolved in one of at least three ways: 1) The documentation for the time module is wrong, and the epoch for Python (at least versions 2.x) should be the Unix epoch. 2) These library functions are slightly wrong and should be modified by subtracing an epoch offset before doing other calculations. This offset can be calculated as time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - time.timezone. 3) These library files should be considered part of the platform-specific implementation, and an alternate platform should provide its own version of these files if necessary. Any thoughts on this? From the perspective of implementing IronPython, I'd prefer that the answer is 1 or 2 -- but mainly I just want to be as compatible with the spec as possible, while respecting CLR-specific norms for functionality which is left up to individual implementations. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Epoch and Platform
On Tue, Jun 17, 2008 at 10:56 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On Tue, Jun 17, 2008 at 10:40 AM, Curt Hagenlocher [EMAIL PROTECTED] wrote: There's no real urgency. The reason this came up is because I just implemented zlib, which automatically enabled the gzip unit tests. The gzip tests are failing because the current timestamp can't be written as a 32-bit value. Why is that? Is it because your epoch is different? If so, I would much prefer the epoch to be 1970. (Maybe this is the resolution you're seeking?) Yes! Except that I was hoping for something a little stronger, like the epoch must be 1970 or the epoch can be anything you want, but you're utterly retarded if you pick something other than 1970. But I'll definitely settle for much prefer. :) Thanks, -Curt -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] Epoch and Platform
The documentation for the time module says that the epoch is the point where the time starts. On January 1st of that year, at 0 hours, the ``time since the epoch'' is zero. For Unix, the epoch is 1970. To find out what the epoch is, look at gmtime(0). This confirms that the epoch is platform-specific. As such, the only legal uses of the timestamp should be 1) comparing with another timestamp to determine elapsed time in seconds 2) passing to another standard Python library function which expects a timestamp 3) as a source of randomness. However, the following files in the standard library have hardcoded the assumption that the Python epoch will always be the same as the Unix epoch: In gzip.py, method GzipFile._write_gzip_header In tarfile.py, method _Stream._init_write_gz In uuid.py, function uuid1 Additionally, the following files in the standard library have hardcoded the assumption that the Python epoch will cause timestamps to fall within the range of a 32-bit unsigned integer value: In imputil.py, function _compile In py_compile.py, function compile So there's some kind of a potential discrepancy here, albeit a minor one. This discrepancy can be resolved in one of at least three ways: 1) The documentation for the time module is wrong, and the epoch for Python (at least versions 2.x) should be the Unix epoch. 2) These library functions are slightly wrong and should be modified by subtracing an epoch offset before doing other calculations. This offset can be calculated as time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - time.timezone. 3) These library files should be considered part of the platform-specific implementation, and an alternate platform should provide its own version of these files if necessary. Any thoughts on this? From the perspective of implementing IronPython, I'd prefer that the answer is 1 or 2 -- but mainly I just want to be as compatible with the spec as possible, while respecting CLR-specific norms for functionality which is left up to individual implementations. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] Epoch and Platform
From what I remember, the Microsoft CLIB has been consistent with the Unix epoch since the bad old days of 16-bit. I believe that the Macintosh CLIB used to be based on January 1, 1904 -- but it's been a long time since I did any Mac development and I'm sure it would have changed with OS X. On Mon, Jun 16, 2008 at 4:38 PM, Guido van Rossum [EMAIL PROTECTED] wrote: ISTR that we force the epoch to be 1970 on all major platforms -- or perhaps it happens to be 1970 even on Windows when using MS's C runtime. On Mon, Jun 16, 2008 at 4:08 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote: The documentation for the time module says that the epoch is the point where the time starts. On January 1st of that year, at 0 hours, the ``time since the epoch'' is zero. For Unix, the epoch is 1970. To find out what the epoch is, look at gmtime(0). This confirms that the epoch is platform-specific. As such, the only legal uses of the timestamp should be 1) comparing with another timestamp to determine elapsed time in seconds 2) passing to another standard Python library function which expects a timestamp 3) as a source of randomness. However, the following files in the standard library have hardcoded the assumption that the Python epoch will always be the same as the Unix epoch: In gzip.py, method GzipFile._write_gzip_header In tarfile.py, method _Stream._init_write_gz In uuid.py, function uuid1 Additionally, the following files in the standard library have hardcoded the assumption that the Python epoch will cause timestamps to fall within the range of a 32-bit unsigned integer value: In imputil.py, function _compile In py_compile.py, function compile So there's some kind of a potential discrepancy here, albeit a minor one. This discrepancy can be resolved in one of at least three ways: 1) The documentation for the time module is wrong, and the epoch for Python (at least versions 2.x) should be the Unix epoch. 2) These library functions are slightly wrong and should be modified by subtracing an epoch offset before doing other calculations. This offset can be calculated as time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - time.timezone. 3) These library files should be considered part of the platform-specific implementation, and an alternate platform should provide its own version of these files if necessary. Any thoughts on this? From the perspective of implementing IronPython, I'd prefer that the answer is 1 or 2 -- but mainly I just want to be as compatible with the spec as possible, while respecting CLR-specific norms for functionality which is left up to individual implementations. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Assignment to None
On Thu, Jun 12, 2008 at 8:06 PM, Frank Wierzbicki [EMAIL PROTECTED] wrote:
On Wed, Jun 11, 2008 at 5:27 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote:
If I recall correctly, Jython handles this by appending a trailing
underscore to the imported name and there's no reason why we couldn't
do something similar.
In truth the current implementation of Jython allows keywords in many
strange places, I expect this was done to allow for method names that
are not keywords in Java so, for example, if there is a method called
print in a Java class that we want to call (quite common) then it
can be called. As far as I know appended underscores don't enter into
it.
After posting that message, I did what I should have done initially
which was to ask Jim Hugunin about it. He said that Jython had gotten
Guido's blessing to parse keywords in a context-sensitive fashion --
so that foo.{keyword} might be considered legal under certain
circumstances. I don't, alas, have any specific cites to that end,
but I suspect that we'll be following that precedent :).
--
Curt Hagenlocher
[EMAIL PROTECTED]
___
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] Assignment to None
On Sun, Jun 8, 2008 at 10:19 PM, Martin v. Löwis [EMAIL PROTECTED] wrote: So, it's okay to setattr the attribute name None but not okay to set it directly? Is this deliberate or is it an unintentional side effect of parser changes to prevent assignment to None? It's deliberate. setattr(o, foo bar, baz) also works, even though foo bar is not an identifier. setattr doesn't take the Python grammar into account, but only the object's structure. Thanks for this example; I found it useful. As Michael says, my primary interest in asking this question is because I'm working on IronPython. Compatibility with CPython is extremely important for us, so I need to understand exactly what behavior is mandated. Here's a recap of the ground this thread has covered: 1. In all versions, direct access to members whose names are reserved keywords (such as print) is not allowed. 2. In Python 2.5 and 2.6, True, False and None are not keywords, but direct assignment to a member named None is specifically prevented by the parser. Members named None may, however, be read directly if they are present. There is no special handling for True or False. 3. In Python 3.0, True, False and None are keywords. This eventually leads to a problem for us in interoperability with other CLR code. One example, as Michael points out, is that None is a relatively common member of enumeration types. Now for IronPython 2.0, we're targeting compatibility with CPython 2.5. If we duplicate 2.5's behavior and allow direct reads but not direct writes for a member named None, we'd be okay for the enumeration example. Enumerated values aren't writable anyway. However, this sets us up for a problem with some hypothetical future version of IronPython that targets 3.0 compabililty. At that point, we'll face the unpleasant task of having to choose between compability and interoperability. We haven't really had to do this before now because the convention in CLR-based code is typically that publicly-exposed symbols start with a capital letter -- and all of the existing reserved words in Python are lower-case. It's likely to be a much bigger issue with Jython, given the Java convention of having lower-cased method names. If I recall correctly, Jython handles this by appending a trailing underscore to the imported name and there's no reason why we couldn't do something similar. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] Assignment to None
My apologies if this is one of those dead horse issues. The following seems a little inconsistent to me: c = C() c.None Traceback (most recent call last): File stdin, line 1, in module AttributeError: C instance has no attribute 'None' c.None = 'foo' File stdin, line 1 SyntaxError: assignment to None setattr(c, 'None', 'foo') c.None 'foo' So, it's okay to setattr the attribute name None but not okay to set it directly? Is this deliberate or is it an unintentional side effect of parser changes to prevent assignment to None? -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] string representation of range in 3.0
On Wed, Apr 16, 2008 at 6:58 AM, Steve Holden [EMAIL PROTECTED] wrote: If you consume values from the iterator to display them in the repr() where do you then propose to store them until the application wants them, and how do you distinguish between real and repr consumption of the values? The next couple of elements is a dangerous thing to use unless you don't mind them disappearing. Not only that, but you'd have no idea what the performance consequences of accessing the next object might be. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] very bad network performance
On Mon, Apr 14, 2008 at 9:12 AM, Ralf Schmitt [EMAIL PROTECTED] wrote: I've tracked it down to this change: http://hgpy.de/py/release25-maint/rev/e9446c6ab3cd this is svn revision 61009. [...] self._rbufsize if 1, and so the code reads one byte at a time The change is correct, but exposes a flaw earlier in the same method. _rbufsize == 1 represents a request to buffer by line, which is clearly irrelevant in this context. A request to read n bytes should just use the default buffer size if buffering by line. Sample patch is attached. -- Curt Hagenlocher [EMAIL PROTECTED] *** --- *** *** 277,294 def read(self, size=-1): data = self._rbuf if size 0: # Read until EOF buffers = [] if data: buffers.append(data) self._rbuf = - if self._rbufsize = 1: - recv_size = self.default_bufsize - else: - recv_size = self._rbufsize while True: ! data = self._sock.recv(recv_size) if not data: break buffers.append(data) --- 277,294 def read(self, size=-1): data = self._rbuf + if self._rbufsize = 1: + rbufsize = self.default_bufsize + else: + rbufsize = self._rbufsize if size 0: # Read until EOF buffers = [] if data: buffers.append(data) self._rbuf = while True: ! data = self._sock.recv(rbufsize) if not data: break buffers.append(data) *** *** 305,311 self._rbuf = while True: left = size - buf_len ! recv_size = max(self._rbufsize, left) data = self._sock.recv(recv_size) if not data: break --- 305,311 self._rbuf = while True: left = size - buf_len ! recv_size = max(rbufsize, left) data = self._sock.recv(recv_size) if not data: break ___ 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] very bad network performance
On Mon, Apr 14, 2008 at 12:17 PM, A.M. Kuchling [EMAIL PROTECTED] wrote: On Mon, Apr 14, 2008 at 11:10:12AM -0700, Curt Hagenlocher wrote: while True: left = size - buf_len ! recv_size = max(self._rbufsize, left) data = self._sock.recv(recv_size) What version is this patch against? (The last 2.5 release, maybe?) Yes, sorry. I thought I had checked this against the repository -- particularly because the max-min change is what kicked off this thread. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] very bad network performance
On Mon, Apr 14, 2008 at 2:29 PM, Ralf Schmitt [EMAIL PROTECTED] wrote: Sorry to reply on the mailing list. But this change is wrong. e.g. if you're using a buffer size of 16 bytes and try to read 256 bytes, it should call recv with a value of 256 and not call recv 16 times with a value of 16. However, there should be an upper limit (as shown by the imap bug). There is an upper limit. It's called the buffer size. If someone specifies a buffer size of 16 bytes, it means read 16 bytes at a time. I don't know why someone would want such a small buffer size, but presumably they have their reasons. The only reason min is a problem is that there's standard library code passing a zero to socket.makefile, which gets turned into a bufsize of 1 by the constructor. I actually agree with Bill Janssen -- __init__ is where the real problem lies. But I think the change to read() is safer. -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] very bad network performance
On Mon, Apr 14, 2008 at 4:19 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
But why was imaplib apparently specifying 10MB? Did it know there was
that much data? Or did it just not want to bother looping over all the
data in smaller buffer increments (e.g. 64K, which is probably the max
of what most TCP stacks will give you)?
I'm going to guess that the code in question is
size = int(self.mo.group('size'))
if __debug__:
if self.debug = 4:
self._mesg('read literal size %s' % size)
data = self.read(size)
It's reading however many bytes are reported by the server as the size.
If I'm right with my hunch that the TCP stack will probably clamp at
64K, perhaps we should use min(system limit, max(requested size,
buffer size))?
I have indeed missed the point of the read buffer size. This would work.
--
Curt Hagenlocher
[EMAIL PROTECTED]
___
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
