Re: [Python-Dev] Alternative path suggestion

[Mike Orr]

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/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.)


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.

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.


> == a tuple instead of a string ==
>
> The biggest conceptual change is that my path object is a subclass of
> ''tuple'', not a subclass of str. For example,
> {{{
> >>> tuple(path('a/b/c'))
> ('a', 'b', 'c')
> >>> tuple(path('/a/b/c'))
> (path.ROOT, 'a', 'b', 'c')
> }}}


How about  an .isabsolute attribute instead of prepending path.ROOT? 
I can see arguments both ways.  An attribute is easy to query and easy
for str() to use, but it wouldn't show up in a tuple-style repr().


> This means that path objects aren't the string representation of a
> path; they are a ''logical'' representation of a path. Remember why a
> filesystem path is called a path - because it's a way to get from one
> place on the filesystem to another. Paths can be relative, which means
> that they don't define from where to start the walk, and can be not
> relative, which means that they do. In the tuple representation,
> relative paths are simply tuples of strings, and not relative paths
> are tuples of strings with a first "root" element.
>
> The advantage of using a logical representation is that you can forget
> about the textual representation, which can be really complex. You
> don't have to call normpath when you're unsure about how a path looks,
> you don't have to search for seps and altseps, and... you don't need
> to remember a lot of names of functions or methods. To show that, take
> a look at those methods from the original path class and their
> equivalent in my path class:
>
> {{{
> 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
> }}}


All that slicing is cool.


> 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.


That's a big drawback.  PEP 355 can choose between string and
non-string, but this way is limited to non-string.  That raises the
minor issue of changing the open() functions etc in the standard
library, and the major issue of changing them in third-party
libraries.


> Having a logical representation of a path calls for a bit of term
> clearing-up. What's an absolute path? On POSIX, it's very simple: a
> path starting with a '/'. But what about Windows? Is "\temp\file" an
> absolute path? I claim that it isn't really. The reason is that if you
> change the current working directory, its meaning changes: It's now
> not "c:\temp\file", but "a:\temp\file". The same goes for
> "c:temp\file". So I decided on these two definitions:
>
>  * 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.
>
> This means that paths starting with a drive letter alone
> (!UnrootedDrive instance, in my module) and paths starting with a
> backslash alone (the CURROOT object, in my module) are not relative
> and not absolute.


I guess that's plausable.  We'll need feedback from Windows users.


> I really think that it's a better way to handle paths. If you want an
> example, compare the current implementation of relpathto and my
> implementation.


In my enhanced Path class (I posted the docstring last summer), I made
a .relpathfrom() function because .relpathto() was so confusing.


> == Easier attributes for stat objects ==
>
> The current path objects includes:
>  * isdir, isfile, islink, and -
>  * atime, mtime, ctime, size.
> The first line does file mode checking, and the second simply gives
> attributes from the stat object.
>
> I suggest that these should be added to th

Re: [Python-Dev] Alternative path suggestion

[Fredrik Lundh]

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/

 



___
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

[Nick Coghlan]

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 is probably the best way to track this idea.

> 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.

Guido has indicated strong dissatisfaction with the idea of subclassing 
str/unicode with respect to PEP 355. And if you're not subclassing those types 
in order to be able to pass the object transparently to existing APIs, then it 
makes much more sense to choose a sensible internal representation like a 
tuple, so that issues like os.sep can be deferred until they matter.

That's generally been my problem with PEP 355 - a string is an excellent 
format for describing and displaying paths, but its a *hopeless* format for 
manipulating them.

A real data type that acts as a convenience API for the various 
string-accepting filesystem APIs would be a good thing.

>> == a tuple instead of a string ==
>>
>> The biggest conceptual change is that my path object is a subclass of
>> ''tuple'', not a subclass of str.

Why subclass anything? The path should internally represent the filesystem 
path as a list or tuple, but it shouldn't *be* a tuple.

Also, was it a deliberate design decision to make the path objects immutable, 
or was that simply copied from the fact that strings are immutable?

Given that immutability allows the string representation to be calculated once 
and then cached, I'll go with that interpretation.

> tuple(path('/a/b/c'))
>> (path.ROOT, 'a', 'b', 'c')
>> }}}
> 
> How about  an .isabsolute attribute instead of prepending path.ROOT? 
> I can see arguments both ways.  An attribute is easy to query and easy
> for str() to use, but it wouldn't show up in a tuple-style repr().

You can have your cake and eat it too by storing most of the state in the 
internal tuple, but providing convenience attributes to perform certain queries.

This would actually be the criterion for the property/method distinction. 
Properties can be determined solely by inspecting the internal data store, 
whereas methods would require accessing the filesystem.

