Re: [Python-Dev] PEP 3147: PYC Repository Directories

I like the idea of the PEP. On the other hand, I dislike using directories for it. Others have explained enough reasons for why creating many directories is a bad idea; and there may be other reasons (file-system limits for number of directories, problems when the directories are located on the ne

Re: [Python-Dev] PEP 3147: PYC Repository Directories

Ben Finney wrote: > Nick Coghlan writes: > >> It won't be cluttered with subfolders - you will have at most one .pyr >> per source .py file. > > If that doesn't meet your threshold of “cluttered with subfolders”, I'm > at a loss for words to think where that threshold might be. It meets, > and e

Re: [Python-Dev] PEP 3147: PYC Repository Directories

Vitor Bosshard wrote: >> 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.

Re: [Python-Dev] PEP 3147: PYC Repository Directories

Ben Finney wrote: > Could we instead have a single subdirectory for each tree of module > packages, keeping them tidily out of the way of the source files, while > making them located just as deterministically:: Not easily. With the scheme currently proposed in the PEP, setting a value for __file_

Re: [Python-Dev] PEP 3147: PYC Repository Directories

On Sat, 30 Jan 2010 20:37:32 -0800, Jeffrey Yasskin wrote: > On Sat, Jan 30, 2010 at 8:22 PM, Vitor Bosshard wrote: > > 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 in

Re: [Python-Dev] PEP 3147: PYC Repository Directories

On Sat, 30 Jan 2010 19:00:05 -0500, Barry Warsaw wrote: > Linux distributions such as Ubuntu [2]_ and Debian [3]_ provide more > than one Python version at the same time to their users. For example, > Ubuntu 9.10 Karmic Koala can install Python 2.5, 2.6, and 3.1, with > Python 2.6 being the defau

Re: [Python-Dev] PEP 3147: PYC Repository Directories

+1 overall. I'm certainly not concerned with replacing pyc clutter with pyr clutter. I do like that you haven't _increased_ the number of extraneous siblings of .py files. I have a couple bikesheddy or "why didn't you do this" comments. I'll be perfectly satisfied with an answer or a line in the p

Re: [Python-Dev] PEP 3147: PYC Repository Directories

On Sat, Jan 30, 2010 at 8:22 PM, Vitor Bosshard wrote: > 2010/1/31 Nick Coghlan : > >>> 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 exampl

Re: [Python-Dev] PEP 3147: PYC Repository Directories

2010/1/31 Nick Coghlan : >> 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 scrip

Re: [Python-Dev] PEP 3147: PYC Repository Directories

Nick Coghlan writes: > It won't be cluttered with subfolders - you will have at most one .pyr > per source .py file. If that doesn't meet your threshold of “cluttered with subfolders”, I'm at a loss for words to think where that threshold might be. It meets, and exceeds by a long shot, my thresh

Re: [Python-Dev] PEP 3147: PYC Repository Directories

Nick Coghlan writes: > This is also the reason why using the version number in the filename > isn't adequate - the magic number can change due to more than just the > Python version changing. Also, if we don't change the bytecode for a > given release, then multiple versions can use the same magi

Re: [Python-Dev] PEP 3147: PYC Repository Directories

2010/1/31 Nick Coghlan : > 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 th

Re: [Python-Dev] PEP 3147: PYC Repository Directories

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

Re: [Python-Dev] PEP 3147: PYC Repository Directories

Daniel Stutzbach wrote: > On Sat, Jan 30, 2010 at 8:21 PM, Vitor Bosshard > wrote: > > 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

Re: [Python-Dev] PEP 3147: PYC Repository Directories

MRAB wrote: > One thing that puzzles me is that the PEP shows that "Python -U" has a > different magic number from "Python", but I can't find any reference to > "-U" (the options appear to be case-sensitive, so presumably it's not > the same as "-u"). We deliberate don't document -U because its ty

Re: [Python-Dev] PEP 3147: PYC Repository Directories

Ben Finney wrote: Vitor Bosshard writes: 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 spil

Re: [Python-Dev] PEP 3147: PYC Repository Directories

On Sat, Jan 30, 2010 at 8:21 PM, Vitor Bosshard wrote: > 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. > Can't a VCS be configured to ignore a .pyr directory just as eas

Re: [Python-Dev] PEP 3147: PYC Repository Directories

