Re: [Python-Dev] Rules for the Tools directory

[Nick Coghlan]

Brett Cannon wrote:
> 
> 
> On Fri, Dec 4, 2009 at 17:20, Antoine Pitrou  > wrote:
> 
> Hello,
> 
> I was going to suggest adding ccbench and iobench to the Tools
> directory,
> so I wonder whether there are any rules for putting stuff there?
> 
> 
> Much like the Demos directory, there are no rules.

I wouldn't go quite that far - while those directories aren't controlled
in the same way as the interpreter and the standard library, there's
still the fact that this is code that the PSF will end up redistributing.

That means the basic rules for any checkin still apply:
- PSF must have the necessary legal rights to redistribute the code
(usually via a Contributor Agreement)
- code should be of good quality

At least checking for objections on python-dev first is probably a good
idea as well (in this case, I think both ccbench and iobench make good
additions).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] Sort out formatting differences in decimal and float

[Stefan Krah]

Hi,

I'm in the process of implementing formatting in my C-decimal module.
Since testing is quite time consuming, I would appreciate a binding
decision on how the following should be formatted:

>>> from decimal import *
>>> format(float(1234), '020,g')
'0,000,000,000,001,234'
>>> format(float(1234), '0=20,g')
'0,000,000,000,001,234'
>>> 
>>> format(Decimal(1234), '020,g')
'0,000,000,000,001,234'
>>> format(Decimal(1234), '0=20,g')
'0001,234'

>>> format(Decimal('nan'), '020,g')
' NaN'
>>> format(Decimal('nan'), '0=20,g')
'0NaN'


You can see that float literally follows PEP-3101:

"If the width field is preceded by a zero ('0') character, this enables
 zero-padding.  This is equivalent to an alignment type of '=' and a
 fill character of '0'."


The advantage of decimal is that the user has the option to suppress
commas. The behaviour of float is slightly easier to implement in C.


So the options are:

   a) 020 is always equivalent to 0=20

   b) 020 is not always equivalent to 0=20



Stefan Krah


___
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] Sort out formatting differences in decimal and float

[Mark Dickinson]

On Sat, Dec 5, 2009 at 11:18 AM, Stefan Krah  wrote:
> Hi,
>
> I'm in the process of implementing formatting in my C-decimal module.
> Since testing is quite time consuming, I would appreciate a binding
> decision on how the following should be formatted:
>
 from decimal import *
 format(float(1234), '020,g')
> '0,000,000,000,001,234'
 format(float(1234), '0=20,g')
> '0,000,000,000,001,234'

 format(Decimal(1234), '020,g')
> '0,000,000,000,001,234'
 format(Decimal(1234), '0=20,g')
> '0001,234'

I like the Decimal behaviour better, but then I might be a little biased.  :-)

I find it odd that, for float formatting, the choice of fill character
affects whether commas are inserted:

Python 3.2a0 (py3k:76671, Dec  4 2009, 18:55:54)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> format(float(1234), '0=20,g')
'0,000,000,000,001,234'
>>> format(float(1234), '1=20,g')
',234'
>>> format(float(1234), 'X=20,g')
'XXX1,234'

Mark
___
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] Sort out formatting differences in decimal and float

[skip]

Sorry for being a curmudgeon, however...

>>> format(Decimal(1234), '020,g')
'0,000,000,000,001,234'
>>> format(Decimal(1234), '0=20,g')
'0001,234'

Why in the world would you ever want to insert commas as separators and not
use them consistently?

>>> format(Decimal('nan'), '020,g')
' NaN'
>>> format(Decimal('nan'), '0=20,g')
'0NaN'

Why in the world would you ever want to zero pad Nan (or Inf, for that matter)?

Stefan> The advantage of decimal is that the user has the option to
Stefan> suppress commas. The behaviour of float is slightly easier to
Stefan> implement in C.

Why?  If the user asked for them why would you want to suppress (some of)
them?

Skip
___
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] Sort out formatting differences in decimal and float

[Daniel Fetchinson]

> Sorry for being a curmudgeon, however...
>
> >>> format(Decimal(1234), '020,g')
> '0,000,000,000,001,234'
> >>> format(Decimal(1234), '0=20,g')
> '0001,234'
>
> Why in the world would you ever want to insert commas as separators and not
> use them consistently?
>
> >>> format(Decimal('nan'), '020,g')
> ' NaN'
> >>> format(Decimal('nan'), '0=20,g')
> '0NaN'
>
> Why in the world would you ever want to zero pad Nan (or Inf, for that
> matter)?

Because you didn't know in advance that the number ending up in your
format call was a nan (or inf)?

