Re: [Python-Dev] Announcing PEP 3136

[Karen Tracey]

At 05:15 PM 9/30/2009, Yuvgoog Greenle wrote:
I like how python has a minimalistic and powerful syntax (-1 for the 
break ___ PEP).


Also, I really dislike the for/else ambiguity "butterflies".

When is the else after a loop executed?
1. When the loop isn't entered at all.
2. When the loop terminates through exhaustion of the list (does 
this include when the list was empty?)

3. When the loop didn't exit because of a break statement.

HINTS: The way django does it is opposite the way python does it and 
there may be more than one correct answer.


Django's template language does not have for/else, it has for/empty: 
http://docs.djangoproject.com/en/dev/ref/templates/builtins/#for-empty


This construct did come from an external snippet that used 'else' 
instead of 'empty'.  However when it was integrated into Django the 
'else' name was specifically rejected because it did the opposite of 
what for/else does in Python.


Karen

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

Re: [Python-Dev] Announcing PEP 3136

[Karen Tracey]

On Wed, Sep 30, 2009 at 5:15 PM, Yuvgoog Greenle wrote:

> I like how python has a minimalistic and powerful syntax (-1 for the break
> ___ PEP).
> Also, I really dislike the for/else ambiguity "butterflies".
> When is the else after a loop executed? 1. When the loop isn't entered at
> all.
> 2. When the loop terminates through exhaustion of the list (does this
> include when the list was empty?)
> 3. When the loop didn't exit because of a break statement.
>
> HINTS: The way django does it is opposite the way python does it and there
> may be more than one correct answer.
>
>
Django's template language does not have for/else, it has for/empty:
http://docs.djangoproject.com/en/dev/ref/templates/builtins/#for-empty

This construct did come from an external snippet that used 'else' instead of
'empty'.  However when it was moved into Django the 'else' name was
specifically rejected because it did the opposite of what for/else does in
Python.

Karen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] nonlocal keyword in 2.x?

[Karen Tracey]

On Thu, Oct 22, 2009 at 5:51 PM, "Martin v. Löwis" wrote:

> > From the Django roadmap for supporting 3.0, using 2.6 as a stepping
> > stone (and if 2.7 was a *better* stepping stone then it would make it
> > easier):
> >
> >http://groups.google.com/group/django-developers/msg/0888b1c8f2518059
> ?
>
> Is that still a current plan? It's from November 2008.
>
>
Django 1.1 came out in 2H09, not 1H09, and Django 1.2 is now looking to come
out in 1H10, not 2H09, so the dates in that note have slipped out by 3-6
months. (The labeling of some features as must-have for a release has been
dropped for 1.2, so as to hopefully prevent the kind of slip seen with
1.1.)  Django 1.2 is still scheduled to drop Python 2.3 support. I think
it's too early to say whether Python 2.4 support will be dropped with 1.3,
nor do I have any good idea when supporting 3.x will become a priority.

Karen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Issue 3745 backwards incompatibility

[Karen Tracey]

In testing some existing code with the 2.7 alpha release, I've run into:

TypeError: Unicode-objects must be encoded before hashing

when the existing code tries to pass unicode objects to hashlib.sha1 and
hashlib.md5.  This is, I believe, due to changes made for issue 3745:

http://bugs.python.org/issue3745

The issue states the need to reject unencoded strings based on the fact that
one backend implementation (openssl) refused to accept them while another
(_sha256) assumed a utf-8 encoding.  The thing is, I cannot observe any such
difference using Python 2.5 or 2.6.  Instead of what is shown in the ticket
(which was done on a Python 3, I believe) I see, when I adjust the demo test
to use Python 2 syntax for "unencoded strings":

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import _hashlib
>>> _hashlib.openssl_sha256(u"\xff")
Traceback (most recent call last):
  File "", line 1, in 
UnicodeEncodeError: 'ascii' codec can't encode character u'\xff' in position
0: ordinal not in range(128)
>>> import _sha256
>>> _sha256.sha256(u'\xff')
Traceback (most recent call last):
  File "", line 1, in 
UnicodeEncodeError: 'ascii' codec can't encode character u'\xff' in position
0: ordinal not in range(128)
>>>

