Re: [Python-Dev] Python 3.0.1

[M.-A. Lemburg]

On 2009-01-29 01:59, Stephen J. Turnbull wrote:
> I think there is definitely something to the notion that the 3.x
> vs. 3.0.y distinction should signal something, and I personally like
> MAL's suggestion that 3.0.x should be marked some sort of beta in
> perpetuity, or at least until 3.1 is ready to ship as stable and
> production-ready.  (That's AIUI, MAL's intent may be somewhat
> different.)

That's basically it, yes.

I don't think that marking 3.0 as experimental is bad in any way,
as long as we're clear about it.

Having lots of incompatible changes in a patch level release will
start to get users worrying about the stability of the 3.x branch
anyway, so a heads-up message and clear perspective for the 3.1
release is a lot better than dumping 3.0 altogether or not
providing such a perspective at all.

That said, we should stick to the statement already made for
3.0 (too early as it now appears), ie. that the same development and
releases processes will apply to the 3.x branch as we have for 2.x -
starting with 3.1.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 29 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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] python breakpoint opcode

[Dr Andrew Perella]

Hi,

I was thinking of adding a breakpoint opcode to python to enable less
invasive debugging.

I came across posts from 1999 by Vladimir Marangozov and Christian Tismer
discussing this issue but the links to the code are all out of date.

Did anything come of this? Is this a good approach to take? - if so why was
this never incorporated?

 

Cheers,

Andrew 

 


Dr. Andrew Perella
Chief Software Architect


Eutechnyx Limited. Metro Centre East Business Park, Waterside Drive,
Gateshead, Tyne & Wear  NE11 9HU  UK   Co.Reg.No. 2172322 


T +44 (0) 191 460 6060   F +44 (0) 191 460 2266   E
 a...@eutechnyx.com   W
 www.eutechnyx.com



 


This e-mail is confidential and may be privileged. It may be read, copied
and used only by the intended recipient. No communication sent by e-mail to
or from Eutechnyx is intended to give rise to contractual or other legal
liability, apart from liability which cannot be excluded under English law.

 


This e-mail is confidential and may be privileged. It may be read, copied and 
used only by the intended recipient. No communication sent by e-mail to or from 
Eutechnyx is intended to give rise to contractual or other legal liability, 
apart from liability which cannot be excluded under English law. 

This email has been scanned for all known viruses by the Email Protection 
Agency. http://www.epagency.net


www.eutechnyx.com Eutechnyx Limited. Registered in England No: 2172322

___
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] mlockall() in Python?

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Evgeni Golov wrote:
> I'd like to write a small daemon in Python, which should never be
> swapped out (on Linux, this daemon will be Linux specific, so no need
> in a platform-independent solution).
> 
> In C I'd do:
> #include 
> mlockall(MCL_FUTURE);
> //do stuff here
> munlockall();
> 
> Is there anything similar in Python?

I would like things like this added to core python, but since you are
restricting yourself to linux, you can use a (trivial) ctypes wrapper.

- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSYGjQZlgi5GaxT1NAQIUMAP/Tl7SWFgVkeeEdRHbkrtlOX4eERbfny7A
xBkUVO72lPB1XnRxZT0+Vo2ggYh/6IHN6SQriEZZPe9Wwn3cZzirjjAqpdvb70TJ
1BezGtLKsoDp4cf6QqDwfITecMaGjfaNhKvvSvPFzaKlpbjsdQjyGCI0dOvxzY5J
6BUxE2yYJdc=
=N0dO
-END PGP SIGNATURE-
___
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] Examples in Py2 or Py3

[Facundo Batista]

Hi!

In the Python Argentina mail list there's already people passing
examples and asking help about Python 3.

This introduces the problem that some examples are in Py2 and others
are in Py3. Sometimes this is not explicit, and gets confusing. I'm
trying to avoid this confusion when preparing my own examples. So far,
I use (py3) as a prefix for any example block, like:

(Py3k)
>>> (some example)
(some result)

Is there any recommended way to avoid confusion in these cases? (I'm
thinking about changing the prompt in my Python installation, to
something like ">2>>" and ">3>>", to be explicit about it... but I
wanted to know if there's another better way)

Thanks.

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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] Examples in Py2 or Py3

[Senthil Kumaran]

> Facundo Batista  wrote:
> Hi!
>
> In the Python Argentina mail list there's already people passing
> examples and asking help about Python 3.

For complete snippets:
#!/usr/bin/env python3.0

vs
#!/usr/bin/env python2.6

And for blocks of code

# this for python 3.0
# this is for python 2.6

I know, it is very rudimentary, but I have followed snippets with
written these identifications.

-- 
Senthil
___
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] Examples in Py2 or Py3

[Facundo Batista]

2009/1/29 Senthil Kumaran :

> And for blocks of code
>
> # this for python 3.0
> # this is for python 2.6

Too much work, ;)

Seriously, most probably people will forgot to add that after the
third example...

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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] Partial function application 'from the right'

[Ben North]

Hi,

I find 'functools.partial' useful, but occasionally I'm unable to use it
because it lacks a 'from the right' version.  E.g., to create a function
which splits a string on commas, you can't say

   # Won't work when called:
   split_comma = partial(str.split, sep = ',')

and to create a 'log to base 10' function, you can't say

   # Won't work when called:
   log_10 = partial(math.log, base = 10.0)

because str.split and math.log don't take keyword arguments.

PEP-309, which introduces functools.partial, mentions

   For completeness, another object that appends partial arguments after
   those supplied in the function call (maybe called rightcurry) has
   been suggested.

'Completeness' by itself doesn't seem to have been a compelling reason
to introduce this feature, but the above cases show that it would be of
real use.

I've created a patch which adds a 'partial_right' function.  The two
examples above:

   >>> import functools, math

   >>> split_comma = functools.partial_right(str.split, ',')
   >>> split_comma('a,b,c')
   ['a', 'b', 'c']

   >>> log_10 = functools.partial_right(math.log, 10.0)
   >>> log_10(100.0)
   2.0

and a general illustrative one:

   >>> def all_args(*args): return args
   ...
   >>> functools.partial_right(all_args, 1, 2)(3, 4)
   (3, 4, 1, 2)

I was prompted to look at this by a recent message on python-dev:

Xavier Morel , Thu, 22 Jan 2009 14:44:41 +0100:
> [...] drop(iterable, n) has to be written islice(iterable, n, None)
> (and of course the naming isn't ideal), and you can't really use
> functools.partial since the iterator is the first argument (unless
> there's a way to partially apply only the tail args without kwargs).

Xavier's case becomes:

   >>> import functools, itertools
   >>> drop = functools.partial_right(itertools.islice, None, None)
   >>> list(drop(range(10), 5))
   [5, 6, 7, 8, 9]

The patch adds a 'from_right' member to partial objects, which can be
True for the new from-the-right behaviour, or False for the existing
from-the-left behaviour.  It's quite small, only c.40 lines, plus a
c.70-line change to test_functools.py.  I imagine a documention patch
would be c.20 lines.

Would there be any interest in this?

Ben.
___
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] pprint(iterator)

[Aahz]

On Tue, Jan 27, 2009, Raymond Hettinger wrote:
>
> It is becoming the norm in 3.x for functions to return iterators,
> generators, or views whereever possible.
>
> I had a thought that pprint() ought to be taught to print iterators:
>
>pprint(enumerate(seq))
>pprint(map(somefunc, somedata))
>pprint(permutations(elements))
>pprint(mydict.items())

Along the lines of what others have said: pprint() cannot consume an
unknown iterator.  Therefore, you can pretty up the existing output
slightly or special-case certain known iterators.  There might also be an
API change to pprint() that allowed it to consume iterators.

The reason I'm chiming in is that I would welcome a PEP that created a
__pprint__ method as an alternative to special-casing.  I think that it
would be generically useful for user-created objects, plus once you've
added this feature other people can easily do some of the grunt work of
extending this through the Python core.  (Actually, unless someone
objects, I don't think a PEP is required, but it would be good for the
usual reasons that PEPs are written, to provide a central place
documenting the addition.)

This can also be done for Python 2.7, too.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.
___
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] pprint(iterator)

[Michael Foord]

Aahz wrote:

On Tue, Jan 27, 2009, Raymond Hettinger wrote:
  

It is becoming the norm in 3.x for functions to return iterators,
generators, or views whereever possible.

I had a thought that pprint() ought to be taught to print iterators:

   pprint(enumerate(seq))
   pprint(map(somefunc, somedata))
   pprint(permutations(elements))
   pprint(mydict.items())



Along the lines of what others have said: pprint() cannot consume an
unknown iterator.  Therefore, you can pretty up the existing output
slightly or special-case certain known iterators.  There might also be an
API change to pprint() that allowed it to consume iterators.

The reason I'm chiming in is that I would welcome a PEP that created a
__pprint__ method as an alternative to special-casing.  I think that it
would be generically useful for user-created objects, plus once you've
added this feature other people can easily do some of the grunt work of
extending this through the Python core.  (Actually, unless someone
objects, I don't think a PEP is required, but it would be good for the
usual reasons that PEPs are written, to provide a central place
documenting the addition.)

This can also be done for Python 2.7, too.
  

Don't we have a pretty-print API - and isn't it spelled __str__ ?

Michael Foord

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
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] pprint(iterator)

[Aahz]