Cheers,
Daniel

> Stefan> The advantage of decimal is that the user has the option to
> Stefan> suppress commas. The behaviour of float is slightly easier to
> Stefan> implement in C.
>
> Why?  If the user asked for them why would you want to suppress (some of)
> them?



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
___
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] Sort out formatting differences in decimal and float

[Mark Dickinson]

On Sat, Dec 5, 2009 at 1:18 PM,   wrote:
>
>    >>> format(Decimal(1234), '020,g')
>    '0,000,000,000,001,234'
>    >>> format(Decimal(1234), '0=20,g')
>    '0001,234'
>
> Why in the world would you ever want to insert commas as separators and not
> use them consistently?

So should commas be inserted for any fill character at all?  Or should
only '0' be special-cased?  What about other digits used as fill characters?
What about other non-ascii zeros?  Should those be special-cased too?

I'm reluctant to add extra special cases and complication to what's
already quite a complicated specification;  it seems better to keep
it simple (well, as simple as possible) and orthogonal.

There's already a good way to ask for zero padding, by using the leading
zero, as in '020,g'.  Why would you use '0=20,g' instead?  I'm not sure
that the 'X=...' notation was intended to be used for zero padding.

Mark
___
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] Sort out formatting differences in decimal and float

[Eric Smith]

Mark Dickinson wrote:

I find it odd that, for float formatting, the choice of fill character
affects whether commas are inserted:

Python 3.2a0 (py3k:76671, Dec  4 2009, 18:55:54)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

format(float(1234), '0=20,g')

'0,000,000,000,001,234'

format(float(1234), '1=20,g')

',234'

format(float(1234), 'X=20,g')

'XXX1,234'


I haven't spent a lot of time looking at it, but this might be related 
to http://bugs.python.org/issue6902 .


I'll move this up in my queue.

Eric.

___
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] Sort out formatting differences in decimal and float

[skip]

Mark> So should commas be inserted for any fill character at all? 

While I'm at it, it makes no sense to me to pad numbers with anything other
than whitespace or zero.  (BTW: I have never liked the new format() stuff,
so I will be sticking with %-formatting as long as it exists in Python.  My
apologies if I don't understand some amazing generality about format(), but
if you do dumb stuff like ask for comma separation of a number then ask to
pad it with '*' you get what you deserve.)

Mark> There's already a good way to ask for zero padding, by using the
Mark> leading zero, as in '020,g'.  Why would you use '0=20,g' instead?

Note to the implementers: '0=20,g' has no mnemonic significance as far as I
can tell.  I thought it was my mail program failing to properly decode a bit
of quoted printable text.

Skip
___
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] [RELEASED] Python 2.7 alpha 1

[Benjamin Peterson]

On behalf of the Python development team, I'm pleased to announce the first
alpha release of Python 2.7.

Python 2.7 is scheduled to be the last major version in the 2.x series.  It
includes many features that were first released in Python 3.1.  The faster io
module, the new nested with statement syntax, improved float repr, and the
memoryview object have been backported from 3.1. Other features include an
ordered dictionary implementation, unittests improvements, and support for ttk
Tile in Tkinter.  For a more extensive list of changes in 2.7, see
http://doc.python.org/dev/doc/whatsnew/2.7.html or Misc/NEWS in the Python
distribution.  Please note that this is a development release, intended as a
preview of new features for the community, and is thus not suitable for
production use.

To download Python 2.7 visit:

 http://www.python.org/download/releases/2.7/

The 2.7 documentation can be found at:

 http://docs.python.org/2.7

Please consider trying Python 2.7 with your code and reporting any bugs you may
notice to:

 http://bugs.python.org


Have fun!

--
Benjamin Peterson
Release Manager
benjamin at python.org
(on behalf of the entire python-dev team and 2.7's contributors)
___
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 1

[Benjamin Peterson]

My apologies. The whatsnew link is actually
http://docs.python.org/dev/whatsnew/2.7.

2009/12/5 Benjamin Peterson :
> On behalf of the Python development team, I'm pleased to announce the first
> alpha release of Python 2.7.



-- 
Regards,
Benjamin
___
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 1

[Scott Dial]

Benjamin Peterson wrote:
> On behalf of the Python development team, I'm pleased to announce the first
> alpha release of Python 2.7.

Was there a call for bugs that should be reviewed for this release?

I once again will prod for attention to this show-stopping bug for using
IMAP-SSL:

http://bugs.python.org/issue5949
Title: IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

-- 
Scott Dial
sc...@scottdial.com
scod...@cs.indiana.edu
___
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 1

[Brett Cannon]

On Sat, Dec 5, 2009 at 10:55, Scott Dial

> wrote:

> Benjamin Peterson wrote:
> > On behalf of the Python development team, I'm pleased to announce the
> first
> > alpha release of Python 2.7.
>
> Was there a call for bugs that should be reviewed for this release?
>
>
No. Since this is an alpha release this is more about discovering new bugs
than than trying to make sure we have everything squashed. When we approach
the first beta release is when I would start pressing on getting key bugs
fixed.

-Brett



> I once again will prod for attention to this show-stopping bug for using
> IMAP-SSL:
>
> http://bugs.python.org/issue5949
> Title: IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
>
> --
> Scott Dial
> sc...@scottdial.com
> scod...@cs.indiana.edu
> ___
> 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/brett%40python.org
>
___
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] Sort out formatting differences in decimal and float

