Thanks for the help

[Martin S]

I completed the basic version of my learning app. (It can be found
here for those remotely interested:
http://www.tyresoschack.se/apps/LASK.py). (LASK rating usually are in
the range c 800 to c 2700 the higher the better).

It's just a simple tool to calculate LASK chess rating and completely
CLI based. The tutorial I was following doesn't cover GUI or error
correction so that will naturally be the next steps in completing the
thing.

Anyway, thanks for explaining the confusing points so far.

Regards,

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

Re: Python 3 is killing Python

[Steven D'Aprano]

On Wed, 16 Jul 2014 14:20:37 +1000, Chris Angelico wrote:

> On Wed, Jul 16, 2014 at 1:51 PM, Steven D'Aprano
>  wrote:
>> Perhaps the *stupidest* thing the author of the "Python 3 is killing
>> Python" blog post wrote was that it's easier to port Python code to a
>> *completely different language*. I cannot fathom the idiocy of somebody
>> who bitches and moans that having to re-write or redesign, oh, let's
>> conservatively say 5% of your Python 2 code is harder than writing your
>> code *completely from scratch* in a completely different language, with
>> completely different third party libraries.
> 
> There's only one way that it's easier to port to a completely new
> language. Pick another language where string handling is as naive as my
> last boss

But even then, you still have to re-write all your code in the new 
language. Using different libraries. All your unit tests are obsolete 
(although your integration tests may not be). End-user documentation will 
probably be re-usable, but documentation aimed at your developers will 
need to be re-written.



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

Re: Mac python py2app problem

[Gregory Ewing]

Kevin Walzer wrote:

On 7/15/14, 9:56 PM, Nicholas Cannon wrote:

I then put the .msi on sourceforge and it works great 
but when i put the .app on there and download it it says something 
like i can open this on old architecture or something so i have to put 
it through google drive


It's hard to make sense of what you are asking for. Can you just zip up 
the app bundle that py2app produces and upload it that way?


Are you aware that a .app on MacOSX is actually a
directory, not a single file? So, as Kevin says,
you will need to turn it into a zip file or
something similar that you can upload to a web
site.

Another popular way to distribute a MacOSX app
is using a disk image file (.dmg). Disk Utility
can be used to create those.

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

Re: Python 3 is killing Python

[Steven D'Aprano]

On Wed, 16 Jul 2014 08:52:31 +0300, Marko Rauhamaa wrote:

> Steven D'Aprano :
> 
>> On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote:
>>> In fact, I find the lazy use of Unicode strings at least as scary as
>>> the lazy use of byte strings, especially since Python 3 sneaks Unicode
>>> to the outer interfaces of the program (files, IPC).
>>
>> I'm not entirely sure I understand what you mean by "lazy use of
>> Unicode strings". And I especially don't understand what you mean by
>> "sneak". The fact that strings are Unicode is *the* biggest and most
>> obvious new feature of Python 3.
> 
> I mean that sys.stdin and sys.stdout should deal with byte strings. 

There are certainly use-cases for stdin and stdout to use bytes, but 
there are also use-cases for them to deal with strings. I'll certainly 
grant you that there ought to be an easy way to get access to the binary 
streams, but I think for a high-level language like Python, the default 
should be text, not bytes.

> I mean that open(path) should open a file in binary mode. Thankfully,
> the subprocess methods exchange bytes by default.

Likewise for files: by default, I should be able to do this:

open("foo.txt", "w").write("foo bar baz")

and have something sensible happen. Although I'm open to the suggestion 
that maybe the Pythonic way to do that should be:

print("foo bar baz", file="foo.txt")


Most programming languages I know of default to opening files in text 
mode, not binary mode, and I don't see any strong reason for Python to go 
against the tide there.

And I don't have an opinion on the subprocess module.


> To me, the main difference between Python 2 and Python 3 is that in the
> former, I use "..." everywhere, and in the latter, I use b"..."
> everywhere. If I should need advanced text processing features, I'll go
> through a decode() and encode().

Having len('λ') == 1 is not an advanced text processing feature.


[...]
>> As of right now, *new* projects ought to be written in Python 3.3 or
>> better, unless you have a compelling reason not to. You don't have to
>> port old projects in order to take advantage of Python 3 for new
>> projects.
> 
> But my distro only provides Python 3.2. What's wrong with Python 3.2?
> Why didn't anybody tell me to put off the migration?

Nothing is "wrong" with Python 3.2, except in the sense that it's now 
about 3 years old there are better versions (3.3 and 3.4) to choose from. 
If you're wedded to the idea of only using the version of Python that 
your distro supports, you may find yourself a version or four behind the 
latest release. (Red Hat only recently stopped supporting a distro where 
the system python was 2.3. Yay.)


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

Re: Python 3 is killing Python

[Mark Lawrence]

On 16/07/2014 00:53, Rick Johnson wrote:

Another thing that irritates is those people who insist on shouting LIKE 
THIS throughout their posts.


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Python 3 is killing Python

[Chris Angelico]

On Wed, Jul 16, 2014 at 5:49 PM, Steven D'Aprano  wrote:
> ... Although I'm open to the suggestion
> that maybe the Pythonic way to do that should be:
>
> print("foo bar baz", file="foo.txt")
>

And I would argue against that suggestion, having worked with a
language where that's the case. In REXX, you write to files using the
LINEOUT and CHAROUT functions (the former adds end-of-line after its
written content, the latter doesn't):

call lineout "foo.txt","foo bar baz"
/* or */
call charout "foo.txt","foo bar "
call lineout "foo.txt","baz"

And correspondingly, CHARIN and LINEIN to read from files. This is
nice and convenient, but it has a number of problems:

1) Hidden global state. Somewhere there's a mapping of file names to
open file handles, and it's not obvious.
2) Corollary: Surprising behaviour if you try to use a file twice in
one program.
3) Closing a file is sometimes unobvious. If you terminate the program
with open files, there's no problem, but if the program keeps running,
its files stay open.
4) Very VERY occasionally, you might run into a problem with too many
open files. (It should be noted that I learned REXX back in the 90s.
It's entirely possible that "too many open files" would be at some
insanely ridiculous number now.) At that point, you need to close
something... but how can you know?

Here's a REXX-style set of functions, implemented in Python:

# files.py
_filemap = {}
def _open(fn, mode): _filemap[fn] = open(fn, mode)

def charout(fn, s):
if fn not in _filemap: _open(fn, "w")
_filemap[fn].write(s)

def lineout(fn, s): charout(fn, s+"\n")

def charin(fn, n=1):
if fn not in _filemap: _open(fn, "r")
return _filemap[fn].read(n)

# Okay, the stream() function does a *lot* more than
# closing files, but that's all I'm implementing.
def stream(fn, *args):
if args != ["c","close"]: raise NotImplemented
del _filemap[fn]



That's more-or-less how REXX does things. There are a lot more
complications (I didn't implement LINEIN, which requires buffering -
more global state), but that's the basic layout. Now, that's already
scaring you a bit (all that global state!), but it gets worse: you
either have heaps of duplication all through your code (repeating the
file name in every output statement), or you have a variable with the
file name that functions as a cookie - it's the same as a file handle
integer, or a FILE *fp with the C stdio library, or a file object in
Python, or anything like that. Usage would be like this:

fn = "foo.txt"
print("foo bar baz", file=fn)
print("hello, world", file=fn)
close_file(fn)

Which has no significant improvement over the current:

f = open("foo.txt", "w")
print("foo bar baz", file=f)
print("hello, world", file=f)
f.close()

And it's worse, because if you put this into a function and return
early from it, the second form will garbage-collect f and close the
file, but the first form won't. That's a recipe for surprises down the
track.

There is a use-case where this is an improvement: you can have a
function that writes to a log file or something, and it doesn't need
to monitor state:

def some_func(...)
do_stuff()
if condition: print(some_state, file="some.log")
do_more_stuff()

With Python's normal style, this would need to either keep on opening
and closing the file (slow and inefficient), or keep track of an open
file object somewhere (global state). If you're going to have global
state anyway, then it's easier to push it to someone else. But I'd
much rather NOT have that state... not to mention the potential
problems from having aliases to the file. I've never tried, for
instance, opening a file using two equivalent names, but it'd probably
open the file twice. Even more confusion.

It's great to be open to suggestions. It's great to be able to discuss
them and figure out which ones are actually worth pursuing :)

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

Re: Python 3 is killing Python

[Chris “Kwpolska” Warrick]

A little more off-topic:

On Wed, Jul 16, 2014 at 3:57 AM, MRAB  wrote:
> On 2014-07-16 00:53, Rick Johnson wrote:
>> Some folks even have software that "blabs" about how great a job it
>> is doing […], so if you see […] some pretentious line
>> about "this was sent from my i-phone" -- send that crap to the
>> bitbucket!
>>
> "This was sent from my iPhone" == "I have an iPhone!"

I personally parse those lines as “sent from my iPhone, which has an
on-screen touch keyboard, and it’s harder to type on it”.

> Also annoying is some footnote that says that the email contains
> confidential information and that if you're not the intended recipient
> you should delete it, etc.
>
> That's somewhat pointless if it's being sent to a public forum!

Corporate lawyers for the win!  99.9% of people who send e-mail with
this line are forced to do so by their corporation’s legal department.

Also, the correct solution for all those is getting a sane client that
can hide quotes and signatures.  Like Gmail (which defaults to
top-posting, but fixing this is one click per message away*).  And if
someone brings the “people need to download it anyway” argument: it’s
2014, people: hard-drives are large nowadays (or you can just use
IMAP) and if you’re paying $100 per kilobyte, you’re doing it wrong
and should not be online in the first place.

* trickier on mobile, though.

-- 
Chris “Kwpolska” Warrick 
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Marko Rauhamaa]

Steven D'Aprano :

> Likewise for files: by default, I should be able to do this:
>
> open("foo.txt", "w").write("foo bar baz")
>
> and have something sensible happen.

I'd prefer:

   open("foo.txt", "wt").write("foo bar baz")

or:

   open("foo.txt", "w", encoding="utf-8").write("foo bar baz")

or:

   open("foo.txt", "w").write("foo bar baz".encode())

Python 3 really is on a mission to elevate text into the mainstream at
the expense of bytes. I'm guessing this is done primarily to promote the
cross-platform transparency of Python code.

For me, a linux system and network programmer, that layer of frosting
only gets in my way and I need to wash it off.

> Most programming languages I know of default to opening files in text
> mode, not binary mode, and I don't see any strong reason for Python to
> go against the tide there.

In unix and linux, there never was a separate text mode for files. When
you open a file, you open a file -- and stuff bytes in it. There is no
commonly accepted text file encoding. UTF-8 comes close to being a
standard, but I know somebody who sticks to an ISO-8859-1 locale.

> Having len('λ') == 1 is not an advanced text processing feature.

There are (relative rare) occasions where you'd like to treat text as
text. Then, it's nice to be able to move the data on the operating table
with .decode() and when the patient has been sewn back together, you can
release them with .encode().

More often, len(b'λ') is what I want.


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

Re: Python 3 is killing Python

[Steven D'Aprano]

On Wed, 16 Jul 2014 18:44:38 +1000, Chris Angelico wrote:

> On Wed, Jul 16, 2014 at 5:49 PM, Steven D'Aprano 
> wrote:
>> ... Although I'm open to the suggestion that maybe the Pythonic way to
>> do that should be:
>>
>> print("foo bar baz", file="foo.txt")
>>
>>
> And I would argue against that suggestion, having worked with a language
> where that's the case.
[...]

> 1) Hidden global state. Somewhere there's a mapping of file names to
> open file handles, and it's not obvious. 

Absolutely not! What do you take me for, the designer of REXX???

:-P

What I had in mind was for print to open the file in append mode, write, 
then close the file. Something like this:


def print(*values, sep=' ', end='\n', file=sys.stdout, flush=False):
def write(f):
for value in values:
f.write(str(value) + sep)
f.write(end)
if flush:
f.flush()
if isinstance(file, (str, bytes)):
with open(file, 'a') as f:
write(f)
else:
write(f)



The downside of this is that it doesn't handle encodings and error 
handlers, or any of the other, more obscure, arguments to open(). But 
since print is intended as a convenience function, I'm okay with that. If 
you need more than the default settings, you should open the file 
yourself:

f = open('something.txt', 'w', encoding='UTF=32')
print("fe fi fo fum", file=f)


> 2) Corollary: Surprising
> behaviour if you try to use a file twice in one program.

Not with my idea. The only surprises are if you try to use it with the 
filename from different threads, but that's a relatively advanced thing 
to do. If you're using print from two threads at once, don't pass a file 
name.


