Re: [Python-Dev] Python 3 executable name
Oren Tirosh wrote: > I suggest an explicitly and permanently different name for the > interpreter executable of this new and incompatible branch of the > language. I want Python 3 scripts starting with #! to have an average > shelf life longer than 18 months. That makes sense, but I'd prefer something less arbitrary than just chopping the name back from "python" to "py". Going that way, Python 4.0 is going to just be called "p", and by the time we get to Python 5.0, the name will have vanished altogether! Greg ___ Python-Dev mailing list [email protected] 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 3 executable name
On 9/12/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > Oren Tirosh wrote: > > > I suggest an explicitly and permanently different name for the > > interpreter executable of this new and incompatible branch of the > > language. I want Python 3 scripts starting with #! to have an average > > shelf life longer than 18 months. > > That makes sense, but I'd prefer something less arbitrary > than just chopping the name back from "python" to "py". > Going that way, Python 4.0 is going to just be called > "p", and by the time we get to Python 5.0, the name > will have vanished altogether! That's OK, by the time Python 5.0 comes out, it will have taken over the world and be the default language for everything. So omitting the name is exactly right :-) Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)
Brett Cannon wrote: > On 9/8/05, Tony Meyer <[EMAIL PROTECTED]> wrote: >> [finding Tools/i18n/pygettext.py] >> > You're right, I think Tools is probably a bad place for >> > anything. If it's not part of the stdlib, I'll likely never >> > find it. >> >> Agreed. Maybe with the introduction of -m in Python 2.4, some of the Tools/ >> scripts could be put in __main__ sections of appropriate modules? So that >> "python -m gettext" would be equivilant to "python Tools/i18n/pygettext.py"? Questionable. Most scripts don't correspond to a single library module. >> (However, pyggettext.py is 22KB, which is a big addition to the module; not >> everything in Tools/Scripts might be used enough for this, or have an >> appopriate module to be put in either). >> >> Are there other ideas about how Tools/ could be improved? Either moving >> things, or making it more likely that people will look there for scripts? >> > > I assume that the Windows installer includes the Tools/ directory. If > it doesn't that is one problem. =) > > Otherwise it is mostly a lack of advertisement and them not being > installed by ``make install``. If you just download the soure and > install you will never know the directory even exists. It needs to be > made obvious to people that it is even there. +1. Most non-Windows users with distribution-supplied Pythons will never get the Tools directory on their installs though there is a number of really useful scripts there. Question is, if ``make install`` should install it, where? Has the time come for /usr/share/python? Or /usr/lib/pythonX.Y/Tools (without __init__.py)? > Probably the only way is to document the directory. I think so, too. The tools are worth a top-level documentation entry. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and iterators
On 9/11/05, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote: > James Y Knight wrote: > > > Just to be clear, I do not want nor expect this. I wish to be able to > > specifically modify code with full knowledge of what has changed in > > Py3.0 such that it will work with both Py2.X and Py3.0. > > If you want these things to work in 2.x and 3.0, just use > iter(dict_instance) and list(dict_instance) as appropriate. Simpler still, just use di.keys() but make sure you're only using the result to iterate over once without modifying the dict's key set. Or if you *have* to avoid creating a list in Py2.x, write your code to iterate over the dict itself even if you'd like itervalues or iteritems; you can always get the value explicitly by indexing the dict. IOW use the API whose name will remain but don't rely on the functionality that will change. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unintentional and unsafe use of realpath()
On Mon, 2005-09-12 at 17:23 +1200, Greg Ewing wrote: > Peter Jones wrote: > > > Another problem (which I have not fixed) is that when realpath() is > > used, in some cases MAXPATHLEN is smaller than the system's > > PATH_MAX/pathconf(path, _PC_PATH_MAX). > > The linux man page for realpath() has this at the bottom: > > BUGS > Never use this function. It is broken by design since it is > impossible > to determine a suitable size for the output buffer. According to > POSIX > a buffer of size PATH_MAX suffices, but PATH_MAX need not be a > defined > constant, and may have to be obtained using pathconf(). And > asking > pathconf() does not really help, since on the one hand POSIX warns > that > the result of pathconf() may be huge and unsuitable for mallocing > mem- > ory. And on the other hand pathconf() may return -1 to signify > that > PATH_MAX is not bounded. > > So maybe it shouldn't be using realpath() at all? Well, the intent is clearly that OSes that have a better option, we shouldn't be using it. But that wasn't really my second point. When use of realpath is unavoidable, it is vitally important that MAXPATHLEN is set to the same value that realpath() got when it was built. If it's any smaller, it's a straightforward overflow, with something like $SYSTEM_MAXPATHLEN - $PYTHON_MAXPATHLEN of space to write nasty bits into. At least on one box I looked at, system's was 4096 and python wound up doing the fallback of 256 (I'm not entirely sure why) so that's 3768 bytes of stack potentially overwritten. In this case, it's not realistically exploitable, because it means a user has to trick root into running "python foo" where foo is a symlink that's built terrifyingly weirdly. So since the user is supplying the symlink, there are much more trivial attacks. But I haven't checked all the uses of realpath in python, some of them could be dangerous. -- Peter ___ Python-Dev mailing list [email protected] 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 3 executable name (was: Re: PEP 3000 and iterators)
> perhaps the Python 3 executable should have a different name as part > of the standard distribution? I suggest "py" / "py.exe" Perhaps the renaming should be more radical, to indicate the extent of the change. I suggest "second", to commemorate "Second City" in Chicago, another famous comedy troupe. The Python3 (that is, Second) version of IDLE could be DICK, after Andy Dick, an alumnus who somewhat resembles Eric Idle, or perhaps MURRAY, after Bill Murray. Bill ___ Python-Dev mailing list [email protected] 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 3 executable name (was: Re: PEP 3000 and iterators)
> Perhaps the renaming should be more radical, to indicate the extent of > the change. Another possiblity would be to use the new name to indicate a position in a spectrum of programming languages. For instance, "beryl", "topaz", "steel" and "jade" are (on the Mohs scale) all sturdier than pearl but not as hard as ruby :-). Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simplify the file-like-object interface
On 9/6/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> One could use "class decorators". For example if you want to define the
> method foo() in a file-like class, you could use code like:
I like the sound of this. Suppose there were a function textstream()
that decorated a file-like object (supporting read() and write()), so
as to add all of __iter__(), next(), readline(), readlines(), and
writeline() that it did not already implement. Then you could wrap any
file-like object easily to give it convenient text-handling:
mytextsocketstream = textstream(mysocketstream)
for line in mytextsocketstream:
print line
Another area where I think this approach can help is with the
text/binary file distinction. file() could always open files as
binary, and there could be a convenience function textfile(name, mode)
which would simply return textstream(file(name, mode)). This would
remove the need for "a" or "b" in the mode parameter, and make it
easier to keep text- and binary-file access separate in one's mind:
tf = textfile("log.txt", "w")
tf.writelines(loglist)
bf = file("img.jpg", "r")
process_image_file(bf)
Finally, I think this could nicely tie into the print
statement/function/method debate, as the print() method could be
defined by the textstream() wrapper, allowing any text stream to
support the convenient print() behaviour, but not requiring it for
binary streams, for which such a function makes little sense anyway.
And then textstream() could be used (in the sys module, preferably) to
ensure that sys.stdout and sys.stderr both support print(). So you'd
have the builtin:
# Actual signature depending on which variant proposal is taken up
def print(*args, **kwargs):
sys.stdout.print(*args, **kwargs)
And using print() could be a simple as:
print("Hello, World")
sys.stdout.print("This is normal output")
sys.stderr.print("This is an error message")
I have a vague idea that a wrapper like this (or another similar
wrapper) could provide for convenient, transparent handling of Unicode
text files also, but I don't know Unicode well enough to be certain.
Andrew.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/6/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > My hypothesis is that there are actually only two use cases that > matter enough to be supported directly: > > (a) quickly print a bunch of items with spaces in between them and a > trailing newline > > (b) print one or more items with precise control over each character Doesn't the write() method of file-like objects already cover (b), except that it only takes a single argument? If the need to print multiple arguments without any separator is so common, could the write() method be extended to take multiple arguments and just write them all out? It'd certainly be backward compatible with old code that called the write() method... Andrew. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
