comp.lang.python - 26 new messages in 6 topics - digest

comp.lang.python
http://groups.google.com/group/comp.lang.python?hl=en

comp.lang.python@googlegroups.com

Today's topics:

* Trouble with UnicodeEncodeError and email - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.python/t/efbcab9b1aa89c9e?hl=en
* the Gravity of Python 2 - 13 messages, 6 authors
http://groups.google.com/group/comp.lang.python/t/0afb505736567141?hl=en
* Looking for tips for moving dev environment from Windows to Mac - 2 messages,
2 authors
http://groups.google.com/group/comp.lang.python/t/ca1bbe129ce09782?hl=en
* Editor for Python - 7 messages, 6 authors
http://groups.google.com/group/comp.lang.python/t/1d3bfdac73cdb9d2?hl=en
* Bytes indexing returns an int - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/906d7333bbd1d189?hl=en
* Suggest an open-source log analyser? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/a7adef00a9d20d74?hl=en

==============================================================================
TOPIC: Trouble with UnicodeEncodeError and email
http://groups.google.com/group/comp.lang.python/t/efbcab9b1aa89c9e?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Jan 8 2014 5:14 am
From: Florian Lindner


Hello!

I've written some tiny script using Python 3 and it used to work perfectly. Then I realized it needs to run on my Debian Stable server too, which offers only Python 2. Ok, most backporting was a matter of minutes, but I'm becoming desperate on some Unicode error...

i use scikit-learn to train a filter on a set of email messages:

vectorizer = CountVectorizer(input='filename', decode_error='replace', strip_accents='unicode',
preprocessor=self.mail_preprocessor, stop_words='english')

http://scikit-learn.org/stable/modules/generated/sklearn.feature_extraction.text.CountVectorizer.html

The vectorizer gets a list of filenames, reads them and passes them to the preprocessor:


def mail_preprocessor(self, message):
# Filter POPFile cruft by matching date string at the beginning.
print("Type:", type(message)) # imported from __future__
pop_reg = re.compile(r"^[0-9]{4}/[0-1][1-9]/[0-3]?[0-9]")
message = [line for line in message.splitlines(True) if not pop_reg.match(line)]
xxx = "".join(message)
msg = email.message_from_string(xxx) # <-- CRASH here

msg_body = ""

for part in msg.walk():
if part.get_content_type() in ["text/plain", "text/html"]:
body = part.get_payload(decode=True)
soup = BeautifulSoup(body)
msg_body += soup.get_text(" ", strip=True)


if "-----BEGIN PGP MESSAGE-----" in msg_body:
msg_body = ""

msg_body += " ".join(email.utils.parseaddr(msg["From"]))
try:
msg_body += " " + msg["Subject"]
except TypeError: # Can't convert 'NoneType' object to str implicitly
pass
msg_body = msg_body.lower()
return msg_body


Type: <type 'unicode'>

Traceback (most recent call last):
File "flofify.py", line 182, in <module>
main()
File "flofify.py", line 161, in main
model.train()
File "flofify.py", line 73, in train
vectors = vectorizer.fit_transform(data[:,1])
File "/usr/lib/python2.7/site-packages/sklearn/feature_extraction/text.py", line 780, in fit_transform
vocabulary, X = self._count_vocab(raw_documents, self.fixed_vocabulary)
File "/usr/lib/python2.7/site-packages/sklearn/feature_extraction/text.py", line 715, in _count_vocab
for feature in analyze(doc):
File "/usr/lib/python2.7/site-packages/sklearn/feature_extraction/text.py", line 229, in <lambda>
tokenize(preprocess(self.decode(doc))), stop_words)
File "flofify.py", line 119, in mail_preprocessor
msg = email.message_from_string(xxx)
File "/usr/lib/python2.7/email/__init__.py", line 57, in message_from_string
return Parser(*args, **kws).parsestr(s)
File "/usr/lib/python2.7/email/parser.py", line 82, in parsestr
return self.parse(StringIO(text), headersonly=headersonly)
UnicodeEncodeError: 'ascii' codec can't encode character u'\ufffd' in position 1624: ordinal not in range(128)

I've tried various modifications like encoding/decoding the message argument to utf-8.

Any help?

Thanks!

Florian





== 2 of 2 ==
Date: Wed, Jan 8 2014 5:26 am
From: Chris Angelico


On Thu, Jan 9, 2014 at 12:14 AM, Florian Lindner <mailinglists@xgm.de> wrote:
> I've written some tiny script using Python 3 and it used to work perfectly. Then I realized it needs to run on my Debian Stable server too, which offers only Python 2. Ok, most backporting was a matter of minutes, but I'm becoming desperate on some Unicode error...

Are you sure it does? The current Debian stable is Wheezy, which comes
with a package 'python3' in the repository, which will install 3.2.3.
(The previous Debian stable, Squeeze, has 3.1.3 under the same name.)
You may need to change your shebang, but that's all you'd need to do.
Or are you unable to install new packages? If so, I strongly recommend
getting Python 3 added, as it's going to spare you a lot of Unicode
headaches.