> 3) Closing a file is sometimes unobvious. If you terminate the program
> with open files, there's no problem, but if the program keeps running,
> its files stay open.
> 4) Very VERY occasionally, you might run into a problem with too many
> open files. (It should be noted that I learned REXX back in the 90s.
> It's entirely possible that "too many open files" would be at some
> insanely ridiculous number now.) At that point, you need to close
> something... but how can you know?

Neither of these will be a problem.

Well, technically, if you opened like a million threads, and had every 
thread try to print to a different file name at the same time, that could 
be a problem. But if you're doing that, you deserve whatever happens.

;-)



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

Re: Python 3 is killing Python

[Chris Angelico]

On Wed, Jul 16, 2014 at 9:35 PM, Steven D'Aprano
 wrote:
> What I had in mind was for print to open the file in append mode, write,
> then close the file.

Ahh, okay. Very different from what I thought you were talking about,
and distinctly different in behaviour from REXX :)

In that case, it avoids the problems that I described, at the expense
of being potentially an attractive nuisance - imagine code like this:

for line in open("input.txt"):
print(transform(line), file="output.txt")

Looks like a really nice clean way to process a file, right? But it's
going to be horrendously slow.

Actually, this could be quite reasonably added as a feature of
print(). Could be monkey-patched in fairly easily

_origprint = print
def print(*a, **kw):
if isinstance(kw.get("file"), (str, bytes)):
with open(kw["file"], 'a') as f:
kw["file"] = f
_origprint(*a, **kw)
else:
_origprint(*a, **kw)

And it'd have its uses. The only risk would be if there's a file-like
object that's a subclass of either str or bytes, which admittedly *is*
theoretically possible...

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

Re: Python 3 is killing Python

