On Fri, Jan 29, 2010 at 11:25 PM, Stephen J. Turnbull
step...@xemacs.org 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
On Fri, Jan 29, 2010 at 11:31 PM, Stephen J. Turnbull
step...@xemacs.org wrote:
Josiah Carlson writes:
On Thu, Jan 28, 2010 at 8:57 PM, Steve Howell showel...@yahoo.com wrote:
What do you think of LISP, and car in particular (apart from
the stupidly cryptic name)?
Apples and
From: Stefan Behnel stefan...@behnel.de
To: python-dev@python.org
Subject: Re: [Python-Dev] Forking and Multithreading - enemy brothers
Message-ID: hk0k0q$7i...@ger.gmane.org
Content-Type: text/plain; charset=ISO-8859-15
Pascal Chambon, 29.01.2010 22:58:
I've just recently realized the huge
/[...]
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.
/[...]
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.
Josiah Carlson writes:
On Fri, Jan 29, 2010 at 11:31 PM, Stephen J. Turnbull
step...@xemacs.org 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
On 29 January 2010 23:45, Martin v. Löwis mar...@v.loewis.de 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
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-brainer.
--- On Fri, 1/29/10, Stephen J. Turnbull step...@xemacs.org 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
I'm back with some tests that I made with the U-S test suite.
2010/1/30 Scott Dial
scott+python-...@scottdial.comscott%2bpython-...@scottdial.com
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
On Fri, Jan 29, 2010 at 12:48 AM, Terry Reedy tjre...@udel.edu 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
On Fri, Jan 29, 2010 at 15:04, exar...@twistedmatrix.com 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 Coghlanncogh...@gmail.com wrote:
Agreed. We originally switched Unladen Swallow to wordcode in our
2009Q1
PEP: 3147
Title: PYC Repository Directories
Version: $Revision$
Last-Modified: $Date$
Author: Barry Warsaw ba...@python.org
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
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,
Vitor Bosshard algor...@gmail.com 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
On Sat, Jan 30, 2010 at 8:21 PM, Vitor Bosshard algor...@gmail.com 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
Ben Finney wrote:
Vitor Bosshard algor...@gmail.com 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
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 typical
Daniel Stutzbach wrote:
On Sat, Jan 30, 2010 at 8:21 PM, Vitor Bosshard algor...@gmail.com
mailto:algor...@gmail.com 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
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
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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
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
On Sat, Jan 30, 2010 at 8:22 PM, Vitor Bosshard algor...@gmail.com wrote:
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.
+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
On Sat, 30 Jan 2010 19:00:05 -0500, Barry Warsaw ba...@python.org 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
On Sat, 30 Jan 2010 20:37:32 -0800, Jeffrey Yasskin jyass...@gmail.com wrote:
On Sat, Jan 30, 2010 at 8:22 PM, Vitor Bosshard algor...@gmail.com wrote:
A trickier case: My GUI app offers scripting facilities. The
associated open file dialog hides all .pyc files, and users select
just from
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__
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.py), and
Ben Finney wrote:
Nick Coghlan ncogh...@gmail.com 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
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
32 matches
Mail list logo
