Re: [Python-Dev] Another case for frozendict
In article
CAPTjJmoZHLfT3G4eqV+=zcvbpf65fkcmah9h_8p162uha7f...@mail.gmail.com,
Chris Angelico ros...@gmail.com wrote:
On Mon, Jul 14, 2014 at 12:04 AM, Jason R. Coombs jar...@jaraco.com wrote:
I can achieve what I need by constructing a set on the âitemsâ of the
dict.
set(tuple(doc.items()) for doc in res)
{(('n', 1), ('err', None), ('ok', 1.0))}
This is flawed; the tuple-of-tuples depends on iteration order, which
may vary. It should be a frozenset of those tuples, not a tuple. Which
strengthens your case; it's that easy to get it wrong in the absence
of an actual frozendict.
I would love to see frozendict in python.
I find myself using dicts for translation tables, usually tables that
should not be modified. Documentation usually suffices to get that idea
across, but it's not ideal.
frozendict would also be handy as a default values for function
arguments. In that case documentation isn't enough and one has to resort
to using a default value of None and then changing it in the function
body.
I like frozendict because I feel it is expressive and adds some safety.
-- Russell
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: [python-tulip] Need help to finish asyncio documentation
In article cap7+vjkmbpyu_e+4tyc3x6ofc_ydmd9k9pxk8atoll6oj_8...@mail.gmail.com, Guido van Rossum gu...@python.org wrote: We could really use more help reviewing and finishing asyncio's docs! ... http://docs.python.org/dev/library/asyncio.html I think the documentation desperately needs an overview. I find it very confusing without one. I guess the links to PEPs are intended to be that, but it would be much more helpful to include the overview in the documentation. I think a bit of re-ordering of topics could also help: - One of the first things presented is a discussion of event loop policy, even though most users will never need to change the policy. Couldn't this go at the end? - It tells how to create and set event loops, with no hint as to why one would want to do that. Is it common to have multiple event loops? A related oddity: what is the point of BaseEventLoop.run_until_complete(future)? It sounds interesting but obscure (unless it applies to one of many event loops). In other words: if it was possible to show basic usage of event loops early, then discuss how to do the fancy stuff (new event loops, new even loop policies later) that might help. BaseEventLoop.stop() says: Every callback scheduled before stop() is called will run. but it does not say WHEN it will run -- immediately due to the stop, or normally as if stop was never called? That said, I am very excited to have this functionality. I have been sticking with Python 2 for now, but this feature may entice me to make the switch. -- Russell -- Forwarded message -- From: Victor Stinner victor.stin...@gmail.com Date: Sat, Feb 8, 2014 at 2:38 PM Subject: [python-tulip] Need help to finish asyncio documentation To: python-tulip python-tu...@googlegroups.com Hi, I wrote most parts of the documentation of the asyncio module, but I'm not sure that anyone already read it yet. Can you please at least take at look? http://docs.python.org/dev/library/asyncio.html Tell me if the documentation needs more examples. I don't want to add whole applications, only very short examples to explain one feature or concept, or show how to use one specific API. I just realized that add/remove_reader/writer() methods of the event loop were not documented, sock_recv/sendall/accept/connect() methods neither. I documented them. There are still many functions which only have XXX for documentation. If you would like to contribute, send patches on .rst files. The source of the documentation is in the Doc/library/ directory of CPython repository: http://hg.python.org/cpython/ Files asyncio-*.rst: http://hg.python.org/cpython/file/default/Doc/library Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 455: TransformDict
In article c4c036b6-130c-4718-beb1-a7c923008...@gmail.com, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Sep 22, 2013, at 6:16 PM, Ethan Furman et...@stoneleaf.us wrote: Are we close to asking for pronouncement? When you're ready, let me know. In the meantime, I conducting usability tests on students in Python classes and researching how well it substitutes for existing solutions for case insensitive dictionaries (the primary use case) and for other existing cases such as dictionaries with unicode normalized keys. If you want to participate in the research, I could also use help looking at what other languages do. Python is not the first language with mappings or to encounter use cases for transforming keys prior to insertion and lookup. I would like to find out what work has already been done on this problem. Another consideration is whether the problem is more general that just dictionaries. Would you want similar functionality in all mapping-like objects (i.e. a persistent dictionaries, os.environ, etc)? Would you want similar functionality for other services (i.e. case-insensitive filenames or other homomorphisms). You can also add to the discussion by trying out your own usability tests on people who haven't been exposed to this thread or the pep. My early results indicate that the API still needs work. ... * Another issue is that we're accumulating too many dictionary variants and that is making it difficult to differentiate and choose between them. I haven't found anyone (even in advanced classes with very experienced pythonistas) would knew about all the variations: dict, defaultdict, Mapping, MutableMapping, mapping views, OrderedDict, Counter, ChainMap, andTransformDict. I agree. I personally think being able to transform keys would be much more useful as a property of existing dictionaries. I often use case-insensitive keys. But I use them with dict and OrderedDict (and probably ought to use defaultdict, as well). TransformDict is neat, but I'd personally be happier seeing this as a 3rd party library for now. -- Russell ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
In article b3293155-e4d5-4389-a555-c31bc49ce...@gmail.com, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Sep 14, 2013, at 1:32 PM, Ned Deily n...@acm.org wrote: The most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have a mature clang but do not provide a 10.6 SDK. Even with using an SDK, it's still possible to end up inadvertently linking with the wrong versions of system libraries. We have been burned by that in the past. I think we should offer a separate Mac build just for 10.6 (much like we do for the 32-bit PPC option for 10.5). If Apple drops support for gcc in 10.9 I guess we have to go this route, but please be careful. Every time you add a new version of python for MacOS X it means that folks providing binary installers (e.g. for numpy) have to provide another binary, and folks using those installers have another chance of picking the wrong one. If you do make a 10.6-only installer, what is the minimum version of MacOS X the modern compiler would support? 10.7 gives a more measured upgrade path, but 10.8 gives a better compiler. -- Russell ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pep 422 Safe object finalization question: why break weakrefs first?
Pep 422 proposes the following order for dealing with cyclic isolates: 1. Weakrefs to CI objects are cleared, and their callbacks called. At this point, the objects are still safe to use. 2. The finalizers of all CI objects are called. 3. The CI is traversed again to determine if it is still isolated. If it is determined that at least one object in CI is now reachable from outside the CI, this collection is aborted and the whole CI is resurrected. Otherwise, proceed. 4. The CI becomes a CT as the GC systematically breaks all known references inside it (using the tp_clear function). Why are weakrefs are broken first, before determining if any of the objects should become resurrected? Naively I would expect weakrefs to be broken after step 3, once the system is sure no objects have been resurrected. I request that this information be added to PEP 422. -- Russell ___ 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 443 - Single-dispatch generic functions (including ABC support)
In article c9841b1f-80f3-4e77-83e6-f71859524...@langa.pl, Åukasz Langa luk...@langa.pl wrote: Hello, Since the initial version, several minor changes have been made to the PEP. The history is visible on hg.python.org. The most important change in this version is that I introduced ABC support and completed a reference implementation. No open issues remain from my point of view. Is it true that this cannot be used for instance and class methods? It dispatches based on the first argument, which is self for instance methods, whereas the second argument would almost certainly be the argument one would want to use for conditional dispatch. -- Russell ___ 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 443 - Single-dispatch generic functions (including ABC support)
A question about the example: how hard would it be to modify the example @fun.register(list) ... to work with other collections? If it is easy, I think it would make a for a much more useful example. -- Russell ___ 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 435 -- Adding an Enum type to the Python standard library
In article CAP7+vJLUO0B0y+=Jcg8D=jq3mggsam1tb9zztto7ncrke6m...@mail.gmail.com, Guido van Rossum gu...@python.org wrote: On Fri, Apr 12, 2013 at 9:34 AM, Guido van Rossum gu...@python.org wrote: To me, NotImplementedError means that a subclass didn't implement something it should have implemented. But that's not the case here, is it? It's not a bug in the class, it's a bug in the call site. So I agree it ought to be TypeError. Seems I was late to this particular argument. :-) Anyway, as far as I can tell the PEP looks great. I personally think it would be nicer if regular Enums were ordered (as long as the underlying values are ordered), but I don't care enough to overrule the FLUFL. I, too, would strongly prefer to see ordering within an enum. I use home-made enums heavily in my code and find ordering comparisons useful there. Using intEnum is certainly doable, but that opens up the door to comparing values from different Enums, which is not something I'd want to allow. I don't understand why order tests are seen as a bad thing, as long as the values have order (as they will in the common cases of string and int values). It seems the code must go out of its way to prohibit such tests. In any case, I'm very pleased to have this library. it will get rid of much boilerplate in my code. It seems very well designed, and I'm really glad to see it supports subclassing to add values! -- Russell ___ 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] Playing with a new theme for the docs
In article 4f6b5b33.9020...@pearwood.info, Steven D'Aprano st...@pearwood.info wrote: ... My first impression of this page: http://www.python.org/~gbrandl/build/html/index.html was that the grey side-bar gives the page a somber, perhaps even dreary, look. First impressions count, and I'm afraid that first look didn't work for me. But clicking through onto other pages with more text improved my feelings. A big +1 on the pale green shading of code blocks. The basic design seems good to me. I'd prefer a serif font for blocks of text, while keeping sans serif for the headings, but that's a mild preference. Looking forward to seeing the next iteration. I like the overall design, but one thing seems to be missing is an overview of what Python is (hence what the page is about). Naturally we don't need that, but a one-line overview with a link to more information would be helpful. -- Russell ___ 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] Playing with a new theme for the docs
In article rowen-edfa17.11495422032...@news.gmane.org, Russell E. Owen ro...@uw.edu wrote: In article 4f6b5b33.9020...@pearwood.info, Steven D'Aprano st...@pearwood.info wrote: ... My first impression of this page: http://www.python.org/~gbrandl/build/html/index.html was that the grey side-bar gives the page a somber, perhaps even dreary, look. First impressions count, and I'm afraid that first look didn't work for me. But clicking through onto other pages with more text improved my feelings. A big +1 on the pale green shading of code blocks. The basic design seems good to me. I'd prefer a serif font for blocks of text, while keeping sans serif for the headings, but that's a mild preference. Looking forward to seeing the next iteration. I like the overall design, but one thing seems to be missing is an overview of what Python is (hence what the page is about). Naturally we don't need that, but a one-line overview with a link to more information would be helpful. -- Russell I'm afraid my last sentence was incoherent. I meant to say: Naturally we, as Python users, don't need that; but a one-line overview with a link to more information would be helpful to others who are not familiar with the language. -- Russell ___ 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] Drop the new time.wallclock() function?
In article efe3877620384242a686d52278b7ccd3362...@rkv-it-exch104.ccp.ad.local, Kristján Valur Jónsson krist...@ccpgames.com wrote: What does jumping forward mean? That's what happens with every clock at every time quantum. The only effect here is that this clock will be slightly noisy, i.e. its precision becomes worse. On average it is still correct. Look at the use cases for this function 1) to enable timeouts for certaing operations, like acquiring locks: Jumping backwards is bad, because that may cause infinite wait time. But jumping forwards is ok, it may just mean that your lock times out a bit early 2) performance measurements: If you are running on a platform with a broken runtime clock, you are not likely to be running performance measurements. Really, I urge you to skip the strict keyword. It just adds confusion. Instead, lets just give the best monotonic clock we can do which doesnt move backwards. Let's just provide a practical real time clock with high resolution that is appropriate for providing timeout functionality and so won't jump backwards for the next 20 years. Let's simply point out to people that it may not be appropriate for high precision timings on old and obsolete hardware and be done with it. I agree. I prefer the name time.monotonic with no flags. It will suit most use cases. I think supplying truly steady time is a low level hardware function (e.g. buy a GPS timer card) with a driver. -- Russell ___ 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] peps: Update with bugfix releases.
In article nad-49d85a.22070509022...@news.gmane.org, Ned Deily n...@acm.org wrote: In article rowen-ba4fcf.11522909022...@news.gmane.org, Russell E. Owen ro...@uw.edu wrote: One problem I've run into is that the 64-bit Mac python 2.7 does not work properly with ActiveState Tcl/Tk. One symptom is to build matplotlib. The results fail -- both versions of Tcl/Tk somehow get linked in. The 64-bit OS X installer is built on and tested on systems with A/S Tcl/Tk 8.5.x and we explicitly recommend its use when possible. http://www.python.org/download/mac/tcltk/ Please open a python bug for this and any other issues you know of regarding the use with current A/S Tcl/Tk 8.5.x with current 2.7.x or 3.2.x installers on OS X 10.6 or 10.7. Yes. I apologize. See the discussion in the Mac python mailing list (I replied to your email there). I was trying to build a matplotlib binary installer and ran into problems. I don't know where the problem comes from, and it may well not have anything to do with the python build. -- Russell ___ 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] peps: Update with bugfix releases.
In article 4f32df1e.40...@v.loewis.de, Martin v. Lowis mar...@v.loewis.de wrote: Am 05.02.2012 21:34, schrieb Ned Deily: In article 20120205204551.horde.ncdeyvnncxdpltxvnkzi...@webmail.df.eu, mar...@v.loewis.de wrote: I understand that but, to me, it makes no sense to send out truly broken releases. Besides, the hash collision attack is not exactly new either. Another few weeks can't make that much of a difference. Why would the release be truly broken? It surely can't be worse than the current releases (which apparently aren't truly broken, else there would have been no point in releasing them back then). They were broken by the release of OS X 10.7 and Xcode 4.2 which were subsequent to the previous releases. None of the currently available python.org installers provide a fully working system on OS X 10.7, or on OS X 10.6 if the user has installed Xcode 4.2 for 10.6. In what way are the current releases not fully working? Are you referring to issues with building extension modules? One problem I've run into is that the 64-bit Mac python 2.7 does not work properly with ActiveState Tcl/Tk. One symptom is to build matplotlib. The results fail -- both versions of Tcl/Tk somehow get linked in. We have had similar problems with the 32-bit python.org python in the past, but recent builds have been fine. I believe the solution that worked for the 32-bit versions was to install ActiveState Tcl/Tk before making the distribution build. The results would work fine with Apple's Tcl/Tk or with ActiveState Tcl/Tk. I don't know if the same solution would work for 64-bit python. I don't know of any issues with the 32-bit build of Python 2.7. I've not tried the Python 3 builds. -- Russell ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
In article 4c62c01d.6000...@netwok.org, Ãric Araujo mer...@netwok.org wrote: Hello list Tarek opened a distutils bugs in http://bugs.python.org/issue7175 that evolved into a discussion about the proper location to use for config files. Distutils uses [.]pydistutils.cfg and .pypirc, and now unittest2 has a config file too. It would be nice to define one standard location for config files used by stdlib modules, and maybe also by third-party programs related closely to Python development (testing tools, static code checkers and the like), in a way that doesnât clutter the user home directory with a dozen dotfiles while still being easily found. (The Unix notions of dotfiles and home directory have to be adapted to use non-dotfiles in some standard place on various Windows. The Mac experts disagree on the right directory to use.) Tarek, Antoine, RDM, MAL were +1 on using ~/.python (whether to use .pythonx.y or .python/x.y is a subissue to discuss after general agreement). What do you think about this? I like the idea as long as different versions of python have different directories and the files are intended to be user-specific. If the files are shared among all users then /usr/local/something seems more reasonable. I also think whatever you choose for linux is also the best choice for Mac OS X (my preferred platform). While there are other possible directories, such as ~/Library/Application Support/something, all tools derived from unix that I know about use the unix convention (ssh, X11, bash...) and I would argue that Python is close enough to count even though it is a framework build. Put another way, copying the unix convention is simple, is exactly what power users would expect and I don't see it would do any harm. -- Russell ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147, __pycache__ directories and umask
In article 4ba80418.6030...@canterbury.ac.nz, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Antoine Pitrou wrote: In light of this issue, I'm -0.5 on __pycache__ becoming the default caching mechanism. The directory ownership/permissions issue is too much of a mess, especially for Web applications (think __pycache__ files created by the Apache user). Doesn't the existing .pyc mechanism have the same problem? Seems to me it's just as insecure to allow the Apache user to create .pyc files, since an attacker could overwrite them with arbitrary bytecode. The only safe way is to pre-compile under a different user and make everything read-only to Apache. The same thing would apply under the __pycache__ regime. This does sound like a bit security hole both in existing Python and the new __pycache__ proposed mechanism. It seems like this is the time to address it, while changing the caching mechanism. If .pyc files are to be shared, it seems essential to (by default) generate them at install time and make them read-only for unprivileged users. This in turn implies that we may have to give up some support for dragging python modules into site-packages, e.g. not generate .pyc files for such modules. At least if we go that route it will mostly affect power users, who can presumably cope. -- Russell ___ 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 2.6.3
In article c11f8211-8938-4c68-8221-c3c73e8e5...@mac.com, Ronald Oussoren ronaldousso...@mac.com wrote: On 9 Sep, 2009, at 19:29, Ned Deily wrote: Without trying to put Ronald on the spot (too much!), it would be a good idea to get his assessment where things stand wrt 2.6 on 10.6 before setting a final release date. MacOS X 10.6 support should be stable now, except for a critical issue with IDLE: opening a new window hangs IDLE (issue 6864). That said, I haven't scanned the issue tracker for more 10.6 related issues. BTW. I'm fine with a sept. 25th release, that should give us enough time to shake out issues with OSX 10.6 support. Ronald- Some or all earlier Mac binaries of Python 2.6 were not compatible with 3rd party Aqua Tcl/Tk (e.g. ActiveState's versions) -- at least on MacOS X 10.5. I hope that will be fixed with the current release. -- Russell ___ 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] (try-except) conditional expression similar to (if-else) conditional (PEP 308)
In article d28975e8-6706-4515-9c9e-fb7f90775...@masklinn.net, Xavier Morel catch-...@masklinn.net wrote: On 6 Aug 2009, at 00:22 , Jeff McAninch wrote: I'm new to this list, so please excuse me if this topic has been discussed, but I didn't see anything similar in the archives. I very often want something like a try-except conditional expression similar to the if-else conditional. I fear this idea is soon going to extend to all compound statements one by one. Wouldn't it be smarter to fix the issue once and for all by looking into making Python's compound statements (or even all statements without restrictions) expressions that can return values in the first place? Now I don't know if it's actually possible, but if it is the problem becomes solved not just for try:except: (and twice so for if:else:) but also for while:, for: (though that one's already served pretty well by comprehensions) and with:. I like this idea a lot. -- Russell ___ 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.6.2
In article nad-304e10.20284516042...@news.gmane.org, Ned Deily n...@acm.org wrote: In article dd982bd4-02ab-4395-afee-cd3d0eeb7...@u.washington.edu, Russell Owen ro...@u.washington.edu wrote: I installed the Mac binary on my Intel 10.5.6 system and it works, except it still uses Apple's system Tcl/Tk 8.4.7 instead of my ActiveState 8.4.19 (which is in /Library/Frameworks where one would expect). I just built python from source and that version does use ActiveState 8.4.19. I wish I knew what's going on. Not being able to use the binary distros is a bit of a pain. You're right, the tkinter included with the 2.6.2 installer is not linked properly: Is: $ cd /Library/Frameworks/Python.framework/Versions/2.6 $ cd lib/python2.6/lib-dynload $ otool -L _tkinter.so _tkinter.so: /System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl (compatibility version 8.4.0, current version 8.4.0) /System/Library/Frameworks/Tk.framework/Versions/8.4/Tk (compatibility version 8.4.0, current version 8.4.0) /usr/lib/libSystem.B.dylib [...] should be: _tkinter.so: /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl (compatibility version 8.4.0, current version 8.4.19) /Library/Frameworks/Tk.framework/Versions/8.4/Tk (compatibility version 8.4.0, current version 8.4.19) /usr/lib/libSystem.B.dylib [...] Just for the record, when I built Python 2.6 from source I got the latter output (the desired result). If someone can point me to instructions I'm willing to try to make a binary installer and make it available (though I'd much prefer to debug the standard installer). -- Russell ___ 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.6.2
Thank you for 2.6.2. I see the Mac binary installer isn't out yet (at least it is not listed on the downloads page). Any chance that it will be compatible with 3rd party Tcl/Tk? Most recent releases have not been; the only way I know to make a compatible build is to build the installer on a machine that already has a 3rd party Tcl/Tk installed; the resulting binary is then compatible with both 3rd party versions of Tcl/Tk and also with Apple's ancient built in version. -- Russell ___ 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 X Installer for 3.0.1 and supported versions
In article ad5bf985-3c9b-4d49-bfe6-0cff1b57a...@mac.com,
Ronald Oussoren ronaldousso...@mac.com wrote:
On 27 Feb, 2009, at 1:57, Ned Deily wrote:
In article rowen-8731e0.13531325022...@news.gmane.org,
Russell E. Owen ro...@u.washington.edu wrote:
I want to follow up on this a bit. In the past if the Mac Python
installer was built on a machine that did NOT have a locally
installed
Tcl/Tk then it would fail to work with a locally installed Tcl/Tk:
Python would segfault when trying to use Tkinter.
The solution was to build the Mac python installer on a machine
with a
locally installed Tcl/Tk. The resulting installer package would
work on
all systems -- with or without locally installed Tcl/Tk.
So...has this problem been worked around, or is the Mac installer
still
built on a machine that has a locally installed Tcl/Tk?
Ronald will have to answer that for sure since he built the installer
for 3.0.1.
However, it seems to be true that the most recent python.org OS X
installers will always favor a /System/Library/Frameworks/{Tcl/Tk}:
That's correct, I don't have a locally installed Tcl/Tk on my laptop
at the moment and couldn't arrange for one in time for the 3.0.1
release.
BTW. The fact that this should result in crashes when a user does have
a locally installed Tcl/Tk is new to me. The reason earlier builds of
the OSX installer were build with a locally installed Tcl/Tk is that
several Tkinter users indicated that the system version is
significantly less useful than a local install.
Any hope of an updated Mac installer for 2.5.4 and/or 2.6 that is built
with a locally installed Tcl/Tk? If/when you do that, I strongly
recommend ActiveState Tcl/Tk 8.4.19 -- the last 8.4 release -- it has
few bugs and very good performance.
(For Python 2.6 you could install Tcl/Tk 8.5 instead, but it might not
work for folks using Apple's built-in Tcl/Tk 8.4. Maybe somebody else
knows; if not it would require some testing.)
Note that even Python 2.5 built against Tcl/Tk 8.5 and most of it
worked, but there were some known bugs.
-- Russell
___
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 X Installer for 3.0.1 and supported versions
In article nad-34f90e.0314022...@news.gmane.org, Ned Deily n...@acm.org wrote: Speaking of an OS X installer for 3.0.1, over the last few weeks I have been working on tidying up the OS X installer build process. While the basic OS X build/installer process is good, some cruft has accumulated over the past years and a number of mostly minor issues arose due to the 3.x split. IMO, the most important issues were with IDLE and, thanks to Ronald, we did get the most important fixes for OS X IDLE checked-in in time for 3.0.1; they are also in py3k and will be going into trunk and 26. I have a few other fixes that apply just to the OSX build/installer parts which did not get submitted in time for the 3.0.1 cutoff but which are ready to go for 3.x and 2.x. Basically they fix some version number updating and ensure that the installer image will be built reproducibly in a clean environment so there is no contamination of the installer images. Currently, that's easy to do as happened with the first round of the OS X 2.6 installer (e.g. with a locally installed Tcl/Tk). I want to follow up on this a bit. In the past if the Mac Python installer was built on a machine that did NOT have a locally installed Tcl/Tk then it would fail to work with a locally installed Tcl/Tk: Python would segfault when trying to use Tkinter. The solution was to build the Mac python installer on a machine with a locally installed Tcl/Tk. The resulting installer package would work on all systems -- with or without locally installed Tcl/Tk. So...has this problem been worked around, or is the Mac installer still built on a machine that has a locally installed Tcl/Tk? I haven't run Python 2.6 yet because there is no release of numpy that is compatible. I did try upgrading from 2.5.2 to 2.5.4 and got a segfault when trying to display images using PIL and Tkinter; I have not had time to try to track that down, so I've just reverted for now. Most people who makes serious use of Tkinter presumably have a locally installed Tcl/Tk because the version that Apple provides is ancient and is missing many important bug fixes and performance enhancements. Also, a somewhat related issue: Tcl/Tk 8.4 is no longer maintained. All development work is going on in Tcl/Tk 8.5. Presumably Apple will transition one of these days, and at that point we may need a separate Mac Python installer for the older operating systems vs. the newer. -- Rusell ___ 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 3142: Add a while clause to generator expressions
In article pine.lnx.4.64.0901210811430.14...@kimball.webabinitio.net, rdmur...@bitdance.com wrote: ... I understand that you are saying that 'while x' is used in the same logical sense (take a different action when x is no longer true), but that I don't feel that that is enough to say that it has similar semantics. Or, perhaps more accurately, it is just similar enough to be very confusing because it is also different enough to be very surprising. The semantics of 'while' in python includes the bit about creating a loop, and does _not_ include executing a 'break' in the surrounding loop. To give 'while' this new meaning would be, IMO, un-pythonic. (If python had a 'for/while' construct, it would be a different story...and then it would probably already be part of the list comprehension syntax.) I agree. I feel that the term while is a poor choice for when this is no longer true then stop. It sounds more like a synonym for if to me. I would be much more comfortable using until (in the opposite sense to the proposed while); it clearly implies we're done so stop. I don't know if it's a feature that is really useful, but I do think it would be transparent: code that used it would be easily understood. -- Russell ___ 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] Fix python darwin build to look for non-framework Tk if not a framework build?
Python's own setup.py file seems to only look for a Framework Tcl/Tk on darwin. This is a headache if one is trying to build a non-framework python that uses a non-framework tcl/tk. Any chance of getting this fixed? I'm willing to work on a patch if it has any chance of being accepted. Any hints on how to determine if it is a framework build from within setup.py would be most welcome! -- Russell ___ 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] trunc()
In article [EMAIL PROTECTED], Martin v. Lowis [EMAIL PROTECTED] wrote: If the ambiguity is that 'int' behaviour is unspecified for floats - is it naive to suggest we specify the behaviour? The concern is that whatever gets specified is arbitrary. There are many ways how an int can be constructed from a float, so why is any such way better than the others, and deserves to be the meaning of int()? But something should be specified. Users should be able to expect consistent behavior. Surely there must be some efficiency reason why it is not specified (e.g. it uses a low-level C call that is not specified)??? I agree with the idea of putting trunc in the math library since it seems to similar to floor. -- Russell ___ 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] trunc()
In article [EMAIL PROTECTED], Paul Moore [EMAIL PROTECTED] wrote: On 24/01/2008, Jeffrey Yasskin [EMAIL PROTECTED] wrote: int has to be a builtin because it's a fundamental type. trunc() followed round() into the builtins. I have no opinion on whether ceil and floor should move there; it probably depends on how often they're used. Suggestion: - int() has to stay in builtins for obvious reasons. - put *all* of trunc, ceil, floor, round into math. - make int(float) an error I like all of your suggestions except the last one. Remember the problem with a/b depending on whether b happened to be a float or an int? I think you'll be creating a very similar problem here. In my opinion int(foo) should do its best to turn foo into an int with *predictable* behavior. The least surprising behavior for int(float) is probably trunc(float). Personally I prefer round(float), but I doubt it is worth breaking code and retraining everybody. -- Russell ___ 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-3000] Universal newlines support in Python 3.0
In article [EMAIL PROTECTED], Stephen J. Turnbull [EMAIL PROTECTED] wrote: Guido van Rossum writes: However, the old universal newlines feature also set an attibute named 'newlines' on the file object to a tuple of up to three elements giving the actual line endings that were observed on the file so far (\r, \n, or \r\n). This feature is not in PEP 3116, and it is not implemented. I'm tempted to kill it. Does anyone have a use case for this? I have run into files that intentionally have more than one newline convention used (mbox and Babyl mail folders, with messages received from various platforms). However, most of the time multiple newline conventions is a sign that the file is either corrupt or isn't text. If so, then saving the file may corrupt it. The newlines attribute could be used to check for this condition. There is at least one Mac source code editor (SubEthaEdit) that is all too happy to add one kind of newline to a file that started out with a different line ending character. As a result I have seen a fair number of text files with mixed line endings. I don't see as many these days, though; perhaps because the current version of SubEthaEdit handles things a bit better. So perhaps it won't matter much for Python 3000. -- Russell ___ 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] distutils patch
A colleague stumbled across distutils bug/misfeature that he found had been reported with an associated patch: http://sourceforge.net/tracker/index.php?func=detailaid=1183712group_i d=5470atid=305470 and I'm wondering if there's any plans to accept the patch or implement some other fix (such as raising an exception if one tries to use a blank package name). The current behavior is clearly unexpected and confusing. If there's something I can do to help get a fix of some kind into python 2.5, I'm happy to do it. Regards, -- Russell ___ 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] get for lists and tuples?
I'd like to have the get method available for lists and tuples. (I figured this must have been discussed before but can't recall it and didn't turn anything up on google). It's obviously not a use-all-the-time method (or it'd already be there), but I find myself wanting it often enough to justify it in my own mind (and curse this omission, relative to dict). Basically I run into it when parsing data of variable length (where the extra elements have some obvious default value), including config files, sys.argv (for simple command scripts), that sort of thing. Yes a 4-liner does the job, but get would be a much clearer way to write it. Anyway, I'm just testing the waters. If it's not heresy then I'd like to do what I can to make it happen. -- Russell ___ 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 3102: Keyword-only arguments
In article [EMAIL PROTECTED], Guido van Rossum [EMAIL PROTECTED] wrote: On 5/2/06, Greg Ewing [EMAIL PROTECTED] wrote: Terry Reedy wrote: my way to call your example (given the data in separate variables): make_person(name, age, phone, location) your way: make_person(name=name, age=age, phone=phone, location = location) For situations like that, I've sometimes thought it would be useful to be able to say something like make_person(=name, =age, =phone, =location) And even with Terry's use case quoted I can't make out what you meant that to do. I'm pretty sure he wants it to mean: make_person(name=name, age=age, phone=phone, location=location). In other words it's a shortcut to avoid needless repetition. Personally I'd like some way to do that, but the initial = is pretty startling at first glance. Not that I have a better suggestion. As far as the rest of the thread goes (and I may be late to the party on this), I personally would *love* to be able to write: def func(arg0, arg1, *args, key1=def1) and force key1 to be specified by name. I've coded this before using **kargs for the keyword-only args, but I'd much rather be able to list them in the def (making it more self-documenting). But that's as far as I'd take it. I don't see the point to keyword-only arguments that do not have default values. And I don't think it's worth the potential confusion to allow keyword-only args after a fixed # of positional args. The proposed syntax reads like exactly the wrong thing to me; | as a separator might do if one is desperate enough for this feature, i.e.: def foo(arg0, arg1 | karg=None): -- Russell ___ 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 359: The make Statement
At some point folks were discussing use cases of make where it was important to preserve the order in which items were added to the namespace. I'd like to suggest adding an implementation of an ordered dictionary to standard python (e.g. as a library or built in type). It's inherently useful, and in this case it could be used by make. -- Russell ___ 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 Library Reference top page too long
In article [EMAIL PROTECTED], Georg Brandl [EMAIL PROTECTED] wrote: Another thing that would be *really* useful is to list the actual built-in types with the category. For example: Sequence Types (str, unicode, list, tuple, buffer, xrange) Mapping Types (dict) +1 If I understand correctly what you mean, that's already done. You're right! I was using a local copy of 2.4.0 documentation and it did not have this feature. -- Russell ___ 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] Py3k: Except clause syntax
In article [EMAIL PROTECTED], Greg Ewing [EMAIL PROTECTED] wrote: For Py3k, any thoughts on changing the syntax of the except clause from except type, value: to except type as value: so that things like except TypeError, ValueError: will do what is expected? Brilliant. I may be showing my clumsiness, but I catch multiple exceptions so rarely that I often stumble over this. -- Russell ___ 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 3000 and new style classes
In article [EMAIL PROTECTED], Tristan Seligmann [EMAIL PROTECTED] wrote: * Lisandro Dalcin [EMAIL PROTECTED] [2005-09-08 13:56:07 -0300]: Yes, you are right. But this way, you are making explicit a behavior that will be implicit in the future. For example, we could also do: two = float(4)/float(2) instead of from future import division two = 4/2 Why does it matter if the single statement you insert is spelled metaclass = type instead of from future import whatever? Remember, unlike the division example, you would only have to insert one statement, as opposed to changing every use of integer division. It matters because metaclass = type is completely obscure. How would any non-expert have a clue what it means? -- Russell ___ 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, take 2: Exception Reorganization for Python 3.0
In article [EMAIL PROTECTED], Brett Cannon [EMAIL PROTECTED] wrote: New Hierarchy = Exception +-- CriticalException (new) +-- KeyboardInterrupt +-- MemoryError +-- SystemError +-- ControlFlowException (new) +-- StopIteration +-- GeneratorExit +-- SystemExit +-- StandardError +-- AssertionError +-- SyntaxError +-- IndentationError +-- TabError +-- UserException (rename of RuntimeError) +-- ArithmeticError +-- FloatingPointError +-- DivideByZeroError +-- OverflowError +-- UnicodeError +-- UnicodeDecodeError +-- UnicodeEncodeError +-- UnicodeTranslateError +-- LookupError +-- IndexError +-- KeyError +-- TypeError +-- AttributeError +-- EnvironmentError +-- OSError +-- IOError +-- EOFError (new inheritance) +-- ImportError +-- NotImplementedError (new inheritance) +-- NamespaceError (rename of NameError) +-- UnboundGlobalError (new) +-- UnboundLocalError +-- UnboundFreeError (new) +-- WeakReferenceError (rename of ReferenceError) +-- ValueError +-- Warning +-- UserWarning +-- AnyDeprecationWarning (new) +-- PendingDeprecationWarning +-- DeprecationWarning +-- SyntaxWarning +-- SemanticsWarning (rename of RuntimeWarning) +-- FutureWarning I am wondering why OSError and IOError are not under StandardError? This seems a serious misfeature to me (perhaps the posting was just misformatted?). Having one class for normal errors (not exceptions whose sole purpose is to halt the program and not so critical that any continuation is hopeless) sure would make it easier to write code that output a traceback and tried to continue. I'd love it. -- Russell ___ 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 343 - next steps
In article [EMAIL PROTECTED], Guido van Rossum [EMAIL PROTECTED] wrote: ... - Whether and how to keep a door open for a future extension to the syntax that allows multiple resources to be acquired in a single with-statement. Possible syntax could be (a)with EXPR1 [as VAR1], EXPR2 [as VAR2], EXPR3 [as VAR3], ...: or (b)with EXPR1, EXPR2, EXPR3, ... as VAR1, VAR2, VAR3, ...: Variant (a) seems better and is more analogous to the use of 'as' in import statements, and (b) has the disadvantage that if you want to acquire several resources and not all of them have an associated variable, you'll have to sprinkle dummy variables on the right of 'as'. So (a) would have my preference. But I would still like to start off without this extension. The issue is: if we allow VAR to be a comma-separated list of variables now, that cuts off the extension to (a) in the future; so the PEP would have to be amended to state that VAR must be a single variable or a list of variables IN PARENTHESES. Thoughts? I agree that (a) sounds better. Also, I think it is very reasonable to require that multiple variables be in parenthesis. You can always lift the restriction later (i.e. if enough folks complain and you decide never to implement (a)), but you can't add such a restriction later. One nit-pick: I suggest not using the term list of anything in parenthesis in the PEP or other docs. It's clear here but may add to some people's list vs tuple confusion. -- Russell ___ 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 343 - Abstract Block Redux
In article [EMAIL PROTECTED], Phillip J. Eby [EMAIL PROTECTED] wrote: ... I personally think that StopIteration, TerminateIteration, KeyboardInterrupt and perhaps certain other exceptions should derive from some base class other than Exception (e.g. Raisable or some such) to help with the bare-except/except Exception problem. But that's probably best addressed by a separate PEP. :) Yes, please!!! I am so sick of writing: except (SystemExit, KeyboardInterrupt): raise except Exception, e: # handle a real error but back to lurking on this discussion... -- Russell ___ 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] Pre-PEP: Unifying try-except and try-finally
In article [EMAIL PROTECTED], Timothy Fitz [EMAIL PROTECTED] wrote: No, as except clauses can only occur before the finally clause, and execution should not go backwards. This restriction feels a bit arbitrary. I can guarantee someone is going to flatten this: try: try: A finally: B except IOError: C A more flexible approach would be to allow finally at the beginning or ending of the try statement. A more flexible approach would be to allow both, or even finally clauses mixed in. To me, that's the ugly portion of this proposal, it's quite arbitrary. And the alternatives I posted have their own brands of ugly. I strongly disagree. It makes sense to me, anyway, that finally can only be the final clause and that it always does exactly what it says: execute as the final bit of the try statement. I think this would be a useful enhancement. It simplifies the published documentation a bit (no need to document try/except as a separate entity from try/finally) and I have plenty of cases where I'd like to take advantage of it. Concisely, this is an arbitrary shortcut for an idiom that already exists. It seems to me that this shortcut would be redundant if PEP 340 or something with similar functionality was accepted. I do see your point here and I'll be curious to see how this shapes up (given the lengthy discussion going on about this tricky proposal). But I also feel that the unification of try/except and try/finally is truly an improvement to the language. To me it feels like a simplification -- it removes an artificial, annoying and unnecessary split. -- Russell ___ 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