[Steven D'Aprano]

On Wed, 16 Jul 2014 13:46:45 +0300, Marko Rauhamaa wrote:

> Python 3 really is on a mission to elevate text into the mainstream at
> the expense of bytes. I'm guessing this is done primarily to promote the
> cross-platform transparency of Python code.

Ahead of bytes? Possibly. At the expense of bytes? Certainly not. If 
there is anything that you cannot conveniently do with bytes, that you 
could do in Python 2, it's likely a bug, or at least an obviously missing 
feature. The core devs recognise that they missed some use-cases (e.g. 
mixed bytes and text) which is now harder than it should be, and are on a 
mission to rectify that as much as possible within the constraints of 
backward compatibility.

E.g. having b"abc"[0] return 97 instead of b"a" was probably a mistake, 
but there are four versions of Python 3.x that do it that way and it's 
too late to change until Python 5000. (Python 4 is unlikely to break 
backwards compatibility in a big way.)


> For me, a linux system and network programmer, that layer of frosting
> only gets in my way and I need to wash it off.

Linux, like all Unixes, is primarily a text-based platform. With a few 
exceptions, /etc is filled with text files, not binary files, and half 
the executables on the system are text (Python, Perl, bash, sh, awk, 
etc.). 

www.catb.org/esr/writings/taoup/html/ch05s01.html

To say that *dealing with text* gets in your way on a Linux system is 
rather like saying that you love Mac OS X except for its gosh-awful GUI 
and APIs.

Of course, as a network programmer, you have to deal with bytes, so I'll 
give you a bit of leeway.


>> Most programming languages I know of default to opening files in text
>> mode, not binary mode, and I don't see any strong reason for Python to
>> go against the tide there.
> 
> In unix and linux, there never was a separate text mode for files. When
> you open a file, you open a file -- and stuff bytes in it. There is no
> commonly accepted text file encoding. UTF-8 comes close to being a
> standard, but I know somebody who sticks to an ISO-8859-1 locale.

And they should be dragged out into the street and beaten with a Clue 
Stick. They're the sort of people who are holding us back from the 
shining utopia of UTF-8 everywhere!

(only half joking)

But seriously, I cannot imagine any *rational* reason for using a legacy 
encoding, but I'm willing to give this person the benefit of the doubt 
that he's not a raving lunatic or old West European-centric curmudgeon 
trying to deny the existence of the rest of the world.

http://i.imgur.com/UeZan.jpg

That being the case, then good luck to him. As far as everyone else:

http://www.utf8everywhere.org/


>> Having len('λ') == 1 is not an advanced text processing feature.
> 
> There are (relative rare) occasions where you'd like to treat text as
> text.

o_O

Relatively rare. Like, um, email, news, html, Unix config files, Windows 
ini files, source code in just about every language ever, SMSes, XML, 
JSON, YAML, instant messenger apps, word processors... even *graphic* 
applications invariably have a text tool. Now, it may be true that some 
of those things may not use text under the hood, but even so, text is 
ubiquitous.

Even binary protocols often include chunks of recognisable human-readable 
text in them:

[steve@ando Pictures]$ hexdump -n 64 -C picture.jpg
  ff d8 ff e0 00 10 4a 46  49 46 00 01 01 00 00 01  |..JFIF..|
0010  00 01 00 00 ff e2 0f 38  49 43 43 5f 50 52 4f 46  |...8ICC_PROF|
0020  49 4c 45 00 01 01 00 00  0f 28 61 70 70 6c 02 10  |ILE..(appl..|
0030  00 00 6d 6e 74 72 52 47  42 20 58 59 5a 20 07 de  |..mntrRGB XYZ ..|
0040


> Then, it's nice to be able to move the data on the operating table
> with .decode() and when the patient has been sewn back together, you can
> release them with .encode().
> 
> More often, len(b'λ') is what I want.

Oh really? Are you sure? What exactly is b'λ'?

I couldn't have made up a better example of the confusion between bytes 
and text if I had tried. Thank you.



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

Re: Python 3 is killing Python

[Chris Angelico]

On Wed, Jul 16, 2014 at 10:10 PM, Steven D'Aprano
 wrote:
> Linux, like all Unixes, is primarily a text-based platform. With a few
> exceptions, /etc is filled with text files, not binary files, and half
> the executables on the system are text (Python, Perl, bash, sh, awk,
> etc.).

An interesting assertion. I know "half" is not meant to be an actual
estimate, but out of curiosity, I whipped up a quick script to figure
out just how many of my executables are text and how many aren't.

#!/usr/bin/env python3
import os, subprocess
text = binary = unknown = unreadable = 0
for path in os.environ["PATH"].split(":"):
for file in os.listdir(path):
fn = os.path.join(path, file)
try:
t = subprocess.check_output(["file", "-L", fn])
except subprocess.CalledProcessError:
print("Unreadable: %s" % fn)
unreadable += 1
continue
if isinstance(t, bytes): t = t.decode("ascii")
# Now to try to figure out what's text and what's binary.
if "text" in t:
# Most Unixes follow the convention of having "text" in
# the output of all files that can be safely blatted to
# a terminal - for instance, "ASCII text executable" is
# used to describe most shell scripts etc; this file is
# a "Python script, ASCII text executable". If I put in
# a non-ASCII char, the 'file' descr becomes changes to
# "Python script, UTF-8 Unicode text executable".
text += 1
elif "directory" in t:
# Ignore directories.
pass
elif "LSB executable" in t or "LSB shared object" in t:
binary += 1
else:
print(t.strip())
unknown += 1
print("%d text, %d binary" % (text, binary))
if unknown: print("Also %d unknowns, which are probably binary." % unknown)
if unreadable: print("Plus %d files that couldn't be read." % unreadable)


On my system, it says:
rosuav@sikorsky:~$ python3 exectypes.py
/usr/local/bin/youtube-dl: data
Unreadable: /usr/bin/wine-safe
/usr/bin/mptopdf: LaTeX auxiliary file,
/usr/bin/gvfs-less: Palm OS dynamic library data "#!/bin/sh"
Unreadable: /usr/bin/gserialver
1140 text, 2060 binary
Also 3 unknowns, which are probably binary.
Plus 2 files that couldn't be read.

So a bit more than a third of my executables are text. That's a pretty
high proportion, and not very far off the rough guesstimate of half.
(And I tried this on three other Linuxes I have around the house,
getting broadly the same proportion, although the numbers are quite
different.)

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

Re: Python 3 is killing Python

[Marko Rauhamaa]

Steven D'Aprano :

> With a few exceptions, /etc is filled with text files, not binary
> files, and half the executables on the system are text (Python, Perl,
> bash, sh, awk, etc.).

Our debate seems to stem from a different idea of what text is. To me,
text in the Python sense is a sequence of UCS-4 character code points.
The opposite of text is not necessarily binary.

Most of those "text" files under /etc expect ASCII. In many contexts,
they tolerate UTF-8 or Latin-3 or whatever, but it's a bit iffy (how are
extra-ASCII passwords encoded in the /etc/shadow?). Also, the files
under /etc, /var/log etc should not depend on the locale since they are
typically interpreted by daemons, which typically don't possess locales.

> Relatively rare. Like, um, email, news, html, Unix config files,
> Windows ini files, source code in just about every language ever,
> SMSes, XML, JSON, YAML, instant messenger apps,

I would be especially wary of letting Python 3 interpret those files for
me. Python's [text] strings could be a wonderful tool on the inside of
my program, but I definitely would like to micromanage the I/O. Do I
obey the locale or not? That's too big (and painful) a question for
Python to answer on its own (and pretend like everything's under
control).

> word processors... even *graphic* applications invariably have a text
> tool.

Thing is, the serious text utilities like word processors probably need
lots of ancillary information so Python's [text] strings might be too
naive to represent even a single character.

>> More often, len(b'λ') is what I want.
>
> Oh really? Are you sure? What exactly is b'λ'?

That's something that ought to work in the UTF-8 paradise.
Unfortunately, Python only allows ASCII in bytes. ASCII only! In this
day and age! Even C is not so picky:

   #include 

   int main()
   {
   printf("Hyvää yötä\n");
   return 0;
   }


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

how to msi install Python to non-default target dir?

[Albert-Jan Roskam]

hi,

I am trying to create a .bat file where (among other things) Python will have 
to be silently installed.
It needs to be installed to the non-default location "c:\program 
files\python27". Any idea how this can be done? 
I keep getting the 'Help' menu, indicating that something went wrong. I've been 
fighting with this for like an hour now! :-(

I followed this structure [1]: msiexec /i (yourFile).msi 
TARGETDIR=C:\YourBin\YourApp

The following does NOT work (I added the cd/md commands later, idem for the /qb)

y:\>set PYTHONDIR="c:\program files\python27"
y:\>cd /d "c:\program files"
y:\>md python27
y:\>cd /d %temp%
y:\>msiexec /i python-2.7.3 TARGETDIR="%PYTHONDIR%" /qb

Thank you!

Regards,

Albert-Jan

[1] 
http://stackoverflow.com/questions/3259737/command-line-option-to-tell-msi-installation-to-a-specific-location
 
[2] Platform: Windows 7 Enterprise, it that matters.



~~

All right, but apart from the sanitation, the medicine, education, wine, public 
order, irrigation, roads, a 

fresh water system, and public health, what have the Romans ever done for us?

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

Re: how to msi install Python to non-default target dir?

[Zachary Ware]

On Wed, Jul 16, 2014 at 8:29 AM, Albert-Jan Roskam
 wrote:
> hi,
>
> I am trying to create a .bat file where (among other things) Python will have 
> to be silently installed.
> It needs to be installed to the non-default location "c:\program 
> files\python27". Any idea how this can be done?
> I keep getting the 'Help' menu, indicating that something went wrong. I've 
> been fighting with this for like an hour now! :-(
>
> I followed this structure [1]: msiexec /i (yourFile).msi 
> TARGETDIR=C:\YourBin\YourApp
>
> The following does NOT work (I added the cd/md commands later, idem for the 
> /qb)
>
> y:\>set PYTHONDIR="c:\program files\python27"
> y:\>cd /d "c:\program files"
> y:\>md python27
> y:\>cd /d %temp%
> y:\>msiexec /i python-2.7.3 TARGETDIR="%PYTHONDIR%" /qb

I'm assuming this is retyped and you missed the '.msi' in retyping?
If not, that may be your issue.  Also, 'set' doesn't require quotes
around a value with spaces, and you're also quoting %PYTHONDIR% when
you use it in the msiexec command, so you're actually double-quoting
the dir name (which could also be the issue).  And, not necessarily an
issue that would prevent installing, but you may want to make sure
you're in the correctly-bitted Program Files directory if you're on
64-bit Windows (%PROGRAMFILES% for 64-bit, %PROGRAMFILES(x86)% for
32-bit; %PROGRAMFILES(x86)% will not be defined on 32-bit Windows or
in a 32-bit process on 64-bit Windows).

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

Re: Python 3 is killing Python

[Grant Edwards]

On 2014-07-16, Dennis Lee Bieber  wrote:
> On Tue, 15 Jul 2014 20:43:03 -0400, Kevin Walzer 
> declaimed the following:
>
>>On 7/15/14, 6:38 PM, Mark Lawrence wrote:
>>>I did see your correction but it gave me an opportunity to mention
>>> google groups, something that just can't be missed
>>
>>If the newgroup had a filter to trim out complaints about Google groups, 
>>half the traffic would be gone. :-)
>
>   That would tend to imply that if it had a filter to trim out posts
> /from/ GoogleGroups there would be no traffic left 

No need.  My slrn configuration does filter out posts from google
groups. So, all I see are the complaints about posts from google
groups -- I haven't figured out how to plonk those...

-- 
Grant Edwards   grant.b.edwardsYow! Th' MIND is the Pizza
  at   Palace of th' SOUL
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Chris Angelico]

On Wed, Jul 16, 2014 at 11:11 PM, Marko Rauhamaa  wrote:
> Steven D'Aprano :
>
>> With a few exceptions, /etc is filled with text files, not binary
>> files, and half the executables on the system are text (Python, Perl,
>> bash, sh, awk, etc.).
>
> Our debate seems to stem from a different idea of what text is. To me,
> text in the Python sense is a sequence of UCS-4 character code points.
> The opposite of text is not necessarily binary.

Let's shift things a moment for an analogy. What is audio? What is
sound? (Music, if you like, but I'm not going to get into the debate
of whether or not Band So-and-so's output should be called music.) I
have a variety of files that store music; some are RIFF WAVs, some are
MPEG level 3s, some are Ogg Vorbis files, and right now I have an MKV
of "Do you wanna build a snowman?" playing. (As far as I'm concerned,
it's primarily there for music, and the video image is buried behind
other windows. But I'll accept the argument that that's just a
container for some other format of audio, probably MPEG but I haven't
checked.) Sound, fundamentally, is a waveform, or a series of air
pressures.

Text, similarly, is not UCS-4, but a series of characters. We are
fortunate enough to have Unicode and can therefore define that text is
a sequence of Unicode codepoints, but the distinction isn't a feature
of Unicode; if you ask a primary school child to identify the letters
in a word, s/he should be able to do so, and that without any computer
involvement at all. Letters, digits, and other characters exist
independently of encodings or even character sets, but it's really
REALLY hard for computers to manipulate what they can't identify. So
let's define Unicode text as "a sequence of Unicode codepoints" or "a
sequence of Unicode characters", and proceed from there.

A file on a Unix or Windows file system consists of a sequence of
bytes. Ergo, a file cannot actually contain text; it must store
*encoded* text. But this is far and away the most common type of file
on any file system. Tweaking the previous script to os.walk() my home
directory, rather than scanning $PATH, the ratios are roughly 2:1 the
other way - heaps more text files than binary. And this is with my
Downloads/ directory being almost entirely binaries, and lots of them;
various zip files, deb packages, executables of various types... about
the only actual text there would be .patch files.

>> Relatively rare. Like, um, email, news, html, Unix config files,
>> Windows ini files, source code in just about every language ever,
>> SMSes, XML, JSON, YAML, instant messenger apps,
>
> I would be especially wary of letting Python 3 interpret those files for
> me. Python's [text] strings could be a wonderful tool on the inside of
> my program, but I definitely would like to micromanage the I/O. Do I
> obey the locale or not? That's too big (and painful) a question for
> Python to answer on its own (and pretend like everything's under
> control).

That's a problem that will be solved progressively, by daemons
shifting to UTF-8 for everything. But until then, you have to treat
log files as "messy" - you can't trust to a simple encoding. But
that's unusual compared to the common case. If you're reading your own
config files, you can simply stipulate that they are to be encoded
UTF-8, and if they're not, you throw an error. Simple! Works with the
easy way of opening files in Python. If you're reading someone else's
config files, you can either figure out what that program is
documented as expecting (and error out if the file's misencoded), or
treat it as messy and read it as binary.

>> word processors... even *graphic* applications invariably have a text
>> tool.
>
> Thing is, the serious text utilities like word processors probably need
> lots of ancillary information so Python's [text] strings might be too
> naive to represent even a single character.

Ancillary information? (La)TeX files are entirely text, and have all
that info in them somewhere. Open Documents are basically zip files of
XML data, where XML is ... all text. Granted, it's barely-readable
text, but it is UTF-8 encoded text. (I just checked an odt file that I
have sitting here, and it does contain a thumbnail in PNG format. But
the primary content is all XML files.)

>>> More often, len(b'λ') is what I want.
>>
>> Oh really? Are you sure? What exactly is b'λ'?
>
> That's something that ought to work in the UTF-8 paradise.
> Unfortunately, Python only allows ASCII in bytes. ASCII only! In this
> day and age! Even C is not so picky:
>
>#include 
>
>int main()
>{
>printf("Hyvää yötä\n");
>return 0;
>}

And I have a program that lets me store 1.75 in an integer variable!
That's ever so much better than most programs. It's so much less
picky!

 Actually, Python allows all bytes in a bytestring, not just ASCII.
However, b'λ' has no meaning; in fact, even b'asdf' is dubious, and
this kind of notation exists only because there are many file f

Re: Python 3 is killing Python

[Frank Millman]

"Marko Rauhamaa"  wrote in message 
news:87egxl4zq8@elektro.pacujo.net...
> Steven D'Aprano :
>
>> On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote:
>>> In fact, I find the lazy use of Unicode strings at least as scary as
>>> the lazy use of byte strings, especially since Python 3 sneaks
>>> Unicode to the outer interfaces of the program (files, IPC).
>>
>> I'm not entirely sure I understand what you mean by "lazy use of
>> Unicode strings". And I especially don't understand what you mean by
>> "sneak". The fact that strings are Unicode is *the* biggest and most
>> obvious new feature of Python 3.
>
> I mean that sys.stdin and sys.stdout should deal with byte strings. I
> mean that open(path) should open a file in binary mode. Thankfully, the
> subprocess methods exchange bytes by default.
>
> To me, the main difference between Python 2 and Python 3 is that in the
> former, I use "..." everywhere, and in the latter, I use b"..."
> everywhere. If I should need advanced text processing features, I'll go
> through a decode() and encode().
>
>> The Python devs aren't slaves, they get to choose what features they
>> work on and which they don't. They don't owe *anybody* any feature
>> they don't want to build, or care to support, and that includes
>> continuing the 2.x series.
>
> No need to erect straw men. Of course, the Python gods do whatever they
> want. And you asked me to clarify my opinion, which I did. The breakage
> of backward compatibility wasn't worth the new features.
>
> But as I said, what is done is done. We'll live with the reality.
>

This sub-thread is the most constructive one I have seen yet that deals with 
the 'problems' that Python3 has created, and how to deal with them.

I take my hat off to Marko for his approach - it has affected him adversely, 
but it has not prevented him from continuing to develop using Python3.

FWIW, here are my thoughts -

1. There were many backward-incompatible changes made in Python3, but the 
only one that seems to cause problems is the change to the bytes/str types. 
I agree that it is a big change, but the others seem to have been accepted 
without argument, so it seems to me that the python devs got an awful lot 
right.

2. Those adversely affected by the change are very vocal, but we hear very 
little from those who have benefited from it. This is to be expected - they 
are just getting on with developing in Python3 and have no need to get 
involved in controversies.

I just tried an experiment in my own project. Ned Batchelder, in his 
Pragmatic Unicode presentation, http://nedbatchelder.com/text/unipain.html, 
suggests that you always have some unicode characters in your data, just to 
ensure that they are handled correctly. He has a tongue-in-cheek example 
which spells the word PYTHON using various exotic unicode characters. I used 
this to populate a field in my database, to see if it would display in my 
browser-based client.

The hardest part was getting it in. There are 6 characters, but utf-8 
requires 16 bytes to store it -


b'\xe2\x84\x99\xc6\xb4\xe2\x98\x82\xe2\x84\x8c\xc3\xb8\xe1\xbc\xa4'.decode('utf-8')

However, that was it. Without any changes to my program, it read it from the 
database and displayed it on the screen. IE8 could only display 2 out of the 
6 characters correctly, and Chrome could display 5 out of 6, but that is a 
separate issue. Python3 handled it perfectly.

Would this have been so easy using Python2 - I don't think so. What follows 
is blatant speculation, but it is quite possible that there are many 
non-English speakers out there that have had their lives made much easier by 
the changes to Python3  - a 'silent majority'? I don't mean an absolute 
majority, as I believe there are still more Python2 users than Python3. But 
of those who have made the switch from 2 to 3, maybe most of them are quite 
happy. If so, then the python devs got that right as well.

Unfortunately, human nature being what it is, the possibility of this split 
in the community continuing, to the detriment of Python itself, is all too 
real. I don't know what more the python devs can do, but there are no 
guarantees of success :-(

Frank Millman



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

Re: how to msi install Python to non-default target dir?

[Albert-Jan Roskam]

 
- Original Message -
> From: Zachary Ware 
> To: Albert-Jan Roskam 
> Cc: Python 
> Sent: Wednesday, July 16, 2014 3:47 PM
> Subject: Re: how to msi install Python to non-default target dir?
> 
> On Wed, Jul 16, 2014 at 8:29 AM, Albert-Jan Roskam
> 
>  wrote:
>>  hi,
>> 
>>  I am trying to create a .bat file where (among other things) Python will 
> have to be silently installed.
>>  It needs to be installed to the non-default location "c:\program 
> files\python27". Any idea how this can be done?
>>  I keep getting the 'Help' menu, indicating that something went 
> wrong. I've been fighting with this for like an hour now! :-(
>> 
>>  I followed this structure [1]: msiexec /i (yourFile).msi 
> TARGETDIR=C:\YourBin\YourApp
>> 
>>  The following does NOT work (I added the cd/md commands later, idem for the 
> /qb)
>> 
>>  y:\>set PYTHONDIR="c:\program files\python27"
>>  y:\>cd /d "c:\program files"
>>  y:\>md python27
>>  y:\>cd /d %temp%
>>  y:\>msiexec /i python-2.7.3 TARGETDIR="%PYTHONDIR%" /qb
> 
> I'm assuming this is retyped and you missed the '.msi' in retyping?

Yes, typo, sorry. I was working in an environment without email access.

> If not, that may be your issue.  Also, 'set' doesn't require quotes
> around a value with spaces, and you're also quoting %PYTHONDIR% when
> you use it in the msiexec command, so you're actually double-quoting
> the dir name (which could also be the issue).  

That was it, thank you!!

>And, not necessarily an
> issue that would prevent installing, but you may want to make sure
> you're in the correctly-bitted Program Files directory if you're on
> 64-bit Windows (%PROGRAMFILES% for 64-bit, %PROGRAMFILES(x86)% for
> 32-bit; %PROGRAMFILES(x86)% will not be defined on 32-bit Windows or
> in a 32-bit process on 64-bit Windows).

Good point. The easiest solution would be to write one .bat for 32bit and one 
for 64bit.

Thanks again!!  
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Marko Rauhamaa]

Chris Angelico :

> On Wed, Jul 16, 2014 at 11:11 PM, Marko Rauhamaa  wrote:
>> I would be especially wary of letting Python 3 interpret those files for
>> me. [...]
>
> If you're reading your own config files, you can simply stipulate that
> they are to be encoded UTF-8, and if they're not, you throw an error.
> Simple! Works with the easy way of opening files in Python.

That's my point! It does not work.

   $ python3 -c "
   > import sys
   > sys.stdout.write(sys.stdin.read())" <<<"Hyvää yötä"
   Hyvää yötä
   $ LANG=en_US.ASCII python3 -c "
   > import sys
   > sys.stdout.write(sys.stdin.read())" <<<"Hyvää yötä"
   Traceback (most recent call last):
 File "", line 3, in 
 File "/usr/lib/python3.2/encodings/ascii.py", line 26, in decode
   return codecs.ascii_decode(input, self.errors)[0]
   UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3\
   : ordinal not in range(128)

In other words, the well-meaning Python3 blindly obeys the locale even
though I "simply stipulated" that my input is UTF-8.

>> Thing is, the serious text utilities like word processors probably
>> need lots of ancillary information so Python's [text] strings might
>> be too naive to represent even a single character.
>
> Ancillary information? (La)TeX files are entirely text,

I mean on the inside. For example, if emacs were to be written in
Python3, I don't know if it could use Python3's strings.

   Each character position in a buffer or a string can have a text property
   list, much like the property list of a symbol (see Property Lists). The
   properties belong to a particular character at a particular place, such
   as, the letter ‘T’ at the beginning of this sentence or the first ‘o’ in
   ‘foo’—if the same character occurs in two different places, the two
   occurrences in general have different properties. http://www.gnu.org/software/emacs/manual/html_node/elisp/Text-Prope
   rties.html>.

> What is C actually storing in that string? Do you know? Can you be
> truly sure that it's UTF-8? No, you cannot.

I happen to know it does. And again, I may "stipulate" it to use your
word.

Python, happily, is even more explicit about it:

   #!/usr/bin/env python3
   # -*- coding: utf-8 -*-


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

Re: Python 3 is killing Python

[Chris Angelico]

On Thu, Jul 17, 2014 at 12:27 AM, Frank Millman  wrote:
> FWIW, here are my thoughts -
>
> 1. There were many backward-incompatible changes made in Python3, but the
> only one that seems to cause problems is the change to the bytes/str types.
> I agree that it is a big change, but the others seem to have been accepted
> without argument, so it seems to me that the python devs got an awful lot
> right.

There are quite a few changes that are almost completely
insignificant, like renaming (eg Tkinter to tkinter), where there's
this tiny difference at the top of your program and absolutely no
difference elsewhere. And there are a few where, for instance,
FileNotFoundError was created, as a subclass of OSError; I have a
program that needs to catch that exception, and I just have a trap at
the top that, if there's no FNFE, assigns it equal to OSError, and
then proceeds as normal. (This does mean that, under Python 2, the
mini HTTP server returns 404s for other types of OSError attempting to
read from certain files; under Python 3, those will result in 500s and
logged errors. I'm not overly concerned about that difference, but I
prefer the Py3 behaviour.) These sorts of changes, while technically
backward-incompatible, aren't going to cause argument - you just zip
through your code and change stuff (probably with a script like 2to3),
or else add a bit of header to ensure compatibility with both
versions. Pretty easy.

Then there are the changes that, while again technically
backward-incompatible, are practically identical *in normal usage*.
For instance, range no longer returns a list, but most range usage is
with iteration anyway. Dict views rather than lists might cause some
problems (if you iterate over d.keys() while mutating d, you'll have
problems in Py3, but in Py2 it's fine), but again, any place where you
have issues, you just tweak it to the new recommended style. Several
of these changes are actually less significant than one change that
happened within the 2.x line - the change from string exceptions to
subclasses of (Base)Exception. There have been a few complaints, but
they're not the stuff about which people say "Python 3 is killing
Python".

> 2. Those adversely affected by the change are very vocal, but we hear very
> little from those who have benefited from it. This is to be expected - they
> are just getting on with developing in Python3 and have no need to get
> involved in controversies.

That's very true. Sometimes you get an idea of how silent something is
and therefore how successful; for example, my house has been
progressively migrated almost exclusively to Linux, and the days that
go by without anyone asking me for help are proof that Linux is a
perfectly acceptable desktop OS. (Actually, even when people _do_ ask
me for help, it's usually either something to do with git, or
something advanced like "How can I find out which files in this whole
directory tree have been changed recently?", which your average user
wouldn't know off-hand how to do on Windows or OS/2 either.) Python 3
has served many people just fine, and those people aren't writing blog
posts about how unexciting their lives have become now that they don't
have to deal with bug reports about stuff the language just does for
them.

> I just tried an experiment in my own project. Ned Batchelder, in his
> Pragmatic Unicode presentation, http://nedbatchelder.com/text/unipain.html,
> suggests that you always have some unicode characters in your data, just to
> ensure that they are handled correctly. He has a tongue-in-cheek example
> which spells the word PYTHON using various exotic unicode characters. I used
> this to populate a field in my database, to see if it would display in my
> browser-based client.
>
> The hardest part was getting it in. There are 6 characters, but utf-8
> requires 16 bytes to store it -
>
> 
> b'\xe2\x84\x99\xc6\xb4\xe2\x98\x82\xe2\x84\x8c\xc3\xb8\xe1\xbc\xa4'.decode('utf-8')
>

Ideally, you would have a browser-based input system as well, which
would allow you to do the whole thing directly. Also, I would strongly
recommend using a database back-end that stores Unicode; and if that
back-end is MySQL, be aware that "utf8" is actually a messed-up
encoding that's like UTF-8 only restricted to three bytes (and
therefore the BMP), and you have to use "utf8mb4" to store all of
Unicode. With a decent back-end like PostgreSQL, you can do this sort
of thing directly:

rosuav=> create table test (id serial primary key,txt text);
CREATE TABLE
rosuav=> insert into test (txt) values ('U+1234 is ሴ');
INSERT 0 1
rosuav=> insert into test (txt) values ('U+12345 is 𒍅');
INSERT 0 1
rosuav=> select id,txt,length(txt) from test;
 id | txt  | length
+--+
  1 | U+1234 is ሴ  | 11
  2 | U+12345 is 𒍅 | 12
(2 rows)

Looks fine to me. You should be able to read and write Unicode from Python, too.

> However, that was it. Without any changes to my program, it read it from the
> datab

Re: Python 3 is killing Python

[Chris Angelico]

On Thu, Jul 17, 2014 at 12:39 AM, Marko Rauhamaa  wrote:
> In other words, the well-meaning Python3 blindly obeys the locale even
> though I "simply stipulated" that my input is UTF-8.

Except that you didn't - that input was not UTF-8. When you put a text
string as redirected input and then change LANG, you're lying to the
system, and you deserve all you get. Why are you even doing this,
other than to be able to point and laugh at programs that do the wrong
thing - when you've instructed them wrongly?

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

Re: Python 3 is killing Python

[Neil D. Cerutti]

On 7/16/2014 10:27 AM, Frank Millman wrote:

Would this have been so easy using Python2 - I don't think so. What follows
is blatant speculation, but it is quite possible that there are many
non-English speakers out there that have had their lives made much easier by
the changes to Python3  - a 'silent majority'? I don't mean an absolute
majority, as I believe there are still more Python2 users than Python3. But
of those who have made the switch from 2 to 3, maybe most of them are quite
happy. If so, then the python devs got that right as well.


Python3 has helped me cope with unexpected non-ASCII characters in other 
systems on our university campus while using a program written back 
before I knew anything about unicode.


When I first spotted mojibake appearing in a student's name and address, 
it was only a couple of emails and a little investigation to determine 
which encoding= bits to sprinkle into my program. And I was finished.


I wrote these applications a decade ago in Python2, and never worried 
about unicode. I translated them to Python3 years ago, and still never 
worried about unicode. The database is supposed to be sanitized against 
non-ASCII by an address and name-scrubbing application, which we aspend 
large amounts of cash on (I don't understand why, but that's what we do).


And thanks to Python3, even though "illegal" characters have crept in, 
and even though I had never worried about unicode before, I could fix my 
program(s) the instant I knew which encodings to use. It would have been 
much harder to get right using Python2.

--
Neil Cerutti


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

Re: Python 3 is killing Python

[Marko Rauhamaa]

Chris Angelico :

> On Thu, Jul 17, 2014 at 12:39 AM, Marko Rauhamaa  wrote:
>> In other words, the well-meaning Python3 blindly obeys the locale even
>> though I "simply stipulated" that my input is UTF-8.
>
> Except that you didn't - that input was not UTF-8. When you put a text
> string as redirected input and then change LANG, you're lying to the
> system, and you deserve all you get. Why are you even doing this,
> other than to be able to point and laugh at programs that do the wrong
> thing - when you've instructed them wrongly?

The example was artificial to make it small enough. The point is,
though, that it is dangerous to assume that the file formats agree with
the locale.


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

Re: Python 3 is killing Python

[Chris Angelico]

On Thu, Jul 17, 2014 at 1:48 AM, Marko Rauhamaa  wrote:
> it is dangerous to assume that the file formats agree with
> the locale.

Of course. You never assume anything about encodings. What you do is
expect something about the encoding, and either throw an error if it's
wrong, or figure out some other encoding to use. With anything that
you broadly control (eg if your program is configured by a file in
/etc that nothing else uses), you just decode with whatever you
document your program as using, and any failure is *not your problem*.
It's that simple. You don't replace /etc/passwd with a JPEG encoded
photograph of your family tree and expect all your family to be able
to log in; no more should you expect a file to be parsed correctly if
it's meant to be UTF-8 and you save it in ISO-8859-4. The two cases
are equally ridiculous.

The only thing that might be an issue is that you can't use open(fn)
to read your files, but you have to explicitly state the encoding.
That would be an understandable problem, especially for someone who
develops on a single platform and forgets that the default differs. As
long as you always explicitly say encoding="utf-8", and document that
you do so, any problems are someone else's.

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

Re: how to msi install Python to non-default target dir?

[Chris Angelico]

On Wed, Jul 16, 2014 at 11:29 PM, Albert-Jan Roskam
 wrote:
> It needs to be installed to the non-default location "c:\program 
> files\python27".

Why must it? Are you aware that many programs have issues with spaces
in file names? That's one reason for Python's default installation
location NOT being in the stupidly-named Program Files. Putting Python
there may cause trouble with, for instance, binary extensions.

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

Re: how to msi install Python to non-default target dir?

[Marko Rauhamaa]

Chris Angelico :

> Why must it? Are you aware that many programs have issues with spaces
> in file names? That's one reason for Python's default installation
> location NOT being in the stupidly-named Program Files. Putting Python
> there may cause trouble with, for instance, binary extensions.

One of Python's advantages over, say, bash is that it can handle spaces
and other funny characters in pathnames.


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

Re: Python 3 is killing Python

[Marko Rauhamaa]

Chris Angelico :

> The only thing that might be an issue is that you can't use open(fn)
> to read your files, but you have to explicitly state the encoding.
> That would be an understandable problem, especially for someone who
> develops on a single platform and forgets that the default differs. As
> long as you always explicitly say encoding="utf-8", and document that
> you do so, any problems are someone else's.

Yes. I don't like open() guessing the enconding:

   The default encoding is platform dependent (whatever
   locale.getpreferredencoding() returns)

Also, I don't like sys.std* guessing the encoding:

   Under other platforms, the locale encoding is used (see
   locale.getpreferredencoding()).

In each case, it would have been better to default to bytes just like
subprocess does.


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

Re: how to msi install Python to non-default target dir?

[Chris Angelico]

On Thu, Jul 17, 2014 at 2:22 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> Why must it? Are you aware that many programs have issues with spaces
>> in file names? That's one reason for Python's default installation
>> location NOT being in the stupidly-named Program Files. Putting Python
>> there may cause trouble with, for instance, binary extensions.
>
> One of Python's advantages over, say, bash is that it can handle spaces
> and other funny characters in pathnames.

Both Python and bash can handle spaces just fine. It's applications
that have trouble.

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

Re: how to msi install Python to non-default target dir?

[Zachary Ware]

On Wed, Jul 16, 2014 at 9:33 AM, Albert-Jan Roskam  wrote:
> From: Zachary Ware 
>> Also, 'set' doesn't require quotes
>> around a value with spaces, and you're also quoting %PYTHONDIR% when
>> you use it in the msiexec command, so you're actually double-quoting
>> the dir name (which could also be the issue).
>
> That was it, thank you!!

Glad I could help :)

>> And, not necessarily an
>> issue that would prevent installing, but you may want to make sure
>> you're in the correctly-bitted Program Files directory if you're on
>> 64-bit Windows (%PROGRAMFILES% for 64-bit, %PROGRAMFILES(x86)% for
>> 32-bit; %PROGRAMFILES(x86)% will not be defined on 32-bit Windows or
>> in a 32-bit process on 64-bit Windows).
>
> Good point. The easiest solution would be to write one .bat for 32bit and one 
> for 64bit.

You could also do something like (untested, but I've used similar in
the Doc/make.bat script):

   if DEFINED ProgramFiles(x86) set 64bitext=.amd64
   set PYTHONDIR=%ProgramFiles%\Python27
   set PYTHONMSI=python-2.7.3%64bitext%.msi
   msiexec /i %PYTHONMSI% TARGETDIR="%PYTHONDIR%" /qb

That's for 64-bit Python on 64-bit Windows, 32-bit Python on 32-bit
Windows.  Or:

   if DEFINED ProgramFiles(x86) set PgrmFls=%ProgramFiles(x86)%
   if NOT DEFINED ProgramFiles(x86) set PgrmFls=%ProgramFiles%
   set PYTHONDIR=%PgrmFls%\Python27
   msiexec /i python-2.7.3.msi TARGETDIR="%PYTHONDIR%" /qb

for 32-bit Python on either platform.

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

This Python 3 is killing Python thread is killing me.

[Deb Wyatt]

Can you all stop already with the non python US bashing?  Please?

Deb in WA, USA


Protect your computer files with professional cloud backup.
Get PCRx Backup and upload unlimited files automatically. 
Learn more at http://backup.pcrx.com/mail


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

Re: Python 3 is killing Python

[Javier]

> I don't see anyone taking the Python 2 source code and backporting a
> bunch of Python 3 features (and/or adding a bunch of their own
> features) and creating the Python 2.8 that
> http://blog.startifact.com/guido_no.jpg rejects. What split is
> actually occurring, or going to occur? I think anyone who talks of
> splitting has an unrealistically low idea of the costs of such a
> split; moving away from what the core Python devs are doing means
> setting up everything fresh, and it's just way too much work to do
> that.

Up to now there have been no attemps of forking because python2.x was
still being developed and they even ported some of the features of
python3 to 2.6/2.7.

I think there has been a severe miscalculation, and the change in the
name of the interpreter python3 to python
http://legacy.python.org/dev/peps/pep-0394/ is a good example of the
disconnection between GvR and the real world.

Arch Linux was the only distro to fall in the trap, and those who use
it (as myself) need to put fake executables in /usr/local/bin
for everything: (python, sphinx, virtualenv...) selecting 2 or 3

http://sindhus.bitbucket.org/manage-python-2-3.html

Things are a bit more complex than just changing '#!/usr/bin/env python'
to '#!/usr/bin/env python2'

Let's see what it happens now that no more features are added to 2.x.
2.8 fork anybody?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Mark Lawrence]

On 16/07/2014 15:27, Frank Millman wrote:


This sub-thread is the most constructive one I have seen yet that deals with
the 'problems' that Python3 has created, and how to deal with them.



How many of the Python3 'problems' were backported to 2.7 or even 2.6?

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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: This Python 3 is killing Python thread is killing me.

[Abhiram R]

On Wed, Jul 16, 2014 at 11:02 PM, Deb Wyatt  wrote:

> Can you all stop already with the non python US bashing?  Please?
>
> Deb in WA, USA
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


​I'm actually picking up a lot of snippets of information from that thread
by being a spectator :) ​But that's just me.

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

Re: Python 3 is killing Python

[Ian Kelly]

On Wed, Jul 16, 2014 at 11:33 AM, Javier  wrote:
> I think there has been a severe miscalculation, and the change in the
> name of the interpreter python3 to python
> http://legacy.python.org/dev/peps/pep-0394/ is a good example of the
> disconnection between GvR and the real world.

Er, that PEP currently recommends that python be a symlink to python2.
It states that at some point in the future, the recommendation will
change to have python symlink to python3.

> Arch Linux was the only distro to fall in the trap

You've got the order of events backward.  That PEP was created
*because* Arch decided to link python to python3.  Neither GvR nor
anybody else who work on Python have any control over that.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: This Python 3 is killing Python thread is killing me.

[alister]

On Wed, 16 Jul 2014 09:32:31 -0800, Deb Wyatt wrote:

> Can you all stop already with the non python US bashing?  Please?
> 
> Deb in WA, USA
> 
>  Protect
> your computer files with professional cloud backup.
> Get PCRx Backup and upload unlimited files automatically.
> Learn more at http://backup.pcrx.com/mail

Sorry Deb
I was not bashing the USA as such...
It was all meant to be taken in good humour. I have had a number of 
enjoyable holidays in the USA and 90% of the people I have met there have 
been great.


-- 
Q:  What's hard going in and soft and sticky coming out?
A:  Chewing gum.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: This Python 3 is killing Python thread is killing me.

[Ian Kelly]

On Wed, Jul 16, 2014 at 11:32 AM, Deb Wyatt  wrote:
> Can you all stop already with the non python US bashing?  Please?

I read it more as counter-US-glorification-trolling than bashing, but
in any case that subthread seems to have died down already, so you
should be safe to start reading again if you want.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: This Python 3 is killing Python thread is killing me.

[Mark Lawrence]

On 16/07/2014 18:32, Deb Wyatt wrote:

Can you all stop already with the non python US bashing?  Please?

Deb in WA, USA



rr started it with a fairly impressive piece of trolling but as you've 
asked so politely I will happily oblige.


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: This Python 3 is killing Python thread is killing me.

[Jason Swails]

On Wed, Jul 16, 2014 at 11:40 AM, Mark Lawrence 
wrote:

> On 16/07/2014 18:32, Deb Wyatt wrote:
>
>> Can you all stop already with the non python US bashing?  Please?
>>
>> Deb in WA, USA
>>
>>
> rr started it with a fairly impressive piece of trolling but as you've
> asked so politely I will happily oblige.


​I honestly don't understand why you haven't kill-filed him yet.  I can
understand people wanting to respond to jmf to prevent newbies and the
Unicode-ignorant from thinking the FSR is not a good thing (or
fundamentally wrong), although I've killfiled him as well. [1] But nobody
will confuse rr's posts with something of value (their only possible use
can be to populate http://en.wikipedia.org/wiki/List_of_logical_fallacies
and http://en.wikipedia.org/wiki/Ad_hominem).  There's nobody to protect
from rr-induced misconceptions. [http://xkcd.com/386/]

My life lurking and learning on Python-list has been dramatically improved
since I began to instantiate filters, I highly recommend it.

Cheers,
Jason

[1] Seen one and you've seen them all, and I'm no unicode expert.
-- 
https://mail.python.org/mailman/listinfo/python-list

Oxycontin no prescription overnight cod delivery , cheap Oxycontin cash on delivery

[numansenm]

Buy Oxycontin online, Really amazing prices and Free bonuses!

Oxycontin BEST SITES FOUND!
Just FOLLOW url below!

**

>>> http://drugeasy.biz/?q=Oxycontin <<< - CLICK HERE!

**

Full information about usage, dosage, Buy online, discounts and more other! 


http://drugeasy.biz/?q=Oxycontin
http://drugeasy.biz/?q=Buy+online+Oxycontin
http://drugeasy.biz/?q=Buy+order+Oxycontin
http://drugeasy.biz/?q=Buy+Oxycontin
http://drugeasy.biz/?q=Buy+cheap+Oxycontin
http://drugeasy.biz/?q=Order+Oxycontin
http://drugeasy.biz/?q=Online+Oxycontin

* Special Internet Prices (up to 40% off average US price)
* Best quality drugs
* NO PRIOR PRESCRIPTION NEEDED!
* 100% Anonimity & Discreet shipping
* Fast FREE shipping (4 to 7 days)
* Loyalty program
* Friendly customer support
* 4 Free Oxycontin/Oxycontin pills with every Order 



cheap online pharmacy Oxycontin
Oxycontin online saturday delivery
online Oxycontin and fedex
cheap order prescription Oxycontin
cheap Oxycontin by money order
buy Oxycontin from mexico online
Oxycontin no prescription usa fedex shipping
overnight delivery Oxycontin
buy Oxycontin online without a prescription and no membership
buy Oxycontin paypal online without prescription
Oxycontin order a prepaid mastercard
no prescription needed Oxycontin
cod shipped Oxycontin
not expensive order prescription Oxycontin
Oxycontin money order
Oxycontin without a perscription
online buy Oxycontin
Oxycontin fedex
buy no online prescription Oxycontin
Oxycontin pharmacies accepting cod delivery
Oxycontin online consultant
online pharmacy fedex cod Oxycontin
buy Oxycontin no scams
Oxycontin c.o.d overnight delivery
buy Oxycontin no prescription cod
overnight Oxycontin order
Oxycontin online doctors
buy Oxycontin on line no prescription
Oxycontin no prescription usa fedex shipping
Oxycontin online uk
watson brand Oxycontin
medicine online Oxycontin
order Oxycontin samples sent
buy Oxycontin no prescription
order Oxycontin without a prescription
Oxycontin no prescription drug
cheap online order Oxycontin
get Oxycontin over the counter online
order Oxycontin next day
buy Oxycontin no perscription cod
real Oxycontin fed ex
Oxycontin no prescription cod
does cv/ pharmacy carry Oxycontin
no prescription cod Oxycontin
cheap Oxycontin without rx
Oxycontin online health insurance lead
buy Oxycontin online with overnight delivery
Oxycontin no rx fed ex
buy Oxycontin without a perscription
lowest prices for Oxycontin online
buy Oxycontin paypal online without prescription
cheap non prescription Oxycontin
Oxycontin ups
Oxycontin for cheap
buy Oxycontin no visa online without prescription
cheapest Oxycontin cash on delivery
Oxycontin order a prepaid mastercard
buy online Oxycontin
purchase Oxycontin mail order
Oxycontin without a prescription online with overnight delivery
Oxycontin from canada
buy Oxycontin with no rx
overnight delivery of Oxycontin with no prescription
cash on delivery Oxycontin no rx
Oxycontin by cod
buy Oxycontin over the counter cod overnight
overnight Oxycontin
order Oxycontin without prescription from us pharmacy
cheap Oxycontin free fedex shipping
order Oxycontin over the counter
where to buy Oxycontin no prescription no fees
only Oxycontin free consult
cod delivery Oxycontin
Oxycontin no prescription
Oxycontin online overnight delivery cod
order Oxycontin over the counter fedex
Oxycontin saturday delivery
buy Oxycontin money order
Oxycontin without prescription mexico
buy cheap Oxycontin without prescription
Oxycontin non prescription for next day delivery
Oxycontin ups delivery only
buy Oxycontin usa cod
Oxycontin with next day delivery
no prescriptions needed for Oxycontin
cheap Oxycontin overnight
prescription Oxycontin
cheap Oxycontin overnight delivery
Oxycontin non prescription fedex overnight free
order Oxycontin no creditcard
buy cheap Oxycontin no Prescription
buy Oxycontin over the counter fedex
Oxycontin no doctor presribe needed
cheap watson Oxycontin online
cheap discount Oxycontin
buy Oxycontin without a prescription online
cheapest Oxycontin free delivery
buy Oxycontin online overseas
buy Oxycontin over the counter online
not expensive Oxycontin next day shipping
order Oxycontin cod next day deliv

Tramadol online saturday delivery , cheap online pharmacy Tramadol

[Sedab Bunay]

Buy Tramadol online, Really amazing prices and Free bonuses!

Tramadol BEST SITES FOUND!
Just FOLLOW url below!

**

>>> http://drugeasy.biz/?q=Tramadol <<< - CLICK HERE!

**

Full information about usage, dosage, Buy online, discounts and more other! 


http://drugeasy.biz/?q=Tramadol
http://drugeasy.biz/?q=Buy+online+Tramadol
http://drugeasy.biz/?q=Buy+order+Tramadol
http://drugeasy.biz/?q=Buy+Tramadol
http://drugeasy.biz/?q=Buy+cheap+Tramadol
http://drugeasy.biz/?q=Order+Tramadol
http://drugeasy.biz/?q=Online+Tramadol

* Special Internet Prices (up to 40% off average US price)
* Best quality drugs
* NO PRIOR PRESCRIPTION NEEDED!
* 100% Anonimity & Discreet shipping
* Fast FREE shipping (4 to 7 days)
* Loyalty program
* Friendly customer support
* 4 Free Tramadol/Tramadol pills with every Order 



cheap online pharmacy Tramadol
Tramadol online saturday delivery
online Tramadol and fedex
cheap order prescription Tramadol
cheap Tramadol by money order
buy Tramadol from mexico online
Tramadol no prescription usa fedex shipping
overnight delivery Tramadol
buy Tramadol online without a prescription and no membership
buy Tramadol paypal online without prescription
Tramadol order a prepaid mastercard
no prescription needed Tramadol
cod shipped Tramadol
not expensive order prescription Tramadol
Tramadol money order
Tramadol without a perscription
online buy Tramadol
Tramadol fedex
buy no online prescription Tramadol
Tramadol pharmacies accepting cod delivery
Tramadol online consultant
online pharmacy fedex cod Tramadol
buy Tramadol no scams
Tramadol c.o.d overnight delivery
buy Tramadol no prescription cod
overnight Tramadol order
Tramadol online doctors
buy Tramadol on line no prescription
Tramadol no prescription usa fedex shipping
Tramadol online uk
watson brand Tramadol
medicine online Tramadol
order Tramadol samples sent
buy Tramadol no prescription
order Tramadol without a prescription
Tramadol no prescription drug
cheap online order Tramadol
get Tramadol over the counter online
order Tramadol next day
buy Tramadol no perscription cod
real Tramadol fed ex
Tramadol no prescription cod
does cv/ pharmacy carry Tramadol
no prescription cod Tramadol
cheap Tramadol without rx
Tramadol online health insurance lead
buy Tramadol online with overnight delivery
Tramadol no rx fed ex
buy Tramadol without a perscription
lowest prices for Tramadol online
buy Tramadol paypal online without prescription
cheap non prescription Tramadol
Tramadol ups
Tramadol for cheap
buy Tramadol no visa online without prescription
cheapest Tramadol cash on delivery
Tramadol order a prepaid mastercard
buy online Tramadol
purchase Tramadol mail order
Tramadol without a prescription online with overnight delivery
Tramadol from canada
buy Tramadol with no rx
overnight delivery of Tramadol with no prescription
cash on delivery Tramadol no rx
Tramadol by cod
buy Tramadol over the counter cod overnight
overnight Tramadol
order Tramadol without prescription from us pharmacy
cheap Tramadol free fedex shipping
order Tramadol over the counter
where to buy Tramadol no prescription no fees
only Tramadol free consult
cod delivery Tramadol
Tramadol no prescription
Tramadol online overnight delivery cod
order Tramadol over the counter fedex
Tramadol saturday delivery
buy Tramadol money order
Tramadol without prescription mexico
buy cheap Tramadol without prescription
Tramadol non prescription for next day delivery
Tramadol ups delivery only
buy Tramadol usa cod
Tramadol with next day delivery
no prescriptions needed for Tramadol
cheap Tramadol overnight
prescription Tramadol
cheap Tramadol overnight delivery
Tramadol non prescription fedex overnight free
order Tramadol no creditcard
buy cheap Tramadol no Prescription
buy Tramadol over the counter fedex
Tramadol no doctor presribe needed
cheap watson Tramadol online
cheap discount Tramadol
buy Tramadol without a prescription online
cheapest Tramadol free delivery
buy Tramadol online overseas
buy Tramadol over the counter online
not expensive Tramadol next day shipping
order Tramadol cod next day delivery
Tramadol cheap
Tramadol buy in UK
Tramadol next day cod fedex
Tramadol to buy

Re: This Python 3 is killing Python thread is killing me.

[Mark Lawrence]

On 16/07/2014 20:24, Jason Swails wrote:


On Wed, Jul 16, 2014 at 11:40 AM, Mark Lawrence mailto:breamore...@yahoo.co.uk>> wrote:

On 16/07/2014 18:32, Deb Wyatt wrote:

Can you all stop already with the non python US bashing?  Please?

Deb in WA, USA


rr started it with a fairly impressive piece of trolling but as
you've asked so politely I will happily oblige.

​I honestly don't understand why you haven't kill-filed him yet.  I can
understand people wanting to respond to jmf to prevent newbies and the
Unicode-ignorant from thinking the FSR is not a good thing (or
fundamentally wrong), although I've killfiled him as well. [1] But
nobody will confuse rr's posts with something of value (their only
possible use can be to populate
http://en.wikipedia.org/wiki/List_of_logical_fallacies and
http://en.wikipedia.org/wiki/Ad_hominem).  There's nobody to protect
from rr-induced misconceptions. [http://xkcd.com/386/]

My life lurking and learning on Python-list has been dramatically
improved since I began to instantiate filters, I highly recommend it.

Cheers,
Jason

[1] Seen one and you've seen them all, and I'm no unicode expert.



The difference between our most illustrious resident unicode expert and 
rr is that the former has only said anything of use once, whereas the 
latter does know about tkinter/IDLE.  rr doesn't show up that often, the 
MIRUC has been spewing his mistruths for nearly two years and IMHO 
should have been booted into touch a long time ago.


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: This Python 3 is killing Python thread is killing me.

[Skip Montanaro]

On Wed, Jul 16, 2014 at 3:27 PM, Mark Lawrence  wrote:
> The difference between our most illustrious resident unicode expert and rr

Sorry, who is "rr"? I went looking in the referenced thread but found
nobody with those initials. Not so helpfully, Gmail elides most sigs,
so I couldn't reliably scan the full text either.

Thx,

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

Re: Python 3 is killing Python

[Terry Reedy]

On 7/16/2014 3:49 AM, Steven D'Aprano wrote:


There are certainly use-cases for stdin and stdout to use bytes, but
there are also use-cases for them to deal with strings. I'll certainly
grant you that there ought to be an easy way to get access to the binary
streams,


As has been discussed before on this list, there is in 3.x.
https://docs.python.org/3/library/sys.html#sys.stdin

>>> b=sys.stdin.buffer.readline()
a line
>>> b
b'a line\r\n'

In other words, 3.x text mode (which essentially nothing to do with 2.x 
'text' mode), is a wrapped binary mode that gives users the *choice* to 
read bytes or text.


--
Terry Jan Reedy

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

Re: This Python 3 is killing Python thread is killing me.

[MRAB]

On 2014-07-16 21:40, Skip Montanaro wrote:

On Wed, Jul 16, 2014 at 3:27 PM, Mark Lawrence  wrote:

The difference between our most illustrious resident unicode expert and rr


Sorry, who is "rr"? I went looking in the referenced thread but found
nobody with those initials. Not so helpfully, Gmail elides most sigs,
so I couldn't reliably scan the full text either.


"rr" is "rantingrickjohnson@...".

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

Re: This Python 3 is killing Python thread is killing me.

[Ethan Furman]

On 07/16/2014 02:32 PM, MRAB wrote:

On 2014-07-16 21:40, Skip Montanaro wrote:


Sorry, who is "rr"? I went looking in the referenced thread but found
nobody with those initials. Not so helpfully, Gmail elides most sigs,
so I couldn't reliably scan the full text either.


"rr" is "rantingrickjohnson@...".


As someone just recently said, "The clue is in the name."  ;)

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

Re: Python 3 is killing Python

[Rick Johnson]

On Wednesday, July 16, 2014 9:27:56 AM UTC-5, Frank Millman wrote:

> 2. Those adversely affected by the change are very vocal,
> but we hear very little from those who have benefited from
> it. This is to be expected - they are just getting on with
> developing in Python3 and have no need to get involved in
> controversies.

And those that "vote with their feet" are not vocal either.

Now, you might think: 

"Why do i *I* care if people start using other languages?", 

Well, if you enjoy writing Python code, and understand (like
i do) that Python is truly valuable to the programming
community, then you should also understand that as the number
of members drop, so too does the "collective intelligence"
of the community. 

Not to mention that at some point, when the numbers get low
*enough*, maintaining a project as big as Python becomes
untenable.

Of course, no community or project can expect expansion of
members "forever", but the last thing you want is people
running away from your project. At a minimum, you want to
maintain a reasonable "average" of community members.

I personally know of few major software developers, who
whilst "shopping" for a scripting language for their API,
wanted to integrate Python because of it's clean syntax and
auto-encapsulation, but they where forced to choose *another*
language because of all the headaches that backwards
incompatibility of Python 3000 would induce in the users of
the API.



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

Re: Python 3 is killing Python

[Terry Reedy]

On 7/16/2014 5:02 PM, Terry Reedy wrote:

On 7/16/2014 3:49 AM, Steven D'Aprano wrote:


There are certainly use-cases for stdin and stdout to use bytes, but
there are also use-cases for them to deal with strings. I'll certainly
grant you that there ought to be an easy way to get access to the binary
streams,


As has been discussed before on this list, there is in 3.x.
https://docs.python.org/3/library/sys.html#sys.stdin

 >>> b=sys.stdin.buffer.readline()
a line
 >>> b
b'a line\r\n'

In other words, 3.x text mode (which essentially nothing to do with 2.x
'text' mode), is a wrapped binary mode that gives users the *choice* to
read bytes or text.


One can also convert a stream permanently with .detach()
>>> import sys
>>> sys.stdin = sys.stdin.detach()
>>> b = sys.stdin.readline()
a line
>>> b
b'a line\r\n'

This does diable the input() function ;-).
>>> b = input()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: '_io.BufferedReader' object has no attribute 'errors'

--
Terry Jan Reedy

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

Re: Python 3 is killing Python

[Mark Lawrence]

On 16/07/2014 23:41, Rick Johnson wrote:


Not to mention that at some point, when the numbers get low
*enough*, maintaining a project as big as Python becomes
untenable.



I'm not aware of any mass exodus from core Python 3 to the fork that has 
consistently proposed to give the world Python 2.8.  Do you know 
something that I don't?


Further the number of people assisting on the bug tracker at the moment 
appears to me to be going up, not down.  It therefore strikes me that 
Python is extremely tenable, thus indicating that people are not falling 
for the FUD about Python 2 versus Python 3.


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


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

Re: Anything better than asyncio.as_completed() and asyncio.wait() to manage execution of large amount of tasks?

[Maxime Steisel]

2014-07-15 14:20 GMT+02:00 Valery Khamenya :
> Hi,
>
> both asyncio.as_completed() and asyncio.wait() work with lists only. No
> generators are accepted. Are there anything similar to those functions that
> pulls Tasks/Futures/coroutines one-by-one and processes them in a limited
> task pool?


Something like this (adapted from as_completed) should do the work:

import asyncio
from concurrent import futures

def parallelize(tasks, *, loop=None, max_workers=5, timeout=None):
loop = loop if loop is not None else asyncio.get_event_loop()
workers = []
pending = set()
done = asyncio.Queue(maxsize=max_workers)
exhausted = False

@asyncio.coroutine
def _worker():
nonlocal exhausted
while not exhausted:
try:
t = next(tasks)
pending.add(t)
yield from t
yield from done.put(t)
pending.remove(t)
except StopIteration:
exhausted = True

def _on_timeout():
for f in workers:
f.cancel()
workers.clear()
#Wake up _wait_for_one()
done.put_nowait(None)

@asyncio.coroutine
def _wait_for_one():
f = yield from done.get()
if f is None:
raise futures.TimeoutError()
return f.result()

workers = [asyncio.async(_worker()) for i in range(max_workers)]

if workers and timeout is not None:
timeout_handle = loop.call_later(timeout, _on_timeout)

while not exhausted or pending or not done.empty():
yield _wait_for_one()

timeout_handle.cancel()
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Rick Johnson]

