Re: [Python-Dev] __file__

2010-03-04 Thread Nick Coghlan 
Henning von Bargen wrote:
> If the ZIP contains only bytecode files, it is just not intended
> for changing any code, so I don't think this is an argument.
> If you have access to the source code, you still can use that instead
> of messing around with byte code.

That doesn't apply when it is the app developer trying to figure out why
their app is breaking when they throw it in a bytecode only zip :)

It's a moot point anyway - Guido has pronounced that the bytecode-only
support will be left alone by PEP 3147 even if the other caching changes
are eventually accepted.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __file__ and bytecode-only

2010-03-04 Thread Nick Coghlan 
Barry Warsaw wrote:
> On Mar 03, 2010, at 07:37 PM, Jim Jewett wrote:
> 
>> I understand the need to ship without source -- but why does that
>> require supporting .pyc (or .pyo) -only?
>>
>> Couldn't vendors just replace the real .py files with empty files?
> 
> Yes, I think that's a possibility.  What would people think about that?

I actually thought of this, but didn't post it because it defeats the
point of byte-code only distribution.

- putting text in the .py file will break the application
- touching the .py file in any way will break the application

If someone wants to break the bytecode only support it should be its own
PEP and not coupled with PEP 3147.

The remaining open question to my mind is whether or not there should be
a -X option to control the bytecode generation. E.g.:

-Xcache_bytecode=no (don't write bytecode files at all)
-Xcache_bytecode=file (write a classic "foo.pyc" file)
-Xcache_bytecode=dir (write to the "__pycache__" directory)

With cache_bytecode=dir being the default for future releases.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __file__

2010-03-04 Thread Barry Warsaw 
On Mar 04, 2010, at 11:25 PM, Nick Coghlan wrote:

>It's a moot point anyway - Guido has pronounced that the bytecode-only
>support will be left alone by PEP 3147 even if the other caching changes
>are eventually accepted.

Right.  I should have stopped while I was ahead.  We'll just keep what's in
the PEP.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Desired changes to Hg emails to python-checkins

2010-03-04 Thread Brett Cannon 
1) I miss not having the affected files listed in the subject line.

2) The To field is set to [email protected] which gets rejected as an invalid
email address if you reply. Would be better to set it to python-checkins so
that the habitual reply to a checkin won't get rejected.

At least I would like to see these changes happen.

-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Desired changes to Hg emails to python-checkins

2010-03-04 Thread Fred Drake 
On Thu, Mar 4, 2010 at 3:20 PM, Brett Cannon  wrote:
> 1) I miss not having the affected files listed in the subject line.
> 2) The To field is set to [email protected] which gets rejected as an invalid
> email address if you reply. Would be better to set it to python-checkins so
> that the habitual reply to a checkin won't get rejected.

I concur on both points.  You are not alone.  :-)


  -Fred

-- 
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Desired changes to Hg emails to python-checkins

2010-03-04 Thread Nick Coghlan 
Brett Cannon wrote:
> 1) I miss not having the affected files listed in the subject line.
> 
> 2) The To field is set to [email protected]  which
> gets rejected as an invalid email address if you reply. Would be better
> to set it to python-checkins so that the habitual reply to a checkin
> won't get rejected.
> 
> At least I would like to see these changes happen.

+1 (and it's OK if the file list gets truncated for big checkins - it's
still handy in typical cases)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Desired changes to Hg emails to python-checkins

2010-03-04 Thread Eric Smith 

Are the diffs gone for some deliberate reason?

I realize the link tells me the changes, but I'll review a lot more code 
if the diffs show up in my inbox than if I have to fire up a browser, 
especially from my phone.


Eric.

Brett Cannon wrote:

1) I miss not having the affected files listed in the subject line.

2) The To field is set to [email protected]  which 
gets rejected as an invalid email address if you reply. Would be better 
to set it to python-checkins so that the habitual reply to a checkin 
won't get rejected.


At least I would like to see these changes happen.

-Brett




___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com



--
Eric.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Desired changes to Hg emails to python-checkins

2010-03-04 Thread Nick Coghlan 
Brett Cannon wrote:
> 1) I miss not having the affected files listed in the subject line.
> 
> 2) The To field is set to [email protected]  which
> gets rejected as an invalid email address if you reply. Would be better
> to set it to python-checkins so that the habitual reply to a checkin
> won't get rejected.
> 
> At least I would like to see these changes happen.