Mind you, I compile my own Py3 for Wheezy, since I like to be on the
bleeding edge. But that's not for everyone. :)

ChrisA





==============================================================================
TOPIC: the Gravity of Python 2
http://groups.google.com/group/comp.lang.python/t/0afb505736567141?hl=en
==============================================================================

== 1 of 13 ==
Date: Wed, Jan 8 2014 6:08 am
From: Mark Lawrence



On 08/01/2014 13:01, Steven D'Aprano wrote:
> Martijn Faassen wrote:
>
>> I also argue that for those projects to move anywhere, they need a
>> clear, blessed, official, as simple as possible, incremental upgrade
>> path. That's why I argue for a Python 2.8.
>
> That incremental upgrade path is Python 2.7.
>
> Remember, when Python 3 first came out, the current version of Python was
> 2.5. 2.6 came out roughly simultaneously with Python 3. So the expected
> upgrade path is:
>
>
> "Bleeding edge" adaptors:
> 2.5 -> 3.0
>
> Early adaptors:
> 2.5 -> 2.6 -> 3.1 or 3.2
>
> Slower adaptors:
> 2.5 -> 2.6 -> 2.7 -> 3.3 or 3.4
>
> Late adaptors:
> 2.5 -> 2.6 -> 2.7 -> 3.5 (expected to be about 18-24 months)
>
> Laggards who wait until support for 2.7 is dropped:
> 2.5 -> 2.6 -> 2.7 -> 3.6 or 3.7
>
> Adding 2.8 doesn't help. It just gives people another excuse to delay
> migrating. Then, in another two or three years, they'll demand 2.9, and put
> it off again. Then they'll insist that 15 years wasn't long enough to
> migrate their code, and demand 2.10.
>
> I have no objection to people delaying migrating. There were lots of risks
> and difficulties in migrating to 3.1 or 3.2, there are fewer risks and
> difficulties in migrating to 3.3 and 3.4, and there will be even fewer by
> the time 3.5 and 3.6 come out. People should migrate when they are
> comfortable. They may even decide to stick to 2.7 for as long as they can
> find a computer capable of running it, security updates or no security
> updates. That's all fine.
>
> What's not fine though is people holding the rest of us back with their
> negativity and FUD that Python 3 is a mistake.
>
>

Big +1 from me to all the above.

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

Mark Lawrence





== 2 of 13 ==
Date: Wed, Jan 8 2014 6:15 am
From: Roy Smith


As somebody who is still firmly in the 2.x world, I'm worried about the
idea of a 2.x fork. While I have my doubts that 3.x was a good idea,
the fact is, it's here. Having the community fractured between the two
camps is not good. Let's say I'm somebody who wants to contribute some
OSS. I have three basic choices:

1) I can make it 3.x only. Now, (nominally) half of the python
community is unable to realize value from my contribution.

2) I can make it 2.x only. Same thing in reverse.

3) I can make it work on both 2.x and 3.x, which means I'm investing
more effort than I had to if it were single platform.

Any of those alternatives is worse than ideal. Forking 2.x to create an
unofficial 2.8 release would just prolong the situation. As I've stated
before, I don't see any urgency in moving to 3.x, and don't imagine
doing there for another couple of years, but I absolutely can't imagine
moving to a 2.8 fork.




== 3 of 13 ==
Date: Wed, Jan 8 2014 6:15 am
From: Mark Lawrence



On 08/01/2014 12:36, Martijn Faassen wrote:
> Hi there,
>
> On 01/07/2014 06:00 PM, Chris Angelico wrote:
>> I'm still not sure how Python 2.8 needs to differ from 2.7. Maybe the
>> touted upgrade path is simply a Python 2.7 installer plus a few handy
>> libraries/modules that will now be preinstalled? These modules look
>> great (I can't say, as I don't have a huge Py2 codebase to judge based
>> on), and they presumably work on the existing Pythons.
>
> Well, in the original article I argue that it may be risky for the
> Python community to leave the large 2.7 projects behind because they
> tend to be the ones that pay us in the end.
>
> I also argue that for those projects to move anywhere, they need a
> clear, blessed, official, as simple as possible, incremental upgrade
> path. That's why I argue for a Python 2.8.
>
> Pointing out the 'future' module is existence proof that further
> incremental steps could be taken on top of what Python 2.7 already does.
>
> I may be that these points are wrong or should be weighed differently.
> It's possible that:
>
> * the risk of losing existing big 2.x projects is low, they'll port
> anyway, the money will keep flowing into our community, they won't look
> at other languages, etc.
>
> * these big 2.x projects are going to all find the 'future' module
> themselves and use it as incremental upgrade path, so there's no need
> for a new blessed Python 2.x.
>
> * the approach of the 'future' module turns out to be fatally flawed
> and/or doesn't really help with incremental upgrades after all.
>
> But that's how I reason about it, and how I weigh things. I think the
> current strategy is risky.
>
> Regards,
>
> Martijn
>

