Greg Ewing wrote:
Barry Warsaw wrote:
I'm not sure I like ~/.local though
- -- it seems counter to the app-specific dot-file approach old
schoolers like me are used to.
Problems with that are starting to show, though.
There's a particular Unix account that I've had for
quite a number
Barry Warsaw wrote:
On the easy_install naming front, how about layegg?
I think I once proposed hatch but that may not be quite the right
word (where's Ken M when you need him? :).
I really don't like all these cute names, simply because they are
obscure. Names that only make sense once
On Thursday, November 30, 2006, at 03:49PM, Talin [EMAIL PROTECTED] wrote:
Barry Warsaw wrote:
On the easy_install naming front, how about layegg?
I think I once proposed hatch but that may not be quite the right
word (where's Ken M when you need him? :).
I really don't like all these
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 30, 2006, at 9:40 AM, Talin wrote:
Greg Ewing wrote:
Barry Warsaw wrote:
I'm not sure I like ~/.local though - -- it seems counter to the
app-specific dot-file approach old schoolers like me are used to.
Problems with that are
Perhaps pyinstall?
Bill
On Nov 30, 2006, at 9:49 AM, Talin wrote:
I really don't like all these cute names, simply because they are
obscure. Names that only make sense once you've gotten the joke may
be self-gratifying but not good HCI.
Warsaw's Fifth Law :)
How about:
I've got a small tweak to tokenize.py that I'd like to run by folks here.
I'm working on a refactoring tool for Python 2.x-to-3.x conversion,
and my approach is to build a full parse tree with annotations that
show where the whitespace and comments go. I use the tokenize module
to scan the input.
On 05:37 pm, [EMAIL PROTECTED] wrote:
Perhaps pyinstall?
Keep in mind that Python packages will still generally be *system*-installed
with other tools, like dpkg (or apt) and rpm, on systems which have them. The
name of the packaging system we're talking about is called either eggs or
At 09:49 AM 11/30/2006 -0800, Guido van Rossum wrote:
I've got a small tweak to tokenize.py that I'd like to run by folks here.
I'm working on a refactoring tool for Python 2.x-to-3.x conversion,
and my approach is to build a full parse tree with annotations that
show where the whitespace and
Are you opposed changing tokenize? If so, why (apart from
compatibility)? ISTM that it would be a good thing if it reported
everything except horizontal whitespace.
On 11/30/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:49 AM 11/30/2006 -0800, Guido van Rossum wrote:
I've got a small tweak
At 10:28 AM 11/30/2006 -0800, Guido van Rossum wrote:
Are you opposed changing tokenize? If so, why (apart from
compatibility)?
Nothing apart from compatibility. I think you should have to explicitly
request the new behavior(s), since tools (like detokenize) written to work
around the old
It would be trivial to add another yield to tokenize.py when
the backslah is detected
+1
I think that it should probably yield a single NL pseudo-token
whose value is a backslash followed by a newline; or perhaps it
should yield the backslash as a comment token, or as a new token.
The
Op woensdag 29-11-2006 om 12:23 uur [tijdzone +0100], schreef Armin
Rigo:
I could not agree more. Nowadays, whenever I get an account on a new
Linux machine, the first thing I have to do is reinstall Python
correctly in my home dir because the system Python lacks distutils.
Wasteful. (There
On 11/30/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:28 AM 11/30/2006 -0800, Guido van Rossum wrote:
Are you opposed changing tokenize? If so, why (apart from
compatibility)?
Nothing apart from compatibility. I think you should have to explicitly
request the new behavior(s), since
Jan Claeys wrote:
Op woensdag 29-11-2006 om 12:23 uur [tijdzone +0100], schreef Armin
Rigo:
I could not agree more. Nowadays, whenever I get an account on a new
Linux machine, the first thing I have to do is reinstall Python
correctly in my home dir because the system Python lacks distutils.
On 11/30/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Are you opposed changing tokenize? If so, why (apart from
compatibility)? ISTM that it would be a good thing if it reported
everything except horizontal whitespace.
it would be a good thing if it could,
On 11/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
The major advantage ~/.local has for *nix systems is the ability to have a
parallel *bin* directory, which provides the user one location to set their
$PATH to, so that installed scripts work as expected, rather than having to
edit a
At 02:46 PM 11/30/2006 -0800, Mike Orr wrote:
Speaking of Virtual Python [1], I've heard some people recommending it
as a general solution to the this library breaks that other
application problem and this app needs a different version of X
library than that other app does.
It was actually
Op donderdag 30-11-2006 om 21:48 uur [tijdzone +], schreef Steve
Holden:
I think the point is that some distros (Debian is the one that springs
to mind most readily, but I'm not a distro archivist) require a separate
install for distutils even though it's been a part of the standard
Barry Warsaw wrote:
When I switched to OS X for most of my desktops, I had several
collisions in this namespace.
I think on MacOSX you have to consider that it's really
~/Documents and the like that are *your* namespaces,
rather than the top level of your home directory.
Also, I think
Op vrijdag 01-12-2006 om 12:44 uur [tijdzone +1300], schreef Greg Ewing:
With ~/.local, you're hiding the fact that the applications
or libraries or whatever are even there in the first
place. You've got all this disk space being used up,
but no way of seeing where or by what, and no
obvious
Jan Claeys wrote:
[...]
Probably the Debian maintainers could have named packages differently to
make things less confusing for newbies (e.g. by having the 'pythonX.Y'
packages being meta-packages that depend on all binary packages built
from the upstream source package), but that doesn't mean
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 30, 2006, at 6:44 PM, Greg Ewing wrote:
Barry Warsaw wrote:
When I switched to OS X for most of my desktops, I had several
collisions in this namespace.
I think on MacOSX you have to consider that it's really
~/Documents and the like
Hello,
I spent my last couple of hourse reading several past threads about fpectl. If
I'm correct
1) fpectl is scheduled for deletion in 2.6.
2) The biggest problem is that the C standard says that it's undefined to
return from a SIGFPE handler. Thus, it's impossible to traps floating point
Patch / Bug Summary
___
Patches : 407 open ( +1) / 3484 closed ( +5) / 3891 total ( +6)
Bugs: 936 open ( +5) / 6363 closed (+14) / 7299 total (+19)
RFE : 246 open ( +1) / 244 closed ( +0) / 490 total ( +1)
New / Reopened Patches
__
sys.id()
On Fri, Dec 01, 2006 at 12:42:42AM +0100, Jan Claeys wrote:
Op donderdag 30-11-2006 om 21:48 uur [tijdzone +], schreef Steve
Holden:
I think the point is that some distros (Debian is the one that springs
to mind most readily, but I'm not a distro archivist) require a separate
install
25 matches
Mail list logo
