Re: tempname.mktemp functionality deprecation
The following function should be immune to race conditions and doesn't use mktemp. def templink(destpath): """Create a hard link to the given file with a unique name. Returns the name of the link.""" pid = os.getpid() i = 1 while True: linkpath = "%s-%s-%s" % (destpath, pid, i) try: os.link(destpath, linkpath) except FileExistsError: i += 1 else: break return linkpath -- Greg -- https://mail.python.org/mailman/listinfo/python-list
[ANN] Second PyCon Israel June 11-14, 2017
Hi All, The second PyCon Israel will take place June 11-14, 2017. * 11 June Django girls workshop at Red Hat Israel offices in Raanana * 12-13 June PyCon Israel main event at Wohl center * 14 June PyCon Israel workshops and sprints We still have some sponsorship spots available, great recruiting and branding opportunity. Also the general session CFP is still open. Read more at http://il.pycon.org/2017/ See you there, -- The PyCon Israel Team -- https://mail.python.org/mailman/listinfo/python-list
Re: MCOW package
On Mon, 1 May 2017 01:01 pm, Metallicow wrote: > I finally uploaded my wx/lib/mcow package. > It has many widgets and mixins and probably more to come. Congratulations! What does it do? -- Steve Emoji: a small, fuzzy, indistinct picture used to replace a clear and perfectly comprehensible word. -- https://mail.python.org/mailman/listinfo/python-list
MCOW package
I finally uploaded my wx/lib/mcow package. It has many widgets and mixins and probably more to come. It has been extensively tested on Windows and at least tested on a linux flavor. It would be nice if I could get some mac testing also. :) https://github.com/Metallicow/MCOW -- https://mail.python.org/mailman/listinfo/python-list
MCOW package
I finally uploaded my wx/lib/mcow package. It has many widgets and mixins and probably more to come. It has been extensively tested on Windows and at least tested on a linux flavor. It would be nice if I could get some mac testing also. :) https://github.com/Metallicow/MCOW -- https://mail.python.org/mailman/listinfo/python-list
Re: tempname.mktemp functionality deprecation
On 2017-05-01 08:41, Cameron Simpson wrote: > On 30Apr2017 06:52, Tim Chase wrote: > >> > - use a GUID-named temp-file instead for less chance of > >> > collision? > > You could, but mktemp is supposed to robustly perform that task, > versus "very very probably". Though with the potential of its race-condition, mktemp() isn't a much stronger guarantee. A GUID seems like the best route. > >> > - I happen to already have a hash of the file contents, so use > >> > the .hexdigest() string as the temp-file name? > > Hashes collide. (Yes, I know that for your purposes we consider > that they don't; I have a very similar situation of my own). And > what if your process is running twice, or leaves around a previous > temp file by accident (or interruption) _or_ the file tree contains > filenames named after the hash of their content (not actually > unheard of)? In both case #1 (a *file* happens to have the name of the SHA256 hash, but has different file contents) and case #2 (another process running generates a *link* with the SHA256 of the matching content), the os.link() should fail with the EEXISTS which I'm okay with. Likewise, if there's an interruption, I'd rather have the stray SHA-named link floating around than lose an existing file-name. > What about some variation on: > > from tempfile import NamedTemporaryFile > ... > with NamedTemporaryFile(dir=your_target_directory) as T: > use T.name, and do your rename/unlink in here As mentioned in my follow-up (which strangely your reply came in with a References header referencing), the NamedTemporaryFile creates the file on-disk, which means os.link(source, T.name) fails with the EEXISTS. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: tempname.mktemp functionality deprecation
On 2017-05-01 09:15, Ben Finney wrote: > I reported this – for a different use case – in issue26362 [0] > https://bugs.python.org/issue26362>. > > The suggested solutions in the documentation do not address the use > case described there; and they do not address the use case you've > described here either. > > Would you be kind enough to update that issue with a description of > your use case as well? Done, linking to this thread: http://bugs.python.org/msg292648 -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: tempname.mktemp functionality deprecation
On Sat, Apr 29, 2017 at 11:45 AM, Tim Chase
wrote:
> Working on some deduplication code, I want do my my best at
> performing an atomic re-hard-linking atop an existing file, akin to
> "ln -f source.txt dest.txt"
>
> However, when I issue
>
> os.link("source.txt", "dest.txt")
>
> it fails with an OSError (EEXISTS). This isn't surprising as it's
> documented. Unfortunately, os.link doesn't support something like
>
> os.link("source.txt", "dest.txt", force=True)
FWIW, ln -f appears to unlink on Linux Mint 18 (GNU coreutils 8.25):
$ strace -f ln -f file file2 2>&1 | tail -15
below cmd output started 2017 Sun Apr 30 04:47:53 PM PDT
munmap(0x7f804fcb4000, 147404) = 0
brk(NULL) = 0x225c000
brk(0x227d000) = 0x227d000
stat("file2", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lstat("file", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lstat("file2", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
linkat(AT_FDCWD, "file", AT_FDCWD, "file2", 0) = -1 EEXIST (File exists)
unlink("file2") = 0
linkat(AT_FDCWD, "file", AT_FDCWD, "file2", 0) = 0
lseek(0, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
close(0)= 0
close(1)= 0
close(2)= 0
exit_group(0) = ?
+++ exited with 0 +++
HTH
--
https://mail.python.org/mailman/listinfo/python-list
Re: tempname.mktemp functionality deprecation
Tim Chase writes: > Unfortunately, tempfile.mktemp() is described as deprecated since 2.3 > (though appears to still exist in the 3.4.2 that is the default Py3 on > Debian Stable). While the deprecation notice says "In version 2.3 of > Python, this module was overhauled for enhanced security. It now > provides three new functions, NamedTemporaryFile(), mkstemp(), and > mkdtemp(), which should eliminate all remaining need to use the > insecure mktemp() function", as best I can tell, all of the other > functions/objects in the tempfile module return a file object, not a > string suitable for passing to link(). The problem you describe is that ‘tmpfile.mktemp’ is deprecated, but there is no other supported standard-library API which does its job. I reported this – for a different use case – in issue26362 [0] https://bugs.python.org/issue26362>. The suggested solutions in the documentation do not address the use case described there; and they do not address the use case you've described here either. Would you be kind enough to update that issue with a description of your use case as well? [0] The issue currently has a message from me, over a year ago, saying that I will “work on a patch soon”. I'd welcome someone else taking that job. -- \ “Books and opinions, no matter from whom they came, if they are | `\ in opposition to human rights, are nothing but dead letters.” | _o__) —Ernestine Rose | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: tempname.mktemp functionality deprecation
On 30Apr2017 06:52, Tim Chase wrote: On 2017-04-29 20:51, Devin Jeanpierre wrote: On Sat, Apr 29, 2017 at 11:45 AM, Tim Chase wrote > So which route should I pursue? > - go ahead and use tempfile.mktemp() ignoring the deprecation? I'd be tempted to. But... > - use a GUID-named temp-file instead for less chance of collision? You could, but mktemp is supposed to robustly perform that task, versus "very very probably". > - I happen to already have a hash of the file contents, so use > the .hexdigest() string as the temp-file name? Hashes collide. (Yes, I know that for your purposes we consider that they don't; I have a very similar situation of my own). And what if your process is running twice, or leaves around a previous temp file by accident (or interruption) _or_ the file tree contains filenames named after the hash of their content (not actually unheard of)? > - some other solution I've missed? What about some variation on: from tempfile import NamedTemporaryFile ... with NamedTemporaryFile(dir=your_target_directory) as T: use T.name, and do your rename/unlink in here Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: test_imaplib fail when installing python3.6.1 on centos6.9
On 4/30/2017 9:09 AM, Wade Wang wrote: Hello, everyone. I'm trying to install Python 3.6.1 on my CentOS 6.9 server, but test_imaplib always fails its test when make test. Here is what I got: == ERROR: test_logincapa_with_client_certfile (test.test_imaplib.RemoteIMAP_ SSLTest) -- Traceback (most recent call last): File "/root/Python-3.6.1/Lib/test/test_imaplib.py", line 973, in test_logincapa_with_client_certfile certfile=CERTFILE) File "/root/Python-3.6.1/Lib/imaplib.py", line 1280, in __init__ IMAP4.__init__(self, host, port) File "/root/Python-3.6.1/Lib/imaplib.py", line 197, in __init__ self.open(host, port) File "/root/Python-3.6.1/Lib/imaplib.py", line 1293, in open IMAP4.open(self, host, port) File "/root/Python-3.6.1/Lib/imaplib.py", line 294, in open self.sock = self._create_socket() File "/root/Python-3.6.1/Lib/imaplib.py", line 1285, in _create_socket server_hostname=self.host) File "/root/Python-3.6.1/Lib/ssl.py", line 401, in wrap_socket _context=self, _session=session) File "/root/Python-3.6.1/Lib/ssl.py", line 808, in __init__ self.do_handshake() File "/root/Python-3.6.1/Lib/ssl.py", line 1061, in do_handshake self._sslobj.do_handshake() File "/root/Python-3.6.1/Lib/ssl.py", line 683, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:749) == ERROR: test_logincapa_with_client_ssl_context (test.test_imaplib.RemoteIMAP_SSLTest) -- Traceback (most recent call last): File "/root/Python-3.6.1/Lib/test/test_imaplib.py", line 979, in test_logincapa_with_client_ssl_context self.host, self.port, ssl_context=self.create_ssl_context()) File "/root/Python-3.6.1/Lib/imaplib.py", line 1280, in __init__ IMAP4.__init__(self, host, port) File "/root/Python-3.6.1/Lib/imaplib.py", line 197, in __init__ self.open(host, port) File "/root/Python-3.6.1/Lib/imaplib.py", line 1293, in open IMAP4.open(self, host, port) File "/root/Python-3.6.1/Lib/imaplib.py", line 294, in open self.sock = self._create_socket() File "/root/Python-3.6.1/Lib/imaplib.py", line 1285, in _create_socket server_hostname=self.host) File "/root/Python-3.6.1/Lib/ssl.py", line 401, in wrap_socket _context=self, _session=session) File "/root/Python-3.6.1/Lib/ssl.py", line 808, in __init__ self.do_handshake() File "/root/Python-3.6.1/Lib/ssl.py", line 1061, in do_handshake self._sslobj.do_handshake() File "/root/Python-3.6.1/Lib/ssl.py", line 683, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:749) -- Ran 95 tests in 27.005s FAILED (errors=2) 1 test failed again: test_imaplib Total duration: 6 min 34 sec Tests result: FAILURE make: *** [test] Error 1 Any solution or suggestion? Unless you get a better solution here, open an issue on bugs.python.org. In the Nosy list box, enter 'ssl' and click the list under 'module'. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
test_imaplib fail when installing python3.6.1 on centos6.9
Hello, everyone. I'm trying to install Python 3.6.1 on my CentOS 6.9 server, but test_imaplib always fails its test when make test. Here is what I got: > == > ERROR: test_logincapa_with_client_certfile (test.test_imaplib.RemoteIMAP_ SSLTest) > -- > Traceback (most recent call last): > File "/root/Python-3.6.1/Lib/test/test_imaplib.py", line 973, in test_logincapa_with_client_certfile > certfile=CERTFILE) > File "/root/Python-3.6.1/Lib/imaplib.py", line 1280, in __init__ > IMAP4.__init__(self, host, port) > File "/root/Python-3.6.1/Lib/imaplib.py", line 197, in __init__ > self.open(host, port) > File "/root/Python-3.6.1/Lib/imaplib.py", line 1293, in open > IMAP4.open(self, host, port) > File "/root/Python-3.6.1/Lib/imaplib.py", line 294, in open > self.sock = self._create_socket() > File "/root/Python-3.6.1/Lib/imaplib.py", line 1285, in _create_socket > server_hostname=self.host) > File "/root/Python-3.6.1/Lib/ssl.py", line 401, in wrap_socket > _context=self, _session=session) > File "/root/Python-3.6.1/Lib/ssl.py", line 808, in __init__ > self.do_handshake() > File "/root/Python-3.6.1/Lib/ssl.py", line 1061, in do_handshake > self._sslobj.do_handshake() > File "/root/Python-3.6.1/Lib/ssl.py", line 683, in do_handshake > self._sslobj.do_handshake() > ssl.SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:749) > > == > ERROR: test_logincapa_with_client_ssl_context (test.test_imaplib.RemoteIMAP_SSLTest) > -- > Traceback (most recent call last): > File "/root/Python-3.6.1/Lib/test/test_imaplib.py", line 979, in > test_logincapa_with_client_ssl_context > self.host, self.port, ssl_context=self.create_ssl_context()) > File "/root/Python-3.6.1/Lib/imaplib.py", line 1280, in __init__ > IMAP4.__init__(self, host, port) > File "/root/Python-3.6.1/Lib/imaplib.py", line 197, in __init__ > self.open(host, port) > File "/root/Python-3.6.1/Lib/imaplib.py", line 1293, in open > IMAP4.open(self, host, port) > File "/root/Python-3.6.1/Lib/imaplib.py", line 294, in open > self.sock = self._create_socket() > File "/root/Python-3.6.1/Lib/imaplib.py", line 1285, in _create_socket > server_hostname=self.host) > File "/root/Python-3.6.1/Lib/ssl.py", line 401, in wrap_socket > _context=self, _session=session) > File "/root/Python-3.6.1/Lib/ssl.py", line 808, in __init__ > self.do_handshake() > File "/root/Python-3.6.1/Lib/ssl.py", line 1061, in do_handshake > self._sslobj.do_handshake() > File "/root/Python-3.6.1/Lib/ssl.py", line 683, in do_handshake > self._sslobj.do_handshake() > ssl.SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:749) > > -- > Ran 95 tests in 27.005s > > FAILED (errors=2) > 1 test failed again: > test_imaplib > > Total duration: 6 min 34 sec > Tests result: FAILURE > make: *** [test] Error 1 Any solution or suggestion? -- https://mail.python.org/mailman/listinfo/python-list
Re: tempname.mktemp functionality deprecation
On 2017-04-29 20:51, Devin Jeanpierre wrote:
> On Sat, Apr 29, 2017 at 11:45 AM, Tim Chase wrote
> > So which route should I pursue?
> >
> > - go ahead and use tempfile.mktemp() ignoring the deprecation?
> >
> > - use a GUID-named temp-file instead for less chance of collision?
> >
> > - I happen to already have a hash of the file contents, so use
> > the .hexdigest() string as the temp-file name?
> >
> > - some other solution I've missed?
>
> I vote the last one: you can read the .name attribute of the
> returned file(-like) object from NamedTemporaryFile to get a path
> to a file, which can be passed to other functions.
Unfortunately, his entails the file-preexisting, causing the same
EEXISTS problem as before:
$ cd ~/tmp
$ echo hello > a
$ python
...
>>> from tempfile import NamedTemporaryFile as NTF
>>> f = NTF(dir='.')
>>> import os
>>> os.link('a', f.name)
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 17] File exists
>>> f.name
'/home/tim/tmp/tmpokEpht'
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Rosetta: Count in factors
On Sat, 29 Apr 2017 22:05:16 +, Robert L. wrote:
>> Task
>>
>> Write a program which counts up from 1, displaying each number as the
>> multiplication of its prime factors.
>>
>> For the purpose of this task, 1 (unity) may be shown as itself.
>>
>>
>> Example
>>
>>2 is prime, so it would be shown as itself. 6 is not prime;
>>it would be shown as 2 x 3
>> 2144 is not prime; it would be shown as 2 x 2 x 2 x 2 x 2 x 67
>
>
> require 'prime'
>
> puts " 1: 1" ; (2..23).each{|n|
> printf "%2d: %s\n", n,
> Prime.prime_division(n).map{|f,c| ([f]*c).join ' x '}.join(' x ')
> }
>
> 1: 1 2: 2 3: 3 4: 2 x 2 5: 5 6: 2 x 3 7: 7 8: 2 x 2 x 2 9: 3 x 3
> 10: 2 x 5 11: 11 12: 2 x 2 x 3 13: 13 14: 2 x 7 15: 3 x 5 16: 2 x 2 x 2
> x 2 17: 17 18: 2 x 3 x 3 19: 19 20: 2 x 2 x 5 21: 3 x 7 22: 2 x 11 23:
> 23
It does not help a student if you do their homework for them,
much better to provide hints & guidance
--
Why do mathematicians insist on using words that already have another
meaning? "It is the complex case that is easier to deal with." "If it
doesn't happen at a corner, but at an edge, it nonetheless happens at a
corner."
--
https://mail.python.org/mailman/listinfo/python-list
Re: Not understanding itertools.dropwhile()
Jason Friedman wrote: > def test_to_start(s): > return "2" in s > > for line in itertools.dropwhile(test_to_start, data.splitlines()): > print(line) It's really all in the names: it could either be for line in dropwhile(test_to_drop, items): ... or for line in dropwhilenot(test_to_start, items): ... > < end code > > > I expect: > > $ python3 dropwhile.py > Line2 > > Line4 > Line5 > > > I get: > > $ python3 dropwhile.py > Line1 > Line2 > > Line4 > Line5 > > > Please explain. -- https://mail.python.org/mailman/listinfo/python-list
