Re: [Python-Dev] PEP: __source__ proposal
Stelios Xanthakis wrote: Now that 2.4 is out and everything maybe it's about time to start discussing the use the __source__ Luke feature which IMO will really boost python into a new domain of exciting possibilities. I'm opposed to this idea. It creates overhead in the size of .pyc files, for no additional value that couldn't be obtained otherwise. As the rationale, the PEP lists: 1. It is generally a tempting idea to use python as an interface to a program. I cannot see how this rationale is related to the PEP. You can use Python as interface to a program with or without __source__. 2. The developers can implement all the functionality and instead of designing a user interface, provide a python interpreter to their users. This does not require __source, either. 3. A much more powerful approach would be an interface which is dynamically constructed by the user to meet the user's needs. Dynamic code generation doesn't require __source__, either. 4. The most common development cycle of python programs is: write .py file - execute .py file - exit - enhance .py file - execute .py file - etc. With the implementation of the __source__ attribute though the development/modification of python code can happen at run-time. This works just fine as well at the moment; see IDLE for an example. Functions and classes can be defined, modified or enhanced while the python shell is running and all the changes can be saved by saving the __source__ attribute of globals before termination. Currently, you can define classes dynamically, and you can also save the source code of the class to a file in case you need it later. Moreover, in such a system it is possible to modify the code modification routines and eventually we have a self-modifying interface. Using a program also means improving its usability. Self-modifying source code is currently also possible. Just read the old source code from a .py file, modify it, and recompile it. The current solution of using 'inspect' to get the source code of functions is not adequate because it doesn't work for code defined with exec and it doesn't have the source of functions/classes defined in the interactive mode. I fail to see why it isn't adequate. Anybody who wants to modify source code that was originally passed to exec just needs to preserve a copy of the source code, separately. Generally, a file is something too abstract. What is more real is the data received by the python parser and that is what is stored in __source__. Not at all. A file is precisely the level of granularity that is burnt into the Python language. A module is *always* a file, executed from top to bottom. It is not possible to recreate the source code of a module if you have only the source code of all functions, and all classes. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] 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: __source__ proposal
Stelios Xanthakis wrote: The key point is that I think think should be the job of the parser and the functionality provided at the interactive prompt w/o the user having to write 'dyndef' or store the code of exec's or request from himself to use specific commands to create functions. It should be transparent built into python. For the case of the interactive prompt, if preserving the source code is somehow desirable (which I doubt), it should be the job of the development environment to offer saving interactively-defined methods. Such IDE support is necessary even if __source__ was available, since users probably would not want to write open(demo.py).write(myfunc.__source__ + \n + myclass.__source) OTOH, programming python is easy and fun and I think the proposed feature will make it even more fun and it aims in increasing the number of people who program python for their every day tasks. It'd be interesting to hear if the developers of IDLE/ipython/etc could use this. I think it is the other way 'round. If this is *only* for interactive mode, than you should *first* change the interactive environments. If you then find you absolutely need this feature to implement the IDEs correctly, I'd like to hear the (new) rationale for the change. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecated xmllib module
Raymond Hettinger wrote: * Deprecated modules just get moved to the lib-old directory. If someone has ancient code relying on the module, it is a somewhat trivial maintenance step to add lib-old to their PYTHONPATH. IOW, I fail to see the harm. I have never considered this as an official policy. For example, when deprecated C modules are removed, they are never moved to lib-old. * For this particular module, xmllib, about six years will have elapsed between its original deprecation in Py2.0 and us taking it out in a Py2.5 release. Correct. For regex, much more time has passed (it is deprecated since 1.5 or something). * The number one current python complaint is the state of the standard library: http://www.internetnews.com/dev-news/article.php/3441931 . Some of this may just be the fruits of AMK's highly publicized journal entry; however, I think the concerns about library quality will persist. I agree. Removing old modules might change this, indeed: the complaint about unstability and incompatibility might then become the number one complaint :-) * The average quality of the library improves as we take out junk (the tzparse module for example) and put in high quality modules like logging, csv, decimal, etc. I am not convinced that all these more recent modules are really higher quality than the modules that have been added ten years ago. Some are (especially those which has seen extensive testing before being integrated), some are not (especially those added in an ad-hoc manner). Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any reason why CPPFLAGS not used in compiling?
Brett C. wrote: I realize that much. But if you look in configure.in it seems to use the previous value of LDFLAGS every time it is redefined as a base and thus gets its initial value from the environment variable the first time it is tweaked. Yes, it would be possible to do the same thing for CPPFLAGS. However, you really need to combine the values. If you assume you don't know anything about the current value of CPPFLAGS, this might get tricky - you might cause build failures if you honor CPPFLAGS too much. Not a big deal, though. I will just use the environment variables in setup.py . You shouldn't do this - you do need to consider the values in the Makefile as well. If you think you need both, you should modify configure.in appropriately. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing aclocal.m4
Neal Norwitz wrote: Can we remove aclocal.m4? The last log message states: fix for bug #811160 - autoconf vs. hp/ux system header files. also applied to release23-maint. Note that aclocal.m4 can go away when autoconf 2.58 is out. It appears to me that 2.59 indeed fixes the HP-UX problem; a diff with and without aclocal.m4 shows chunks like cat confdefs.h conftest.$ac_ext cat conftest.$ac_ext _ACEOF /* end confdefs.h. */ +/* Define $ac_func to an innocuous variant, in case limits.h declares $ac_func. + For example, HP-UX 11i limits.h declares gettimeofday. */ +#define $ac_func innocuous_$ac_func + /* System header to define __stub macros and hopefully few prototypes, which can conflict with char $ac_func (); below. Prefer limits.h to assert.h if __STDC__ is defined, since -limits.h exists even on freestanding compilers. Under hpux, -including limits.h includes sys/time.h and causes problems -checking for functions defined therein. */ -#if defined (__STDC__) !defined (_HPUX_SOURCE) +limits.h exists even on freestanding compilers. */ + +#ifdef __STDC__ # include limits.h #else # include assert.h #endif + +#undef $ac_func + So they manage to get limits.h define, say, innoucuous_clock(), instead of clock(), whereas we currently avoid including limits.h on HP-UX. IOW, it seems like it should work, but somebody should test it on HP-UX to be sure. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supporting Third Party Modules (was The other Py2.4 issue)
Bob Ippolito wrote: I believe this is not implementable: How can the DLL know which Python DLL to use? Well for py2app on Mac OS X, I wrote an executable stub that chooses a Python runtime from an XML file, looks up and binds a few symbols from it dynamically, and then starts doing stuff. While that would work, I think this is inappropriate for this specific issue: we want to write extension modules which are independent of the Python version, and might even be used with multiple Python installations on the same system. In that case, adding configuration files won't work, as each usage of the extension might require a different Python DLL. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Supporting Third Party Modules (was The other Py2.4 issue)
Bob Ippolito wrote: I was talking about PYTHON_API_VERSION, hence forced in quotes. Nobody likes to see an ugly error message. Ah, that... If PYTHON_API_VERSION changes, it is because there is a real incompatibility, somewhere. It is not automatically bumped with each release. So it is safe to ignore the ugly error message only if you have not used any of the API that became incompatible. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MinGW And The other Py2.4 issue
Thomas Heller wrote: And recently I played with bindings to OpenGL's glut32.dll - glut calls exit() from internal C code. If linked with the wrong CRT, this will do nothing instead of terminating the process. Interesting. Looking at the code of exit(), it is clear that the wrong atexit handlers will be called if you use the wrong CRT (i.e. only one set of atexit handlers will be called, whereas you might have multiple lists of atexit handlers); see atonexit.c. It is not so clear why you could possibly get out of exit() without actually exiting. The only possible code path I see in the msvcr71.dll is when mscoree.dll is in the address space, in which case the CRT will invoke CorExitProcess (!). In all other cases, it will invoke ExitProcess, which, to my understanding, will terminate the process unconditionally. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The other Py2.4 issue
Armin Rigo wrote: In other words, if you want 3rd parties to compile Windows binaries for 2.4, tell them how. The straight-forward answer is: Get VC7.1 (aka VS.NET 2003), and invoke python setup.py bdist_wininst That's not too hard to do, I think. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The other Py2.4 issue
Carlos Ribeiro wrote: If none of your users volunteers to do the build for you, I would stop worrying about the Windows users. Sorry, Martin. I understand your point, but I think you are not being realistic. I for myself took the decision to use only free tools for my own development, but I still have to suport my Windows customers. I can't force them to change to Linux. I don't own a copy of MSVC. Also, one of the reasons to choose a third part module is to save time. The moment I am required to recompile everything myself I'm losing this convenience. This of course impacts my ability to focus on my own work, and so the story goes. I did not suggest that *all* your Windows users should recompile your module - just a single one would be sufficient. I'm not saying that module authors should work for free just to save me some time hassle. It's fair if an author decides to release a Linux-only module. But again -- this is not realistic. The world has a lot of Windows users, and I depend on them for my own income. If I can't find a good set of Python tools for my projects, what should I do? Picking another language is not a choice, mind you :-) As I said: Find a volunteer that has the necessary build infrastructure, and have that volunteer build the extension for you. The dream scenario is not to require recompiling, at least inside the same major release (2.4 to 2.5, for example). That would be really great. That is guaranteed. Extensions built for 2.4 will certainly continue to work in 2.4.1, and later 2.4.x. They will stop working with 2.5 (as they are linked with python24.dll). Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MinGW And The other Py2.4 issue
Paul Moore wrote: For a starter, what steps do you actually take to build a release? I assume that the first step is to build Python, by clicking on build in VS.NET. Yes. You can skip this step by just putting all the .pyds, dlls, and .exes into the PCbuild directory. The packaging will try to pick them up from there (and proceed if some are missing, like Tcl likely will). Once you have that, is there a single script you run? Yes. Invoke Tools\msi\msi.py, using a Python that has pythonwin (i.e. COM interopability). The only tricky part is that you need cabarc.exe, which is included in VC, and in the platform SDK. If there's a document describing the release process somewhere, feel free to point me at it. Tools/msi/README.txt Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MinGW And The other Py2.4 issue
Paul Moore wrote: OK, I've got a copy of the Python sources, and had a look. The change needed to msi.py to include libpythonXX.a in the installer looks simple. But I'm less sure as to where to build the file. It seems to me that msi.py is not the right place - that's focused on building the installer, not building the files to be installed. Don't worry about this: there is already quite some building going on in msi.py. If you look at the CVS copy of Tools/msi, you find that it now has a nmake makefile to build msisupport.dll, which replaces the VB scripts. It also extracts msvcr71.dll from the merge module (.msm) each time it is invoked. So having yet another build process would be just fine; adding it to the makefile would have the added advantage that nmake will compare time stamps for us (if it is easier to do in Python than in nmake, that would be a reason not to use nmake, though). On the other hand, including it in the build process is a nuisance, as well, as it would add a dependency on mingw (or cygwin) to the MSVC build process. That is definitely undesirable. Lots of people build Python using the project files, and only few need the packaging to work. My feeling is that building libpythonXX.a should be a separate step, handled by a dedicated script, which gets run before msi.py. Making it separate is fine, as long as msi.py invokes/calls it. What do others (particularly Martin) think? Should I keep the steps separate, and focused on one task each, or should I incorporate the build of libpythonXX.a into msi.py, so that the installer build still requires just one step? Having the entire process involve as few manual steps as possible is definitely an important goal. Keeping it modular (in terms of splitting it into several files) is also a good idea, and one which does not conflict at all with the fully automatic goal. msi.py supports a config.py which allows to add customization. Putting cygwin_dir = rC:\cygwin into msi.py might be appropriate, with an option to set cygwin_dir to None, to indicate that cygwin should not be used in the build process. (similar to the way have_tcl already works). Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mmap feature or bug?
Josiah Carlson wrote: Is mmap's inability to be subclassed a feature or bug? No. It's a missing feature: it's not a bug, because nobody says this should work, and anybody trying will find out that it doesn't work, so nobody is tricked into believing it should work. The mmap type is not even documented; mmap.mmap is a function. It's not a feature, because (atleast IMO) there would be nothing wrong with making mmap.mmap a subclassable type. Is one's inability to use a = mmapinstance.__setslice__;a(1,2,'a') (and others) a feature or bug? That is a bug. Slice assignments are supported, and so should __setslice__. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] 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 in education
Randy Chung wrote: I'm going to be leading a class on Python at the University of California, Berkeley next semester (starting in January). I'm interested in using actual bugs in Python as exercises for the class, the goal being 1) to give the students something real to work with, and 2) to (hopefully) contribute back anything we manage to put together to the Python dev team. Welcome to the club! I'm just running a class on development processes in open source software (i.e. with a somewhat different scope), where students already have fixed bugs in Mozilla and PHP - unfortunately, none of them were interested in Python. Nevertheless, this is quite fun for both the students, and myself - especially when the Mozilla guys do a review after 3h, the super review after 36h, and explain that they cannot commit the fix because the code is frozen (and then do after two weeks, well before the presentation in the class). What I'm looking for are some oustanding bugs which the more experienced devs feel would be straightforward to implement I'd look in the one-to-two-year old range of bugs. One risk in such a course is that some of the developers fixes the bug while your student is working on it, which is discouraging. How many bugs do you need? The *really* easy ones are documentation bugs, but I expect that students don't see this as a sufficient challenge. There are currently roughly 100 documentation bugs open. You can further filter out all assigned bugs; the unassigned ones are likely resting because nobody cares (yet). Looking at unassigned bugs starting from offset 300, I think all of the following bugs might be suitable: - 840065 - 839151 - 837242 (really trivial) - 828743 - 813986 If you feel this is off topic, please feel free to reply to me off-list. This is clearly python-dev relevant. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MS VC compiler versions
M.-A. Lemburg wrote: Here's an update of the list I currently have: I have * SDK Itanium compiler Microsoft (R) C/C++ Optimizing Compiler Version 13.10.2240.8 for IA-64 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MS VC compiler versions
M.-A. Lemburg wrote: Thanks, Martin. Could you also give me the official version number of the compiler or SDK ? It is Windows Server 2003 Platform SDK, February 2003. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patches: 1 for the price of 10.
Jeremy Hylton wrote: I got started on these this morning, will likely finish them tomorrow. It would be perverse to apply your patch last, wouldn't it? It turns out that Titus' patch might be more involved than he thought it would be. In any case, the review itself is a highly appreciated contribution. In the hope that this progress can trigger more contributions like this, I'll happily reduce the requirements to 5 reviews. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Build extensions for windows python 2.4 what are the compiler rules?
Barry Scott wrote: It seems that I can build extensions with msvc 6.0 that work with the python 2.4 windows binary kit. Is this safe? No, it isn't. This emerges as a Python 2.4 FAQ. I recall warning a while ago about mixing msvc 6.0 and msvc 7.1 runtime DLL's. Is this an issue with python 2.4? Yes, it is. I'm also surprised that the python 2.4 source kit only mentions MSVC 6.0 and not the compiler that you actually built python 2.4 with. Why do you say that? PCbuild/readme.txt starts with Building Python using VC++ 7.1 - This directory is used to build Python for Win32 platforms, e.g. Windows 95, 98 and NT. It requires Microsoft Visual C++ 7.1 (a.k.a. Visual Studio .NET 2003). (For other Windows platforms and compilers, see ../PC/readme.txt.) Regards, Martin ___ 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] Build extensions for windows python 2.4 what are the compiler rules?
Barry Scott wrote: I recursive grep'ed and missed this ref. However I did read this in README.TXT: Building on non-UNIX systems For Windows (2000/NT/ME/98/95), assuming you have MS VC++ 6.0, the project files are in PCbuild, the workspace is pcbuild.dsw. See PCbuild\readme.txt for detailed instructions. Which says that PCbuild/readme.txt is about VC++ 6.0 I see. This is now corrected in CVS. Regards, Martin ___ 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] Re: Zipfile needs?
Scott David Daniels wrote: I believe there is an issue actually building in the encryption/decryption in terms of redistribution. Submitters should not worry about this too much. The issue primarily exists in the U.S., and there are now (U.S.) official procedures to deal with them, and the PSF can and does follow these procedures. Regards, Martin ___ 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] csv module TODO list
Andrew McNamara wrote: There's a bunch of jobs we (CSV module maintainers) have been putting off - attached is a list (in no particular order): * unicode support (this will probably uglify the code considerably). Can you please elaborate on that? What needs to be done, and how is that going to be done? It might be possible to avoid considerable uglification. Regards, Martin ___ 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] csv module TODO list
Andrew McNamara wrote: Marc-Andre Lemburg mentioned that he has encountered UTF-16 encoded csv files, so a reasonable starting point would be the ability to read and parse, as well as the ability to generate, one of these. I see. That would be reasonable, indeed. Notice that this is not so much a Unicode issue, but more an encoding issue. If you solve the arbitrary encodings problem, you solve UTF-16 as a side effect. The reader interface currently returns a row at a time, consuming as many lines from the supplied iterable (with the most common iterable being a file). This suggests to me that we will need an optional encoding argument to the reader constructor, and that the reader will need to decode the source lines. Ok. In this context, I see two possible implementation strategies: 1. Implement the csv module two times: once for bytes, and once for Unicode characters. It is likely that the source code would be the same for each case; you just need to make sure the Dialect and Formatting Parameters change their width accordingly. If you use the SRE approach, you would do #define CSV_ITEM_T char #define CSV_NAME_PREFIX byte_ #include csvimpl.c #define CSV_ITEM_T Py_Unicode #define CSV_NAME_PREFIX unicode_ #include csvimpl.c 2. Use just the existing _csv module, and represent non-byte encodings as UTF-8. This will work as long as the delimiters and other markup characters have always a single byte in UTF-8, which is the case for ':\, as well as for \r and \n. Then, wenn processing using an explicit encoding, first convert the input into Unicode objects. Then encode the Unicode objects into UTF-8, and pass it to _csv. For the results you get back, convert each element back from UTF-8 to a Unicode object. This could be implemented as def reader(f, encoding=None): if encoding is None: return _csv.reader(f) enc, dec, reader, writer = codecs.lookup(encoding) utf8_enc, utf8_dec, utf8_r, utf8_w = codecs.lookup(UTF-8) # Make a recoder which can only read utf8_stream = codecs.StreamRecoder(f, utf8_enc, None, Reader, None) csv_reader = _csv.reader(utf8_stream) # For performance reasons, map_result could be implemented in C def map_result(t): result = [None]*len(t) for i, val in enumerate(t): result[i] = utf8_dec(val) return tuple(result) return itertools.imap(map_result, csv_reader) # This code is untested This approach has the disadvantage of performing three recodings: from input charset to Unicode, from Unicode to UTF-8, from UTF-8 to Unicode. One could: - skip the initial recoding if the encoding is already known to be _csv-safe (i.e. if it is a pure ASCII superset). This would be valid for ASCII, iso-8859-n, UTF-8, ... - offer the user to keep the results in the input encoding, instead of always returning Unicode objects. Apart from this disadvantage, I think this gives people what they want: they can specify the encoding of the input, and they get the results not only csv-separated, but also unicode-decode. This approach is the same that is used for Python source code encodings: the source is first recoded into UTF-8, then parsed, then recoded back. That said, I'm hardly a unicode expert, so I may be overlooking something (could a utf-16 encoded character span a line break, for example). This cannot happen: \r, in UTF-16, is also 2 bytes (0D 00, if UTF-16LE). There are issues that Unicode has additional line break characters, which is probably irrelevant. Regards, Martin ___ 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] 2.3.5 schedule, and something I'd like to get in
Ronald Oussoren wrote: Wouldn't it be better to link with the actual dylib inside the framework on 10.2? Otherwise you can no longer build 2.3 extensions after you've installed 2.4. That's what I thought, too. Regards, Martin ___ 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] Changing the default value of stat_float_times
When support for floating-point stat times was added in 2.3, it was the plan that this should eventually become the default. Does anybody object if I change the default now, for Python 2.5? Applications which then break can globally change it back, with os.stat_float_times(False) Regards, Martin ___ 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] Exceptions *must*? be old-style classes?
Alex Martelli wrote: What would happen if Exception were made a new-style class, enforce inheritance from Exception for all new-style exceptions, and allow all old-style exceptions as before. string exceptions would break. Couldn't we just specialcase strings specifically, to keep grandfathering them in? Sure. That just wouldn't be the change that Simon described, anymore. You don't specify in which way you would like to specialcase strings. Two alternatives are possible: 1. Throwing strings is still allowed, and to catch them, you need the identical string (i.e. the current behaviour) 2. Throwing strings is allowed, and they can be caught by either the identical string, or by catching str In the context of Simon's proposal, the first alternative would be more meaningful, I guess. The and so on would presumably refer to whether special methods should be looked up on the instance or the type. Perhaps. That type(exc) changes might also cause problems. It seems to me that if the new-style Exception is made very normally and strings are grandfathered in, we ARE down to exoteric breakage cases (potentially fixable by those new magic descriptors as above for specialmethods). This would be worth a try. Does anybody have a patch to implement it? Regards, Martin ___ 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] Exceptions *must*? be old-style classes?
Guido van Rossum wrote: a) Is Exception to be new-style? Probably not in 2.5; Martin and others have suggested that this could introduce instability for users' existing exception classes. Really? I thought that was eventually decided to be a very small amount of code. I still think that only an experiment could decide: somebody should come up with a patch that does that, and we will see what breaks. I still have the *feeling* that this has significant impact, but I could not pin-point this to any specific problem I anticipate. Regards, Martin ___ 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] builtin_id() returns negative numbers
Donovan Baarda wrote: Seriously, on the Python lists there has been a discussion rejecting an md5sum implementation because the author donated it to the public domain. Apparently lawyers have decided that you can't give code away. Intellectual charity is illegal :-) Despite the smiley: It is not illegal - it just does not have any legal effect. Just by saying I am the chancellor of Germany, it does not make you the chancellor of Germany; instead, you need to go through the election processes. Likewise, saying the public can have my code does not make it so. Instead, you have to formulate a license that permits the public to do with the code what you think it should be allowed to do. Most people who've used the term public domain in the past didn't really care whether they still have the copyright - what they wanted to say is that anybody can use their work for any purpose. Regards, Martin ___ 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] Re: Some old patches
Reinhold Birkenfeld wrote: No one listening? I'm sorry when patch reviews are not welcome in python-devel; in this case I'll post individual comments to the patches on SF. I have seen them, and I appreciate them, but I had no time to respond, yet (likewise for the 20+ other reviews which I still need to look at). Regards, Martin ___ 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 bunch of Patch reviews
Irmen de Jong wrote:
I've looked at one bug and a bunch of patches and
added a comment to them:
Thanks! I have now processed the ones for which I found guidance.
As for the remaining ones:
[ 756021 ] Allow socket.inet_aton('255.255.255.255') on Windows
Looks good but added suggestion about when to test for special case
So what to do about this? Wait whether he revises the patch?
Accept anyway? Update the patch myself?
[ 1103350 ] send/recv SEGMENT_SIZE should be used more in socketmodule
So what do you propose to do? AFAICT, there is no definition of
SEGMENT_SIZE in a TCP implementation, and I think we should not try
to make up a value.
IMO, Python should expose sockets more or less as-is. If the system
has a flaw, Python should expose it instead of working around it.
[ 1062014 ] fix for 764437 AF_UNIX socket special linux socket names
Can you please elaborate the problem? What is a special linux socket
name?
Regardless, the comment of the other reviewer is also valid: any patch
needs documentation and test cases.
Regards,
Martin
___
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 309
Raymond Hettinger wrote: Are you sure about that? Contriving examples is easy, but download a few modules, scan them for use cases, and you may find, as I did, that partial() rarely applies. The argument order tends to be problematic. So would you like to see the decision to accept PEP 309 reverted? Regards, Martin ___ 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 309
Raymond Hettinger wrote: I would like for the principal advocates to reach a consensus that the proposed implementation is a winner. That I cannot understand. Do you want the advocates to verify that the implementation conforms to the specification? or that the implementation of the PEP is faster than any other existing implementation of the PEP? These two hold, I believe. Ideally, that decision should be informed by trying it out on their own, real code and seeing whether it offers genuine improvements. Performance-wise, or usability-wise? Because usability-wise, all implementations of the PEP are identical, so all implementations of the PEP should offer the precisely same improvements. Along the way, they should assess whether it is as applicable as expected, whether the existing limitations are problematic, and whether performance is an issue. Ah, so you question the specification, not the implementation of it. My concern is that with Guido having approved the idea in abstract form, the actual implementation has escaped scrutiny. Also, if the API is different from the PEP, acceptance should not be automatic. AFAICT, the proposed patch implements the behaviour of the PEP exactly. If functional.partial() isn't a clear winner, it may be a reasonable to ask that it be released in the wild and evolve before being solidified in the standard library. My sense is that that the current implementation is far from its highest state of evolution. Again, this I cannot understand. I do believe that there is no better way to implement the PEP. The PEP very explicitly defines what precisely functional.partial is, and the implementation follows that specification very closely. Regards, Martin ___ 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] Quick access to Python bug reports in Thunderbird
I find that I frequently need to open a bug report whose bug number is in a python-dev email I read with Mozilla Thunderbird. I now tried to automate things a bit more, and found the excellent DictionarySearch plugin: http://dictionarysearch.mozdev.org/index.html To install, follow these steps: 1. Download the plugin (for Thunderbird, make sure to download to disk) http://dictionarysearch.mozdev.org/download.php/http://downloads.mozdev.org/dictionarysearch/dictionarysearch_0.8.xpi 2. In Thunderbird, open Tools/Extensions/Install, select the file downloaded 3. Open Tools/Extensions again, double-click DictionarySearch. 4. In Dictionary 1, fill in Text: Python Bug $ Access Key: y (as P will conflict with Print) URL: http://www.python.org/sf/$ To use the plugin, select a bug report number in a message, select the context menu, and type y (or click the Python Bug menu entry). Regards, Martin P.S. In case you wonder why this plugin is DictionarySearch: it is meant to lookup words in an email in a dictionary, e.g. Wikipedia. ___ 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 309
Paul Moore wrote: While I'm not saying that it's too late to attempt to persuade Guido to reverse himself, it does seem to me to be a lot of fuss over a fairly small function - and no-one said anything like this at the time. I would probably fuss much less if it would not simultaneously introduce a new module as well. When I put up 5 reviews to get Martin to look at this, I honestly believed that it was a simple case of an accepted PEP with a complete implementation (admittedly scattered over a couple of SF patches), and would simply be a matter of committing it. That was a fair assumption. However, it turned out that a) people still have doubts about the proposed functionality of the PEP. For some, it does too much, for others, too little. Changing the PEP now would be much cheaper than first committing the changes, and then redoing the PEP again, as we might need to deprecate the functional.partial first. So as part of the review, I need to confirm that there still is no opposition to the PEP (which now appears to be the case) b) it is not obvious that the patch is complete. It probably is, but I would have committed a single patch much quicker than collecting bits and pieces from multiple patches, only to find out that they won't integrate properly. c) it appears that the implementation of the PEP is incorrect (as Raymond just discovered). Again, it is better to require a perfect implementation before committing the changes, instead of pushing the contributor afterwards to add the missing changes. IMHO, the burden is on those who want the Accepted status revoking to persuade Guido to pronounce to that effect. Most certainly. So far, nobody stepped forward and requested that this status is revoked, so no persuading is necessary. However, as part of the review process, it *is* necessary to check again whether somebody would have preferred that the PEP is revoked - atleast when the acceptance of the PEP is many months old. Otherwise, based on the standard PEP workflow process, it's time to move on, and ensure that the patches provide a complete implementation, and assuming they do to commit them. Correct. I would have done so more readily if I knew how the Accepted status got into the document. I could have researched that (going through old email archives), or I could just ask whether people agree that the status is indeed Accepted. (But I don't want to put myself up as a big champion of PEP 309 - I like it, and I'd like to get the accepted and there's a patch, but not yet implemented status resolved, but that's all. I'm not going to switch to Perl if the patch isn't accepted :-)) It seems to me that the patch will be committed shortly, assuming somebody corrects the remaining flaws in the implementation. I could do that, but I would prefer if somebody contributed an updated patch. Regards, Martin ___ 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 309
Raymond Hettinger wrote:
My reading of the PEP did not include making the structure members
public. This complicates and slows the implementation. The notion of
introducing mutable state to the PFA is at odds with the driving forces
behind functional programming (i.e. statelessness).
Notice that the C code is (or atleast is meant as) a faithful
implementation of the Example Implementation in the PEP, including
the literal spelling of the class attributes. Now, it is not clear
what is meant as normative in the PEP; I would agree that these member
names are not meant to be exposed.
If necessary for introspection, the structure members can be made
read-only.
This issue is not discussed in the PEP. If exposed, I think I would
prefer different names. Starting all names with p_, might be
appropriate, and I would rename fn to func (following method
objects). Not sure what names would be appropriate for arguments
and keywords.
Notice that the proposed documentation says this:
Partial objects are callable objects that are created, and mostly
behave, like the functions created by \function{partial}. The main
difference is that because they are Python objects, they have attributes
that can be inspected or modified.
So it was atleast the intention of the PEP author that partial functions
are mutable.
Also, there may be room to improve the implementation by building on the
passed-in dictionary rather than creating a copy of the one in the
partial object.
Couldn't this cause the modifications be passed to the caller? This
would not be acceptable, but I could not figure out whether
CALL_FUNCTION* will always create a new kwdict, or whether it might
pass through a dict from the original caller.
The current choice may be the correct one because it
has the outer call override the defaults in the event of a keyword
conflict -- if so, that should be documented.
Notice that the Example Implementation specifies this:
if kw and self.kw:
d = self.kw.copy()
d.update(kw)
else:
d = kw or self.kw
In any case - the fine points of the semantics primarily need to go into
the documentation, which currently says
and keyword arguments override those provided when the new function
was created.
Overall, I have no major objections to the PEP or the patch. Before it
goes in on auto-pilot, it would be darned nice if the proponents said
that they've found it helpful in real code and that they are satisfied
with the timings.
I guess darned nice is the best you can hope for. Not sure if Peter
Harris is still around.
Regards,
Martin
___
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] Quick access to Python bug reports in Thunderbird
Alan McIntyre wrote: Thanks, somehow I managed to be oblivious to patches bugs being essentially the same thing on SF. :-) The SF URLs are different (or atleast, they used to be (*), as they also include the tracker ID and the project ID, and SF complains if you guess either wrong. Therefore, I wrote http://www.python.org/sf/ (also accessible through sf?id=) which looks an ID up in all trackers, in sequence, and caches the result in a file. Unfortunately, this a) fails if the item gets moved between trackers b) takes some time on the first access Nevertheless, it works in most cases, and it is easier to remember - especially as the shortest form is python.org/sf/itemid (browsers will add the http://, DNS will add the www., and the script will forward to SF index.php) Regards, Martin (*) Apparently, SF now supports an (apparently undocumented) URL format of http://sourceforge.net/support/tracker.php?aid=itemid I'ld like to try this some day more systematically, to see whether it would help simplifying the current Python script on python.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] Re: PEP 754
Warnes, Gregory R wrote: What else needs to be done to allow fpconst to go into the Python library? See PEP 1. First, the PEP must be Accepted. Regards, Martin ___ 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] Re: python-dev Summary for 2005-01-16 through 2005-01-31
Steve Holden wrote: Now, the reason for this specific rant is this: I can tell a cry for help when I see one. Brett has done a magnificent job of providing python-dev summaries since Andrew decided he'd had enough, and he is to be congratulated for it. I managed to offload another bunch of work on him (moderation of various troublesome PyCon mailing lists), but at least I was able to recompense him by letting him into PyCon for nothing. The more I participate, the more I can relate to Eric Raymond's notion of a gift society. Volunteers give their contributions to the community just because they want to, and they may get recognition in return. But because these are gifts, you can just stop giving them away at any time, and nobody should feel bad about doing so. The community only is only entitled to the contributor saying so - finding somebody else to step in is indeed optional. I don't actually know whether Brett would prefer to hand over the python-dev summaries to somebody else, but if he wants to, he could just *stop* publishing them, with nobody taking over, and my appreciation of this contribution would not change at all. Continuing it until a new volunteer steps forward is, as I said, truly optional. I still recall when Tim Peters reappeared in the net (even though I haven't been around long enough to remember him disappear), and I know I didn't understand all the cheering and praising (I do now, of course). So their isn't anything wrong with taking a vacation from a project for some time, not even if the vacation takes a few years :-) Enough ranting. Regards, Martin ___ 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] Patch Reviewing
Reinhold Birkenfeld wrote: just felt a little bored and tried to review a few (no-brainer) patches. Thanks! They are now all closed. Please understand that there is a chance that a review posted *only* to python-dev might get lost/overlooked by the committers, and then somebody may need to duplicate your work later. So it is better to include the review in the patch, and only post a summary to python-dev. Regards, Martin ___ 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] Outdating import.c 2.241
I just mistakenly checked in import.c; I have outdated this checkin (cvs admin -o 2.241 import.c). If you happened to have checked-out import.c in-between, don't be surprised if the version numbers go backwards. Regards, Martin ___ 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] Memory Allocator Part 2: Did I get it right?
Brett C. wrote: Assuming a code review says the patch is sane, do we want to go with this garbage collection change? From past discussions I don't remember a consensus on acceptance or rejection, just lots of discussion about ripping out the hacks to allow freeing memory w/o holding the GIL (I assume Evan's patch rips that code out). I think the consensus is that the feature is desirable. So if the code is correct, it should be checked in. Regards, Martin ___ 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] Migrating to subversion
I don't know whether anybody has done this before, but I just tried to run cvs2svn on the Python repository. The conversion took 7 hours, and the result is now available at http://www.dcl.hpi.uni-potsdam.de/python/branches/ Because of the load that the conversion produces on the machine, I cannot run the entire conversion every day. Reportedly, cvs2svn is able to run in incremental mode, but I haven't tried this out yet. On close inspection, you might notice a few things: - A few branches/tags are missing, namely r16b1|cnri-16-start|descr-branch|release152p1-patches|after-c all-reorg|r22a1|before-call-reorg|release16|r161|r161-branch|r16a2|release152p2 I had to manually exclude these tags, because cvs2svn complained that they (some of them) are tags on some files, and branches on other files. When I excluded these, it then complained that some other tags depend on the excluded ones, so I had to exclude these as well. I suspect that this can be fixed by modifying the CVS repository before the conversion, typically by converting the version tags to branch tags. cvs2svn did not report what files specifically caused the problems, and I don't know the proper cvs/rcs incantation to fix these. So if anybody has done that before, or knows how to, please let me know. - A few tags are useless, most notably the vendor branches. I think they should be excluded in the conversion. I don't know where the unlabeled branches come from, but they appear to be useless as well. - It has imported the CVSROOT directory as well. I don't know whether this is deliberate/useful. Anyway, this repository is now online for anonymous read-only access. Anybody interested in playing with it is welcome to do so. For those interested in server side issues: the repository is an 1.1.1 fsfs repository. The CVS repository consumes 368MiB; the SVN repository 797MiB. Regards, Martin ___ 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] Migrating to subversion
Barry Warsaw wrote: I personally have had no success doing this, but the last time I tried was with a fairly old version of svn. It gives an error message when you try. You then need to interpret the error message, retry, and it gives you another error message. You do this three times, and end up with the command line cvs2svn -q --fs-type=fsfs --encoding=latin1 --exclude=r16b1|cnri-16-start|descr-branch|release152p1-patches|after-call-reorg|r22a1|before-call-reorg|release16|r161|r161-branch|r16a2|release152p2 -s py.svn.new python BTW, it looks like you just pulled in python/dist right? Did you pull in the trunk? What about nondist, or as Greg mentioned, distutils which is a sibling of the top-level python directory. I posted the wrong URL. The right one is http://www.dcl.hpi.uni-potsdam.de/python/ It has distutils right in http://www.dcl.hpi.uni-potsdam.de/python/trunk/distutils/ Just curious - why did you choose fsfs instead of the BerkeleyDB backend? I had hoped that it would consume less disk space - but I really should try with bdb again. In our operational repositories, I have now migrated everything to fsfs because it is so much more friendly to backups. You can backup the on-disk state, and trust that is consistent. With bdb, you need to use hot-backup.py or some such, and this gives you an entire copy which then goes into all incremental backups. With fsfs, the incremental backups really pickup new commits only. (for the Python svn, it doesn't matter much, since that is excluded from backup, anyway) Thanks for doing this Martin. I've heard that SF may be offering svn as early as May or June and I would love to see us convert when that's available. So do I. However, I now believe that it is unlikely that SF will provide automatic conversion (or the automatic conversion will be useless/fail); instead, we likely need to provide our hand-tuned conversion. I'll keep collecting issues/complaints about this specific conversion, and try to integrate them if I can. Regards, Martin ___ 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] Migrating to subversion
Greg Ward wrote: Presumably for Python's repository, this would work: cvs2svn -s /home/svn/python /home/cvs/python/python ...except, umm, isn't distutils a separate top-level directory in the Python repository or something? Ok. Removing the CVSROOT before the conversion (from CVS) or after the conversion (from svn) would probably work. OTOH, I wonder whether the distutils CVS needs to be converted at all, or whether it would be sufficient to only migrate the python module (in which case your approach would be sufficient). Regards, Martin ___ 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] os.access and Unicode
Apparently, os.access was forgotten when the file system encoding was introduced in Python 2.2, and then it was again forgotten in PEP 277. I've now fixed it in the trunk (posixmodule.c:2.334), and I wonder whether this is a backport candidate. People who try to invoke os.access with a non-ASCII filename on non-NT+ systems will get a UnicodeError; with the patch, the operation will succeed (assuming the characters are all supported in the file system encoding). Should this be backported? Regards, Martin ___ 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] os.access and Unicode
Brett C. wrote: If there was no other way to get os.access-like functionality, I would say it should be backported. But since there are other ways to figure out everything that os.access can tell you I believe this is not really true, atleast not on Windows, and perhaps not in certain NFS cases, either. If there are ACLs on the file, access will consider them (or atleast it should), but no other method will. Regards, Martin ___ 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] LinkedHashSet/LinkedHashMap equivalents
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? -0 for the addition to the collections module, -1 on the specific name. Java made a *big* mistake by putting Hash into the names of these things. From the outside, it is primarily a Dictionary; only when you look closer you see that this specific dictionary requires hashable keys (as opposed to, say, the C++ std::map, which requires sortable keys). So consequently, the data type should be called OrderedDictionary, and its cookbook recipe is http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/107747 Regards, Martin ___ 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] LinkedHashSet/LinkedHashMap equivalents
Thomas Heller wrote: I cannot understand why people are against adding it to stdlib (after the name, the implementation, and the exact place have been decided). It's certainly a useful data type, isn't it? It depends on the precise semantics. You often want a dictionary where the keys come out in some order - but that is rarely the order in which they were added to the dictionary. Most frequently, you want the keys sorted, according to some criteria. If not that, I would assume that you typically have the order of keys determined before even filling the dictionary, in which case you can do for k in keys_in_preferred_order: v = hashtable[k] process(k,v) I remember having needed that once in the past 15 years (in Smalltalk at the time), so I wrote an OrderedDictionary for Smalltalk/V (which didn't have it). It took me an hour or so. I don't recall what precisely it was that I needed it for, and I cannot think of any use case for the data type right now. So I'm -0 on adding the data type: I have a vague feeling it is needed, but rarely, and I don't know precisely what for. Regards, Martin ___ 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] LinkedHashSet/LinkedHashMap equivalents
John Williams wrote:
The other use case I have is for dealing with data where the iteration
order doesn't matter to the program but it does matter to users. For
instance, consider the ConfigParser's write method. Any ordering of
values in the output is functionally equivalent, but the original data
is likely to have come from a file that was arranged in some meaningful
order, and it would be nice to preserve that order, especially if it can
be done with no extra effort.
That is a good example, IMO. But then, in the specific case, the
dictionary for each section is created deeply inside ConfigParser,
with the lines
cursect = {'__name__': sectname}
self._sections[sectname] = cursect
So this uses a builtin dict, and there is no easy way to override it
for the application.
Of course, given your reasoning, ConfigParser *should* use an
OrderedDictionary (probably both for cursect and for self._sections),
in which case this would all be transparent to the application.
Regards,
Martin
___
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.4.1, release candidate 1
Anthony Baxter wrote: On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.1 (release candidate 1). Python 2.4.1 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the bugs squished in this release. I'd like to encourage feedback on whether the Windows installer works for people. It replaces the VBScript part in the MSI package with native code, which ought to drop the dependency on VBScript, but might introduce new incompatibilities. Regards, Martin ___ 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] os.access and Unicode
Skip Montanaro wrote: I say backport. If people were trying to call os.access with unicode filenames it would have been failing and they were either avoiding unicode filenames as a result or working around it some other way. I can't see how making os.access work with unicode filenames is going to break existing code. The question is whether it would encourage conditional work-arounds. If people will put into their code if sys.version_info (2,4,2): import os, sys def new_access(name, mode, old_access = os.access): try: return old_access(name, mode) except UnicodeError: return old_access(name.encode( sys.getfilesystemencoding()), mode) os.access = new_access then backporting does not improve anything. OTOH, if people are likely to say yes, this was a bug in 2.4.0 and 2.4.1, you need atleast 2.4.2, backporting will help. Regards, Martin ___ 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.4.1, release candidate 1
Michael Chermside wrote: I tried several stranger things, like installing over 2.4.0 but in a different directory. Everything worked like clockwork. I did NOT try anything that would have involved a system with various things missing (like lack of VBScript), but I did play around with alternate install locations, repairs, uninstalls, single-user and all-user installs, and I found no problems anywhere. Nice work! Thanks! Somebody reported that it failed to update python24.dll in an update installation; not sure why this would be. Regards, Martin ___ 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] Re: RELEASED Python 2.4.1, release candidate 1
Alexander Schremmer wrote: Somebody reported that it failed to update python24.dll in an update installation; not sure why this would be. Because it was in use? Perhaps. In that case, Installer should schedule a reboot, and ask for the reboot when the installation is otherwise complete. Regards, Martin ___ 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] Re: distutils fix for building Zope against Python 2.4.1c1
Tim Peters wrote: Don't think it's needed on HEAD. As the checkin comment said: This doesn't appear to be an issue on the HEAD (MSVCCompiler initializes itself via __init__() on the HEAD). I verified by building Zope with unaltered HEAD too, and had no problem with that. Are you sure your HEAD is current? My copy of msvccompiler.py 1.67 reads def __init__ (self, verbose=0, dry_run=0, force=0): CCompiler.__init__ (self, verbose, dry_run, force) self.__version = get_build_version() if self.__version = 7: self.__root = rSoftware\Microsoft\VisualStudio self.__macros = MacroExpander(self.__version) else: self.__root = rSoftware\Microsoft\Devstudio self.initialized = False def initialize(self): self.__paths = self.get_msvc_paths(path) ... Regards, Martin ___ 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] Python2.4.1c1 and win32com
Leeuw van der, Tim wrote: The generated files crash the Python interpreter with Python 2.4 Under Python 2.4.1c1, They give a syntax error!? Even though the bug was fixed in pywin, it is interesting to observe that Mark's analysis says Cause of the underling crash is that the generated .py causes an overflow as the byte-code is generated - something in 2.4 bloated the byte-code for these modules. There also seems to be an interaction with PEP 263, for which patch 1101726 might provide a solution. So I think this needs to be investigated; please submit a bug report, including the Python file that causes the crash. Regards, Martin ___ 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] Re: RELEASED Python 2.4.1, release candidate 1
Jeremy Hylton wrote: I seem to have a problem with the install on XP SP1. Python itself is installed, but IDLE won't start. The error says: IDLE's subprocess didn't make connection. Either IDLE can't start a subprocess or personal firewall software is blocking the connection. I believe the problem is the firewall, but I'm not sure if it is related to the install. The previous install (Python 2.3) worked fine. What firewall software are you using? Any exceptions in the console when starting IDLE? Regards, Martin ___ 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.4.1, release candidate 1
Kurt B. Kaiser wrote: I had some strange experiences. Weird indeed. I downloaded the 2.4.1c1 installer to the desktop and clicked on it. It complained that it couldn't access the installer. Do you happen to remember the precise error message? I then clicked on the 2.4.1b2 installer and that started ok. Cancelled it. This must have been 2.4b2, right? However, didn't you have 2.4 installed already? For ducks I installed Python at D:\Python 2.4. It installed in the correct location, also found C:\Python24 and uninstalled that. That is supposed to happen; I never tested it, though. Python and IDLE appear to run ok. Shortcuts on Run work, and file association was updated, so right clicking a .py used IDLE from Python 2.4.1c1, in no-subprocess mode. Good! Martin ___ 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] Open issues for 2.4.1
Anthony Baxter wrote: Ok, I'm convinced - Martin, can you check this in? Done! Martin ___ 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.4.1, release candidate 1
Kurt B. Kaiser wrote: Do you happen to remember the precise error message? This installation package could not be opened. Ah, that you get if the file is already open. Do you run some shell extension that might want to look into the MSI file, or virus scanners? I also recall a KB article that the Indexing Service sometimes prevents files from being opened. Quadruple-click could also cause the problem, if you try to start multiple installers. If I wait for the download to complete and the virus check to finish, then it's AOK. That's why the third time was the charm. Ok, so it's likely incomplete download. Regards, Martin ___ 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] comprehension abbreviation
Eric Nieuwland wrote:
[ test for exprlist in testlist list-iter-opt ]
Aren't these names a bit mixed up w.r.t. what's in that position?
It comes more-or-less straight out of Grammar/Grammar, so: no,
I don't think so.
As far as I know
test is not a test but a function as it produces any value not just
True/False
To quote more of Grammar/Grammar, it is
test: and_test ('or' and_test)* | lambdef
and_test: not_test ('and' not_test)*
not_test: 'not' not_test | comparison
comparison: expr (comp_op expr)*
comp_op: ''|''|'=='|'='|'='|''|'!='|'in'|'not' 'in'|'is'|'is' 'not'
expr: xor_expr ('|' xor_expr)*
...
power: atom trailer* ['**' factor]
trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME
So a function call is a power is a factor is a term is an arith_expr
is a shift_expr is an and_expr is a xor_expr is an expr is a comparison
is a not_test is an and_test is a test.
exprlst is a list of names, not arbitrary expressions
No, it's more than that. I can also be
a, (b, c, (d, e))
But as I said: there are further (semantical) constraints what
kind of expression you can have there.
Regards,
Martin
___
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] Problems with definition of _POSIX_C_SOURCE
Jack Jansen wrote: The comment in pyconfig.h suggests that defining _POSIX_C_SOURCE may enable certain features, but the actual system headers appear to work the other way around: it seems that defining this will disable features that are not strict Posix. Does anyone know what the real meaning of this define is? Because if it is the former then Python is right, but if it is the latter Python really has no business defining it As you can see from the formal definition that Tim gave you, both is right: the macro causes system headers to provide the functions that POSIX says they should provide, and remove functions that POSIX does not mention, except when enabled through other feature selection macros. in general Python isn't 100% posix-compliant because it'll use all sorts of platform-dependent (and, thus, potentially non-posix-compliant) code... Python is 100% POSIX compliant. It also uses extensions to POSIX on platforms that provide them, but if these extensions are not available, it falls back to just not using them. So Python really uses POSIX with extension. A careful operating system developer will understand that this is a useful programming model, and provide feature selection macros to enable features that go beyond POSIX. That's why you can see various feature selection macros at the beginning of configure.in. In case you wonder why Python defines this in the first place: some platforms really need the definition, or else they don't provide the proper header contents (i.e. they fall back to ISO C for some headers), most notably Tru64 and HP-UX. Other systems implement different versions of the same API, e.g. Solaris, and defining _POSIX_C_SOURCE makes these systems provide the POSIX version of the API. This problem is currently stopping Python 2.4.1 to compile on this platform, so if anyone can provide any insight that would be very helpful... Just define _THIS_PLATFORM_SOURCE. If there is no such define, complain to the vendor of this platform, and ask Apple to provide such a macro. If this falls on deaf ears, go to the block Some systems cannot stand _XOPEN_SOURCE being defined at all; in configure.in and make another entry. Make sure that entry: - lists the precise reason for the entry (e.g. what structure/type/function gets hidden that shouldn't be hidden) - lists your name as the contact to ask for details - is specific to the particular release of this platform, so if future versions of this platform fix the bug, the work-around of disabling _XOPEN_SOURCE and _POSIX_C_SOURCE can be removed Regards, Martin ___ 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] thread semantics for file objects
Jeremy Hylton wrote: Are the thread semantics for file objecst documented anywhere? Literally, the answer to your question is no. I'm surprised that it does not, for example, guarantee that reads and writes are atomic, since CPython relies on fread and fwrite which are atomic. Where is the connection? Why would anything that CPython requires from the C library have any effect on Python's documentation? The only effect on Python documentation is that anybody writes it. Nobody cares, so nobody writes documentation. Remember, you were asking what behaviour is *documented*, not what behaviour is guaranteed by the implementation (in a specific version of the implementation). Also, there are other operations that go to the trouble of calling flockfile(). What's the point if we don't provide any guarantees? Because nobody cares about guarantees in the documentation. Instead, people care about observable behaviour. So if you get a crash due to a race condition, you care, you report a bug, the Python developer agrees its a bug, and fixes it by adding synchronization. Nobody reported a bug to the Python documentation. 0.6 wink. If it is not part of the specified behavior, then I suppose it's a quality of implementation issue. Either way it would be helpful if the Python documentation said something, e.g. you can rely on readline() being threadsafe or you can't but the current CPython implementation happens to be. It would be helpful to whom? To you? I doubt this, as you will be the one who writes the documentation :-) readline() seemed like an interesting case because readlines() doesn't have the same implementation and the behavior is different. So, as another example, you could ask whether readlines() has a bug or not. Nobody knows. It depends on the Python developer who reviews the bug report. Most likely, he considers it tricky and leaves it open for somebody else. If his name is Martin, he will find that this is not a bug (because it does not cause a crash, and does not contradict with the documentation), and he will reclassify it as a wishlist item. If his name is Tim, and if he has a good day, he will fix it, and add a comment on floating point numbers. Regards, Martin ___ 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] Change 'env var BROWSER override' semantics in webbrowser.py
Rodrigo Dias Arruda Senra wrote: I propose a small change in webbrowse.py module. I think I'm generally in favour of such a change. However: - please don't post patches to python-dev, unless you *want* them to be ignored. Typically, nobody will pick up patches from python-dev and apply them, except for rare cases (e.g. urgent bug fixes of serious breakages); post to SF instead. - please accompany your change with a documentation patch. It may be that the exact search procedure for browsers is not specified yet; take that chance and specify it so clearly that the code without your patch would actually conflict with the documentation, so that readers of the new code can verify that this is indeed the documentation-mandated behaviour. - consider integration of test cases. As this involves startup code and environment variables, I would be willing to waive the test case requirement here as unimplementable. However, do consider writing test cases. Regards, Martin ___ 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] New PyPI broken package editing
Walter Dörwald wrote: I'm not sure if this is the right approach. I think the approach is right, but the implementation is wrong. The encoding I specify in setup.py should be independent of the encoding used between distutils and PyPI to communicate on the wire. I.e. the author (and maintainer) argument should always be unicode. should is a correct description. It should allow Unicode strings, which it then should encode to UTF-8 during transmission. The matter of fact is that the register command as released in 2.4 (and 2.4.1) doesn't. When str is passed, this is treated as any other str in a unicode context, it is decoded using the default encoding. This would fix another problem: It would make it nearly impossible to send a request to PyPI with the wrong encoding, because any encoding problems are sorted out completely on the client side. distutils should *not* assume that byte strings are in the default encoding. It is fair to assume they are in ASCII; if the administrator has changed the default encoding, then this cannot possibly affect all the setup.py files out there. Also, it is a fact that the deployed versions of the register command just send byte strings in setup.py as-is, without trying to do any kind of recoding. In any case, PyPI now requires that the form submission uses UTF-8, and refuses anything else. So it *is* impossible to send, say, Latin-1; whether the client makes that happen by properly encoding Unicode strings or whether they are in setup.py in the first place does not matter. Is there a way to display the HTTP response by PyPI? Yes, please invoke upload with --show-response. Editing the package is still broken. The link edit on the page http://www.python.org/pypi/ll-ansistyle/0.6.1 gives: --- Error... There's been a problem with your request exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 92: ordinal not in range(128) I see. I'll investigate. Martin ___ 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] Re: [Python-checkins] python/dist/src/Python thread_pthread.h, 2.53, 2.53.4.1
Andrew MacIntyre wrote: This change has broken the build on FreeBSD 4.x for me: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes - I. -I./Include -DPy_BUILD_CORE -o Python/thread.o Python/thread.c In file included from Python/thread.c:101: Python/thread_pthread.h:19: syntax error *** Error code 1 This should be fixed now, please try again and report whether it works. It would be really nice if you could try to analyse such problems deeper in the future. In this case, it would have helped if you had reported that _POSIX_SEMAPHORES is defined as #define _POSIX_SEMAPHORES so that the #if line expands to #if == -1 The standard solution in this case is to write #if (_POSIX_SEMAPHORES+0) == -1 so that it expands to a binary add if _POSIX_SEMAPHORES really is a number (as it should be, according to POSIX); if some system incorrectly defines _POSIX_SEMAPHORES to empty, you get #if (+0) == -1 which still should compile. Regards, Martin ___ 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] 64-bit sequence and buffer protocol
Travis Oliphant wrote: What is the opinion of people on this list about how to fix the problem. I believe Martin was looking at the problem and had told Perry Greenfield he was fixing it. Apparently at the recent PyCon, Perry and he talked and Martin said the problem is harder than he had initially thought. It would be good to document what some of this problems are so that the community can assist in fixing this problem. I have put a patch on http://sourceforge.net/tracker/index.php?func=detailaid=1166195group_id=5470atid=305470 which solves this problem (eventually); this is the pre-PyCon version; I'll update it to the post-PyCon version later this month. I'll also write a PEP with the proposed changes. 1) Convert all C-ints to Py_LONG_LONG in the sequence and buffer protocols. This would be bad, since it would cause an overhead on 32-bit systems. Instead, I propose to change all C ints holding indexes and sizes to Py_ssize_t. 2) Add new C-API's that mirror the current ones which use Py_LONG_LONG instead of the current int. I'll propose a type flag, where each type can indicate whether it expects indexes and sizes as int or as Py_ssize_t. However, there are more issues. In particular, PyArg_ParseTuple needs to change to expect a different index type for selected i arguments; it also needs to change to possibly store a different type into the length of a s# argument. This altogether doesn't support types that exceed 2**31 elements even on an 32-bit system (or 2**63 elements on a 64-bit system); authors of such types would have to follow the advise 4) Tell writers of such large objects to not use the sequence and/or buffer protocols and instead use the mapping protocol and a different bytes object (that currently they would have to implement themselves and ignore the buffer protocol C-API). Regards, Martin ___ 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] Pickling instances of nested classes
Walter Dörwald wrote: So is this change wanted? useful? implementable with reasonable effort? Or just not worth it? I think it is just not worth it. This means I won't attempt to implement it. I think I defined originally the __module__ attribute for classes to support better pickling (and defined it to be a string to avoid cycles); we considered the nested classes case at the time and concluded oh well, don't do that then. Regards, Martin ___ 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] New PyPI broken package editing
Walter Dörwald wrote: The register command in 2.4 (and current CVS) simply does a value = str(value) in post_to_server() so the encoded bytes sent depend on the default encoding. Would it be sufficient to change this to value = unicode(value).encode(utf-8) Indeed. I think this can go into 2.4.2. Another solution might be to include the encoding in the Content-type header of the request. IMHO the best solution would be to do both: Always use UTF-8 as the encoding and include this in the Content-type header in the request. PyPI should honor this encoding when it finds it and should fall back to whatever it used before if it doesn't. Yeah, well :-) Content-type in form upload is a mess, as you certainly know. It should be honored, but commonly isn't. This, in turn, causes browsers to ignore it. PyPI uses the CGI module. It currently decodes anything that doesn't have a filename attribute to UTF-8, causing rejection of anything that doesn't send UTF-8. This could be fixed/extended, but I think that would be best done in the CGI module, for consumption by any application that uses form upload. For example, doing cgi.FieldStorage(..., encoding=UTF-8) should cause a) decoding of every field that has an encoding= in its content type b) decoding of every field that is not a file to UTF-8. It is a file if it I) has a filename, or II) cannot be decoded to the target decoding For backwards compatibility, a) can only be enabled if the CGI application explicitly tells what encoding it expects. I'd like to state contributions are welcome, although others may think differently. Regards, Martin ___ 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] New PyPI broken package editing
Walter Dörwald wrote: There's been a problem with your request exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 92: ordinal not in range(128) That should be fixed now, please try again. Please report further errors you find to sf.net/projects/pypi. Suggestions/RFEs could go to the PyPI tracker, or here to python-dev. Regards, Martin ___ 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.org/sf URLs aren't working? Re: [Python-Dev] Weekly Python Patch/Bug Summary
Skip Montanaro wrote: Here's a traceback: Traceback (most recent call last): File /usr/local/apache/cgi-bin/sf, line 82, in ? log_type(report, tracker) File /usr/local/apache/cgi-bin/sf, line 42, in log_type os.unlink(idsfile+.lck) OSError: [Errno 2] No such file or directory: '/tmp/sourceforge-ids.txt.lck' and here's the script. It looks like lock file creation is failing but log_type() isn't returning, so in the finally clause deletion fails. Somebody took world write permission on /tmp away; I don't know whether this was intentional - I have restored them for a moment. The script actually has two errors: it is not os.sleep, but time.sleep (so it would only try one time, not ten times); plus (and I'm glad you did not catch that, either :-) the finally block is always executed, even if the file was not created, and even if the function is left through return. I've fixed the script, however, if somebody takes away o+w on /tmp again, it will mean that the caching silently stops. Regards, Martin ___ 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.org/sf URLs aren't working? Re: [Python-Dev] Weekly Python Patch/Bug Summary
Guido van Rossum wrote: I forwarded this to MvL, who wrote the code; he'll look into it but probably not before Sunday. Actually, now that I saw that it is a permission problem, it turned out to be fixable quite easily. Regards, Martin ___ 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] Re: hierarchicial named groups extension to the re library
Josiah Carlson wrote: re2 can be used as a limited structural parser. This makes the re module useful for more things than it is currently. The question of it being in the standard library, however, I think should be made based on the criteria used previously (whatever they were). In general, if developers can readily agree that a functionality should be added (i.e. it is obvious for some reason), it is added right away. Otherwise, a PEP should be written, and reviewed by the community. In the specific case, Chris Ottrey submitted a link to his project to the SF patches tracker, asking for inclusion. I felt that there is likely no immediate agreement, and suggested he asks on python-dev, and writes a PEP. If this kind of functionality would fall on immediate rejection for some reason, even writing the PEP might be pointless. If the functionality is generally considered useful, a PEP can be written, and then implemented according to the PEP procedures (i.e. collect feedback, discuss alternatives, ask for BDFL pronouncement). I personally think that the proposed functionality should *not* live in a separate module, but somehow be integrated into SRE. Whether or not the proposed functionality is useful in the first place, I don't know. I never have nested named groups in my regular expressions. Regards, Martin ___ 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] longobject.c ob_size
Michael Hudson wrote: Asking mostly for curiousity, how hard would it be to have longs store their sign bit somewhere less aggravating? It seems to me that the top bit of ob_digit[0] is always 0, for example, and I'm sure this would result no less convolution in longobject.c it'd be considerably more localized convolution. I think the amount of special-casing that you need would remain the same - i.e. you would have to mask out the sign before performing the algorithms, then bring it back in. Masking out the bit from digit[0] might slow down the algorithms somewhat, because you would probably mask it out from every digit, not only digit[0] (or else test for digit[0], which test would then be performed for all digits). You would also have to keep the special case for 0L, which has ob_size==0 (i.e. doesn't have digit[0]). That said, I think the change could be implemented within a few hours, taking a day to make the testsuite run again; depending on the review process, you might need two releases to fix the bugs (but then, it is also reasonable to expect to get it right the first time). Regards, Martin ___ 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] Unicode byte order mark decoding
Stephen J. Turnbull wrote: So there is a standard for the UTF-8 signature, and I know of applications which produce it. While I agree with you that Python's codecs shouldn't produce it (by default), providing an option to strip is a good idea. I would personally like to see an utf-8-bom codec (perhaps better named utf-8-sig, which strips the BOM on reading (if present) and generates it on writing. However, this option should be part of the initialization of an IO stream which produces Unicodes, _not_ an operation on arbitrary internal strings (whether raw or Unicode). With the UTF-8-SIG codec, it would apply to all operation modes of the codec, whether stream-based or from strings. Whether or not to use the codec would be the application's choice. Regards, Martin ___ 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] Unicode byte order mark decoding
Walter Dörwald wrote: The stateful decoder has a little problem: At least three bytes have to be available from the stream until the StreamReader decides whether these bytes are a BOM that has to be skipped. This means that if the file only contains ab, the user will never see these two characters. This can be improved, of course: If the first byte is a, it most definitely is *not* an UTF-8 signature. So we only need a second byte for the characters between U+F000 and U+, and a third byte only for the characters U+FEC0...U+FEFF. But with the first byte being \xef, we need three bytes *anyway*, so we can always decide with the first byte only whether we need to wait for three bytes. A solution for this would be to add an argument named final to the decode and read methods that tells the decoder that the stream has ended and the remaining buffered bytes have to be handled now. Shouldn't an empty read from the underlying stream be taken as an EOF? Regards, Martin ___ 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] Unicode byte order mark decoding
Walter Dörwald wrote: There are situations where the byte stream might be temporarily exhausted, e.g. an XML parser that tries to support the IncrementalParser interface, or when you want to decode encoded data piecewise, because you want to give a progress report. Yes, but these are not file-like objects. In the IncrementalParser, it is *not* the case that a read operation returns an empty string. Instead, the application repeatedly feeds data explicitly. For a file-like object, returning indicates EOF. Regards, Martin ___ 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] Unicode byte order mark decoding
Stephen J. Turnbull wrote: Of course it must be supported. My point is that many strings (in my applications, all but those strings that result from slurping in a file or process output in one go -- example, not a statistically valid sample!) are not the beginning of what once was a stream. It is error-prone (not to mention unaesthetic) to not make that distinction. Explicit is better than implicit. I can't put these two paragraphs together. If you think that explicit is better than implicit, why do you not want to make different calls for the first chunk of a stream, and the subsequent chunks? s=cStringIO.StringIO() s1=codecs.getwriter(utf-8)(s) s1.write(uHallo) s.getvalue() 'Hallo' Yes! Exactly (except in reverse, we want to _read_ from the slurped stream-as-string, not write to one)! ... and there's no need for a utf-8-sig codec for strings, since you can support the usage in exactly this way. However, if there is an utf-8-sig codec for streams, there is currently no way of *preventing* this codec to also be available for strings. The very same code is used for streams and for strings, and automatically so. Regards, Martin ___ 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] Unicode byte order mark decoding
Nicholas Bastin wrote: It would be nice if you could optionally specify that the codec would assume UTF-16BE if no BOM was present, and not raise UnicodeError in that case, which would preserve the current behaviour as well as allow users' to ask for behaviour which conforms to the standard. Alternatively, the UTF-16BE codec could support the BOM, and do UTF-16LE if the other BOM is found. This would also support your usecase, and in a better way. The Unicode assertion that UTF-16 is BE by default is void these days - there is *always* a higher layer protocol, and it more often than not specifies (perhaps not in English words, but only in the source code of the generator) that the default should by LE. Regards, Martin ___ 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] Re: marshal / unmarshal
Skip Montanaro wrote: Martin Yet, this *still* is a platform dependence. Python makes no Martin guarantee that 1e1000 is a supported float literal on any Martin platform, and indeed, on your platform, 1e1000 is not supported Martin on your platform. Are float(inf) and float(nan) supported everywhere? I would not expect that, but Tim will correct me if I'm wrong. As a starting point can it be agreed on whether they should be supported? (There is a unique IEEE-754 representation for both values, right? Perhaps yes for inf, but I think maybe no for nan. There are multiple IEEE-754 representations for NaN. However, I understand all NaN are meant to compare unequal - even if they use the same representation. If so, the float(1e1) == float(inf) in all cases, right? Currently, not necessarily: if a large-enough exponent is supported (which might be the case with a IEEE long double, dunno), 1e1 would be a regular value. That seems like it would be a start in the right direction. Pieces of it would be a start in the right direction. Regards, Martin ___ 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] Re: Re: Re: marshal / unmarshal
Fredrik Lundh wrote: I was under the impression that the marshal format has been stable for quite a long time (people are using it for various RPC protocols, among other things). I might be wrong. Python 2.4 introduced support for string sharing in marshal files, with an option to suppress sharing if an application needs to suppress it for backwards compatibility. Regards, Martin ___ 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] Unified or context diffs?
Nick Coghlan wrote: Are context diffs still favoured for patches? Just for the record: I also prefer unified over context diffs. Regards, Martin ___ 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 tests fails on HP-UX 11.11 and core dumps
Senthil Prabu.S wrote: I tried python -4.2.1 on a HP-UX 11.11 PA machine. I was able to python. Gmake passes, gmake test results in error. The python reported that test_pty fails,when running this test alone. Can anyone help to find why core dumps at running the *test_subprocess.py* test. Also how can I solve it? Please understand that python-dev is not the place to get free consulting. If you are willing to investigate somewhat further, try to understand the problem, and propose patches, then I would be willing to review the patches, comment on their correctness, and perhaps integrate them into the Python CVS. As it stands, I can personally take no more time to help with HP-UX problems for the near future (say, ten years :-) I do recall that there are serious problems with pseudo-terminals in Python and HP-UX, so yes, we have heard of this before. If I knew a solution, it were applied to Python already. Please understand that this perhaps hostile-sounding response is just my personal view; if somebody else responds more gracefully, just ignore me. Regards, Martin ___ 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] shadow password module (spwd) is never built due to error in setup.py
Irmen de Jong wrote: Please advise? setup.py should refer to config_h_vars, which in turn should be set earlier. Regards, Martin ___ 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] Proper place to put extra args for building
Brett C. wrote: Hmm. OK, that is an interesting idea. Would make rebuilding a lot easier if it was just an environment variable that was part of the default OPT value; ``OPT=$BUILDFLAGS -g -Wall -Wstrict-prototyping. I say we go with that. What is a good name, though? PY_OPT? I think EXTRA_CFLAGS is common, and it would not specifically be part of OPT, but rather of CFLAGS. I am only talking about that because that is how OPT is currently structured; configure.in replaces the defaults with what the user provides if the environment variable is set. This is what I don't want. The question is whether the user is supposed to provide a value for OPT in the first place. OPT is a set of flag that (IMO) should control the optimization level of the compiler, which, in the wider sense, also includes the question whether debug information should be generated. It should be possible to link object files compiled with different OPT settings, so flags that will give binary-incompatible object files should not be in OPT. It might be desirable to allow the user to override OPT, e.g. to specify that the compiler should not use -O3 but, say, -O1. I don't think there is much point in allowing OPT to be extended. But then, it is already possible to override OPT (when invoking make), which might be enough control. Regards, Martin ___ 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] Proper place to put extra args for building
Brett C. wrote: Works for me. If no one objects I will check in the change for CFLAGS to make it ``$(BASECFLAGS) $(OPT) $EXTRA_CFLAGS`` soon (is quoting it enough to make sure that it isn't evaluated by configure but left as a string to be evaluated by the shell when the Makefile is running?). If you put it into Makefile.pre.in, the only thing to avoid that configure evaluates is is not to use @[EMAIL PROTECTED] OTOH, putting a $ in front of it is not good enough for make: $EXTRA_CFLAGS evaluates the variable E, and then appends XTRA_CFLAGS. Regards, Martin ___ 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] Proper place to put extra args for building
Brett C. wrote: Yep, you're right. I initially thought that the parentheses meant it was a Makefile-only variable, but it actually goes to the environment for those unknown values. Before I check it in, though, should setup.py be tweaked to use it as well? I say yes. You means sysconfig.py, right? Probably yes. This is a mess. distutils should just do what Makefile does for builtin modules, i.e. use CFLAGS from the Makefile. Instead, it supports CFLAGS as being additive to the Makefile value CFLAGS, which in turn it just *knows* $(BASECFLAGS) $(OPT). Regards, Martin ___ 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] Proper place to put extra args for building
Brett C. wrote: You means sysconfig.py, right? Right. No, I mean Python's setup.py; line 174. Ah, ok. You mean Distutils' sysconfig, right? I can change that as well if you want. Please do; otherwise, people might see strange effects. Regards, Martin ___ 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] Proper place to put extra args for building
Brett C. wrote: OK, EXTRA_CFLAGS support has been checked into Makefile.pre.in and distutils.sysconfig . Martin, please double-check I tweaked sysconfig the way you wanted. It is the way I wanted it, but it doesn't work. Just try and use it for some extension modules to see for yourself, I tried with a harmless GCC option (-fgcse). The problem is that distutils only looks at the Makefile, not at the environment variables. So I changed parse_makefile to do what make does: fall back to the environment when no makefile variable is set. This was still not sufficient, since distutils never looks at CFLAGS. So I changed setup.py and sysconfig.py to fetch CFLAGS, and not bother with BASECFLAGS and EXTRA_CFLAGS. setup.py 1.218 NEWS 1.1289 sysconfig.py 1.65 Regards, Martin ___ 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] Problem with embedded python
Ugo Di Girolamo wrote: What am I doing wrong? This is not the forum to ask this question, please use python-list@python.org instead. Regards, Martin ___ 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] Py_UNICODE madness
Nicholas Bastin wrote: That makes PyUnicode_FromUnicode() a lot less useful. Well, really, not useful at all. Why do you say that? Py_UNICODE is as good a type to store characters as any other, and if you happen to have a Py_UNICODE[], you can use that function to build a unicode object. You might suggest that PyUnicode_FromWideChar is more useful, but that's only true on platforms that support wchar_t. Useful to do what? PyInt_FromLong isn't useful if you have a void*, either... Is there no universally supported way of moving buffers of unicode data (as common data types, like unsigned short, etc.) into Python from C? There is no common Unicode type in C, period (be it Python or not). Your best bet is to prepare a Py_UNICODE[], either by copying from your favourite Unicode type, or by casting it, e.g. #if Py_UNICODE_IS_AS_WIDE_AS_MY_UNICODE_TYPE Py_UNICODE* data = (Py_UNICODE*) my_data; do_free=0; #else Py_UNICODE* data = malloc(sizeof(Py_UNICODE)*my_data_len); for(int i=0;i=my_data_len) data[i] = my_data[i]; do_free=1; #endif PyObject *uni = PyUnicode_FromUnicode(data); if(do_free)free(data); Regards, Martin ___ 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] New Py_UNICODE doc
Nicholas Bastin wrote: This type represents the storage type which is used by Python internally as the basis for holding Unicode ordinals. Extension module developers should make no assumptions about the size of this type on any given platform. But people want to know Is Python's Unicode 16-bit or 32-bit? So the documentation should explicitly say it depends. Regards, Martin ___ 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] Adding DBL_MANTISSA and such to Python
Edward C. Jones wrote: The documentation should discuss portability. This is the critical issue here. Discussing portability is not enough; these features really ought to be either available on a majority of the installations, or not available at all. In particular, they would need to be available on Windows. I haven't check whether VC 7.1 provides them, and if it doesn't, somebody would have to provide a direct implementation. I'd say contributions are welcome. Regards, Martin ___ 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] PEP 340 keyword: after
I haven't followed the PEP 340 discussion in detail, but as the PEP doesn't list keywords that have been considered and rejected, I'd like to propose my own: use after instead of block: after opening(/etc/passwd) as f: for line in f: print line.rstrip() after locking(myLock): # code that needs to hold the lock Regards, Martin ___ 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] New Py_UNICODE doc
Nicholas Bastin wrote: The important piece of information is that it is not guaranteed to be a particular one of those sizes. Once you can't guarantee the size, no one really cares what size it is. Please trust many years of experience: This is just not true. People do care, and they want to know. If we tell them it depends, they ask how can I find out. The documentation should discourage developers from attempting to manipulate Py_UNICODE directly, which, other than trivia, is the only reason why someone would care what size the internal representation is. Why is that? Of *course* people will have to manipulate Py_UNICODE* buffers directly. What else can they use? Regards, Martin ___ 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] New Py_UNICODE doc
Nicholas Bastin wrote: If this is the case, then we're clearly misleading users. If the configure script says UCS-2, then as a user I would assume that surrogate pairs would *not* be encoded, because I chose UCS-2, and it doesn't support that. What do you mean by that? That the interpreter crashes if you try to store a low surrogate into a Py_UNICODE? I would assume that any UTF-16 string I would read would be transcoded into the internal type (UCS-2), and information would be lost. If this is not the case, then what does the configure option mean? It tells you whether you have the two-octet form of the Universal Character Set, or the four-octet form. Regards, Martin ___ 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] New Py_UNICODE doc
Nicholas Bastin wrote: Because the encoding of that buffer appears to be different depending on the configure options. What makes it appear so? sizeof(Py_UNICODE) changes when you change the option - does that, in your mind, mean that the encoding changes? If that isn't true, then someone needs to change the doc, and the configure options. Right now, it seems *very* clear that Py_UNICODE may either be UCS-2 or UCS-4 encoded if you read the configure help, and you can't use the buffer directly if the encoding is variable. However, you seem to be saying that this isn't true. It's a compile-time option (as all configure options). So at run-time, it isn't variable. Regards, Martin ___ 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] New Py_UNICODE doc
Nicholas Bastin wrote: No, that's not true. Python lets you choose UCS-4 or UCS-2. What the default is depends on your platform. The truth is more complicated. If your Tcl is built for UCS-4, then Python will also be built for UCS-4 (unless overridden by command line). Otherwise, Python will default to UCS-2. Regards, Martin ___ 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] New Py_UNICODE doc
M.-A. Lemburg wrote: Hmm, looking at the configure.in script, it seems you're right. I wonder why this weird dependency on TCL was added. If Python is configured for UCS-2, and Tcl for UCS-4, then Tkinter would not work out of the box. Hence the weird dependency. Regards, Martin ___ 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] New Py_UNICODE doc
Shane Hathaway wrote: Ok. Thanks for helping me understand where Python is WRT unicode. I can work around the issues (or maybe try to help solve them) now that I know the current state of affairs. If Python correctly handled UTF-16 strings internally, we wouldn't need the UCS-4 configuration switch, would we? Define correctly. Python, in ucs2 mode, will allow to address individual surrogate codes, e.g. in indexing. So you get u\U00012345[0] u'\ud808' This will never work correctly, and never should, because an efficient implementation isn't possible. If you want safe indexing and slicing, you need ucs4. Regards, Martin ___ 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] New Py_UNICODE doc
Nicholas Bastin wrote: What I mean is pretty clear. UCS-2 does *NOT* support surrogate pairs. If it did, it would be called UTF-16. If Python really supported UCS-2, then surrogate pairs from UTF-16 inputs would either get turned into two garbage characters, or the I couldn't transcode this UCS-2 code point (I don't remember which on that is off the top of my head). OTOH, if Python really supported UTF-16, then unichr(0x1) would work, and len(u\U0001) would be 1. It is primarily just the UTF-8 codec which supports UTF-16. Regards, Martin ___ 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] New Py_UNICODE doc
Shane Hathaway wrote: Py_UNICODE would always be 32 bits wide. This would break PythonWin, which relies on Py_UNICODE being the same as WCHAR_T. PythonWin is not broken, it just hasn't been ported to UCS-4, yet (and porting this is difficult and will cause a performance loss). Regards, Martin ___ 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
