Re: [Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

[Eugene Toder]

To give this a positive spin, here's a patch that implements constant
folding on AST (it does few other optimizations on compiler data
structures, so it replaces "peephole over bytecode" completely).

http://bugs.python.org/issue11549

It passes make test, but of course more testing is needed. Comments are welcome.

Eugene
___
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] PEP 382 Master

[Guido van Rossum]

On Mon, Mar 14, 2011 at 1:10 PM, "Martin v. Löwis"  wrote:
> I'd like to appoint Eric Smith as the PEP master for PEP 382
> (Namespace Packages).

Eric has ample experience with PEPs and strikes me as pretty
even-keeled (hi Eric! :-) so +1 from me.

> I hope to complete the implementation shortly, at which point
> there will be a final call for comments.

Great, ideally we should have reference implementations for all PEPs
before their final review.

-- 
--Guido van Rossum (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] pydoc for named tuples is missing methods

[James Mills]

On Tue, Mar 15, 2011 at 11:50 AM, Terry Reedy  wrote:
>> How would that work if you had a field named "replace"? I think
>> Raymond's current design is as good as it's going to get.
>
> 'as_dict' is an unlikely fieldname. 're_place' is too, but that just shift
> the '_' from '_replace'. No gain. I might prefer _asdict to _as_dict, but
> not enough to change.

Probably a stupid idea (sorry) but one could just
make asdict() and replace() public methods
with the caveat that developers not use those
as field names.

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"
___
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] pydoc for named tuples is missing methods

[Terry Reedy]

On 3/14/2011 9:23 PM, Eric Smith wrote:

On 3/14/2011 8:44 PM, James Mills wrote:

On Tue, Mar 15, 2011 at 9:48 AM, R. David
Murray wrote:

But directly calling a __xxx__ method in Python is a very
unusual thing to do. It would be extremely odd to have that
be the expected way to call a method on a class.


Can't namedtuple be improved to support the named fields _and_
have as_dict() and replace() without leading underscores ?


How would that work if you had a field named "replace"? I think
Raymond's current design is as good as it's going to get.


'as_dict' is an unlikely fieldname. 're_place' is too, but that just 
shift the '_' from '_replace'. No gain. I might prefer _asdict to 
_as_dict, but not enough to change.


--
Terry Jan Reedy

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

Re: [Python-Dev] pydoc for named tuples is missing methods

[Eric Smith]

On 3/14/2011 8:44 PM, James Mills wrote:

On Tue, Mar 15, 2011 at 9:48 AM, R. David Murray  wrote:

But directly calling a __xxx__ method in Python is a very
unusual thing to do.  It would be extremely odd to have that
be the expected way to call a method on a class.


Can't namedtuple be improved to support the named fields _and_
have as_dict() and replace() without leading underscores ?


How would that work if you had a field named "replace"? I think 
Raymond's current design is as good as it's going to get.


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

[Python-Dev] NetBSD and curses

[Bill Green]

Hi all,

I ran across this issue several months ago and filed a bug report 
(#9667).  It just came up again, and it doesn't look like anything's 
been done with the bug report, so I thought I'd post here.


In _cursesmodule.c there are a lot of preprocesser conditionals that 
test if the system is NetBSD. In my case, the issue was that the module 
built lacked the KEY_UP / _DOWN / etc. constants, but there are other 
changes as well.  This is the case even if you're compiling against 
ncurses instead of the system curses.  Αttached below is a patch against 
2.7.1 that negates the NetBSD conditionals if ncurses is present.  It 
seems to work as expected, although I haven't done any real testing.  I 
assumed this was done because NetBSD curses was missing something, but I 
looked at the headers and it seems to have most of the constants that 
the compilation directives are leaving out (A_INVIS, the aforementioned 
KEY_* constants, at least), so I'm not sure why that code isn't compiled 
in anyway.  Please let me know if I'm misunderstanding this.


Thanks,
Bill
--- Python-2.7.1/Modules/_cursesmodule.c2011-03-13 23:34:27.0 
-0700
+++ Python-2.7.1/Modules/_cursesmodule.c.1  2011-03-14 00:33:09.0 
-0700
@@ -322,13 +322,13 @@
 
 Window_OneArgNoReturnFunction(clearok, int, "i;True(1) or False(0)")
 Window_OneArgNoReturnFunction(idlok, int, "i;True(1) or False(0)")
-#if defined(__NetBSD__)
+#if defined(__NetBSD__) && !defined(HAVE_NCURSES_H)
 Window_OneArgNoReturnVoidFunction(keypad, int, "i;True(1) or False(0)")
 #else
 Window_OneArgNoReturnFunction(keypad, int, "i;True(1) or False(0)")
 #endif
 Window_OneArgNoReturnFunction(leaveok, int, "i;True(1) or False(0)")
-#if defined(__NetBSD__)
+#if defined(__NetBSD__) && !defined(HAVE_NCURSES_H)
 Window_OneArgNoReturnVoidFunction(nodelay, int, "i;True(1) or False(0)")
 #else
 Window_OneArgNoReturnFunction(nodelay, int, "i;True(1) or False(0)")
@@ -891,7 +891,7 @@
 return Py_BuildValue("c", rtn);
 } else {
 const char *knp;
-#if defined(__NetBSD__)
+#if defined(__NetBSD__) && !defined(HAVE_NCURSES_H)
 knp = unctrl(rtn);
 #else
 knp = keyname(rtn);
@@ -2108,7 +2108,7 @@
 }
 #endif /* HAVE_CURSES_IS_TERM_RESIZED */
 