[Nick Coghlan]

s...@pobox.com wrote:

>  My
> apologies if I don't understand some amazing generality about format()

>>> format("Header", '=^20s')
'===Header==='

>>> "Format a single object {0!r}, multiple times in a single string.
Year: {0.year}; Month: {0.month}; Day: {0.day}; Formatted:
{0:%Y-%M-%d}".format(datetime.now())
'Format a single object datetime.datetime(2009, 12, 6, 9, 16, 0,
875018), multiple times in a single string. Year: 2009; Month: 12; Day:
6; Formatted: 2009-16-06'

>>> "Use keyword arguments easily: {x}, {y}, {z}".format(x=1, y=2, z=3)
'Use keyword arguments easily: 1, 2, 3'

For the things that mod formatting already allows you to do, our aim is
to get format() functionality at least on par with what mod formatting
supports (it should be most of the way there with the number formatting
cleanups for 2.7/3.2). For the rest of the features (explicit position
references, centre alignment, arbitrary fill characters, attribute and
subscript references, type defined formatting control), mod formatting
isn't even in the game.

Getting rid of the magic behaviour associated with the use of tuples on
the right hand side is also valuable:

>>> "%s" % (1, 2)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: not all arguments converted during string formatting
>>> "{}".format((1, 2))
'(1, 2)'

Developers that are already used to the limitations of mod formatting
are expected to take some time to decide if they care about the extra
features offered by the format method, but for new developers it should
be an easy choice.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] Sort out formatting differences in decimal and float

[Terry Reedy]

Nick Coghlan wrote:

s...@pobox.com wrote:


 My
apologies if I don't understand some amazing generality about format()



format("Header", '=^20s')

'===Header==='


"Format a single object {0!r}, multiple times in a single string.

Year: {0.year}; Month: {0.month}; Day: {0.day}; Formatted:
{0:%Y-%M-%d}".format(datetime.now())
'Format a single object datetime.datetime(2009, 12, 6, 9, 16, 0,
875018), multiple times in a single string. Year: 2009; Month: 12; Day:
6; Formatted: 2009-16-06'


"Use keyword arguments easily: {x}, {y}, {z}".format(x=1, y=2, z=3)

'Use keyword arguments easily: 1, 2, 3'

For the things that mod formatting already allows you to do, our aim is
to get format() functionality at least on par with what mod formatting
supports (it should be most of the way there with the number formatting
cleanups for 2.7/3.2). For the rest of the features (explicit position
references, centre alignment, arbitrary fill characters, attribute and
subscript references, type defined formatting control), mod formatting
isn't even in the game.

Getting rid of the magic behaviour associated with the use of tuples on
the right hand side is also valuable:


"%s" % (1, 2)

Traceback (most recent call last):
  File "", line 1, in 
TypeError: not all arguments converted during string formatting

"{}".format((1, 2))

'(1, 2)'


A nice demonstration of what an excellent piece of work the new .format 
is or is becoming. I would still like it to be a goal for 3.2 that all 
stdlib modules that work with formats accept the new formats and not 
just % formats.


Mark Summerfield only covered .format in his book on Python 3 programimg 
and I hated to tell him that there was at least one module in the stdlib 
that currently (3.1) requires the old style.


Terry Jan Reedy

___
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] Sort out formatting differences in decimal and float

[Nick Coghlan]

Terry Reedy wrote:
> A nice demonstration of what an excellent piece of work the new .format
> is or is becoming. I would still like it to be a goal for 3.2 that all
> stdlib modules that work with formats accept the new formats and not
> just % formats.
> 
> Mark Summerfield only covered .format in his book on Python 3 programimg
> and I hated to tell him that there was at least one module in the stdlib
> that currently (3.1) requires the old style.

Yes, we do need to do that. It would be nice if we could come up with a
cleaner solution than a proliferation of parallel APIs everywhere though :(

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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