On 7/28/2010 4:42 AM, Ray Allen wrote:
I believe, in design purpose, the os.mkdir() is to match the system call
"mkdir()" exactly, the os.makedirs() is a "Super-mkdir", it provides
extra convenience for using when we want to create directories. This is
the case makedirs() should deal with.
Aft
I believe, in design purpose, the os.mkdir() is to match the system call
"mkdir()" exactly, the os.makedirs() is a "Super-mkdir", it provides
extra convenience for using when we want to create directories. This is the
case makedirs() should deal with. A new function maybe confused with
makedirs().
On 28/07/2010 11:53, Greg Ewing wrote:
Hrvoje Niksic wrote:
mktree would only create a single "branch", not an entire tree.
Maybe mkbranch, then?
Seeing as we already have a decision to add this functionality to
os.makedirs as a switch and not to create a new function, this
bikeshedding see
Hrvoje Niksic wrote:
mktree would only create a
single "branch", not an entire tree.
Maybe mkbranch, then?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.o
Hrvoje Niksic writes:
> single "branch", not an entire tree. I'd imagine a mktree function to
> accept a data structure describing the tree to be created.
-1 on mktree for that reason.
> If you're going for a short name distinctive from mkdir, I propose
> mksubdirs.
A little more accurat
On 07/27/2010 06:18 PM, Alexander Belopolsky wrote:
On Tue, Jul 20, 2010 at 10:20 AM, R. David Murray wrote:
I'd go with putting it in shutil.
+1
I would also call it shutil.mktree which will go well with
shutil.rmtree next to it.
Note that mktree is not analogous to rmtree - while rmtree
On Tue, Jul 20, 2010 at 10:20 AM, R. David Murray wrote:
> I'd go with putting it in shutil.
+1
I would also call it shutil.mktree which will go well with
shutil.rmtree next to it.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
Greg Ewing writes:
> Ray Allen wrote:
>
> > I think in this case, the errno is generate by c standard library,
> > which can be seen as cross-platform.
>
> But I'm never sure how standard the actual error numbers are, though.
You can use them by name, and in fact I strongly recommend it:
im
Ray Allen wrote:
I think in this case, the errno is generate by c standard library, which
can be seen as cross-platform.
But I'm never sure how standard the actual error
numbers are, though. I tend to think of them as
coming from Unix-land, and thus fair game for
getting screwed around with on
Hey folks,
On 21 July 2010 10:37, Greg Ewing wrote:
> Steven D'Aprano wrote:
>>
>> Perhaps all we need is a recipe in the docs:
>>
>> try:
>> os.makedirs(path)
>> except OSError, e:
>> if e.errno != 17:
>> raise
>
> I don't like writing code that depends on particular
> errno values,
>
> I don't see what would be so bad about adding a new
function for this. Think of it as correcting the mistake
of not making makedirs() behave this way from the
beginning.
If you want to add a new function, then what its name should be? I guess it
should be too similar as existing ones. It'
Steven D'Aprano wrote:
Perhaps all we need is a recipe in the docs:
try:
os.makedirs(path)
except OSError, e:
if e.errno != 17:
raise
I don't like writing code that depends on particular
errno values, because I don't trust it to work cross-
platform.
Also it seems suboptimal t
岳帅杰 wrote:
Sorry, I don't know what is the "no constant arguments" guideline refers
to. Could you give me some more explanation?
It's a rule of thumb that Guido says he uses when
designing an API. If in the majority of use cases for
a proposed function, one of its arguments would always
be a co
On Tue, Jul 20, 2010 at 11:35 PM, Cameron Simpson wrote:
> On 20Jul2010 17:49, Michael Foord wrote:
> | On 20/07/2010 14:43, Nick Coghlan wrote:
> | >On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano
> wrote:
> | >>I'm -0 on adding an argument to os.makedirs, +0 on adding a variant
> | >>functi
On 20Jul2010 17:49, Michael Foord wrote:
| On 20/07/2010 14:43, Nick Coghlan wrote:
| >On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano
wrote:
| >>I'm -0 on adding an argument to os.makedirs, +0 on adding a variant
| >>function to os, and +0.5 on adding the variant to the shutil module.
| >shut
On 07/20/2010 12:00 PM, Fred Drake wrote:
On Tue, Jul 20, 2010 at 12:47 PM, Ron Adam wrote:
It doesn't fall under the single constant rule if done this way.
If the value for 'allow' were almost always given as a constant, this
would be an argument for three functions instead of one.
The gu
Michael Foord wrote:
> On 20/07/2010 14:43, Nick Coghlan wrote:
> > On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano
> > wrote:
> >
> >> I'm -0 on adding an argument to os.makedirs, +0 on adding a variant
> >> function to os, and +0.5 on adding the variant to the shutil module.
> >>
On 7/20/2010 12:49 PM, Michael Foord wrote:
On 20/07/2010 14:43, Nick Coghlan wrote:
On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano
wrote:
I'm -0 on adding an argument to os.makedirs, +0 on adding a variant
function to os, and +0.5 on adding the variant to the shutil module.
shutil seems li
On Tue, Jul 20, 2010 at 12:47 PM, Ron Adam wrote:
> It doesn't fall under the single constant rule if done this way.
If the value for 'allow' were almost always given as a constant, this
would be an argument for three functions instead of one.
The guideline has little to do with the type of the
On 07/20/2010 11:47 AM, Ron Adam wrote:
On 07/20/2010 10:43 AM, Fred Drake wrote:
On Tue, Jul 20, 2010 at 9:09 AM, Steven D'Aprano
wrote:
It refers to the guideline that you shouldn't have a single function
with two (or more) different behaviour and an argument that does
nothing but select
On 20/07/2010 14:43, Nick Coghlan wrote:
On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano wrote:
I'm -0 on adding an argument to os.makedirs, +0 on adding a variant
function to os, and +0.5 on adding the variant to the shutil module.
shutil seems like the place for it to me. The sub
On 07/20/2010 10:43 AM, Fred Drake wrote:
On Tue, Jul 20, 2010 at 9:09 AM, Steven D'Aprano wrote:
It refers to the guideline that you shouldn't have a single function
with two (or more) different behaviour and an argument that does
nothing but select between them.
In particular, when that a
On Tue, Jul 20, 2010 at 9:09 AM, Steven D'Aprano wrote:
> It refers to the guideline that you shouldn't have a single function
> with two (or more) different behaviour and an argument that does
> nothing but select between them.
In particular, when that argument is almost never given a variable
v
I'd go with putting it in shutil. We could also add a function there
that wraps up the recipe in issue 9311 to work around the quirks of
os.access on FreeBSD (and possibly other platforms).
--
R. David Murray www.bitdance.com
__
On Tue, 20 Jul 2010, Steven D'Aprano wrote:
I tend to agree. Perhaps all we need is a recipe in the docs:
try:
os.makedirs(path)
except OSError, e:
if e.errno != 17:
raise
What if the path or a parent of it already exists as a file? If one has
requested -p I believe one typical
On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano wrote:
> I'm -0 on adding an argument to os.makedirs, +0 on adding a variant
> function to os, and +0.5 on adding the variant to the shutil module.
shutil seems like the place for it to me. The subtlety of getting the
error suppression correct mak
On Tue, 20 Jul 2010 06:49:44 pm 岳帅杰 wrote:
> Sorry, I don't know what is the "no constant arguments" guideline
> refers to. Could you give me some more explanation?
It refers to the guideline that you shouldn't have a single function
with two (or more) different behaviour and an argument that doe
Sorry, I don't know what is the "no constant arguments" guideline refers to.
Could you give me some more explanation?
By the way, I feel adding separate functions is not quiet worthy for such a
function.
On Tue, Jul 20, 2010 at 7:11 AM, Greg Ewing wrote:
> Ray Allen wrote:
>
> I think both os.m
Ray Allen wrote:
I think both os.mkdir() and
os.makedirs() should add a keyword argument to suppress the "OSError:
[Errno 17] File exists".
This could be seen as violating the "no constant arguments"
guideline. Maybe separate function would be better?
--
Greg
See http://bugs.python.org/issue9299
On Mon, Jul 19, 2010 at 1:16 PM, Ray Allen wrote:
>
> Agree. Through searching for existing issues, I found there isn't any such
> request. And I will submit one.
>
> The '-p' option of shell's mkdir has tow functions:
> 1, create parents directories if n
Agree. Through searching for existing issues, I found there isn't any such
request. And I will submit one.
The '-p' option of shell's mkdir has tow functions:
1, create parents directories if not exists,
2, suppress "File exists" error if the target has already exists.
What we need is the
Tim Golden wrote:
That said, it's not clear just how far the stdlib should go to
mimic every switch and option of shell commands...
I don't think it's a matter of mimicking switches just because
they're there.
The operation of "make sure this directory and all its parents
exist" is very commo
On Sun, Jul 18, 2010 at 11:30 AM, Tim Golden wrote:
> On 17/07/2010 11:03 PM, Peng Yu wrote:
>>
>> I don't see that there is a function in the library that mimic the
>> behavior of 'mkdir -p'. If 'makedirs' is used, it will generate an
>> error if the file already exists. There are some functions
On 17/07/2010 11:03 PM, Peng Yu wrote:
I don't see that there is a function in the library that mimic the
behavior of 'mkdir -p'. If 'makedirs' is used, it will generate an
error if the file already exists. There are some functions available
on the website to close the gap. But I'd prefer this is
On 17/07/2010 23:03, Peng Yu wrote:
I don't see that there is a function in the library that mimic the
behavior of 'mkdir -p'. If 'makedirs' is used, it will generate an
error if the file already exists. There are some functions available
on the website to close the gap. But I'd prefer this is in
35 matches
Mail list logo