I'd like to keep the inline diffs as well - much easier to skim patches
as I click through messages, whereas links to changesets, while useful
if I decide to look at a change in more detail, don't tell me a lot at a
glance.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Desired changes to Hg emails to python-checkins

2010-03-04 Thread Barry Warsaw 
On Mar 04, 2010, at 03:43 PM, Eric Smith wrote:

>Are the diffs gone for some deliberate reason?
>
>I realize the link tells me the changes, but I'll review a lot more code 
>if the diffs show up in my inbox than if I have to fire up a browser, 
>especially from my phone.

Agreed, please restore the diffs!
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Desired changes to Hg emails to python-checkins

2010-03-04 Thread Dirkjan Ochtman 
First off, this was just a first sample, it was by no means the
definitive format.

Second, the diffs are already back, in the next message (this first
one was per changegroup, not per changeset -- new ones will be per
changeset).

On Thu, Mar 4, 2010 at 21:20, Brett Cannon  wrote:
> 1) I miss not having the affected files listed in the subject line.

Well, I think it looks rather ugly, and Tarek said he'd like the first
line of the commit message in the subject instead, so that's what I've
implemented right now. But then if there's a majority who want the
files, I'm happy to put them back.

> 2) The To field is set to [email protected] which gets rejected as an invalid
> email address if you reply. Would be better to set it to python-checkins so
> that the habitual reply to a checkin won't get rejected.

Will fix.

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Desired changes to Hg emails to python-checkins

2010-03-04 Thread Benjamin Peterson 
2010/3/4 Dirkjan Ochtman :
> Well, I think it looks rather ugly, and Tarek said he'd like the first
> line of the commit message in the subject instead, so that's what I've
> implemented right now. But then if there's a majority who want the
> files, I'm happy to put them back.

+1 to bringing back affected files. It helps tell at a glance whether
a changeset is interesting or not.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Desired changes to Hg emails to python-checkins

2010-03-04 Thread Dirkjan Ochtman 
On Thu, Mar 4, 2010 at 22:44, Benjamin Peterson  wrote:
> +1 to bringing back affected files. It helps tell at a glance whether
> a changeset is interesting or not.

Do they need to be in the subject, or would it be fine to have them in
the message?

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Desired changes to Hg emails to python-checkins

2010-03-04 Thread Benjamin Peterson 
2010/3/4 Dirkjan Ochtman :
> On Thu, Mar 4, 2010 at 22:44, Benjamin Peterson  wrote:
>> +1 to bringing back affected files. It helps tell at a glance whether
>> a changeset is interesting or not.
>
> Do they need to be in the subject, or would it be fine to have them in
> the message?

Both is good actually.


-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Desired changes to Hg emails to python-checkins

2010-03-04 Thread Brett Cannon 
On Thu, Mar 4, 2010 at 13:56, Benjamin Peterson  wrote:

> 2010/3/4 Dirkjan Ochtman :
> > On Thu, Mar 4, 2010 at 22:44, Benjamin Peterson 
> wrote:
> >> +1 to bringing back affected files. It helps tell at a glance whether
> >> a changeset is interesting or not.
> >
> > Do they need to be in the subject, or would it be fine to have them in
> > the message?
>
> Both is good actually.
>

I prefer the subject so that I can easily skim them to see if someone edited
a file I really care about, but if that is not possible then the body is
acceptable, especially if it is the first thing in the body (that would let
me at least see some of it in the initial snippet Gmail shows).

-Brett



>
>
> --
> Regards,
> Benjamin
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Desired changes to Hg emails to python-checkins

2010-03-04 Thread Stephen J. Turnbull 
Brett Cannon writes:

 > I prefer the subject so that I can easily skim them to see if someone edited
 > a file I really care about, but if that is not possible then the body is
 > acceptable, especially if it is the first thing in the body (that would let
 > me at least see some of it in the initial snippet Gmail shows).

I don't know if it's pedantically RFC-correct, but occasionally you'll
see a Summary field in the header.  I think using the first line of
the log in the Subject field and the file list as the Summary field
would be a good way to do it, *if* people's MUAs would display
Summary.  I suspect they don't (mine does, but mine does a lot of
nifty things that cellphone MUAs don't :-( ).
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] doctest, unicode repr, and 2to3

2010-03-04 Thread Martin v. Löwis 
Johan Harjano ran into an interesting problem when trying to run the
Django test suite under Python 3.1.

Django has doctests of the form

>>> a6.headline
u'Default headline'

