[Python-Dev] Python long command line options
Hi all! Martin von Löwis said that it'd be necessary to discuss a patch to Python's ability to parse command-line parameters to the interpreter here, and I thought I might start the ball rolling. The associated patch of mine is: http://sourceforge.net/tracker/index.php?func=detailaid=1481112group_id=5470atid=305470 which refers to: http://groups.google.de/group/comp.lang.python/browse_thread/thread/e3db1619040d7c6c/3c119e09122c83ed?hl=de#3c119e09122c83ed (sorry for the long URLs, tinyurl isn't working for me at the moment...) The patch itself is an extension of the Python/getopt.c module to handle long command-line parameters (including option data passed as --name=data), which are specified in the optstring as: shortopt[(longopt)][:] for example: V(version) or c(command): The patch doesn't change behaviour on old optstrings, except where an old optstring relied on the fact that one of :, (, ) are valid parameter names (because of the unconditional strchr to find the option name). I've not found any reference to _PyOS_GetOpt besides the one in Modules/main.c, so I don't think this change in behaviour breaks any existing code. The patch relies only on usability of strchr (which the old getopt.c did too), removes a usage of strcmp which was completely unneccesary, fixes some checks which were unneccesarily broad (= replaced by ==), and compilation doesn't show any warnings on gcc 3.4.6; as for Windows (and MSVC), I don't have the means to test there. The current patch offers prefix matching: when an option is only specified with a significant amount of prefix characters which doesn't match any other long option, the patch assumes that the user meant this option. For example: --ver would also be interpreted as command-line parameter --version just as would --v --ve --vers --versi --versio if there are no other long options that start with the corresponding prefix. This trick is easy enough to remove from the sources, though, so that only correctly spelled options are actually returned. Anyway, back on topic, I personally agree with the people who posted to comp.lang.python that --version (and possibly --help, possibly other long parameters too) would be useful additions to Pythons command-line parameters, as it's increasingly getting more common amongst GNU and BSD utilities to support these command-line options to get information about the utility at hand (very popular amongst system administrators) and to use long commandline options to be able to easily see what an option does when encountered in a shell script of some sort. And, as this doesn't break any old code (-V isn't going away by the patch), I personally find this to be a very useful change. Your thoughts? --- Heiko. ___ 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] lambda in Python
xahlee xah at xahlee.org writes: Today i ran into one of Guido van Rossum's blog article titled “Language Design Is Not Just Solving Puzzles” at http://www.artima.com/weblogs/viewpost.jsp?thread=147358 The confrontational tone of this post makes it pretty much impossible to have a reasonable debate on the subject. I'd suggest that if you really want to be heard (instead of merely having that I'm right feeling) that you try a different approach. -- 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] Alternative path suggestion
Noam Raphael wrote: You can find the implementation at http://wiki.python.org/moin/AlternativePathModule?action=raw (By the way, is there some code wiki available? It can simply be a public svn repository. I think it will be useful for those things.) pastebin is quite popular: http://python.pastebin.com/ /F ___ 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] lambda in Python
On May 4, 2006, at 6:00 AM, Talin wrote: xahlee xah at xahlee.org writes: Today i ran into one of Guido van Rossum's blog article titled ?Language Design Is Not Just Solving Puzzles? at http://www.artima.com/weblogs/viewpost.jsp?thread=147358 The confrontational tone of this post makes it pretty much impossible to have a reasonable debate on the subject. I'd suggest that if you really want to be heard (instead of merely having that I'm right feeling) that you try a different approach. -- Talin Xah Lee is a well known troll, he does stuff like this on c.l.p. all the time. Best to just ignore him, he doesn't listen to reason. Jay P. ___ 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 long command line options
Heiko Wundram wrote: Anyway, back on topic, I personally agree with the people who posted to comp.lang.python that --version (and possibly --help, possibly other long parameters too) would be useful additions to Pythons command-line parameters, as it's increasingly getting more common amongst GNU and BSD utilities to support these command-line options to get information about the utility at hand (very popular amongst system administrators) and to use long commandline options to be able to easily see what an option does when encountered in a shell script of some sort. +0 from me, as long as the 'best guess' bit removed. Otherwise '-v' would be verbose, while --v was version. And if we added '--verbose' later, scripts relying on '--v' would start getting an error. Much better to force people to spell the option right in the first place. And any such patch would require additional tests in test_cmd_line.py if the new option is equivalent to an option that's already tested by that file. Being able to give less cryptic names to the various options would be good for shell scripts and sys calls. e.g.: -c == --command -d == --debugparser -E == --noenv -h == --help -i == --interactive -m == --runmodule -O == no long equivalent -OO == no long equivalent -Q == --div old, --div warn, --div warnall, --div new -S == --nosite -t == --warntabs -tt == --errtabs -u == --unbuffered -v == --verbose -V == --version -W == --warn -x == --skipfirstline As far as I know, the only place these are documented is in python -h and the Linux man pages. And good luck to you if you encounter a sys call containing python -U. Even though not recognising the meaning of the option is likely to be the least of your worries in that case, at least you'd have some idea *why* some Python scripts start collapsing in a screaming heap when you try it ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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 long command line options
Heiko Wundram wrote: Anyway, back on topic, I personally agree with the people who posted to comp.lang.python that --version (and possibly --help, possibly other long parameters too) would be useful additions to Pythons command-line parameters, as it's increasingly getting more common amongst GNU and BSD utilities to support these command-line options to get information about the utility at hand (very popular amongst system administrators) and to use long commandline options to be able to easily see what an option does when encountered in a shell script of some sort. And, as this doesn't break any old code (-V isn't going away by the patch), I personally find this to be a very useful change. Your thoughts? Personally, I'm +1, but wonder if it would be enough to support '--help' and '--version'. We then could cut out the best guess code and the code to enable --opt=value. Georg ___ 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] Alternative path suggestion
Stefan Rank wrote: I suggest storing the first element separately from the rest of the path. The reason for suggesting this is that you use 'os.sep' to separate elements in the normal path, but *not* to separate the first element from the rest. I want to add that people might want to manipulate paths that are not for the currently running OS. Therefore I think the `sep` should be an attribute of the root element. I meant to mention that. The idea I had was for normal path objects to use os.sep and os.extsep (so they can be pickled and unpickled successfully between platforms), and then have a mechanism that allowed a platform specific path to be selected based on the desired platform (i.e. one of the possible values of os.name: 'posix', 'nt', 'os2', 'mac', 'ce' or 'riscos'). My inclination was to have a PlatformPath subclass that accepted 'os', 'sep' and 'extsep' keyword arguments to the constructor, and provided the appropriate 'sep' and 'extsep' attributes (supplying 'os' would just be a shortcut to avoid specifying the separators explicitly). That way the main class can avoid being complicated by the relatively rare need to operate on another platform's paths, while still supporting the ability. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] Alternative path suggestion
On 5/4/06, Nick Coghlan [EMAIL PROTECTED] wrote: My inclination was to have a PlatformPath subclass that accepted 'os', 'sep' and 'extsep' keyword arguments to the constructor, and provided the appropriate 'sep' and 'extsep' attributes (supplying 'os' would just be a shortcut to avoid specifying the separators explicitly). That way the main class can avoid being complicated by the relatively rare need to operate on another platform's paths, while still supporting the ability. You ought to have predefined classes for the standard OSes. Expecting people to know the values for sep and extsep seems unhelpful. In fact, unless you expect to support the os.path interface forever, as well as the new interface, I'd assume there would have to be internal WindowsPath and PosixPath classes anyway - much like the current ntpath and posixpath modules. So keeping that structure, and simply having if os.name == 'posix': Path = PosixPath elif os.name == 'nt': Path = WindowsPath ... etc at the end, would seem simplest. (But all the current proposals seem to build on os.path, so maybe I should assume otherwise, that os.path will remain indefinitely...) Paul. ___ 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] Time since the epoch
Hello, Python library reference 6.11 says, The epoch is the point where the time starts. On January 1st of that year, at 0 hours, the time since the epoch'' is zero. For Unix, the epoch is 1970. To me this seems to suggest that the epoch may vary among platforms and implementations as long as it's consistent. Am I correct? For example, does it make sense to file bug reports to Python projects assuming that time.time() returns seconds since the Unix epoch? I am asking because currently Python and IronPython returns very different values for time.time() even if they run on the same computer and at the same time. Seo Sanghyeon ___ 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 long command line options
Heiko Wundram wrote: Personally, I'm +1, but wonder if it would be enough to support '--help' and '--version'. We then could cut out the best guess code and the code to enable --opt=value. The code for the above functionality is about 10-12 lines of C of the whole patch. If there's concensus to remove it, I'll gladly prepare a patch that doesn't contain this, but I don't think it's sensible to do so just because it makes the code shorter. But, the best guess functionality most certainly is debatable on other grounds. exactly. as the zen says, explicit is better than I know what you mean, even if you don't mean what I think you mean. I'm +1 on adding --help and --version, +1 on adding -? and /? for windows only, -0=slightly sceptical if adding a generic long option machinery is worth it, and -1 on a guessing machinery. /F ___ 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] Time since the epoch
On 5/2/06, Sanghyeon Seo [EMAIL PROTECTED] wrote: Hello,Python library reference 6.11 says, The epoch is the point where thetime starts. On January 1st of that year, at 0 hours, the time sincethe epoch'' is zero. For Unix, the epoch is 1970. To me this seems to suggest that the epoch may vary among platformsand implementations as long as it's consistent. Am I correct?Yes. (I believe the C standard doesn't specify the 'epoch', just POSIX does -- for C. Regardless of that, Python's 'epoch' isn't guaranteed anywhere, and the docs you quote are probably the most authorative docs on the question.) For example, does it make sense to file bug reports to Python projectsassuming that time.time() returns seconds since the Unix epoch?I would say so, yes. I am asking because currently Python and IronPython returns verydifferent values for time.time() even if they run on the same computerand at the same time.As long as the value returned by time.time () is still 'seconds', and everything in the time and datetime modules properly considers the same epoch, I would say it's a bug (for third-party modules or for other parts of the standard library) to break. -- Thomas Wouters [EMAIL PROTECTED]Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] Alternative path suggestion
on 04.05.2006 16:18 Paul Moore said the following:
On 5/4/06, Nick Coghlan [EMAIL PROTECTED] wrote:
My inclination was to have a PlatformPath subclass that accepted 'os', 'sep'
and 'extsep' keyword arguments to the constructor, and provided the
appropriate 'sep' and 'extsep' attributes (supplying 'os' would just be a
shortcut to avoid specifying the separators explicitly).
That way the main class can avoid being complicated by the relatively rare
need to operate on another platform's paths, while still supporting the
ability.
You ought to have predefined classes for the standard OSes. Expecting
people to know the values for sep and extsep seems unhelpful.
I assume that having subclasses (at least for the different os
filesystem paths) is not necessary.
The sep and extsep that needs to be used is determined by the root of
the path.
The root, I suppose, is set when constructing the path from a string.
The ambiguous cases are relative paths and `p = path()`.
(Also think of the proposed URL root which normally would mandate '/' as
sep. Actually, the format depends on the 'scheme' part of the URL...)
On the output side ( `str(pathinstance)` ) the format is determined by
the root.
At least if you ignore people who want to have
C:/this/style/of/acceptable/windows/path
When constructing a relative path, I suggest creating a os dependent one
(root==None) by default, even if you use::
p = path('./unix/relative/style')
on Windows.
Daring people can later use::
p.root = path.WINDOWSRELATIVE# or
p.root = path.UNIXRELATIVE
if they need to.
stefan
___
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] lambda in Python
xahlee wrote: I do not wish to be the subject of mobbing here. If you have opinions on what i wrote, respond to the subject on topic as with any discussion. Please do not start a gazillion war-cry on me. If you cannot tolerate the way i express my opinions, at this moment write a polite request to me and cc to the sys op of this forum. If the sysop deems fit, I'd be happy to be asked to leave by the sysop. There's no sysop needed to tell you this: This is a mailing list and newsgroup (no forum) devoted to the development *of* *Python*. Obviously, we all like Python the way it is and people who disagree (especially those who accuse the BDFL of being ignorant) don't belong here. Georg ___ 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] binary trees. Review obmalloc.c
Tim Peters wrote: [Vladimir 'Yu' Stepanov] * To adapt allocation of blocks of memory with other alignment. Now alignment is rigidly set on 8 bytes. As a variant, it is possible to use alignment on 4 bytes. And this value can be set at start of the interpreter through arguments/variable environments/etc. At testing with alignment on 4 or 8 bytes difference in speed of work was not appreciable. [Martin v. Löwis] That depends on the hardware you use, of course. Some architectures absolutely cannot stand mis-aligned accesses, and programs will just crash if they try to perform such accesses. Note that we _had_ to add a goofy long double to the PyGC_Head union because some Python platform required 8-byte alignment for some types ... see rev 25454. Any spelling of malloc() also needs to return memory aligned for any legitimate purpose, and 8-byte alignment is the strictest requirement we know of across current Python platforms. It is possible to receive the reference about these tests? I have lead some tests, which very small difference of speed of work at alignment on 4 and 8 byte (a maximum of 8%, and in the basic less than one percent). In tests consecutive search of elements in one piece of memory was used. I understand, that it is necessary to lead still the test with a casual choice of addresses to minimize optimization of work cache the processor. And certainly not all platforms will show the same result (I shall try to not forget to attach a source code of the test and its result of work :) ). On the other hand reduction of a memory size by each separate copy of object is capable to increase speed by the same percent that is lost at change of displacement about 8 bytes up to 4 :) Besides begins to refuse probably superstructures on allocation of memory at some objects, since int. So Python should err on the safe side, and only use a smaller alignment when it is known not to hurt. OTOH, I don't see the *advantage* in reducing the alignment. It could cut wasted bytes. There is no per-object memory overhead in a release-build obmalloc: the allocatable part of a pool is entirely used for user-visible object memory, except when the alignment requirement ends up forcing unused (by both the user and by obmalloc) pad bytes. For example, Python ints consume 12 bytes on 32-bit boxes, but if space were allocated for them by obmalloc (it's not), obmalloc would have to use 16 bytes per int to preserve 8-byte alignment. Good note. OTOH, obmalloc (unlike PyGC_Head) has always used 8-byte alignment, because that's what worked best for Vladimir Marangozov during his extensive timing tests. It's not an isolated decision -- e.g., it's also influenced by, and influences, the best pool size, and (of course) cutting alignment to 4 would double the number of size classes obmalloc has to juggle. Yes, the maximum quantity of buffers will really be doubled. But it should not to affect as that productivity of system, or on total amount of consumed memory. Change of a fragmentation of memory to count it is impossible, since it will depend on the concrete application. * To expand the maximal size which can be allocated by means of the given module. Now the maximal size is 256 bytes. Right. This is somewhat deliberate, though; the expectation is that fragmentation will increase dramatically if even larger size classes are supported. It's entirely deliberate ;-) obmalloc is no way trying to be a general-purpose allocator. It was designed specifically for the common memory patterns in Python, aiming at large numbers of small objects of the same size. That's extremely common in Python, and allocations larger than 256 bytes are not. The maximum size was actually 64 bytes at first.After that, dicts grew an embedded 8-element table, which vastly increased the size of the dict struct. obmalloc's limit was boosted to 256 then, although it could have stopped at the size of a dict (in the rough ballpark of 150 bytes). There was no reason (then or now) to go beyond 256. See below. * At the size of the allocated memory close to maximal, the allocation of blocks becomes inefficient. For example, for the sizesof blocks 248 and 256 (blocksize), values of quantity of elements (PAGESIZE/blocksize) it is equal 16. I.e. it would be possible to use for the sizes of the block 248 same page, as for the size of the block 256. Good idea; that shouldn't be too difficult to implement: for sizes above 215, pools need to be spaced apart only at 16 bytes. I'd rather drop the limit to 215 then 0.3 wink. Allocations that large probably still aren't important to obmalloc, but it is important that finding a requested allocation's size index be as cheap as possible. Uniformity helps that. An available module on allocation of memory really does not approach for overall aims. And speed of work can blink in case of existing non-uniform realization on allocation of memory. In some cases allocation of memory in the
Re: [Python-Dev] lambda in Python
On May 4, 2006, at 11:31 AM, Georg Brandl wrote: Obviously, we all like Python the way it is and people who disagree (especially those who accuse the BDFL of being ignorant) don't belong here. If that were really the case, there wouldn't be much point to having a Python-Dev list, now would there? Zac ___ 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] Shared libs on Linux (Was: test failures in test_ctypes (HEAD))
On 5/3/06, Thomas Heller [EMAIL PROTECTED] wrote: [Crossposting to both python-dev and ctypes-users, please respond to the listthat seems most appropriate]Guido van Rossum wrote: File /home/guido/projects/python/trunk/Lib/ctypes/__init__.py, line 288, in __init__ self._handle = _dlopen(self._name, mode) OSError: /usr/lib/libglut.so.3: undefined symbol: XGetExtensionVersionIt means that /usr/lib/libglut.so.3 is not explicitly linking to xlibs, but it should. Nothing wrong with python, it's the GL library that was not correctly linked. ___ 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] lambda in Python
Reminder: the best way to get rid of a troll is to ignore him. -- --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] Alternative path suggestion
On 5/4/06, Nick Coghlan [EMAIL PROTECTED] wrote: Guido has indicated strong dissatisfaction with the idea of subclassing str/unicode with respect to PEP 355. That's not my only problem with that PEP; I'm not at all convinced that an object is a better solution than a module for this particular use case. FWIW, subclassing tuple isn't any better in my book than subclassing str/unicode. My only other comment on this discussion: I don't really have time for it; but don't let that stop you all from having a jolly good time. If you need me to pronounce on something, put me (and python-dev) in the To: header and limit your post to 20 lines. -- --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] Alternative path suggestion
The biggest conceptual change is that my path object is a subclass of
''tuple'', not a subclass of str. For example,
Using tuples is a nice idea! Object paths using tuples is a somewhat
common concept. I don't see an immediate reason to be a *subclass*
of tuple, though, as opposed to using it as an internal representation.
{{{
p.normpath() - Isn't needed - done by the constructor
p.basename() - p[-1]
p.splitpath() - (p[:-1], p[-1])
p.splitunc() - (p[0], p[1:]) (if isinstance(p[0], path.UNCRoot))
p.splitall() - Isn't needed
p.parent - p[:-1]
p.name- p[-1]
p.drive - p[0] (if isinstance(p[0], path.Drive))
p.uncshare- p[0] (if isinstance(p[0], path.UNCRoot))
and of course:
p.join(q) [or anything like it] - p + q
}}}
Nice indeed.
The only drawback I can see in using a logical representation is that
giving a path object to functions which expect a path string won't
work. The immediate solution is to simply use str(p) instead of p. The
long-term solution is to make all related functions accept a path
object.
Let's use __path_.. I mean, generic functions! ;-)
(...)
* A ''relative path'' is a path without a root element, so it can be
concatenated to other paths.
* An ''absolute path'' is a path whose meaning doesn't change when
the current working directory changes.
That sounds right.
== Easier attributes for stat objects ==
The current path objects includes:
* isdir, isfile, islink, and -
* atime, mtime, ctime, size.
(...)
This indeed shouldn't be attributes of path, IMO, since they are
operations that depend on the state of the filesystem, and will
change behind your back.
I think that isfile, isdir should be kept (along with lisfile,
lisdir), since I think that doing what they do is quite common, and
requires six lines:
I don't agree. isdir is an attribute of the filesystem, not of
the path object. I'd never expect that e.g. a network operation
could result from accessing an attribute in Python, and that could
certainly happen if the path is referencing a network filesystem.
--
Gustavo Niemeyer
http://niemeyer.net
___
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 long command line options
On 5/4/06, Fredrik Lundh [EMAIL PROTECTED] wrote: I'm +1 on adding --help and --version, +1 on adding -? and /? for windows only, -0=slightly sceptical if adding a generic long option machinery is worth it, and -1 on a guessing machinery. I fully support Fredrik's position on this issue. -- --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] Alternative path suggestion
You ought to have predefined classes for the standard OSes. Expecting people to know the values for sep and extsep seems unhelpful. (...) Why not something as simple as having path.sep == None meaning the default for the platform, and a defined value for otherwise? -- Gustavo Niemeyer http://niemeyer.net ___ 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] PEP 3102: Keyword-only arguments
Greg Ewing [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] BJörn Lindqvist wrote: would have thought that the one obvious way to get rid of the wanky feeling would have been to write: def make_person(name, age, phone, location): ... make_person(name, age, phone, location) This doesn't fly in something like PyGUI, where there are literally dozens of potential arguments to many of the constructors. The only sane way to deal with that is for them to be keyword-only, at least conceptually if not in actual implementation. You are mixing lemons and peaches. There is no disagreement about name-only options with default values or default behavior in the absence of a value (your peach case). The dispute is about the sensibility and politeness of requiring a small fixed number of required, no-default args to be passed by name only (the lemon case) and prohibiting a call passing by position, as above. Terry Jan Reedy ___ 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 long command line options
Fredrik Lundh wrote: I'm +1 on adding --help and --version, +1 on adding -? and /? for windows only, -0=slightly sceptical if adding a generic long option machinery is worth it, and -1 on a guessing machinery. I also agree with all these judgments. Regards, Martin ___ 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-checkins] r45898 - in python/trunk: Lib/test/test_os.py Lib/test/test_shutil.py Misc/NEWS Modules/posixmodule.c
[Guido] I wonder if it's time to move the Win32 code out of posixmodule.c? It seems the current mess of #ifdefs can't be very maintainable. [Martin v. Löwis] I vaguely recall that we had considered that before, and rejected it, for some reason. Not sure what the reason was, but one might have been that there still is OS/2 code in there, also. Martin worked up a patch for this in 2002, which he withdrew based on mixed reviews (a +0.5 and two -0); the comments still seem relevant: http://www.python.org/sf/592529 ___ 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] Confirmed: DC-area sprint on Sat. June 3rd
The DC-area sprint is now confirmed. It'll be on Saturday June 3, from 10 AM to 5 PM at the Arlington Career Center in Arlington VA. I've created a wiki page at http://wiki.python.org/moin/ArlingtonSprint; please add your name if you'll be coming. The wiki page can also be used to brainstorm about tasks to work on. While this started out as a Python core sprint, there's no problem if people want to come and work on something other than the Python core (space permitting). I'm still waiting to get an upper limit on attendance, and will add that figure to the wiki page once I get it. --amk ___ 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 long command line options
Am Donnerstag 04 Mai 2006 16:21 schrieb Fredrik Lundh: I'm +1 on adding --help and --version, +1 on adding -? and /? for windows only, -0=slightly sceptical if adding a generic long option machinery is worth it, and -1 on a guessing machinery. I've updated the patch on the SourceForge tracker to reflect this criticism. In effect: 1) --help and --version are added unconditionally on all platforms 2) -? and /? are recognized on Windows, as are /help and /version, because / is just a different longopt-specifier on Windows for the getopt machinery in _PyOS_GetOpt 3) I removed the prefix matching 4) I removed the last reference to a string function in _PyOS_GetOpt 5) --command, which was a test-case for me, has been removed as a long-opt again. The module has undergone a complete rewrite with this patch, and I've adapted the module header to reflect this (because there's absolutely no legacy code left now, which can be seen pretty clearly when you look at a diff...). The usage output in Modules/main.c has also been adapted, as have the test cases in test_cmd_line.py for usage and version, which pass cleanly for me. The patch doesn't produce any warnings on gcc 3.4.6, and I've tested the Windows-specific additions to _PyOS_GetOpt by injecting MS_WINDOWS into the compilation on my system for Python/getopt.c, and it produces correct results on /?, /version, /help, and -?, but as I said before I can't tell whether there are bugs left which surface when it's being compiled on Windows directly, as I don't have a Windows system to test this patch on. Anyway, would be glad to hear any feedback. --- Heiko. ___ 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 long command line options
Am Donnerstag 04 Mai 2006 21:25 schrieb Heiko Wundram: 2) -? and /? are recognized on Windows, as are /help and /version, because / is just a different longopt-specifier on Windows for the getopt machinery in _PyOS_GetOpt Just on a side-note: I chose for '/' to be a long-opt identifier on Windows, because it is for pretty much any Microsoft programming tool out there, starting with the linker, ending with the compiler of MSVC++, amongst others. I know that shell commands such as dir, etc. take / to be similar to - on *nix (as single character command line arguments), but I guess the former is more useful. It's no problem to change this behaviour, though. --- Heiko. ___ 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] context guards, context entry values, context managers, context contexts
fwiw, I just tested http://pyref.infogami.com/with on a live audience, and most people seemed to grok the context guard concept quite quickly. note sure about the context entry value term, though. anyone has a better idea ? /F ___ 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] context guards, context entry values, context managers, context contexts
At 11:20 PM 5/4/2006 +0200, Fredrik Lundh wrote: fwiw, I just tested http://pyref.infogami.com/with on a live audience, and most people seemed to grok the context guard concept quite quickly. note sure about the context entry value term, though. anyone has a better idea ? guarded value? That works for files, at least. ___ 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] PEP 3102: Keyword-only arguments
Terry Reedy wrote: The dispute is about the sensibility and politeness of requiring a small fixed number of required, no-default args to be passed by name only There seems to be some confusion between two different subthreads here. BJörn Lindqvist seemed to be saying that instead of my suggested make_person(=name, =age, =phone, =location) as a substitute for make_person(name=name, age=age, phone=phone, location=location) it would be better to pass the arguments positionally. I was pointing out that you can't do this when the thing you're calling requires them to be passed by keyword. -- 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