On Wednesday, July 16, 2014 6:00:16 PM UTC-5, Mark Lawrence wrote:
> I'm not aware of any mass exodus from core Python 3 to the
> fork that has consistently proposed to give the world
> Python 2.8.  Do you know something that I don't?

Well, currently at least, we don't even *need* a Python 2.8,
not for the next couple of years anyway.

But i think that when the time arrives, the "someone", or
"some entity" will inevitably decide that, whilst Python2.x
was the best high level language available to date, it has
many flaws that cannot be worked around "cleanly", so
instead of continuing on with Python "as-is", we should take
all the good ideas of Python, plus all the good ideas of
Ruby, plus few good ideas in Perl, Javascript, etc... and
create a *whole* new language that will supersede them all.

BECAUSE REMEMBER, EVOLUTION IS A GOOD THING!

This is what i wished the Python dev *would* have devoted
their energies to, not the abortion of "Python3" we have
today. Look, i don't mean to dismiss all the difficult work
invoked in creating Python3, but i just cannot support
something that is a lackluster improvement at best. If we're
going to break Python, let's do it "correctly".

You see, people just hate updating code for what is
basically the same language. HOWEVER, if you give them a
*new* language, that is an "intelligent evolution" of the
old language, then they will be *EXCITED* to write code
again.

