Re: suggestions, comments on an "is_subdict" test

[Raymond Hettinger]

On Apr 22, 8:18 am, MRAB  wrote:
> On 22/04/2011 15:57, Irmen de Jong wrote:
>
>
>
>
>
>
>
> > On 22-4-2011 15:55, Vlastimil Brom wrote:
> >> Hi all,
> >> I'd like to ask for comments or advice on a simple code for testing a
> >> "subdict", i.e. check whether all items of a given dictionary are
> >> present in a reference dictionary.
> >> Sofar I have:
>
> >> def is_subdict(test_dct, base_dct):
> >>      """Test whether all the items of test_dct are present in base_dct."""
> >>      unique_obj = object()
> >>      for key, value in test_dct.items():
> >>          if not base_dct.get(key, unique_obj) == value:
> >>              return False
> >>      return True
>
> >> I'd like to ask for possibly more idiomatic solutions, or more obvious
> >> ways to do this. Did I maybe missed some builtin possibility?
>
> > I would use:
>
> > test_dct.items()<= base_dct.items()
>
> In Python 2:
>
>  >>> test_dct = {"foo": 0, "bar": 1}
>  >>> base_dct = {"foo": 0, "bar": 1, "baz": 2}
>  >>>
>  >>> test_dct.items() <= base_dct.items()
> False
>
> In Python 3:
>
>  >>> test_dct = {"foo": 0, "bar": 1}
>  >>> base_dct = {"foo": 0, "bar": 1, "baz": 2}
>  >>> test_dct.items() <= base_dct.items()
> True
>
> YMMV

That is because it is spelled differently in Python 2.7:

>>> test_dct = {"foo": 0, "bar": 1}
>>> base_dct = {"foo": 0, "bar": 1, "baz": 2}
>>> test_dct.viewitems() <= base_dct.viewitems()
True

Raymond

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

Re: suggestions, comments on an "is_subdict" test

[Paul Rubin]

Irmen de Jong  writes:
> I would use:
> test_dct.items() <= base_dct.items()

I think you need an explicit cast:

  set(test_dct.items()) <= set(base_dct.items())
-- 
http://mail.python.org/mailman/listinfo/python-list

When is PEP necessary?

[Disc Magnet]

Is PEP necessary to add a new package to the standard library?

What if the community just wants to add a new module to an existing package?

What if only a new function has to be added to a module in the standard library?

What if only a line or two are to be added to a function in the
standard library?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Vectors

[Algis Kabaila]

On Saturday 23 April 2011 14:13:31 sturlamolden wrote:
> On Apr 23, 2:32 am, Algis Kabaila  
wrote:
> > Thanks for that.  Last time I looked at numpy (for Python3)
> > it was available in source only.  I know, real men do
> > compile, but I am an old man...  I will compile if it is
> > unavoidable, but in case of numpy it does not seem  a
> > simple matter. Am I badly mistaken?
> 
> There is a Win32 binary for Python 3.1:
> 
> http://sourceforge.net/projects/numpy/files/NumPy/1.5.1/
> 
> I have not tried to compile NumPy as I use Enthought to
> avoid such headaches. I value my own time enough to pay
> for a subscription ;-)
> 
> http://enthought.com/
> 
> 
> 
> Sturla

Whilst I have Win32 officially paid for OS, never "fire it up".  
I find nix systems much more interesting and convenient for 
programming and  consequently I use ubuntu for computing 
activities.  I do understand that many people prefer Win32 and 
appreciate their right to use what they want.  I just am at a 
loss to understand *why* ...

I guess each to own taste,

OldAl.
-- 
Algis
http://akabaila.pcug.org.au/StructuralAnalysis.pdf
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: learnpython.org - an online interactive Python tutorial

[flebber]

On Apr 23, 4:28 pm, Dennis Lee Bieber  wrote:
> On Fri, 22 Apr 2011 17:08:53 +1000, Chris Angelico 
> declaimed the following in gmane.comp.python.general:
>
> > I'm not so sure that all strings should autopromote to integer (or
> > "numeric" generally). However, adding a string and a number _should_
> > (IMHO) promote the number to string.
>
> > print "Hello, "+name+", you have "+credit+" dollars of credit with us."
>
> > Okay, that one is probably better done with the % operator, but it
> > definitely makes logical sense to concatenate numbers and strings as
> > strings, not to add them as numbers.
>
>         But what if /I/ want
>                 "A" + 1
> to return
>                 "B"
>
> 
> --
>         Wulfraed                 Dennis Lee Bieber         AF6VN
>         wlfr...@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

I like what you have done. Was it deliberate that your site teaches
python 2.x code rather than 3.x?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When is PEP necessary?