On Thu, Jan 29, 2009, Michael Foord wrote:
> Aahz wrote:
>> On Tue, Jan 27, 2009, Raymond Hettinger wrote:
>>   
>>> It is becoming the norm in 3.x for functions to return iterators,
>>> generators, or views whereever possible.
>>>
>>> I had a thought that pprint() ought to be taught to print iterators:
>>>
>>>pprint(enumerate(seq))
>>>pprint(map(somefunc, somedata))
>>>pprint(permutations(elements))
>>>pprint(mydict.items())
>>> 
>>
>> The reason I'm chiming in is that I would welcome a PEP that created a
>> __pprint__ method as an alternative to special-casing.  I think that it
>> would be generically useful for user-created objects, plus once you've
>> added this feature other people can easily do some of the grunt work of
>> extending this through the Python core.  (Actually, unless someone
>> objects, I don't think a PEP is required, but it would be good for the
>> usual reasons that PEPs are written, to provide a central place
>> documenting the addition.)
>   
> Don't we have a pretty-print API - and isn't it spelled __str__ ?

In theory, yes.  In practice, we wouldn't be having this discussion if
that really worked.  But it probably would make sense to see how far
using __str__ can take us -- AFAICT enumobject.c doesn't define __str__
(although I may be missing something, I don't know Python at the C level
very well).
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.
___
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] Examples in Py2 or Py3

[rdmurray]

On Thu, 29 Jan 2009 at 10:50, Facundo Batista wrote:

This introduces the problem that some examples are in Py2 and others
are in Py3. Sometimes this is not explicit, and gets confusing. I'm
trying to avoid this confusion when preparing my own examples. So far,
I use (py3) as a prefix for any example block, like:

(Py3k)

(some example)

(some result)

Is there any recommended way to avoid confusion in these cases? (I'm
thinking about changing the prompt in my Python installation, to
something like ">2>>" and ">3>>", to be explicit about it... but I
wanted to know if there's another better way)


My suggestion would be to run the examples in the interpreter shell
to validate them before posting, and just cut and paste the banner
along with the example:

Python 2.6.1 (r261:67515, Jan  7 2009, 17:09:13)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print "hello world"
hello world

Python 3.0 (r30:67503, Dec 18 2008, 19:09:30)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print("hello world")
hello world

A bit noisier, but not much more work than cutting and pasting the
example without the banner :)

--RDM
___
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] pprint(iterator)

[Oleg Broytmann]

On Thu, Jan 29, 2009 at 08:06:18AM -0800, Aahz wrote:
> On Thu, Jan 29, 2009, Michael Foord wrote:
> > Don't we have a pretty-print API - and isn't it spelled __str__ ?
> 
> In theory, yes.  In practice, we wouldn't be having this discussion if
> that really worked.  But it probably would make sense to see how far
> using __str__ can take us -- AFAICT enumobject.c doesn't define __str__
> (although I may be missing something, I don't know Python at the C level
> very well).

   Container objects (tuples/lists/dicts/sets) don't define __str__.
Is __pprint__ an attempt to redefine __str__?

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
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] Include C++ code in the ctypes test suite?

[Thomas Heller]

I'm currently working on a patch that adds the __thiscall calling
convention to ctypes.  This calling convention is used on Windows
for calling member functions from C++ classes.  The idea is to eventually
allow ctypes to wrap C++ classes.

To test this functionality it is required to add some C++ source code to the
ctypes private test module _ctypes_test.pyd/_ctypes_test.so.

Is it appropriate to add C++ source files to the Python repository,
or would that create too much trouble on some platforms?
-- 
Thanks,
Thomas

___
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] Include C++ code in the ctypes test suite?

[Benjamin Peterson]

On Thu, Jan 29, 2009 at 10:27 AM, Thomas Heller  wrote:
> Is it appropriate to add C++ source files to the Python repository,
> or would that create too much trouble on some platforms?

I don't see a problem with that as long as platforms without C++
compilers aren't affected in the build process.



-- 
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] pprint(iterator)

[Paul Moore]

2009/1/29 Oleg Broytmann :
> On Thu, Jan 29, 2009 at 08:06:18AM -0800, Aahz wrote:
>> On Thu, Jan 29, 2009, Michael Foord wrote:
>> > Don't we have a pretty-print API - and isn't it spelled __str__ ?
>>
>> In theory, yes.  In practice, we wouldn't be having this discussion if
>> that really worked.  But it probably would make sense to see how far
>> using __str__ can take us -- AFAICT enumobject.c doesn't define __str__
>> (although I may be missing something, I don't know Python at the C level
>> very well).
>
>   Container objects (tuples/lists/dicts/sets) don't define __str__.
> Is __pprint__ an attempt to redefine __str__?

Anyone feel like raising the topic of generic functions again? :-)

More practically, the undocumented simplegeneric decorator in pkgutil
could be used:

Python 2.6.1 (r261:67517, Dec  4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkgutil import simplegeneric
>>> @simplegeneric
... def f(obj):
...return "Object of type %s" % type(obj)
...
>>> def str_f(s):
...return "String: " + s
...
>>> f.register(str, str_f)

>>> f("Test")
'String: Test'
>>> f(1)
"Object of type "
>>>

To me, that seems better than inventing yet another special method.

Paul.
___
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] Include C++ code in the ctypes test suite?

[Christian Heimes]

Thomas Heller schrieb:
> To test this functionality it is required to add some C++ source code to the
> ctypes private test module _ctypes_test.pyd/_ctypes_test.so.
> 
> Is it appropriate to add C++ source files to the Python repository,
> or would that create too much trouble on some platforms?

How about creating an additional test library ctypes_test_cpp.cpp? This
way we can still run the ctypes tests on a platform without a C++
compiler. Of course you could add some preprocessor magic but that's
just another way to ask for trouble. A second test library should make
it easier.

Christian

___
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] Include C++ code in the ctypes test suite?

[Antoine Pitrou]

Thomas Heller  ctypes.org> writes:
> 
> To test this functionality it is required to add some C++ source code to the
> ctypes private test module _ctypes_test.pyd/_ctypes_test.so.

Perhaps you should create a separate test module (_ctypes_pp_test?) so that
platforms without a properly configured C++ compiler can still run the other
tests.

(I also suppose configure can detect the presence of a C++ compiler...)

Regards

Antoine.


___
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] Python 3.0.1

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jan 29, 2009, at 6:31 AM, A.M. Kuchling wrote:


If we intend for 3.0 to be a 'beta release', or to weaken the 'no
features in micro releases' rule, then fine; but we have to be *really
clear about it*.  Are we?  (The 3.0 release page calls it
production-ready.)


I think it sets bad precedence to downgrade our confidence in the  
release.  Again, my position is that it's better to stick to the same  
development processes we've always used, fix the most egregious  
problems in 3.0.1 with no API changes, but spend most of our energy on  
a 3.1 release in 6 months.


Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSYHga3EjvBPtnXfVAQLQxQP+Ipu3J0Ogvj0kW4txTgu8SJ4Hr6q7ll7i
uyASnNQdB0WV3My1VsymMb5VlIWJtuvwY4DxYR1fqLHOQY6CloFqmmIkeMpZKt/K
qXqNI1OvyLfoqg6QqXI+A4UFnUwlv7bSFHqZUu8wVn4De/kQqVfFUgjxBCoNe0lj
0au4xGdjjYo=
=qOne
-END PGP SIGNATURE-
___
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] Include C++ code in the ctypes test suite?

[Alexander Belopolsky]

On Thu, Jan 29, 2009 at 11:50 AM, Antoine Pitrou  wrote:
..
> (I also suppose configure can detect the presence of a C++ compiler...)
>
This test is already there:

$ ./configure
...
checking for g++... g++
configure: WARNING:

  By default, distutils will build C++ extension modules with "g++".
  If this is not intended, then set CXX on the configure command line.
...
___
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] Partial function application 'from the right'

[Terry Reedy]

Ben North wrote:


I find 'functools.partial' useful, but occasionally I'm unable to use it
because it lacks a 'from the right' version. ...
Would there be any interest in this?


I think so.  Post your patch to the tracker. Even if eventually 
rejected, it will be there for people to use.


___
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] Partial function application 'from the right'

[Antoine Pitrou]

Hello,

Ben North  redfrontdoor.org> writes:
> 
> I find 'functools.partial' useful, but occasionally I'm unable to use it
> because it lacks a 'from the right' version.  E.g., to create a function
> which splits a string on commas, you can't say
> 
># Won't work when called:
>split_comma = partial(str.split, sep = ',')

In py3k, we could also use "..." (the Ellipsis object) to denote places where an
argument is missing, so that:

split_comma = partial(str.split, ..., ',')

would do what you want.

Regards

Antoine.


___
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] Python 3.0.1

[Guido van Rossum]

> On Jan 29, 2009, at 6:31 AM, A.M. Kuchling wrote:
>> If we intend for 3.0 to be a 'beta release', or to weaken the 'no
>> features in micro releases' rule, then fine; but we have to be *really
>> clear about it*.  Are we?  (The 3.0 release page calls it
>> production-ready.)

On Thu, Jan 29, 2009 at 8:59 AM, Barry Warsaw  wrote:
> I think it sets bad precedence to downgrade our confidence in the release.
>  Again, my position is that it's better to stick to the same development
> processes we've always used, fix the most egregious problems in 3.0.1 with
> no API changes, but spend most of our energy on a 3.1 release in 6 months.