> Further the number of people assisting on the bug tracker
> at the moment appears to me to be going up, not down.  It
> therefore strikes me that Python is extremely tenable,
> thus indicating that people are not falling for the FUD
> about Python 2 versus Python 3.

Again, your "metrics", are tainted. I believe the spike in
bug reports has less to do with:

"New community members jumping in to help"

And more to do with:

"Damn, this Python3 is buggy and i need to tell someone
so i can get my customers off my back and this egg off
my face, lest my feet move faster than Fred Flintstone!"

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

Re: This Python 3 is killing Python thread is killing me.

[Jason Swails]

On Wed, Jul 16, 2014 at 1:27 PM, Mark Lawrence 
wrote:

>
> The difference between our most illustrious resident unicode expert and rr
> is that the former has only said anything of use once, whereas the latter
> does know about tkinter/IDLE.  rr doesn't show up that often, the MIRUC has
> been spewing his mistruths for nearly two years and IMHO should have been
> booted into touch a long time ago.


"Know about" is awfully vague.  Start with 5 things:

1) A browser opened to effbot
2) An open python interpreter
3) A willingness to build widgets and widget collections as Frame subclasses
4) A willingness to fingerpaint with Canvas objects to create custom widgets
5) A useful(ish) program to write

Within a couple hours I learned everything I later saw in all of rr's
Tkinter posts, albeit without the irrelevant condescension. (I've written 3
Tkinter-based GUIs, all simple... I'm no expert with it.)

But that's quite beside the point.  When rr says something 'useful' about
using Python, he probably doesn't need to be corrected.  When he doesn't,
it's often incoherent verbiage with big words, flashy/illogical/outrageous
comparisons, and ad hominem attacks aimed at everyone that's disagreed with
him on the interwebs.  While I occasionally found it satisfying to fire
back and bask in my own logical and moral superiority, the little corner of
my life I devote to python-list is far more peaceful and fulfilling (not to
mention productive) now.

One last opinion before I sign off on this thread, I make an active effort
to attach my name to useful contributions on the web and cut down on the
useless.  I don't want my name associated with the idea "a lot of what he
sends is useless ranting or useless retaliation thereof".  With the volume
of material available on the web, I try to be careful not to make a poor
impression with anything I author (although that is unavoidable sometimes).

All the best,
Jason

P.S. And nobody will think you're just like  if you
don't bite back in a public forum.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Steven D'Aprano]