My understanding is that 95% of core developers won't work on 2.8,
partly I suspect because of the massive overhead they've already had to
do supporting 2 and 3 in parellel. Assuming that I'm correct, who is
going to do the work involved, you Martijn?

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

Mark Lawrence





== 4 of 13 ==
Date: Wed, Jan 8 2014 6:30 am
From: Mark Lawrence



On 08/01/2014 14:15, Roy Smith wrote:
> As somebody who is still firmly in the 2.x world, I'm worried about the
> idea of a 2.x fork. While I have my doubts that 3.x was a good idea,
> the fact is, it's here. Having the community fractured between the two
> camps is not good. Let's say I'm somebody who wants to contribute some
> OSS. I have three basic choices:
>
> 1) I can make it 3.x only. Now, (nominally) half of the python
> community is unable to realize value from my contribution.
>
> 2) I can make it 2.x only. Same thing in reverse.
>
> 3) I can make it work on both 2.x and 3.x, which means I'm investing
> more effort than I had to if it were single platform.
>
> Any of those alternatives is worse than ideal. Forking 2.x to create an
> unofficial 2.8 release would just prolong the situation. As I've stated
> before, I don't see any urgency in moving to 3.x, and don't imagine
> doing there for another couple of years, but I absolutely can't imagine
> moving to a 2.8 fork.
>

The above strikes me as common sense. Surely that's out of place on
this list? :)

But to be serious why not stick with 2.x if there's no compelling reason
to move? Whatever happened to "if it ain't broke, don't fix it"? And
before anyone says anything please don't start on about the bytes versus
string debate, I'm fairly certain that there are a substantial number of
application areas that don't run into these problems.

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

Mark Lawrence





== 5 of 13 ==
Date: Wed, Jan 8 2014 6:45 am
From: Pedro Larroy


I think for new projects one should go with 3.x this is the right thing to
do. If you require a module that's 2.x only it's easy enough to port it
unless it depends on some monster like protobuf which doesn't have
python3.x support


Pedro.


On Wed, Jan 8, 2014 at 3:30 PM, Mark Lawrence <breamoreboy@yahoo.co.uk>wrote:

> On 08/01/2014 14:15, Roy Smith wrote:
>
>> As somebody who is still firmly in the 2.x world, I'm worried about the
>> idea of a 2.x fork. While I have my doubts that 3.x was a good idea,
>> the fact is, it's here. Having the community fractured between the two
>> camps is not good. Let's say I'm somebody who wants to contribute some
>> OSS. I have three basic choices:
>>
>> 1) I can make it 3.x only. Now, (nominally) half of the python
>> community is unable to realize value from my contribution.
>>
>> 2) I can make it 2.x only. Same thing in reverse.
>>
>> 3) I can make it work on both 2.x and 3.x, which means I'm investing
>> more effort than I had to if it were single platform.
>>
>> Any of those alternatives is worse than ideal. Forking 2.x to create an
>> unofficial 2.8 release would just prolong the situation. As I've stated
>> before, I don't see any urgency in moving to 3.x, and don't imagine
>> doing there for another couple of years, but I absolutely can't imagine
>> moving to a 2.8 fork.
>>
>>
> The above strikes me as common sense. Surely that's out of place on this
> list? :)
>
> But to be serious why not stick with 2.x if there's no compelling reason
> to move? Whatever happened to "if it ain't broke, don't fix it"? And
> before anyone says anything please don't start on about the bytes versus
> string debate, I'm fairly certain that there are a substantial number of
> application areas that don't run into these problems.
>
>
> --
> My fellow Pythonistas, ask not what our language can do for you, ask what
> you can do for our language.
>
> Mark Lawrence
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>




== 6 of 13 ==
Date: Wed, Jan 8 2014 6:50 am
From: Chris Angelico


On Thu, Jan 9, 2014 at 1:30 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> But to be serious why not stick with 2.x if there's no compelling reason to
> move? Whatever happened to "if it ain't broke, don't fix it"? And before
> anyone says anything please don't start on about the bytes versus string
> debate, I'm fairly certain that there are a substantial number of
> application areas that don't run into these problems.

Two reasons for moving:

1) Support for newer hardware, underlying libraries, etc
2) Bug fixes and security patches.