>> This means that path objects aren't the string representation of a
>> path; they are a ''logical'' representation of a path. Remember why a
>> filesystem path is called a path - because it's a way to get from one
>> place on the filesystem to another. Paths can be relative, which means
>> that they don't define from where to start the walk, and can be not
>> relative, which means that they do. In the tuple representation,
>> relative paths are simply tuples of strings, and not relative paths
>> are tuples of strings with a first "root" element.

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.

Possible values for the path's root element would then be:

   None ==> relative path
   path.ROOT ==> Unix absolute path
   path.DRIVECWD ==> Windows drive relative path
   path.DRIVEROOT ==> Windows drive absolute path
   path.UNCSHARE  ==> UNC path
   path.URL  ==> URL path

The last four would have attributes (the two Windows ones to get at the drive 
letter, the UNC one to get at the share name, and the URL one to get at the 
text of the URL).

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)

The string representation would then be:

   def __str__(self):
   return (str(self.root)
   + os.sep.join(self.path)
   + os.extsep + self.ext)

>> The advantage of using a logical representation is that you can forget
>> about the textual representation, which can be really complex.

As noted earlier - text is a great format for path related I/O. It's a lousy 
format for path manipulation.

>> {{{
>> 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))
>> }}}

These same operations using separate root and path attributes:

p.basename()  -> p[-1]
p.splitpath() -> (p[:-1], p[-1])
p.splitunc()  -> (p.root, p.path)
p.splitall()  -> Isn't needed
p.parent  -> p[:-1]
p.name-> p[-1]
p.drive   -> p.root.drive  (AttributeError if not drive based)
p.uncshare-> p.root.share  (Attribut

Re: [Python-Dev] lambda in Python

[Jay Parlar]

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 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] Alternative path suggestion

[Stefan Rank]

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 rejected if the other is approved.
> 
> I agree that a competing PEP is probably the best way to track this idea.



>>> This means that path objects aren't the string representation of a
>>> path; they are a ''logical'' representation of a path. Remember why a
>>> filesystem path is called a path - because it's a way to get from one
>>> place on the filesystem to another. Paths can be relative, which means
>>> that they don't define from where to start the walk, and can be not
>>> relative, which means that they do. In the tuple representation,
>>> relative paths are simply tuples of strings, and not relative paths
>>> are tuples of strings with a first "root" element.
> 
> 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.
For the same reason I'd like to add two values to the following list:

> Possible values for the path's root element would then be:
> 
>None ==> relative path
   (uses os.sep)
+path.UNIXRELATIVE ==> uses '/'
+path.WINDOWSRELATIVE ==> uses r'\' unconditionally
>path.ROOT ==> Unix absolute path
>path.DRIVECWD ==> Windows drive relative path
>path.DRIVEROOT ==> Windows drive absolute path
>path.UNCSHARE  ==> UNC path
>path.URL  ==> URL path
> 
> The last four would have attributes (the two Windows ones to get at the drive 
> letter, the UNC one to get at the share name, and the URL one to get at the 
> text of the URL).
> 
> 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)
> 
> The string representation would then be:
> 
>def __str__(self):
>return (str(self.root)
>+ os.sep.join(self.path)
>+ os.extsep + self.ext)
> 
>>> The advantage of using a logical representation is that you can forget
>>> about the textual representation, which can be really complex.
> 
> As noted earlier - text is a great format for path related I/O. It's a lousy 
> format for path manipulation.
> 
>>> {{{
>>> 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))
>>> }}}
> 
> These same operations using separate root and path attributes:
> 
> p.basename()  -> p[-1]
> p.splitpath() -> (p[:-1], p[-1])
> p.splitunc()  -> (p.root, p.path)
> p.splitall()  -> Isn't needed
> p.parent  -> p[:-1]
> p.name-> p[-1]
> p.drive   -> p.root.drive  (AttributeError if not drive based)
> p.uncshare-> p.root.share  (AttributeError if not drive based)
> 
>> That's a big drawback.  PEP 355 can choose between string and
>> non-string, but this way is limited to non-string.  That raises the
>> minor issue of changing the open() functions etc in the standard
>> library, and the major issue of changing them in third-party
>> libraries.
> 
> It's not that big a drama, really. All you need to do is call str() on your 
> path objects when you're done manipulating them. The third party libraries 
> don't need to know how you created your paths, only what you ended up with.
> 
> Alternatively, if the path elements are stored in separate attributes, 
> there's 
> nothing stopping the main object from inheriting from str or unicode the way 
> the PEP 355 path object does.
> 
> Either way, this object would still be far more convenient for manipulating 
> paths than a string based representation that has to deal with OS-specific 
> issues on every operation, rather than only during creation and conversion to 
> a string. The path objects would also serve as an OS-independent 
> representation of filesystem paths.
> 
> In fact, I'd leave most of the low-level API's working only on strings - the 
> only one I'd change to accept path objects directly is open() (which would be 
> fairly easy, as that's a factory function now).
> 
>>> This means that paths starting with a drive letter alone
>>> (!UnrootedDrive instance, in my module) and paths starting with a
>>> backslash alone (the CURROOT object, in my module) are no

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

