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
> >
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()
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
ex
-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
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 m
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
> obvi
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 MacO
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
>
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
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
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
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 dis
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),
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. (The
> 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.
Th
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 beh
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, optionally, be made to report
horizontal whitespace as well.
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 tw
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
At 06:02 PM 11/30/2006 +, [EMAIL PROTECTED] wrote:
>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 packag
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
"se
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.
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 :)
>
> > H
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 :)
>
-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 a
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 do
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
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
28 matches
Mail list logo