#1 won't be a visible problem for most people - they'll be using a
Python packaged by their OS, so if there are any issues with building
Python against version X.Y of libfoobar, the OS maintainers will
either ship the older version of libfoobar, or make Python work. Only
a handful of people (the OS package maintainers themselves) will even
need to consider that. So it's #2 that people will be thinking about.
There's going to come a time when python.org will no longer provide
updates for Python 2.7, and at that point, everyone has to decide
which is greater: the risk of undiscovered flaws, or the hassle of
shifting. For most end users, they'll choose to stick with an
unsupported Python rather than shift, but there are those (corporates,
mainly) for whom a promise of bug fixes is critical, so that'd be
their date to shift. After all, it worked for Windows XP, right?
End-of-life date rolls around and everyone moves onto Windows 7....
hmm, maybe that didn't quite happen. Still, it does put pressure on
people.

ChrisA




== 7 of 13 ==
Date: Wed, Jan 8 2014 7:06 am
From: Grant Edwards


On 2014-01-08, Chris Angelico <rosuav@gmail.com> wrote:

> Two reasons for moving:
>
> 1) Support for newer hardware

How does Python 3.x support newer hardware than Python 2.7?

--
Grant Edwards grant.b.edwards Yow! Psychoanalysis??
at I thought this was a nude
gmail.com rap session!!!




== 8 of 13 ==
Date: Wed, Jan 8 2014 7:08 am
From: Martijn Faassen


On 01/08/2014 01:46 PM, Chris Angelico wrote:
> On Wed, Jan 8, 2014 at 11:36 PM, Martijn Faassen <faassen@startifact.com> wrote:
>> Well, in the original article I argue that it may be risky for the Python
>> community to leave the large 2.7 projects behind because they tend to be the
>> ones that pay us in the end.
>>
>> I also argue that for those projects to move anywhere, they need a clear,
>> blessed, official, as simple as possible, incremental upgrade path. That's
>> why I argue for a Python 2.8.
>>
>> Pointing out the 'future' module is existence proof that further incremental
>> steps could be taken on top of what Python 2.7 already does.
>
> Yep, but suppose it were simply that the future module is blessed as
> the official, simple, incremental upgrade path. That doesn't violate
> PEP 404, it allows the future module to continue to be expanded
> without worrying about the PSF's schedules (more stuff might be added
> to it in response to Python 3.5, but this is all in the hands of
> future's maintainer), and it should be relatively simple to produce an
> installer that goes and grabs it.

That would be better than nothing, but would break the: "upgrade path
should be totally obvious" guideline. Also the core developers are
generally not in the habit of blessing external projects except by
taking them into the stdlib, so that'd be a first.

> As Mark Rosewater is fond of saying, restrictions breed creativity.
> Can the porting community take the PEP 404 restriction and be creative
> within it? I suspect it'll go a long way.

How many actively maintained applications on Python 2.7 are being
ported? Do we know? If not many, is this a problem? As problems also
breed creativity.

Regards,

Martijn





== 9 of 13 ==
Date: Wed, Jan 8 2014 7:22 am
From: Martijn Faassen


Hey,

I'm pointing out possible improvements that Python 2.8 could offer that
would help incremental porting efforts of applications. I'm pointing
about that helping application developers move forward incrementally may
be a worthwhile consideration. Like, there's money there.

You can point out that 2.6 and 2.7 were already such releases, and I
will then point out that many people *have* upgraded their applications
to these releases. Is there now going to be a giant leap forward to
Python 3 by these projects, or is the jump still too far? Opinions differ.

On 01/08/2014 02:01 PM, Steven D'Aprano wrote:
> Adding 2.8 doesn't help. It just gives people another excuse to delay
> migrating. Then, in another two or three years, they'll demand 2.9, and put
> it off again. Then they'll insist that 15 years wasn't long enough to
> migrate their code, and demand 2.10.

I can play this kind of rhetorical game too, including demands and such
fun. Who is demanding who does what?

It's not really a surprise that people expect there to be a compatible
release of a programming language. We'll have to see whether the demand
for it is strong enough to tear out community apart, or whether all will
be right in the end.

> What's not fine though is people holding the rest of us back with their
> negativity and FUD that Python 3 is a mistake.

That's not what I believe I've been doing. Though if people do this, is
the Python community really so fragile it can't deal with a little bit
of pushback?

What's not fine is that people who think all is well tell the people who
disagree to shut up. Maybe we should introduce the concept of "check
your Python 3 privilege".

Regards,

Martijn





== 10 of 13 ==
Date: Wed, Jan 8 2014 7:26 am
From: Martijn Faassen


Hey,

On 01/08/2014 03:30 PM, Mark Lawrence wrote:

> But to be serious why not stick with 2.x if there's no compelling reason
> to move? Whatever happened to "if it ain't broke, don't fix it"?

That's fine for static applications that don't have to change.

Successful applications tend to grow new features over the years. It's
not fun to do so if new capabilities are growing out of reach in Python
3 land.

It's possible if enough features exist in Python 3 land bosses of
successful applications will fund a port, with all the risks of
introducing bugs that this entails. But a smoother upgrade path would
help those applications more. And as I pointed out before, these
applications are where a lot of money and development resources are
coming from in our community.

Of course it's possible my assessment of the importance of these
applications, their development resources, and the bump a Python 3 port
presents for them, is off.

