Re: [Python-Dev] Compiling 2.7.2 on OS/2
Hi All,
On 06/01/12 10:25, Terry Reedy wrote:
On 1/5/2012 3:01 PM, Paul Smedley wrote:
File ./setup.py, line 1154, in detect_modules
for arg in sysconfig.get_config_var(__CONFIG_ARGS).split()]
AttributeError: 'NoneType' object has no attribute 'split'
make: *** [sharedmods] Error 1
File ./setup.py, line 1368, in detect_modules
if '--with-system-expat' in sysconfig.get_config_var(CONFIG_ARGS):
TypeError: argument of type 'NoneType' is not iterable
make: *** [sharedmods] Error 1
Which again points to problems with
sysconfig.get_config_var(CONFIG_ARGS):
[The earlier call was with __CONFIG_ARGS, for whatever difference that
makes.] It appears to be returning None instead of [] (or a populated
list).
In 3.2.2, at line 579 of sysconfig.py is
def get_config_var(name):
return get_config_vars().get(name)
That defaults to None if name is not a key in the dict returned by
get_config_vars(). My guess is that it always is and and the the value
is always a list for tested win/*nix/mac systems. So either setup.py has
the bug of assuming that there is always a list value for CONFIG_ARGS
or sysconfig.py has the bug of not setting it for os2, perhaps because
of a bug elsewhere.
At line 440 of sysconfig.py is
def get_config_var(*args):
global _CONFIG_VARS
if _CONFIG_VARS is None:
_CONFIG_VARS = {}
code to populate _CONFIG_VARS, including
if os.name in ('nt', 'os2'):
_init_non_posix(_CONFIG_VARS)
if args:
vals = []
for name in args:
vals.append(_CONFIG_VARS.get(name))
return vals
else:
return _CONFIG_VARS
At 456 is
def _init_non_posix(vars):
Initialize the module as appropriate for NT
# set basic install directories
...
CONFIG_ARGS is not set explicitly for any system anywhere in the file,
so I do not know how the call ever works.
using _init_posix() for 'os2' instead of _init_non_posix is the fix for
this.
sysconfig.py also needs the following changes:
--- \dev\Python-2.7.2-o\Lib\sysconfig.py2012-01-06 19:27:14.0
+1030
+++ sysconfig.py2012-01-07 19:03:00.0 +1030
@@ -46,7 +46,7 @@
'scripts': '{base}/Scripts',
'data' : '{base}',
},
-'os2_home': {
+'os2_user': {
'stdlib': '{userbase}/lib/python{py_version_short}',
'platstdlib': '{userbase}/lib/python{py_version_short}',
'purelib':
'{userbase}/lib/python{py_version_short}/site-packages',
@@ -413,9 +413,9 @@
_CONFIG_VARS['platbase'] = _EXEC_PREFIX
_CONFIG_VARS['projectbase'] = _PROJECT_BASE
-if os.name in ('nt', 'os2'):
+if os.name in ('nt'):
_init_non_posix(_CONFIG_VARS)
-if os.name == 'posix':
+if os.name in ('posix', 'os2'):
_init_posix(_CONFIG_VARS)
# Setting 'userbase' is done below the call to the
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling 2.7.2 on OS/2
On 1/7/2012 3:48 AM, Paul Smedley wrote:
using _init_posix() for 'os2' instead of _init_non_posix is the fix for
this.
sysconfig.py also needs the following changes:
--- \dev\Python-2.7.2-o\Lib\sysconfig.py 2012-01-06 19:27:14.0
+1030
+++ sysconfig.py 2012-01-07 19:03:00.0 +1030
@@ -46,7 +46,7 @@
'scripts': '{base}/Scripts',
'data' : '{base}',
},
- 'os2_home': {
+ 'os2_user': {
'stdlib': '{userbase}/lib/python{py_version_short}',
'platstdlib': '{userbase}/lib/python{py_version_short}',
'purelib': '{userbase}/lib/python{py_version_short}/site-packages',
@@ -413,9 +413,9 @@
_CONFIG_VARS['platbase'] = _EXEC_PREFIX
_CONFIG_VARS['projectbase'] = _PROJECT_BASE
- if os.name in ('nt', 'os2'):
+ if os.name in ('nt'):
_init_non_posix(_CONFIG_VARS)
- if os.name == 'posix':
+ if os.name in ('posix', 'os2'):
_init_posix(_CONFIG_VARS)
Submit a patch on the tracker, preferably as a file rather than cut and
paste.
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
Christian Heimes, 31.12.2011 04:59:
Am 31.12.2011 03:22, schrieb Victor Stinner:
The unique structure of CPython's dict implementation makes it harder to
get the number of values with equal hash. The academic hash map (the one
I learnt about at university) uses a bucket to store all elements with
equal hash (more precise hash: mod mask). However Python's dict however
perturbs the hash until it finds a free slot its array. The second,
third ... collision can be caused by a legit and completely different
(!) hash.
The last choice is to change the hash algorithm. The *idea* is the same
than adding salt to hashed password (in practice it will be a little bit
different): if a pseudo-random salt is added, the attacker cannot
prepare a single dataset, he/she will have to regenerate a new dataset
for each possible salt value. If the salt is big enough (size in bits),
the attacker will need too much CPU to generate the dataset (compute N
keys with the same hash value). Basically, it slows down the attack by
2^(size of the salt).
That's the idea of randomized hashing functions as implemented by Ruby
1.8, Perl and others. The random seed is used as IV. Multiple rounds of
multiply, XOR and MOD (integer overflows) cause a deviation. In your
other posting you were worried about the performance implication. A
randomized hash function just adds a single ADD operation, that's all.
Downside: With randomization all hashes are unpredictable and change
after every restart of the interpreter. This has some subtle side
effects like a different outcome of {a:1, b:1, c:1}.keys() after a
restart of the interpreter.
Another possibility would be to replace our fast hash function by a
better hash function like MD5 or SHA1 (so the creation of the dataset
would be too slow in practice = too expensive), but cryptographic hash
functions are much slower (and so would slow down Python too much).
I agree with your analysis. Cryptographic hash functions are far too
slow for our use case. During my research I found another hash function
that claims to be fast and that may not be vulnerable to this kind of
attack: http://isthe.com/chongo/tech/comp/fnv/
Wouldn't Bob Jenkins' lookup3 hash function fit in here? After all, it's
portable, known to provide a very good distribution for different string
values and is generally fast on both 32 and 64 bit architectures.
http://burtleburtle.net/bob/c/lookup3.c
The analysis is here:
http://burtleburtle.net/bob/hash/doobs.html
It seems that there's also support for generating 64bit hash values
(actually 2x32bits) efficiently.
Admittedly, this may require some adaptation for the PEP393 unicode memory
layout in order to produce identical hashes for all three representations
if they represent the same content. So it's not a drop-in replacement.
Stefan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] usefulness of Python version of threading.RLock
2012/1/7 Charles-François Natali neolo...@free.fr: Thanks for those precisions, but I must admit it doesn't help me much... Can we drop it? A yes/no answer will do it ;-) The yes/no answer is No, we can't drop it. Even though CPython no longer uses the Python version of RLock in normal operation, it's still the reference implementation for everyone else that has to perform the same task (i.e. wrap Python code around a non-reentrant lock to create a reentrant one). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #9993: When the source and destination are on different filesystems,
On Sat, Jan 7, 2012 at 5:17 AM, antoine.pitrou python-check...@python.org wrote: http://hg.python.org/cpython/rev/1ea8b7233fd7 changeset: 74288:1ea8b7233fd7 user: Antoine Pitrou solip...@pitrou.net date: Fri Jan 06 20:16:19 2012 +0100 summary: Issue #9993: When the source and destination are on different filesystems, and the source is a symlink, shutil.move() now recreates a symlink on the destination instead of copying the file contents. Patch by Jonathan Niehof and Hynek Schlawack. That seems like a fairly nasty backwards incompatibilty right there. While the old behaviour was different from mv, it was still perfectly well defined. Now, operations that used to work may fail - basically anything involving an absolute symlink will silently fail if being moved to removable media (it will create a symlink that is completely useless on the destination machine). Relative symlinks may or may not be broken depending on whether or not their target is *also* being copied to the destination media. The new help text also doesn't say what will happen if the destination doesn't even *support* symlinks (as is quite likely in the removable media case). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] usefulness of Python version of threading.RLock
Nick did you mean to say wrap python code around a reentrant lock to create a non-reentrant lock? Isn't that what PyRLock is doing? FWIW having now read issues 13697 and 13550, I'm +1 for dropping Python RLock, and all the logging machinery in threading. 2012/1/8 Nick Coghlan ncogh...@gmail.com 2012/1/7 Charles-François Natali neolo...@free.fr: Thanks for those precisions, but I must admit it doesn't help me much... Can we drop it? A yes/no answer will do it ;-) The yes/no answer is No, we can't drop it. Even though CPython no longer uses the Python version of RLock in normal operation, it's still the reference implementation for everyone else that has to perform the same task (i.e. wrap Python code around a non-reentrant lock to create a reentrant one). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- ಠ_ಠ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] usefulness of Python version of threading.RLock
2012/1/8 Matt Joiner anacro...@gmail.com: Nick did you mean to say wrap python code around a reentrant lock to create a non-reentrant lock? Isn't that what PyRLock is doing? Actually, I should have said recursive, not reentrant. FWIW having now read issues 13697 and 13550, I'm +1 for dropping Python RLock, and all the logging machinery in threading. While I agree on removing the unused and potentially problematic debugging machinery, I'm not convinced of the benefits of removing the pure Python RLock implementation. To quote Charles-François from the tracker issue: Now, the fun part: this affects not only RLock, but every Python code performing atomic actions: condition variables, barriers, etc. There are some constraints on what can be done from a signal handler, and it should probably be documented. Remove the pure Python RLock doesn't seem to actually solve anything - it just pushes the problem of fixing the signal interaction back onto third party users that are even more ill-equipped to resolve it than we are. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #9993: When the source and destination are on different filesystems,
Hi Nick, Am Samstag, 7. Januar 2012 um 14:22 schrieb Nick Coghlan: http://hg.python.org/cpython/rev/1ea8b7233fd7 changeset: 74288:1ea8b7233fd7 user: Antoine Pitrou solip...@pitrou.net (mailto:solip...@pitrou.net) date: Fri Jan 06 20:16:19 2012 +0100 summary: Issue #9993: When the source and destination are on different filesystems, and the source is a symlink, shutil.move() now recreates a symlink on the destination instead of copying the file contents. Patch by Jonathan Niehof and Hynek Schlawack. That seems like a fairly nasty backwards incompatibilty right there. While the old behaviour was different from mv, it was still perfectly well defined. Now, operations that used to work may fail - basically anything involving an absolute symlink will silently fail if being moved to removable media (it will create a symlink that is completely useless on the destination machine). Relative symlinks may or may not be broken depending on whether or not their target is *also* being copied to the destination media. I had a look at it, the possible cases are as following: 1. we can just do a os.rename(): if src is a link it stays one 2. os.rename() fails, src is not a symlink but a directory: copytree() is used with symlinks=True, i.e. symlinks are preserved, no matter where they point to, i.e. this would clash with removable media as well. 3. os.rename() fails and src is a symlink. In both former cases, links were preserved. And the removable-media-argument is IMHO moot due to case 2. If you want hardcore backwards compatibility, we could make the old behavior default and add some flag. But to be honest, the new approach seems more congruent to me. The new help text also doesn't say what will happen if the destination doesn't even *support* symlinks (as is quite likely in the removable media case). A clarification might be appropriate. Maybe even a direct warning, that in such cases the usage of copytree(…, symlinks=False) might be a better idea? But the more I think about it, the more it's my impression, that symlink problems aren't really our problems as they go through all possible layers and it's next to impossible to catch all edge cases in library code. Therefore I'd say it's best just to behave like UNIX tools (please note I'm not defensive here, I've just fixed the tests+docs :)). Cheers, Hynek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
Am 07.01.2012 12:02, schrieb Stefan Behnel: Wouldn't Bob Jenkins' lookup3 hash function fit in here? After all, it's portable, known to provide a very good distribution for different string values and is generally fast on both 32 and 64 bit architectures. http://burtleburtle.net/bob/c/lookup3.c The analysis is here: http://burtleburtle.net/bob/hash/doobs.html It seems that there's also support for generating 64bit hash values (actually 2x32bits) efficiently. This thread as well as the ticket is getting so long that people barely have a chance to catch up ... Guido has stated that he doesn't want a completely new hash algorithm for Python 2.x to 3.2. A new hash algorithm for 3.3 needs a PEP, too. I've done some experiments with FNV and Murmur3. With Murmur3 128bit I've seen some minor speed improvements on 64bit platforms. At first I was surprised but it makes sense. Murmur3 operates on uint32_t blocks while Python's hash algorithm iterates over 1 byte (bytes, ASCII), 2 bytes (USC2) or 4 bytes (USC4) types. Since most strings are either ASCII or UCS2, the inner loop of the current algorithm is more tight. Admittedly, this may require some adaptation for the PEP393 unicode memory layout in order to produce identical hashes for all three representations if they represent the same content. So it's not a drop-in replacement. Is this condition required and implemented at the moment? Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python as a Metro-style App
I just tried porting Python as a Metro (Windows 8) App, and failed.
Metro Apps use a variant of the Windows API called WinRT that still
allows to write native applications in C++, but restricts various APIs
to a subset of the full Win32 functionality. For example, everything
related to subprocess creation would not work; none of the
byte-oriented file API seems to be present, and a number of file
operation functions are absent as well (such as MoveFile).
Regardless, porting Python ought to be feasible, except that it fails
fundamentally with the preview release of Visual Studio.
The problem is that compilation of C code is apparently not
supported/tested in that preview release. When compiling a trivial
C file in a Metro app, the compiler complains that a temporary file
ending with md could not be found, most likely because the C
compiler failed to generate it, whereas the C++ compiler would.
I tried compiling the Python sources as C++, but that produced
hundreds of compilation errors. Most of them are either about missing
casts (e.g. from int to enum types, or from void * to other pointer
types), or about the static forward declarations of type objects.
For the latter, anonymous namespaces should be used. While it is
feasible to replace
static PyTypeObject foo;
...
static PyTypeObject foo = {
...
};
with
Py_BEGIN_STATIC
PyTypeObject foo;
Py_END_STATIC
...
Py_BEGIN_STATIC
PyTypeObject foo = {
...
};
Py_END_STATIC
I'm not sure whether such a change would be accepted, in particular as
Microsoft might fix the bug in the compiler until the final release
of Windows 8.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
On 1/7/2012 12:57 PM, Christian Heimes wrote: Am 07.01.2012 12:02, schrieb Stefan Behnel: Admittedly, this may require some adaptation for the PEP393 unicode memory layout in order to produce identical hashes for all three representations if they represent the same content. So it's not a drop-in replacement. Is this condition required and implemented at the moment? If o1 == o2, then hash(o1) == hash(o2) is an unstated requirement implied by They [hash values] are used to quickly compare dictionary keys during a dictionary lookup. since hash(o1) != hash(o2) is taken to mean o1 != o2 (whereas hash(o1) == hash(o2) is taken to mean o1 == o2 is possible but must be checked). Hashing should be a coarsening of == as an equivalence relationship. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] A question about the subprocess implementation
The subprocess.Popen constructor takes stdin, stdout and stderr keyword
arguments which are supposed to represent the file handles of the child process.
The object also has stdin, stdout and stderr attributes, which one would naively
expect to correspond to the passed in values, except where you pass in e.g.
subprocess.PIPE (in which case the corresponding attribute would be set to an
actual stream or descriptor).
However, in common cases, even when keyword arguments are passed in, the
corresponding attributes are set to None. The following script
import os
from subprocess import Popen, PIPE
import tempfile
cmd = 'ls /tmp'.split()
p = Popen(cmd, stdout=open(os.devnull, 'w+b'))
print('process output streams: %s, %s' % (p.stdout, p.stderr))
p = Popen(cmd, stdout=tempfile.TemporaryFile())
print('process output streams: %s, %s' % (p.stdout, p.stderr))
prints
process output streams: None, None
process output streams: None, None
under both Python 2.7 and 3.2. However, if subprocess.PIPE is passed in, then
the corresponding attribute *is* set: if the last four lines are changed to
p = Popen(cmd, stdout=PIPE)
print('process output streams: %s, %s' % (p.stdout, p.stderr))
p = Popen(cmd, stdout=open(os.devnull, 'w+b'), stderr=PIPE)
print('process output streams: %s, %s' % (p.stdout, p.stderr))
then you get
process output streams: open file 'fdopen', mode 'rb' at 0x2088660, None
process output streams: None, open file 'fdopen', mode 'rb' at 0x2088e40
under Python 2.7, and
process output streams: _io.FileIO name=3 mode='rb', None
process output streams: None, _io.FileIO name=5 mode='rb'
This seems to me to contradict the principle of least surprise. One would
expect, when an file-like object is passed in as a keyword argument, that it be
placed in the corresponding attribute. That way, if one wants to do
p.stdout.close() (which is necessary in some cases), one doesn't hit an
AttributeError because NoneType has no attribute 'close'.
This seems like it might be a bug, but if so it does seem rather egregious: can
someone tell me if there is a good design reason for the current behaviour? If
there isn't one, I'll raise an issue.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
2012/1/7 Martin v. Löwis mar...@v.loewis.de: I just tried porting Python as a Metro (Windows 8) App, and failed. Is this required for Python to run on Windows 8? Sorry if that's a dumb question. I'm not sure if Metro App is a special class of application. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
Zitat von Benjamin Peterson benja...@python.org: 2012/1/7 Martin v. Löwis mar...@v.loewis.de: I just tried porting Python as a Metro (Windows 8) App, and failed. Is this required for Python to run on Windows 8? No. Existing applications (desktop applications) will continue to work unmodified. Metro-style apps are primarily intended for smart phones and tablet PCs, and will be distributed through the Windows app store. The current VS prerelease supports both Intel and ARM processors for Apps. A related question is whether Python will compile unmodified with Visual Studio 11. Although I had some difficulties with that also so far, I expect that this will ultimately work (although not unmodified - the project files need to be updated, as will the packaging process). A then-related question is whether Python 3.3 should be compiled with Visual Studio 11. I'd still be in favor of that, provided Microsoft manages to release that soon enough. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
On Sat, Jan 7, 2012 at 16:07, mar...@v.loewis.de wrote: A then-related question is whether Python 3.3 should be compiled with Visual Studio 11. I'd still be in favor of that, provided Microsoft manages to release that soon enough. I'm guessing the change would have to be done before the first beta? It would have to be released awfully soon, and I haven't heard an estimated release date as of yet. I currently have the default branch mostly ported to VS 2010 save for a number of failed tests, FWIW. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
A then-related question is whether Python 3.3 should be compiled with Visual Studio 11. I'd still be in favor of that, provided Microsoft manages to release that soon enough. Martin, I assume you mean the Express version of Visual Studio 11 here, right? Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
On Sat, 07 Jan 2012 18:57:41 +0100 Martin v. Löwis mar...@v.loewis.de wrote: For example, everything related to subprocess creation would not work; none of the byte-oriented file API seems to be present, and a number of file operation functions are absent as well (such as MoveFile). When you say MoveFile is absent, is MoveFileEx supported instead? Or is moving files just totally impossible? Depending on the extent of removed/disabled functionality, it might not be very interesting to have a Metro port at all. I'm not sure whether such a change would be accepted, in particular as Microsoft might fix the bug in the compiler until the final release of Windows 8. I would hope they finally support compiling C code... Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
On 1/7/2012 4:47 PM, Benjamin Peterson wrote: 2012/1/7 Martin v. Löwismar...@v.loewis.de: I just tried porting Python as a Metro (Windows 8) App, and failed. Is this required for Python to run on Windows 8? No, normal 'desktop' programs will still run in desktop mode. Sorry if that's a dumb question. I'm not sure if Metro App is a special class of application. Yes. They are basically 'phone/touchpad' apps, and will be managed in the more or less the same way. They will probably only be available through MS storefront, after vetting by MS. Only Metro Apps will survive a system Refresh, along with user data. Traditional unvetted, direct-from-supplier, desktops apps will be wiped because they might be 'bad'. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling 2.7.2 on OS/2
Hi Terry,
On 07/01/12 19:47, Terry Reedy wrote:
On 1/7/2012 3:48 AM, Paul Smedley wrote:
using _init_posix() for 'os2' instead of _init_non_posix is the fix for
this.
sysconfig.py also needs the following changes:
--- \dev\Python-2.7.2-o\Lib\sysconfig.py 2012-01-06 19:27:14.0
+1030
+++ sysconfig.py 2012-01-07 19:03:00.0 +1030
@@ -46,7 +46,7 @@
'scripts': '{base}/Scripts',
'data' : '{base}',
},
- 'os2_home': {
+ 'os2_user': {
'stdlib': '{userbase}/lib/python{py_version_short}',
'platstdlib': '{userbase}/lib/python{py_version_short}',
'purelib': '{userbase}/lib/python{py_version_short}/site-packages',
@@ -413,9 +413,9 @@
_CONFIG_VARS['platbase'] = _EXEC_PREFIX
_CONFIG_VARS['projectbase'] = _PROJECT_BASE
- if os.name in ('nt', 'os2'):
+ if os.name in ('nt'):
_init_non_posix(_CONFIG_VARS)
- if os.name == 'posix':
+ if os.name in ('posix', 'os2'):
_init_posix(_CONFIG_VARS)
Submit a patch on the tracker, preferably as a file rather than cut and
paste.
Will do right now.
Cheers,
Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A question about the subprocess implementation
On 1/7/2012 4:25 PM, Vinay Sajip wrote:
The subprocess.Popen constructor takes stdin, stdout and stderr keyword
arguments which are supposed to represent the file handles of the child process.
The object also has stdin, stdout and stderr attributes, which one would naively
expect to correspond to the passed in values, except where you pass in e.g.
subprocess.PIPE (in which case the corresponding attribute would be set to an
actual stream or descriptor).
However, in common cases, even when keyword arguments are passed in, the
corresponding attributes are set to None. The following script
import os
from subprocess import Popen, PIPE
import tempfile
cmd = 'ls /tmp'.split()
p = Popen(cmd, stdout=open(os.devnull, 'w+b'))
print('process output streams: %s, %s' % (p.stdout, p.stderr))
p = Popen(cmd, stdout=tempfile.TemporaryFile())
print('process output streams: %s, %s' % (p.stdout, p.stderr))
prints
process output streams: None, None
process output streams: None, None
under both Python 2.7 and 3.2. However, if subprocess.PIPE is passed in, then
the corresponding attribute *is* set: if the last four lines are changed to
p = Popen(cmd, stdout=PIPE)
print('process output streams: %s, %s' % (p.stdout, p.stderr))
p = Popen(cmd, stdout=open(os.devnull, 'w+b'), stderr=PIPE)
print('process output streams: %s, %s' % (p.stdout, p.stderr))
then you get
process output streams:open file 'fdopen', mode 'rb' at 0x2088660, None
process output streams: None,open file 'fdopen', mode 'rb' at 0x2088e40
under Python 2.7, and
process output streams:_io.FileIO name=3 mode='rb', None
process output streams: None,_io.FileIO name=5 mode='rb'
This seems to me to contradict the principle of least surprise. One would
expect, when an file-like object is passed in as a keyword argument, that it be
placed in the corresponding attribute.
The behavior matches the doc: Popen.stdin
If the stdin argument was PIPE, this attribute is a file object that
provides input to the child process. Otherwise, it is None.
-- ditto for Popen.stdout, .stderr
That way, if one wants to do
p.stdout.close() (which is necessary in some cases), one doesn't hit an
AttributeError because NoneType has no attribute 'close'.
I believe you are expected to keep a reference to anything you pass in.
pout = open(os.devnull, 'w+b')
p = Popen(cmd, stdout=pout, 'w+b'), stderr=PIPE)
The attributes were added for the case when you do not otherwise have
access.
This seems like it might be a bug, but if so it does seem rather egregious:
It would be egregious if is were a bug, but it is not.
someone tell me if there is a good design reason for the current behaviour? If
there isn't one, I'll raise an issue.
That seems like a possibly reasonable enhancement request. But the
counterargument might be that you have to separately keep track of the
need to close anyway. Or that you should do things like
with open(os.devnull, 'w+b') as pout:
p = Popen(cmd, stdout=pout, 'w+b'), stderr=PIPE)
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
On 7 January 2012 22:56, Eli Bendersky eli...@gmail.com wrote: A then-related question is whether Python 3.3 should be compiled with Visual Studio 11. I'd still be in favor of that, provided Microsoft manages to release that soon enough. Martin, I assume you mean the Express version of Visual Studio 11 here, right? I would assume that Express should work, but the python.org distributed binaries will use the full version (IIUC, the official distribution uses some optimisations not present in Express - Profile Guided Optimisation, I believe). Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
On Sat, Jan 7, 2012 at 18:04, Paul Moore p.f.mo...@gmail.com wrote: On 7 January 2012 22:56, Eli Bendersky eli...@gmail.com wrote: A then-related question is whether Python 3.3 should be compiled with Visual Studio 11. I'd still be in favor of that, provided Microsoft manages to release that soon enough. Martin, I assume you mean the Express version of Visual Studio 11 here, right? I would assume that Express should work, but the python.org distributed binaries will use the full version (IIUC, the official distribution uses some optimisations not present in Express - Profile Guided Optimisation, I believe). The bigger issue is how Express doesn't (officially) support x64 builds, unless that's changing in VS11. Perhaps this is better for another topic, but is anyone using the PGO stuff? I know we have PGInstrument and PGUpdate build configurations but I've never seen them mentioned anywhere. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
Antoine Pitrou: When you say MoveFile is absent, is MoveFileEx supported instead? WinRT strongly prefers asynchronous methods for all lengthy operations. The most likely call to use for moving files is StorageFile.MoveAsync. http://msdn.microsoft.com/en-us/library/windows/apps/br227219.aspx Depending on the extent of removed/disabled functionality, it might not be very interesting to have a Metro port at all. Asynchronous APIs will become much more important on all platforms in the future to ensure responsive user interfaces. Python should not be left behind. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A question about the subprocess implementation
On Sat, 7 Jan 2012 21:25:37 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
The subprocess.Popen constructor takes stdin, stdout and stderr keyword
arguments which are supposed to represent the file handles of the child
process.
The object also has stdin, stdout and stderr attributes, which one would
naively
expect to correspond to the passed in values, except where you pass in e.g.
subprocess.PIPE (in which case the corresponding attribute would be set to an
actual stream or descriptor).
However, in common cases, even when keyword arguments are passed in, the
corresponding attributes are set to None. The following script
Note that this is documented behavior for these attributes.
This seems to me to contradict the principle of least surprise. One
would expect, when an file-like object is passed in as a keyword
argument, that it be placed in the corresponding attribute.
Since the only reason they exist is so you can access your end of a
pipe, setting them to anything would seem to be a bug. I'd argue that
their existence is more a pola violation than them having the value
None. But None is easier than a call to hasattr.
That way, if one wants to do p.stdout.close() (which is necessary in
some cases), one doesn't hit an AttributeError because NoneType has
no attribute 'close'.
You can close the object you passed in if it wasn't PIPE. If you
passed in PIPE, the object has to be exposed some way, otherwise you
*can't* close it.
This did raise one interesting question, which will go to ideas...
mike
--
Mike Meyer m...@mired.org http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O ascii ribbon campaign - stop html mail - www.asciiribbon.org
import os
from subprocess import Popen, PIPE
import tempfile
cmd = 'ls /tmp'.split()
p = Popen(cmd, stdout=open(os.devnull, 'w+b'))
print('process output streams: %s, %s' % (p.stdout, p.stderr))
p = Popen(cmd, stdout=tempfile.TemporaryFile())
print('process output streams: %s, %s' % (p.stdout, p.stderr))
prints
process output streams: None, None
process output streams: None, None
under both Python 2.7 and 3.2. However, if subprocess.PIPE is passed in, then
the corresponding attribute *is* set: if the last four lines are changed to
p = Popen(cmd, stdout=PIPE)
print('process output streams: %s, %s' % (p.stdout, p.stderr))
p = Popen(cmd, stdout=open(os.devnull, 'w+b'), stderr=PIPE)
print('process output streams: %s, %s' % (p.stdout, p.stderr))
then you get
process output streams: open file 'fdopen', mode 'rb' at 0x2088660, None
process output streams: None, open file 'fdopen', mode 'rb' at 0x2088e40
under Python 2.7, and
process output streams: _io.FileIO name=3 mode='rb', None
process output streams: None, _io.FileIO name=5 mode='rb'
This seems to me to contradict the principle of least surprise. One would
expect, when an file-like object is passed in as a keyword argument, that it
be
placed in the corresponding attribute. That way, if one wants to do
p.stdout.close() (which is necessary in some cases), one doesn't hit an
AttributeError because NoneType has no attribute 'close'.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
When you say MoveFile is absent, is MoveFileEx supported instead? WinRT strongly prefers asynchronous methods for all lengthy operations. The most likely call to use for moving files is StorageFile.MoveAsync. http://msdn.microsoft.com/en-us/library/windows/apps/br227219.aspx How does it translate to C? Depending on the extent of removed/disabled functionality, it might not be very interesting to have a Metro port at all. Asynchronous APIs will become much more important on all platforms in the future to ensure responsive user interfaces. Python should not be left behind. I'm not sure why responsive user interfaces would be more important today than 10 years ago, but at least I hope Microsoft has found something more usable than overlapped I/O. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #9993: When the source and destination are on different filesystems,
On Sun, Jan 8, 2012 at 4:00 AM, Antoine Pitrou solip...@pitrou.net wrote: I'm not sure it was *well* defined (or even defined at all). It seems more of a by-product of the implementation. It's not only different from mv, but it's inconsistent with itself (the semantics are different depending on whether the paths are on the same filesystem or not; also, it copied the *file* but erased the *link*). Yeah, Hynek's explanation pointing out the existing inconsistencies made sense to me. I have to agree with the point that symlinks+removable media are almost inevitably going to create weirdness that isn't easily handled by any means other than symlinks=False :P Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
Antoine Pitrou: How does it translate to C? The simplest technique would be to use C++ code to bridge from C to the API. If you really wanted to you could explicitly call the function pointer in the COM vtable but doing COM in C is more effort than calling through C++. I'm not sure why responsive user interfaces would be more important today than 10 years ago, but at least I hope Microsoft has found something more usable than overlapped I/O. They are more important now due to the use of phones and tablets together with distant file systems. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
On 2012-01-08, at 01:27 , Antoine Pitrou wrote: When you say MoveFile is absent, is MoveFileEx supported instead? WinRT strongly prefers asynchronous methods for all lengthy operations. The most likely call to use for moving files is StorageFile.MoveAsync. http://msdn.microsoft.com/en-us/library/windows/apps/br227219.aspx How does it translate to C? From what I've read so far, it does not. WinRT inherits from COM (and the .net framework in some parts), so it seems like it's fundamentally an object-based API and the lowest-level language available is two variants of C++ (a template library and an extension to C++ which looks a bit like MS's older C++/CLI). I have not seen any mention of C bindings for WinRT so far. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A question about the subprocess implementation
Terry Reedy tjreedy at udel.edu writes: The behavior matches the doc: Popen.stdin If the stdin argument was PIPE, this attribute is a file object that provides input to the child process. Otherwise, it is None. Right, but it's not very helpful, nor especially intuitive. Why does it have to be None in the case where you pass in a file object? Is there some benefit to be gained by doing this? Does something bad happen if you store that file object in proc.stdin / proc.stdout / proc.stderr? I believe you are expected to keep a reference to anything you pass in. This can of course be done, but it can make code less clear than it needs to be. For example, if you run a subprocess asynchronously, the code that makes the Popen constructor call can be in a different place to the code that e.g. captures process output after completion. For that code to know how the Popen was constructed seems to make coupling overly strong. That seems like a possibly reasonable enhancement request. But the counterargument might be that you have to separately keep track of the need to close anyway. It may be that the close() needs to be called whether you passed PIPE in, or a file-like object - (a) because of the need to receive and handle SIGPIPE in command pipelines, and (b) because it's e.g. set to a pipe you constructed yourself, and you need to close the write end before you can issue an unsized read on the read end. So the close logic would have to do e.g. if proc.stdout is None: proc.stdout.close() else: # pull out the reference from some other place and then close it rather than just proc.stdout.close() It's doable, of course. The with construction you suggested isn't usable in the general case, where the close() code is in a different place from the code which fires off the subprocess. Of course, since the behaviour matches the docs it would be an enhancement request rather than a bug report. I was hoping someone could enlighten me as to the *reason* for the current behaviour ... as it is, subprocess comes in for some stick in the community for being hard to use ... Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A question about the subprocess implementation
Mike Meyer mwm at mired.org writes: Since the only reason they exist is so you can access your end of a pipe, setting them to anything would seem to be a bug. I'd argue that their existence is more a pola violation than them having the value None. But None is easier than a call to hasattr. I don't follow your reasoning, re. why setting them to a handle used for subprocess output would be a bug - it's logically the same as the PIPE case. For example, I might have a pipe (say, constructed using os.pipe()) whose write end is intended for the subprocess to output to, and whose read end I want to hand off to some other code to read the output from the subprocess. However, if that other code does a read() on that pipe, it will hang until the write handle for the pipe is closed. So, once the subprocess has terminated, I need to close the write handle. The actual reading might be done not in my code but in some client code of my code. While I could use some other place to store it, where's the problem in storing it in proc.stdout or proc.stderr? You can close the object you passed in if it wasn't PIPE. If you passed in PIPE, the object has to be exposed some way, otherwise you *can't* close it. Yes, I'm not disputing that I need to keep track of it - just that proc.stdout seems a good place to keep it. That way, the closing code can be de-coupled from the code that sets up the subprocess. A use case for this is when you want the subprocess and the parent to run concurrently/asynchronously, so the proc.wait() and subsequent processing happens at a different time and place to the kick-off. Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A question about the subprocess implementation
That's documented behaviour nonetheless. I would agree that the behaviour is a
stupid one (not knowing the reason for it); even so it cannot be changed in a
backwards compatible way.
Am 07.01.2012 um 22:25 schrieb Vinay Sajip vinay_sa...@yahoo.co.uk:
The subprocess.Popen constructor takes stdin, stdout and stderr keyword
arguments which are supposed to represent the file handles of the child
process.
The object also has stdin, stdout and stderr attributes, which one would
naively
expect to correspond to the passed in values, except where you pass in e.g.
subprocess.PIPE (in which case the corresponding attribute would be set to an
actual stream or descriptor).
However, in common cases, even when keyword arguments are passed in, the
corresponding attributes are set to None. The following script
import os
from subprocess import Popen, PIPE
import tempfile
cmd = 'ls /tmp'.split()
p = Popen(cmd, stdout=open(os.devnull, 'w+b'))
print('process output streams: %s, %s' % (p.stdout, p.stderr))
p = Popen(cmd, stdout=tempfile.TemporaryFile())
print('process output streams: %s, %s' % (p.stdout, p.stderr))
prints
process output streams: None, None
process output streams: None, None
under both Python 2.7 and 3.2. However, if subprocess.PIPE is passed in, then
the corresponding attribute *is* set: if the last four lines are changed to
p = Popen(cmd, stdout=PIPE)
print('process output streams: %s, %s' % (p.stdout, p.stderr))
p = Popen(cmd, stdout=open(os.devnull, 'w+b'), stderr=PIPE)
print('process output streams: %s, %s' % (p.stdout, p.stderr))
then you get
process output streams: open file 'fdopen', mode 'rb' at 0x2088660, None
process output streams: None, open file 'fdopen', mode 'rb' at 0x2088e40
under Python 2.7, and
process output streams: _io.FileIO name=3 mode='rb', None
process output streams: None, _io.FileIO name=5 mode='rb'
This seems to me to contradict the principle of least surprise. One would
expect, when an file-like object is passed in as a keyword argument, that it
be
placed in the corresponding attribute. That way, if one wants to do
p.stdout.close() (which is necessary in some cases), one doesn't hit an
AttributeError because NoneType has no attribute 'close'.
This seems like it might be a bug, but if so it does seem rather egregious:
can
someone tell me if there is a good design reason for the current behaviour? If
there isn't one, I'll raise an issue.
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/dasdasich%40googlemail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A question about the subprocess implementation
On 2012-01-08 10:48 , Vinay Sajip wrote: Terry Reedytjreedyat udel.edu writes: The behavior matches the doc: Popen.stdin If the stdin argument was PIPE, this attribute is a file object that provides input to the child process. Otherwise, it is None. Right, but it's not very helpful, nor especially intuitive. Why does it have to be None in the case where you pass in a file object? Is there some benefit to be gained by doing this? Does something bad happen if you store that file object in proc.stdin / proc.stdout / proc.stderr? proc.stdin, proc.stdout, and proc.stderr aren't meant to be a reference to the file that got connected to the subprocess' stdin/stdout/stderr. They are meant to be a reference to the OTHER END of the pipe that got connected. When you pass in a normal file object there is no such thing as the OTHER END of that file. The value None reflects this fact, and should continue to do so. -Phil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A question about the subprocess implementation
On Sun, 8 Jan 2012 02:06:33 + (UTC) Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Mike Meyer mwm at mired.org writes: Since the only reason they exist is so you can access your end of a pipe, setting them to anything would seem to be a bug. I'd argue that their existence is more a pola violation than them having the value None. But None is easier than a call to hasattr. I don't follow your reasoning, re. why setting them to a handle used for subprocess output would be a bug - it's logically the same as the PIPE case. No, it isn't. In the PIPE case, the value of the attributes isn't otherwise available to the caller. I think you're not following because you're thinking about what you want to do with the attributes: storing it [the fd] in proc.stdout or proc.stderr? As opposed to what they're used for, which is communicating the fd's created in the PIPE case to the caller. Would you feel the same way if they were given the more accurate names pipe_input and pipe_output? You can close the object you passed in if it wasn't PIPE. If you passed in PIPE, the object has to be exposed some way, otherwise you *can't* close it. Yes, I'm not disputing that I need to keep track of it - just that proc.stdout seems a good place to keep it. I disagree. Having the proc object keep track of these things for you is making it more complicated (by the admittedly trivial change of assigning those two attributes when they aren't used) so you can make your process creation code less complicated (by the equally trivial change of assigning the values in those two attributes when they are used). Since only the caller knows when this complication is needed, that's the logical place to put it. That way, the closing code can be de-coupled from the code that sets up the subprocess. There are other ways to do that. It's still the same tradeoff - you're making the proc code more complicated to make the calling code simpler, even though only the calling code knows if that's needed. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
Zitat von Eli Bendersky eli...@gmail.com: A then-related question is whether Python 3.3 should be compiled with Visual Studio 11. I'd still be in favor of that, provided Microsoft manages to release that soon enough. Martin, I assume you mean the Express version of Visual Studio 11 here, right? *Here*, I mean Visual Studio 11, any edition. I don't think the edition matters for determining what version the project files have - any edition will be able to read the project files, Express or not. If you are specifically asking whether I would make the release of the express edition a prerequisite to releasing Python: no, I wouldn't. I would expect that Microsoft releases the express edition along with or soon after the commercial editions, and the commercial edition is sufficient for running the Python release process. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
When you say MoveFile is absent, is MoveFileEx supported instead? Or is moving files just totally impossible? I can't check the SDK headers right now, but according to the online documentation, MoveFileExW is indeed available. I'm not sure whether you are allowed to pass arbitrary file names in an App, though. Depending on the extent of removed/disabled functionality, it might not be very interesting to have a Metro port at all. I'm not so sure. Even if the low-level Win32 API was not available, you might still be able to do useful things with the higher-level APIs, such as Windows.Storage (in case of file access). If you use, say, Windows.Storage.ApplicationData.RoamingSettings in your app, you should not actually worry what the file is named on disk (or whether there is a spinning disk in the system at all, which probably isn't). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
Perhaps this is better for another topic, but is anyone using the PGO stuff? I know we have PGInstrument and PGUpdate build configurations but I've never seen them mentioned anywhere. I'm using them in the 32-bit builds. I don't use them for the 64-bit builds, as the build machine was a 32-bit system (but perhaps I start with PGO for Win64 for 3.3). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
Zitat von Antoine Pitrou solip...@pitrou.net: When you say MoveFile is absent, is MoveFileEx supported instead? WinRT strongly prefers asynchronous methods for all lengthy operations. The most likely call to use for moving files is StorageFile.MoveAsync. http://msdn.microsoft.com/en-us/library/windows/apps/br227219.aspx How does it translate to C? Not sure whether you are asking literally for *C*: please remember that my original report said that C is apparently not currently supported for Apps. In any case, for native C++ code, do StorageFile ^the_file = something(); the_file-MoveAsync(destinationFolder, newfile.txt); This may look like managed C++ to you, but it really compiles into native code. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