[Nick Coghlan]

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

[Georg Brandl]

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] Python long command line options

[Heiko Wundram]

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 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.

--- 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] Alternative path suggestion

[Nick Coghlan]

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] lambda in Python

[xahlee]

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.

Thanks.

Xah
[EMAIL PROTECTED]
∑ http://xahlee.org/


On 2006 May 4, at 6:21 AM, Jay Parlar wrote:


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 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/xah% 
40xahlee.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

[Paul Moore]

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

[Sanghyeon Seo]

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

[Fredrik Lundh]

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.

 



___
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

[Thomas Wouters]

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

[Stefan Rank]

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

[Georg Brandl]

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

[Vladimir 'Yu' Stepanov]

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 

Re: [Python-Dev] lambda in Python

[Zachery Bir]

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))

[Gustavo Carneiro]

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

[Guido van Rossum]

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

[Guido van Rossum]

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

[Gustavo Niemeyer]

> 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

[Guido van Rossum]

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

[Gustavo Niemeyer]

> 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

[Terry Reedy]

"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

[Martin v. Löwis]

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] Alternative path suggestion

[Terry Reedy]

"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 radical.

Only locally.  Last July, I wrote the following for clp:

http://article.gmane.org/gmane.comp.python.general/412997
Subject: Re: PEP on path module for standard library
Date: 2005-07-22 18:47:00 GMT
"
 Very interesting.  Java's File class is a system-independent "abstract
representation of file and directory pathnames" which is constructed from 
and converted to system-dependent string-form pathnames (including URL/URI 
file:... forms).  A File consist of an optional prefix and a *sequence* of 
zero or more string names.

In other words, Java's File class is what Duncan and I thought Python's
Path class might or possibly should be.  So this internal representation
might be worth considering as an option.  Of course, if the interface is
done right, it mostly should not make too much difference to the user.
"
I believe a previous post gave the reference to the File doc, which might 
be worth consulting.  As I remember, the general response at that time was 
that the existing string-based path class was tried, useful, and well 
accepted, so why try anything more different.  That seems to have become 
clearer with time.

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-checkins] r45898 - in python/trunk: Lib/test/test_os.py Lib/test/test_shutil.py Misc/NEWS Modules/posixmodule.c

[Tim Peters]

[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

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

[Giovanni Bajo]

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 based on
> mixed reviews (a +0.5 and two -0); the comments still seem relevant:
>
> http://www.python.org/sf/592529

I think another way of doing it would be to keep the single module
posixmodule (maybe appropriately renamed) and then internally dispatch
function implementations where possible. If the dispatching is done
correctly (through a fixed size virtual table for all the platforms),
BuildBot should be able to tell you quite fast if you forgot something.

At least, this setup would fix the docstring and the largefile issues raised
in your comment in that bug.
-- 
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] Confirmed: DC-area sprint on Sat. June 3rd

[A.M. Kuchling]

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

[Heiko Wundram]

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

[Heiko Wundram]

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

[Fredrik Lundh]

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

[Phillip J. Eby]

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] context guards, context entry values, context managers, context contexts

[Nick Coghlan]

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 one :)

I'm personally +1 on switching to 'guard' for the following reasons:
   - 'guarding' block entry and exit seems much more natural terminology to me 
than 'managing' entry and exit (since the block entry and exit is really still 
managed by the interpreter - the guard is just given the change to intervene 
in both cases).
   - 'manager' is a pretty generic term ('wooly' as Greg put it), so it needs 
to be qualified a lot more often than 'guard' does.
   - .NET uses 'managed code' in relation to sandboxes (as I understand it), 
so I suspect 'context manager' would up causing at least a bit of confusion in 
relation to IronPython

OTOH, I also think getting rid of __context__() has made the problems with the 
term context manager far less severe, so I'm not averse to the idea of leaving 
it alone, either.

> note sure about the "context entry value" term, though.  anyone
> has a better idea ?

The latest version of the PEP punts on this entirely - for most real use 
cases, you're going to be talking about a specific thing, anyway (such as the 
new decimal context returned by a decimal context manager).

