Re: [Python-Dev] PEP 3147: PYC Repository Directories
2010/1/31 Georg Brandl g.bra...@gmx.net: foo.py foo.pyr/ cpython-25.pyc cpython-25U.pyc cpython-27.pyc cpython-27U.pyc cpython-32.pyc unladen-011.pyc wpython-11.pyc +1. It should be quite easy to assign a new name every time the magic number is updated. If we don't change the bytecode for a given Python version, then the name of the bytecode format used wouldn't change either. That would be the only remaining complaint for casual users. (Why doesn't Python compile my file for 2.8?) I think it's preferable to have a redundant copy of the compiled file floating around rather than creating confusion as to which one each python interpreter uses. Optimizing disk space (and marginal compile time) is not worth the mental overhead this would introduce. Better keep it as clear and simple as possible, i.e. create different .pyc files even if the bytecode doesn't change between releases. Vitor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147: PYC Repository Directories
2010/1/31 Nick Coghlan ncogh...@gmail.com: Georg Brandl wrote: Then why did Subversion choose to follow the CVS way and create a subdirectory in each versioned directory? IMO, this is much more annoying given the alternative of a single .hg/.bzr/whatever directory. For .pyc vs .pyr, you didn't have the alternative of putting all that stuff in one directory now. I actually like the svn/cvs way, since each directory in the working copy is self-contained. The DVCS way means that you can't tell just by looking at a directory whether it is part of a working copy or not - there is a non-local element affecting you at a higher point in the filesystem hierarchy. Exactly. How would you define where the pyr folder goes? At the root of a package? What if I delete the __init__.py file there? Will the existing pyr folder be orphaned and a new one created in each subfolder? Unlike VCS working copies, the package / module / script hierarchy is not formally defined in python. Having one single pyr (or__pycache__ or whatever it's called) subfolder per folder is an easy to understand, solid solution. I'm also in favor of making this folder non-hidden. Unlike a .git or.hg folder, it impacts the code execution itself. Think of the newbies! .pyc files already lead to heisenbugs for inexperienced developers (e.g. importing a lingering pyc instead of an intended module with the same name further down sys.path), and they're in plain sight. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147: PYC Repository Directories
2010/1/30 Barry Warsaw ba...@python.org: Multiple file extensions The PEP author also considered an approach where multiple thin byte compiled files lived in the same place, but used different file extensions to designate the Python version. E.g. foo.pyc25, foo.pyc26, foo.pyc31 etc. This was rejected because of the clutter involved in writing so many different files. The multiple extension approach makes it more difficult (and an ongoing task) to update any tools that are dependent on the file extension. Why not: foo.py foo.pyc # 2.7 or 3.2 foo.27.pyc foo.32.pyc etc. This is simpler and more logical than the current subfolder proposal, as it is clear which version each file corresponds to. Python can use all the magic values it wants, but please don't spill them over into the filesystem. Readability counts. Putting the files into a separate dir also makes it much harder to work with external tools; e.g. VCSes already ignore .pyc and .pyo files, but not unknown directories. I'd rather have a folder cluttered with files I know I can ignore (and can easily run a selective rm over) than one that is cluttered with subfolders. Vitor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147: PYC Repository Directories
2010/1/31 Nick Coghlan ncogh...@gmail.com: Vitor Bosshard wrote: Why not: foo.py foo.pyc # 2.7 or 3.2 foo.27.pyc foo.32.pyc etc. This is simpler and more logical than the current subfolder proposal, as it is clear which version each file corresponds to. Python can use all the magic values it wants, but please don't spill them over into the filesystem. Readability counts. There is no one-to-one correspondence between Python version and pyc magic numbers. Different runtime options may change the magic number and different versions may reuse a magic number Good point. Runtime options would need to change the version (e.g. foo.25U.py), and versions that reuse magic numbers would be redundantly written to disk. However, the underlying issue as I see it is that the magic value is an implementation detail that should not be exposed. Putting the files into a separate dir also makes it much harder to work with external tools; e.g. VCSes already ignore .pyc and .pyo files, but not unknown directories. I'd rather have a folder cluttered with files I know I can ignore (and can easily run a selective rm over) than one that is cluttered with subfolders. It won't be cluttered with subfolders - you will have at most one .pyr per source .py file. Even more conveniently, many file browsers already list subfolders and files separately, so if you never run a version of Python that uses the old .pyc format you won't even get that level of clutter. Since those folders would start with arbitrary characters, they'd be intermingled with real subfolders, which is a terrible mess. At least the current .pyc files are always clustered nicely right next to their source file. That is significantly better than accumulating an unbounded number of different .pyc files interspersed amongst the actual source files I care about. I do see your point. How about creating a single pyr folder, in which *all* compiled files of the parent folder go, e.g. pyr/foo.0c4f0a0d.pyc Vitor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3147: PYC Repository Directories
2010/1/31 Nick Coghlan ncogh...@gmail.com: Can't a VCS be configured to ignore a .pyr directory just as easily as it can be configured to ignore a .pyc file? Yes they can. Of course they can, but not out of the box. It was just an example off the top of my head. A trickier case: My GUI app offers scripting facilities. The associated open file dialog hides all .pyc files, and users select just from .py files. if subfolders are introduced, however, they can't be hidden away as easily. Filtering by extension is standard functionality in all GUI toolkits. Hiding a fraction of subfolders is not. The point is that creating large amounts of subfolders goes against the expectations that python (and pretty much any other program for that matter) has established. If it's possible to keep in line with those expectations, it should at least be considered, given that existing programs could continue to work without needing to change anything. If the decision is made that folders will be used (for x y z reason), then great care should be taken to make the change as minimally invasive as possible. Vitor ___ 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] Retrieve an arbitrary element from a set without removing it
2009/10/23 Willi Richert w.rich...@gmx.net: Hi, recently I wrote an algorithm, in which very often I had to get an arbitrary element from a set without removing it. Three possibilities came to mind: 1. x = some_set.pop() some_set.add(x) 2. for x in some_set: break 3. x = iter(some_set).next() Of course, the third should be the fastest. It nevertheless goes through all the iterator creation stuff, which costs some time. I wondered, why the builtin set does not provide a more direct and efficient way for retrieving some element without removing it. Is there any reason for this? I imagine something like x = some_set.get() I see this as being useful for frozensets as well, where you can't get an arbitrary element easily due to the obvious lack of .pop(). I ran into this recently, when I had a frozenset that I knew had 1 element (it was the difference between 2 other sets), but couldn't get to that element easily (get the pun?) ___ 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
- Mensaje original De: Gerald Britton gerald.brit...@gmail.com Para: rdmur...@bitdance.com CC: python-dev@python.org Enviado: miércoles, 21 de enero, 2009 11:38:01 Asunto: Re: [Python-Dev] PEP 3142: Add a while clause to generator expressions FWIW, there are a few historic languages that implement a compound for-loop: Algol 68, PL/I, SAS et al allow constructs that, if translated to an equivalent (currently invalid) Python-style syntax would look like this for item in iterable while predicate: suite Some also allow for an until keyword. I'm not suggesting that we need to do this in Python; it's just interesting to note that there is some precedent for this approach. Well, you could propose changing the for loop syntax (and by extension comprehensions and generators). It's a much more radical proposal, but it does keep consistency across the board, which is one of the major flaws of the PEP in its current form. BTW, there is already an until keyword in python, it's called while not ;) Vitor ¡Todo sobre la Liga Mexicana de fútbol! Estadisticas, resultados, calendario, fotos y más:lt; http://espanol.sports.yahoo.com/ ___ 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
- Mensaje original De: Gerald Britton gerald.brit...@gmail.com Para: Vitor Bosshard algor...@yahoo.com CC: python-3...@udmvt.ru; python-dev@python.org Enviado: martes, 20 de enero, 2009 13:40:07 Asunto: Re: [Python-Dev] PEP 3142: Add a while clause to generator expressions Right, but the PEP is only about generator expressions. Yes, but consistency with list comprehensions would be a nice thing to have, which is absent from both the or raise() idiom and the takewhile one (which is, by definition, a generator). The new syntax wouldn't have this issue. I'm not in favor of the change, just pointing this out. Vitor ¡Todo sobre la Liga Mexicana de fútbol! Estadisticas, resultados, calendario, fotos y más:lt; http://espanol.sports.yahoo.com/ ___ 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
- Mensaje original De: Gerald Britton gerald.brit...@gmail.com Para: Terry Reedy tjre...@udel.edu CC: python-dev@python.org Enviado: lunes, 19 de enero, 2009 15:03:47 Asunto: Re: [Python-Dev] PEP 3142: Add a while clause to generator expressions Duly noted and thanks for the feedback! (just what I was looking for actually). I do disagree with the idea that the proposal, if implemented, would make Python harder to learn. Not sure who would find it harder. Having to find and use takewhile was harder for me. I still find that one counter-intuitive. I would have expected the parameters in the reverse order (take something, while something else is true). Tripped me up a few times, which got me thinking about an alternative. Are you even sure the list comprehension doesn't already shortcut evaluation? This quick test in 2.6 hints otherwise: a = (i for i in range(10) if i**210) a.next() 0 a.next() 1 a.next() 2 a.next() 3 a.next() Traceback (most recent call last): File pyshell#32, line 1, in module a.next() StopIteration ¡Todo sobre la Liga Mexicana de fútbol! Estadisticas, resultados, calendario, fotos y más:lt; http://espanol.sports.yahoo.com/ ___ 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] if-syntax for regular for-loops
- Mensaje original De: Leif Walsh [EMAIL PROTECTED] Para: Andreas Nilsson [EMAIL PROTECTED] CC: python-dev@python.org Enviado: viernes, 3 de octubre, 2008 10:29:33 Asunto: Re: [Python-Dev] if-syntax for regular for-loops On Fri, Oct 3, 2008 at 6:10 AM, Andreas Nilsson wrote: With that out of the way, on to todays subject: I use list comprehensions and generator expressions a lot and lately I've found myself writing a lot of code like this: for i in items if i.some_field == some_value: i.do_something() Naturally it won't work but it seems like a pretty straight-forward extension to allow compressing simple loops to fit on one line. The alternative, in my eyes, suggests there's something more happening than a simple include-test which makes it harder to comprehend. for i in items: if i.some_field == some_value: i.do_something() One possibility of course is to use a generator-expression but that makes it look like there are two for loops and it feels like a waste setting up a generator just for filtering. for i in (i for i in items if some_field == some_value): i.do_something() Stupid idea? Am I missing some obviously better way of achieving the same result? It's been discussed already. Essentially, all that saves is a newline or two, which, as I think has been generally accepted, tends to hurt readability. The exact same argument could be used for list comprehensions themselves. They exist anyway, creating inconsistency in the language (being almost identical to for loops regarding syntax) Vitor Premios MTV 2008¡En exclusiva! Fotos, nominados, videos, y mucho más! Mira aquí http://mtvla.yahoo.com/ ___ 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