On Wed, 16 Jul 2014 19:20:14 +0300, Marko Rauhamaa wrote:

> Chris Angelico :
> 
>> The only thing that might be an issue is that you can't use open(fn) to
>> read your files, but you have to explicitly state the encoding. That
>> would be an understandable problem, especially for someone who develops
>> on a single platform and forgets that the default differs. As long as
>> you always explicitly say encoding="utf-8", and document that you do
>> so, any problems are someone else's.
> 
> Yes. I don't like open() guessing the enconding:

It doesn't *guess*. It has a sensible default encoding which, for most 
users most of the time, does the right thing. Ultimately though, the 
encoding is under your control: you can specify it if you think you know 
better.


>The default encoding is platform dependent (whatever
>locale.getpreferredencoding() returns)

Right. Most text files will be written using the preferred encoding, 
unless the user explicitly uses something else when writing the file. In 
that case it's the user's responsibility. Or if they've got the file from 
another system with a different encoding. But even then, the most common 
encodings are ASCII-compatible, which means that the lowest common 
denominator case (reading and writing ASCII files) will Just Work.

From a purity stand-point, no, open() shouldn't have a default encoding, 
and the user should have to specify it. But what makes you imagine that 
the user will know the correct encoding better than Python does? The 
average coder[1] shouldn't have to care about encodings just to do 
file.write("Hello World"), and on the average computer they don't have to 
because Python sets a sensible default.