Vitor Bosshard writes: > 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 t

Re: [Python-Dev] PEP 3147: PYC Repository Directories

2010/1/30 Barry Warsaw : > > 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.

[Python-Dev] PEP 3147: PYC Repository Directories

PEP: 3147 Title: PYC Repository Directories Version: $Revision$ Last-Modified: $Date$ Author: Barry Warsaw Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2009-12-16 Python-Version: 3.2 Post-History: Abstract This PEP describes an extension to Python's import mech

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Fri, Jan 29, 2010 at 15:04, wrote: > On 10:47 pm, tjre...@udel.edu wrote: >> >> On 1/29/2010 4:19 PM, Collin Winter wrote: >>> >>> On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan wrote: >> >>> Agreed. We originally switched Unladen Swallow to wordcode in our >>> 2009Q1 release, and saw a perform

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

On Fri, Jan 29, 2010 at 12:48 AM, Terry Reedy wrote: > On 1/28/2010 6:30 PM, Josiah Carlson wrote: > >> I would also point out that the way these things are typically done is >> that programmers/engineers have use-cases that are not satisfied by >> existing structures, they explain the issues they

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

I'm back with some tests that I made with the U-S test suite. 2010/1/30 Scott Dial > > Cesare, just FYI, your Hg repository has lost the execute bits on some > files (namely "./configure" and "./Parser/asdl_c.py"), so it does not > quite build out-of-the-box. > Unfortunately, I haven't found a

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

--- On Fri, 1/29/10, Stephen J. Turnbull wrote: > > > Lisp lists are really stacks > > No, they're really (ie, concretely) singly-linked > lists.  > > Now, stacks are an abstract data type, and singly-linked > lists provide > an efficient implementation of stacks.  But that's not > what link

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

Minor erratum: Stephen J. Turnbull writes: > Emacs hasn't made that choice, XEmacs did. I believe Emacs is still > "restricted" to 128MB, or maybe 256MB, buffers. They recently had an > opportunity to increase integer size, and thus maximum buffer size, > but refused it. It's not a no-brai

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 29 January 2010 23:45, "Martin v. Löwis" wrote: >> On Windows, would a C extension author be able to distribute a single >> binary (bdist_wininst/bdist_msi) which would be compatible with >> with-LLVM and without-LLVM builds of Python? > > When PEP 384 gets implemented, you not only get that, b

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

Josiah Carlson writes: > On Fri, Jan 29, 2010 at 11:31 PM, Stephen J. Turnbull > wrote: > > Some people complained, but we considered this well worthwhile (moving > > one "type bit" from the car to the header allowed Lisp integers to > > cover the range -1G to +1G, and there are a surprising

Re: [Python-Dev] Forking and Multithreading - enemy brothers

/[...] What dangers do you refer to specifically? Something reproducible? -L / Since it's a race condition issue, it's not easily reproducible with normal libraries - which only take threading locks for small moments. But it can appear if your threads make good use of the threading module. By

Re: [Python-Dev] Forking and Multithreading - enemy brothers

/[...] What dangers do you refer to specifically? Something reproducible? -L / Since it's a race condition issue, it's not easily reproducible with normal libraries - which only take threading locks for small moments. But it can appear if your threads make good use of the threading module. By

Re: [Python-Dev] Forking and Multithreading - enemy brothers

From: Stefan Behnel To: python-dev@python.org Subject: Re: [Python-Dev] Forking and Multithreading - enemy brothers Message-ID: Content-Type: text/plain; charset=ISO-8859-15 Pascal Chambon, 29.01.2010 22:58: I've just recently realized the huge problems surrounding the mix of multithreading an

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

On Fri, Jan 29, 2010 at 11:31 PM, Stephen J. Turnbull wrote: > Josiah Carlson writes: >  > On Thu, Jan 28, 2010 at 8:57 PM, Steve Howell wrote: > >  > > What do you think of LISP, and "car" in particular (apart from >  > > the stupidly cryptic name)? > >  > Apples and oranges. > > True, but speak

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

On Fri, Jan 29, 2010 at 11:25 PM, Stephen J. Turnbull wrote: > Josiah Carlson writes: > >  > Lisp lists are really stacks > > No, they're really (ie, concretely) singly-linked lists. > > Now, stacks are an abstract data type, and singly-linked lists provide > an efficient implementation of stacks.