On 29Feb2016 00:47, Alan Bawden wrote:
Cameron Simpson writes:
On 22Feb2016 12:34, Alan Bawden wrote:
I have deleted the part of discussion where it seems that we must simply
agree to disagree. You think mktemp() is _way_ more dangerous that I
do.
I certainly think the habit of using it
Cameron Simpson writes:
> On 22Feb2016 12:34, Alan Bawden wrote:
I have deleted the part of discussion where it seems that we must simply
agree to disagree. You think mktemp() is _way_ more dangerous that I
do.
>>> In fact your use case isn't safe, because _another_ task using mktemp
>>> in co
On Tue, Feb 23, 2016, at 03:22, Paul Rubin wrote:
> Thanks. It would be nice if those were gatewayed to usenet like this
> group is. I can't bring myself to subscribe to mailing lists.
Have you tried gmane?
--
https://mail.python.org/mailman/listinfo/python-list
On 2016-02-25, Steven D'Aprano wrote:
> The links already provided go through the evidence. For example, they
> explain that /dev/random and /dev/urandom both use the exact same CSPRNG. If
> you don't believe that, you can actually read the source to Linux, FreeBSD,
> OpenBSD and NetBSD. (But n
On Thursday 25 February 2016 17:54, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> On Wednesday 24 February 2016 18:20, Marko Rauhamaa wrote:
>>> Steven D'Aprano :
And that is where you repeat something which is rank superstition.
>>>
>>> Can you find info to back that up.
>>
>> The links a
Steven D'Aprano :
> On Wednesday 24 February 2016 18:20, Marko Rauhamaa wrote:
>> Steven D'Aprano :
>>> And that is where you repeat something which is rank superstition.
>>
>> Can you find info to back that up.
>
> The links already provided go through the evidence. For example, they
> explain
On Wednesday 24 February 2016 18:20, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> On Tue, 23 Feb 2016 05:54 pm, Marko Rauhamaa wrote:
>>> However, when you are generating signing or encryption keys, you
>>> should use /dev/random.
>>
>> And that is where you repeat something which is rank super
On Tue, 23 Feb 2016 07:22 pm, Paul Rubin wrote:
> Mark Lawrence writes:
>> https://mail.python.org/pipermail/python-ideas/2015-September/036333.html
>> then http://www.gossamer-threads.com/lists/python/dev/1223780
>
> Thanks. It would be nice if those were gatewayed to usenet like this
> group
Steven D'Aprano :
> On Tue, 23 Feb 2016 05:54 pm, Marko Rauhamaa wrote:
>> However, when you are generating signing or encryption keys, you
>> should use /dev/random.
>
> And that is where you repeat something which is rank superstition.
Can you find info to back that up. All I've seen so far is
On Tue, 23 Feb 2016 05:54 pm, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> On Tue, 23 Feb 2016 06:32 am, Marko Rauhamaa wrote:
>>> Under Linux, /dev/random is the way to go when strong security is
>>> needed. Note that /dev/random is a scarce resource on ordinary
>>> systems.
>>
>> That's actua
Paul Rubin :
> Marko Rauhamaa writes:
>> It is also correct that /dev/urandom depletes the entropy pool as
>> effectively as /dev/random.
>
> I think see what's confusing you: the above is a misconception that is
> probably held by lots of people. Entropy is not water and from a
> cryptographic
On 2016-02-23, Mark Lawrence wrote:
> On 23/02/2016 08:22, Paul Rubin wrote:
>> Mark Lawrence writes:
>>> https://mail.python.org/pipermail/python-ideas/2015-September/036333.html
>>> then http://www.gossamer-threads.com/lists/python/dev/1223780
>>
>> Thanks. It would be nice if those were gatew
On 23/02/2016 08:22, Paul Rubin wrote:
Mark Lawrence writes:
https://mail.python.org/pipermail/python-ideas/2015-September/036333.html
then http://www.gossamer-threads.com/lists/python/dev/1223780
Thanks. It would be nice if those were gatewayed to usenet like this
group is. I can't bring m
Paul Rubin wrote:
> Mark Lawrence writes:
>> https://mail.python.org/pipermail/python-ideas/2015-September/036333.html
>> then http://www.gossamer-threads.com/lists/python/dev/1223780
>
> Thanks. It would be nice if those were gatewayed to usenet like this
> group is. I can't bring myself to s
Mark Lawrence writes:
> https://mail.python.org/pipermail/python-ideas/2015-September/036333.html
> then http://www.gossamer-threads.com/lists/python/dev/1223780
Thanks. It would be nice if those were gatewayed to usenet like this
group is. I can't bring myself to subscribe to mailing lists.
>
On 23/02/2016 02:27, Paul Rubin wrote:
Steven D'Aprano writes:
https://www.python.org/dev/peps/pep-0506/
I didn't know about this! The discussion was all on mailing lists?
https://mail.python.org/pipermail/python-ideas/2015-September/036333.html then
http://www.gossamer-threads.com/lists/
Marko Rauhamaa writes:
> It is also correct that /dev/urandom depletes the entropy pool as
> effectively as /dev/random.
I think see what's confusing you: the above is a misconception that is
probably held by lots of people. Entropy is not water and from a
cryptographic standpoint there is esse
Steven D'Aprano :
> On Tue, 23 Feb 2016 06:32 am, Marko Rauhamaa wrote:
>> Under Linux, /dev/random is the way to go when strong security is
>> needed. Note that /dev/random is a scarce resource on ordinary
>> systems.
>
> That's actually incorrect, but you're not the only one to have been
> misle
Chris Angelico writes:
> How much future are you expecting?
This is old but its methodology still seems ok:
http://saluc.engr.uconn.edu/refs/keymgr/blaze95minimalkeylength.pdf
I also like this:
http://cr.yp.to/talks/2015.10.05/slides-djb-20151005-a4.pdf
Quote (slide 37):
The crypto us
On Tue, Feb 23, 2016 at 1:27 PM, Paul Rubin wrote:
> 3) The default token length should be long enough to not have to "change
> in the future". If the user wants a shorter token, they ask for that,
> or can truncate a longer one that they receive from the default.
How much future are you e
Steven D'Aprano writes:
> https://www.python.org/dev/peps/pep-0506/
I didn't know about this! The discussion was all on mailing lists?
A few things I suggest changing:
1) the default system RNG for Linux should be getrandom(2) on kernels
that support it (3.17 and later).
2) Some effort
On 2016-02-23, Ben Finney wrote:
> Oscar Benjamin writes:
>> What does unpredictable mean in this context? Maybe I'm reading too
>> much into that...
>
> I think you may be, yes. The request in this thread requires making
> direct use of the “generate a new valid temporary fielsystem path”
> func
On Tue, Feb 23, 2016 at 11:44 AM, Jon Ribbens
wrote:
> On 2016-02-23, Chris Angelico wrote:
>> On Tue, Feb 23, 2016 at 11:26 AM, Jon Ribbens
>> wrote:
>>> On 2016-02-23, Chris Angelico wrote:
On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
wrote:
>> If you generate 2**128 + 1 such nu
On 2016-02-23, Chris Angelico wrote:
> On Tue, Feb 23, 2016 at 11:26 AM, Jon Ribbens
> wrote:
>> On 2016-02-23, Chris Angelico wrote:
>>> On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
>>> wrote:
> If you generate 2**128 + 1 such numbers, you are *guaranteed* to
... have expired due
On Tue, 23 Feb 2016 06:32 am, Marko Rauhamaa wrote:
> Jon Ribbens :
>
>> Suppose you had code like this:
>>
>> filename = binascii.hexlify(os.urandom(16)).decode("ascii")
>>
>> Do we really think that is insecure or that there are any practical
>> attacks against it? It would be basically the s
On Tue, Feb 23, 2016 at 11:26 AM, Jon Ribbens
wrote:
> On 2016-02-23, Chris Angelico wrote:
>> On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
>> wrote:
If you generate 2**128 + 1 such numbers, you are *guaranteed* to
>>>
>>> ... have expired due to the heat death of the universe.
>>
>> Maybe.
Oscar Benjamin writes:
> What does unpredictable mean in this context? Maybe I'm reading too
> much into that...
I think you may be, yes. The request in this thread requires making
direct use of the “generate a new valid temporary fielsystem path”
functionality already implemented in ‘tempfile’.
On 2016-02-23, Chris Angelico wrote:
> On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
> wrote:
>>> If you generate 2**128 + 1 such numbers, you are *guaranteed* to
>>
>> ... have expired due to the heat death of the universe.
>
> Maybe... but by the time you get to 2**64 of them, you have a 50%
> c
On Tue, 23 Feb 2016 05:17 am, Jon Ribbens wrote:
> On 2016-02-22, Ethan Furman wrote:
>> On 02/14/2016 04:08 PM, Ben Finney wrote:
>>> I am unconcerned with whether there is a real filesystem entry of that
>>> name; the goal entails having no filesystem activity for this. I want a
>>> valid uniqu
On Tue, Feb 23, 2016 at 11:08 AM, Jon Ribbens
wrote:
> On 2016-02-22, Steven D'Aprano wrote:
>> On Tue, 23 Feb 2016 05:48 am, Marko Rauhamaa wrote:
>>> Jon Ribbens :
I was under the impression that the point of UUIDs is that you can be
*so* confident that there won't be a collision that
On 2016-02-22, Steven D'Aprano wrote:
> On Tue, 23 Feb 2016 05:48 am, Marko Rauhamaa wrote:
>> Jon Ribbens :
>>> I was under the impression that the point of UUIDs is that you can be
>>> *so* confident that there won't be a collision that for all practical
>>> purposes it's indistinguishable from
On 2016-02-23, Steven D'Aprano wrote:
> On Tue, 23 Feb 2016 06:22 am, Jon Ribbens wrote:
>> Suppose you had code like this:
>>
>> filename = binascii.hexlify(os.urandom(16)).decode("ascii")
>>
>> Do we really think that is insecure or that there are any practical
>> attacks against it? It would
On Tue, 23 Feb 2016 06:22 am, Jon Ribbens wrote:
> Suppose you had code like this:
>
> filename = binascii.hexlify(os.urandom(16)).decode("ascii")
>
> Do we really think that is insecure or that there are any practical
> attacks against it? It would be basically the same as saying that
> urandom
On 22 Feb 2016 22:50, "Ben Finney" wrote:
>
> Ethan Furman writes:
>
> > On 02/14/2016 04:08 PM, Ben Finney wrote:
> >
> > > I am unconcerned with whether there is a real filesystem entry of that
> > > name; the goal entails having no filesystem activity for this. I want
a
> > > valid unique file
On Tue, 23 Feb 2016 06:22 am, Paul Rubin wrote:
> Chris Angelico writes:
>>> I was under the impression that the point of UUIDs is that you can be
>>> *so* confident that there won't be a collision that for all practical
>>> purposes it's indistinguishable from being certain.
>> Maybe, if everyon
On Tue, 23 Feb 2016 05:48 am, Marko Rauhamaa wrote:
> Jon Ribbens :
>
>> I was under the impression that the point of UUIDs is that you can be
>> *so* confident that there won't be a collision that for all practical
>> purposes it's indistinguishable from being certain.
>
> Yes, if you generate
Marko Rauhamaa writes:
http://www.2uo.de/myths-about-urandom/
>> I don't know what web pamphlet you mean,
> The only one linked above.
Oh, I wouldn't have called that a pamphlet. I could quibble with the
writing style but the points in the article are basically correct.
> getrandom(2) is a
On 22Feb2016 12:34, Alan Bawden wrote:
Cameron Simpson writes:
On 16Feb2016 19:24, Alan Bawden wrote:
So in the FIFO case, I might write something like the following:
def make_temp_fifo(mode=0o600):
while True:
path = tempfile.mktemp()
try:
os
On 02/22/2016 02:25 PM, Cameron Simpson wrote:
On 22Feb2016 10:11, Ethan Furman wrote:
On 02/14/2016 04:08 PM, Ben Finney wrote:
I am unconcerned with whether there is a real filesystem entry of that
name; the goal entails having no filesystem activity for this. I want a
valid unique filesyst
Ethan Furman writes:
> On 02/14/2016 04:08 PM, Ben Finney wrote:
>
> > I am unconcerned with whether there is a real filesystem entry of that
> > name; the goal entails having no filesystem activity for this. I want a
> > valid unique filesystem path, without touching the filesystem.
>
> This is
On 22Feb2016 10:11, Ethan Furman wrote:
On 02/14/2016 04:08 PM, Ben Finney wrote:
I am unconcerned with whether there is a real filesystem entry of that
name; the goal entails having no filesystem activity for this. I want a
valid unique filesystem path, without touching the filesystem.
This
Paul Rubin :
>>> http://www.2uo.de/myths-about-urandom/
>> Did you post the link because you agreed with the Web pamphlet?
>
> I don't know what web pamphlet you mean,
The only one linked above.
Cryptography is tricky business, indeed. I know enough about it not to
improvise too much. Infinitesi
Marko Rauhamaa writes:
>> http://www.2uo.de/myths-about-urandom/
> Did you post the link because you agreed with the Web pamphlet?
I don't know what web pamphlet you mean, but the right thing to use now
is getrandom(2). The random/urandom interface was poorly designed and
misleadingly documented
Random832 :
> On Mon, Feb 22, 2016, at 14:32, Marko Rauhamaa wrote:
>> urandom() is not quite random and so should not be considered
>> cryptographically airtight.
>>
>> Under Linux, /dev/random is the way to go when strong security is
>> needed. Note that /dev/random is a scarce resource on ordi
On Mon, Feb 22, 2016, at 14:32, Marko Rauhamaa wrote:
> urandom() is not quite random and so should not be considered
> cryptographically airtight.
>
> Under Linux, /dev/random is the way to go when strong security is
> needed. Note that /dev/random is a scarce resource on ordinary systems.
http:
On Tue, Feb 23, 2016 at 6:22 AM, Jon Ribbens
wrote:
>> Maybe, if everyone's cooperating. I'm not sure how they fare in the
>> face of malice though.
>
> Suppose you had code like this:
>
> filename = binascii.hexlify(os.urandom(16)).decode("ascii")
>
> Do we really think that is insecure or that
Jon Ribbens :
> Suppose you had code like this:
>
> filename = binascii.hexlify(os.urandom(16)).decode("ascii")
>
> Do we really think that is insecure or that there are any practical
> attacks against it? It would be basically the same as saying that
> urandom() is broken, surely?
urandom() is
On 2016-02-22, Chris Angelico wrote:
> On Tue, Feb 23, 2016 at 5:39 AM, Jon Ribbens
> wrote:
>> On 2016-02-22, Chris Angelico wrote:
>>> On Tue, Feb 23, 2016 at 5:17 AM, Jon Ribbens
>>> wrote:
Weell, I have a lot of sympathy for that point, but on the other
hand the whole concept of
Chris Angelico writes:
>> I was under the impression that the point of UUIDs is that you can be
>> *so* confident that there won't be a collision that for all practical
>> purposes it's indistinguishable from being certain.
> Maybe, if everyone's cooperating. I'm not sure how they fare in the
> fa
On Tue, Feb 23, 2016 at 5:39 AM, Jon Ribbens
wrote:
> On 2016-02-22, Chris Angelico wrote:
>> On Tue, Feb 23, 2016 at 5:17 AM, Jon Ribbens
>> wrote:
>>> Weell, I have a lot of sympathy for that point, but on the other
>>> hand the whole concept of UUIDs ("import uuid") is predicated on the
>>
Jon Ribbens :
> I was under the impression that the point of UUIDs is that you can be
> *so* confident that there won't be a collision that for all practical
> purposes it's indistinguishable from being certain.
Yes, if you generate a random 128-bit number, it will be unique --
unless someone clo
On 2016-02-22, Chris Angelico wrote:
> On Tue, Feb 23, 2016 at 5:17 AM, Jon Ribbens
> wrote:
>> Weell, I have a lot of sympathy for that point, but on the other
>> hand the whole concept of UUIDs ("import uuid") is predicated on the
>> opposite assumption.
>
> Not quite opposite. Ethan is asse
On 2016-02-22, Ethan Furman wrote:
> On 02/14/2016 04:08 PM, Ben Finney wrote:
>> I am unconcerned with whether there is a real filesystem entry of that
>> name; the goal entails having no filesystem activity for this. I want a
>> valid unique filesystem path, without touching the filesystem.
>
>
On Tue, Feb 23, 2016 at 5:17 AM, Jon Ribbens
wrote:
> On 2016-02-22, Ethan Furman wrote:
>> On 02/14/2016 04:08 PM, Ben Finney wrote:
>>> I am unconcerned with whether there is a real filesystem entry of that
>>> name; the goal entails having no filesystem activity for this. I want a
>>> valid un
On 02/14/2016 04:08 PM, Ben Finney wrote:
I am unconcerned with whether there is a real filesystem entry of that
name; the goal entails having no filesystem activity for this. I want a
valid unique filesystem path, without touching the filesystem.
This is impossible. If you don't touch the fi
Cameron Simpson writes:
> On 16Feb2016 19:24, Alan Bawden wrote:
>>So in the FIFO case, I might write something like the following:
>>
>>def make_temp_fifo(mode=0o600):
>>while True:
>>path = tempfile.mktemp()
>>try:
>>os.mkfifo(path, mode=mode
On 16Feb2016 19:24, Alan Bawden wrote:
Ben Finney writes:
Cameron Simpson writes:
I've been watching this for a few days, and am struggling to
understand your use case.
Yes, you're not alone. This surprises me, which is why I'm persisting.
Can you elaborate with a concrete example and it
On 16 February 2016 at 19:40, Ben Finney wrote:
> Oscar Benjamin writes:
>
>> If you're going to patch open to return a fake file when asked to open
>> fake_file_path why do you care whether there is a real file of that
>> name?
>
> I don't, and have been saying explicitly many times in this thre
Ben Finney writes:
> Cameron Simpson writes:
>
>> I've been watching this for a few days, and am struggling to
>> understand your use case.
>
> Yes, you're not alone. This surprises me, which is why I'm persisting.
>
>> Can you elaborate with a concrete example and its purpose which would
>> wor
Steven D'Aprano writes:
> On Tue, 16 Feb 2016 04:56 pm, Ben Finney wrote:
>
> > names = tempfile._get_candidate_names()
>
> I'm not sure that calling a private function of the tempfile module is
> better than calling a deprecated function.
Agreed, which is why I'm seeking a public API that i
Oscar Benjamin writes:
> If you're going to patch open to return a fake file when asked to open
> fake_file_path why do you care whether there is a real file of that
> name?
I don't, and have been saying explicitly many times in this thread that
I do not care whether the file exists. Somehow tha
On Tue, 16 Feb 2016 04:56 pm, Ben Finney wrote:
> An example::
>
> import io
> import tempfile
> names = tempfile._get_candidate_names()
I'm not sure that calling a private function of the tempfile module is
better than calling a deprecated function.
> def test_frobnicates_con
On 16 Feb 2016 05:57, "Ben Finney" wrote:
>
> Cameron Simpson writes:
>
> > I've been watching this for a few days, and am struggling to
> > understand your use case.
>
> Yes, you're not alone. This surprises me, which is why I'm persisting.
>
> > Can you elaborate with a concrete example and its
Cameron Simpson writes:
> I've been watching this for a few days, and am struggling to
> understand your use case.
Yes, you're not alone. This surprises me, which is why I'm persisting.
> Can you elaborate with a concrete example and its purpose which would
> work with a mktemp-ish official fun
"Mario R. Osorio" writes:
> I would create a RAM disk
> (http://www.cyberciti.biz/faq/howto-create-linux-ram-disk-filesystem/),
> generate all the path/files I want with any, or my own algorithm, run
> the tests, unmount it, destroy it, be happy ... Whats wrong with
> that??
It is addressing the
I would create a RAM disk
(http://www.cyberciti.biz/faq/howto-create-linux-ram-disk-filesystem/),
generate all the path/files I want with any, or my own algorithm, run the
tests, unmount it, destroy it, be happy ... Whats wrong with that?? AFAIK, RAM
disks do not get logged, and even if they do
On Sunday, February 14, 2016 at 10:55:11 PM UTC-6, Steven D'Aprano wrote:
> If you want to guarantee that these faux pathnames can't
> leak out of your test suite and touch the file system,
> prepend an ASCII NUL to them. That will make it an illegal
> path on all file systems that I'm aware of.
H
On Mon, 15 Feb 2016 15:28:27 +1100, Ben Finney wrote:
> The behaviour is already implemented in the standard library. What I'm
> looking for is a way to use it (not re-implement it) that is public API
> and isn't scolded by the library documentation.
So, basically you want (essentially) the exact
Roel Schroeven writes:
> Use uuid.uuid1()?
That has potential. A little counter-intuitive, for use in documentation
about testing filesystem paths; but not frightening or dubious to the
conscientious reader.
I'll see whether that meets this use case, thank you.
The bug report (to make a suppor
Gregory Ewing wrote:
> Ben Finney wrote:
>> One valid filesystem path each time it's accessed. That is, behaviour
>> equivalent to ‘tempfile.mktemp’.
>>
>> My question is because the standard library clearly has this useful
>> functionality implemented, but simultaneously warns strongly against i
On 15Feb2016 12:19, Ben Finney wrote:
Dan Sommers writes:
On Mon, 15 Feb 2016 11:08:52 +1100, Ben Finney wrote:
> I am unconcerned with whether there is a real filesystem entry of
> that name; the goal entails having no filesystem activity for this.
> I want a valid unique filesystem path, wit
Ben Finney schreef op 2016-02-14 22:46:
How should a program generate a unique filesystem path and *not* create
the filesystem entry?
> ...
What standard library function should I be using to generate
‘tempfile.mktemp’-like unique paths, and *not* ever create a real file
by that path?
Use uui
On 2016-02-15, Ben Finney wrote:
> Dan Sommers writes:
>
>> On Mon, 15 Feb 2016 11:08:52 +1100, Ben Finney wrote:
>>
>> > I am unconcerned with whether there is a real filesystem entry of
>> > that name; the goal entails having no filesystem activity for this.
>> > I want a valid unique filesyste
On 2016-02-14, Ben Finney wrote:
> Howdy all,
>
> How should a program generate a unique filesystem path and *not* create
> the filesystem entry?
Short answer: you can't because it's the filesystem entry operation
that is atomic and guarantees uniqueness.
> [..]
> What standard library function
Ben Finney wrote:
The existing behaviour of ‘tempfile.mktemp’ – actually of its internal
class ‘tempfile._RandomNameSequence’ – is to generate unpredictable,
unique, valid filesystem paths that are different each time.
But that's not documented behaviour, so even if mktemp()
weren't marked as
Ben Finney wrote:
One valid filesystem path each time it's accessed. That is, behaviour
equivalent to ‘tempfile.mktemp’.
My question is because the standard library clearly has this useful
functionality implemented, but simultaneously warns strongly against its
use.
But it *doesn't*, if your r
Steven D'Aprano writes:
> If you can absolutely guarantee that this string will never actually
> be used on a real filesystem, then go right ahead and use it.
I'm giving advice in examples in documentation. It's not enough to have
some private usage that I know is good, I am looking for a standa
On Monday 15 February 2016 12:19, Ben Finney wrote:
> One valid filesystem path each time it's accessed. That is, behaviour
> equivalent to ‘tempfile.mktemp’.
>
> My question is because the standard library clearly has this useful
> functionality implemented, but simultaneously warns strongly aga
Good evening/morning Ben,
>> > I am unconcerned with whether there is a real filesystem entry of
>> > that name; the goal entails having no filesystem activity for this.
>> > I want a valid unique filesystem path, without touching the
>> > filesystem.
>>
>> Your phrasing is ambiguous.
>
>The exis
Steven D'Aprano writes:
> On Monday 15 February 2016 11:08, Ben Finney wrote:
>
> > I am unconcerned with whether there is a real filesystem entry of
> > that name; the goal entails having no filesystem activity for this.
> > I want a valid unique filesystem path, without touching the
> > filesys
On Monday 15 February 2016 11:08, Ben Finney wrote:
> I am unconcerned with whether there is a real filesystem entry of that
> name; the goal entails having no filesystem activity for this. I want a
> valid unique filesystem path, without touching the filesystem.
Your phrasing is ambiguous.
If y
Dan Sommers writes:
> On Mon, 15 Feb 2016 11:08:52 +1100, Ben Finney wrote:
>
> > I am unconcerned with whether there is a real filesystem entry of
> > that name; the goal entails having no filesystem activity for this.
> > I want a valid unique filesystem path, without touching the
> > filesyste
On Mon, 15 Feb 2016 11:08:52 +1100, Ben Finney wrote:
> I am unconcerned with whether there is a real filesystem entry of that
> name; the goal entails having no filesystem activity for this. I want
> a valid unique filesystem path, without touching the filesystem.
That's an odd use case.
If it'
Matt Wheeler writes:
> On 14 Feb 2016 21:46, "Ben Finney" wrote:
> > What standard library function should I be using to generate
> > ‘tempfile.mktemp’-like unique paths, and *not* ever create a real
> > file by that path?
>
> Could you use tempfile.TemporaryDirectory and then just use a
> consi
On 14 Feb 2016 21:46, "Ben Finney" wrote:
> What standard library function should I be using to generate
> ‘tempfile.mktemp’-like unique paths, and *not* ever create a real file
> by that path?
Could you use tempfile.TemporaryDirectory and then just use a consistent
name within that directory.
I
Ben Finney wrote:
> How should a program generate a unique filesystem path and *not* create
> the filesystem entry?
The Python documentation suggests that it should not.
> The ‘tempfile.mktemp’ function is strongly deprecated, and rightly so
> https://docs.python.org/3/library/tempfile.html#tem
Howdy all,
How should a program generate a unique filesystem path and *not* create
the filesystem entry?
The ‘tempfile.mktemp’ function is strongly deprecated, and rightly so
https://docs.python.org/3/library/tempfile.html#tempfile.mktemp>
because it leaves the program vulnerable to insecure file
87 matches
Mail list logo