But you know what? From a purity stand-point, *even binary mode* assumes 
an encoding of sorts. How do you know that binary files on your platform 
use eight-bit bytes? Some DSPs use 9-bit bytes, and historically 
computers had as few as 6 or as many as 60 bits per byte. This is why the 
C standard requires that a byte is *at least* 8 bits.

But, having said that, the assumption that binary files are based on 8-
bit bytes is pretty safe. It would be foolish to force the majority of 
people, who don't need to care about these sorts of details, to care 
about them just to suit the one in ten-thousand who do.

Likewise with text files. Python makes sensible defaults which will suit 
most people, rather than force people to guess the wrong encoding. But 
it's only a default, you can explicitly set it if you believe the file in 
question uses a different encoding.


[...]
> In each case, it would have been better to default to bytes just like
> subprocess does.

Better for whom? You? Maybe. For the typical programmer that Python is 
designed for? Hell no.




[1] Lets be honest, there still is a bias towards English and ASCII in 
computing, and probably this will remain the case until English ceases to 
be a de facto lingua franca. Most programming languages are written for 
J. Random Hacker, not Jランダムハッカー.


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

Re: Python 3 is killing Python

[Steven D'Aprano]

On Wed, 16 Jul 2014 18:16:16 -0700, Rick Johnson wrote:

> On Wednesday, July 16, 2014 6:00:16 PM UTC-5, Mark Lawrence wrote:
>> I'm not aware of any mass exodus from core Python 3 to the fork that
>> has consistently proposed to give the world Python 2.8.  Do you know
>> something that I don't?
> 
> Well, currently at least, we don't even *need* a Python 2.8, not for the
> next couple of years anyway.

There will never be a Python 2.8. When push comes to shove, the people 
bitching about Python 3 will not do the work necessary to fork Python 2.7 
and make a version 2.8.



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

Re: Python 3 is killing Python

[Chris Angelico]

On Thu, Jul 17, 2014 at 12:51 PM, Steven D'Aprano  wrote:
> Most programming languages are written for
> J. Random Hacker, not Jランダムハッカー.

I had to paste that into Google Translate to be able to understand
what you meant (although I could guess just fine)... but to actually
see the characters, I had to paste it into my MUD client. Yeah. Figure
that out. A MUD client had better font support for other languages
than a web browser with a dedicated translation tool.

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

Re: Python 3 is killing Python

[Steven D'Aprano]

On Wed, 16 Jul 2014 15:41:38 -0700, Rick Johnson wrote:

> I personally know of few major software developers, who whilst
> "shopping" for a scripting language for their API, wanted to integrate
> Python because of it's clean syntax and auto-encapsulation, but they
> where forced to choose *another* language because of all the headaches
> that backwards incompatibility of Python 3000 would induce in the users
> of the API.

Oh Really?

I call bullshit. Name names. Name projects.

If they are "shopping" for a scripting language, that means they don't 
have one yet. Which means their users have no existing scripts that need 
to be ported from Python 2 to 3. Whatever language is chosen, whether it 
is Ruby, Lua, Python 3 or something else, its all equally as new.


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

Re: Python 3 is killing Python

[Chris Angelico]

On Thu, Jul 17, 2014 at 11:16 AM, Rick Johnson
 wrote:
> But i think that when the time arrives, the "someone", or
> "some entity" will inevitably decide that, whilst Python2.x
> was the best high level language available to date, it has
> many flaws that cannot be worked around "cleanly", so
> instead of continuing on with Python "as-is", we should take
> all the good ideas of Python, plus all the good ideas of
> Ruby, plus few good ideas in Perl, Javascript, etc... and
> create a *whole* new language that will supersede them all.
>
> BECAUSE REMEMBER, EVOLUTION IS A GOOD THING!

Let 'em. If you believe evolution is such a good thing, you're most
welcome to arrange it. Personally, I believe that *guided development*
is a good thing, and whaddayaknow, that's exactly what we have here
from GvR and from the python-dev team. Proper development of a large
or small project requires an intelligent person with a hand on the
tiller, not randomly undirected additions (or, perhaps not
"undirected" so much as "directed by every single whining mailing list
post" - which is the same thing, really); someone needs to decide
which ideas are good and which are bad. Undirected evolution is
destructive. Directed cultivation is constructive.

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

Re: networkx plot random graph Error

[Jason Swails]

On Jul 15, 2014, at 3:11 AM, u2107  wrote:

> I am trying to read a file with 3 columns with col 1 and 2 as nodes/edges and 
> column 3 as weight (value with decimal)
> 
> I am trying to execute this code 
> 
> 
> import networkx as nx
> 
> 
> G = nx.read_edgelist('file.txt', data=[("weight")])
> G.edges(data=True)
> 
> edge_labels = dict(((u, v), d["weight"]) for u, v, d in G.edges(data=True))
> pos = nx.random_layout(G)
> nx.draw(G, pos)
> nx.draw_networkx_edge_labels(G, pos, edge_labels=edge_labels)
> 
> import matplotlib.pyplot as plt; plt.show()
> 
> 
> 
> Error: 
> 
> File "graph_one.py", line 4, in 
>G = nx.read_edgelist('File.txt', data=[("weight")])
>  File "", line 2, in read_edgelist
>  File 
> "/usr/local/lib/python2.7/dist-packages/networkx-1.7-py2.7.egg/networkx/utils/decorators.py",
>  line 241, in _open_file
>fobj = _dispatch_dict[ext](path, mode=mode)
> IOError: [Errno 2] No such file or directory: 
> 'contactUSC_nodes_diff_small.txt'

This looks like some file didn't exist which probably should have.  The next 
line looks like you may have fixed the problem and then run the command again?  
Is this part of the error message?  Including stuff like this is confusing (to 
me, at least).

> lavanya@peerformance:~/Desktop/INRIA_Papers/Python$ python graph_one.py
> Traceback (most recent call last):
>  File "graph_one.py", line 4, in 
>G = nx.read_edgelist('contactUSC_node_diff_small.txt', data=[("weight")])
>  File "", line 2, in read_edgelist
>  File 
> "/usr/local/lib/python2.7/dist-packages/networkx-1.7-py2.7.egg/networkx/utils/decorators.py",
>  line 263, in _open_file
>result = func(*new_args, **kwargs)
>  File 
> "/usr/local/lib/python2.7/dist-packages/networkx-1.7-py2.7.egg/networkx/readwrite/edgelist.py",
>  line 367, in read_edgelist
>data=data)
>  File 
> "/usr/local/lib/python2.7/dist-packages/networkx-1.7-py2.7.egg/networkx/readwrite/edgelist.py",
>  line 286, in parse_edgelist
>for (edge_key,edge_type),edge_value in zip(data,d):
> 
> ValueError: too many values to unpack

Collections in python can be "unpacked" using a specific syntax that assigns a 
tuple of individual variables (or names) to a collection (these can be nested). 
 If there are too many or too few single names, a ValueError gets thrown.  
Consider:

py> col = [1, 2, 3]
py> a, b, c = col
py> print("{0} {1} {2}".format(a, b, c))
1 2 3
py> a, b = col
Traceback (most recent call last):
  File "", line 1, in 
ValueError: too many values to unpack
py> a, b, c, d = col
Traceback (most recent call last):
  File "", line 1, in 
ValueError: need more than 3 values to unpack

The traceback for this exception ends inside the networkx code and either 
indicates a bug in the networkx code or an input error that is not gracefully 
handled.

My suggestions are twofold:

1) Upgrade to the latest release.  If this is a bug, it's very possible that it 
was fixed in later releases (1.7 is over 2 years old and there have been a 
couple major releases since then.

2) Sign up for the networkx mailing list and ask your question there.  You are 
certain to get a faster and more relevant answer. (See the "mailing list" link 
here: http://networkx.github.io/)

Hope this helps,
Jason

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

Re: Python 3 is killing Python

[Tim Roberts]

Steven D'Aprano  wrote:
>
>For what little it is worth, if any one country won World War Two, it was 
>the USSR.

I don't think that's quite accurate.  It is certainly true that the USSR
suffered vastly more casualties than any participant in the war,
essentially losing one entire generation of young men.  It is also true
that the USSR faced the Germans head-on for longer than any other
combatant.

But it is is not at all clear that the USSR could have defeated Germany on
its own.  The enormous industrial capacity of the United States was an
extremely significant factor that helped turn the tide in what otherwise
would have been an ugly war of attrition, much like WWI.
-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Tim Roberts]

MRAB  wrote:
>On 2014-07-16 00:53, Rick Johnson wrote:
>> On Tuesday, July 15, 2014 5:40:29 PM UTC-5, Abhiram R wrote:
>>
>> ...or some pretentious line
>> about "this was sent from my i-phone" -- send that crap to the
>> bitbucket!
>>
>"This was sent from my iPhone" == "I have an iPhone!"

Please note that iPhones come configured from the factory to say that. Some
users probably don't even know it is happening.
-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Steven D'Aprano]

On Wed, 16 Jul 2014 11:50:24 -0600, Ian Kelly wrote:

> On Wed, Jul 16, 2014 at 11:33 AM, Javier  wrote:
>> I think there has been a severe miscalculation, and the change in the
>> name of the interpreter python3 to python
>> http://legacy.python.org/dev/peps/pep-0394/ is a good example of the
>> disconnection between GvR and the real world.
> 
> Er, that PEP currently recommends that python be a symlink to python2.
> It states that at some point in the future, the recommendation will
> change to have python symlink to python3.
> 
>> Arch Linux was the only distro to fall in the trap
> 
> You've got the order of events backward.  That PEP was created *because*
> Arch decided to link python to python3.  Neither GvR nor anybody else
> who work on Python have any control over that.

This is correct. When Arch first announced this change, oh, four years 
ago if I remember correctly, the core devs were rather dismayed. Some of 
them would prefer to see "python" mean "python2" forever (which I happen 
to disagree with) but even those who would like to see "python" some day 
mean "python3" thought it was *way* too early.

I think that the sensible approach is to start by migrating internal 
tools to "python2" rather than "python", then migrate internal tools to 
python3, and gradually move towards having "python" mean "the user's 
python" rather than "the system python". That will be future-proof for 
Python 4 and Python 5.



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

Re: This Python 3 is killing Python thread is killing me.

[Chris Angelico]

On Thu, Jul 17, 2014 at 6:40 AM, Skip Montanaro  wrote:
> On Wed, Jul 16, 2014 at 3:27 PM, Mark Lawrence  
> wrote:
>> The difference between our most illustrious resident unicode expert and rr
>
> Sorry, who is "rr"? I went looking in the referenced thread but found
> nobody with those initials. Not so helpfully, Gmail elides most sigs,
> so I couldn't reliably scan the full text either.
>

He used to call himself rantingr...@gmail.com and then somehow lost
access to that account (which usually means forgot the password). Now
he's "Rick Johnson"  but most of us
still refer to him as Ranting Rick.

(Apparently he was rt8...@gmail.com years ago, but that was before my time.)

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

Re: Python 3 is killing Python

[Chris Angelico]

On Thu, Jul 17, 2014 at 1:20 PM, Tim Roberts  wrote:
> MRAB  wrote:
>>On 2014-07-16 00:53, Rick Johnson wrote:
>>> On Tuesday, July 15, 2014 5:40:29 PM UTC-5, Abhiram R wrote:
>>>
>>> ...or some pretentious line
>>> about "this was sent from my i-phone" -- send that crap to the
>>> bitbucket!
>>>
>>"This was sent from my iPhone" == "I have an iPhone!"
>
> Please note that iPhones come configured from the factory to say that. Some
> users probably don't even know it is happening.

The sad thing is, it's on par with the "This email checked by the free
version of  - this message can be removed in the
registered version!" messages you sometimes see. The difference is
that with an iphone, you've already paid for it...

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

Re: initializing "parameters" class in Python only once?

[alex23]

On 15/07/2014 3:28 PM, Steven D'Aprano wrote:

# === module params.py ===
class Params(object):
 a = 1
 b = 2

 @property
 def c(self):
 return self.a**2 + self.b**2 - self.a + 1

params = Params()
del Params  # hide the class


Then callers just say:

from params import params
print params.c


I'd replace the instantiation & deletion of the class in params.py with:

import sys
sys.modules[__name__] = Params()

..and replace the module itself with the parameter object. I'd also add:

__file__ = __file__

...to the class definition to help with debugging. But this is really 
just bikeshedding.


It's a shame the property decorator doesn't work at the module level, 
though.


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

Interleaved posting style for text discussion forums (was: Python 3 is killing Python)

[Ben Finney]

Abhiram R  writes:

> ​Aah. Understood. Apologies for the "noobishness" :) ​