Even when converting the doctest with 2to3, the expected output is
unmodified. However, in 3.x, the expected output will change (i.e. not
produce an u"" prefix anymore).

Now, it might be possible to reformulate the test case (e.g. use print()
instead of relying on repr), however, this is undesirable as a) the test
should continue to test in 2.x that the result object is a unicode
string, and b) it makes the test less readable.

I would like to find a solution where this gets automatically corrected,
e.g. through 2to3, or through changes to doctest, or through changes of
str.__repr__.

Any proposal appreciated.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] doctest, unicode repr, and 2to3

2010-03-04 Thread Barry Warsaw 
On Mar 05, 2010, at 05:11 AM, Martin v. Löwis wrote:

>Johan Harjano ran into an interesting problem when trying to run the
>Django test suite under Python 3.1.
>
>Django has doctests of the form
>
 a6.headline
>u'Default headline'
>
>Even when converting the doctest with 2to3, the expected output is
>unmodified. However, in 3.x, the expected output will change (i.e. not
>produce an u"" prefix anymore).

For this reason, I always recommend using print, even though...

>Now, it might be possible to reformulate the test case (e.g. use print()
>instead of relying on repr), however, this is undesirable as a) the test
>should continue to test in 2.x that the result object is a unicode
>string, and b) it makes the test less readable.

If you really want to test that it's a unicode, shouldn't you actually test
its type?  (I'm not sure what would happen with that under 2to3.)  Besides,
the type of the string is very rarely important, so I think the u-prefix and
quotes is mostly just noise.

>I would like to find a solution where this gets automatically corrected,
>e.g. through 2to3, or through changes to doctest, or through changes of
>str.__repr__.

I think Michael was also talking about changes to doctest that would
automatically sort dictionaries and sets.  Again, it's not hard to write
doctests correctly, but it's surprisingly common to implicitly rely on sort
order.

I think the right place to change these is in doctest.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] doctest, unicode repr, and 2to3

2010-03-04 Thread Glyph Lefkowitz 

On Mar 4, 2010, at 11:30 PM, Barry Warsaw wrote:

> If you really want to test that it's a unicode, shouldn't you actually test
> its type?  (I'm not sure what would happen with that under 2to3.)

Presumably 2to3 will be smart enough to translate 'unicode' to 'str' and 
'bytes' to... 'bytes'.  Just don't use 'str' in 2.x and you should be okay :).

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [PEP 3148] futures - execute computations asynchronously

2010-03-04 Thread Brian Quinlan 

Hi all,

I recently submitted a daft PEP for a package designed to make it  
easier to execute Python functions asynchronously using threads and  
processes. It lets the user focus on their computational problem  
without having to build explicit thread/process pools and work queues.


The package has been discussed on stdlib-sig but now I'd like this  
group's feedback.


The PEP lives here:
http://python.org/dev/peps/pep-3148/

Here are two examples to whet your appetites:

"""Determine if several numbers are prime."""
import futures
import math

PRIMES = [
112272535095293,
112582705942171,
112272535095293,
115280095190773,
115797848077099,
1099726899285419]

def is_prime(n):
if n % 2 == 0:
return False

sqrt_n = int(math.floor(math.sqrt(n)))
for i in range(3, sqrt_n + 1, 2):
if n % i == 0:
return False
return True

# Uses as many CPUs as your machine has.
with futures.ProcessPoolExecutor() as executor:
for number, is_prime in zip(PRIMES, executor.map(is_prime,  
PRIMES)):

print('%d is prime: %s' % (number, is_prime))


"""Print out the size of the home pages of various new sites (and Fox  
News)."""

import futures
import urllib.request

URLS = ['http://www.foxnews.com/',
'http://www.cnn.com/',
'http://europe.wsj.com/',
'http://www.bbc.co.uk/',
'http://some-made-up-domain.com/']

def load_url(url, timeout):
return urllib.request.urlopen(url, timeout=timeout).read()

with futures.ThreadPoolExecutor(max_workers=5) as executor:
# Create a future for each URL load.
future_to_url = dict((executor.submit(load_url, url, 60), url)
 for url in URLS)

# Iterate over the futures in the order that they complete.
for future in futures.as_completed(future_to_url):
url = future_to_url[future]
if future.exception() is not None:
print('%r generated an exception: %s' % (url,
  
future.exception()))

else:
print('%r page is %d bytes' % (url, len(future.result(

Cheers,
Brian
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com