Regards,

Martijn






== 11 of 13 ==
Date: Wed, Jan 8 2014 7:31 am
From: Chris Angelico


On Thu, Jan 9, 2014 at 2:06 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2014-01-08, Chris Angelico <rosuav@gmail.com> wrote:
>
>> Two reasons for moving:
>>
>> 1) Support for newer hardware
>
> How does Python 3.x support newer hardware than Python 2.7?

At the moment, I would say there's no difference between those two
versions. But there was an issue a short while ago about OS X 10.9 and
the compilers/libraries available for it, which necessitated some
patches, and those patches would have been applied to all
currently-supported versions of Python. That means that 2.7 got them
(in 2.7.6 [1]), so it'll build nicely, but 2.6 won't have, so anyone
who wants to use 2.6 on 10.9 will have to manually backport that fix.
I mention hardware because there are times when the new hardware won't
run the old OS, the new OS won't work with the old compiler and/or
library, and the new compiler/library won't work with the old Python.
At that point, you have to either run a virtual machine (overkill) or
remain on the old hardware (hence, Python X.Y doesn't support your
hardware).

So long as 2.7 is being supported, there are no problems with this.
Same with the bug fixes and security patches that I mention in the
next line. Once it's out of support, though, both will cease (or they
might cease at different times), and then new hardware, new compilers,
new versions of required libraries, could cause problems. I elaborated
further down that these issues would be mainly dealt with by OS
package maintainers (I'm sure Red Hat have been doing this for years),
but they'll still be problems.

[1] http://www.python.org/download/releases/2.7.6/

ChrisA




== 12 of 13 ==
Date: Wed, Jan 8 2014 7:39 am
From: Chris Angelico


On Thu, Jan 9, 2014 at 2:22 AM, Martijn Faassen <faassen@startifact.com> wrote:
> I'm pointing out possible improvements that Python 2.8 could offer that
> would help incremental porting efforts of applications. I'm pointing about
> that helping application developers move forward incrementally may be a
> worthwhile consideration. Like, there's money there.

I'm not sure who's actually paying the PSF to develop a 2.8, so I'm
not sure why you can say there's money there. Are you offering? Or do
you have reason to believe someone else will?

> You can point out that 2.6 and 2.7 were already such releases, and I will
> then point out that many people *have* upgraded their applications to these
> releases. Is there now going to be a giant leap forward to Python 3 by these
> projects, or is the jump still too far? Opinions differ.

Still waiting for a solid suggestion as to what would actually be
different in 2.8 that can't be done with a module. If there's a really
brilliant module that massively eases the burden of porting, then
python.org / the PSF might well even add it to the stdlib, or at least
point people to it from the home page. That would make for an
excellent "smooth upgrade" path, dealing with the renamed modules and
so on, and it takes no language changes at all.

I'm pretty sure most people here are in broad agreement with your goal
of making it easy to migrate to Py3. What we're not seeing - or at
least, what I'm not seeing - is how a Python 2.8 would achieve that;
and what several of us ARE seeing is how a Python 2.8 actually makes
it harder.

ChrisA




== 13 of 13 ==
Date: Wed, Jan 8 2014 7:50 am
From: Mark Lawrence



On 08/01/2014 15:39, Chris Angelico wrote:
> On Thu, Jan 9, 2014 at 2:22 AM, Martijn Faassen <faassen@startifact.com> wrote:
>> I'm pointing out possible improvements that Python 2.8 could offer that
>> would help incremental porting efforts of applications. I'm pointing about
>> that helping application developers move forward incrementally may be a
>> worthwhile consideration. Like, there's money there.
>
> I'm not sure who's actually paying the PSF to develop a 2.8, so I'm
> not sure why you can say there's money there. Are you offering? Or do
> you have reason to believe someone else will?
>

There can be �1,000,000 in the PSF kitty but if the core developers
don't want to do the work it won't happen!!!

Personally I still think the whole idea of a 2.8 is nonsense that would
only serve to divert already scarce resources. Fixing some of the 4,000
(?) open issues on the bug tracker would come higher up my list,
particularly as some of them have been sitting there for ten years. Or
how about finally getting the "new" regex module into the standard library?

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

Mark Lawrence






==============================================================================
TOPIC: Looking for tips for moving dev environment from Windows to Mac
http://groups.google.com/group/comp.lang.python/t/ca1bbe129ce09782?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Jan 8 2014 6:11 am
From: python@bdurham.com


Long time Windows developer making the move to Apple platform. My new
development environment is a 15" MacBook Pro with 16 Gb RAM and a 512
Gb SSD. I'm totally new to the world of Apple hardware and software and
am looking for advice on what apps, utilities and hardware I should
consider for my new environment..



Some early questions:



1. Which distribution of Python to install (Python.org, ActivateState,
other?) and do I need to do anything special to avoid overwriting the
system copy of Python?



2. Text editor: Textmate, BBEdit, Emacs/VI, or other?



3. Multiple external monitors: Any recommendations on monitor
specs/models for 2 external monitors for a MacBook?



4. Best visual diff utility for Mac?



Any other "gotta have" Mac apps, utilities, or hardware accessories you
would recommend?



Thank you!

Malcolm




== 2 of 2 ==
Date: Wed, Jan 8 2014 7:45 am
From: William Ray Wing


On Jan 8, 2014, at 9:11 AM, python@bdurham.com wrote:

> Long time Windows developer making the move to Apple platform. My new development environment is a 15" MacBook Pro with 16 Gb RAM and a 512 Gb SSD. I'm totally new to the world of Apple hardware and software and am looking for advice on what apps, utilities and hardware I should consider for my new environment..

Welcome to the world of Macs, OS-X, and Darwin.

>
> Some early questions:
>
> 1. Which distribution of Python to install (Python.org, ActivateState, other?) and do I need to do anything special to avoid overwriting the system copy of Python?
>

The answer to this is going to depend on exactly what you are intending to do. ActiveState (for example) has what may well be the best totally integrated package of libraries (GUI, numpy, mathplotlib, and such), but has a pretty expensive license if you are going to do commercial development. Tell us more if you want a better recommendation.


> 2. Text editor: Textmate, BBEdit, Emacs/VI, or other?
>

At the risk of setting off a religious war; I use BBEdit (have used it for years, and have been very pleased with its speed, power, regular updates, and integration with the OS). There is strong support for other editors on this list, I'm sure you will hear from supporters of vi, Emacs, and Vim.

> 3. Multiple external monitors: Any recommendations on monitor specs/models for 2 external monitors for a MacBook?

I use Apple monitors, but that's strictly personal.

>
> 4. Best visual diff utility for Mac?

BBEdit has a nice built-in diff with side-by-side scrolling windows. When combined with its code-folding, multi-file search, and built-in python support, it makes a nice package.

>
> Any other "gotta have" Mac apps, utilities, or hardware accessories you would recommend?

Two external disks. One dedicated to TimeMachine for continuous backups of code as you write it, and one dedicated to either CarbonCopy Cloner or SuperDuper. Whichever you choose, set it up to do once-a-week clones at say 2:00 AM Sunday. Modern Mac's are just as hard to crash as any other modern UNIX-derived system, and Mac laptops continue to top Consumer Reports list of trouble-free systems, but ANY hardware can develop problems and it pays to be paranoid.

Again, welcome.

-Bill

>
> Thank you!
> Malcolm
> --
> https://mail.python.org/mailman/listinfo/python-list






==============================================================================
TOPIC: Editor for Python
http://groups.google.com/group/comp.lang.python/t/1d3bfdac73cdb9d2?hl=en
==============================================================================

== 1 of 7 ==
Date: Wed, Jan 8 2014 6:23 am
From: Douglas Duhaime


I've been pleased with Komodo, and certainly prefer it over Notepad++.

Komodo:
http://www.activestate.com/komodo-ide?gclid=COHE4eLj7rsCFQISMwodOUQAiw


On Wed, Jan 8, 2014 at 7:23 AM, Jean-Michel Pichavant <
jeanmichel@sequans.com> wrote:

> ----- Original Message -----
> > On Friday, 23 November 2001 04:13:40 UTC+5:30, MANUEL FERNANDEZ PEREZ
> > wrote:
> > > Hello,
> > > I'm looking for an editor for Python.I' m interested it works on
> > > Windows.Can
> > > anybody help me?
> > >
> > > Thank you
> > >
> > > Manuel
>
> http://lmgtfy.com/?q=python+editor+windows
>
> Otherwise, must of the newcomers will be pleased with
> http://notepad-plus-plus.org/
>
> Ideally, try to use an editor that will allow you to edit any type of
> code, python or anything else.
>
> JM
>
> PS : you could also have searched this archive, this subject has been
> already discussed... a lot.
>
>
> -- IMPORTANT NOTICE:
>
> The contents of this email and any attachments are confidential and may
> also be privileged. If you are not the intended recipient, please notify
> the sender immediately and do not disclose the contents to any other
> person, use it for any purpose, or store or copy the information in any
> medium. Thank you.
> --
> https://mail.python.org/mailman/listinfo/python-list
>



--
Douglas Duhaime
Department of English, University of Notre Dame
douglasduhaime.com, dduhaime@nd.edu




== 2 of 7 ==
Date: Wed, Jan 8 2014 7:13 am
From: Jean-Michel Pichavant



----- Original Message -----

> I've been pleased with Komodo, and certainly prefer it over
> Notepad++.

> Komodo:
> http://www.activestate.com/komodo-ide?gclid=COHE4eLj7rsCFQISMwodOUQAiw

Komodo is an IDE and costs 385$. I certainly expect it to better than notepad++.

JM


-- IMPORTANT NOTICE:

The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.




== 3 of 7 ==
Date: Wed, Jan 8 2014 7:19 am
From: Alister


On Wed, 08 Jan 2014 16:13:09 +0100, Jean-Michel Pichavant wrote:

> ----- Original Message -----
>
>> I've been pleased with Komodo, and certainly prefer it over Notepad++.
>
>> Komodo:
>> http://www.activestate.com/komodo-ide?gclid=COHE4eLj7rsCFQISMwodOUQAiw
>
> Komodo is an IDE and costs 385$. I certainly expect it to better than
> notepad++.
>
> JM
>
I like Geany it is almost & IDE & considerably cheaper (about $385
cheaper if your price is correct :-) )

