Re: UNABLE TO GET IDLE TO RUN

[Laura Creighton]

I think that it would be useful if IDLE spit out a warning:

Warning: local file /u/lac/junk/string.py shadows module named string in the 
Standard Library

Laura

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most space-efficient way to store log entries

[Laura Creighton]

Did the OP say he wanted to keep his compressed logfiles on a
local disk?  What if he wants to send them across the internet
to some other machine and would like the transfer to happen as
quickly as possible?

Laura

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: system error - api-ms-win-crt-runtime-l1-1-0.dll

[Laura Creighton]

1. If you are running XP, you cannot run Python 3.5.  XP is not supported.
   You need to get a newer OS.
2. Otherwise, the api-ms-win-crt-runtime-l1-1-0-dll is Microsofts Universal 
   CRT.  You don't have one.  You need to install it. Get it here:
   http://www.microsoft.com/en-us/download/details.aspx?id=48234

Laura


-- 
https://mail.python.org/mailman/listinfo/python-list

RE: system error - api-ms-win-crt-runtime-l1-1-0.dll

[Nagu Koppula]

Hi Laura,

 

Thanks for your quick response and help!

It is windows 7 and it is working after I downloaded the Microsoft's
Universal CRT.

 

 

Regards,

Nagu

-Original Message-
From: Laura Creighton [mailto:l...@openend.se] 
Sent: Thursday, October 29, 2015 4:34 PM
To: Nagu Koppula 
Cc: python-list@python.org; l...@openend.se
Subject: Re: system error - api-ms-win-crt-runtime-l1-1-0.dll

 

1. If you are running XP, you cannot run Python 3.5.  XP is not supported.

   You need to get a newer OS.

2. Otherwise, the api-ms-win-crt-runtime-l1-1-0-dll is Microsofts Universal 

   CRT.  You don't have one.  You need to install it. Get it here:


http://www.microsoft.com/en-us/download/details.aspx?id=48234

 

Laura

 

-- 
https://mail.python.org/mailman/listinfo/python-list

Problem working with subprocess.check_call

[David Aldrich]

Hi

I am working on Linux with Python 3.4.

I want to do a bash diff on two text files and show just the first 20 lines of 
diff's output.  So I tried:

>>> cmd = 'head -20 <(diff ' + file1 + ' ' + file2 + ')'
>>> subprocess.check_call(cmd, shell=True)

The command contained in cmd works ok from the bash prompt but not from Python 
code.  In Python I get:

/bin/sh: -c: line 0: syntax error near unexpected token `('

I think the problem is that check_call is not using the bash shell.  So I also 
tried:

>>> subprocess.check_call("bash", "-O", "extglob", "-c", cmd)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.4/subprocess.py", line 556, in check_call
retcode = call(*popenargs, **kwargs)
  File "/usr/local/lib/python3.4/subprocess.py", line 537, in call
with Popen(*popenargs, **kwargs) as p:
  File "/usr/local/lib/python3.4/subprocess.py", line 767, in __init__
raise TypeError("bufsize must be an integer")
TypeError: bufsize must be an integer

Can anyone help me with this please?

Best regards

David

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem working with subprocess.check_call

[INADA Naoki]

On Thu, Oct 29, 2015 at 6:52 PM, David Aldrich 
wrote:

> Hi
>
>
>
> I am working on Linux with Python 3.4.
>
>
>
> I want to do a bash diff on two text files and show just the first 20
> lines of diff’s output.  So I tried:
>
>
>
> >>> cmd = 'head -20 <(diff ' + file1 + ' ' + file2 + ')'
>
> >>> subprocess.check_call(cmd, shell=True)
>
>
>
> The command contained in cmd works ok from the bash prompt but not from
> Python code.  In Python I get:
>
>
>
> /bin/sh: -c: line 0: syntax error near unexpected token `('
>
>
>
> I think the problem is that check_call is not using the bash shell.  So I
> also tried:
>
>
>
> >>> subprocess.check_call("bash", "-O", "extglob", "-c", cmd)
>

Try this

subprocess.check_call(["bash", "-O", "extglob", "-c", cmd])


> Traceback (most recent call last):
>
>   File "", line 1, in 
>
>   File "/usr/local/lib/python3.4/subprocess.py", line 556, in check_call
>
> retcode = call(*popenargs, **kwargs)
>
>   File "/usr/local/lib/python3.4/subprocess.py", line 537, in call
>
> with Popen(*popenargs, **kwargs) as p:
>
>   File "/usr/local/lib/python3.4/subprocess.py", line 767, in __init__
>
> raise TypeError("bufsize must be an integer")
>
> TypeError: bufsize must be an integer
>
>
>
> Can anyone help me with this please?
>
>
>
> Best regards
>
>
>
> David
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>


-- 
INADA Naoki  
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Problem working with subprocess.check_call

[David Aldrich]

> Try this

> subprocess.check_call(["bash", "-O", "extglob", "-c", cmd])

That worked. Thanks very much!

David
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem working with subprocess.check_call

[Pete Dowdell]

On 29/10/15 16:52, David Aldrich wrote:


Hi

I am working on Linux with Python 3.4.

I want to do a bash diff on two text files and show just the first 20 
lines of diff’s output.  So I tried:


>>> cmd = 'head -20 <(diff ' + file1 + ' ' + file2 + ')'

>>> subprocess.check_call(cmd, shell=True)



You could use a shell pipe in your command - and use str.format() too 
for better readability, perhaps:


> cmd = 'diff  {} {} | head -20'.format( file1, file2 )
> subprocess.check_call(cmd, shell=True)

Although this approach would not be recommended if file1 or file2 are 
not sanitised


pd
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem working with subprocess.check_call

[Laura Creighton]

In a message of Thu, 29 Oct 2015 09:52:56 +, David Aldrich writes:
>Hi
>
>I am working on Linux with Python 3.4.
>
>I want to do a bash diff on two text files and show just the first 20 lines of 
>diff's output.  So I tried:
>
 cmd = 'head -20 <(diff ' + file1 + ' ' + file2 + ')'
 subprocess.check_call(cmd, shell=True)

I am reading https://docs.python.org/3.5/library/subprocess.html

because my first thought was that shell should be False here.
The doc doesn't say.  Filing doc bug now.

Laura

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem working with subprocess.check_call

[Peter Otten]

David Aldrich wrote:

> I am working on Linux with Python 3.4.
> 
> I want to do a bash diff on two text files and show just the first 20
> lines of diff's output.  So I tried:
> 
 cmd = 'head -20 <(diff ' + file1 + ' ' + file2 + ')'
 subprocess.check_call(cmd, shell=True)
> 
> The command contained in cmd works ok from the bash prompt but not from
> Python code.  In Python I get:
> 
> /bin/sh: -c: line 0: syntax error near unexpected token `('
> 
> I think the problem is that check_call is not using the bash shell.  

I think your diagnosis is correct.

> So I
> also tried:
> 
 subprocess.check_call("bash", "-O", "extglob", "-c", cmd)
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/local/lib/python3.4/subprocess.py", line 556, in check_call
> retcode = call(*popenargs, **kwargs)
>   File "/usr/local/lib/python3.4/subprocess.py", line 537, in call
> with Popen(*popenargs, **kwargs) as p:
>   File "/usr/local/lib/python3.4/subprocess.py", line 767, in __init__
> raise TypeError("bufsize must be an integer")
> TypeError: bufsize must be an integer
> 
> Can anyone help me with this please?

Try specifying the shell explicitly:

check_call(["/bin/bash", "-c", cmd])

Or use a command that works with the default shell:

check_call("diff ... | head -n20", shell=True)

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem working with subprocess.check_call

[Laura Creighton]

In a message of Thu, 29 Oct 2015 11:11:17 +0100, Laura Creighton writes:
>In a message of Thu, 29 Oct 2015 09:52:56 +, David Aldrich writes:
>>Hi
>>
>>I am working on Linux with Python 3.4.
>>
>>I want to do a bash diff on two text files and show just the first 20 lines 
>>of diff's output.  So I tried:
>>
> cmd = 'head -20 <(diff ' + file1 + ' ' + file2 + ')'
> subprocess.check_call(cmd, shell=True)
>
>I am reading https://docs.python.org/3.5/library/subprocess.html
>
>because my first thought was that shell should be False here.
>The doc doesn't say.  Filing doc bug now.
>
>Laura

False alarm, I just cannot read today.  Inject more caffeine and try again.

Laura

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: UNABLE TO GET IDLE TO RUN

[Terry Reedy]

On 10/29/2015 3:53 AM, Laura Creighton wrote:

I think that it would be useful if IDLE spit out a warning:


User code is compiled and executed by builtin compile and exec, so it 
would have to be python (exec) that emit a warning.



Warning: local file /u/lac/junk/string.py shadows module named string in the 
Standard Library


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Most space-efficient way to store log entries

[Marc Aymerich]

On Wed, Oct 28, 2015 at 11:30 PM, Marc Aymerich  wrote:
> Hi,
> I'm writting an application that saves historical state in a log file.
> I want to be really efficient in terms of used bytes.
>
> What I'm doing now is:
>
> 1) First use zlib.compress
> 2) And then remove all new lines using binascii.b2a_base64, so I have
> a log entry per line.
>
> but b2a_base64 is far from ideal: adds lots of bytes to the compressed
> log entry. So, I wonder if perhaps there is a better way to remove new
> lines from the zlib output? or maybe a different approach?
>
> Anyone?

[]

wow, lots of interesting replies here, allow me to clarify my
situation and answear some of the questions.

I'm writing a toy project for my master thesis, which is never going
into production.

What I'm doing is a decentralized file system for configuration
managemente (without centralized authority). This means:

1) Each node on the cluster needs to keep track of *all* the changes
that ever ocurred. So far, each node is storing each change as
individual lines on a file (the "historical state log" I was referring
to, the concept is very similar to the bitcoin blockchain)

2) The main communication channel is driven by a UDP gossip protocol.
>From the performance perspective, it makes a huge difference if the
whole log entry fits into the UDP payload (512B), otherwise the log
entry has to be transferred by other means. Because config files are
mostly text, almost every single one of them can fit into a UDP
packet, if properly compressed.

After reading your replies I'm concluding that

1) I should use the most space-efficient encoding *only* for
transferring the log entry, just lzma compress it.
2) I should use the most readable one for storing the block on the log
file. Leave metadata as text and compress+base64 the "actual file
content" so it fits in an space-less ascii block, something like:

# $ cat log
# 
 

a5438566b83b4383899500c6b70dcac1 1446054664 WRITE /.keys
TUY4Q0FRRUVHQHNkl6MTNtZz09Cg==
2d:ce:6d:c5:95:54:cb:d2:fe:ba:68:ed:1d:8e:74:0f
iPDxBYuUEjlZl99/xGCNzpbuDezJJfolr+eNLNrXEYAgG/0yme3bu9DCkPO9Gq7+

cb4f67a712964699a5c2d49a42e48946 1446054664 WRITE /.cluster
MTcyLjE3LjLjEK 2d:ce:6d:c5:95:54:cb:d2:fe:ba:68:ed:1d:8e:74:0f
/VKMeVG95MT9VdObRyhidzxIgiTef+7nl3flgQpqVAgRfhqrBGRB4XTgJFSelvCo

5041fba6b6534dfe92bf99ed5ead8fa6 1446055543 MKDIR /etc
2d:ce:6d:c5:95:54:cb:d2:fe:ba:68:ed:1d:8e:74:0f
+CMeVp33FxXFSfczbmkoW4tnalu5ojuC1WprMkc7Kxp/WHlMsx9Os3Zal0Bi/uD8

80c47cd5a73e4881b7284eed465ab10a 1446055843 WRITE /etc/node.conf
aG9sYQo= 2d:ce:6d:c5:95:54:cb:d2:fe:ba:68:ed:1d:8e:74:0f
oQVF7UCAFRCC7cC0Ln8V16f8mnON465sdXoIEIGCKBUOWOBE5daFmJTu0thAkXVf



-- 
Marc
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most space-efficient way to store log entries

[Chris Angelico]

On Thu, Oct 29, 2015 at 9:35 PM, Marc Aymerich  wrote:
> 1) Each node on the cluster needs to keep track of *all* the changes
> that ever ocurred. So far, each node is storing each change as
> individual lines on a file (the "historical state log" I was referring
> to, the concept is very similar to the bitcoin blockchain)
>
> 2) The main communication channel is driven by a UDP gossip protocol.
> From the performance perspective, it makes a huge difference if the
> whole log entry fits into the UDP payload (512B), otherwise the log
> entry has to be transferred by other means. Because config files are
> mostly text, almost every single one of them can fit into a UDP
> packet, if properly compressed.
>
> After reading your replies I'm concluding that
>
> 1) I should use the most space-efficient encoding *only* for
> transferring the log entry, just lzma compress it.
> 2) I should use the most readable one for storing the block on the log
> file. Leave metadata as text and compress+base64 the "actual file
> content" so it fits in an space-less ascii block, something like:

I agree with those conclusions. If anything goes wrong, you have the
tidy log in a form that's easily dug into, and then compression is
used for transmission only.

A couple of points of interest, though:

1) Conflicts - since you lack any concept of central authority,
there's the possibility that two peers will simultaneously make
incompatible changes, and then begin propagating them through the
farm. What happens when a node receives a change it can't apply?

2) UDP is unreliable. What happens if a node misses out on a change?
Can it figure out that it's missed something, and go ask?

I'm assuming you've thought about these, and am curious as to how
you've solved them - might be useful in some of the things I've played
with.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Problem working with subprocess.check_call

[David Aldrich]

Thanks for all your answers.

David
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most space-efficient way to store log entries

[Marc Aymerich]

On Thu, Oct 29, 2015 at 11:52 AM, Chris Angelico  wrote:
> On Thu, Oct 29, 2015 at 9:35 PM, Marc Aymerich  wrote:
>> 1) Each node on the cluster needs to keep track of *all* the changes
>> that ever ocurred. So far, each node is storing each change as
>> individual lines on a file (the "historical state log" I was referring
>> to, the concept is very similar to the bitcoin blockchain)
>>
>> 2) The main communication channel is driven by a UDP gossip protocol.
>> From the performance perspective, it makes a huge difference if the
>> whole log entry fits into the UDP payload (512B), otherwise the log
>> entry has to be transferred by other means. Because config files are
>> mostly text, almost every single one of them can fit into a UDP
>> packet, if properly compressed.
>>
>> After reading your replies I'm concluding that
>>
>> 1) I should use the most space-efficient encoding *only* for
>> transferring the log entry, just lzma compress it.
>> 2) I should use the most readable one for storing the block on the log
>> file. Leave metadata as text and compress+base64 the "actual file
>> content" so it fits in an space-less ascii block, something like:
>
> I agree with those conclusions. If anything goes wrong, you have the
> tidy log in a form that's easily dug into, and then compression is
> used for transmission only.
>
> A couple of points of interest, though:
>
> 1) Conflicts - since you lack any concept of central authority,
> there's the possibility that two peers will simultaneously make
> incompatible changes, and then begin propagating them through the
> farm. What happens when a node receives a change it can't apply?

Yes, my solution is very similar to the bitcoin blockchain double
spending solution [1]. I have one blockchain for every path, all log
entries contain the hash of its ancestor, when more than one log entry
has the same ancestor we have a conflict (branching). Solving this
conflict just means that all nodes on the network should agree on
choosing the same branch. Bitcoin uses proof-of-work: the longest
chain (more CPU power) is always chosen. My nodes will chose the
branch with:
  1) more log entries with higher authority signatures (allowing to
support key revoking)**
  2) if equal, the one with more different valid signatures (more
participants say its the good one)
  3) if equal, higher hash (arbitrary but it has to be deterministic) :P

Notice that the file system is eventual consistent, the branch that is
valid now, may not be tomorrow.

**My solution for decentralized authority is having a .keys file on
each directory containing the keys that are authorized to write in it,
higher authority just means that a log entry signature belongs to a
key that appears higher in the file system hierarchy (kind of
proof-of-stake, the branch with higher authority wins so key revoking
is possible)

[1] https://en.bitcoin.it/wiki/How_bitcoin_works#Double_spending

> 2) UDP is unreliable. What happens if a node misses out on a change?
> Can it figure out that it's missed something, and go ask?

I'm still pending to read some papers on the matter (just starting),
but as far as I can tell gossip protocols take a probabilistic
approach when disseminating information, like the spread of a disease,
one particular node is exposed multiple times to the same messages by
different nodes, making gossip protocols very resilient to packet
loss. Also when a node recovers from failure (or rejoins the cluster
after a network partition) I perform a full state sync, but I still
don't know if this is sufficient or I'll need to do periodic syncs,
still learning. Btw, I'm using serf[1] which in turn uses SWIM[2], and
there are a lot of other interesting papers, just didn't read them,
yet.

[1] https://www.serfdom.io/docs/internals/gossip.html
[2] https://www.cs.cornell.edu/~asdas/research/dsn02-swim.pdf



-- 
Marc
-- 
https://mail.python.org/mailman/listinfo/python-list

python.exe is not a valid win32 executable

[Steffen Herzfeldt]

Hi,

today i downloaded python3.5.0 x86 (win32) installer.

after the programm installed the files into its standard directory without asking me if i wanted it in a different position, i tried running a program that was written for python 3.3.x

the response of my system was an error message "python.exe is not a valid 32 bit executable." .

 

I just wanted to let you know that your program just doesn't work on WinXP.

 

I guess you just think "Linux is better anyway" to which i agree until it comes to games requiring directx, but that doesn't change the fact that the installer was labeled as working on win32 systems.

 

I hope you solve the problem.

 

keep up the good work and once Linux natively handles directx i'll dump MS immediately.

 

with best regards,

 

Steffen H.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to implement an async message bus

[Nagy László Zsolt]

 try:
 return await waiter
 finally:
 # TODO: Use a context manager to add and remove the keys.
 for key in keys:
 self._waiters[key].discard(waiter)
 if handle:
 handle.cancel()

 def notify(self, key, message):
 if key in self._waiters and self._waiters[key]:
 waiter = next(iter(self._waiters[key]))
 waiter.set_result((key, message))
>>> I think this is what I needed. I'm going to try this tomorrow.
>> Yes, putting aside the asyncio/tornado distinction, I think a Future
>> will still solve the problem for you.
> No, it won't. :-( 
>
> Finally, I got it working, by replacing asyncio.Future with
> tornado.concurrent.Future.
>
> At least it is consistent. But it is also missing key features. For
> example, there is no tornado.concurrent.Condition.
I was corrected, as follows:

> asyncio.Futures depend on the asyncio event loop, so you must
> configure Tornado to use the asyncio loop:
>
>
> tornado.ioloop.IOLoop.configure('tornado.platform.asyncio.AsyncIOMainLoop')
>
> This could definitely use some better documentation. It would be nice
> if it could fail in a more graceful way (give an error message instead
> of hanging), but I'm not sure if there's any way to do that.
>

So tornado can be used with asyncio, but it requires configuration (and
it is not yet very well documented).

> Also, for your python-list message: there is now (since 4.2) a Tornado
> Condition class, but it lives in tornado.locks instead of
> tornado.concurrent.

There is a little incosistency here, but at least there is a Condition
class.

I think the tornado team is trying to make tornado fully compatible with
asyncio, just the are not there yet.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python.exe is not a valid win32 executable

[Chris Angelico]

On Fri, Oct 30, 2015 at 3:14 AM, Steffen Herzfeldt  wrote:
> Hi,
> today i downloaded python3.5.0 x86 (win32) installer.
> after the programm installed the files into its standard directory without
> asking me if i wanted it in a different position, i tried running a program
> that was written for python 3.3.x
> the response of my system was an error message "python.exe is not a valid 32
> bit executable." .
>
> I just wanted to let you know that your program just doesn't work on WinXP.

Yes, that's correct.

> I guess you just think "Linux is better anyway" to which i agree until it
> comes to games requiring directx, but that doesn't change the fact that the
> installer was labeled as working on win32 systems.

Python 3.5 *does* work on Win32 systems that are still supported by
Microsoft - specifically, Windows 7, 8, and 10, as well as the server
builds that are still in support. Maintaining support for Windows XP
would mean avoiding the benefit of newer APIs and other features, and
the policy of the Python development team is to support only those
releases of Windows which still have upstream support as of when they
are released.

You can use Python 3.4 and 2.7 on XP, and you can use Python 3.5 on
Win 7 or better.

> I hope you solve the problem.

There isn't a problem to be solved, except for the one that a
12-year-old release of a closed-source operating system is still in
use. Do you expect the latest Python builds to run on Windows 98SE?
No. It's time to move on.

Well, actually, there is one issue here, and that's that the installer
goes all the way through until the very end, and then you get that
cryptic error message. That's a known flaw in the installer, and once
Python 3.5.1 is released, that should be fixed - but it's "fixed" in
the sense that you now will get a simple and clear message, rather
than being "fixed" in terms of letting you run Python 3.5 on Win XP.

> keep up the good work and once Linux natively handles directx i'll dump MS
> immediately.

I don't know what you mean by "natively", but I play a number of
DirectX games on my Debian Linux. Give it a try! You might find that
it all works perfectly.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python.exe is not a valid win32 executable

[Laura Creighton]

In a message of Thu, 29 Oct 2015 17:14:25 +0100, "Steffen Herzfeldt" writes:
>Hi,
>today i downloaded python3.5.0 x86 (win32) installer.
>after the programm installed the files into its standard directory without
>asking me if i wanted it in a different position, i tried running a program
>that was written for python 3.3.x
>the response of my system was an error message "python.exe is not a valid
>32 bit executable." .
> 
>I just wanted to let you know that your program just doesn't work on WinXP.

Thank you.  We have a bug report in about detecting winXP early
and saying that 3.5 requires a newer version of windows.  The
next installer should report this properly.

>I guess you just think "Linux is better anyway" to which i agree until it
>comes to games requiring directx, but that doesn't change the fact that the
>installer was labeled as working on win32 systems.

You are wrong about the thinking -- indeed the installer was written
by a Microsoft employee, Steven Dower.  He just missed  having
it detect winXP.  

>I hope you solve the problem.

Alas, it is a 'won't fix' for python.org.  Maybe Activestate or
Continuum.io will support XP with their 3.5 packages, but 
python-dev is not going to.

>keep up the good work and once Linux natively handles directx i'll dump MS
>immediately.

*oh how I wish*

>with best regards,
> 
>Steffen H.

Sorry we didn't do a better job of telling you this will not work,

Laura

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python.exe is not a valid win32 executable

[Laura Creighton]

In a message of Fri, 30 Oct 2015 03:36:36 +1100, Chris Angelico writes:
>I don't know what you mean by "natively", but I play a number of
>DirectX games on my Debian Linux. Give it a try! You might find that
>it all works perfectly.

Or, if you develop games, you might not

http://www.pcworld.com/article/2940470/hey-gamers-directx-11-is-coming-to-linux-thanks-to-codeweavers-and-wine.html

has us all crossing our fingers and waiting, waiting, anxiously waiting ...

Laura

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python.exe is not a valid win32 executable

[Tim Golden]

On 29/10/2015 16:14, Steffen Herzfeldt wrote:

I just wanted to let you know that your program just doesn't work on WinXP.
I guess you just think "Linux is better anyway" to which i agree until
it comes to games requiring directx, but that doesn't change the fact
that the installer was labeled as working on win32 systems.


Others have replied that the installer has a fix for the next release 
which will highlight this sooner. I would point out that we have 
gradually dropped support for *several* win32-based systems over the 
last few years, more or less following Microsoft's own deprecation 
regime. Win9x was dropped in 2.6; 2000 was dropped in 3.3.


There's a balance to be had in everything: every system we support adds 
some burden of maintenance. There's no pro-Linux conspiracy here: just 
the development team making pragmatic choices about maintenance and support.


TJG
--
https://mail.python.org/mailman/listinfo/python-list

Re: python.exe is not a valid win32 executable

[Mark Lawrence]

On 29/10/2015 17:28, Tim Golden wrote:

On 29/10/2015 16:14, Steffen Herzfeldt wrote:

I just wanted to let you know that your program just doesn't work on
WinXP.
I guess you just think "Linux is better anyway" to which i agree until
it comes to games requiring directx, but that doesn't change the fact
that the installer was labeled as working on win32 systems.


Others have replied that the installer has a fix for the next release
which will highlight this sooner. I would point out that we have
gradually dropped support for *several* win32-based systems over the
last few years, more or less following Microsoft's own deprecation
regime. Win9x was dropped in 2.6; 2000 was dropped in 3.3.



Specifically from 
https://www.python.org/dev/peps/pep-0011/#microsoft-windows, the first 
three paragraphs.



 Microsoft has established a policy called product support lifecycle 
[1] . Each product's lifecycle has a mainstream support phase, where the 
product is generally commercially available, and an extended support 
phase, where paid support is still available, and certain bug fixes are 
released (in particular security fixes).


CPython's Windows support now follows this lifecycle. A new feature 
release X.Y.0 will support all Windows releases whose extended support 
phase is not yet expired. Subsequent bug fix releases will support the 
same Windows releases as the original feature release (even if the 
extended support phase has ended).


Because of this policy, no further Windows releases need to be listed in 
this PEP.



--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: python.exe is not a valid win32 executable

[Gisle Vanem]

Mark Lawrence wrote:


CPython's Windows support now follows this lifecycle. A new feature
release X.Y.0 will support all Windows releases whose extended support
phase is not yet expired. Subsequent bug fix releases will support the
same Windows releases as the original feature release (even if the
extended support phase has ended).


The reason for error message the OP reported is what
the MSVC 2015 (?) linker puts in the PE optional header.
From 'pedump python3.exe':

Optional Header
  Magic 010B
  linker version14.00
  ...
  file align200
  required OS version   6.00   << !!

Hence the error on Win-XP (i.e. 5.x).

Wouldn't it be more elegant of Python (and it's installer)
to put a '-subsystem:console,5.02' in the link flags?
And then detect Win-XP later on and refuse a further install?

--
--gv
--
https://mail.python.org/mailman/listinfo/python-list

Re: python.exe is not a valid win32 executable

[Laura Creighton]

In a message of Thu, 29 Oct 2015 19:21:14 +0100, Gisle Vanem writes:
>Wouldn't it be more elegant of Python (and it's installer)
>to put a '-subsystem:console,5.02' in the link flags?
>And then detect Win-XP later on and refuse a further install?
>
>-- 
>--gv
>-- 
>https://mail.python.org/mailman/listinfo/python-list

In 3.5.1 it will (already does, I think).  Actually I do not know
how Steve Dower chose to detect XP early, but that would be a
good way. see https://bugs.python.org/issue25143
And add your idea if you like.

Laura
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most space-efficient way to store log entries

[Cameron Simpson]

On 29Oct2015 09:15, Laura Creighton  wrote:

Did the OP say he wanted to keep his compressed logfiles on a
local disk?  What if he wants to send them across the internet
to some other machine and would like the transfer to happen as
quickly as possible?


Then he's still better off keeping them uncompressed and using compression in 
the transfer. "ssh -o compression=yes" or "rsync -z", etc.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Most space-efficient way to store log entries

[Laura Creighton]

In a message of Fri, 30 Oct 2015 08:28:07 +1100, Cameron Simpson writes:
>On 29Oct2015 09:15, Laura Creighton  wrote:
>>Did the OP say he wanted to keep his compressed logfiles on a
>>local disk?  What if he wants to send them across the internet
>>to some other machine and would like the transfer to happen as
>>quickly as possible?
>
>Then he's still better off keeping them uncompressed and using compression in 
>the transfer. "ssh -o compression=yes" or "rsync -z", etc.
>
>Cheers,
>Cameron Simpson 

"ssh -o compression=yes" is what I am using.
But I am all ears for a better idea.

We can do no better?

Laura

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most space-efficient way to store log entries

[Laura Creighton]

In a message of Fri, 30 Oct 2015 09:47:42 +1100, Cameron Simpson writes:
>Another post suggests that the OP is transferring log info in UDP packets and 
>hopes to keep the state within a maximum packet size, hence his desire for 
>compact representation. I suspect that personally I'd be going for some 
>efficient text encoding of the state and putting whatever compression he 
>intends in the UDP throw/catch:
>
>  take text log line
>  compress
>  send over UDP
>  receive UDP packet
>  decompress
>  store in clear text
>
>or bypass UDP altogether, but I imagine the OP has his reasons.

I'd bypass UDP altogether.

But in terms of my problem

ssh -o compression=yes

Can we get my files over faster?

This is plenty fast enough for our nightly
(Should the americans nuke us, we can get the
kayaking club up ok) transfer out of country. :)

I have never worried of if before.

 But, efficiency for its own sake.
Way useless,  but way cool.

can I get my files out faster?

Laura
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most space-efficient way to store log entries

[Cameron Simpson]

On 29Oct2015 23:16, Laura Creighton  wrote:

In a message of Fri, 30 Oct 2015 08:28:07 +1100, Cameron Simpson writes:

On 29Oct2015 09:15, Laura Creighton  wrote:

Did the OP say he wanted to keep his compressed logfiles on a
local disk?  What if he wants to send them across the internet
to some other machine and would like the transfer to happen as
quickly as possible?


Then he's still better off keeping them uncompressed and using compression in
the transfer. "ssh -o compression=yes" or "rsync -z", etc.

Cheers,
Cameron Simpson 


"ssh -o compression=yes" is what I am using.
But I am all ears for a better idea.

We can do no better?


Depends on your criteria for "better". Absent other constraints I'm broadly 
for:


 keeping logs uncompressed and unencoded, for ease of eyeballing and processing 
with text tools

 rotating and compressing logs if feasible

 avoiding compression and other encoding within log lines

Another post suggests that the OP is transferring log info in UDP packets and 
hopes to keep the state within a maximum packet size, hence his desire for 
compact representation. I suspect that personally I'd be going for some 
efficient text encoding of the state and putting whatever compression he 
intends in the UDP throw/catch:


 take text log line
 compress
 send over UDP
 receive UDP packet
 decompress
 store in clear text

or bypass UDP altogether, but I imagine the OP has his reasons.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Most space-efficient way to store log entries

[Marc Aymerich]

On Thu, Oct 29, 2015 at 11:57 PM, Laura Creighton  wrote:
> In a message of Fri, 30 Oct 2015 09:47:42 +1100, Cameron Simpson writes:
>>Another post suggests that the OP is transferring log info in UDP packets and
>>hopes to keep the state within a maximum packet size, hence his desire for
>>compact representation. I suspect that personally I'd be going for some
>>efficient text encoding of the state and putting whatever compression he
>>intends in the UDP throw/catch:
>>
>>  take text log line
>>  compress
>>  send over UDP
>>  receive UDP packet
>>  decompress
>>  store in clear text
>>
>>or bypass UDP altogether, but I imagine the OP has his reasons.
>
> I'd bypass UDP altogether.
>
> But in terms of my problem
>
> ssh -o compression=yes
>
> Can we get my files over faster?
>
> This is plenty fast enough for our nightly
> (Should the americans nuke us, we can get the
> kayaking club up ok) transfer out of country. :)
>
> I have never worried of if before.
>
>  But, efficiency for its own sake.
> Way useless,  but way cool.
>
> can I get my files out faster?

Usually I use my home router (which has an attached HDD) for
downloading movies and stuff (big files) from the WAN... it has a
800Mhz mips cpu... anyway my experience with it is that:

rsync tops at ~400Kbps
apache+wget tops at ~1.1Mbps
netcat tops at ~1.4Mbps

-- 
Marc
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python.exe is not a valid win32 executable

[Terry Reedy]

On 10/29/2015 1:14 PM, Laura Creighton wrote:


Alas, it is a 'won't fix' for python.org.  Maybe Activestate or
Continuum.io will support XP with their 3.5 packages,


It would be an unpleasant task at best.  CPython does not work with xp 
because is uses shiny new system features that first appeared in Vista. 
 Either they were not used before, or the code contained version-based 
conditions to either use the new feature or use an inferior workaround.


Suppose you want to use 'yield from' in a 3.x module.  You have 3 
choices: 1. don't use it; 2. use it conditionally and also provide a 
workaround based on 'yield'; 3. use it and as a consequence, require 3.4+.


By analogy, the cpython developers felt constrained to use options 1 or 
2, both of which have their costs, and support xp for as long as 
Microsoft supported xp.  When Microsoft dropped support for xp, they 
felt free to switch to option 3 *for new versions*.


I don't know if there are any new-in-win7 features that coredevs are 
just waiting to use when Vista goes off MS support.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Most space-efficient way to store log entries

[Cameron Simpson]

On 30Oct2015 00:35, Marc Aymerich  wrote:

Usually I use my home router (which has an attached HDD) for
downloading movies and stuff (big files) from the WAN... it has a
800Mhz mips cpu... anyway my experience with it is that:

rsync tops at ~400Kbps


Rsync is not a maximally efficient file transfer tool. What it excels at is 
incremental transfer, when you have some of a set of files, or a portion of a 
file you need to extend, such as updating a copy of a growing log file.



apache+wget tops at ~1.1Mbps
netcat tops at ~1.4Mbps


You might also try scp or sftp. On a LAN or if one endpoint is CPU constrained 
(probably the data source) you may find that compression is actually a lose. If 
your source data is already low redundancy (video, many audio formats, most 
image data, already compressed files like .gz or .zip) then compression is 
definitely a lose.


Finally, on a LAN you may be able to mount one end or the other as a remote 
filesystem. Then you can benchmark plain old "cp" over SMB or NFS etc.


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Windows 10 pip2.7.exe uninstall fails

[Mark Lawrence]

On 28/10/2015 12:22, Robin Becker wrote:



A message box is displayed:-

"This app can't run on your PC
To find a version for your PC, check with the software publisher".

Close the message box and:-

"Access is denied."

Searching hasn't thrown up a single reference to uninstall errors like
this, any
ideas?




so perhaps yours is an exceptional case


pip.exe and pip2.exe 96kb, pip2.7.exe 0kb might explain things.  Please 
don't ask, I don't know :(


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list