(Sample from Windows because that's the only place I can get import _sha256
to work.  The Ubuntu Linux I tried behaves the same way as above for the
_hashlib version, while it doesn't appear to have _sha256 as an option.)

So from what I can see the behavior wasn't inconsistent from
backend-to-backend in Python 2 but rather fell in line with what I'm
familiar with: if you pass unicode to some code that only wants bytes, the
unicode object will get encoded to a bytestring using the system default
encoding. No problems if the data can in fact always be encoded using that
encoding, the error above if the data can't be encoded. Changing these
functions to now require the caller to do the encoding explicitly ahead of
time strikes me as introducing an inconsistency. Plus it introduces a
backwards incompatibility in Python 2.7.  Is this really necessary?

Karen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2

[Karen Tracey]

On Sat, Jan 9, 2010 at 12:29 PM, Benjamin Peterson wrote:

> On behalf of the Python development team, I'm gleeful to announce the
> second
> alpha release of Python 2.7.
>
>
Well yay.  Django's test suite (1242 tests) runs with just one failure on
the 2.7 alpha 2 level, and that looks to be likely due to the improved
string/float rounding so not really a problem, just a difference.  That's
down from 104 failures and 40 errors with 2.7 alpha 1.

Note on the website page http://www.python.org/download/releases/2.7/ the
"Change log for this release" link is still pointing to the alpha 1
changelog.

Thanks,
Karen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

[Karen Tracey]

On Fri, Jan 22, 2010 at 7:38 AM, Michael Foord wrote:

> On 21/01/2010 21:21, "Martin v. Löwis" wrote:
>
>> Where the default *file system encoding* is used (i.e. text files are
>>> written or read without specifying an encoding)
>>>
>>>
>> I think you misunderstand the notion of the *file system encoding*.
>> It is *not* a "file encoding", but the file *system* encoding, i.e.
>> the encoding for file *names*, not for file *content*.
>>
>> It was used on Windows for Windows 95; it is not used anymore on Windows
>> (although it's still used on Unix).
>>
>>
>
> Ok, I'm just using the wrong terminology. I'm aware that mbcs is used for
> filename encoding on Windows (right?). The encoding I'm talking about is the
> encoding that Python uses to decode a file (or encode a string) when you do
> the following in Python 3:
>
>text = open(filename).read()
>open(filename, 'w').write(some_string)
>
> It isn't the default encoding (always utf-8 by default in Python 3
> apparently), it isn't the file system encoding which is the system encoding
> used for file names. What is the correct terminology for this platform
> dependent encoding that Python uses here?
>
>
The doc here:
http://docs.python.org/3.1/library/functions.html?highlight=open#open just
calls it default encoding and clarifies that is "whatever
locale.getpreferredencoding() returns".

The important point is that it is platform dependent - so if you ship and
> use text files with your Python application and don't specify an encoding
> then it will work fine on some platforms and blow up or use the wrong
> encoding on other platforms.
>
>
Yes. If you ship text files with your Python application, then you'd best
take care to know the encoding when you create them and specify it as the
encoding to use when you open the file for reading by your application.

Karen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

[Karen Tracey]

On Fri, Jan 22, 2010 at 9:22 AM, Michael Foord wrote:

>  On 22/01/2010 14:18, Karen Tracey wrote:
>
>
> The doc here:
> http://docs.python.org/3.1/library/functions.html?highlight=open#open just
> calls it default encoding and clarifies that is "whatever
> locale.getpreferredencoding() returns".
>
>
> Heh, so we have two different encoding mechanisms both called "default
> encoding". One is always utf-8 in Python 3 and one is platform dependent...
> Great. :-)
>

Well to be fair the the doc is describing the default value for the
parameter named encoding, so its reference to "default encoding" should not
be extrapolated to mean the default encoding for Python 3 overall. I worded
that sentence above poorly. But yes, it is easy to get confused here.

Karen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Breaking undocumented API

[Karen Tracey]

On Thu, Nov 11, 2010 at 6:51 AM, Michael Foord wrote:

> On 10/11/2010 15:48, R. David Murray wrote:
>
>> I think Tres was referring to certain packages (which shall remain
>> nameless since I don't feel like googling to find one) whose
>> documentation recommends the 'from  import *' methodology.
>>
>
> Contenders include popular libraries like fabric and django:
>
> http://docs.fabfile.org/0.9.2/usage/fabfiles.html
> http://docs.djangoproject.com/en/1.2/intro/tutorial03/
>
>
That is one very specific module in Django that gets imported that way, it
is not a general pattern recommended by Django. For every other Django
module besides that one you will see specific imports being used in the doc.

Karen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Change in repr of Decimal in 2.6

[Karen Tracey]

[Originally posted to python-list but on further reflection and some
feedback I think it might be more appropriate here.]

I noticed when trying out Python's 2.6b2 release that the repr of Decimal
has changed since 2.5.  On 2.5:

Python 2.5.1 (r251:54863, Mar  7 2008, 04:10:12)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import decimal
>>> decimal.Decimal(7)
Decimal("7")
>>>

double quotes were used whereas on 2.6b2:

Python 2.6b2 (r26b2:65082, Jul 18 2008, 13:36:54)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import decimal
>>> decimal.Decimal(7)
Decimal('7')
>>>

single quotes are used.  Searching around I see this was done in r60773 with
the log message:

Fix decimal repr which should have used single quotes like other reprs.

but I can't find any discussion other than that.

My problem is this breaks a bunch of doctests that were written assuming the
prior repr.  I can't just update the tests to assume the new single quotes
because they are for code that is supposed to run on everything back to
Python 2.3.

So my questions:

Is this backwards-incompatible change really necessary and could it be
reconsidered?

If it's here to stay, is there some straightforward way that I am unaware of
to construct tests that use Decimal repr but will work correctly on Python
2.3-2.6?

Thanks for any feedback,
Karen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fwd: Change in repr of Decimal in 2.6

[Karen Tracey]

Meant to copy list on reply, sorry.

-- Forwarded message --
From: Karen Tracey <[EMAIL PROTECTED]>
Date: Fri, Jul 18, 2008 at 11:48 PM
Subject: Re: [Python-Dev] Change in repr of Decimal in 2.6
To: Raymond Hettinger <[EMAIL PROTECTED]>


On Fri, Jul 18, 2008 at 11:19 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:

> From: Karen Tracey
>
>> I noticed when trying out Python's 2.6b2 release that the repr of Decimal
>> has changed since 2.5.  On 2.5:
>>
> ...
>
>>  quotes were used whereas on 2.6b2:
>>
> ...
>
>> single quotes are used.  Searching around I see this was done in r60773
>> with the log message:
>> Fix decimal repr which should have used single quotes like other reprs.
>>
>> but I can't find any discussion other than that.
>>
>
> Guido requested this change so that the Decimal repr would match the style
> used elsewhere (i.e. str(7) --> '7').
>

Thanks for the background.  Can't say I ever noticed the inconsistency
myself.


>
>  If it's here to stay, is there some straightforward way that I am unaware
>> of to construct tests that use Decimal repr but will work correctly on
>> Python 2.3-2.6?
>>
>
> A quick hack is to monkey patch the decimal module:
>
>   >>> import decimal
>   >>> decimal.Decimal.__repr__ = lambda s: 'Decimal("%s")' % str(s)
>

That is quick, but does seem hackish.


> A better fix is to amend to doctests to not rely on the __repr__ format.
> Instead of:
>
>  >>> Decimal('7.1')
>  Decimal("7.1")
>
> use:
>
>  >>> print Decimal('7.1')
>  7.1
>

Yeah, but the testcases are not quite that simple.  They're often testing
return values from functions and as much verifying that the type is correct
as the value, so I think I'd have to change stuff like:

>>> f.clean('1')
Decimal("1")

to:

>>> x = f.clean('1')
>>> print type(x), x
 1

right?

Thanks for the answer,
Karen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Change in repr of Decimal in 2.6

[Karen Tracey]

On Fri, Jul 18, 2008 at 11:55 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> This is an example of the problem with doctest -- it's easy to
> overspecify the tests. I don't think that whether the repr() of a
> Decimal uses single or double quotes should be considered a spec cast
> in stone by doctests.
>

OK, but I'm just thinking of all the places in tests we have stuff like:

>>> var.method(params)
expected_repr_of_return_value

We should really be doing something else to guard against a potential future
change in repr of whatever it is?

Thanks,
Karen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fwd: Change in repr of Decimal in 2.6

[Karen Tracey]

On Sat, Jul 19, 2008 at 10:52 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:

> >>> f.clean('1') == Decimal('1')
> True
>

Ah, yes, why didn't I think of that?


>
> Since 'True' is a keyword, and Guido is *very* reluctant to even add
> keywords, let alone change their spelling, I think you can depend on that
> working indefinitely.  Similarly, if you now have
>
> >>> type(a)
> 
>
> you test will fail in 3.0 which instead prints '.  But
>
> >>>type(a) is int
> True
>
> will continue working.
>
> Doctest has two quite different uses.  One is to check text with
> interactive examples to make sure there are no mistakes in the examples.
>  For that, printing representations is usually the natural style.  Then one
> must accept that representations change faster that object behavior.
>
> The other use is to check code.  For that, the more stilted  style is more
> future-proof.  For text doing double duty as a formal reference and code
> test, I would go for cross-version dependability.
>
>
Thanks, I see your point about the different styles.   I think we have a
fair number of tests that use the print-style (probably because that's
easiest, and then people see that style everywhere and do the same when
adding new tests) when to be future proof they really should be using the
alternative.

Karen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] should list's call to __len__ swallow SystemExit?

[Karen Tracey]

On Wed, Jan 14, 2009 at 6:12 AM, Nick Coghlan  wrote:

> Dino Viehland wrote:
> > We had a bug reported that effectively boils down to we're not
> > swallowing exceptions when list calls __len__
> > (
> http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=20598
> ).
> >
> >
> > We can obviously make the change to catch exceptions here in
> > IronPython even if it seems like a bad idea to me ☺  But CPython
> > seems to catch not only normal exceptions, but also SystemExit.  It
> > seems like there's been a move away from this so I thought I'd
> > mention it here.  I tested it on 2.6.1 and 3.0.
>
> I'd agree that CPython appears to be the one misbehaving here, rather
> than IronPython.
>
> Opening a new issue at bugs.python.org would be the best way forward.
>

There is already a bug for this, I believe:

http://bugs.python.org/issue1242657

Karen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com