[Steven D'Aprano]

On Sat, 23 Apr 2011 17:46:26 +0530, Disc Magnet wrote:

> Is PEP necessary to add a new package to the standard library?

See http://www.python.org/dev/peps/pep-0001/

 
> What if the community just wants to add a new module to an existing
> package?

"Just"? Adding a new module is a big step.

How do you know the community wants to add a new module, without a PEP? 
The purpose of the PEP is to demonstrate that the community wants the new 
module, and to ensure that there will be people available to maintain 
that module once it is added.

http://www.python.org/dev/peps/pep-0002/


> What if only a new function has to be added to a module in the standard
> library?
> 
> What if only a line or two are to be added to a function in the standard
> library?

Trivial changes do not require a PEP.

There is a procedure which is supposed to be followed for backwards-
incompatible changes (described in a PEP, naturally), but for new 
features, generally the package maintainer is free to add them without a 
PEP.



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

Re: learnpython.org - an online interactive Python tutorial

[Dotan Cohen]

On Wed, Apr 20, 2011 at 20:15, Ron  wrote:
> Hey everyone.
>
> I've written an online interactive Python tutorial atop Google App Engine: 
> http://www.learnpython.org.
>
> All you need to do is log in using your Google account and edit the wiki to 
> add your tutorials.
>
> Read more on the website.
>
> Thanks for your help, and I would appreciate if you help me spread the word, 
> and give me feedback on the website.
> --
> http://mail.python.org/mailman/listinfo/python-list
>

Nice work! I notice that the "Next Chapter" link does not work.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Vectors

[sturlamolden]

On Apr 23, 2:26 pm, Algis Kabaila  wrote:

> I do understand that many people prefer Win32 and
> appreciate their right to use what they want.  I just am at a
> loss to understand *why* ...

For the same reason some people prefered OS/2 or
DEC to SunOS or BSD.

For the same reason some people prefer Perl or Java
to Python.

Sturla


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

Re: learnpython.org - an online interactive Python tutorial

[rantingrick]

On Apr 23, 1:28 am, Dennis Lee Bieber  wrote:

> But what if /I/ want
>                 "A" + 1
> to return
>                 "B"


No problem! Python even allows you to create your own functions! I
know, amazing! 8-O

>>> def succ(s):
return chr(ord(s) + 1)

>>> succ('a')
'b'
>>> succ('B')
'C'
>>> succ('Z')
'['

PS: The cases of (s > 255) or (s < 0) will be for the advanced reader
to solve.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: learnpython.org - an online interactive Python tutorial

[rantingrick]

On Apr 22, 1:38 am, harrismh777  wrote:

> Strings should auto-type-promote to numbers if appropriate.

No they should not! We do not want a language to "guess" our
intentions. We are big boys and girls and should be responsible for
own actions.

> This behavior should occur in input() as well. If a 'number' string is
> entered and can be converted to a Python number (whatever I mean by that
> at the moment) then the string should be converted to a number (int or
> float as appropriate) and the input() should return a reference to the
> number type  ( a value );  otherwise, input() should return the string
> entered, or throw a type error.

No, no, no! This is evil! That is what "eval" is for my friend.

> If an operation like (+) is used to add  1 + '1' then the string should
> be converted to int and the addition should take place, returning a
> reference to object int (2).

My god man,  have you gone completely insane? 8-O
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: learnpython.org - an online interactive Python tutorial

[Dotan Cohen]

On Fri, Apr 22, 2011 at 09:38, harrismh777  wrote:
> If an operation like (+) is used to add  1 + '1' then the string should be
> converted to int and the addition should take place, returning a reference
> to object int (2).
>

No, the int 1 should be cast to a string, and the result should be the
string '11'.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: learnpython.org - an online interactive Python tutorial

[Tim Chase]

On 04/23/2011 11:51 AM, Dotan Cohen wrote:

harrismh777  wrote:

If an operation like (+) is used to add  1 + '1' then the
string should be converted to int and the addition should
take place, returning a reference to object int (2).


No, the int 1 should be cast to a string, and the result
should be the string '11'.


Oh, come on...clearly if you're adding mixed types, there's 
significance to the difference, so the result should obviously be 
the complex number


  (1+1j)

Or maybe it should be the tuple

  (1,1)

Or did I mean the list

 [1,1]

It's all so obvious...  :)

I didn't mind the auto-promotion (as much) in VB6 when I had an 
explicit concat operator


  1 & "1"   ' returns "11"

vs

  1 + "1"   ' returns 2

-tkc




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

detecting newline character

[Daniel Geržo]

Hello guys,

I need to detect the newline characters used in the file I am reading. 
For this purpose I am using the following code:


def _read_lines(self):
with contextlib.closing(codecs.open(self.path, "rU")) as fobj:
fobj.readlines()
if isinstance(fobj.newlines, tuple):
self.newline = fobj.newlines[0]
else:
self.newline = fobj.newlines

This works fine, if I call codecs.open() without encoding argument; I am 
testing with an ASCII enghlish text file, and in such case the 
fobj.newlines is correctly detected being as '\r\n'. However, when I 
call codecs.open() with encoding='ascii' argument, the fobj.newlines is 
None and I can't figure out why that is the case. Reading the PEP at 
http://www.python.org/dev/peps/pep-0278/ I don't see any reason why 
would I end up with newlines being None after I call readlines().


Anyone has an idea? You can fetch the file I am testing with from 
http://danger.rulez.sk/subrip_ascii.srt


Thanks.

--
S pozdravom / Best regards
  Daniel Gerzo
--
http://mail.python.org/mailman/listinfo/python-list

Re: detecting newline character

[Chris Rebert]

On Sat, Apr 23, 2011 at 11:09 AM, Daniel Geržo  wrote:
> Hello guys,
>
> I need to detect the newline characters used in the file I am reading. For
> this purpose I am using the following code:
>
> def _read_lines(self):
>    with contextlib.closing(codecs.open(self.path, "rU")) as fobj:
>        fobj.readlines()
>        if isinstance(fobj.newlines, tuple):
>            self.newline = fobj.newlines[0]
>        else:
>            self.newline = fobj.newlines
>
> This works fine, if I call codecs.open() without encoding argument; I am
> testing with an ASCII enghlish text file, and in such case the fobj.newlines
> is correctly detected being as '\r\n'. However, when I call codecs.open()
> with encoding='ascii' argument, the fobj.newlines is None and I can't figure
> out why that is the case. Reading the PEP at
> http://www.python.org/dev/peps/pep-0278/ I don't see any reason why would I
> end up with newlines being None after I call readlines().
>
> Anyone has an idea?

I would hypothesize that it's an interaction bug between universal
newlines and codecs.open().

http://docs.python.org/library/codecs.html#codecs.open :
"Note: Files are always opened in binary mode, even if no binary mode
was specified. This is done to avoid data loss due to encodings using
8-bit values. This means that no automatic conversion of '\n' is done
on reading and writing."

Meanwhile, the vanilla built-in open() docs, at least the way I
interpret them, say that "U" and "rU" (both with the same meaning) are
the only sensical `mode` values involving universal newlines.

I would speculate that the upshot of this is that codecs.open() ends
up calling built-in open() with a nonsense `mode` of "rUb" or similar,
resulting in strange behavior.

If this explanation is correct, then there are 2 bugs:
1. Built-in open() should treat "b" and "U" as mutually exclusive and
reject mode strings which involve both.
2. codecs.open() should either reject modes involving "U", or be fixed
so that they work as expected.

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: detecting newline character

[Thomas 'PointedEars' Lahn]

Daniel Geržo wrote:

> I need to detect the newline characters used in the file I am reading.
> For this purpose I am using the following code:
> 
> def _read_lines(self):
>  with contextlib.closing(codecs.open(self.path, "rU")) as fobj:
>  fobj.readlines()
>  if isinstance(fobj.newlines, tuple):
>  self.newline = fobj.newlines[0]
>  else:
>  self.newline = fobj.newlines
> 
> This works fine, if I call codecs.open() without encoding argument; I am
> testing with an ASCII enghlish text file, and in such case the
> fobj.newlines is correctly detected being as '\r\n'. However, when I
> call codecs.open() with encoding='ascii' argument, the fobj.newlines is
> None and I can't figure out why that is the case. Reading the PEP at
> http://www.python.org/dev/peps/pep-0278/ I don't see any reason why
> would I end up with newlines being None after I call readlines().
> 
> Anyone has an idea? You can fetch the file I am testing with from
> http://danger.rulez.sk/subrip_ascii.srt

I see nothing suspicious in your .srt *after* downloading it.  file -i 
confirms that it only contains US-ASCII characters (but see below).

The only reason I can think of for this not working ATM comes from the 
documentation, where it says that 'U' requires Python to be built with 
universal newline support; that it is *usually* so, but might not be so in 
your case (but then the question remains: How could it be not None without 
`encoding' argument?)




WFM with and without `encoding' argument in python-2.7.1-8 (CPython), Debian 
GNU/Linux 6.0.1, Linux 2.6.35.5-pe (custom) SMP i686.

Which Python implementation and version are you using on which system?

On which system has the "ASCII" file been created and how?  Note that both 
uploading the file with FTP in ASCII mode and downloading over HTTP might 
have removed the problem Python has with it.

-- 
PointedEars
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Input() in Python3

[Westley Martínez]

On Fri, Apr 22, 2011 at 10:08:20AM -0400, Mel wrote:
> Westley Martínez wrote:
> > On Fri, Apr 22, 2011 at 04:49:19PM +1000, Chris Angelico wrote:
> 
> >> U NO. NO NO NO. What if someone enters "os.exit()" as their
> >> number? You shouldn't eval() unchecked user input!
> >> 
> >> Chris Angelico
> > 
> > Right, there's no way to check you're getting a number, however using:
> > 
> > a = int(input('enter a number > ')) # use float() for floats
> > 
> > will raise an exception if it can't convert the string.
> 
> But sys.exit() doesn't return a string.  My fave is
> 
> Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
> [GCC 4.4.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys
> >>> a = int (input ('enter a number >'))
> enter a number >sys.setrecursionlimit(1)
> Exception RuntimeError: 'maximum recursion depth exceeded while calling a 
> Python object' in  ignored
> Exception RuntimeError: 'maximum recursion depth exceeded while calling a 
> Python object' in  ignored
> Error in sys.excepthook:
> RuntimeError: maximum recursion depth exceeded
> 
> Original exception was:
> Traceback (most recent call last):
>   File "", line 1, in 
> RuntimeError: maximum recursion depth exceeded while calling a Python object
> >>> int (0)
> Exception RuntimeError: 'maximum recursion depth exceeded while calling a 
> Python object' in  ignored
> Exception RuntimeError: 'maximum recursion depth exceeded while calling a 
> Python object' in  ignored
> Error in sys.excepthook:
> RuntimeError: maximum recursion depth exceeded
> 
> Original exception was:
> Traceback (most recent call last):
>   File "", line 1, in 
> RuntimeError: maximum recursion depth exceeded while calling a Python object
> >>> 
> 
> 
>   Mel.
> 

What?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: detecting newline character

[Thomas 'PointedEars' Lahn]

Chris Rebert wrote:

> On Sat, Apr 23, 2011 at 11:09 AM, Daniel Geržo  wrote:
>> I need to detect the newline characters used in the file I am reading.
>> For this purpose I am using the following code:
>>
>> def _read_lines(self):
>> with contextlib.closing(codecs.open(self.path, "rU")) as fobj:
>> fobj.readlines()
>> if isinstance(fobj.newlines, tuple):
>> self.newline = fobj.newlines[0]
>> else:
>> self.newline = fobj.newlines
>>
>> This works fine, if I call codecs.open() without encoding argument; I am
>> testing with an ASCII enghlish text file, and in such case the
>> fobj.newlines is correctly detected being as '\r\n'. However, when I call
>> codecs.open() with encoding='ascii' argument, the fobj.newlines is None
>> and I can't figure out why that is the case. Reading the PEP at
>> http://www.python.org/dev/peps/pep-0278/ I don't see any reason why would
>> I end up with newlines being None after I call readlines().
>>
>> Anyone has an idea?
> 
> I would hypothesize that it's an interaction bug between universal
> newlines and codecs.open().
> 
> […]
> I would speculate that the upshot of this is that codecs.open() ends
> up calling built-in open() with a nonsense `mode` of "rUb" or similar,
> resulting in strange behavior.
> 
> If this explanation is correct, then there are 2 bugs:
> 1. Built-in open() should treat "b" and "U" as mutually exclusive and
> reject mode strings which involve both.
> 2. codecs.open() should either reject modes involving "U", or be fixed
> so that they work as expected.

You might be correct that it is a bug (already fixed in versions newer than 
2.5), since codecs.open() from my Python 2.6 reads as follows:

def open(filename, mode='rb', encoding=None, errors='strict', buffering=1):
"""
…
"""
if encoding is not None:
if 'U' in mode:
# No automatic conversion of '\n' is done on reading and writing
mode = mode.strip().replace('U', '')
if mode[:1] not in set('rwa'):
mode = 'r' + mode
if 'b' not in mode:
# Force opening of the file in binary mode
mode = mode + 'b'
file = __builtin__.open(filename, mode, buffering)
if encoding is None:
return file
info = lookup(encoding)
srw = StreamReaderWriter(file, info.streamreader, info.streamwriter, 
errors)
# Add attributes to simplify introspection
srw.encoding = encoding
return srw

-- 
PointedEars
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: learnpython.org - an online interactive Python tutorial

[Westley Martínez]

On Fri, Apr 22, 2011 at 04:48:39PM -0700, Dan Stromberg wrote:
> On Thu, Apr 21, 2011 at 11:38 PM, harrismh777 wrote:
> 
> >
> > Yes. And you have managed to point out a serious flaw in the overall logic
> > and consistency of Python, IMHO.
> >
> > Strings should auto-type-promote to numbers if appropriate.
> 
> 
> Please no.  It's a little more convenient sometimes when you're coding, but
> it adds bugs that aren't worth the small benefit.
> 
> Explicit is better than implicit.
> 
> http://www.python.org/dev/peps/pep-0020/

We have tcl for this anyways.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: detecting newline character

[Daniel Geržo]

On 23.4.2011 21:33, Thomas 'PointedEars' Lahn wrote:

Chris Rebert wrote:


On Sat, Apr 23, 2011 at 11:09 AM, Daniel Geržo  wrote:

I need to detect the newline characters used in the file I am reading.
For this purpose I am using the following code:

def _read_lines(self):
 with contextlib.closing(codecs.open(self.path, "rU")) as fobj:
 fobj.readlines()
 if isinstance(fobj.newlines, tuple):
 self.newline = fobj.newlines[0]
 else:
 self.newline = fobj.newlines

This works fine, if I call codecs.open() without encoding argument; I am
testing with an ASCII enghlish text file, and in such case the
fobj.newlines is correctly detected being as '\r\n'. However, when I call
codecs.open() with encoding='ascii' argument, the fobj.newlines is None
and I can't figure out why that is the case. Reading the PEP at
http://www.python.org/dev/peps/pep-0278/ I don't see any reason why would
I end up with newlines being None after I call readlines().

Anyone has an idea?


I would hypothesize that it's an interaction bug between universal
newlines and codecs.open().

[…]
I would speculate that the upshot of this is that codecs.open() ends
up calling built-in open() with a nonsense `mode` of "rUb" or similar,
resulting in strange behavior.

If this explanation is correct, then there are 2 bugs:
1. Built-in open() should treat "b" and "U" as mutually exclusive and
reject mode strings which involve both.
2. codecs.open() should either reject modes involving "U", or be fixed
so that they work as expected.


You might be correct that it is a bug (already fixed in versions newer than
2.5), since codecs.open() from my Python 2.6 reads as follows:


Well I am doing this on:
Python 2.7.1 (r271:86832, Mar  7 2011, 14:28:09)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin

So what do you guys advise me to do?

--
S pozdravom / Best regards
  Daniel Gerzo
--
http://mail.python.org/mailman/listinfo/python-list

Re: A question about Python Classes

[chad]

On Apr 22, 12:47 pm, Carl Banks  wrote:
> On Thursday, April 21, 2011 11:00:08 AM UTC-7, MRAB wrote:
> > On 21/04/2011 18:12, Pascal J. Bourguignon wrote:
> > > chad  writes:
>
> > >> Let's say I have the following
>
> > >> class BaseHandler:
> > >>      def foo(self):
> > >>          print "Hello"
>
> > >> class HomeHandler(BaseHandler):
> > >>      pass
>
> > >> Then I do the following...
>
> > >> test = HomeHandler()
> > >> test.foo()
>
> > >> How can HomeHandler call foo() when I never created an instance of
> > >> BaseHandler?
>
> > > But you created one!
>
> > No, he didn't, he created an instance of HomeHandler.
>
> > > test is an instance of HomeHandler, which is a subclass of BaseHandler,
> > > so test is also an instance of BaseHandler.
>
> > test isn't really an instance of BaseHandler, it's an instance of
> > HomeHandler, which is a subclass of BaseHandler.
>
> I'm going to vote that this is incorrect usage.  An instance of HomeHandler 
> is also an instance of BaseHandler, and it is incorrect to say it is not.  
> The call to HomeHandler does create an instance of BaseHandler.
>

What do you mean by the "call to HomeHandler"?  Don't I call
HomeHandler after I create an instance of BaseHandler?

Chad

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

Re: When is PEP necessary?

[Martin v. Loewis]

Am 23.04.2011 14:16, schrieb Disc Magnet:
> Is PEP necessary to add a new package to the standard library?

A PEP is necessary if the proposed change is contentious. If there is
widespread agreement that the change is desirable, no PEP is needed.

> What if the community just wants to add a new module to an existing package?

It depends on many questions: how does the author of the module think
about that addition? If he vetoes it (for example), it doesn't matter
what the community wants. Also, who is going to maintain it? Are there
competing libraries that provide the same feature? etc.

> What if only a new function has to be added to a module in the standard 
> library?

Likewise. Propose to contribute it, and see what happens.

> What if only a line or two are to be added to a function in the
> standard library?

See above. It depends on the two lines. For example, changing the
default source encoding to UTF-8 was a fairly small change, yet
given past discussions, I felt that writing PEP 3120 was necessary.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: When is PEP necessary?

[Daniel Kluev]

On Sat, Apr 23, 2011 at 11:16 PM, Disc Magnet  wrote:
> Is PEP necessary to add a new package to the standard library?
> *skip*

Don't forget that Python is not limited to CPython. Other
implementations need these PEPs to provide compliant packages.
While its not that important for pure-python modules, anything tied to
C-API better be documented, or it becomes a nightmare to keep
non-CPython version having identical interface.

-- 
With best regards,
Daniel Kluev
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: detecting newline character

[Thomas 'PointedEars' Lahn]

Daniel Geržo wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Chris Rebert wrote:
>>> Daniel Geržo wrote:
 [f.newlines is None after f.readlines()
  when f = codecs.open(…, mode='rU', encoding='ascii'),
  but not when f = codecs.open(…, mode='rU')]
>>>
>>> […]
>>> I would speculate that the upshot of this is that codecs.open() ends
>>> up calling built-in open() with a nonsense `mode` of "rUb" or similar,
>>> resulting in strange behavior.
>>>
>>> If this explanation is correct, then there are 2 bugs:
>>> 1. Built-in open() should treat "b" and "U" as mutually exclusive and
>>> reject mode strings which involve both.
>>> 2. codecs.open() should either reject modes involving "U", or be fixed
>>> so that they work as expected.
>>
>> You might be correct that it is a bug (already fixed in versions newer
>> than 2.5), since codecs.open() from my Python 2.6 reads as follows:
> 
> Well I am doing this on:
> Python 2.7.1 (r271:86832, Mar  7 2011, 14:28:09)
> [GCC 4.2.1 (Apple Inc. build 5664)] on darwin
> 
> So what do you guys advise me to do?

RTSL, fix when necessary (see my other follow-up), check the trunk, and if 
necessary submit a patch. 

For an immediate solution, do not do what is not supposed to work (calling 
codecs.open(…, mode='U')).  You can find the three kinds of newlines in the 
text with, e.g.

  self.newline = list(
set(re.findall(r'\r?\n|\r', ''.join(fobj.readlines()


Please trim your quotes to the relevant minimum (see above for example).

-- 
PointedEars
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A question about Python Classes

[Steven D'Aprano]

On Sat, 23 Apr 2011 13:30:02 -0700, chad wrote:

> On Apr 22, 12:47 pm, Carl Banks  wrote:
>> On Thursday, April 21, 2011 11:00:08 AM UTC-7, MRAB wrote:
>> > On 21/04/2011 18:12, Pascal J. Bourguignon wrote:
>> > > chad  writes:
>>
>> > >> Let's say I have the following
>>
>> > >> class BaseHandler:
>> > >>      def foo(self):
>> > >>          print "Hello"
>>
>> > >> class HomeHandler(BaseHandler):
>> > >>      pass
>>
>> > >> Then I do the following...
>>
>> > >> test = HomeHandler()
>> > >> test.foo()
>>
>> > >> How can HomeHandler call foo() when I never created an instance of
>> > >> BaseHandler?
>>
>> > > But you created one!
>>
>> > No, he didn't, he created an instance of HomeHandler.
>>
>> > > test is an instance of HomeHandler, which is a subclass of
>> > > BaseHandler, so test is also an instance of BaseHandler.
>>
>> > test isn't really an instance of BaseHandler, it's an instance of
>> > HomeHandler, which is a subclass of BaseHandler.
>>
>> I'm going to vote that this is incorrect usage.  An instance of
>> HomeHandler is also an instance of BaseHandler, and it is incorrect to
>> say it is not.  The call to HomeHandler does create an instance of
>> BaseHandler.
>>
>>
> What do you mean by the "call to HomeHandler"?  Don't I call HomeHandler
> after I create an instance of BaseHandler?

Not directly/explicitly.

The process you do is:

(1) Create the class BaseHandler.
(2) Create the class HomeHandler, which is a subclass of BaseHandler.
(3) Call HomeHandler.

At no point do you create a *direct* instance of BaseHandler (e.g. by 
calling BaseHandler). However the instance of HomeHandler is ALSO an 
instance of BaseHandler by virtue of the is-subclass relationship:

>>> issubclass(HomeHandler, BaseHandler)
True
>>> isinstance(test, HomeHandler)
True
>>> isinstance(test, BaseHandler)
True


If you *had* created a direct instance of BaseHandler by calling 
BaseHandler:

>>> base = BaseHandler()
>>> isinstance(base, BaseHandler)
True
>>> isinstance(base, HomeHandler):
False


It's like this... "Toyota Prius" is a subclass of "Motor Vehicle", so 
each and every Prius car is also a motor vehicle. But not every motor 
vehicle is a Toyota Prius.


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

Re: learnpython.org - an online interactive Python tutorial

[harrismh777]

Chris Angelico wrote:

Wow, someone else who knows REXX and OS/2! REXX was the first bignum
language I met, and it was really cool after working in BASIC and
80x86 assembly to suddenly be able to work with arbitrary-precision
numbers!


Yes, my "big num" research stuff was initially done in REXX, on VM/CMS. 
I later ported my libraries over to OS/2 and continued with that well 
into the '90s, when I discovered Unix and 'bc'.  Many folks are not 
aware that 'bc' also has arbitrary precision floating point math and a 
standard math library. It is much faster than REXX because the libraries 
are written in C, and unlike REXX they do not have to be implemented in 
the interpreter. The syntax of 'bc' is C-like, which is its only 
down-side for new students who have never had any language training. 
REXX was a great business language, particularly when CMS Pipelines was 
introduced.


Just for fun, and a trip down memory lane, you can take a look at some 
of my ancient REXX code... this code is a REXX math library designed to 
be used from the command line,  written in REXX. The primary scientific 
functions were implemented, as well as some code to calculate PI... 
most of the algorithms can be ported to 'bc' easily, but the 'bc' 
algorithms will run much faster, of course.


Back in the day, REXX was the 'new BASIC'

... now I use Python.


//
//
/** COMPUTE COMMAND LINE SCIENTIFIC CALCULATOR **/
//
//
/****/
/**   IBM Corporation  **/
/**   HARRISMH at RCHVMP2  **/
/**   EL8/663-1 B627   **/
/**   Rochester, MN  55901 **/
/****/
/**   AUTHOR:  Marcus Harris   **/
/** DATE:  93/10/22 ( port from VM/CMS )   **/
/**   UPDATE:  98/03/07**/
/**  VER:  2.0a**/
/****/
//
//
/**  syntax**/
/****/
/**  COMPUTE  expression<;expression><;expression><@digits>**/
/****/
/****/
/**  The expression(s) will be computed and displayed in terminal  **/
/**  line mode to arbitrary <@digits> of accuracy. **/
/****/
/**  The expression(s) may be any REXX math clause and may include **/
/**  a variable assignment, for use in a subsequent expression:**/
/**  ie.,  COMPUTE A=3;B=7;A/B;A*B@30  **/
/**(will compute both the quotient and product of A & B)   **/
/****/
//
//
/**  NOTES **/
/****/
/**  COMPUTE  expression<;expression><;expression><@digits>**/
/****/
/**  This program exploits Rexx  INTERPRET and NUMERIC DIGITS  **/
/****/
/**  This exec is portable to OS/2, NT and w95 Rexx/objectRexx **/
/**  without changes.  **/
/****/
//
//
/**  updates   **/
/** 93/10/21 mhh New Program  (port from VM/CMS)   **/
/** 98/03/07 mhh New Version 2.0a  **/
/**  This version includes trigonometric, logarithmic, **/
/**  exponential and combinatorial functions.  **/
/****/
/**  See the REXROOTS ABOUT file for a discussion  **/
/**  o

Re: learnpython.org - an online interactive Python tutorial

[Steven D'Aprano]

On Fri, 22 Apr 2011 01:38:21 -0500, harrismh777 wrote:

> Heiko Wundram wrote:
>> The difference between strong typing and weak typing is best described
>> by:
>>
>> Python 2.6.5 (r265:79063, Jun 12 2010, 17:07:01) [GCC 4.3.4 20090804
>> (release) 1] on cygwin Type "help", "copyright", "credits" or "license"
>> for more information.
> >>>  1+'2'
>> Traceback (most recent call last):
>>File "", line 1, in
>> TypeError: unsupported operand type(s) for +: 'int' and 'str'
> >>>
> >>>
> Yes. And you have managed to point out a serious flaw in the overall
> logic and consistency of Python, IMHO.
> 
> Strings should auto-type-promote to numbers if appropriate.

If that's a "serious" flaw, it's a flaw shared by the vast majority of 
programming languages.

As for the question of "consistency", I would argue the opposite: that 
auto-promoting strings to numbers arguably is useful, but that is what is 
inconsistent, not the failure to do so.

Consider...

"one" + 1

Should this also promote "one" to integer 1? If so, what about "uno" and 
"un" and "ein" and "один"? 

If not, why privilege one *string* representation of the number 1 over 
other *string* representations of the number 1?

How about this?

"[1, 2, 3]" + [4]

Should that auto-promote to a list as well? If not, why not? Why does 
your argument in favour of auto-promotion to int also not apply to auto-
promotion to list?

What about this?

"[2, 40, 10, 3]".sort()

Should that auto-promote to list? Should the result of sorting be 
[2, 3, 10, 40] or ['10', '2', '3', '40']? 

What about:

"[2, 4, 1, 3]".index("[")

Should that call the *string* index method, or the *list* index method?


If you want to argue that auto-promoting of strings to numbers is 
convenient for lazy programmers who can't be bothered keeping the 
distinction between strings and numbers straight, or for those who can't 
base the extra typing required to call int() but don't mind the 
inefficiency of the language repeatedly converting numbers to and from 
strings in the background, then I'd agree that the "convenience" argument 
is an argument in favour of weak-typing. (Not necessarily a *good* 
argument, but it's an argument.)

But I hope it is clear that "consistency" is not an argument in favour of 
weak-typing. As far as I know, no language applies weak-typing broadly to 
all types, and if a language did, it would be fraught with problems and 
traps.


[...]
> My feelings about this are strongly influenced by my experiences with
> the REXX language on IBM's SAA systems--- OS/2 and VM/CMS. In REXX
> everything is a string... everything. 

This is much like my experience with Apple's Hypertalk, where the only 
data structure is a string. I'm very fond of Hypertalk, but it is hardly 
designed with machine efficiency in mind. If you think Python is slow 
now, imagine how slow it would be if every expression had to be converted 
from a number back into a string, and vice versa, after every operation:

x = str(int("1") + int("2"))
y = str(int("9")/int("3"))
z = str(int(x) - int(y))
flag = str(int(z) == int("0"))

only implicitly, by the interpreter.


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

Re: Input() in Python3

[harrismh777]

Chris Rebert wrote:

Well, it pretty much*was*  totally removed; it was prone to misuse and
had very few legitimate uses. It's just that raw_input() also got
renamed simultaneously.
What were you using it for? There are often much better alternatives.


For the purpose pretty much described in PEP 3111... education.

Teaching new programmers  input, control, arithmetic, logic, and output 
 works best with simple built-ins. IMHO


I want to teach young folks how to get stuff into their simple programs, 
crank on them a bit, and spit out the results... without having to teach 
them imports, libraries, &etc.


Keep in mind that some of this stuff is very simple (say trivial) and is 
being used to provide a way to get the data 'they are expecting' into 
the program easily, with a prompt.


This was the great concept in BASIC, and REXX, and others.  The C 
language broke with this concept by declaring that the language does not 
provide I/O   ... only in the standard library, as functions!


The beauty of Python (as I've noted before) is that it can be used in an 
uber-sophisticated way... AND it can also be taught to children!  Having 
thought a little more about that, I suppose that I agree that input() 
should return a raw string. After all, the students aren't really 
entering "numbers" are they?? They are entering strings of characters 
that need to be converted into numbers... easily explained... I was just 
surprised to find that issue so hotly debated... again, why remove 
something that works.


The wisdom was to use a system call instead, right?



kind regards,

m harris
--
http://mail.python.org/mailman/listinfo/python-list

Re: When is PEP necessary?

[Jean-Paul Calderone]

On Apr 23, 5:09 pm, Daniel Kluev  wrote:
> On Sat, Apr 23, 2011 at 11:16 PM, Disc Magnet  wrote:
> > Is PEP necessary to add a new package to the standard library?
> > *skip*
>
> Don't forget that Python is not limited to CPython. Other
> implementations need these PEPs to provide compliant packages.
> While its not that important for pure-python modules, anything tied to
> C-API better be documented, or it becomes a nightmare to keep
> non-CPython version having identical interface.
>

Unit tests actually serve this purpose much better than do PEPs.

Jean-Paul
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: learnpython.org - an online interactive Python tutorial

[Chris Angelico]

On Sun, Apr 24, 2011 at 10:42 AM, Steven D'Aprano
 wrote:
> This is much like my experience with Apple's Hypertalk, where the only
> data structure is a string. I'm very fond of Hypertalk, but it is hardly
> designed with machine efficiency in mind. If you think Python is slow
> now, imagine how slow it would be if every expression had to be converted
> from a number back into a string, and vice versa, after every operation:
>
> x = str(int("1") + int("2"))
> y = str(int("9")/int("3"))
> z = str(int(x) - int(y))
> flag = str(int(z) == int("0"))
>
> only implicitly, by the interpreter.

Except that it wouldn't bother with a native integer implementation,
would it? With a string-is-bignum system, it could simply do the
arithmetic on the string itself, with no conversions at all.

Re harrismh's code: For that sort of work, I used and still use the
REXXTry program that comes with OS/2 (written, I believe, by Mike
Cowlishaw), with a modified input routine that gives readline-style
capabilities. Dragging this vaguely back on topic, the end result is
rather similar in feel to IDLE or Hilfe (Pike's interactive
interpreter).

Chris Angelico
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: learnpython.org - an online interactive Python tutorial

[Cameron Simpson]

On 23Apr2011 19:37, harrismh777  wrote:
[...]
| Yes, my "big num" research stuff was initially done in REXX, on
| VM/CMS. I later ported my libraries over to OS/2 and continued with
| that well into the '90s, when I discovered Unix and 'bc'.  Many
| folks are not aware that 'bc' also has arbitrary precision floating
| point math and a standard math library.

Floating point math? I thought, historically at least, that bc is built
on dc (arbitrary precision integer math, reverse polish syntax) and that
consequently bc uses fixed point math rather than floating point.

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

>From sci.physics:
t...@mailzone.com:
  The only problem is, how do you send a message from Earth to Mars
  instantly?  Does anyone have any ideas about where we can start?
John Baez :
  Just use a coordinate system in which the point at which the message is
  received has the same t coordinate as the point at which the message was sent.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: learnpython.org - an online interactive Python tutorial

[harrismh777]

Cameron Simpson wrote:

| folks are not aware that 'bc' also has arbitrary precision floating
| point math and a standard math library.

Floating point math? I thought, historically at least, that bc is built
on dc (arbitrary precision integer math, reverse polish syntax) and that
consequently bc uses fixed point math rather than floating point.


My bad... I don't mean under-the-covers... I mean that the user may 
calculate arbitrary precision floating arithmetic ... bc keeps track of 
the decimal point and displays the number of digits the user specifies; 
arbitrary precision calculator.  (loose language, sorry)


On a *nix system, Mac OSx, Linux, run this to get 1000+ digits of PI:

time echo "scale = 1010; 16 * a(1/5) - 4 * a(1/239)" |bc -lq



scale sets the precision,  -lq  loads the math library arctan() quiet.


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

Re: learnpython.org - an online interactive Python tutorial

[harrismh777]

Steven D'Aprano wrote:

If that's a "serious" flaw, it's a flaw shared by the vast majority of
programming languages.


   Yes, agreed.


As for the question of "consistency", I would argue the opposite: that
auto-promoting strings to numbers arguably is useful, but that is what is
inconsistent, not the failure to do so.


   I see your point...  but I'll push back just a little, in a minute...



Consider...

"one" + 1

"[1, 2, 3]" + [4]

"[2, 40, 10, 3]".sort()


   Yes, maybe problems all. Again, I see the point of your argument, 
and I do not necessarily disagree...


   I've been giving this some more thought. From the keyboard, all I am 
able to enter are character strings (not numbers). Presumably these are 
UTF-8 strings in python3.  If I enter the character string  57  then 
python converts my character string input and returns an reference to 
object 57.  If I enter the keyboard character string 34567 then the 
python interpreter converts my character string input into an object 
(creates a new object) (34567) returning a reference to that object (a 
type int). If I enter the keyboard character string 3.14 the python 
interpreter creates a float object (converts my string into a float) and 
returns a reference to the object. In any event, keyboard character 
strings that just happen to be numbers, are converted into int or float 
objects by the interpreter, from the keyboard, automatically.
   My idea for consistency is this: since the interpreter converts int 
to float, and float to imaginary (when needed), then it does (at least 
in a limited way) type promoting. So, it is consistent with the input 
methods generally to promote numeric string input to int --> float --> 
imaginary, as needed, therefore it is also consistent to promote a 
numeric string (that which I used to call a REXX number) into an int --> 
float --> imaginary, as implied by the statement(s). I am not asking for 
weak typing generally... nor am I thinking that all promotions are a 
good thing... just numeric string to int --> float --> imaginary when it 
makes sense. In any event, the programmer should be able to overide the 
behavior explicitly. On the other hand, I do see your point regarding 
performance. Otherwise,...


   ... type promotions really would not cause any more confusion for 
programmers who now know that int will be converted to float and use 
that knowledge conveniently


   I do believe that explicit is better than implicit (generally)... 
but not in this case. I am noticing a pattern in some of the responses, 
and that pattern is that some folks would find this appealing if not 
overtly convenient. The question IS, which I am not able to answer at 
this point, whether the convenience would actually cause other 
difficulties that would be worse...?



kind regards,
m harris




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

Re: Closing generators

[Thomas Rachel]

Am 23.04.2011 04:15, schrieb Terry Reedy:


.close() methods that release operating system resources are needed
*because* there is no guarantee of immediate garbage collection. They
were not needed when CPython was the only Python. The with statement was
added partly to make it easier to make sure that .close() was called.


I was already aware that "with:" saves me a "finally: close(...)" and 
replaces the "try:" line by a slightly more complicated line, but seen 
on the whole it is much better memorizable.


I really like "with" and use it wherever sensible and practical.



But in these (admittedly rarely) cases, it is better practice to close
explicitly, isn't it?


If by 'rare case' you mean a generator that opens a file or socket, or
something similar, then yes. One can think of a opened file object as an
iterator (it has __iter__ and __next__) with lots of other methods.


Oh, ok. I never thought about it in that way - and it is not exactly the 
same: a file object already has its __enter__ and __exit__ methods which 
serves to avoid using closing(), while a generator object misses them.


But thanks for pointing out that it is only necessary in generators who 
do "necessary" cleanup things while reacting to GeneratorExit or in 
their finally. Then a programmer should propagate exactly such 
generators (or their generating functions) not "as they are", but as 
context manager objects which yield a generator which is to be closed 
upon exit[1].



Instead of writing such a generator, though, I might consider an
iterator class with __enter__ and __exit__ methods so that it was also a
with-statement context manager, just like file objects and other such
things, so that closing would be similarly automatic. Or easier:

from contextlib import closing


Yes, I mentionned that in the original posting, and I think my question 
is answered as well now - unlike file objects, generators were not 
designed to have a __enter__/__exit__ by themselves, but instead require 
use of closing() probably due to the fact that this feature is needed so 
rarely (although it would have been nice to have it always...).



Thanks for the answers,

Thomas

[1] Maybe in this way:

class GeneratorClosing(object):
"""Take a parameterless generator functon and make it a context
manager which yields a iterator on each with: invocation. This
iterator is supposed to be used (once, clearly) inside the with:
and automatically closed on exit. Nested usage is supported as
well."""
def __init__(self, gen):
self._iter = gen
self._stack = []
def __enter__(self):
it = iter(self._iter())
self._stack.append(it) # for allowing nested usage...
return it
def __exit__(self, *e):
self._stack.pop(-1).close() # remove and close last element.

(which even can be used as a decorator to such a generator function, as 
long as it doesn't take arguments).


So I can do

@GeneratorClosing
def mygen():
try:
yield 1
yield 2
finally:
print "cleanup"

and then use

with mygen as it:
for i in it: print i
# Now, have the __enter__ call the generator function again in order to
# produce a new generator.
with mygen as it:
for i in it: print i

and be sure that cleanup happens for every generator created in that way.
--
http://mail.python.org/mailman/listinfo/python-list

Question about compiling python 30 from subversion repository on OSX

[Anthony Kong]

Hi, all,

I have checked out source code from this url 
http://svn.python.org/projects/python/branches/py3k, then run

./configure  --with-universal-archs=64-bit
make

First of all, I got this message:

---
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
Usually, copying Modules/Setup.dist to Modules/Setup will work.
---

Then the build failed with these messages

/usr/bin/ranlib: file: libpython3.3m.a(dynamic_annotations.o) has no symbols
/usr/bin/ranlib: file: libpython3.3m.a(pymath.o) has no symbols
ranlib libpython3.3m.a
ranlib: file: libpython3.3m.a(dynamic_annotations.o) has no symbols
ranlib: file: libpython3.3m.a(pymath.o) has no symbols
gcc   -framework CoreFoundation -o python.exe Modules/python.o libpython3.3m.a 
-ldl  -framework CoreFoundation
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "/Users/antkong/wd/python/python3/Lib/io.py", line 60, in 
/bin/sh: line 1: 55310 Abort trap  CC='gcc' LDSHARED='gcc -bundle 
-undefined dynamic_lookup  ' OPT='-DNDEBUG -g -fwrapv -O3 -Wall 
-Wstrict-prototypes' ./python.exe -E ./setup.py build
make: *** [sharedmods] Error 134


I wonder what caused these error messages. Is it possible that I am checking 
out the wrong branch?

The 3.2 branch (http://svn.python.org/projects/python/branches/release32-maint) 
can be compiled without much issue.


Cheers



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

Re: Question about compiling python 30 from subversion repository on OSX

[Ned Deily]

In article 
,
 Anthony Kong  wrote:
> I have checked out source code from this url 
> http://svn.python.org/projects/python/branches/py3k, then run
> 
> ./configure  --with-universal-archs=64-bit
> make
> 
> First of all, I got this message:
> 
> ---
> Modules/Setup.dist is newer than Modules/Setup;
> check to make sure you have all the updates you
> need in your Modules/Setup file.
> Usually, copying Modules/Setup.dist to Modules/Setup will work.
> ---
> 
> Then the build failed with these messages
> 
> /usr/bin/ranlib: file: libpython3.3m.a(dynamic_annotations.o) has no symbols
> /usr/bin/ranlib: file: libpython3.3m.a(pymath.o) has no symbols
> ranlib libpython3.3m.a
> ranlib: file: libpython3.3m.a(dynamic_annotations.o) has no symbols
> ranlib: file: libpython3.3m.a(pymath.o) has no symbols
> gcc   -framework CoreFoundation -o python.exe Modules/python.o 
> libpython3.3m.a -ldl  -framework CoreFoundation
> Could not find platform dependent libraries 
> Consider setting $PYTHONHOME to [:]
> Fatal Python error: Py_Initialize: can't initialize sys standard streams
> Traceback (most recent call last):
>   File "/Users/antkong/wd/python/python3/Lib/io.py", line 60, in 
> /bin/sh: line 1: 55310 Abort trap  CC='gcc' LDSHARED='gcc -bundle 
> -undefined dynamic_lookup  ' OPT='-DNDEBUG -g -fwrapv -O3 -Wall 
> -Wstrict-prototypes' ./python.exe -E ./setup.py build
> make: *** [sharedmods] Error 134
> 
> 
> I wonder what caused these error messages. Is it possible that I am checking 
> out the wrong branch?

Python development has recently moved from using Subversion to Mercurial 
(hg).  The py3k branch in the svn repository at that URL is now frozen 
in-time and not being updated.

$ svn info
Path: .
URL: http://svn.python.org/projects/python/branches/py3k
Repository Root: http://svn.python.org/projects
Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771
Revision: 88828
Node Kind: directory
Schedule: normal
Last Changed Author: giampaolo.rodola
Last Changed Rev: 88761
Last Changed Date: 2011-03-06 13:04:47 -0800 (Sun, 06 Mar 2011)

Information on how to access the hg repos is contained in the new Python 
Developer's Guide:

   http://docs.python.org/devguide/setup.html

If you use hg to clone a copy of the current repo, you'll see something 
more like this:

$ hg clone http://hg.python.org/cpython
$ cd cpython
$ hg log -b default
changeset:   69534:020ebe0be33e
user:Antoine Pitrou 
date:Sat Apr 23 17:56:06 2011 +0200
summary: Remove unused private function

Try the build again from a clean directory using the current hg repo.  
That said, if the message appears, follow the directions about copying 
Modules/Setup.dist to Modules/Setup.  That is likely the source of your 
original build failure.

> The 3.2 branch 
> (http://svn.python.org/projects/python/branches/release32-maint) can be 
> compiled without much issue.

That is out-of-date as well.  All current development and maintenance 
branches (2.7, 3.1, 3.2, default(=py3k)) are now maintained in the hg 
repo as described in the developer's guide.

-- 
 Ned Deily,
 n...@acm.org

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