-#if !defined(__NetBSD__)
+#if !defined(__NetBSD__) || defined(HAVE_NCURSES_H)
 static PyObject *
 PyCurses_KeyName(PyObject *self, PyObject *args)
 {
@@ -2672,7 +2672,7 @@
 #ifdef HAVE_CURSES_IS_TERM_RESIZED
 {"is_term_resized", (PyCFunction)PyCurses_Is_Term_Resized, 
METH_VARARGS},
 #endif
-#if !defined(__NetBSD__)
+#if !defined(__NetBSD__) || defined(HAVE_NCURSES_H)
 {"keyname", (PyCFunction)PyCurses_KeyName, METH_VARARGS},
 #endif
 {"killchar",(PyCFunction)PyCurses_KillChar, METH_NOARGS},
@@ -2783,7 +2783,7 @@
 SetDictInt("A_DIM", A_DIM);
 SetDictInt("A_BOLD",A_BOLD);
 SetDictInt("A_ALTCHARSET",  A_ALTCHARSET);
-#if !defined(__NetBSD__)
+#if !defined(__NetBSD__) || defined(HAVE_NCURSES_H)
 SetDictInt("A_INVIS",   A_INVIS);
 #endif
 SetDictInt("A_PROTECT", A_PROTECT);
@@ -2857,7 +2857,7 @@
 int key;
 char *key_n;
 char *key_n2;
-#if !defined(__NetBSD__)
+#if !defined(__NetBSD__) || defined(HAVE_NCURSES_H)
 for (key=KEY_MIN;key < KEY_MAX; key++) {
 key_n = (char *)keyname(key);
 if (key_n == NULL || strcmp(key_n,"UNKNOWN KEY")==0)
___
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] pydoc for named tuples is missing methods

[James Mills]

On Tue, Mar 15, 2011 at 9:48 AM, R. David Murray  wrote:
> But directly calling a __xxx__ method in Python is a very
> unusual thing to do.  It would be extremely odd to have that
> be the expected way to call a method on a class.

Can't namedtuple be improved to support the named fields _and_
have as_dict() and replace() without leading underscores ?

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"
___
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] packaging

[Greg Ewing]

Antoine Pitrou wrote:


But doesn't it also mean many setup.py scripts will have very tedious
import sequences, such as:

try:
from packaging.compiler import FooCompiler
from packaging.commands import BarCommand
except ImportError:
try:
from distutils2.compiler import FooCompiler
from distutils2.commands import BarCommand

> ...

Maybe this will be the killer app for the "or" enhancement
to the import statement. :-)

--
Greg
___
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] pydoc for named tuples is missing methods

[R. David Murray]

On Tue, 15 Mar 2011 09:54:23 +1300, Greg Ewing  
wrote:
> Nick Coghlan wrote:
> 
> > True, but all those underscores are a PITA to type and read for
> > methods that are meant to be called directly.
> 
> Matter of taste, I suppose. I don't find them all that
> bothersome, and a double underscore name stands out very
> clearly as being part of the infrastructure rather than
> something user-defined.

But directly calling a __xxx__ method in Python is a very
unusual thing to do.  It would be extremely odd to have that
be the expected way to call a method on a class.

--
R. David Murray  www.bitdance.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

[Python-Dev] Copyright notices

[Nadeem Vawda]

I was wondering what the policy is regarding copyright notices and license
boilerplate text at the top of source files.

I am currently rewriting the bz2 module (see http://bugs.python.org/issue5863),
splitting the existing Modules/bz2module.c into Modules/_bz2module.c and
Lib/bz2.py.

Are new files expected to include a copyright notice and/or license boilerplate
text? Also, is it necessary for _bz2module.c (new) to retain the copyright
notices from bz2module.c (old)? In the tracker issue, Antoine said he didn't
think so, but suggested that I get some additional opinions.

Regards,
Nadeem
___
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] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

[Reid Kleckner]

On Mon, Mar 14, 2011 at 6:30 PM, Lennart Regebro  wrote:
> On Wed, Mar 9, 2011 at 01:15, Stefan Behnel  wrote:
>> I can confirm that the Cython project was as surprised of the PyCapsule
>> change in Python 3.2 as (I guess) most other users, and I would claim that
>> we are a project with one of the highest probabilities of being impacted by
>> C-API changes.
>
> And so was I. I discovered it today.
>
> And personally, I don't mind being surprised. And I'm sorry I didn't
> have time to try out the zope.* packages that support Python 3 on 3.2,
> but then again the difference was supposed to be between 2.x and 3.x.
> I didn't expect 3.2 to suddenly be backwards incompatible. Of the
> eight packages that currently support 3.1 (in trunk), two packages do
> not compile, and one gets massive test failures (which may only be
> test failures, and not actual failures). That is *not* good. Perhaps
> there is a easy way to map the API's with #defines, but if this is the
> case, why was the change done in the first place?

I don't know how your code works, but handling either type from C
seems very straightforward to me.  You can simply use #ifdef
Py_COBJECT_H to see if the cobject.h header was pulled into Python.h.
Similarly for Py_CAPSULE_H.  All you lose is that if you do get a
PyCObject, there is no way of knowing if the void pointer is of the
right type.

> Many projects, not only the Zope Toolkit needs to support a lot of
> versions. The Zope component architecture currently supports 2.4, 2.5
> and 2.6 and is expected to work on 2.7. I don't know if 2.4 or 2.5 can
> be dropped, but it definitely will be *years* until we can drop
> support for 2.6.  But if I move the PyCObject API to the PyCapsule
> API, the zope packages will **only work on Python 2.7 and 3.2**. This
> is obviously not an option. If I do *not* switch, I can't support
> Python 3.2. That's bad.
>
> **We can't deprecate an API in one version and drop the API in the
> next. This is not acceptable. The deprecation period must be much
> longer!**

Surely, you must be joking.  Python already has a long release cycle.
I'm not familiar with this feature, but suppose it is decided that
there is sufficient cause to remove a feature.  First, we have to wait
until the next release to deprecate it.  Then we have to wait yet one
more release to remove it.  With an 18-month release cycle, that's 27
months on average.  To me, that is a very long time to wait.

