Éric Araujo added the comment:
Agreed, a doc PR to warn against using any of the distutils *util modules would
be useful.
--
assignee: eric.araujo ->
components: +Documentation -Distutils
resolution: works for me ->
stage: resolved -> needs patch
status: closed -> pending
versions:
Ivan Tashev added the comment:
distutils.dir_util is easily found in the documentation. If this behaviour is
not fixed, at least the docs should state dir_util is not recommended for
public use.
--
nosy: +ivtashev
___
Python tracker
Malcolm Smith added the comment:
Please reopen this issue. The distutils2 project has now been abandoned, so
that's no longer a justification for taking no action.
At the very least, the documentation should be fixed to either warn about this
surprising behavior, or make it clear that the
Éric Araujo mer...@netwok.org added the comment:
So It is better to define what a public function is.
That is no easy task. See #10894 for a general discussion. For the particular
case of distutils, there is no distinction between internal helpers that we
should be free to change and public
Diego Queiroz queiroz.di...@gmail.com added the comment:
I would agree if mkpath were a public function.
So It is better to define what a public function is. Any function in any
module of any project, if it is indented to be used by other modules, it is
public by definition.
If new people get
New submission from Diego Queiroz queiroz.di...@gmail.com:
There is a problem with dir_util cache (defined by _path_created global
variable).
It appears to be useful but it isn't, just repeat these steps to understand the
problem I'm facing:
1) Use mkpath to create any path (eg.
Éric Araujo mer...@netwok.org added the comment:
Thanks for the report and diagnosis. Why does your application randomly
removes files created by distutils?
--
assignee: tarek - eric.araujo
versions: +Python 3.2 -Python 2.5, Python 2.6
___
Python
Diego Queiroz queiroz.di...@gmail.com added the comment:
Well. My application does not actually randomly remove the folders, it just
can't guarantee for a given process how the folder it created will be deleted.
I have many tasks running on a cluster using the same disk. Some tasks creates
Éric Araujo mer...@netwok.org added the comment:
Maybe I’m tired, but I don’t understand why your application would remove
directories that distutils creates. We’ve fixed a bug related to a race
condition when *creating* directories (#9281), but behaving sanely on an
unstable tree seems
Diego Queiroz queiroz.di...@gmail.com added the comment:
Suppose the application creates one folder and add some data to it:
- /scratch/a/b/c
While the application is still running (it is not using the folder anymore),
you see the data, copy it to somewhere and delete everything manually
Éric Araujo mer...@netwok.org added the comment:
“Maybe distutils package was not designed for the purpose I am using it (I am
not using it to install python modules or anything), but this behavior is not
well documented anyway.” Aaaah, I had no idea you were using the function
directly for
Diego Queiroz queiroz.di...@gmail.com added the comment:
You were right, os.makedirs fits my needs. :-)
Anyway, I still think the change in the documentation is needed.
This is not an implementation detail, it is part of the way the function works.
The user should be aware of the behavior when
Éric Araujo mer...@netwok.org added the comment:
“This is not an implementation detail, it is part of the way the function
works. The user should be aware of the behavior when [they] call this function
twice.”
I would agree if mkpath were a public function. I think it’s an implementation
13 matches
Mail list logo
