Re: [Python-Dev] Python and the Linux Standard Base (LSB)
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 of years, accumulating much stuff. Nowadays when I do ls -a ~, I get a directory listing several screens long... The whole concept of hidden files seems ill- considered to me, anyway. It's too easy to forget that they're there. Putting infrequently-referenced stuff in a non-hidden location such as ~/local seems just as good and less magical to me. On OS X, you of course have ~/Library. I suppose the Linux equivalent would be something like ~/lib. Maybe this is something that we should be asking the LSB folks for advice on? -- Greg ___ 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/talin%40acm.org ___ 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] Python and the Linux Standard Base (LSB)
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 you've gotten the joke may be self-gratifying but not good HCI. How about: python -M install Or maybe we could even lobby to get: python --install as a synonym of the above? -- Talin ___ 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] Python and the Linux Standard Base (LSB)
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 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. How about: python -M install Or maybe we could even lobby to get: python --install as a synonym of the above? Maybe because 'install' is just one of the actions? I'd also like to see 'uninstall', 'list' and 'upgrade' actions (and have some very crude code to do this). Ronald ___ 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] Python and the Linux Standard Base (LSB)
-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 starting to show, though. There's a particular Unix account that I've had for quite a number of years, accumulating much stuff. Nowadays when I do ls -a ~, I get a directory listing several screens long... The whole concept of hidden files seems ill- considered to me, anyway. It's too easy to forget that they're there. Putting infrequently-referenced stuff in a non-hidden location such as ~/local seems just as good and less magical to me. On OS X, you of course have ~/Library. I suppose the Linux equivalent would be something like ~/lib. I forgot to add in my previous follow up why I'd prefer ~/.local over ~/local. It's a namespace thing. Dot-files in my home directory are like __names__ in Python -- they don't belong to me. Non-dot-names are my namespace so things like ~/local constrain what I can call my own files. When I switched to OS X for most of my desktops, I had several collisions in this namespace. I keep all my homedir files under subversion and could not check out my environment on my new Mac until I named a few directories (this was exacerbated by the case- insensitive file system). I think in general OS X has less philosophical problem with colliding in the non-dot namespace because most OS X users don't ever /see/ their home directory. They see ~/Desktop. Maybe that's what all the kids are into these days, but I still think dot-names are better to use for a wider acceptance. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRW72vXEjvBPtnXfVAQJUmAP8DOQkDJm35xfpSPmvFPXYNZYRhYk8gdSk yMisPq100d5c0lGvW/LjDyLoyi96vd0IQu/WfSgzbe9MBvJ6egP2R0U9hgwytxo5 VcI7jiqel8KFRqgM+4Xqau7MGRiIBGsNX/V5tzGPBA5QP4eSSEFXh/2i9l7ciWJE bN/byz5zlXo= =8CkG -END PGP SIGNATURE- ___ 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] Python and the Linux Standard Base (LSB)
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: python -M install Or maybe we could even lobby to get: python --install as a synonym of the above? As Ronald points out, installing is only one action, and then you have to handle all of its options too. Maybe that means python -M install --install-dir foo --other-setuptools-options would work, but I don't think just bare --install does. I'm also not sure python -M install is a big improvement over egg or whatever (egg actually isn't bad). - -Barry ___ 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
[Python-Dev] Small tweak to tokenize.py?
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. This is nearly perfect (I can render code from the
parse tree and it will be an exact match of the input) except for
continuation lines -- while the tokenize gives me pseudo-tokens for
comments and ignored newlines, it doesn't give me the backslashes at
all (while it does give me the newline following the backslash).
It would be trivial to add another yield to tokenize.py when the
backslah is detected:
--- tokenize.py (revision 52865)
+++ tokenize.py (working copy)
@@ -370,6 +370,8 @@
elif initial in namechars: # ordinary name
yield (NAME, token, spos, epos, line)
elif initial == '\\': # continued stmt
+# This yield is new; needed for better idempotency:
+yield (NL, initial, spos, (spos[0], spos[1]+1), line)
continued = 1
else:
if initial in '([{': parenlev = parenlev + 1
(Though 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. Thoughts?)
This wouldn't be 100% backwards compatible, so I'm not dreaming of
adding this to 2.5.1, but what about 2.6?
(There's another issue with tokenize.py too -- when you use it to
parse Python-like source code containing non-Python operators, e.g.
'?', it does something bogus.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Python and the Linux Standard Base (LSB)
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 setuptools depending on the context. pyinstall invites confusion with the Python installer, which is a different program, used to install Python itself on Windows. It's just a brand. If users can understand that Excel means Spreadsheet, Outlook means E-Mail, and GIMP means Image Editor, then I think we should give them some credit on being able to figure out what the installer program is called. (I don't really care that much in this particular case, but this was one of my pet peeves with GNOME a while back. There was a brief change to the names of everything in the menus to remove all brand-names: Firefox became Web Browser, Evolution became E-Mail, Rhythmbox became Music Player. I remember looking at my applications menu and wondering which of the 3 music players that I had installed the menu would run. Thankfully this nonsense stopped and they compromised on names like Firefox Web Browser and GIMP Image Editor.) ___ 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] Small tweak to tokenize.py?
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 comments go. I use the tokenize module
to scan the input. This is nearly perfect (I can render code from the
parse tree and it will be an exact match of the input) except for
continuation lines -- while the tokenize gives me pseudo-tokens for
comments and ignored newlines, it doesn't give me the backslashes at
all (while it does give me the newline following the backslash).
The following routine will render a token stream, and it automatically
restores the missing \'s. I don't know if it'll work with your patch, but
perhaps you could use it instead of changing tokenize. For the
documentation and examples, see:
http://peak.telecommunity.com/DevCenter/scale.dsl#converting-tokens-back-to-text
def detokenize(tokens, indent=0):
Convert `tokens` iterable back to a string.
out = []; add = out.append
lr,lc,last = 0,0,''
baseindent = None
for tok, val, (sr,sc), (er,ec), line in flatten_stmt(tokens):
# Insert trailing line continuation and blanks for skipped lines
lr = lr or sr # first line of input is first line of output
if srlr:
if last:
if len(last)lc:
add(last[lc:])
lr+=1
if srlr:
add(' '*indent + '\\\n'*(sr-lr))# blank continuation lines
lc = 0
# Re-indent first token on line
if lc==0:
if tok==INDENT:
continue # we want to dedent first actual token
else:
curindent = len(line[:sc].expandtabs())
if baseindent is None and tok not in WHITESPACE:
baseindent = curindent
elif baseindent is not None and curindent=baseindent:
add(' ' * (curindent-baseindent))
if indent and tok not in (DEDENT, ENDMARKER, NL, NEWLINE):
add(' ' * indent)
# Not at start of line, handle intraline whitespace by retaining it
elif sclc:
add(line[lc:sc])
if val:
add(val)
lr,lc,last = er,ec,line
return ''.join(out)
___
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] Small tweak to tokenize.py?
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 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. This is nearly perfect (I can render code from the
parse tree and it will be an exact match of the input) except for
continuation lines -- while the tokenize gives me pseudo-tokens for
comments and ignored newlines, it doesn't give me the backslashes at
all (while it does give me the newline following the backslash).
The following routine will render a token stream, and it automatically
restores the missing \'s. I don't know if it'll work with your patch, but
perhaps you could use it instead of changing tokenize. For the
documentation and examples, see:
http://peak.telecommunity.com/DevCenter/scale.dsl#converting-tokens-back-to-text
def detokenize(tokens, indent=0):
Convert `tokens` iterable back to a string.
out = []; add = out.append
lr,lc,last = 0,0,''
baseindent = None
for tok, val, (sr,sc), (er,ec), line in flatten_stmt(tokens):
# Insert trailing line continuation and blanks for skipped lines
lr = lr or sr # first line of input is first line of output
if srlr:
if last:
if len(last)lc:
add(last[lc:])
lr+=1
if srlr:
add(' '*indent + '\\\n'*(sr-lr))# blank continuation
lines
lc = 0
# Re-indent first token on line
if lc==0:
if tok==INDENT:
continue # we want to dedent first actual token
else:
curindent = len(line[:sc].expandtabs())
if baseindent is None and tok not in WHITESPACE:
baseindent = curindent
elif baseindent is not None and curindent=baseindent:
add(' ' * (curindent-baseindent))
if indent and tok not in (DEDENT, ENDMARKER, NL, NEWLINE):
add(' ' * indent)
# Not at start of line, handle intraline whitespace by retaining it
elif sclc:
add(line[lc:sc])
if val:
add(val)
lr,lc,last = er,ec,line
return ''.join(out)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Small tweak to tokenize.py?
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 behavior might behave oddly with the change. Mainly, though, I thought you might find the code useful, given the nature of your project. (Although I suppose you've probably already written something similar.) ___ 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] Small tweak to tokenize.py?
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 first option is likely the most compatible with existing uses of tokenize. If a comment token were emitted, an existing colorizer or pretty-printer would markup the continuation as a comment (possibly not what the tool author intended). If a new token were created, it might break if-elif-else chains in tools that thought they knew the universe of possible token types. Raymond ___ 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] Python and the Linux Standard Base (LSB)
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 are some applications and libraries that use distutils at run-time to compile things, and I'm using such applications and libraries on a daily basis.) I think you should blame the sysadmins, and kick them to install python properly for use by a developer, because every distro I know provides distutils... ;-) -- Jan Claeys ___ 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] Small tweak to tokenize.py?
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 tools (like detokenize) written to work
around the old behavior might behave oddly with the change.
Can you test it with this new change (slightly different from before)?
It reports a NL pseudo-token with as its text value '\\\n' (or
'\\\r\n' if the line ends in \r\n).
@@ -370,6 +370,8 @@
elif initial in namechars: # ordinary name
yield (NAME, token, spos, epos, line)
elif initial == '\\': # continued stmt
+# This yield is new; needed for better idempotency:
+yield (NL, token, spos, (lnum, pos), line)
continued = 1
else:
if initial in '([{': parenlev = parenlev + 1
Mainly, though, I thought you might find the code useful, given the nature
of your project. (Although I suppose you've probably already written
something similar.)
Indeed.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Python and the Linux Standard Base (LSB)
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. Wasteful. (There are some applications and libraries that use distutils at run-time to compile things, and I'm using such applications and libraries on a daily basis.) I think you should blame the sysadmins, and kick them to install python properly for use by a developer, because every distro I know provides distutils... ;-) 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 *Python* distro since 2.3 (2.2?) So, it isn't that you can't get distutils, it's that you have to take an extra step over and above installing Python. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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] Small tweak to tokenize.py?
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, optionally, be made to report horizontal whitespace as well. It's remarkably easy to get this out of the existing API; keep track of the end position returned by the previous call, and if it's different from the start position returned by the next call, slice the line text from the column positions, assuming the line numbers are the same. If the line numbers differ, something has been eating \n tokens; this shouldn't happen any more with my patch. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Python and the Linux Standard Base (LSB)
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 bunch of .foorc files to add to your environment with each additional package. After all, what's the point of a per-user install if the software isn't actually installed in any meaningful way, and you have to manually edit your shell startup scripts, log out and log in again anyway? Another nice feature there is that it uses a pre-existing layout convention (bin lib share etc ...) rather than attempting to build a new one, so the only thing that has to change about the package installation is the root. Putting programs and libraries in a hidden directory? Things the user intends to run or inspect? Putting a hidden directory on $PATH? I'm... stunned. It sounds like a very bad idea. Dotfiles are for a program's internal state: black box stuff. Not programs the user will run, and not Python modules he may want to inspect or subclass. ~/bin and ~/lib already work well with both Virtual Python and ./configure, and it's what many users are already doing. On the other hand, the freedesktop link says ~/.local can be overridden with environment variables. That may be an acceptable compromise between the two. 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. I've started using it off and on but haven't come to any general conclusion on it. Is it becoming pretty widespread among Python users. Would it be worth mentioning in the LSB/FHS? It only works on *nix systems currently, but Linux is a *nix system anyway. [1] http://peak.telecommunity.com/dist/virtual-python.py (It installs a pseudo copy of Python symlinked to the system one, so that you have your own site--packages directory independent of others ) -- Mike Orr [EMAIL PROTECTED] ___ 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] Python and the Linux Standard Base (LSB)
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 created to help people who don't have root access (e.g. in shared web hosting accounts) get their own Python. It does work for other things, but I haven't been especially recommending it for anything besides that, since eggs take care of multi-version app/library support quite nicely. Indeeed, the virtual-python approach is itself unnecessary now, as easy_install has much better PYTHONPATH support now, than when virtual-python was created. ___ 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] Python and the Linux Standard Base (LSB)
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 *Python* distro since 2.3 (2.2?) So, it isn't that you can't get distutils, it's that you have to take an extra step over and above installing Python. No, it just means that several parts of the python.org source package are spread over several binary packages, just like happens with hundreds or thousands of other packages, and any Debian (or Ubuntu or other distro doing this) administrator worth his or her money should be aware of that, and be able to find those packages. E.g. on a debian sarge system: $ apt-cache showsrc python2.4 | grep Binary Binary: python2.4-doc, python2.4, python2.4-examples, python2.4-tk, python2.4-dev, idle-python2.4, python2.4-dbg, python2.4-gdbm Or on an Ubuntu edgy system: $ apt-cache showsrc python2.4 | grep Binary Binary: python2.4-dbg, python2.4-dev, python2.4, python2.4-doc, idle-python2.4, python2.4-minimal, python2.4-examples 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 splitting python (or other projects) up in several packages is wrong. E.g. when installing on an flash drive, people are probably quite happy to leave the 20 MiB of Python documentation out... Maybe python.org can include several logical divisions in the python.org distribution and make it easy for OS distro packagers to make separate packages if they want to, as most of them are quite happy to have less work to do, provided the upstream divisions do more or less what they want. ;-) (Oh, and such a division should IMHO also include a minimal python for embedded/low-resource hardware use, where things like distutils, GUI toolkits, a colelction of 20 XML libraries and documentation are most likely not needed.) -- Jan Claeys ___ 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] Python and the Linux Standard Base (LSB)
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 MacOSX has a somewhat different philosophy about hiding things. The Finder hides the internals of things like application bundles, which is fine, but the application itself is visible, so you can move it around or delete it if you want. 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 way of freeing it up. I think that's bad HCI. -- Greg ___ 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] Python and the Linux Standard Base (LSB)
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 way of freeing it up. I think that's bad HCI. AFAIK fd.o's use of ~/.local is mainly for things like *.desktop files (e.g. menu items added or changed by the user). -- Jan Claeys ___ 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] Python and the Linux Standard Base (LSB)
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 splitting python (or other projects) up in several packages is wrong. E.g. when installing on an flash drive, people are probably quite happy to leave the 20 MiB of Python documentation out... Right, who cares about newbies, they're only the future of the language, after all. I take your point that some flexibility is advantageous once you get past the newbie stage, but I think that here we are talking about trying to avoid mis-steps that will potentially put people off making that transition. Maybe python.org can include several logical divisions in the python.org distribution and make it easy for OS distro packagers to make separate packages if they want to, as most of them are quite happy to have less work to do, provided the upstream divisions do more or less what they want. ;-) (Oh, and such a division should IMHO also include a minimal python for embedded/low-resource hardware use, where things like distutils, GUI toolkits, a colelction of 20 XML libraries and documentation are most likely not needed.) If only there were some guarantee that the distros would respect any project partitioning imposed by python-deb we might stand a chance of resolving these issues. By and large they do tend to go their own way, though. I suppose the only alternative is prominently-posted materials on python.org about Python on Debian, Python on Ubuntu, ... and various addition to the FAQs. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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] Python and the Linux Standard Base (LSB)
-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 that are *your* namespaces, rather than the top level of your home directory. That's not how a *nix developer is going to think, but OSX does straddle the line between my grandma's OS and a Real Development Platform. It usually does a pretty good job of letting the *nix geeks pop the hood and play in the sandbox they're used to (to mix some metaphors :), but letting you ignore all that stuff if you want, like when I'm just using it to write some music. I actually think it does a pretty good job here too, or at least as good as can be expected. But it does create collisions where I've generally not had them on e.g. Linux or Solaris. Maybe I'd see more of that if e.g. I actually tried to use a Linux desktop in grandma- mode too. Also, I think MacOSX has a somewhat different philosophy about hiding things. The Finder hides the internals of things like application bundles, which is fine, but the application itself is visible, so you can move it around or delete it if you want. The Finder is for my grandma, the terminal is for me. Sometimes I / want/ to put on my grandma's clothes and pretend I'm just a desktop consumer. When I do, I'm usually fine with letting Finder protect me from all the hungry-wolf dot-files. 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 way of freeing it up. I think that's bad HCI. Yes, but who are they hidden from? Dot-files aren't for my grandma, they're for me (in my normal clothes). I'd expect that a geek who installed stuff into ~/.local would know enough to know how to find it, delete it, etc. To me that's good adaptive HCI -- novice users don't care and won't use it or see it, advanced users know how to take advantage of it because it fits in, or at least relates to, their world view. OTOH, the fact that most OSX applications don't store their data in dot-files but instead in ~/Library is fine too, because their data needs to be visible to grandma occasionally. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRW95u3EjvBPtnXfVAQK7fgP/ZfmTIg+x2QqrmDcRiomcYzioS6J8YXEY K0Iiy/uYjux/XfDYbCHUatl2hO/pIGH6NOPHOWZ3/eub+9BfKaIkIn3sIvxVOzd/ cN/AN0OVsHUAPqWiotrALFqAUNj6uP+UUs6/cmlx9LtkNiIIFs6eg16993vNu2eZ pWSK6CKeBnQ= =vzU5 -END PGP SIGNATURE- ___ 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
[Python-Dev] fpectl: does a better implementation make sense?
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 exceptions and convert them to Python exceptions in a way that really works. 3) Moreover, the current implementation of PyFPE_* macros (turning on/off the traps + setjmp) are pretty slow, so they're off by default. Now, I would like Python to rause exceptions (FloatingPointError) whenever a Inf or NaN is computed or used in calculations (which to the best of my little understanding of 754 basically means that I want all FPU errors to be detected and handled). I am not arguing that this should be the default behaviour, I'm just saying that I would like if there was a way to enable this (even if only at Python compile time, in fact). I read that Tim Peters suggested several times to rewrite fpectl so that it does not use traps/signals at all, but just checks the FPU bits to see if there was a FPU error. Basically, the PyFPE BEGIN macro would clear the FPU bits, and the STOP macro would check for FPU errors and raise an appropriate exception if needed. Is this suggestion still valid or people changed their mind meanwhile? Would such a rewrite of fpectl (or a new module with a different name) be accepted? -- Giovanni Bajo ___ 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
[Python-Dev] Weekly Python Patch/Bug Summary
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() and sys.intern() (2006-11-23) http://python.org/sf/1601678 opened by Georg Brandl clarify comparison return values (2006-11-24) http://python.org/sf/1602128 opened by Jim Jewett non-framework built python fails to define environ properly (2006-11-23) http://python.org/sf/1602133 opened by paul Suggest a textlist() method for ElementTree (2006-11-24) http://python.org/sf/1602189 opened by Raymond Hettinger subprocess: error redirecting i/o from non-console process (2006-11-27) http://python.org/sf/1603907 opened by Oren Tirosh Performance boost for array repeat (2006-11-28) CLOSED http://python.org/sf/1605020 opened by Mike Klaas Make Imap Error more helpful (2006-11-29) http://python.org/sf/1605192 opened by Thomas Guettler vendor-packages directory. (2005-09-22) http://python.org/sf/1298835 reopened by loewis Patches Closed __ __bool__ instead of __nonzero__ (2006-11-21) http://python.org/sf/1600346 closed by jackdied SRE engine do not release the GIL (2005-11-25) http://python.org/sf/1366311 closed by eric_noyau Implement lazy read for sockets (2003-12-04) http://python.org/sf/853963 closed by loewis Disable POSIX for certain/older NetBSD versions (2003-12-05) http://python.org/sf/854796 closed by loewis Performance boost for array repeat (2006-11-28) http://python.org/sf/1605020 closed by mklaas New / Reopened Bugs ___ using python extension(wxPython) in c (2006-11-23) CLOSED http://python.org/sf/1601607 opened by jolleydtan getopt Documentation improvement (2006-11-23) CLOSED http://python.org/sf/1601630 opened by Thomas Guettler Incorrect docs for bisect_left (2006-11-24) http://python.org/sf/1602378 opened by Daniel Eloff itemconfigure returns incorrect text property of text items (2006-11-25) http://python.org/sf/1602742 opened by Wojciech Mula wave module forgets to close file on exception (2006-11-26) http://python.org/sf/1603150 opened by amerinese wave module forgets to close file on exception (2006-11-26) CLOSED http://python.org/sf/1603246 opened by amerinese pstats module (profiler) doens't support unicode paths (2006-11-26) CLOSED http://python.org/sf/1603321 opened by Adal Chiriliuc def foo(((x))) segfault (2006-11-26) CLOSED http://python.org/sf/1603332 opened by Tony Lownds f=open fails with TypeError (2006-11-26) CLOSED http://python.org/sf/1603336 opened by Gibholio f=open fails with TypeError (2006-11-26) CLOSED http://python.org/sf/1603412 opened by Gibholio subprocess.py (py2.5) wrongly claims py2.2 compatibility (2006-11-27) http://python.org/sf/1603424 opened by Tim Wegener Python socket library confused by IPV6 notation in /etc/host (2006-11-27) http://python.org/sf/1603527 opened by Eric S. Raymond SaveConfigParser.write() doesn't quote %-Sign (2006-11-27) http://python.org/sf/1603688 opened by Rebecca Breu grammatical error in Python Library Reference::Tkinter (2006-11-27) CLOSED http://python.org/sf/1603789 opened by Gabriel M. Elder subprocess.Popen closes fds for sys.stdout or sys.stderr (2006-11-28) http://python.org/sf/1604851 opened by Nishkar Grover _CRT_SECURE_NO_DEPRECATE macro redefinition with VC++ 8 (2006-11-28) CLOSED http://python.org/sf/1604862 opened by William Fulton logging %(module)s reporting wrong modules (2006-11-29) http://python.org/sf/1605110 opened by Mad-Marty csv module broken for unicode (2006-11-30) http://python.org/sf/1606092 opened by JettLogic readline on popen3 file returns empty string before end (2006-11-30) http://python.org/sf/1606233 opened by Bill Wallace Bugs Closed ___ utf_8_sig decode fails with buffer input (2006-11-23) http://python.org/sf/1601501 closed by doerwalter using python extension(wxPython) in c (2006-11-23) http://python.org/sf/1601607 closed by loewis getopt Documentation improvement (2006-11-23) http://python.org/sf/1601630 closed by gbrandl ctypes Structure allows recursive definition (2006-11-17) http://python.org/sf/1598620 closed by theller 2.4 2.5 can't create win installer on linux (2006-10-04) http://python.org/sf/1570417 closed by loewis wave module forgets to close file on exception (2006-11-26) http://python.org/sf/1603246 closed by gbrandl pstats module (profiler) doens't support unicode paths (2006-11-26) http://python.org/sf/1603321 closed by gbrandl def foo(((x))) segfault (2006-11-26)
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
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 for distutils even though it's been a part of the standard *Python* distro since 2.3 (2.2?) So, it isn't that you can't get distutils, it's that you have to take an extra step over and above installing Python. No, it just means that several parts of the python.org source package are spread over several binary packages, just like happens with hundreds or thousands of other packages, and any Debian (or Ubuntu or other distro doing this) administrator worth his or her money should be aware of that, and be able to find those packages. In both the current Debian and Ubuntu releases, the python2.4 binary package includes distutils. See for yourself at http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelistword=python2.4version=stablearch=i386page=1number=all if you like. So I'm not sure what the fuss is about. Maybe python.org can include several logical divisions in the python.org distribution and make it easy for OS distro packagers to make separate packages if they want to, as most of them are quite happy to have less work to do, provided the upstream divisions do more or less what they want. ;-) (Oh, and such a division should IMHO also include a minimal python for embedded/low-resource hardware use, where things like distutils, GUI toolkits, a colelction of 20 XML libraries and documentation are most likely not needed.) There's already a python2.4-minimal package in Debian/Ubuntu that would probably be a good starting point for an embedded distribution that cares about space more than providing a complete Python. -Andrew. ___ 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