I'd like to find a middle ground. We can all agree that the users of
3.0 are a small minority compared to the 2.x users. Therefore I think
we can bend the rules more than we have done for the recent 2.x
releases. Those rules weren't always there (anyone remember the
addition of bool, True and False to 2.2.1?). The rules were introduced
for the benefit of our most conservative users -- people who introduce
Python in an enterprise and don't want to find that they are forced to
upgrade in six months.

Frankly, I don't really believe the users for whom those rules were
created are using 3.0 yet. Instead, I expect there to be two types of
users: people in the educational business who don't have a lot of
bridges to burn and are eager to use the new features; and developers
of serious Python software (e.g. Twisted) who are trying to figure out
how to port their code to 3.0. The first group isn't affected by the
changes we're considering here (e.g. removing cmp or some obscure
functions from the operator module). The latter group *may* be
affected, simply because they may have some pre-3.0 code using old
features that (by accident) still works under 3.0.

On the one hand I understand that those folks want a stable target. On
the other hand I think they would prefer to find out sooner rather
than later they're using stuff they shouldn't be using any more. It's
a delicate balance for sure, and I certainly don't want to open the
floodgates here, or rebrand 3.1 as 3.0.1 or anything like that. But I
really don't believe that the strictest interpretation of "no new
features" will benefit us for 3.0.1. Perhaps we should decide when to
go back to a more strict interpretation of the rules based on the
uptake of Python 3 compared to Python 2.

I don't believe that we risk influencing that uptake by bending the
rules; the uptake will depend on the availability of ported 3rd party
packages and some performance gains. (I don't know enough about the C
reimplementation of io.py to tell whether it could be folded into 3.0
or will have to wait for 3.1.)

Finally, to those who claim that 2.6 is a mess because multiprocessing
wasn't perfectly stable at introduction: that's never been the
standard we've used for totally *new* features. It's always been okay
to add slightly immature features at a major release, as long as (a)
they don't break anything else, and (b) we can fix things in the next
release while maintaining backward compatibility.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] python breakpoint opcode

[Brett Cannon]

On Thu, Jan 29, 2009 at 02:38, Dr Andrew Perella  wrote:
> Hi,
>
> I was thinking of adding a breakpoint opcode to python to enable less
> invasive debugging.
>
> I came across posts from 1999 by Vladimir Marangozov and Christian Tismer
> discussing this issue but the links to the code are all out of date.
>
> Did anything come of this?

There is nothing currently in Python for this, but I was not around
for the discussion back then.

-Brett
___
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] Python 3.0.1

[Steve Holden]

Guido van Rossum wrote:
[...]
> 
> Finally, to those who claim that 2.6 is a mess because multiprocessing
> wasn't perfectly stable at introduction: that's never been the
> standard we've used for totally *new* features. It's always been okay
> to add slightly immature features at a major release, as long as (a)
> they don't break anything else, and (b) we can fix things in the next
> release while maintaining backward compatibility.
> 
There's a large distance between saying its introduction was ill-advised
and that 2.6 is a mess. I certainly never intimated such a thing (I said
it was "a rushed release"). Did anyone?

Of course we can fix it. Of course 2.6 is great.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

___
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] Python 3.0.1

[Guido van Rossum]

On Thu, Jan 29, 2009 at 10:57 AM, Steve Holden  wrote:
> Guido van Rossum wrote:
> [...]
>>
>> Finally, to those who claim that 2.6 is a mess because multiprocessing
>> wasn't perfectly stable at introduction: that's never been the
>> standard we've used for totally *new* features. It's always been okay
>> to add slightly immature features at a major release, as long as (a)
>> they don't break anything else, and (b) we can fix things in the next
>> release while maintaining backward compatibility.
>>
> There's a large distance between saying its introduction was ill-advised
> and that 2.6 is a mess. I certainly never intimated such a thing (I said
> it was "a rushed release"). Did anyone?

I don't think that 2.6 as a whole counts as a rushed release, despite
the inclusion of multiprocessing. And I don't think it was ill-advised
either.

> Of course we can fix it. Of course 2.6 is great.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Python 3.0.1

[Martin v. Löwis]

> I think it sets bad precedence to downgrade our confidence in the
> release.  Again, my position is that it's better to stick to the same
> development processes we've always used, fix the most egregious problems
> in 3.0.1 with no API changes, but spend most of our energy on a 3.1
> release in 6 months.

+1

Martin
___
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] Include C++ code in the ctypes test suite?

[Martin v. Löwis]

> Is it appropriate to add C++ source files to the Python repository,
> or would that create too much trouble on some platforms?

I think there will be massive portability problems, which only fade
after one or two years, until this actually works everywhere.

So failure of this to work shouldn't break the Python build, and,
preferably, the build process should suggest the user what might
have happened when it failed.

Regards,
Martin
___
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] Partial function application 'from the right'

[Scott David Daniels]

Antoine Pitrou wrote:

...
In py3k, we could also use "..." (the Ellipsis object) to denote 
places where an argument is missing, so that:

split_comma = partial(str.split, ..., ',')
would do what you want.


Thus preventing any use of partial when an argument could be an
the Ellipsis instance.

--Scott David Daniels
scott.dani...@acm.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] Partial function application 'from the right'

[Antoine Pitrou]

Scott David Daniels  Acm.Org> writes:
> 
> Antoine Pitrou wrote:
> > ...
> > In py3k, we could also use "..." (the Ellipsis object) to denote 
> > places where an argument is missing, so that:
> > split_comma = partial(str.split, ..., ',')
> > would do what you want.
> 
> Thus preventing any use of partial when an argument could be an
> the Ellipsis instance.

Obviously, it is the drawback :) But Ellipsis is hardly used anywhere, and it 
reads good in this very use case.



___
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] Universal newlines, and the gzip module.

[Christopher Barker]

Hi all,

Over on the matplotlib mailing list, we ran into a problem with trying 
to use Universal newlines with gzip. In virtually all of my code that 
reads text files, I use the 'U' flag to open files, it really helps not 
having to deal with newline issues. Yes, they are fewer now that the 
Macintosh uses \n, but they can still be a pain.


Anyway, we added such support to some matplotlib methods, and found that 
gzip file reading broken We were passing the flags though into either 
file() or gzip.open(), and passing 'U' into gzip.open() turns out to be 
fatal.


1) It would be nice if the gzip module (and the zip lib module) 
supported Universal newlines -- you could read a compressed text file 
with "wrong" newlines, and have them handled properly. However, that may 
be hard to do, so at least:


2) Passing a 'U' flag in to gzip.open shouldn't break it.

I took a look at the Python SVN (2.5.4 and 2.6.1) for the gzip lib. I 
see this:



# guarantee the file is opened in binary mode on platforms
# that care about that sort of thing
if mode and 'b' not in mode:
mode += 'b'
if fileobj is None:
fileobj = self.myfileobj = __builtin__.open(filename, mode 
or 'rb')


this is going to break for 'U' == you'll get 'rUb'. I tested 
file(filename, 'rUb'), and it looks like it does universal newline 
translation.


So:

* Either gzip should be a bit smarter, and remove the 'U' flag (that's 
what we did in the MPL code), or force 'rb' or 'wb'.


* Or: file opening should be a bit smarter -- what does 'rUb' mean? a 
file can't be both Binary and Universal Text. Should it raise an 
exception? Somehow I think it would be better to ignore the 'U', but 
maybe that's only because of the issue I happen to be looking at now.



That later seems a better idea -- this issue could certainly come up in 
other places than the gzip module, but maybe it would break a bunch of 
code -- who knows?


I haven't touched py3 yet, so I have not idea if this issue is different 
there.


-Chris



--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Partial function application 'from the right'

[Alexander Belopolsky]

This discussion probably belongs to python-ideas, but since we already
have this thread, I'll reply here instead of opening a new thread
there.

Ellipsis was introduced into python to serve needs of the numeric
python community.  If you think of numpy multiarrays as functions
taking ndim number of arguments, then ellipsis is used to denote any
number of missing arguments and : is used to denote a single missing
argument.

By this analogy, partial(f, ..., *args) is right_partial with '...'
standing for any number of missing arguments.  I you want to specify
exactly one missing argument, you would want to write partial(f, :,
*args), which is not a valid syntax even in Py3.

If one is willing to use [] instead of () with partial, it is possible
to implement  partial[f, ..., *args] and partial[f, x, :, z] already
in Py2, but I would rather see : allowed in the argument lists or some
other short syntax for missing arguments.  If such syntax is
introduced, the need for partial may even go away with
partial(str.split, :, ',') spelled simply as str.split(:, ',').

On Thu, Jan 29, 2009 at 3:04 PM, Antoine Pitrou  wrote:
> Scott David Daniels  Acm.Org> writes:
>>
>> Antoine Pitrou wrote:
>> > ...
>> > In py3k, we could also use "..." (the Ellipsis object) to denote
>> > places where an argument is missing, so that:
>> > split_comma = partial(str.split, ..., ',')
>> > would do what you want.
>>
>> Thus preventing any use of partial when an argument could be an
>> the Ellipsis instance.
>
> Obviously, it is the drawback :) But Ellipsis is hardly used anywhere, and it
> reads good in this very use case.
>
>
>
> ___
> 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/alexander.belopolsky%40gmail.com
>
___
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] Python 3.0.1