"context entry value" really isn't that much better than "result of the 
__enter__ method", and the latter has the virtue of being explicit. . .

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

[Nick Coghlan]

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 solution than a module for this particular
> use case.

Object vs module isn't my objection to the standard library status quo, either 
- it's the fact that it's a choice of using one object vs 5 or 6 different 
modules ;)

However, I'm going to have to bow out of this discussion for now, too - it's 
interesting, but Python 2.5 is a lot closer than Python 2.6. . .

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] lambda in Python

[Delaney, Timothy (Tim)]

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 Xah?
Based on his past history, I doubt we'll ever see anything useful from
him.

Tim Delaney
___
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

[Greg Ewing]

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
MacOS and VMS, to make sure that it's feasible to fit
them into your tuple-like format.


> The question is, does forcing people to use .stat() expose an
> implementation detail that should be hidden, and does it smell of
> Unixism?  Most people think a file *is* a regular file or a directory.
>  The fact that this is encoded in the file's permission bits -- which
> stat() examines -- is a quirk of Unix.

Permission bits aren't the only thing that stat() examines.
I don't see anything wrong with having stat() be the way to
get at whatever metadata there is about a file on a platform.
And having .isdir etc. attributes on the stat() result
abstracts whether they're obtained from the permission bits
or not.

--
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] Alternative path suggestion

[Greg Ewing]

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 about filenames with multiple suffixes,
such as "spam.tar.gz"? What part of that would you put in
the extension attribute?

--
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] PEP 3102: Keyword-only arguments

[Greg Ewing]

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

[Python-Dev] Python sprint mechanics

[Tim Peters]

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 their time reviewing and doing commits for the
former.

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.  Instead it would make best sense for each
sprint project to work in its own branch, something SVN makes very
easy, but only for those who _can_ commit.  This year's PyCon core
sprint isn't a good model here, as everyone there did have commit
privs -- and that's unusual.

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
want to keep working on their branches after the sprint ends.  Purely
local SVN setups wouldn't work either, since sprint projects will
generally have more than one worker bee, and they need to share code
changes.  There:  I think that's enough to prove I don't have a clue
:-)
___
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 sprint mechanics

[Neal Norwitz]

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 wouldn't really work since people will
> want to keep working on their branches after the sprint ends.  Purely
> local SVN setups wouldn't work either, since sprint projects will
> generally have more than one worker bee, and they need to share code
> changes.  There:  I think that's enough to prove I don't have a clue

I guess that means it's my turn to let my ignorance shine yet again.  :-)

Could we take a snapshot of the SVN repo, hosted on python.org, open
it up for public commit during the period?

That seems easy to setup.  The difficulty would come in when we need
to merge back to the real SVN.

n
___
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 sprint mechanics

[Martin v. Löwis]

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
> want to keep working on their branches after the sprint ends.  Purely
> local SVN setups wouldn't work either, since sprint projects will
> generally have more than one worker bee, and they need to share code
> changes.

I think Fredrik Lundh points to svk at such occasions.

People usually get commit privileges when they have demonstrates to
simultaneously meet a number of requirements, such as
- following style guides
- never committing anything without discussion which might cause
  strong opposition
- always committing tests and documentation along with the actual
  code changes
- licensing all of their own changes to the PSF
- ...more things I can't put into words right now.
Of course, many committers miss some of these rules some of
the time, but I hope they all feel guilty when doing so :-)

It might be reasonable to waive the "have demonstrated" part for
some group of people, i.e. give them commit privs after telling
them what the rules are. However, in this case, I'd would really
like to see some "shepherd" who oversees this group of people.
gcc has a "commit-after-approval" privilege; if you have that,
you can only commit after somebody (a "maintainer") has approved
a change. Approvals are 'on file' in a mailing list archive.

I could imagine such a model for sprint participants, if
there would be somebody to volunteer as a shepherd. That person
would have to track the status of the individual projects,
and either revoke commit privs when the project is eventually
completed, or grant the contributors permanent (without-approval)
commit privs if he considers this appropriate.

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 sprint mechanics

[Anthony Baxter]

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 are considered for landing on the trunk. Massive refactorings 
really don't fill me with happy thoughts.

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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]

"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 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.

At present, Python allows this as a choice.

> I was pointing out that you can't do this when the thing you're
> calling requires them to be passed by keyword.

My point has been that the function writer should not make such a 
requirement (for four no-defaut, required params) and that proposing to do 
so with the proposed '*' is an abuse (for public code).  The caller should 
continue to be allowed to make the choice.  Again, this case is completely 
different from the case of numerous optional args that you brought up.

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