>
> -- IMPORTANT NOTICE:
>
> The contents of this email and any attachments are confidential and may
> also be privileged. If you are not the intended recipient, please notify
> the sender immediately and do not disclose the contents to any other
> person, use it for any purpose, or store or copy the information in any
> medium. Thank you.

too late you have sent this to a public forum



--
Harriet's Dining Observation:
In every restaurant, the hardness of the butter pats
increases in direct proportion to the softness of the bread.




== 4 of 7 ==
Date: Wed, Jan 8 2014 7:53 am
From: Jean-Michel Pichavant


> > -- IMPORTANT NOTICE:
> >
> > The contents of this email and any attachments are confidential and
> > may
> > also be privileged. If you are not the intended recipient, please
> > notify
> > the sender immediately and do not disclose the contents to any
> > other
> > person, use it for any purpose, or store or copy the information in
> > any
> > medium. Thank you.
>
> too late you have sent this to a public forum

No pb with that, the python list is the intended recipient :)

I tried to negotiate this with my IT guys, but it looks like it's now mandatory, something related to being in the USA stock market.
I have no way to remove it, it's added by the email server. I apologise for the noise.

JM


-- IMPORTANT NOTICE:

The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.




== 5 of 7 ==
Date: Wed, Jan 8 2014 8:40 am
From: Joel Goldstick