Thanks for understanding. Here is a good explanation of “Interleaved style”
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style>
which is the proper etiquette for text-based discussions.

-- 
 \  “I used to be an airline pilot. I got fired because I kept |
  `\   locking the keys in the plane. They caught me on an 80 foot |
_o__)stepladder with a coathanger.” —Steven Wright |
Ben Finney

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

Re: Python 3 is killing Python

[Ben Finney]

Chris “Kwpolska” Warrick  writes:

> Also, the correct solution for all those is getting a sane client that
> can hide quotes and signatures.

No, there is often useful (or at least interesting) information in a
message signature block; the problem is with *some* of them, not all of
them.

And the problem is that one message presents obnoxious crap to every
reader; suggesting that the recipient is the one responsible for
avoiding obnoxious behaviour in a public forum is a mistake of ethics.

The correct solution to obnoxious crap boilerplate in messages is for
the sender to take action to stop generating obnoxious crap boilerplate
in messages. And our job is to convince them to implement that solution.

-- 
 \   “If you define cowardice as running away at the first sign of |
  `\   danger, screaming and tripping and begging for mercy, then yes, |
_o__)   Mr. Brave man, I guess I'm a coward.” —Jack Handey |
Ben Finney

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

Re: Python 3 is killing Python

[Steven D'Aprano]

On Wed, 16 Jul 2014 17:33:44 +, Javier wrote:

> 2.8 fork anybody?

It already exists. It is called 2.7, and 2.6 before that. Python 3.0 came 
out on December 3rd, 2008, a couple of weeks before the last release of 
2.4 and in parallel with 2.5 (2.4.6 and 2.5.3 both came out on the 19th 
December). 2.6 and 2.7 are the transitional versions between 2.x and 3.x.

The core devs deliberately set out to have a long (10 years or more) 
transition period. Early adaptors can help iron out the issues with 
Python 3.0, 3.1 and 3.2, 3.3 starts going mainstream, and it won't be 
until probably 3.5 or 3.6 that Python 3 will be truly mainstream.

If you're still using Python 2.7 when Python 3.7 comes out in (likely 4 
or 5 years), you'll be in the same position as those who are still using 
Python 2.2 or 2.3 now: you'll either be happy with the status quo (and 
lack of external support) and will never change, or you've missed the 
boat.



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

Re: initializing "parameters" class in Python only once?

[Steven D'Aprano]

On Thu, 17 Jul 2014 13:35:24 +1000, alex23 wrote:

> It's a shame the property decorator doesn't work at the module level,
> though.

Not necessarily the property decorator, but some sort of computed 
variable would be nice.


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

Re: Python 3 is killing Python

[Rick Johnson]

On Wednesday, July 16, 2014 10:16:00 PM UTC-5, Steven D'Aprano wrote:
> If they are "shopping" for a scripting language, that
> means they don't have one yet. Which means their users
> have no existing scripts that need to be ported from
> Python 2 to 3. Whatever language is chosen, whether it is
> Ruby, Lua, Python 3 or something else, its all equally as
> new.

Sometimes, when we become proficient in an area of
expertise, we forget about all the stumbling blocks that
impede the neophytes -- which explains your befuddlement!

Even though i will freely admit that Python is the easiest
language to learn (IMHO), and more so because GvR did not
allow TIM-TOWDI to run rampant, Python2 already had many
stumbling blocks (new classes vs old classes crap!), but
Python3 exacerbated the problem by interjecting many, *MANY*
more stumbling blocks!

You and i don't use "print", and especially not "input" all
that much, but both of these (types of) functions are
*VITAL* lifelines for the noob when learning a language!

Not to mention the issues of looking at the wrong "version"
of a tutorial when using the "other" version of Python.
Again, you and i won't make these mistakes, but a noob will!

Look, Python has gone from: 
"A noob friendly language"

to:
"A Noobie subtle bug hell!". 

And since not all APIs are intended for "professional
programmers", choosing a language that is easy to learn, but
also, not "overly confusing" and "easy to misuse", is vital!

You cannot expect, say: "audio and video" people, to be
"professional programmers" -- who know all the "do's" and
"don'ts" of a dozen or so different languages and have
degrees in computer science and extensive knowledge of
algorithmic and logic theories!

They are just people who need to automate this or that task,
or create a functionality that does not exist via the GUI
interface, and as such, they should *NOT* need to be
burdened with the pitfalls of a backwards compatibility and
fractured community nightmare!

NO THANKS PYTHON, WE WANT OUR USERS TO BE "PRODUCTIVE"!

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

Re: Python 3 is killing Python

[Frank Millman]

"Steven D'Aprano"  wrote in message 
news:53c66ba8$0$9505$c3e8da3$54964...@news.astraweb.com...
>
> E.g. having b"abc"[0] return 97 instead of b"a" was probably a mistake,
> but there are four versions of Python 3.x that do it that way and it's
> too late to change until Python 5000. (Python 4 is unlikely to break
> backwards compatibility in a big way.)
>

If it was considered important enough, couldn't they just introduce a new 
datatype, say B'...', with the desired behaviour. B'' would be backported to 
Python 2.7 as an alternative to b'', to faciliate writing code that works on 
both versions.

There would be a lot of overlap with b'...', but the differences could be 
documented. Methods could be added to B'' to replicate any behaviour of b'' 
which has been changed. Then over time b'' could be deprecated, and in 
Python 4 b'' could replace B''.

Frank Millman



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

Re: Python 3 is killing Python

[Rick Johnson]

On Wednesday, July 16, 2014 10:18:56 PM UTC-5, Tim Roberts wrote:
> Steven D'Aprano wrote:
> >For what little it is worth, if any one country won World War Two, it was 
> >the USSR.
> I don't think that's quite accurate.  It is certainly true
> that the USSR suffered vastly more casualties than any
> participant in the war, essentially losing one entire
> generation of young men.  It is also true that the USSR
> faced the Germans head-on for longer than any other
> combatant. But it is is not at all clear that the USSR
> could have defeated Germany on its own.  The enormous
> industrial capacity of the United States was an extremely
> significant factor that helped turn the tide in what
> otherwise would have been an ugly war of attrition, much
> like WWI.

I've been wresting with my decision to "correct Steven"
every since he posted this bombastic statement of his,
because, the *real* history of WW2 tells quite a different
story than our friend Steven would like us to believe.

Heck, after suffering terrible casualties, even the "godless
tyrant" Stalin was so scared of losing the war, that he
released the priests and ministers from the gulags and
allowed the shrines to circulate around Moscow again. Ha, the
only time a godless man seeks god is on his death bed, and
Stalin was scared to death!

And then Stevens comments about how "tough" the Russian army
was because they "steamrolled" Germany and most of Europe --
obviously he has no capacity to distinguish between
"honorable warfare" and complete "barbarism".

*ANY* army can rape/kill women and children and raise peasant
villages to the ground! Look, i understand the Russians
earned some "payback", but not *all* forms of warfare can be
justified *even* after the horrendous losses they suffered!

The enemy was the third-Reich, not innocent German/Polish civilians! 

In fact, the atrocities committed by the Russians were only
eclipsed by the SS.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python 3 is killing Python

[Gregory Ewing]

Rick Johnson wrote:

*ANY* army can rape/kill women and children and raise peasant
villages to the ground!


So... the villages were underground before?

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

Re: Python 3 is killing Python

[Chris Angelico]

On Thu, Jul 17, 2014 at 3:15 PM, Rick Johnson
 wrote:
> *ANY* army can rape/kill women and children and raise peasant
> villages to the ground!

That would be "raze", unless those villages grow like potatoes.

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

Re: Python 3 is killing Python

[alex23]

On 15/07/2014 11:57 PM, Kevin Walzer wrote:

The number of language revisions that result in deliberate, code-level
incompatibility out there is pretty small. People rightly expect that
code written for version 2.x of a language will continue to work with
version 3.x, even if 3.x is designed to go in another direction.


PHP regularly breaks compatibility between _minor_ version releases:

http://php.net/manual/en/migration53.incompatible.php

Even more so with major releases:

http://php.net/manual/en/migration5.incompatible.php

And yet I never see anywhere near as much angst and agony as Python 3.x 
has caused.

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

Re: initializing "parameters" class in Python only once?

[Ethan Furman]

On 07/16/2014 08:35 PM, alex23 wrote:

On 15/07/2014 3:28 PM, Steven D'Aprano wrote:

# === module params.py ===
class Params(object):
 a = 1
 b = 2

 @property
 def c(self):
 return self.a**2 + self.b**2 - self.a + 1

params = Params()
del Params  # hide the class


Then callers just say:

from params import params
print params.c


I'd replace the instantiation & deletion of the class in params.py with:

 import sys
 sys.modules[__name__] = Params()

..and replace the module itself with the parameter object. I'd also add:

 __file__ = __file__

...to the class definition to help with debugging. But this is really just 
bikeshedding.


Just make sure the 'sys.modules' assignment happens at the *end* of params.py.

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

Re: This Python 3 is killing Python thread is killing me.

[Chris Angelico]

On Thu, Jul 17, 2014 at 4:16 AM, alister
 wrote:
> I have had a number of
> enjoyable holidays in the USA and 90% of the people I have met there have
> been great.

I'd go even further. I've only actually visited the US once, but
everyone was great except for *one* unpleasant experience with staff
at a New York railway station, and it's possible that person was just
having a bad day. Of course, it's also possible that we caught a huge
lot of really nasty people who just happened to be having a _good_ day
when we were there, but I'll be charitable and assume they're
genuinely nice people. :) Mind you, we spent most of our time in the
southern states, where people are pretty amazingly hospitable and
friendly as a rule. Actually, the hardest part of visiting the US was
learning that before crossing the road, instead of looking right and
then left, we have to look left and then right...

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

Re: Python 3 is killing Python

[Chris Angelico]

On Thu, Jul 17, 2014 at 3:36 PM, Gregory Ewing
 wrote:
> Rick Johnson wrote:
>>
>> *ANY* army can rape/kill women and children and raise peasant
>> villages to the ground!
>
>
> So... the villages were underground before?

*high five*

We had the same thought.

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

Re: Python 3 is killing Python

[Frank Millman]

"Chris Angelico"  wrote in message 
news:CAPTjJmr4nPA6euD-j2uNAN==h=ids1o5bdhgj0fnjkjo9wf...@mail.gmail.com...
> On Thu, Jul 17, 2014 at 12:27 AM, Frank Millman  
> wrote:
>
>> Unfortunately, human nature being what it is, the possibility of this 
>> split
>> in the community continuing, to the detriment of Python itself, is all 
>> too
>> real.
>
> What split, exactly? There are always these talks of a split... but I
> don't see one happening.

It is worth watching this -
https://www.youtube.com/watch?v=skYBOXE02OQ

This is the intro -

Kenneth Reitz, Python evangelist at Heroku and author of the popular 
Requests library, discusses the state of Python today, the division in the 
community, and how we can forge ahead into a shiny future. Pythonistas 
unite!


Frank



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

Re: Python 3 is killing Python

[Chris Angelico]

On Thu, Jul 17, 2014 at 4:31 PM, Frank Millman  wrote:
> It is worth watching this -
> https://www.youtube.com/watch?v=skYBOXE02OQ

Not in a position to watch Youtube vids at the moment. A blog post I'd
read, but a talk is not well suited to all forms of delivery... What's
it saying, can you summarize?

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