> In fact, since the deprecation in the Python 2 line happened in 2.7,
> the deprecation period of this API in practice was between July 3rd
> 2010 and February 20 2011. That is a deprecation period of somewhat
> longer than seven months. Nobody obviously though 2.6 was out of
> practical use by now, so why did you decide to remove one if it's
> API's?

PyCObject was deprecated in 3.1, as well as 2.7.
http://docs.python.org/release/3.1.3/c-api/cobject.html#PyCObject

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

[Python-Dev] Fwd: Re: packaging

[Tarek Ziadé]

Sorry i am not used to my new phone .. fwding to python-dev
-- Message transféré --
De : "Tarek Ziadé" 
Date : 14 mars 2011 19:12
Objet : Re: [Python-Dev] packaging
À : "Paul Moore" 

That document is from the latest release at pypi.  You can find a fresher
doc in docs in the hg repo.  There's also a rendering at
http://distutils2.notmyidea.org which is more recent.

One task during the sprint is to consolidate all the doc ;)
Le 14 mars 2011 19:03, "Paul Moore"  a écrit :

> On 14 March 2011 22:34, Tarek Ziadé  wrote:
>> Setup.py is gone in distutils2 and therefore in packaging
>
> Where can I find the documentation? The distutils2 docs ("A simple
> example") still use setup.py. See
>
http://packages.python.org/Distutils2/distutils/introduction.html#a-simple-example
>
> 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] packaging

[Paul Moore]

On 14 March 2011 22:34, Tarek Ziadé  wrote:
> Setup.py is gone in distutils2 and therefore in packaging

Where can I find the documentation? The distutils2 docs ("A simple
example") still use setup.py. See
http://packages.python.org/Distutils2/distutils/introduction.html#a-simple-example

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] packaging

[Tarek Ziadé]

Setup.py is gone in distutils2 and therefore in packaging
Le 14 mars 2011 18:27, "Antoine Pitrou"  a écrit :
> On Mon, 14 Mar 2011 18:00:50 -0400
> Tarek Ziadé  wrote:
>>
>> And it's also a good way to prevent any conflict with 3.3 : the
>> standalone version for 2.4 to 3.2 is "distutils2", and people won't
>> have to deal with the same package being in the stdlib and at PyPI.
>> (like json vs simplejson, unittest vs unittest2...)
>
> But doesn't it also mean many setup.py scripts will have very tedious
> import sequences, such as:
>
> try:
> from packaging.compiler import FooCompiler
> from packaging.commands import BarCommand
> except ImportError:
> try:
> from distutils2.compiler import FooCompiler
> from distutils2.commands import BarCommand
> except ImportError:
> try:
> from setuptools.compiler import FooCompiler
> from setuptools.commands import OtherNameForBarCommand as \
> BarCommand
> except ImportError:
> from distutils.compiler import FooCompiler
> from distutils.commands import OtherNameForBarCommand as \
> BarCommand
>
> (I'm still remembering the import dances which were necessary to get
> cElementTree/ElementTree in the 2.4-2.5 days)
>
> 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/ziade.tarek%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] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

[Lennart Regebro]

On Wed, Mar 9, 2011 at 01:15, Stefan Behnel  wrote:
> I can confirm that the Cython project was as surprised of the PyCapsule
> change in Python 3.2 as (I guess) most other users, and I would claim that
> we are a project with one of the highest probabilities of being impacted by
> C-API changes.

And so was I. I discovered it today.

And personally, I don't mind being surprised. And I'm sorry I didn't
have time to try out the zope.* packages that support Python 3 on 3.2,
but then again the difference was supposed to be between 2.x and 3.x.
I didn't expect 3.2 to suddenly be backwards incompatible. Of the
eight packages that currently support 3.1 (in trunk), two packages do
not compile, and one gets massive test failures (which may only be
test failures, and not actual failures). That is *not* good. Perhaps
there is a easy way to map the API's with #defines, but if this is the
case, why was the change done in the first place?

But the problem here is not the surprise. If I had known about this
beforehand, that would only have helped, if I could have convinced
others that the API shouldn't have been removed!

The problem is the deprecation period!

Many projects, not only the Zope Toolkit needs to support a lot of
versions. The Zope component architecture currently supports 2.4, 2.5
and 2.6 and is expected to work on 2.7. I don't know if 2.4 or 2.5 can
be dropped, but it definitely will be *years* until we can drop
support for 2.6.  But if I move the PyCObject API to the PyCapsule
API, the zope packages will **only work on Python 2.7 and 3.2**. This
is obviously not an option. If I do *not* switch, I can't support
Python 3.2. That's bad.

**We can't deprecate an API in one version and drop the API in the
next. This is not acceptable. The deprecation period must be much
longer!**

In fact, since the deprecation in the Python 2 line happened in 2.7,
the deprecation period of this API in practice was between July 3rd
2010 and February 20 2011. That is a deprecation period of somewhat
longer than seven months. Nobody obviously though 2.6 was out of
practical use by now, so why did you decide to remove one if it's
API's?


Let's make no bones about this: The PyCObject API should *not* have
been removed in 3.2. In fact, the removal should be reversed, and
3.2.1 should be released ASAP, making 3.2 a moot and unsupported
version. It can possibly be removed in 3.3, but better would be 3.4.
It must be possible to support 3-4 releases of Python with the current
release speed. We need to support python versions that are five years
old or so. In fact the deprecation period should probably be somewhat
similar to the security fix period.

-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python3porting.com/
+33 661 58 14 64
___
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] packaging

[Antoine Pitrou]

On Mon, 14 Mar 2011 18:00:50 -0400
Tarek Ziadé  wrote:
> 
> And it's also a good way to prevent any conflict with 3.3 : the
> standalone version for 2.4 to 3.2 is "distutils2", and people won't
> have to deal with the same package being in the stdlib and at PyPI.
> (like json vs simplejson, unittest vs unittest2...)