On Wed, Jan 8, 2014 at 10:53 AM, Jean-Michel Pichavant <
jeanmichel@sequans.com> wrote:

> > > -- IMPORTANT NOTICE:
> > >
> > > The contents of this email and any attachments are confidential and
> > > may
> > > also be privileged. If you are not the intended recipient, please
> > > notify
> > > the sender immediately and do not disclose the contents to any
> > > other
> > > person, use it for any purpose, or store or copy the information in
> > > any
> > > medium. Thank you.
> >
> > too late you have sent this to a public forum
>
> No pb with that, the python list is the intended recipient :)
>
> I tried to negotiate this with my IT guys, but it looks like it's now
> mandatory, something related to being in the USA stock market.
> I have no way to remove it, it's added by the email server. I apologise
> for the noise.
>

Two thoughts: maybe create a gmail account, and
What is wrong with this world that some over paid lawyer requires a
useless, silly statement to justify his employment. The money that person
is being paid should be given to someone else.

>
> JM
>
>
> -- IMPORTANT NOTICE:
>
> The contents of this email and any attachments are confidential and may
> also be privileged. If you are not the intended recipient, please notify
> the sender immediately and do not disclose the contents to any other
> person, use it for any purpose, or store or copy the information in any
> medium. Thank you.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>


--
Joel Goldstick
http://joelgoldstick.com




== 6 of 7 ==
Date: Wed, Jan 8 2014 8:50 am
From: Chris "Kwpolska" Warrick


On Wed, Jan 8, 2014 at 4:53 PM, Jean-Michel Pichavant
<jeanmichel@sequans.com> wrote:
> I tried to negotiate this with my IT guys, but it looks like it's now mandatory, something related to being in the USA stock market.
> I have no way to remove it, it's added by the email server. I apologise for the noise.

But you have a way to hide it for people whose clients do support
that. Simply, instead of signing your letters with "JM" yourself and
having your employer add this spam, simply have your mail client add
the sequence below as your signature. Some clients offer adding the
separator automatically and you only have to type JM in the signature
field.

The "magical" sequence is: -- \nJM

(that is 0x2D 2D 20 0A 4A 4D, with a trailing space)


> JM
>
>
> -- IMPORTANT NOTICE:
>
> The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>



--
Chris "Kwpolska" Warrick <http://kwpolska.tk>
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense




== 7 of 7 ==
Date: Wed, Jan 8 2014 8:52 am
From: Chris Angelico


On Thu, Jan 9, 2014 at 3:40 AM, Joel Goldstick <joel.goldstick@gmail.com> wrote:
> What is wrong with this world that some over paid lawyer requires a useless,
> silly statement to justify his employment. The money that person is being
> paid should be given to someone else.

Good luck. Guess who would be suing you for wrongful dismissal? :)

