On 10/31/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > Why is 'split' in os.path but 'stat' and 'mkdir' and 'remove' are in
> > os? Don't they all operate on paths?
>
> no. are you saying that you're unable to see the conceptual difference
> between a name and an object?
I see the differenc
More comments...
Mike Orr wrote:
> Talin wrote:
>> 1) Does os.path need to be refactored at all?
>
> Yes. Functions are scattered arbitrarily across six modules: os,
> os.path, shutil, stat, glob, fnmatch. You have to search through five
> scattered doc pages in the Python library to find your
>p = os.path.normpath( os.path.join( __file__, "../..", "lib" ) )
Shouldn't an example avoid using the path separator directly within a
string literal?
p = path.normpath(path.join(__file__, "..", "..", "lib"))
--
Michael Urman
___
Python-3
On Wed, Nov 01, 2006 at 08:03:55AM -0600, Michael Urman wrote:
> >p = os.path.normpath( os.path.join( __file__, "../..", "lib" ) )
>
> Shouldn't an example avoid using the path separator directly within a
> string literal?
>
> p = path.normpath(path.join(__file__, "..", "..", "lib"))
On 10/29/06, Gary Stephenson <[EMAIL PROTECTED]> wrote:
> I would like to suggest the spelling "free", as I believe the term "free
> variable" has been widely used to describe the concept (albeit
> usually in reference to undeclared variables.)
They are currently called free variables (or cell va
Hi folks,
I have finally completed a draft of a PEP on rebinding of names
in outer scopes. I've tried to go back and gather all of the
(amazingly numerous) proposals -- if i've forgotten or misattributed
any, let me know and i'll be happy to correct them.
I look forward to your thoughts on it:
I wrote:
> I have finally completed a draft of a PEP on rebinding of names
[...]
> http://zesty.ca/python/pep-3104.txt
I've turned this into HTML also, in case you find that easier to read:
http://zesty.ca/python/pep-3104.html
-- ?!ng
___
Pyth
Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 01, 2006 at 08:03:55AM -0600, Michael Urman wrote:
> > >p = os.path.normpath( os.path.join( __file__, "../..", "lib" ) )
> >
> > Shouldn't an example avoid using the path separator directly within a
> > string literal?
> >
> > p
Michael Urman wrote:
>>p = os.path.normpath( os.path.join( __file__, "../..", "lib" ) )
>
> Shouldn't an example avoid using the path separator directly within a
> string literal?
>
>p = path.normpath(path.join(__file__, "..", "..", "lib"))
No need. 'normpath' will automatically conv
Talin wrote:
> Now, that being said, I wouldn't have a problem with there being an
> "abstract filesystem object" that represents an entity on disk (be it
> file, directory, etc.), which would have a path inside it that would do
> some of the things you suggest.
I think this option should be e
On Wed, Nov 01, 2006 at 08:32:08AM -0800, Josiah Carlson wrote:
> > p = path.normpath(path.join(__file__, os.pardir, os.pardir, "lib"))
>
> What operating systems that Python currently supports doesn't have ".."
> mean "parent directory"?
macpath.py defines pardir = '::'. MacOS 9, probably.
O
Oleg Broytmann <[EMAIL PROTECTED]> wrote:
>
> On Wed, Nov 01, 2006 at 08:32:08AM -0800, Josiah Carlson wrote:
> > > p = path.normpath(path.join(__file__, os.pardir, os.pardir, "lib"))
> >
> > What operating systems that Python currently supports doesn't have ".."
> > mean "parent directory"?
>
On 1 Nov 2006, at 15:17, Ka-Ping Yee wrote:
> I have finally completed a draft of a PEP on rebinding of names
> in outer scopes.
Nice summary - thanks for all the work.
> I look forward to your thoughts on it:
Minor point: it might be worth mentioning (in the section "Rebinding
Operator") that
?!ng writes:
> I have finally completed a draft of a PEP on rebinding of names
> in outer scopes. I've tried to go back and gather all of the
> (amazingly numerous) proposals
And you've done an astonishingly good job of it. The amount of
history in this PEP is impressive, and it demonstrates the
The thread on python-dev has been revived, so those interested in this
subject will want to look in both places.
On 11/1/06, Talin <[EMAIL PROTECTED]> wrote:
> Actually I generally use:
>
>p = os.path.normpath( os.path.join( __file__, "../..", "lib" ) )
>
> or even:
>
>p = os.path.
"Mike Orr" <[EMAIL PROTECTED]> writes:
> /a/b/../c# Previous component is always a directory, so eliminate.
This is not equivalent to a/c on Unix if b is a symlink to a directory,
because .. goes to the parent of the target of the symlink.
--
__("< Marcin Kowalczyk
\__/
Ka-Ping Yee wrote:
> Hi folks,
>
> I have finally completed a draft of a PEP on rebinding of names
> in outer scopes. I've tried to go back and gather all of the
> (amazingly numerous) proposals -- if i've forgotten or misattributed
> any, let me know and i'll be happy to correct them.
>
> I look
On 11/1/06, Neil Toronto <[EMAIL PROTECTED]> wrote:
> Ka-Ping Yee wrote:
> > I have finally completed a draft of a PEP on rebinding of names
> > in outer scopes. I've tried to go back and gather all of the
> > (amazingly numerous) proposals -- if i've forgotten or misattributed
> > any, let me kno
On 11/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 11/1/06, Neil Toronto <[EMAIL PROTECTED]> wrote:> Ka-Ping Yee wrote:> > I have finally completed a draft of a PEP on rebinding of names> > in outer scopes. I've tried to go back and gather all of the
> > (amazingly numerous) proposals -- i
Guido van Rossum wrote:
> My personal preference is still to abuse 'global' instead of adding a
> new, ugly keyword. That would make the syntax for global and nonlocal
> completely identical. :-) But I seem to be alone in this preference.
You're not alone -- I'd be happy with that, too.
I don't e
Ka-Ping Yee wrote:
> Hi folks,
>
> I have finally completed a draft of a PEP on rebinding of names
> in outer scopes. I've tried to go back and gather all of the
> (amazingly numerous) proposals -- if i've forgotten or misattributed
> any, let me know and i'll be happy to correct them.
>
> I loo
Hi again.
I've updated the PEP to incorporate some suggestions i received.
This revision also adds a Ruby example, a quote from 1994, a
security argument, and and an additional error case (attempting
to declare a parameter name nonlocal). Thanks, everyone!
http://zesty.ca/python/pep-3104.txt
Guido wrote:
> My personal preference is still to abuse 'global' instead of adding a
> new, ugly keyword. That would make the syntax for global and nonlocal
> completely identical. :-) But I seem to be alone in this preference.
Brett wrote:
> Seeing Guido have a sad face is enough to force me to h
>Guido wrote:
>> My personal preference is still to abuse 'global' instead of adding a
>> new, ugly keyword. That would make the syntax for global and nonlocal
>> completely identical. :-) But I seem to be alone in this preference.
>
>Brett wrote:
>> Seeing Guido have a sad face is enough to force
"Andrew McNamara" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> >Guido wrote:
>>> My personal preference is still to abuse 'global' instead of adding a
>>> new, ugly keyword. That would make the syntax for global and nonlocal
>>> completely identical. :-) But I seem to be alone in
Guido wrote:
> My personal preference is still to abuse 'global' instead of adding a
> new, ugly keyword. That would make the syntax for global and nonlocal
> completely identical. :-) But I seem to be alone in this preference.
Brett wrote:
> Seeing Guido have a sad face is enough to force me to h
Ka-Ping Yee wrote:
> Would it help at all to survey some folks to see how many interpret
> "global variable" to mean "top-level" vs. "anything nonlocal"?
Steven Bethard wrote:
> I don't think that'll really be worth it. I'd be amazed if people
> didn't expect it to mean "top-level".
If that's a
On 11/1/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> I think a fairer survey example would be something like this:
>
> n = 1
> def f():
> n = 2
> def g():
> global n = 99
> return n
> g()
>
> f()
> print n
>
> Which 'n' do you expect g
I wrote:
> I'm convinced that "global variable" means top-level for most
> programmers and so this usage would be confusing -- but i think we're
> all just repeating what we've said before.
Andrew McNamara wrote:
> But it doesn't mean "top-level" - it already comes with the qualifier
> "module".
Mike Orr wrote:
> P.stat().mtime and P.lstat().mtime look a lot better than P.mtime()
> and P.lmtime()
Another thing to consider is that stat() potentially
lets you enquire about multiple attributes without
making a system call for each one.
--
Greg
__
>Andrew McNamara wrote:
>> But it doesn't mean "top-level" - it already comes with the qualifier
>> "module".
>
>This is exactly what "global variable" means in C, Perl, JavaScript,
>Ruby, etc.
>
>The global scope is the widest scope in which you can declare a variable.
This is inaccurate at best.
Michael Urman wrote:
>> p = os.path.normpath( os.path.join( __file__, "../..", "lib" ) )
>
> Shouldn't an example avoid using the path separator directly within a
> string literal?
And avoid using a platform-specific parent
directory specifier:
p = path.normpath(path.join(__file__, os.p
Jim Jewett wrote:
> I'll suggest "reuse"
>
> reuse myoutvar
But to me that sounds like you're shadowing myoutvar,
which is completely the wrong idea.
--
Greg
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listi
Guido van Rossum wrote:
>> > A shorthand form is also permitted, in which nonlocal is prepended to
>> > an assignment or augmented assignment statement:
>> >
>> > nonlocal x = 3
>>
>> Is a similar statement for globals legal in Py3k? It's not in 2.4
>> (according to my own testing) or 2.5
On Nov 1, 2006, at 8:07 PM, Josiah Carlson wrote:
Oleg Broytmann <[EMAIL PROTECTED]> wrote:
On Wed, Nov 01, 2006 at 08:32:08AM -0800, Josiah Carlson wrote:
p = path.normpath(path.join(__file__, os.pardir, os.pardir, "lib"))
What operating systems that Python currently supports doesn't
h
Posted to python-dev and python-3000. Follow-ups to python-dev only please.
On 10/31/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> here's mine; it's fully backwards compatible, can go right into 2.6,
> and can be incrementally improved in future releases:
>
> 1) add a pathname wrapper to "
36 matches
Mail list logo