[Raymond Hettinger]

From: "Guido van Rossum" 

On the one hand I understand that those folks want a stable target. On
the other hand I think they would prefer to find out sooner rather
than later they're using stuff they shouldn't be using any more. It's
a delicate balance for sure, and I certainly don't want to open the
floodgates here, or rebrand 3.1 as 3.0.1 or anything like that. But I
really don't believe that the strictest interpretation of "no new
features" will benefit us for 3.0.1. Perhaps we should decide when to
go back to a more strict interpretation of the rules based on the
uptake of Python 3 compared to Python 2.


That seems like a smart choice to me.  Make the fixups as early as possible,
before there has been significant uptake.

Am reminded of a cautionary tale from The Art of Unix Programming 
http://www.faqs.org/docs/artu/ch15s04.html#id2986550 :

"""

No discussion of make(1) would be complete without an acknowledgement that it includes one of the worst design botches in the 
history of Unix. The use of tab characters as a required leader for command lines associated with a production means that the 
interpretation of a makefile can change drastically on the basis of invisible differences in whitespace.



"Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. 
After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it 
stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my 
embedded base. The rest, sadly, is history." -- Stuart Feldman


"""


Raymond


___
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] Python 3.0.1

[Michael Foord]

Raymond Hettinger wrote:

From: "Guido van Rossum" 

On the one hand I understand that those folks want a stable target. On
the other hand I think they would prefer to find out sooner rather
than later they're using stuff they shouldn't be using any more. It's
a delicate balance for sure, and I certainly don't want to open the
floodgates here, or rebrand 3.1 as 3.0.1 or anything like that. But I
really don't believe that the strictest interpretation of "no new
features" will benefit us for 3.0.1. Perhaps we should decide when to
go back to a more strict interpretation of the rules based on the
uptake of Python 3 compared to Python 2.


That seems like a smart choice to me.  Make the fixups as early as 
possible,

before there has been significant uptake.

Am reminded of a cautionary tale from The Art of Unix Programming 
http://www.faqs.org/docs/artu/ch15s04.html#id2986550 :


"""

No discussion of make(1) would be complete without an acknowledgement 
that it includes one of the worst design botches in the history of 
Unix. The use of tab characters as a required leader for command lines 
associated with a production means that the interpretation of a 
makefile can change drastically on the basis of invisible differences 
in whitespace.



"Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't 
tried either, so I figured this would be a good excuse to learn. After 
getting myself snarled up with my first stab at Lex, I just did 
something simple with the pattern newline-tab. It worked, it stayed. 
And then a few weeks later I had a user population of about a dozen, 
most of them friends, and I didn't want to screw up my embedded base. 
The rest, sadly, is history." -- Stuart Feldman


"""



I suspect that the use of significant whitespace is too deeply ingrained 
in Python for us to change it now - even in Python 3. ;-)


Michael



Raymond


___
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/fuzzyman%40voidspace.org.uk 




--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
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] pprint(iterator)

[Nick Coghlan]

Michael Foord wrote:
> Don't we have a pretty-print API - and isn't it spelled __str__ ?

For the "reiterable" cases like dictionary views (where the object is
not consumed), an appropriate __str__ or __repr__ should be written).

Whether that is something as simple as ".items()" for an items view, or something more complicated that
more directly shows the content of the view, I'm not sure.

For the standard iterators like enumerate and ranged, I would suggest
that they be modified to use a repr of the form:

"reversed()"
"enumerate()"
"iter()"
"iter(, )"

While those obviously won't show how much of the iterable has been
consumed, neither do the current representations.

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] Partial function application 'from the right'

[Leif Walsh]

On Thu, Jan 29, 2009 at 9:12 AM, Ben North  wrote:
> I find 'functools.partial' useful, but occasionally I'm unable to use it
> because it lacks a 'from the right' version.  E.g., to create a function
> which splits a string on commas, you can't say

First of all, many functions like this are easy to handle yourself.  Example:

>>> def split_comma(s):
>>>   return str.split(s, ',')

That said, it seems to me that if we're going to add to
functools.partial, we should go all the way and allow keyword
arguments (or a dict of them, if it's otherwise too hard to
implement).  Otherwise, in another few {days, weeks, months} we'll see
another thread like this clamoring for a keyword-sensitive
functools.partial.

Come to think of it, I would imagine the next iteration would ask for
a way to curry arbitrary positional arguments, and I can't come up
with a simple and beautiful way to do that off the top of my head.
Maybe this is an argument for keeping functools.partial the way it is
and forcing developers to write their own currying functions.

-- 
Cheers,
Leif
___
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] Partial function application 'from the right'

[Antoine Pitrou]

Alexander Belopolsky  gmail.com> writes:
> 
> By this analogy, partial(f, ..., *args) is right_partial with '...'
> standing for any number of missing arguments.  I you want to specify
> exactly one missing argument, you would want to write partial(f, :,
> *args), which is not a valid syntax even in Py3.

Yes, of course, but... the meaning which numpy attributes to Ellipsis does not
have to be the same in other libraries. Otherwise this meaning would have been
embedded in the interpreter itself, while it hasn't.

The point of using Ellipsis in this case is not to be numpy-friendly, but rather
to exploit the fact that it is a very rarely used object, and that it has an
alternate spelling which suits very well (visually speaking) the purpose being
discussed.

Regards

Antoine.


___
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] Python 3.0.1

[Aahz]

On Wed, Jan 28, 2009, M.-A. Lemburg wrote:
>
> Why don't we just mark 3.0.x as experimental branch and keep updating/
> fixing things that were not sorted out for the 3.0.0 release ?! I
> think that's a fair approach, given that the only way to get field
> testing for new open-source software is to release early and often.
>
> A 3.1 release should then be the first stable release of the 3.x
> series and mark the start of the usual deprecation mechanisms we have
> in the 2.x series. Needless to say, that rushing 3.1 out now would
> only cause yet another experimental release... major releases do take
> time to stabilize.

Speaking as the original author of PEP6 (Bug Fix Releases), this sounds
like a reasonable middle ground.  I certainly advocate that nobody
consider Python 3.0 for production software, and enshrining that into the
dev process should work well.  At the same time, I think each individual
change that doesn't clearly fall into the PEP6 process of being a bugfix
needs to be vetted beyond what's permitted for not-yet-released versions.

The problem is that the obvious candidate for doing the vetting is the
Release Manager, and Barry doesn't like this approach.  The vetting does
need to be handled by a core committer IMO -- MAL, are you volunteering?
Anyone else?

Barry, are you actively opposed to marking 3.0.x as experimental, or do
you just dislike it?  (I.e. are you -1 or -0?)
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.
___
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] Merging to the 3.0 maintenance branch

[Nick Coghlan]

Benjamin Peterson wrote:
> On Wed, Jan 28, 2009 at 10:37 PM, brett. cannon
>  wrote:
>> Author: brett.cannon
>> Date: Thu Jan 29 05:37:06 2009
>> New Revision: 69093
>>
>> Log:
>> Backport r69092 by hand since svnmerge keeps saying there is a conflict on 
>> '.'.
> 
> Just do "svn resolved ."

There are potential problems with doing it that way [1]. The safer
option is to do:

svn revert .
svnmerge merge -M -F 

Perhaps we should add a "maintmerge" script (along with "maintmerge.bat"
batch file) to the root development directory that automates this:

#/bin/sh
svnmerge merge -r $1
svn revert .
svnmerge -M -F $1

(Note that my shell scripting is a little rusty and I haven't actually
executed that example...)

Then the advice will just be to use svnmerge directly most of the time,
and maintmerge when merging a revision that was itself created with
svnmerge.

Cheers,
Nick.

[1] How to clobber svnmerge's revision tracking 101:
http://mail.python.org/pipermail/python-dev/2008-December/084644.html

-- 
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] Partial function application 'from the right'

[Nick Coghlan]

Leif Walsh wrote:
> That said, it seems to me that if we're going to add to
> functools.partial, we should go all the way and allow keyword
> arguments (or a dict of them, if it's otherwise too hard to
> implement).  Otherwise, in another few {days, weeks, months} we'll see
> another thread like this clamoring for a keyword-sensitive
> functools.partial.

functools.partial *does* support keyword arguments - it's just that some
functions and methods written in C (such as string methods) *don't*, so
partial's keyword support doesn't help.

A functools.rpartial would go some way towards addressing that.

Using the standalone Ellipsis to denote missing arguments would probably
start to miss the whole point of functools.partial: the only reason for
its existence is that it is *faster than the equivalent Python function*.

If partial starts messing about looking for missing arguments and then
slotting them in, then it is likely to slow down to the point where you
would be better off skipping it and writing a dedicated function that
adds the extra arguments.

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] Partial function application 'from the right'

[Antoine Pitrou]

Nick Coghlan  gmail.com> writes:
> 
> If partial starts messing about looking for missing arguments and then
> slotting them in, then it is likely to slow down to the point where you
> would be better off skipping it and writing a dedicated function that
> adds the extra arguments.

Looking for missing arguments is very cheap, just raw pointer compares (Ellipsis
is a singleton). In comparison, the cost of executing a dedicated Python
function would be overwhelming.


___
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] pprint(iterator)