I'm not sure those sorts of footers are enforceable or of any value,
but they keep on popping up. Gmail at my end will happily fold it down
as repeated/quoted text, so it doesn't bother me more than once per
thread (usually), so hey, if it keeps the lawyers from hassling
someone, I'm not fussed.

ChrisA





==============================================================================
TOPIC: Bytes indexing returns an int
http://groups.google.com/group/comp.lang.python/t/906d7333bbd1d189?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 8 2014 8:08 am
From: wxjmfauth@gmail.com


Le mercredi 8 janvier 2014 12:05:49 UTC+1, Robin Becker a écrit :
> On 07/01/2014 19:48, Serhiy Storchaka wrote:
>
> ........
>
> > data[0] == b'\xE1'[0] works as expected in both Python 2.7 and 3.x.
>
> >
>
> >
>
> I have been porting a lot of python 2 only code to a python2.7 + 3.3 version for
>
> a few months now. Bytes indexing was a particular problem. PDF uses quite a lot
>
> of single byte indicators so code like
>
>
>
> if text[k] == 'R':
>
> .....
>
>
>
> or
>
>
>
> dispatch_dict.get(text[k],error)()
>
>
>
> is much harder to make compatible because of this issue. I think this change was
>
> a mistake.
>
>
>
> To get round this I have tried the following class to resurrect the old style
>
> behaviour
>
>
>
> if isPy3:
>
> class RLBytes(bytes):
>
> '''simply ensures that B[x] returns a bytes type object and not an int'''
>
> def __getitem__(self,x):
>
> if isinstance(x,int):
>
> return RLBytes([bytes.__getitem__(self,x)])
>
> else:
>
> return RLBytes(bytes.__getitem__(self,x))
>
>
>
> I'm not sure if that covers all possible cases, but it works for my dispatching
>
> cases. Unfortunately you can't do simple class assignment to change the
>
> behaviour so you have to copy the text.
>
>
>
> I find a lot of the "so glad we got rid of byte strings" fervour a bit silly.
>
> Bytes, chars, words etc etc were around long before unicode. Byte strings could
>
> already represent unicode in efficient ways that happened to be useful for
>
> western languages. Having two string types is inconvenient and error prone,
>
> swapping their labels and making subtle changes is a real pain.
>
> --


--

Byte strings (encoded code points) or native unicode is one
thing.

But on the other side, the problem is elsewhere. These very
talented ascii narrow minded, unicode illiterate devs only
succeded to produce this (I, really, do not wish to be rude).

>>> import unicodedata
>>> unicodedata.name('ǟ')
'LATIN SMALL LETTER A WITH DIAERESIS AND MACRON'
>>> sys.getsizeof('a')
26
>>> sys.getsizeof('ǟ')
40
>>> timeit.timeit("unicodedata.normalize('NFKD', 'ǟ')", "import unicodedata")
0.8040018888575129
>>> timeit.timeit("unicodedata.normalize('NFKD', 'zzz')", "import unicodedata")
0.3073749330963995
>>> timeit.timeit("unicodedata.normalize('NFKD', 'z')", "import unicodedata")
0.2874013282653962
>>>
>>> timeit.timeit("len(unicodedata.normalize('NFKD', 'zzz'))", "import unicodedata")
0.3803570633857589
>>> timeit.timeit("len(unicodedata.normalize('NFKD', 'ǟ'))", "import unicodedata")
0.9359970320201683

pdf, typography, linguistic, scripts, ... in mind, in other word the real
*unicode* world.

jmf






==============================================================================
TOPIC: Suggest an open-source log analyser?
http://groups.google.com/group/comp.lang.python/t/a7adef00a9d20d74?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 8 2014 8:46 am
From: Alec Taylor


So yeah, if you know of a good one; please share.

Thanks

On Sun, Jan 5, 2014 at 2:50 PM, Alec Taylor <alec.taylor6@gmail.com> wrote:
> Because I'm thinking that something with a much less expressive query
> interface would serve me better in the long run... e.g.: Redis or
> maybe Hadoop
>
> On Sat, Jan 4, 2014 at 5:35 PM, Walter Hurry <walterhurry@lavabit.com> wrote:
>> On Thu, 02 Jan 2014 16:40:19 +1100, Alec Taylor wrote:
>>
>>> I use the Python logger class; with the example syntax of:
>>> Formatter('%(asctime)s - %(name)s - %(levelname)s - %(message)s')
>>>
>>> Can of course easily use e.g.: a JSON syntax here instead.
>>>
>>> Are there any open-source log viewers (e.g.: with a web-interface)
>>> that you'd recommend; for drilling down into my logs?
>>>
>> If you want to do in-depth analysis, why not just stick it into an SQL
>> database; e.g. SQLite or Postgres?
>>
>> --
>> https://mail.python.org/mailman/listinfo/python-list




==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.python"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.python?hl=en

To unsubscribe from this group, send email to comp.lang.python+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.python/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en