But doesn't it also mean many setup.py scripts will have very tedious
import sequences, such as:

try:
from packaging.compiler import FooCompiler
from packaging.commands import BarCommand
except ImportError:
try:
from distutils2.compiler import FooCompiler
from distutils2.commands import BarCommand
except ImportError:
try:
from setuptools.compiler import FooCompiler
from setuptools.commands import OtherNameForBarCommand as \
BarCommand
except ImportError:
from distutils.compiler import FooCompiler
from distutils.commands import OtherNameForBarCommand as \
   BarCommand

(I'm still remembering the import dances which were necessary to get
cElementTree/ElementTree in the 2.4-2.5 days)

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] packaging

[Tarek Ziadé]

On Mon, Mar 14, 2011 at 4:46 PM, Antoine Pitrou  wrote:
> On Mon, 14 Mar 2011 15:39:55 -0400
> Tarek Ziadé  wrote:
>> Hey,
>>
>> I just wanted to summarize what we've started at the sprint (and
>> hopefully finish 1 to 7 this week):
>>
>> 1/ distutils2 is merged as the "packaging" Python package in the
>> standard library
>
> Why does it get yet another name?
> We already have distutils, setuptools, distribute, distutils2... now
> "packaging"?

For  it makes sense to have a "packaging" namespace in the standard
library, where we'll be able to add more modules, features etc.

"Distutils" becomes a misnomer now that we'll have features like:

- display the list of installed projects
- search projects at PyPI
- ...

And it's also a good way to prevent any conflict with 3.3 : the
standalone version for 2.4 to 3.2 is "distutils2", and people won't
have to deal with the same package being in the stdlib and at PyPI.
(like json vs simplejson, unittest vs unittest2...)

Cheers
Tarek

> 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/ziade.tarek%40gmail.com
>



-- 
Tarek Ziadé | http://ziade.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] packaging

[Barry Warsaw]

On Mar 14, 2011, at 09:46 PM, Antoine Pitrou wrote:

>Why does it get yet another name?
>We already have distutils, setuptools, distribute, distutils2... now
>"packaging"?

We need a unique name for Python 3.3, otherwise third party modules can't be
written to conditionally depend on the batteries-included version in 3.3, or a
standalone backport for older Pythons.

Guido's already pronounced that it will be 'packaging' in 3.3.

-Barry


signature.asc
Description: 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] [PEPs] Support the /usr/bin/python2 symlink upstream

[Michael Foord]

On 07/03/2011 21:33, Glenn Linderman wrote:

On 3/7/2011 4:00 PM, Michael Foord wrote:

On 07/03/2011 23:52, Greg Ewing wrote:

Michael Foord wrote:

- I doubt calling it python.exe will fly, but I'm not sure. If 
so what will you call what is currently 'python.exe'? - if not then 
"python foo.py" on the command line will *still* not work...


However, if it's installed as the exe associated with the .py
and .pyw extensions, then simply 'foo.py' on the command line
*will* work, and will work better than it does now.

So long as '.py' and '.pyw' are set in the PATHEXT environment 
variable. (Which again the Python installer doesn't do by default.)



No, PATHEXT only means you can invoke

foo.py

and

foo

and get the same results (sometimes, depending on what all in on PATH 
and PATHEXT)


You're correct of course. My apologies.

Michael Foord



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

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
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] pydoc for named tuples is missing methods

[Greg Ewing]

Nick Coghlan wrote:


True, but all those underscores are a PITA to type and read for
methods that are meant to be called directly.


Matter of taste, I suppose. I don't find them all that
bothersome, and a double underscore name stands out very
clearly as being part of the infrastructure rather than
something user-defined.

--
Greg
___
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] packaging

[Antoine Pitrou]

On Mon, 14 Mar 2011 15:39:55 -0400
Tarek Ziadé  wrote:
> Hey,
> 
> I just wanted to summarize what we've started at the sprint (and
> hopefully finish 1 to 7 this week):
> 
> 1/ distutils2 is merged as the "packaging" Python package in the
> standard library

Why does it get yet another name?
We already have distutils, setuptools, distribute, distutils2... now
"packaging"?

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] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

[Cesare Di Mauro]

2011/3/14 Alexander Belopolsky 