[Steven D'Aprano]

Michael Foord wrote:


Don't we have a pretty-print API - and isn't it spelled __str__ ?


Not really. If it were as simple as calling str(obj), there would be no 
need for the pprint module. In any case, it seems that the pprint module 
actually calls repr() on objects other than dicts, tuples and lists.


I'm concerned about the number of special methods exploding, but I've 
also come across times where I needed more than two string 
representations of an object. Sometimes I solved this by adding a 
pprint() method, other times I used other names, and it would be nice if 
there was a standard way of spelling it. So I'm +0.5 on Aahz's 
suggestion of __pprint__.


In my ideal world, __pprint__ should allow (but not require) extra 
arguments, so that one can do something like the following:


pprint(binarytree)  # sensible defaults
pprint(binarytree, order='preorder')



--
Steven

___
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] Universal newlines, and the gzip module.

[Brett Cannon]

On Thu, Jan 29, 2009 at 12:39, Christopher Barker  wrote:
> Hi all,
>
> Over on the matplotlib mailing list, we ran into a problem with trying to
> use Universal newlines with gzip. In virtually all of my code that reads
> text files, I use the 'U' flag to open files, it really helps not having to
> deal with newline issues. Yes, they are fewer now that the Macintosh uses
> \n, but they can still be a pain.
>
> Anyway, we added such support to some matplotlib methods, and found that
> gzip file reading broken We were passing the flags though into either file()
> or gzip.open(), and passing 'U' into gzip.open() turns out to be fatal.
>
> 1) It would be nice if the gzip module (and the zip lib module) supported
> Universal newlines -- you could read a compressed text file with "wrong"
> newlines, and have them handled properly. However, that may be hard to do,
> so at least:
>
> 2) Passing a 'U' flag in to gzip.open shouldn't break it.
>
> I took a look at the Python SVN (2.5.4 and 2.6.1) for the gzip lib. I see
> this:
>
>
># guarantee the file is opened in binary mode on platforms
># that care about that sort of thing
>if mode and 'b' not in mode:
>mode += 'b'
>if fileobj is None:
>fileobj = self.myfileobj = __builtin__.open(filename, mode or
> 'rb')
>
> this is going to break for 'U' == you'll get 'rUb'. I tested file(filename,
> 'rUb'), and it looks like it does universal newline translation.
>
> So:
>
> * Either gzip should be a bit smarter, and remove the 'U' flag (that's what
> we did in the MPL code), or force 'rb' or 'wb'.
>
> * Or: file opening should be a bit smarter -- what does 'rUb' mean? a file
> can't be both Binary and Universal Text. Should it raise an exception?
> Somehow I think it would be better to ignore the 'U', but maybe that's only
> because of the issue I happen to be looking at now.
>
>
> That later seems a better idea -- this issue could certainly come up in
> other places than the gzip module, but maybe it would break a bunch of code
> -- who knows?

I think it should be raising an exception as 'rUb' is an invalid value
for the argument.

-Brett
___
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] Broken Test -- test_distutils

[Raymond Hettinger]

In the past couple of days, test_distutils started failing.  
It looks like a pure python error and may have been 
introduced by guilherme.polo's checkins:



File "c:\py27\lib\distutils\tests\test_sdist.py", line 119, in test_make_distr
ibution
   spawn('tar --help')
 File "c:\py27\lib\distutils\spawn.py", line 37, in spawn
   _spawn_nt(cmd, search_path, dry_run=dry_run)
 File "c:\py27\lib\distutils\spawn.py", line 70, in _spawn_nt
   cmd = _nt_quote_args(cmd)
 File "c:\py27\lib\distutils\spawn.py", line 61, in _nt_quote_args
   args[i] = '"%s"' % args[i]
TypeError: 'str' object does not support item assignment

1 test failed:
   test_distutils



Raymond




___
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] Broken Test -- test_distutils

[Tarek Ziadé]

On Fri, Jan 30, 2009 at 12:00 AM, Raymond Hettinger  wrote:
> In the past couple of days, test_distutils started failing.  It looks like a
> pure python error and may have been introduced by guilherme.polo's checkins:
>

That's me. I'll fix this problem right now.

>
> File "c:\py27\lib\distutils\tests\test_sdist.py", line 119, in
> test_make_distr
> ibution
>   spawn('tar --help')
>  File "c:\py27\lib\distutils\spawn.py", line 37, in spawn
>   _spawn_nt(cmd, search_path, dry_run=dry_run)
>  File "c:\py27\lib\distutils\spawn.py", line 70, in _spawn_nt
>   cmd = _nt_quote_args(cmd)
>  File "c:\py27\lib\distutils\spawn.py", line 61, in _nt_quote_args
>   args[i] = '"%s"' % args[i]
> TypeError: 'str' object does not support item assignment
>
> 1 test failed:
>   test_distutils
>
>
>
> Raymond
>
>
>
>
> ___
> 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/ziade.tarek%40gmail.com
>



-- 
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
___
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] Broken Test -- test_distutils

[Guilherme Polo]

On Thu, Jan 29, 2009 at 9:00 PM, Raymond Hettinger  wrote:
> In the past couple of days, test_distutils started failing.  It looks like a
> pure python error and may have been introduced by guilherme.polo's checkins:
>
>
> File "c:\py27\lib\distutils\tests\test_sdist.py", line 119, in
> test_make_distr
> ibution
>   spawn('tar --help')
>  File "c:\py27\lib\distutils\spawn.py", line 37, in spawn
>   _spawn_nt(cmd, search_path, dry_run=dry_run)
>  File "c:\py27\lib\distutils\spawn.py", line 70, in _spawn_nt
>   cmd = _nt_quote_args(cmd)
>  File "c:\py27\lib\distutils\spawn.py", line 61, in _nt_quote_args
>   args[i] = '"%s"' % args[i]
> TypeError: 'str' object does not support item assignment
>
> 1 test failed:
>   test_distutils
>
>

How did my commits introduced that error ?

>
> Raymond
>


-- 
-- Guilherme H. Polo Goncalves
___
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] pprint(iterator)

[Robert Kern]

On 2009-01-29 08:20, Aahz wrote:


The reason I'm chiming in is that I would welcome a PEP that created a
__pprint__ method as an alternative to special-casing.  I think that it
would be generically useful for user-created objects, plus once you've
added this feature other people can easily do some of the grunt work of
extending this through the Python core.  (Actually, unless someone
objects, I don't think a PEP is required, but it would be good for the
usual reasons that PEPs are written, to provide a central place
documenting the addition.)


I think it's worth looking at Armin Ronacher's pretty.py for a starting point.

  http://dev.pocoo.org/hg/sandbox/file/tip/pretty

I've been using it as my default displayhook under IPython for a few weeks now. 
It uses a combination of a function registry and a __pretty__ special method to 
find the right pretty printer.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

___
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] Broken Test -- test_distutils

[Raymond Hettinger]

[Tarek Ziadé]

That's me. I'll fix this problem right now.



Thanks.  I appreciate it.


Raymond


___
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] Partial function application 'from the right'

[Daniel Stutzbach]

On Thu, Jan 29, 2009 at 4:04 PM, Antoine Pitrou  wrote:

> Alexander Belopolsky  gmail.com> writes:
> > By this analogy, partial(f, ..., *args) is right_partial with '...'
> > standing for any number of missing arguments.  I you want to specify
> > exactly one missing argument, you would want to write partial(f, :,
> > *args), which is not a valid syntax even in Py3.
>
> Yes, of course, but... the meaning which numpy attributes to Ellipsis does
> not
> have to be the same in other libraries. Otherwise this meaning would have
> been
> embedded in the interpreter itself, while it hasn't.
>

The meaning which numpy attributes to Ellipsis is also the meaning that
mathematical notation has attached to Ellipsis for a very long time.

See: http://en.wikipedia.org/wiki/Ellipsis#In_mathematical_notation

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Partial function application 'from the right'

[Mike Klaas]

On 29-Jan-09, at 3:21 PM, Daniel Stutzbach wrote:

On Thu, Jan 29, 2009 at 4:04 PM, Antoine Pitrou  
 wrote:

Alexander Belopolsky  gmail.com> writes:
> By this analogy, partial(f, ..., *args) is right_partial with '...'
> standing for any number of missing arguments.  I you want to specify
> exactly one missing argument, you would want to write partial(f, :,
> *args), which is not a valid syntax even in Py3.

Yes, of course, but... the meaning which numpy attributes to  
Ellipsis does not
have to be the same in other libraries. Otherwise this meaning would  
have been

embedded in the interpreter itself, while it hasn't.

The meaning which numpy attributes to Ellipsis is also the meaning  
that mathematical notation has attached to Ellipsis for a very long  
time.


And yet, python isn't confined to mathematical notation.  *, ** are  
both overloaded for use in argument lists to no-one's peril, AFAICT.


-Mike
___
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] Python 3.0.1

[Raymond Hettinger]

[Aahz]

At the same time, I think each individual
change that doesn't clearly fall into the PEP6 process of being a bugfix
needs to be vetted beyond what's permitted for not-yet-released versions.


To get the ball rolling, I have a candidate for discussion.

Very late in the 3.0 process (after feature freeze), the bsddb code was
ripped out (good riddance).  This had the unfortunate side-effect of
crippling shelves which now fall back to using dumbdbm.

I'm somewhat working on an alternate dbm based on sqlite3:
   http://code.activestate.com/recipes/576638/
