Re: [Python-Dev] PEP 3102: Keyword-only arguments

"Greg Ewing" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] 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 diff

Re: [Python-Dev] Python sprint mechanics

On Friday 05 May 2006 15:16, Tim Peters wrote: > While that may be unavoidable for Bug Days, a major difference for > the sprint is that little of the code is likely _intended_ to end > up on the trunk at this time. Given where we are in the 2.5 release cycle, I'd _hope_ that only safe changes a

Re: [Python-Dev] Python sprint mechanics

Tim Peters wrote: > Since I hope we see a lot more of these problems in the future, what > can be done to ease the pain? I don't know enough about SVN admin to > know what might be realistic. Adding a pile of "temporary > committers" comes to mind, but wouldn't really work since people will > wa

Re: [Python-Dev] Python sprint mechanics

On 5/4/06, Tim Peters <[EMAIL PROTECTED]> wrote: > > Since I hope we see a lot more of these problems in the future, what Me too. > can be done to ease the pain? I don't know enough about SVN admin to > know what might be realistic. Adding a pile of "temporary > committers" comes to mind, but

[Python-Dev] Python sprint mechanics

There's going to be a Python sprint in Iceland later this month, and it raises some management issues we also see on Bug Days, but more so: a relatively large number of people slinging code without commit privileges, and a relative handful with commit privileges. The latter end up spending all th

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 sug

Re: [Python-Dev] Alternative path suggestion

Nick Coghlan wrote: > Similarly, I would separate out the extension to a distinct attribute, as it > too uses a different separator from the normal path elements ('.' most > places, > but '/' on RISC OS, for example) -1. What constitutes "the extension" is not well-defined in all cases. What a

Re: [Python-Dev] Alternative path suggestion

Mike Orr wrote: > The main difficulty with this approach is it's so radical. It would > require a serious champion to convince people it's as good as our > tried-and-true strings. Another thing you would need to do is implement it for some of the less Unix-like path syntaxes, such as Classic Mac

Re: [Python-Dev] lambda in Python

Guido van Rossum wrote: > Reminder: the best way to get rid of a troll is to ignore him. Indeed. Xah got past Spambayes for me because this time he posted on Python-dev - I doubt that he'll get past Spambayes again by doing that :) Should we add an explicit rule to the Python-dev spam filter for

Re: [Python-Dev] Alternative path suggestion

Guido van Rossum wrote: > 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 soluti

Re: [Python-Dev] context guards, context entry values, context managers, context contexts

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. Compared to the various other changes made lately to PEP 343, s/manager/guard/ would be a fairly straightforward

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 ? "gu

[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 ? ___ Python-Dev

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

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 tracke

[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 ; please add your name if you'll be coming. The wiki page can also be used to brainstorm a

Re: [Python-Dev] [Python-checkins] r45898 - in python/trunk:Lib/test/test_os.py Lib/test/test_shutil.py Misc/NEWSModules/posixmodule.c

Tim Peters wrote: > [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

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

Re: [Python-Dev] Alternative path suggestion

"Mike Orr" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Intriguing idea, Noam, and excellent thinking. I'd say it's worth a > separate PEP. I am glad to see this idea resurface and developed. So +1 on an alternate PEP. > The main difficulty with this approach is it's so radi

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

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, locati

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:/

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 is

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 i

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 particul

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

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 = _dlope

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 woul

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 environme

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

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

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

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 th

[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

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 spe

Re: [Python-Dev] lambda in Python

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 c

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 wa

Re: [Python-Dev] Python long command line options

Am Donnerstag 04 Mai 2006 15:41 schrieb Georg Brandl: > Heiko Wundram wrote: > > 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. The code for the above f

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 a

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 am

Re: [Python-Dev] Alternative path suggestion

on 04.05.2006 14:57 Nick Coghlan said the following: > Mike Orr wrote: >> Intriguing idea, Noam, and excellent thinking. I'd say it's worth a >> separate PEP. It's too different to fit into PEP 355, and too big to >> be summarized in the "Open Issues" section. Of course, one PEP will >> be rejec

Re: [Python-Dev] lambda in Python

On May 4, 2006, at 6:00 AM, Talin wrote: > xahlee 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 make

Re: [Python-Dev] Alternative path suggestion

Mike Orr wrote: > Intriguing idea, Noam, and excellent thinking. I'd say it's worth a > separate PEP. It's too different to fit into PEP 355, and too big to > be summarized in the "Open Issues" section. Of course, one PEP will > be rejected if the other is approved. I agree that a competing PEP

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

Re: [Python-Dev] Alternative path suggestion

On 5/2/06, Noam Raphael <[EMAIL PROTECTED]> wrote: > Here are my ideas. It's a copy of what I posted a few minutes ago in > the wiki - you can view it at > http://wiki.python.org/moin/AlternativePathClass (it looks better > there). > > You can find the implementation at > http://wiki.python.org/moi