> On Sat, Mar 12, 2011 at 1:08 PM, Raymond Hettinger
>  wrote:
> > I would like to withdraw my suggestion for the recursive constant folding
> patch to be reverted.
>
> So what is the status of peephole optimization now?  Is it back under
> active development?   Let me quote a tracker comment that I posted two
> years ago and go no response to ('>'-quote are from Raymond's
> message):
>
> """
> Constant folding promotes more readable code: 24*60*60 is more obvious
> than 86400, prefixing positive numbers with + leads to better visual
> alignment, etc.  Users should not be required to think twice about
> which constant expressions are folded and which are not.
>
> Here is another surprise with the current peepholer:
>
> >>> dis(lambda:1+2*3)
>   1   0 LOAD_CONST   0 (1)
>  3 LOAD_CONST   3 (6)
>  6 BINARY_ADD
>  7 RETURN_VALUE
>
> >>> dis(lambda:2*3+1)
>  1   0 LOAD_CONST   4 (7)
>  3 RETURN_VALUE
>
> I have a fix in the works, but I will wait for your further comments
> before submitting it.
>
> >
> >  More importantly, we decided that the peepholer is the wrong place to
> >  do much of this work.  Most of the peepholer is going to be migrated
> >  up the chain, after the AST is generated, but before the opcodes are
> >  generated.  That is a faster, more reliable, and more general
> >  approach.
> >
>
> I agree.   Constant folding, is an interesting case because peepholer
> has to duplicate a subset of eval logic.  I wonder if the new approach
> could eliminate that.
>

I followed a different approach. Constant folding in WPython is made between
ASDL evalutation and AST building.

The idea is to "intercept" constant values and apply the operations
generating a new value instead of generating the classic AST node (a BinOp
for a binary operation, for example).

This way there's no need to parse the AST tree seeking for cases where to
apply the constant folding logic.

It's faster, because you don't need an additional pass through the AST:
you'll do it while building the AST...

It consumes less memory too, since you don't need to generate complex AST
nodes that must be discarded after applying the folding (which generates new
nodes). Think about a tuple of constant values, for example: you have to
generate a Tuple AST structure from the ASDL, then an AST constant folder
will generate the tuple. In WPython the tuple is generated immediately,
directly from the ADSL seq structure.

It's also efficient, since expressions such as 1 + 2 * 3 can be completely
folded generating 7, instead of 1 + 6 of the (classic) peepholer. That's
because, when parsing the ASDL structures, nodes are evaluated in respect of
operator precedence, so first we evaluate 2 * 3, which produces 6 applying
the folding, and then 1 + 6, which produces 7 in the end.

Cesare
___
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] PEP 382 Master

[Martin v. Löwis]

I'd like to appoint Eric Smith as the PEP master for PEP 382
(Namespace Packages).
I hope to complete the implementation shortly, at which point
there will be a final call for comments.

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

[Python-Dev] New committers coming online

[Jesse Noller]

As agreed to at the language summit, I have pinged the IronPython,
Jython and PyPy teams for committers on their respective teams who
(do/did not) have commit rights prior to PyCon. These people are:

Jeff Hardy (IronPython)
Alex Gaynor (PyPy)
Carl Friedrich Bolz (PyPy)
Maciej Fijalkowski (PyPy)
Antonio Cuni (PyPy)

And one other whose CLA I have in my bag (still haven't unpacked from
PyCon). So if you see them committing, this is a heads up.

A side note: The Jython guys would really love to join us in our HG
future-land. Frank Wierzbicki expressed a lot of interest in this.

Jesse
___
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] packaging

[Tarek Ziadé]

Hey,

I just wanted to summarize what we've started at the sprint (and
hopefully finish 1 to 7 this week):

1/ distutils2 is merged as the "packaging" Python package in the
standard library
2/ distutils2 will provide a "pysetup" script in Python to run all
packaging tools (pysetup is a wrapper that will run
"packaging.run.main")
3/ pkgutil gets the new API (PEP 376) we implemented in distutils2._backport
4/ sysconfig installations paths are moved to a sysconfig.cfg file.
5/ the sysconfig,cfg file will be located besides sysconfig.py in the
standard library
6/ sysconfig will lookup for sysconfig.cfg in several places and merge
sections from down to bottom:
 1/ current directory
 2/ per-user site-packages
 3/ global site-packages
7/ a backport for 2.4 to 3.2 will be provided for "packaging" using
the "distutils2" name
8/ we will release distutils2 in the next 18 months
9/ once 3.3 is out, the backport will just get bug fixes


Cheers
Tarek

-- 
Tarek Ziadé | http://ziade.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] PEP 395: Module Aliasing

[Michael Foord]

On 09/03/2011 16:30, P.J. Eby wrote:

At 05:35 PM 3/4/2011 +, Michael Foord wrote:
That (below) is not distutils it is setuptools. distutils just uses 
`scripts=[...]`, which annoyingly *doesn't* work with setuptools.


Er, what?  That's news to me.  Could you file a bug report about what 
doesn't work, specifically?
Ok. I'm afraid I was relying on anecdotal evidence (the people who 
wanted setuptools specific features in my setup.py told me I *had* to 
use entry points for scripts instead of the standard distutils scripts 
machinery). I'll try out a vanilla "scripts" entry in a setuptools 
setup.py and report back.


All the best,

Michael

--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
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] Have we lost changeset info in the buildbots

[David Bolen]

Antoine Pitrou  writes:

> I suggest you try http://code.google.com/p/bbreport/, which provides a
> very nice command-line interface.

Speaking of bbreport, I sometimes use the published page on that site
(http://code.google.com/p/bbreport/wiki/PythonBuildbotReport) to check
over things, but looking at it today, it seems to most recently have been
generated back in January.  Or is the generated date line wrong?

-- David

___
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] imaplib: Time2Internaldate() returns localized strings

[Sebastian Spaeth]

Hi there,

imaplib has an issue (well, more than one :-)), but in this specific
case there is even a patch that I want to lobby.

http://bugs.python.org/issue11024
imaplib: Time2Internaldate() returns localized strings while the IMAP
RFC requires English month names. As that function is used for every
.append(), this outright prevents some international users during some
months from adding messages. :-)

There is a patch that fixes imaplib and I would be grateful if someone
with commit access would have a look at it, and consider pushing it in.

Thank you so much,
Sebastian

P.S., please keep me CC'd
___
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] Have we lost changeset info in the buildbots

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/03/11 18:07, Antoine Pitrou wrote:
> On Mon, 14 Mar 2011 17:59:27 +0100
> Jesus Cea  wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Traditionally I could see who was the committer who push change to the
>> buildbots. This info seems not to be (easily) available.
> 
> That info was lost quite before the hg migration, when the buildbot
> version was upgraded on the server.
> 
> I suggest you try http://code.google.com/p/bbreport/, which provides a
> very nice command-line interface.

Thanks for the suggestion.

Sniff...

"""
[jcea@babylon5 bbreport]$ python bbreport.py  -r 15b090c9442a
Usage: bbreport.py [options] branch ...