It is a pure python module and probably will not be used directly, but shelves
will see an immediate benefit (especially for large shelves) in terms of speed
and space.

On the one hand, it is an API change or new feature because people can
(if they choose) access the dbm directly.  OTOH, it is basically a performance 
fix for shelves whose API won't change at all.  The part that is visible and

incompatible is that 3.0.1 shelves won't be readable by 3.0.0.




The problem is that the obvious candidate for doing the vetting is the
Release Manager, and Barry doesn't like this approach.  The vetting does
need to be handled by a core committer IMO -- MAL, are you volunteering?
Anyone else?


It should be someone who is using 3.0 regularly (ideally someone who
is working on fixing it).  IMO, people who aren't exercising it don't really
have a feel for the problems or the cost/benefits of the fixes.



Barry, are you actively opposed to marking 3.0.x as experimental, or do
you just dislike it?  (I.e. are you -1 or -0?)


My preference is to *not* mark it as experimental.  Instead, I prefer
doing what it takes to make the 3.0.x series viable.  



Raymond
___
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] Partial function application 'from the right'

[Collin Winter]

On Thu, Jan 29, 2009 at 6:12 AM, Ben North  wrote:
> Hi,
>
> I find 'functools.partial' useful, but occasionally I'm unable to use it
> because it lacks a 'from the right' version.  E.g., to create a function
> which splits a string on commas, you can't say
>
>   # Won't work when called:
>   split_comma = partial(str.split, sep = ',')
[snip]
> I've created a patch which adds a 'partial_right' function.  The two
> examples above:
>
>   >>> import functools, math
>
>   >>> split_comma = functools.partial_right(str.split, ',')
>   >>> split_comma('a,b,c')
>   ['a', 'b', 'c']
>
>   >>> log_10 = functools.partial_right(math.log, 10.0)
>   >>> log_10(100.0)
>   2.0

Can you point to real code that this makes more readable?

Collin
___
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] Partial function application 'from the right'

[Daniel Stutzbach]

On Thu, Jan 29, 2009 at 5:24 PM, Mike Klaas  wrote:

> And yet, python isn't confined to mathematical notation.  *, ** are both
> overloaded for use in argument lists to no-one's peril, AFAICT.
>

Certainly, but there is no danger of confusion them for multiplication in
context, whereas:

split_comma = partial(str.split, ..., ',')

to me looks like "make ',' the last argument" rather than "make ',' the
second argument".

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Partial function application 'from the right'

[Andrew Bennetts]

Mike Klaas wrote:
> On 29-Jan-09, at 3:21 PM, Daniel Stutzbach wrote:
[...]
>> The meaning which numpy attributes to Ellipsis is also the meaning  
>> that mathematical notation has attached to Ellipsis for a very long  
>> time.
>
> And yet, python isn't confined to mathematical notation.  *, ** are both 
> overloaded for use in argument lists to no-one's peril, AFAICT.

With the crucial difference that * and ** are purely syntax, but Ellipsis is
an object.

-Andrew.

___
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] Python 3.0.1

[Guido van Rossum]

On Thu, Jan 29, 2009 at 3:27 PM, Raymond Hettinger  wrote:
> To get the ball rolling, I have a candidate for discussion.
>
> Very late in the 3.0 process (after feature freeze), the bsddb code was
> ripped out (good riddance).  This had the unfortunate side-effect of
> crippling shelves which now fall back to using dumbdbm.
>
> I'm somewhat working on an alternate dbm based on sqlite3:
>   http://code.activestate.com/recipes/576638/
> It is a pure python module and probably will not be used directly, but shelves
> will see an immediate benefit (especially for large shelves) in terms of speed
> and space.
>
> On the one hand, it is an API change or new feature because people can
> (if they choose) access the dbm directly.  OTOH, it is basically a
> performance fix for shelves whose API won't change at all.  The part that is 
> visible
> and incompatible is that 3.0.1 shelves won't be readable by 3.0.0.

That is too much for 3.0.1. It could affect external file formats
which strikes me as a bad idea.

Sounds like a good candidate for 3.1, which we should be expecting in
4-6 months I hope. Also you could try find shelve users (are there
any?) and recommend they install this as a 3rd party package, with the
expectation it'll be built into 3.1.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Python 3.0.1

[Raymond Hettinger]

On the one hand, it is an API change or new feature because people can
(if they choose) access the dbm directly.  OTOH, it is basically a
performance fix for shelves whose API won't change at all.  The part that is 
visible
and incompatible is that 3.0.1 shelves won't be readable by 3.0.0.


That is too much for 3.0.1. It could affect external file formats
which strikes me as a bad idea.


We should have insisted that bsddb not be taken out until a replacement
was put in.  The process was broken with the RM insisting on feature 
freeze early in the game but letting tools like bsddb get ripped-out near 
the end.  IMO, it was foolish to do one without the other.
After the second alphas was out, there was resistance to any additions 
or to revisiting any of the early changes -- that was probably

as mistake -- now we're deferring the fix for another 4-6 months
and 3.0.x will never have it (at least right out of the box, as shipped).



Also you could try find shelve users (are there
any?) 


I'm a big fan of shelves and have always used them extensively.
Not sure if anyone else cares about them though.



recommend they install this as a 3rd party package, with the
expectation it'll be built into 3.1.


Will do.  That was my original plan since the day bsddb got ripped out.



Raymond
___
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] Python 3.0.1

[Raymond Hettinger]

A couple additional thoughts FWIW:

* whichdb() selects from multiple file formats, so 3.0.1 would still
  be able to read 3.0.0 files.   It is the 2.x shelves that won't be
  readable at all under any scenario.

* If you're thinking that shelves have very few users and that
 3.0.0 has had few adopters, doesn't that mitigate the effects
 of making a better format available in 3.0.1?  Wouldn't this
 be the time to do it?

* The file format itself is not new or unreadable by 3.0.0.
  It is just a plain sqlite3 file.  Was is new is the ability
  of shelve's to call sqlite.  To me, that is something a little
  different than changing a pickle protocol or somesuch.


Raymond
___
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] Python 3.0.1

[Antoine Pitrou]

Raymond Hettinger  rcn.com> writes:
> 
> * If you're thinking that shelves have very few users and that
>   3.0.0 has had few adopters, doesn't that mitigate the effects
>   of making a better format available in 3.0.1?  Wouldn't this
>   be the time to do it?

There was already another proposal for an sqlite-based dbm module, you may
want to synchronize with it:
http://bugs.python.org/issue3783

As I see it, the problem with introducing it in 3.0.1 is that we would be
rushing in a new piece of code without much review or polish. Also, there are
only two release blockers left for 3.0.1, so we might just finish those and
release, then concentrate on 3.1.

Regards

Antoine.


___
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] pprint(iterator)

[Raymond Hettinger]

Along the lines of what others have said: pprint() cannot consume an
unknown iterator.  


Perhaps so.  It's nice to have printing be free of side-effects (other than
the actual printing).

I've been working with 3.0 daily for several months (on a book project)
and mostly think it's great.  But sooner or later, we're going to have to 
address the issue about iterator reprs at the interactive prompt.  This is a 
separate and more general issue than pprint().  My experience so far is that 
it is that the shift to more things being unviewable at the prompt is bit frustrating

and makes the language more opaque.  If that has been a source of irritation
to me, then it will likely be more acutely felt by people who are starting out
and are using the interactive prompt to explore the language.

I don't know the right answer here (perhaps an alternate sys.displayhook).
Just wanted to provide some early feedback based on my experiences
heavily exercising 3.0.


Raymond


P.S.  My other experience with 3.0 is that my most frequent error has
changed.  It used to be that the number reason for my getting a syntax
error was leaving-off a colon.  Now, my number one reason is
omitting parens in a print() function call.  I thought I would get used to
it quickly, but it still comes up several times a day.


___
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] pprint(iterator)

[Antoine Pitrou]

Raymond Hettinger  rcn.com> writes:
> 
> P.S.  My other experience with 3.0 is that my most frequent error has
> changed.  It used to be that the number reason for my getting a syntax
> error was leaving-off a colon.  Now, my number one reason is
> omitting parens in a print() function call.  I thought I would get used to
> it quickly, but it still comes up several times a day.

I find myself with the reverse problem. When I code with 2.x, I often put parens
around the argument list of a print staement.



___
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] Python 3.0.1

[Stephen J. Turnbull]

Raymond Hettinger writes:

 > My preference is to *not* mark it as experimental.

Don't take the word "experimental" too seriously.  It's clearly an
exaggeration given the current state of 3.0.x.  What is meant is an
explicit announcement that the stability rules chosen in response to
the bool-True-False brouhaha will be relaxed for the 3.0.x series
*only*.

 > Instead, I prefer doing what it takes to make the 3.0.x series viable.  

That's not an "instead", that's two independent choices.  The point is
that most of the people who are voicing concerns fear precisely that
policy.

I think that the important question is "can the 3.0.x series be made
'viable' in less than the time frame for 3.1?"  If not, I really have
to think it's DOA from the point of view of folks who consider 3.0.0
non-viable.  I think that's what Barry and Martin are saying.

Guido is saying something different.  AIUI, he's saying that explicitly
introducing controlled instability into 3.0.x of the form "this is
what the extremely stable non-buggy inherited-from-3.0 core of 3.1 is
going to look like" will be a great service to those who consider
3.0.0 non-viable.