bbreport.py: error: option -r: invalid integer value: '15b090c9442a'
"""

- -- 
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.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTX5lzplgi5GaxT1NAQJ8iwQAmnFHvjxh/OB1OsnUOy4s4RLizgK5Jqo0
N2yynyErx1wdgxB1TGzfMxpZxrWrgGzQrQBiZ5/XuNN6BcUTPW9Lu+np/muKB+qm
3AL864XOqxzbAh2/p4FleZJIqGBnniFUlB3AclI6KLhjumvJFDHLeKczRGPVWFE+
Ref0AtQBVNg=
=mQiJ
-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] cpython: Add a 'timeout' argument to subprocess.Popen.

[Reid Kleckner]

On Mon, Mar 14, 2011 at 12:36 PM, Antoine Pitrou  wrote:
> On Mon, 14 Mar 2011 17:16:11 +0100
> reid.kleckner  wrote:
>> @@ -265,34 +271,43 @@
>>        generates enough output to a pipe such that it blocks waiting
>>        for the OS pipe buffer to accept more data.
>>
>> +   .. versionchanged:: 3.2
>> +      *timeout* was added.
>
> Unless you plan to borrow someone's time machine, this should probably
> be 3.3.

Fixed soon after in http://hg.python.org/cpython/rev/72e49cb7fcf5 .

Reid
___
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] PEPs migrated to mercurial?

[Georg Brandl]

Am 14.03.2011 17:48, schrieb Jesus Cea:
> I see , but last change was a year ago.
> 
> I changes PEP 11 time ago, and I can't see the changes there. So the
> repository seems a bit outdated. Or, maybe, are we still using SVN for
> PEPs?.

Yes.  Not for much longer though.

Georg

___
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] Have we lost changeset info in the buildbots

[Antoine Pitrou]

On Mon, 14 Mar 2011 17:59:27 +0100
Jesus Cea  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Traditionally I could see who was the committer who push change to the
> buildbots. This info seems not to be (easily) available.

That info was lost quite before the hg migration, when the buildbot
version was upgraded on the server.

I suggest you try http://code.google.com/p/bbreport/, which provides a
very nice command-line interface.

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

[Python-Dev] Have we lost changeset info in the buildbots

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Traditionally I could see who was the committer who push change to the
buildbots. This info seems not to be (easily) available.

For instance, I see
.
I just pushed a changeset. I can't see easily if my changeset is being
tested now, or when...

Ideally I would like to see WHO pushed the changeset under test and,
moving my mouse over it, see the commit message and a link to the mercurial.

- -- 
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.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTX5Jb5lgi5GaxT1NAQJUNQP+OQjp9HgMpVETViizGOnOSHImY2imR78e
jBsuRWp4Jcsh6h9lui0vrSpXxLtd065PR1CtOloOjXMR2dAUKGeMYKcsqTfb6p9n
oRZWlnXWpwnEg38Lkgkk9Mz4uYcmljUs7kmn+jEbqS7jWsO2rPZGtab5CV+5ZG0o
kqB8ZUB/YX8=
=9+B2
-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] PEPs migrated to mercurial?

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I see , but last change was a year ago.

I changes PEP 11 time ago, and I can't see the changes there. So the
repository seems a bit outdated. Or, maybe, are we still using SVN for
PEPs?.

- -- 
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.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTX5G+5lgi5GaxT1NAQKBtAP/bROH6dye23+w+nK/D8deKtxEqQlIFeVh
3Dtuo9IhtmkhhFlXeD50WNyLBZPRpbdA97Lo1WL65Fgvj94EDwbI83ex83Bs5DGH
UXfawy635NbxVzJvWL1VXI5rCzcjKY6WrmAgzTPDFyoD1KvzSz6E+kR3IEVohKh3
EihPnrygIA8=
=B44H
-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] Python 3.4 version in the tracker

[Georg Brandl]

Am 13.03.2011 14:47, schrieb Eric Smith:
> On 03/13/2011 06:49 AM, Georg Brandl wrote:
>> On 12.03.2011 17:09, Eric Smith wrote:
>>> On 03/12/2011 10:55 AM, Éric Araujo wrote:
> I have a deprecation warning that I need to make an error in 3.4.

 A neat trick to remember to do those changes is using a test that fails
 if something does not raise a DeprecationWarning if sys.version_info[:2]
 == (3, 3), or an error if sys.version_info[:3] == (3, 4).  You write
 those tests once and let “make test” remind you as soon as the Python
 version changes.
>>>
>>> I like the idea, but it seems a little hostile to the person who
>>> actually changes the version number!
>>
>> If it helps to remember these things (usually deprecations) that we've often
>> forgotten in the past, I don't mind being the one to innocently break the
>> buildbots by increasing the version number.
> 
> Are you volunteering to change all of the PendingDeprecationWarnings to 
> DeprecationWarnings and DeprecationWarnings to errors of some sort? It 
> might be a big job.
> 
> I'm just trying to figure out what the mechanics would be.

No, I'll still forward these failures to whoever put them into the modules :)

Georg

___
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] cpython: Add a 'timeout' argument to subprocess.Popen.

[Antoine Pitrou]

On Mon, 14 Mar 2011 17:16:11 +0100
reid.kleckner  wrote:
> @@ -265,34 +271,43 @@
>generates enough output to a pipe such that it blocks waiting
>for the OS pipe buffer to accept more data.
>  
> +   .. versionchanged:: 3.2
> +  *timeout* was added.

Unless you plan to borrow someone's time machine, this should probably
be 3.3.

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] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

[Ned Batchelder]

On 3/12/2011 12:39 AM, Eugene Toder wrote:

>  You've got wishful thinking if you think a handful of tests can catch
>  errors in code that sophisticated.

Why limit yourself with a handful of tests? Python is widespread,
there's*a lot*  of code in Python. Unlike with libraries, any code you
run tests the optimizer, so just run a lot of code. And, as I've said,
write a test generator.


As we're thinking about what the optimizer of the future should be, it 
would be great to have a way to turn it off completely.  This would 
allow the tests to run test code both with and without the optimizer, 
and to verify that the two results were the same.  Then we could 
automatically verify that the optimizer isn't changing semantics.


BTW: I also believe it would be very useful to make the 
turn-off-the-optimizer switch available for users so they can run their 
code unoptimized for times when they are more interested in program 
analysis than in execution speed.  See http://bugs.python.org/issue2506 
(closed 3 years ago) that I filed with this request.


--Ned.
___
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] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

[Alexander Belopolsky]

On Sat, Mar 12, 2011 at 1:08 PM, Raymond Hettinger
 wrote:
> I would like to withdraw my suggestion for the recursive constant folding 
> patch to be reverted.

So what is the status of peephole optimization now?  Is it back under
active development?   Let me quote a tracker comment that I posted two
years ago and go no response to ('>'-quote are from Raymond's
message):

"""
Constant folding promotes more readable code: 24*60*60 is more obvious
than 86400, prefixing positive numbers with + leads to better visual
alignment, etc.  Users should not be required to think twice about
which constant expressions are folded and which are not.