The key point is that new features in 3.1 are generally going to be
considered less reliable than those inherited from 3.0, and thus a
debugged 3.0, even if the implementations have been unstable, provides
a way for the very demanding to determine what that set is, and to
test how it behaves in their applications.

I think it's worth a try, after consultation with some of the major
developers who are the ostensible beneficiaries.  But if tried, I
think it's important to mark 3.0.x as "not yet stable" even if the
instability is carefully defined and controlled.
___
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] [Python-checkins] Merging to the 3.0 maintenance branch

[Martin v. Löwis]

> There are potential problems with doing it that way [1]. The safer
> option is to do:
> 
> svn revert .
> svnmerge merge -M -F 

I still don't see the potential problem. If you do svnmerge, svn commit,
all is fine, right? The problem *only* arises if you do svnmerge,
svn up, svn commit - and clearly, you shouldn't do that. If, on commit,
you get a conflict, you should revert all your changes, svn up, and
start all over with the merge.

Regards,
Martin
___
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] Python 3.0.1

[Aahz]

On Fri, Jan 30, 2009, Antoine Pitrou wrote:
> Raymond Hettinger  rcn.com> writes:
>> 
>> * If you're thinking that shelves have very few users and that
>>   3.0.0 has had few adopters, doesn't that mitigate the effects
>>   of making a better format available in 3.0.1?  Wouldn't this
>>   be the time to do it?
> 
> There was already another proposal for an sqlite-based dbm module, you may
> want to synchronize with it:
> http://bugs.python.org/issue3783
> 
> As I see it, the problem with introducing it in 3.0.1 is that we would
> be rushing in a new piece of code without much review or polish. Also,
> there are only two release blockers left for 3.0.1, so we might just
> finish those and release, then concentrate on 3.1.

There's absolutely no reason not to have a 3.0.2 before 3.1 comes out.
You're probably right that what Raymond wants to is best not done for
3.0.1 -- but once we've agreed in principle that 3.0.x isn't a true
production release of Python for PEP6 purposes, we can do "release early,
release often".
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.
___
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] Python 3.0.1

[Martin v. Löwis]

> Don't take the word "experimental" too seriously.  It's clearly an
> exaggeration given the current state of 3.0.x.  What is meant is an
> explicit announcement that the stability rules chosen in response to
> the bool-True-False brouhaha will be relaxed for the 3.0.x series
> *only*.

The name for that shouldn't be "experimental", though. I don't think
it needs any name at all. It would be sufficient to report, in the
release announcement, and some stuff got removed in an incompatible
way. This is also different from bool-True-False, which was an
addition, not a removal.

> I think that the important question is "can the 3.0.x series be made
> 'viable' in less than the time frame for 3.1?"  If not, I really have
> to think it's DOA from the point of view of folks who consider 3.0.0
> non-viable.  I think that's what Barry and Martin are saying.

DOA == dead on arrival? I don't think Python 3.0 is dead. Instead, I
think it is fairly buggy, but those bugs can be fixed. Removal of stuff
is *not* a bug fix, of course.

The *real* bugs in 3.0 is stuff like "IDLE doesn't work", "bdist_wininst
doesn't work", etc.

I personally can agree with removal of stuff (despite it not being
a bug fix). However, more importantly, I want to support respective
authority. If the release manager sets a policy on what is and what
is not acceptable for a bug fix release, every committer should
implement this policy (or at least not actively break it).

With the removals in the code, I do think it is important to release
3.0.1 quickly, like, say, next week.

> The key point is that new features in 3.1 are generally going to be
> considered less reliable than those inherited from 3.0, and thus a
> debugged 3.0, even if the implementations have been unstable, provides
> a way for the very demanding to determine what that set is, and to
> test how it behaves in their applications.

That is fairly abstract. What specific bugs in Python 3.0 are you
talking about?

Regards,
Martin
___
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] [Python-checkins] Merging to the 3.0 maintenance branch

[Brett Cannon]

On Thu, Jan 29, 2009 at 18:27, "Martin v. Löwis"  wrote:
>> There are potential problems with doing it that way [1]. The safer
>> option is to do:
>>
>> svn revert .
>> svnmerge merge -M -F 
>
> I still don't see the potential problem. If you do svnmerge, svn commit,
> all is fine, right? The problem *only* arises if you do svnmerge,
> svn up, svn commit - and clearly, you shouldn't do that. If, on commit,
> you get a conflict, you should revert all your changes, svn up, and
> start all over with the merge.

I did do that and I still got conflicts.

-Brett
___
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] [Python-checkins] Merging to the 3.0 maintenance branch

[Martin v. Löwis]

Brett Cannon wrote:
> On Thu, Jan 29, 2009 at 18:27, "Martin v. Löwis"  wrote:
>>> There are potential problems with doing it that way [1]. The safer
>>> option is to do:
>>>
>>> svn revert .
>>> svnmerge merge -M -F 
>> I still don't see the potential problem. If you do svnmerge, svn commit,
>> all is fine, right? The problem *only* arises if you do svnmerge,
>> svn up, svn commit - and clearly, you shouldn't do that. If, on commit,
>> you get a conflict, you should revert all your changes, svn up, and
>> start all over with the merge.
> 
> I did do that and I still got conflicts.

What is "that"? "svn revert -R" (plus rm for all added files),
"svn up", "svnmerge", "svn revert ."?

What conflicts?

Martin
___
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] [Python-checkins] Merging to the 3.0 maintenance branch

[Brett Cannon]

On Thu, Jan 29, 2009 at 19:03, "Martin v. Löwis"  wrote:
> Brett Cannon wrote:
>> On Thu, Jan 29, 2009 at 18:27, "Martin v. Löwis"  wrote:
 There are potential problems with doing it that way [1]. The safer
 option is to do:

 svn revert .
 svnmerge merge -M -F 
>>> I still don't see the potential problem. If you do svnmerge, svn commit,
>>> all is fine, right? The problem *only* arises if you do svnmerge,
>>> svn up, svn commit - and clearly, you shouldn't do that. If, on commit,
>>> you get a conflict, you should revert all your changes, svn up, and
>>> start all over with the merge.
>>
>> I did do that and I still got conflicts.
>
> What is "that"? "svn revert -R" (plus rm for all added files),
> "svn up", "svnmerge", "svn revert ."?

svn up
svnmerge
... conflicts
svn revert -R .
svn up
svnmerge
... same conflicts


>
> What conflicts?

Some metadata on '.'.

-Brett
___
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] Python 3.0.1

[rdmurray]

On Thu, 29 Jan 2009 at 16:43, Raymond Hettinger wrote:

On Thu, 29 Jan 2009 at 15:40, Guido van Rossum wrote:

 Also you could try find shelve users (are there
 any?) 


I'm a big fan of shelves and have always used them extensively.
Not sure if anyone else cares about them though.


I use them.  Not in any released products at the moment, though, and I
haven't migrated the shelve-using code to 3.0 yet.  So I'd be in favor
of adding sqlite3 support as soon as practical.

--RDM
___
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] [Python-checkins] Merging to the 3.0 maintenance branch

[Martin v. Löwis]

> svn up
> svnmerge
> ... conflicts
> svn revert -R .
> svn up
> svnmerge
> ... same conflicts

Ah. In the 3.0 branch, always do "svn revert ." after svnmerge.
It's ok (Nick says it isn't exactly ok, but I don't understand why)

Martin
___
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] pprint(iterator)

[Ron Adam]

Steven D'Aprano wrote:

Michael Foord wrote:


Don't we have a pretty-print API - and isn't it spelled __str__ ?


Not really. If it were as simple as calling str(obj), there would be no 
need for the pprint module.


I agree.  And when I want to use pprint, there are usually additional 
output formatting requirements I need that isn't a "one size fits all" type 
of problem.



In any case, it seems that the pprint module

actually calls repr() on objects other than dicts, tuples and lists.

I'm concerned about the number of special methods exploding, but I've 
also come across times where I needed more than two string 
representations of an object. Sometimes I solved this by adding a 
pprint() method, other times I used other names, and it would be nice if 
there was a standard way of spelling it. So I'm +0.5 on Aahz's 
suggestion of __pprint__.


I'm -.5 on addint __pprint__ for the above reasons.


In my ideal world, __pprint__ should allow (but not require) extra 
arguments, so that one can do something like the following:


pprint(binarytree)  # sensible defaults
pprint(binarytree, order='preorder')


It seems to me pprint is one of those functions where output format 
specifiers and keywords make sense because you are trying to fit the data 
output of a wide variety of types to a particular output need.  It's not 
reasonably possible for each type to predict what that output need is.


Some of the options that sound useful might be:

   abbreviated form
   short form
   long complete detail form
   tree form
   column align form
   right or left margins and alignment options

Think of it as how 'dir' is used for examining the contents of a disk drive 
where different output styles is useful at different times.


Looking at it this way, instead of a __pprint__ method, a optional 
__pprint_style__ attribute could specify a default output style that the 
pprint function would fall back to.



Maybe for iterators, it's not the data produced but rather the current 
state of use that is more useful?


For example for partially consumed iterators it might be useful to express 
how many items have been taken, and how many are left to take when that 
info is available. (?)


The idea is that pretty printing is usually used to check the status or 
state of something.  Or at least that is how I use it.


Ron

