Here is another surprise with the current peepholer:

>>> dis(lambda:1+2*3)
  1   0 LOAD_CONST   0 (1)
  3 LOAD_CONST   3 (6)
  6 BINARY_ADD
  7 RETURN_VALUE

>>> dis(lambda:2*3+1)
  1   0 LOAD_CONST   4 (7)
  3 RETURN_VALUE

I have a fix in the works, but I will wait for your further comments
before submitting it.

>
>  More importantly, we decided that the peepholer is the wrong place to
>  do much of this work.  Most of the peepholer is going to be migrated
>  up the chain, after the AST is generated, but before the opcodes are
>  generated.  That is a faster, more reliable, and more general
>  approach.
>

I agree.   Constant folding, is an interesting case because peepholer
has to duplicate a subset of eval logic.  I wonder if the new approach
could eliminate that.

BTW, what is the rationale for leading +/- not being part of the
number literal? Unary +/- optimization seems mostly useful for the
simple +/-x case which could be handled by the tokenizer.

What is the timeline for that project?  Maybe a comment should be
placed in peephole.c explaining that there is a plan to move
uptimization logic up the compilation chain and announcing a
moratorium on further peephole.c work.  I am not the only one
submitting peephole optimizer patches recently.
""" http://bugs.python.org/issue2499#msg64638

I understand that the constant folding pass for AST is the subject of
http://bugs.python.org/issue1346238.  The first patch in that issue is
more than four years old.  Is that an indication that optimizing AST
is actually harder than optimizing bytecode?
___
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] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

[Alexander Belopolsky]

On Fri, Mar 11, 2011 at 9:53 PM, Alexander Belopolsky
 wrote:
> On Fri, Mar 11, 2011 at 9:28 PM, Raymond Hettinger
>  wrote:
>> Today, there was a significant check-in to the peephole optimizer that I
>> think should be reverted:
>>                http://hg.python.org/cpython/rev/14205d0fee45/
>
> +1
>
> I was going to comment on the corresponding issue #11244 more or less
> supporting Raymond's arguments.

When I wrote this, I was actually looking at the issue 11462.  I now
realize that #11462 was in fact closed as "rejected".

I am still confused, however, about [14205d0fee45].  The commit
message refers to "Issue #11244", but the comment does not match the
subject of the tracker issue:

"""
Issue #11244: The peephole optimizer is now able to constant-fold
arbitrarily complex expressions. This also fixes a 3.2 regression where
operations involving negative numbers were not constant-folded.
"""

I think issue #11244 is just the second part: "a 3.2 regression where
operations involving negative numbers were not constant-folded."

If this is the case, what is left to do for #11244?  The bug reported
in that issue seem to have been fixed:

>>> dis(lambda: (1,-2,3))
  1   0 LOAD_CONST   5 ((1, -2, 3))
  3 RETURN_VALUE
___
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] pydoc for named tuples is missing methods

[Tim Lesher]

On Mon, Mar 14, 2011 at 05:45, Nick Coghlan  wrote:
> There are two relatively simple ways forward I can see:
>
> A. Add a __public__ attribute that pydoc (and import *) understand.
> This would overrride the default "this is private" detection and add
> affected names to the public list (without needing to respecify all
> the "default public" names - this is important in order to support
> subclassing correctly)

I believe this was the direction the bug report was implying.

I'll be sprinting for a few hours this morning; if there are no
objections, I will try to turn this idea into a patch that makes
pydoc.visiblename look for a __public__ function attribute as "step
0".

Maybe there should also be a @public decorator to apply it, although
that name may be an attractive nuisance, tempting C++ or Java
programmers new to Python to ask for @protected and @private...

-- 
Tim Lesher 
___
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] pydoc for named tuples is missing methods

[Eric Smith]

On 03/14/2011 07:46 AM, Antoine Pitrou wrote:

On Mon, 14 Mar 2011 06:29:09 -0400
Eric Smith  wrote:

On 03/14/2011 02:33 AM, Greg Ewing wrote:

Tim Lesher wrote:


Because named tuple prefixes a single underscore to its added method
names (_asdict, _replace, and _make), those methods' docstrings are
omitted from pydoc:


IMO these should be called __asdict__, __replace__ and
__make__. Users are perfectly entitled to make up their
own single-underscore names, so using a single underscore
is not sufficient to prevent name collisions.


namedtuple won't let you use names starting with an underscore, so the
single underscore names are sufficient.


Not for members perhaps, but nothing prevents you from defining methods
with these names in a subclass AFAIK.


Good point. You can define methods or other attributes this way:

>>> from collections import namedtuple
>>> A = namedtuple('A', 'x y')
>>> class B(A):
...   _replace = 3
...
>>> b = B(1, 2)
>>> b._replace
3

___
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] cpython (3.2): Issue #11329: PyEval_InitThreads() cannot be called before Py_Initialize()

[Antoine Pitrou]

On Mon, 14 Mar 2011 06:01:17 -0400
Nick Coghlan  wrote:

> On Sun, Mar 13, 2011 at 6:29 PM, antoine.pitrou
>  wrote:
> >    .. index:: single: Py_Initialize()
> >
> > -   This is a no-op when called for a second time.  It is safe to call this 
> > function
> > -   before calling :c:func:`Py_Initialize`.
> > +   This is a no-op when called for a second time.
> 
> This change probably deserves a "versionchanged" tag and a note in the
> "Porting to Python 3" section of What's New, since it may cause
> weirdness for people embedding Python in their apps.

Agreed, will do.

cheers

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] pydoc for named tuples is missing methods

[Antoine Pitrou]

On Mon, 14 Mar 2011 06:29:09 -0400
Eric Smith  wrote:
> On 03/14/2011 02:33 AM, Greg Ewing wrote:
> > Tim Lesher wrote:
> >
> >> Because named tuple prefixes a single underscore to its added method
> >> names (_asdict, _replace, and _make), those methods' docstrings are
> >> omitted from pydoc:
> >
> > IMO these should be called __asdict__, __replace__ and
> > __make__. Users are perfectly entitled to make up their
> > own single-underscore names, so using a single underscore
> > is not sufficient to prevent name collisions.
> 
> namedtuple won't let you use names starting with an underscore, so the 
> single underscore names are sufficient.

Not for members perhaps, but nothing prevents you from defining methods
with these names in a subclass AFAIK.

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] pydoc for named tuples is missing methods

[Nick Coghlan]

On Mon, Mar 14, 2011 at 6:43 AM, Éric Araujo  wrote:
>> No, probably we should add some sort of __yes_i_am_public__ override
>> attribute that pydoc looks for. It's such a pity that those methods
>> have to have underscores...
>
> My opinion is that pydoc should use __dir__ (namedtuple does not
> currently use it but could).

Oh, I forgot about __dir__. However, the problem with that is that
dir() and __dir__() are designed to return *everything*, public or
private.

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] pydoc for named tuples is missing methods

[Éric Araujo]

> No, probably we should add some sort of __yes_i_am_public__ override
> attribute that pydoc looks for. It's such a pity that those methods
> have to have underscores...

My opinion is that pydoc should use __dir__ (namedtuple does not
currently use it but could).

Regards
___
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] pydoc for named tuples is missing methods

[Eric Smith]

On 03/14/2011 02:33 AM, Greg Ewing wrote:

Tim Lesher wrote:


Because named tuple prefixes a single underscore to its added method
names (_asdict, _replace, and _make), those methods' docstrings are
omitted from pydoc:


IMO these should be called __asdict__, __replace__ and
__make__. Users are perfectly entitled to make up their
own single-underscore names, so using a single underscore
is not sufficient to prevent name collisions.


namedtuple won't let you use names starting with an underscore, so the 
single underscore names are sufficient.


Eric.

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

Re: [Python-Dev] [Python-checkins] cpython (3.2): Issue #11329: PyEval_InitThreads() cannot be called before Py_Initialize()

[Nick Coghlan]

On Sun, Mar 13, 2011 at 6:29 PM, antoine.pitrou
 wrote:
>    .. index:: single: Py_Initialize()
>
> -   This is a no-op when called for a second time.  It is safe to call this 
> function
> -   before calling :c:func:`Py_Initialize`.
> +   This is a no-op when called for a second time.

This change probably deserves a "versionchanged" tag and a note in the
"Porting to Python 3" section of What's New, since it may cause
weirdness for people embedding Python in their apps.

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] pydoc for named tuples is missing methods

[Nick Coghlan]

On Mon, Mar 14, 2011 at 2:33 AM, Greg Ewing  wrote:
> Tim Lesher wrote:
>
>> Because named tuple prefixes a single underscore to its added method
>> names (_asdict, _replace, and _make), those methods' docstrings are
>> omitted from pydoc:
>
> IMO these should be called __asdict__, __replace__ and
> __make__. Users are perfectly entitled to make up their
> own single-underscore names, so using a single underscore
> is not sufficient to prevent name collisions.

True, but all those underscores are a PITA to type and read for
methods that are meant to be called directly. A single leading
underscore is enough to move them out of the way of the standard
public fields of a named tuple. Giving a nominally private name to a
field that is already publically accessible via index would be
nonsensical.

There are two relatively simple ways forward I can see:

A. Add a __public__ attribute that pydoc (and import *) understand.
This would overrride the default "this is private" detection and add
affected names to the public list (without needing to respecify all
the "default public" names - this is important in order to support
subclassing correctly)

B. Add a different prefix to the named tuple methods (e.g ntup_asdict,
ntup_replace, ntup_make).

There's also an even more radical alternative:

C. Add syntax for bypassing the instance lookup when accessing attributes.

If "obj..replace(*args)" (or whatever - this specific example arguably
fails the "syntax shall not look like grit on Tim's monitor" test) was
guaranteed to do the moral equivalent of "type(obj).replace(obj,
*args)", then these could all become normal public methods, with the
caveat that access via the class should be forced when using them.
This would also make a *lot* of the Python code dealing with magic
methods a fair bit cleaner (we currently have to do the type(obj)
dance manually in various places to avoid metaclass confusion issues).

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] pydoc for named tuples is missing methods

[Raymond Hettinger]

On Mar 13, 2011, at 7:41 PM, Tim Lesher wrote:

> [I mentioned this to Raymond Hettinger after his PyCon talk, and I
> promised a bug and hopefully a patch. I don't see an obvious solution,
> though, so I'll ask here first.]

Just make a tracker entry and assign it to me.
I'll take a look and see what can be done.


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