___
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] 3.0.1/3.1.0 summary

[Brett Cannon]

This is my attempt to summarize what everyone has been saying so we
can get this resolved.

>From what I can tell, most people like the idea of doing a 3.0.1
release ASAP (like "in a week or so" fast) with the stuff that should
have been removed from 3.0.0 in the first place removed.

People also seem to support doing a 3.1 release April/May where new
stuff (e.g. io in C, new shelve back-end for sqlite3) is introduced to
the rest of the world. This timeline has the benefit of allowing us to
do an alpha release at PyCon and puts us at a six month release cycle
which does not portray 3.0 or 3.1 as rushed releases.

The sticky points I see are:

1. Barry, who is the release manager for 3.0.1, does not like the idea
of the cruft that is being proposed removed from 3.0.1. Personally I
say we continue to peer pressure him as I think a new major release is
not like our typical minor release, but I am not about to force Barry
to go against what he thinks is reasonable unless I am willing to step
up as release manager (and I am not since I simply don't have the time
to learn the process fast enough along with just a lack of time with
other Python stuff).

2. Do we label 3.0.x as experimental? I say no since it isn't
experimental; we basically had some bugs slip through that happen to
be compatibility problems that were overlooked. I for one never viewed
3.0.x as experimental, just not the best we could necessarily do
without more input from the community and our own experience with 3.x
in general.

Let's see if we can get these two points squared away so we can get
3.0.1 in whatever state it is meant to be in out the door quickly.

-Brett
___
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] Python 3.0.1

[Stephen J. Turnbull]

"Martin v. Löwis" writes:

 > > Don't take the word "experimental" too seriously.  What is meant
 > > is an explicit announcement that the stability rules will be
 > > relaxed for the 3.0.x series *only*.
 > 
 > The name for that shouldn't be "experimental", though. I don't think
 > it needs any name at all.

That's what I meant.  I'm sure that whoever wrote the word
"experimental" in the first place regrets it, because it doesn't
reflect what they meant.

 > > I think that the important question is "can the 3.0.x series be made
 > > 'viable' in less than the time frame for 3.1?"  If not, I really have
 > > to think it's DOA from the point of view of folks who consider 3.0.0
 > > non-viable.  I think that's what Barry and Martin are saying.
 > 
 > DOA == dead on arrival? I don't think Python 3.0 is dead.

I'm sorry, DOA was poor word choice, especially this context.  I meant
that people who currently consider 3.0 non-viable are more likely to
focus on the branch that will become 3.1 unless a "viable" 3.0.x will
arrive *very* quickly.

 > That is fairly abstract. What specific bugs in Python 3.0 are you
 > talking about?

I'm not talking about specific bugs; I'm perfectly happy with 3.0 for
my purposes, and I think it very unlikely that any of the possibly
destabilizing changes that have been proposed for 3.0.1 will affect
me adversely.

Rather, I'm trying to disentangle some of the unfortunate word choices
that have been made (and I apologize for making one of my own!), and
find common ground so that a policy can be set more quickly.

IMO it's likely that there's really no audience for a 3.0.x series
that conforms to the rules used for 2.x from 2.2.1 or so on.  That is,
there are people who really don't care because 3.0 is already a better
platform for their application whether there are minor changes or not,
and there are people who do care about stability but they're not going
to use 3.0.x whether it adheres to the previous rules strictly or not.
There are very few who will use 3.0.x if and only if it adheres strictly.
___
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] Python 3.0.1

[Guido van Rossum]

On Thu, Jan 29, 2009 at 4:58 PM, Raymond Hettinger  wrote:
> A couple additional thoughts FWIW:
>
> * whichdb() selects from multiple file formats, so 3.0.1 would still
>  be able to read 3.0.0 files.   It is the 2.x shelves that won't be
>  readable at all under any scenario.
>
> * If you're thinking that shelves have very few users and that
>  3.0.0 has had few adopters, doesn't that mitigate the effects
>  of making a better format available in 3.0.1?  Wouldn't this
>  be the time to do it?
>
> * The file format itself is not new or unreadable by 3.0.0.
>  It is just a plain sqlite3 file.  Was is new is the ability
>  of shelve's to call sqlite.  To me, that is something a little
>  different than changing a pickle protocol or somesuch.

Sorry, not convinced. This is a change of a different scale than
removing stuff that should've been removed. I understand you'd like to
see your baby released. But I think it's better to have it tried and
tested by others *outside* the core distro first. dbm is not broken in
3.0, just slow. Well so be it, io.py is too and that's a lot more
serious. I also note that on some systems at least ndbm and/or gdbm
are supported.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Python 3.0.1

[Raymond Hettinger]

[Guido van Rossum]

Sorry, not convinced.


No worries.  Py3.1 is not far off.

Just so I'm clear.  Are you thinking that 3.0.x will never have
fast shelves, or are you thinking 3.0.2 or 3.0.3 after some
external deployment and battle-testing for the module?


Raymond

___
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] pprint(iterator)

[Terry Reedy]

Ron Adam wrote:



Steven D'Aprano wrote:

Michael Foord wrote:


Don't we have a pretty-print API - and isn't it spelled __str__ ?


Not really. If it were as simple as calling str(obj), there would be 
no need for the pprint module.


I agree.  And when I want to use pprint, there are usually additional 
output formatting requirements I need that isn't a "one size fits all" 
type of problem.


Like others, I am wary of over-expanding the list of special methods. 
Perhap format strings could have a fourth conversion specifier, !p 
(pretty) in addition to !s, !r, and !a.


___
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] 3.0.1/3.1.0 summary

[Terry Reedy]

Brett Cannon wrote:

This is my attempt to summarize what everyone has been saying so we
can get this resolved.


From what I can tell, most people like the idea of doing a 3.0.1

release ASAP (like "in a week or so" fast) with the stuff that should
have been removed from 3.0.0 in the first place removed.

People also seem to support doing a 3.1 release April/May where new
stuff (e.g. io in C, new shelve back-end for sqlite3) is introduced to
the rest of the world. This timeline has the benefit of allowing us to
do an alpha release at PyCon and puts us at a six month release cycle
which does not portray 3.0 or 3.1 as rushed releases.

The sticky points I see are:

1. Barry, who is the release manager for 3.0.1, does not like the idea
of the cruft that is being proposed removed from 3.0.1. Personally I
say we continue to peer pressure him as I think a new major release is
not like our typical minor release, but I am not about to force Barry
to go against what he thinks is reasonable unless I am willing to step
up as release manager (and I am not since I simply don't have the time
to learn the process fast enough along with just a lack of time with
other Python stuff).


While I prefer cruft removal now, I will, for the same reason, accept 
and use whatever whatever Barry delivers.



2. Do we label 3.0.x as experimental? I say no since it isn't
experimental; we basically had some bugs slip through that happen to
be compatibility problems that were overlooked. I for one never viewed
3.0.x as experimental, just not the best we could necessarily do
without more input from the community and our own experience with 3.x
in general.


It is normal for true x.0 releases to be slightly flakey.  Experienced 
users typically wait for x.1 (or SP1) releases for building production 
systems.  I understand that 'normal' is below Python's usual high 
standards, but it is not a tragedy ;-).



Let's see if we can get these two points squared away so we can get
3.0.1 in whatever state it is meant to be in out the door quickly.


+1

Terry

___
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] python breakpoint opcode

[Neal Norwitz]

On Thu, Jan 29, 2009 at 2:38 AM, Dr Andrew Perella  wrote:
> Hi,
>
> I was thinking of adding a breakpoint opcode to python to enable less
> invasive debugging.
>
> I came across posts from 1999 by Vladimir Marangozov and Christian Tismer
> discussing this issue but the links to the code are all out of date.

Can you provide the links?

n
___
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] 3.0.1/3.1.0 summary

[Martin v. Löwis]

> 1. Barry, who is the release manager for 3.0.1, does not like the idea
> of the cruft that is being proposed removed from 3.0.1.

I don't think he actually said that (in fact, I think he said the
opposite). It would be good if he clarified, though.

Regards,
Martin
___
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] Python 3.0.1

[Martin v. Löwis]

> Just so I'm clear.  Are you thinking that 3.0.x will never have
> fast shelves

As Guido said, shelves are *already* fast in 3.0, if you are
using the right operating system.

Regards,
Martin
___
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] pprint(iterator)

[Eric Smith]

Terry Reedy wrote:

Ron Adam wrote:



Steven D'Aprano wrote:

Michael Foord wrote:


Don't we have a pretty-print API - and isn't it spelled __str__ ?


Not really. If it were as simple as calling str(obj), there would be 
no need for the pprint module.


I agree.  And when I want to use pprint, there are usually additional 
output formatting requirements I need that isn't a "one size fits all" 
type of problem.


I don't see how you can have a standard interface (like __pprint__), and 
have additional, per-object formatting parameters. But that's beside the 
point, I don't like __pprint__ in any event. Too special.


Like others, I am wary of over-expanding the list of special methods. 
Perhap format strings could have a fourth conversion specifier, !p 
(pretty) in addition to !s, !r, and !a.


What would format() do with "!p"? With "!s", it calls str(o), with "!r", 
it calls repr(o). "!p" could call o.__pprint__(), but that's the special 
method you're trying to avoid!


(I don't recall if I added "!a", and a machine that would know isn't 
available to me just now.)


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